Evaluation of global LC model not working

Hey Nestor,
I encountered some bug in the evaluation of global LC models that I am not able to resolve myself.
The setting is the following:
I use only a global GP ("_lc") and different instrumental parameters (sigma_w, mflux, mdilution) for a set of photometry from different instruments to search for the rotation period in a light curve.
The fit seems to have worked (it converges and produces the pkl-file and posterior). However, I would like to plot the light curve and model. But this unfortunately doesn't work.
I use the results from the juliet.fit-object and try to run
  model_lc = results.lc.evaluate("instrument",  t=model_times,  GPregressors=model_times)

where instrument is one of the instruments that is used and model_times are the super-sampled model times. I usually used this for RV fits, but I assume it should work the same for light curves.
Unfortunately, it  produces the error (please ignore the lines given in the traceback, they refer to the pep-formated code):
Traceback (most recent call last):
  File ".../juliet/juliet/fit.py", line 2793, in evaluate_model
    x = self.evaluate_model(instrument = instrument, parameter_values = self.posteriors, resampling = resampling, \
  File ".../juliet/juliet/fit.py", line 2430, in evaluate_model
    ginstrument] = dummy_indexes
UnboundLocalError: local variable 'dummy_indexes' referenced before assignment

I was able to trace back the declaration of dummy_indexes to l. 1998 (last commit of yours). There the variable is assigned, but only within an else-statement that is valid for RV models. I assume that this may be an indentation error and therefore unindented the line once.
However, this only brought up another error:
Traceback (most recent call last):
  File ".../juliet/juliet/fit.py", line 2793, in evaluate_model
    x = self.evaluate_model(instrument = instrument, parameter_values = self.posteriors, resampling = resampling, \
  File ".../juliet/juliet/fit.py", line 2433, in evaluate_model
    self.generate_lc_model(
  File ".../juliet/fit.py", line 3172, in generate_lc_model
    self.model['global'][self.instrument_indexes[
IndexError: index 854 is out of bounds for axis 0 with size 854

I tried to dig down deeper, but was not able to fully understand the differences that are necessary for the light curve models in comparison to the RV models.
For example, I could see that you set self.model['global'] = np.ones(len(t)) for the RVs (l. 2123), while you don't do so for the lc models.
However, adding this lead only down to the "rollback" in l. 2207 and following, where even more variables were unassigned because they were only defined in some rv-else statements.
Do you have any idea what the issue could be?

Hi @JonasKemmer,
Sorry for coming so late to this. I do have an idea on what is going on, but don't have the time today to work on this. Will leave it on my plate to fix --- will come back to this later in the week to fix!
Néstor

Tracking back to old bugs. @JonasKemmer --- is this still an issue or you solved it with your PR? A working example would be great to check.
N.


Failed sending data to the peer with latest nightly

Problem

Builds inside docker containers (CI) seem to fail on nightly versions > 2021-07-05.
error: failed to compile `sccache v0.2.15`, intermediate artifacts can be found at `/tmp/cargo-installYaFAmQ`

Caused by:
failed to download from `https://crates.io/api/v1/crates/async-io/1.6.0/download`

Caused by:
[55] Failed sending data to the peer (Connection died, tried 5 times before giving up)

Steps

Build a project inside a docker container.

Possible Solution(s)

Using nightly 2021-07-05 with rustup default nightly-2021-07-05 appears to fix the issue.
Notes
May be related to #6513.
https://github.community/t/failed-sending-data-to-the-peer-connection-died-tried-5-times-before-giving-up/189130
Output of cargo version:
cargo 1.55.0-nightly (3ebb5f15a 2021-07-02) (oddly this is the same version that seems to fail in the latest nightly builds).

Is it a duplicate of https://github.com/rust-lang/crates.io/issues/3782?

Is it a duplicate of rust-lang/crates.io#3782?

Yep, apologies, searched for the error but didn't see any results.

The next nightly (in about 12 hours from the time of this post) should have a temporary workaround in #9695.


pnpm support / fix debugging ui

Added support for pnpm and fixing debugging ui.
https://github.com/callstack/haul/issues/432

@ThomasMichon I'd be happy to accept a PR with the changes you suggested, especially when proven to be faster or easier to maintain/read :)


chore: improve e2e tests login and welcome screen flow

This PR adds some improvements to the e2e test. Some of the code in the login flow were actually not working properly e.g. https://github.com/GaloyMoney/galoy-mobile/pull/1701/files#diff-8ffce1538d4d0c0cd9a295395d3e111073f9cf483a2b104d9ddf92bba152b07eL68
Also, somehow the displayCurrency of some of the test accounts was not USD by default which caused some the send flow tests to fail (see here for browserstack video). Maybe someone used the token locally, changed it to different currency??. Regardless, I have added a function to reset the display currency.

Any idea why the tests are currently failing on Android?

Yeah. The list of buttons in the settings screen does not currently fit into the screen all together. So when we scroll down to enter the debug screen and come back to the settings screen, the phone number button(which we also use to validate that the user is logged in) is no longer in focus. For bigger screens, this is not an issue. So I added the scroll command in this PR to scroll up to show the phone button for smaller screens.

@UncleSamtoshi should we merge this one? it seems it's fixing the e2e on android (at least partially?)

@UncleSamtoshi should we merge this one? it seems it's fixing the e2e on android (at least partially?)

This PR was originally intended to fix the android tests. We can merge it if its okay by you and @UncleSamtoshi
Might beed a rebase though

Closing this PR in as the tests has been fixed here https://github.com/GaloyMoney/galoy-mobile/pull/1742


Added Integration tests against arrow

This enables the integration tests on our side by cloning apache/arrow@master and running our PRs against it.
This job takes some time, as there docker layers are not being cached. I think that this is already a problem in apache/arrow@master and imo we should address there.

Codecov Report

Merging #10 (e2b0faa) into master (ae812db) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head e2b0faa differs from pull request most recent head 0f389bd. Consider uploading reports for the commit 0f389bd to get more accurate results

@@           Coverage Diff           @@
##           master      #10   +/-   ##
=======================================
  Coverage   82.47%   82.47%
=======================================
  Files         162      162
  Lines       43414    43414
=======================================
  Hits        35806    35806
  Misses       7608     7608

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ae812db...0f389bd. Read the comment docs.

I rewrote master to remove the history of the other languages (and 50MB of history). This means this PR will need to be "rebased" against the current master.
The best way I found to do this was to find the relevant commits (via git log) and then cherry-pick them one at a time. For example (change COMMIT-SHA to whatever the commit actually is):
git reset --hard apache/master
git cherry-pick COMMIT-SHA
git push -f alamb

@jorgecarleitao  I don't see the Integration test being triggered on this PR . Do we need to do something else to get it to run?

I think I made a mistake: we probably need synchronize on the list of triggers in the pull_request. I was trying to not trigger this when the PR was marked as drafted but caused a false-positive.

(it did triggered the first time I made it, but I can see that a force push is not triggering it)

I'm not too familiar with archery but the overall approach seems reasonable

@alamb , thanks for the rebase; @nevi-me , thanks for the review.
@wesm @kszucs , any concerns  / alternatives with this approach? I suspect that other implementations (Julia) may copy this, and thus some validation beyond rust is appreciated.

It seems like a clean approach, though we'll need to update the integration testing in apache/arrow to include arrow-rs, so this configuration will need an update after that.

though we'll need to update the integration testing in apache/arrow to include arrow-rs, so this configuration will need an update after that.

Got it. In https://github.com/apache/arrow/pull/10096, the last commit introduces a git clone from this repo to rust/ in apacher/arrow/, so that the tests run on apache/arrow pick this one. Wouldn't that be enough?

Wouldn't that be enough?

Yes, at least I think so.


New Options for Chi Correction in MAC Projections

This was needed for the manifold stuff, so moving it in now to capture some progress toward fully merging that capability. Probably won't merge the rest for a while though.
This PR does two things:

Optionally print the zero norm of the chi correction on each SDC iteration, which indicates the mismatch between the actual pressure and the prescribed pressure based on the Low Mach assumption. This can be used to assess how the SDC iterations are converging. Note that the values printed are the mismatch before the indicated iteration, so the value for the 0th iteration on one time step corresponds to the value at the end of the previous timestep. That output looks something like this:

   SDC iter [1]
      Before SDC 1: max relative P mismatch is 0.0002924937001
   - oneSDC()::MACProjection()   --> Time: 0.003672
   - oneSDC()::ScalarAdvection() --> Time: 0.009108
   - oneSDC()::ScalarDiffusion() --> Time: 0.059437
   - oneSDC()::ScalarReaction()  --> Time: 0.76213
   SDC iter [2]
   - oneSDC()::Update t^{n+1,k}  --> Time: 0.029643
      Before SDC 2: max relative P mismatch is 0.01296565691
   - oneSDC()::MACProjection()   --> Time: 0.003565
   - oneSDC()::ScalarAdvection() --> Time: 0.009067
   - oneSDC()::ScalarDiffusion() --> Time: 0.057344
   - oneSDC()::ScalarReaction()  --> Time: 0.757911

Offer new strategies for how the divergence constraint on each SDC iteration is computed:

DivuEveryIter (current, remains default),
DivuFirstIter (the estimate of Divu computed on the 0th SDC iteration is kept constant, and only the chi correction is used to drive the solution toward convergence)
NoDivu (the Divu estimates are ignored in the MAC projection and only the chi correction is used to iteratively ensure the actual pressure (RhoRT) matches the desired value)

For the PMF case, it can be observed that the second option provides better convergence of the pressure than the first. My working hypothesis is that updating the estimated divergence constraint essentially adds noise to the iterative update of the chi correction. The converged solution with infinite SDC iterations would be the same between all methods, but the rate of convergence is not. The existing approach is left as the default because the alternative DivuFirstIter approach hasn't been tested for a wide range of cases yet. The NoDivu option should never be used and is only included for comparison. In the latter two options, some compute could be saved by not recomputing the divergence estimate at each n+1,k, but for now it is computed but then ignored.

The convergence gets much better with smaller timesteps. I'm not sure about grid resolution, but I imagine that also helps.


feat: add workspace status check to code and ssh commands #821

Pull Request Title
Add workspace status check to code and ssh commands
Description
Currently, the code and ssh commands do not check the status of the project before opening them in IDE or doing an ssh. This change adds additional checks to do the same.

[ ] This change requires a documentation update
[ ] I have made corresponding changes to the documentation

Related Issue(s)
This PR addresses issue https://github.com/daytonaio/daytona/issues/770
Screenshots

Notes
None

/claim #770

@titanventura hi buddy, some suggestions for you, it will help your pr to get merge early

In the description's instead of Pull Request Title renamed it to feat add workspace status check to code and ssh commands, do not write beside it
in section fo related issues besides the above reference line use closes #770 and also add these /claim #770 to that.
one more thing made a new commit by signing off means use git commit -m "your commit name" --signoff
then after that use one more command git push origin <your branch name> --force  to check the tests after pushing.

@titanventura code looks good and everything works great. Nice work.
Before I approve:

please run go fmt ./... to format the code so the checks can pass
Please squash all your commits into one with the following message: feat: add project status check when opening


ctx passed as a argument vs bound as this

So I just noticed Koa v2 is on it's way soon, and I decided to take a gander at it and I noticed that it's now the signature is function (ctx, next) instead of function (next) with ctx bound as this. Is there a reason this was changed in v2?

This has been discussed in details in #581.

Okay thank you, I tried to find it but couldn't.

Hmmm, after reading them, I failed to see why the change in signature was made, just examples using it.

the primary reason is so that you can write koa apps w/ async arrow functions:
async (ctx, next) => {
  await next()
}

using this, it is impossible

Ah, arrow functions. Makes sense. Thanks @jonathanong


Add Tools Version to Version Schema

Closes #729 unless there was an intention to display this somewhere or reveal it in the Prometheus metrics?
⚠ Schema change ⚠

If you want me to look at increasing test coverage just let me know 👍

Nothing big really, I just wanted to make sure we record a "live" fixture with the _version key somewhere and decode it. Would be even better if we ran an actual swift package dump-package and decoded that so that we're alerted when the key changes from _version (if it ever will) but I didn't want to bother with that now.
I've also made toolsVersion optional, because we had a failure in test_processing_pipeline where we didn't mock that key in. While it is strictly possible to get a package dump without toolsVersion that's for Swift 3, which we don't support. So we wouldn't need to make that option but it's just simpler for the test.
I've open a PR with your changes and my little tweaks now - thanks again for picking this up!


Additional VTO events

https://github.com/rroller/dahua/issues/28

Hey @rroller , any chance that you are able to get back to this one? I also have a Dahua VTO and would love to have these additional items.
Thank you very much!


Replace checksums files by Dataset infos json

Better verifications when loading a dataset
I replaced the urls_checksums directory that used to contain checksums.txt and cached_sizes.txt, by a single file dataset_infos.json. It's just a dict config_name -> DatasetInfo.
It simplifies and improves how verifications of checksums and splits sizes are done, as they're all stored in DatasetInfo (one per config). Also, having already access to DatasetInfo enables to check disk space before running download_and_prepare for a given config.
The dataset infos json file is user readable, you can take a look at the squad one that I generated in this PR.
Renaming
According to these changes, I did some renaming:
save_checksums -> save_infos
ignore_checksums -> ignore_verifications
for example, when you are creating a dataset you have to run
nlp-cli test path/to/my/dataset --save_infos --all_configs
instead of
nlp-cli test path/to/my/dataset --save_checksums --all_configs
And now, the fun part
We'll have to rerun the nlp-cli test ... --save_infos --all_configs for all the datasets

feedback appreciated !

Great! LGTM :-)

Ok, really clean!
I like the logic (not a huge fan of using _asdict_inner but it makes sense).
I think it's a nice improvement!
How should we update the files in the repo? Run a big job on a server or on somebody's computer who has most of the datasets already downloaded?

Maybe we can split the updates among us...IMO most datasets run very quickly.
I think I've downloaded 50 datasets and 80% are loaded in <5min,  15% in <1h and then wmt which is still downloading (since 12h).
I deleted my cache because the wmt downloads require quite a lot of space, so I only have parts of the wmt datasets on my computer.
@mariamabarham I guess you have downloaded most of the datasets no?


Can I use this module with sequelize-typescript?

I prefer to use https://github.com/RobinBuschmann/sequelize-typescript for defining my models. Do your module work with it?

I am using sequelize-auto-migrations with sequelize-typescript.
sequelize-cli snipet created by sequelize init is not support sequelize-typescript model.
you need to change model loading manually.
sample is below.
// models/index.js
'use strict';

var fs = require('fs');
var path = require('path');
var parseDbUrl = require("parse-database-url");
var Sequelize = require('sequelize-typescript').Sequelize;
var basename = path.basename(__filename);
var env = process.env.NODE_ENV || 'development';
var config = require(__dirname + '/../config/config.json')[env];
var db = {};

var dbConfig = parseDbUrl(process.env[config.use_env_variable]);

var sequelize = new Sequelize({
  name: dbConfig.database,
  username: dbConfig.user,
  password: dbConfig.password,
  dialect: dbConfig.driver,
  host: dbConfig.host,
  port: dbConfig.port,
  modelPaths: [__dirname + '/../dist/js/main/models'] // you must prepare compiled javascript source.
});

Object.keys(sequelize.models).forEach((modelName) => {
  db[modelName] = sequelize.models[modelName];
});

db.sequelize = sequelize;
db.Sequelize = Sequelize;

module.exports = db;

I think it does. There's no need to write in the flavor of the index.js generated by sequelize-cli. You just need the two objects: Sequelize, which is the node module, and sequelize, which is the sequelize instance.
And to prevent sequelize-typescript to mis-treat the index.ts or index.js file as a model, you may change the modelPaths to another location.
Generally, you can write in the following spirit:
'use strict';

import {Sequelize} from 'sequelize-typescript';

const db: any = {};
const devConfig = require('../config/config.json').development;

const sequelize = new Sequelize(Object.assign({
  username: 'devuser',
  password: 'somepassword',
  name: 'devdb',
  host: '<IP_ADDRESS>',
  dialect: 'postgres',
  validateOnly: false,
  modelPaths: [__dirname + '/../models/inuse']
}, devConfig));

db.sequelize = sequelize;
db.Sequelize = Sequelize;

module.exports = db;

This didn't seem to work for me anymore. instead, I created a fork for our project which directly integrates with sequelize-typescript. In case anyone gets issues with this I'll leave a link https://github.com/top-gg/sequelize-typescript-auto-migrations


Wrong values reported in time intervals

https://travis-ci.com/openshift/odo/jobs/207361276#L1442
The value reported is 2562047h47m16.854775807s which is equivalent to<PHONE_NUMBER> years

@cdrage can please you look into it?
/kind bug
/priority medium

@mik-dass LOL. That shouldn't happen. I'll take this up :+1:

@mik-dass I have a feeling it has to do with:
https://github.com/openshift/odo/blob/master/pkg/log/fidget/spinner.go#L125
and the Travis CI environment not reporting the time correctly...
Hopefully it's just a fluke and won't happen again, but I'll do some quick debugging and see how in the world they managed to get such a high value.

@mik-dass I have a feeling it has to do with:
https://github.com/openshift/odo/blob/master/pkg/log/fidget/spinner.go#L125
and the Travis CI environment not reporting the time correctly...
Hopefully it's just a fluke and won't happen again, but I'll do some quick debugging and see how in the world they managed to get such a high value.

@cdrage It is not related to TravisCI, I can see it in integrations tests if running on my local machine.
Interestingly if I run odo command manually from the terminal, it is ok, but in tests outputs, it is still wrong.

@cdrage interestingly this weird time interval happens when we enable the -v flag. @kadel Since we run the integration tests with the v flag enabled, it shows the weird interval in the integration tests. Without the flag it seems to work fine.

@mik-dass Managed to fix it. The code logic wasn't adding a value to the time variable in the struct. Hence the value overflow and it saying it was taking wayyyyy longer than normal haha. Fixed in the PR! https://github.com/openshift/odo/pull/1824


Improve quick pick experiment selection

[ ] The commands "Modify Experiment Param(s) and Resume", "Modify Experiment Param(s) and Queue" , and "Modify Experiment Param(s) and Run" are only showing the branches instead of all experiments.
[ ] The command "Remove Experiment" (possible some others as well) doesn't let you filter by description and detail
[ ] All quick picks for experiment selection should be showing the first three columns

I think Remove Experiment should be Remove Experiments and moved to canPickMany


Plaintext (serializeNodesToText): join text of node with separating spaces: separate list items

fix for https://github.com/eea/volto-slate/issues/67

May I have more info to fix the problem jenkins found? I have no access to the log.


Update troubleshoot-microsoft-store-for-business.md

added link to the troubleshooting guide, issue #1664

@nenonix @JohanFreelancer9 - kindly do the copy editor review for this PR. Thanks.

Dear @JohanFreelancer9 ,
your recommendations were applied, thank you!

@TrudyHa @jaimeo @lizap - Can you please assist to check, approve and merge the content of this PR based on issue #1664?
Thank you.

@mypil et al - I've reviewed and will merge now. However, please note that I had to correct the reference to Configuration Manager to use the actual product name. Please use caution when referring to Microsoft services and products - no nicknames or abbreviations, please.

@lizap - this is noted. Thank you for your help in merging the PR content. Looping in @nenonix so this info could be added in the Wiki.


Should throw an error when no BLE command is sent after a request is received ?

I’m using your proxy with evcc, within in a custom charger and it’s working quite good. Today I observed some strange behavior with current not being adjusted and charge not stopping. When looking at the log, I saw the requests received, but nothing happening and no error:
2024/06/16 14:56:53 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:5]
2024/06/16 14:58:23 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:4]
2024/06/16 14:58:53 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:3]
2024/06/16 14:59:23 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:2]
2024/06/16 15:01:24 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:3]
2024/06/16 15:01:24 received command "charge_start" (VIN: MYMODELY) with body: map[]
2024/06/16 15:01:53 received command "wake_up" (VIN: MYMODELY) with body: map[]
2024/06/16 15:02:23 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:5]
2024/06/16 15:03:53 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:3]
2024/06/16 15:04:23 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:1]
2024/06/16 15:06:53 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:2]
2024/06/16 15:07:23 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:3]
2024/06/16 15:07:53 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:4]
2024/06/16 15:08:23 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:2]
2024/06/16 15:08:53 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:1]
2024/06/16 15:11:03 received command "charge_stop" (VIN: MYMODELY) with body: map[]
2024/06/16 15:14:53 received command "charge_stop" (VIN: MYMODELY) with body: map[]
2024/06/16 15:18:23 received command "charge_stop" (VIN: MYMODELY) with body: map[]
After restarting the container, everything started to work as expected again:
2024/06/16 16:11:50 TeslaBleHttpProxy is loading ...
2024/06/16 16:11:50 TeslaBleHttpProxy is running!
2024/06/16 16:12:27 received command "charge_stop" (VIN: MYMODELY) with body: map[]
2024/06/16 16:12:27 handle command: charge_stop (VIN: MYMODELY)
2024/06/16 16:12:27 Connecting to vehicle...
2024/06/16 16:12:29 sending command "charge_stop"...
2024/06/16 16:12:30 The command "charge_stop" was successfully executed.
Going back in the log I observed there has been some errors before and then at some point it seems the just give up trying to send BLE command until the restart.
2024/06/16 11:34:37 retrying in 6 seconds
2024/06/16 11:34:43 Connecting to vehicle...
2024/06/16 11:34:53 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:7]
2024/06/16 11:34:53 stop retrying after 3 attempts
2024/06/16 11:34:53 The command "set_charging_amps" was canceled:
2024/06/16 11:34:53 [Error]failed to connect to vehicle (A): failed to find BLE beacon for MYMODELY (S67a76e989a933054C): can't scan: context deadline exceeded
2024/06/16 11:34:54 handle command: set_charging_amps (VIN: MYMODELY)
2024/06/16 11:34:54 Connecting to vehicle...
2024/06/16 11:35:23 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:8]
2024/06/16 11:35:53 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:7]
2024/06/16 11:42:53 received command "set_charging_amps" (VIN: MYMODELY) with body: map[charging_amps:6]
Do you understand this behavior ? Instead of stopping to send BLE command, shouldn’t error be thrown for every command (and reported to evcc) ? Would it be possible to detect this special state and automatically restart the container ?
Let me know if you know if you need more information or test, I’ll be happy to help!

Thank you for the detailed description.
This behavior should not be possible. I will try to add some more debug logs next week, so we can locate the problem.

I'm having the same issue.
After a while commands are being received but not executed anymore.
If the proxy is restarted everything works again.
Can I enable some logging that could help in this case?
body=map[] 2024/06/29 16:51:24 INFO received command
command=set_charging_amps VIN= body=map[charging_amps:3]
2024/06/29 16:51:49 INFO received command command=set_charging_amps
VIN= body=map[charging_amps:4] 2024/06/29 16:55:05 INFO
received command command=charge_stop VIN= body=map[]
2024/06/29 16:55:21 INFO received command command=charge_stop
VIN= body=map[] 2024/06/29 16:55:49 INFO received command
command=charge_stop VIN= body=map[] 2024/06/29 16:56:05
INFO received command command=charge_stop VIN= body=map[]
2024/06/29 16:56:30 INFO received command command=charge_stop
VIN= body=map[] 2024/06/29 16:56:44 INFO received command
command=set_charging_amps VIN= body=map[charging_amps:2]
2024/06/29 16:57:04 INFO received command command=set_charging_amps
VIN= body=map[charging_amps:3] 2024/06/29 16:57:29 INFO
received command command=charge_stop VIN= body=map[]
2024/06/29 16:57:55 INFO received command command=charge_stop
VIN= body=map[] 2024/06/29 16:58:22 INFO received command
command=set_charging_amps VIN= body=map[charging_amps:2]
2024/06/29 16:58:34 INFO received command command=set_charging_amps
VIN= body=map[charging_amps:3] 2024/06/29 16:59:19 INFO
received command command=set_charging_amps VIN=
body=map[charging_amps:4] 2024/06/29 16:59:29 INFO received command
command=set_charging_amps VIN= body=map[charging_amps:3]
2024/06/29 16:59:44 INFO received command command=set_charging_amps
VIN= body=map[charging_amps:4] 2024/06/29 17:03:54 INFO
received command command=set_charging_amps VIN=
body=map[charging_amps:3] 2024/06/29 17:06:14 INFO received command
command=charge_stop VIN= body=map[] 2024/06/29 17:06:34
INFO received command command=set_charging_amps VIN=
body=map[charging_amps:3] 2024/06/29 17:32:59 INFO received command
command=charge_stop VIN= body=map[] 2024/06/29 17:33:19
INFO received command command=set_charging_amps VIN=
body=map[charging_amps:3] 2024/06/29 17:34:59 INFO received command
command=set_charging_amps VIN= body=map[charging_amps:3]
2024/06/29 17:35:29 INFO received command command=set_charging_amps
VIN= body=map[charging_amps:2] 2024/06/29 17:35:59 INFO
received command command=set_charging_amps VIN=
body=map[charging_amps:3] 2024/06/29 17:36:29 INFO received command
command=set_charging_amps VIN= body=map[charging_amps:3]
2024/06/29 17:36:54 INFO received command command=set_charging_amps
VIN= body=map[charging_amps:2] 2024/06/29 17:37:09 INFO
received command command=set_charging_amps VIN=
body=map[charging_amps:3] 2024/06/29 17:41:49 INFO received command
command=set_charging_amps VIN= body=map[charging_amps:2]
2024/06/29 17:42:19 INFO received command command=set_charging_amps
VIN= body=map[charging_amps:3] 2024/06/29 17:43:39 INFO
received command command=set_charging_amps VIN=
body=map[charging_amps:2] 2024/06/29 17:53:49 INFO received command
command=set_charging_amps VIN= body=map[charging_amps:2]
2024/06/29 17:56:14 INFO received command command=set_charging_amps
VIN= body=map[charging_amps:2] 2024/06/29 18:08:30 INFO
received command command=charge_stop VIN= body=map[]
2024/06/29 18:08:59 INFO received command command=charge_stop
VIN= body=map[] 2024/06/29 18:09:22 INFO received command
command=set_charging_amps VIN= body=map[charging_amps:2]
2024/06/29 18:09:47 INFO received command command=set_charging_amps
VIN= body=map[charging_amps:2]
2024/06/29 18:23:42 INFO received command command=charge_stop VIN= body=map[]

Can you please set the environment variable logLevel to debug and post the log of when this happens?
I wasn’t able to reproduce this.

@gauner1986, are you calling the ble proxy from a custom vehicle or a custom charger in evcc ?
The reason I’m asking that is that I had this issue when using it at the charger level, and after charging a non-Tesla vehicle on my TWC3. Since I switched to using the ble proxy at the vehicle level for, I didn’t experience the issue. So it may be the accumulation of errors when trying to send commands to the no-connected vehicle that may lead to this weird state.
In other words, can you provide more information on the context in which you are using the ble proxy ? This could help, in addition to more detail logs, to find the root cause of that.

I have bumped the log level to debug and am hoping for a sunny day in the next time.
I'm actually not using EVCC at all. I have my own automations in home assistant which do my solar excess charging.
Excerpt of my configuration.yaml
rest_command:
tesla_set_charging_amps:
url: http://pi:8080/api/1/vehicles/VIN/command/set_charging_amps
method: POST
payload: '{"charging_amps": "{{charging_amps}}"}'
content_type:  'application/json'
tesla_set_charge_limit:
url: http://pi:8080/api/1/vehicles/VIN/command/set_charge_limit
method: POST
payload: '{"percent": "{{charge_limit}}"}'
content_type:  'application/json'
tesla_wakeup:
url: http://pi:8080/api/1/vehicles/VIN/command/wake_up
method: POST
tesla_charge_start:
url: http://pi:8080/api/1/vehicles/VIN/command/charge_start
method: POST
tesla_charge_stop:
url: http://pi:8080/api/1/vehicles/VIN/command/charge_stop

Usually if that happens you receive a connection error though. In our error case here there's no feedback to the received commands at all.
I had a case where it just happened in a series of events without any delays:
2024/06/28 16:24:04 INFO The command was successfully executed. command=charge_stop
2024/06/28 16:24:24 INFO received command command=charge_start VIN=VIN body=map[]
2024/06/28 16:24:24 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2]
2024/06/28 16:24:25 INFO handle command command=charge_start VIN=VIN
2024/06/28 16:24:28 INFO The command was successfully executed. command=charge_start
2024/06/28 16:24:29 INFO handle command command=set_charging_amps VIN=VIN
2024/06/28 16:24:32 INFO The command was successfully executed. command=set_charging_amps
2024/06/28 16:24:54 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3]
2024/06/28 16:24:55 INFO handle command command=set_charging_amps VIN=VIN
2024/06/28 16:24:58 INFO The command was successfully executed. command=set_charging_amps
2024/06/28 16:25:15 INFO received command command=charge_stop VIN=VIN body=map[]
2024/06/28 16:25:15 INFO handle command command=charge_stop VIN=VIN
2024/06/28 16:25:24 INFO received command command=charge_stop VIN=VIN body=map[]
2024/06/28 16:26:05 INFO received command command=charge_stop VIN=VIN body=map[]
2024/06/28 16:26:24 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3]
2024/06/28 16:26:35 INFO received command command=charge_stop VIN=VIN body=map[]
2024/06/28 16:26:44 INFO received command command=charge_stop VIN=VIN body=map[]
2024/06/28 16:27:04 INFO received command command=charge_stop VIN=VIN body=map[]
2024/06/28 16:27:19 INFO received command command=charge_stop VIN=VIN body=map[]
2024/06/28 16:30:40 INFO received command command=charge_stop VIN=VIN body=map[]
2024/06/28 16:32:04 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3]
2024/06/28 16:32:24 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3]

Are you using on board ble or a dongle? I had a dongle that would crash
until I rebooted but that’s probably not your issue because that gave errors
On Tue, 2 Jul 2024 at 08:27, gauner1986 @.***> wrote:

Usually if that happens you receive a connection error though. In our
error case here there's no feedback to the received commands at all.
I had a case where it just happened in a series of events without any
delays:
2024/06/28 16:24:04 INFO The command was successfully executed.
command=charge_stop
2024/06/28 16:24:24 INFO received command command=charge_start VIN=VIN
body=map[]
2024/06/28 16:24:24 INFO received command command=set_charging_amps
VIN=VIN body=map[charging_amps:2]
2024/06/28 16:24:25 INFO handle command command=charge_start VIN=VIN
2024/06/28 16:24:28 INFO The command was successfully executed.
command=charge_start
2024/06/28 16:24:29 INFO handle command command=set_charging_amps VIN=VIN
2024/06/28 16:24:32 INFO The command was successfully executed.
command=set_charging_amps
2024/06/28 16:24:54 INFO received command command=set_charging_amps
VIN=VIN body=map[charging_amps:3]
2024/06/28 16:24:55 INFO handle command command=set_charging_amps VIN=VIN
2024/06/28 16:24:58 INFO The command was successfully executed.
command=set_charging_amps
2024/06/28 16:25:15 INFO received command command=charge_stop VIN=VIN
body=map[]
2024/06/28 16:25:15 INFO handle command command=charge_stop VIN=VIN
2024/06/28 16:25:24 INFO received command command=charge_stop VIN=VIN
body=map[]
2024/06/28 16:26:05 INFO received command command=charge_stop VIN=VIN
body=map[]
2024/06/28 16:26:24 INFO received command command=set_charging_amps
VIN=VIN body=map[charging_amps:3]
2024/06/28 16:26:35 INFO received command command=charge_stop VIN=VIN
body=map[]
2024/06/28 16:26:44 INFO received command command=charge_stop VIN=VIN
body=map[]
2024/06/28 16:27:04 INFO received command command=charge_stop VIN=VIN
body=map[]
2024/06/28 16:27:19 INFO received command command=charge_stop VIN=VIN
body=map[]
2024/06/28 16:30:40 INFO received command command=charge_stop VIN=VIN
body=map[]
2024/06/28 16:32:04 INFO received command command=set_charging_amps
VIN=VIN body=map[charging_amps:3]
2024/06/28 16:32:24 INFO received command command=set_charging_amps
VIN=VIN body=map[charging_amps:3]
—
Reply to this email directly, view it on GitHub
https://github.com/wimaha/TeslaBleHttpProxy/issues/6#issuecomment-2201200666,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKH2FP3GXU4BLG6PDHAJEQTZKHJUJAVCNFSM6AAAAABJMWDSZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBRGIYDANRWGY
.
You are receiving this because you commented.Message ID:
@.***>

I'm using a raspberry pi 1 with a USB dongle.

Check dmesg for an issues in there. I found that my UB400 worked fine but
my UB500 would crash on raspian. On Ubuntu on a pi zero 2 w the UB500
worked fine
On Tue, 2 Jul 2024 at 09:00, gauner1986 @.***> wrote:

I'm using a raspberry pi 1 with a USB dongle.
—
Reply to this email directly, view it on GitHub
https://github.com/wimaha/TeslaBleHttpProxy/issues/6#issuecomment-2201325408,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKH2FPZCD4TPB2CT4RQ6ISTZKHNRBAVCNFSM6AAAAABJMWDSZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBRGMZDKNBQHA
.
You are receiving this because you commented.Message ID:
@.***>

Will do. Though last time I had the problem it was enough to simply restart the proxy.

There are no unhandled errors in the program. So maybe the problem is in the ble package itself. It seems the handle loop is blocked without return or error.
Maybe we can find the error with debug log.

I have the same issue on a Raspberry pi Zero W.  When charging, I hit the proxy every 15 seconds with a "set_charging_amps" command.  After several hours, I see repeated "received command", but the commands are not sent to the car, nor is there any other error or informational message.

Any Debug Logs?

I've created a new version with the following improvements that might solve this problem:

The ble connection will be reused for all subsequent requests for 30 seconds
This improvement has been incorporated: https://github.com/teslamotors/vehicle-command/pull/269

The version is under the dev tag on Docker: image: wimaha/tesla-ble-http-proxy:dev
Could you please test this version? Thank you!

Couldn't test a lot in the past few days because of very bad weather in Hamburg.
I'm building myself and running without docker due to system constraints. Did you commit in a special branch?

Yes, you will find it in the branch refactor/performance-optimization: https://github.com/wimaha/TeslaBleHttpProxy/tree/refactor/performance-optimization

Any Debug Logs?

I am now running your "refactor" version, with debug set.  I'll share my experience and the logs, should the issue reoccur.

Interesting behaviour...
I notice that when the proxy throws this error, my car goes to zero amps (as shown on the app and in my energy monitor) and then quickly climbs back up to the target.  When I kill the proxy, the odd behaviour goes away.
Thoughts?
2024/07/07 12:31:46 INFO TeslaBleHttpProxy is loading ... 2024/07/07 12:31:46 DEBU LogLevel set to debug 2024/07/07 12:31:46 INFO TeslaBleHttpProxy is running! 2024/07/07 12:32:04 INFO received command command=set_charging_amps VIN=LRWYHCEL4PC726XYZ body=map[charging_amps:23] 2024/07/07 12:32:05 INFO handle command command=set_charging_amps VIN=LRWYHCEL4PC726XYZ 2024/07/07 12:32:06 WARN failed to connect to vehicle (A): ble: failed to enumerate device services: ATT request failed: input channel closed: io: read/write on closed pipe 2024/07/07 12:32:06 INFO retrying in 3 seconds 2024/07/07 12:32:10 WARN failed to connect to vehicle (A): ble: failed to enumerate device services: ATT request failed: input channel closed: io: read/write on closed pipe 2024/07/07 12:32:10 INFO retrying in 6 seconds 2024/07/07 12:32:19 INFO The command was successfully executed. command=set_charging_amps

It happened again today. This time with debug logs enabled. I'm on 89dba612b2b71a91639b3cc8dee4397979626455.
2024/07/07 15:25:09 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:25:10 INFO connectToVehicle ...
2024/07/07 15:25:10 DEBU trying connecting to vehicle attempt=1
2024/07/07 15:25:10 DEBU Connecting to vehicle (A)...
2024/07/07 15:25:10 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5]
2024/07/07 15:25:10 DEBU Create vehicle object ...
2024/07/07 15:25:10 DEBU Connecting to vehicle (B)...
2024/07/07 15:25:10 DEBU start VCSEC session...
2024/07/07 15:25:12 DEBU car successfully wakeup
2024/07/07 15:25:12 DEBU start Infotainment session...
2024/07/07 15:25:13 INFO Session started
2024/07/07 15:25:13 DEBU sending command ... command=charge_start
2024/07/07 15:25:14 WARN failed to start charge: car could not execute command: disconnected
2024/07/07 15:25:14 INFO retrying in 3 seconds
2024/07/07 15:25:18 WARN failed to start charge: car could not execute command: disconnected
2024/07/07 15:25:18 INFO retrying in 6 seconds
2024/07/07 15:25:24 ERRO The command was canceled. command=charge_start err="failed to start charge: context deadline exceeded"
2024/07/07 15:25:24 DEBU Disconnect vehicle (A)
2024/07/07 15:25:24 DEBU Close connection (A)
2024/07/07 15:25:26 INFO connectToVehicle ...
2024/07/07 15:25:26 DEBU trying connecting to vehicle attempt=1
2024/07/07 15:25:26 DEBU Connecting to vehicle (A)...
2024/07/07 15:25:26 DEBU Create vehicle object ...
2024/07/07 15:25:26 DEBU Connecting to vehicle (B)...
2024/07/07 15:25:26 DEBU start VCSEC session...
2024/07/07 15:25:27 DEBU car successfully wakeup
2024/07/07 15:25:27 DEBU start Infotainment session...
2024/07/07 15:25:28 INFO Session started
2024/07/07 15:25:28 DEBU sending command ... command=set_charging_amps
2024/07/07 15:25:29 INFO The command was successfully executed. command=set_charging_amps
2024/07/07 15:25:54 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:25:54 DEBU sending command ... command=charge_start
2024/07/07 15:25:54 DEBU Disconnect vehicle (A)
2024/07/07 15:25:54 DEBU Close connection (A)
2024/07/07 15:25:54 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:25:55 INFO connectToVehicle ...
2024/07/07 15:25:55 DEBU trying connecting to vehicle attempt=1
2024/07/07 15:25:55 DEBU Connecting to vehicle (A)...
2024/07/07 15:25:58 DEBU Create vehicle object ...
2024/07/07 15:25:58 DEBU Connecting to vehicle (B)...
2024/07/07 15:25:58 DEBU start VCSEC session...
2024/07/07 15:26:00 DEBU car successfully wakeup
2024/07/07 15:26:00 DEBU start Infotainment session...
2024/07/07 15:26:10 DEBU Disconnect vehicle (B)
2024/07/07 15:26:10 DEBU Close connection (B)
2024/07/07 15:26:10 WARN failed to perform handshake with vehicle (B): context deadline exceeded
2024/07/07 15:26:10 INFO retrying in 3 seconds
2024/07/07 15:26:13 DEBU trying connecting to vehicle attempt=2
2024/07/07 15:26:13 DEBU Connecting to vehicle (A)...
2024/07/07 15:26:19 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:26:19 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:26:28 WARN failed to connect to vehicle (A): context deadline exceeded
2024/07/07 15:26:28 INFO retrying in 6 seconds
2024/07/07 15:26:34 DEBU trying connecting to vehicle attempt=3
2024/07/07 15:26:34 DEBU Connecting to vehicle (A)...
2024/07/07 15:26:39 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:26:39 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:26:49 ERRO stop retrying after 3 attempts error="failed to connect to vehicle (A): context deadline exceeded"
2024/07/07 15:26:50 INFO connectToVehicle ...
2024/07/07 15:26:50 DEBU trying connecting to vehicle attempt=1
2024/07/07 15:26:50 DEBU Connecting to vehicle (A)...
2024/07/07 15:27:05 WARN failed to connect to vehicle (A): context deadline exceeded
2024/07/07 15:27:05 INFO retrying in 3 seconds
2024/07/07 15:27:08 DEBU trying connecting to vehicle attempt=2
2024/07/07 15:27:08 DEBU Connecting to vehicle (A)...
2024/07/07 15:27:23 WARN failed to connect to vehicle (A): context deadline exceeded
2024/07/07 15:27:23 INFO retrying in 6 seconds
2024/07/07 15:27:29 DEBU trying connecting to vehicle attempt=3
2024/07/07 15:27:29 DEBU Connecting to vehicle (A)...
2024/07/07 15:27:44 ERRO stop retrying after 3 attempts error="failed to connect to vehicle (A): context deadline exceeded"
2024/07/07 15:27:45 INFO connectToVehicle ...
2024/07/07 15:27:45 DEBU trying connecting to vehicle attempt=1
2024/07/07 15:27:45 DEBU Connecting to vehicle (A)...
2024/07/07 15:27:59 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:27:59 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3]
2024/07/07 15:28:00 WARN failed to connect to vehicle (A): context deadline exceeded
2024/07/07 15:28:00 INFO retrying in 3 seconds
2024/07/07 15:28:03 DEBU trying connecting to vehicle attempt=2
2024/07/07 15:28:03 DEBU Connecting to vehicle (A)...
2024/07/07 15:28:18 WARN failed to connect to vehicle (A): context deadline exceeded
2024/07/07 15:28:18 INFO retrying in 6 seconds
2024/07/07 15:28:19 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:28:19 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:28:24 DEBU trying connecting to vehicle attempt=3
2024/07/07 15:28:24 DEBU Connecting to vehicle (A)...
2024/07/07 15:28:34 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:28:34 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:28:39 ERRO stop retrying after 3 attempts error="failed to connect to vehicle (A): context deadline exceeded"
2024/07/07 15:28:40 INFO connectToVehicle ...
2024/07/07 15:28:40 DEBU trying connecting to vehicle attempt=1
2024/07/07 15:28:40 DEBU Connecting to vehicle (A)...
2024/07/07 15:28:54 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:28:54 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5]
2024/07/07 15:28:55 WARN failed to connect to vehicle (A): context deadline exceeded
2024/07/07 15:28:55 INFO retrying in 3 seconds
2024/07/07 15:28:58 DEBU trying connecting to vehicle attempt=2
2024/07/07 15:28:58 DEBU Connecting to vehicle (A)...
2024/07/07 15:29:04 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:29:04 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:29:13 WARN failed to connect to vehicle (A): context deadline exceeded
2024/07/07 15:29:13 INFO retrying in 6 seconds
2024/07/07 15:29:19 DEBU trying connecting to vehicle attempt=3
2024/07/07 15:29:19 DEBU Connecting to vehicle (A)...
2024/07/07 15:29:34 ERRO stop retrying after 3 attempts error="failed to connect to vehicle (A): context deadline exceeded"
2024/07/07 15:29:35 INFO connectToVehicle ...
2024/07/07 15:29:35 DEBU trying connecting to vehicle attempt=1
2024/07/07 15:29:35 DEBU Connecting to vehicle (A)...
2024/07/07 15:29:50 WARN failed to connect to vehicle (A): context deadline exceeded
2024/07/07 15:29:50 INFO retrying in 3 seconds
2024/07/07 15:29:53 DEBU trying connecting to vehicle attempt=2
2024/07/07 15:29:53 DEBU Connecting to vehicle (A)...
2024/07/07 15:30:04 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:30:04 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5]
2024/07/07 15:30:08 WARN failed to connect to vehicle (A): context deadline exceeded
2024/07/07 15:30:08 INFO retrying in 6 seconds
2024/07/07 15:30:14 DEBU trying connecting to vehicle attempt=3
2024/07/07 15:30:14 DEBU Connecting to vehicle (A)...
2024/07/07 15:30:19 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:30:19 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:30:29 ERRO stop retrying after 3 attempts error="failed to connect to vehicle (A): context deadline exceeded"
2024/07/07 15:30:31 INFO connectToVehicle ...
2024/07/07 15:30:31 DEBU trying connecting to vehicle attempt=1
2024/07/07 15:30:31 DEBU Connecting to vehicle (A)...
2024/07/07 15:30:46 WARN failed to connect to vehicle (A): context deadline exceeded
2024/07/07 15:30:46 INFO retrying in 3 seconds
2024/07/07 15:30:49 DEBU trying connecting to vehicle attempt=2
2024/07/07 15:30:49 DEBU Connecting to vehicle (A)...
2024/07/07 15:30:49 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:30:49 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:31:04 WARN failed to connect to vehicle (A): context deadline exceeded
2024/07/07 15:31:04 INFO retrying in 6 seconds
2024/07/07 15:31:04 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:31:04 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5]
2024/07/07 15:31:10 DEBU trying connecting to vehicle attempt=3
2024/07/07 15:31:10 DEBU Connecting to vehicle (A)...
2024/07/07 15:31:19 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:31:19 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:31:25 ERRO stop retrying after 3 attempts error="failed to connect to vehicle (A): context deadline exceeded"
2024/07/07 15:31:26 INFO connectToVehicle ...
2024/07/07 15:31:26 DEBU trying connecting to vehicle attempt=1
2024/07/07 15:31:26 DEBU Connecting to vehicle (A)...
2024/07/07 15:31:49 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:31:49 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5]
2024/07/07 15:33:39 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:33:39 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3]
2024/07/07 15:34:09 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:34:09 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5]
2024/07/07 15:35:59 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:35:59 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:39:09 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:39:09 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5]
2024/07/07 15:39:39 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:39:39 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3]
2024/07/07 15:39:49 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:39:49 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:40:14 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:40:14 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:40:24 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:40:24 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5]
2024/07/07 15:41:34 INFO received command command=charge_start VIN=VIN body=map[]
2024/07/07 15:41:34 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5]
2024/07/07 15:42:53 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5]
2024/07/07 15:43:54 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:44:08 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5]
2024/07/07 15:44:58 INFO received command command=charge_stop VIN=VIN body=map[]
2024/07/07 15:45:28 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5]
2024/07/07 15:45:40 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2]
2024/07/07 15:45:59 INFO received command command=charge_stop VIN=VIN body=map[]
2024/07/07 15:47:13 INFO received command command=charge_stop VIN=VIN body=map[]
2024/07/07 15:47:38 INFO received command command=charge_stop VIN=VIN body=map[]
2024/07/07 15:47:59 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:48:09 INFO received command command=charge_stop VIN=VIN body=map[]
2024/07/07 15:48:23 INFO received command command=charge_stop VIN=VIN body=map[]
2024/07/07 15:49:09 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:49:33 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3]
2024/07/07 15:50:28 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5]
2024/07/07 15:51:03 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:51:28 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4]
2024/07/07 15:52:18 INFO received command command=charge_stop VIN=VIN body=map[]
2024/07/07 15:53:28 INFO received command command=charge_stop VIN=VIN body=map[]
2024/07/07 15:53:56 INFO received command command=charge_stop VIN=VIN body=map[]

Thank you for the logs. I can see the part which is blocking. Unfortunately the blocking part is ether in the tesla command repository or in the go ble package.
But I think the teal problem here ist, that the connection can't be established after 18 attempts. Perhaps we should add something, that after 5 failed attempts no new commands are accepted and the proxy waits for a view minutes for the connection issue to be resolved.

Hm. Not sure if this is the only trigger. There were other cases where the connection was fine beforehand.

Got a new occurence. I didn't pay a lot of attention the last few days. There was one connection issue again and then it got stalled for days without recovery:
2024/07/11 11:09:17 INFO The command was successfully executed. command=set_charging_amps 2024/07/11 11:09:21 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:09:21 DEBU sending command ... command=set_charging_amps 2024/07/11 11:09:22 INFO The command was successfully executed. command=set_charging_amps 2024/07/11 11:09:31 INFO received command command=charge_stop VIN=VIN body=map[] 2024/07/11 11:09:31 DEBU sending command ... command=charge_stop 2024/07/11 11:09:32 INFO The command was successfully executed. command=charge_stop 2024/07/11 11:09:45 DEBU Connection Timeout 2024/07/11 11:09:45 DEBU Disconnect vehicle (A) 2024/07/11 11:09:45 DEBU Close connection (A) 2024/07/11 11:10:50 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:10:51 INFO connectToVehicle ... 2024/07/11 11:10:51 DEBU trying connecting to vehicle attempt=1 2024/07/11 11:10:51 DEBU Connecting to vehicle (A)... 2024/07/11 11:10:51 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3] 2024/07/11 11:11:10 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:11:11 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:14:45 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:14:45 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:16:15 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:16:15 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:16:55 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:16:55 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:17:50 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:17:50 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:18:55 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:18:56 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:19:10 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:19:10 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:19:40 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:19:40 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:21:00 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:21:00 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:27:35 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:27:35 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:30:15 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:30:15 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3] 2024/07/11 11:30:25 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:30:25 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:32:00 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:32:00 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:34:25 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:34:25 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:34:40 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:34:40 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:2] 2024/07/11 11:37:35 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:37:35 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3] 2024/07/11 11:38:00 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:38:00 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3] 2024/07/11 11:38:55 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:38:55 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3] 2024/07/11 11:39:35 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:39:35 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3] 2024/07/11 11:39:45 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:39:45 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4] 2024/07/11 11:40:20 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:40:20 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3] 2024/07/11 11:40:35 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:40:35 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:3] 2024/07/11 11:40:45 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:40:45 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4] 2024/07/11 11:41:45 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:41:45 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:5] 2024/07/11 11:42:30 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:42:30 INFO received command command=set_charging_amps VIN=VIN body=map[charging_amps:4] 2024/07/11 11:42:45 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/11 11:43:00 INFO received command command=charge_start VIN=VIN body=map[] .... 2024/07/11 18:07:34 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/12 20:48:45 INFO received command command=charge_stop VIN=VIN body=map[] 2024/07/14 09:28:42 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/14 09:49:01 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/14 10:26:11 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/14 13:14:05 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/14 14:10:05 INFO received command command=charge_stop VIN=VIN body=map[] 2024/07/15 09:31:56 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/15 10:17:05 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/15 10:32:17 INFO received command command=charge_start VIN=VIN body=map[] 2024/07/15 10:33:35 INFO received command command=charge_start VIN=VIN body=map[]
Is there a possibility to monitor a command and kill it if no success event is received in a certain time frame?

I cam back from a week-end and no command are working, even after restarting evcc and TeslaBleHttpProxy and even waking up / starting the car from the phone app.
My setup is interesting because I am migrating and I have two instances of TeslaBleHttpProxy v1.2 running, one on a Raspberry Pi4 (docker image) and one on an Intel NUC (self go compile).
To switch, I change the evcc config and restart. But I have the same problem on both machines... Actually I have another Pi4 and same problem. Also generating new key and trying to register it did work.
So I wonder is the problem is on TeslaBleHttpProxy, or could it be on the car side that sometimes just don't want to communicate at all? I tried to remove all the "Unknow key" to kind of clean, but now I have difficulty to recreate a key.
It is so sad to have seen it working for hours or days and now it fail. I'll sleep on that and try again whenever possible with https://github.com/teslamotors/vehicle-command/ to check the basics.

I tested with vehicule-command after successfully adding a key and then copying that key to ~/TeslaBleHttpProxy/key but I had no success with evcc controling the charge (here trying to stop the charge).
dglaude@dglaude-NUC5PPYB:~/evcc$ sudo journalctl -fau TeslaBleHttpProxy
jui 21 23:51:57 dglaude-NUC5PPYB systemd[1]: Started TeslaBleHttpProxy.
jui 21 23:51:57 dglaude-NUC5PPYB TeslaBleHttpProxy[434183]: 2024/07/21 23:51:57 INFO TeslaBleHttpProxy 1.2 is loading ...
jui 21 23:51:57 dglaude-NUC5PPYB TeslaBleHttpProxy[434183]: 2024/07/21 23:51:57 INFO BleControl initialized
jui 21 23:51:57 dglaude-NUC5PPYB TeslaBleHttpProxy[434183]: 2024/07/21 23:51:57 INFO TeslaBleHttpProxy is running!
jui 21 23:58:47 dglaude-NUC5PPYB TeslaBleHttpProxy[434183]: 2024/07/21 23:58:47 INFO received command=charge_stop body=map[]
jui 21 23:58:47 dglaude-NUC5PPYB TeslaBleHttpProxy[434183]: 2024/07/21 23:58:47 INFO connecting to Vehicle ...
jui 21 23:59:02 dglaude-NUC5PPYB TeslaBleHttpProxy[434183]: 2024/07/21 23:59:02 WARN failed to connect to vehicle (A): context deadline exceeded
jui 21 23:59:02 dglaude-NUC5PPYB TeslaBleHttpProxy[434183]: 2024/07/21 23:59:02 INFO retrying in 3 seconds
jui 21 23:59:07 dglaude-NUC5PPYB TeslaBleHttpProxy[434183]: 2024/07/21 23:59:07 can't accept: listner timed out
jui 21 23:59:20 dglaude-NUC5PPYB TeslaBleHttpProxy[434183]: 2024/07/21 23:59:20 WARN failed to connect to vehicle (A): context deadline exceeded
jui 21 23:59:20 dglaude-NUC5PPYB TeslaBleHttpProxy[434183]: 2024/07/21 23:59:20 INFO retrying in 6 seconds```

The interesting part is that if I try with `vehicule-command` while `TeslaBleHttpProxy` still run, I get error. I had to stop `TeslaBleHttpProxy` then at second attempt I was able to change the charge speed.

```dglaude@dglaude-NUC5PPYB:~/GIT/vehicle-command$ sudo /home/dglaude/go/bin/tesla-control -vin XP7YYYYY1YY999999 -key-file private.pem -ble charging-set-amps 6
Error: failed to find a BLE device: can't init hci: no devices available: (hci0: can't down device: device or resource busy)
dglaude@dglaude-NUC5PPYB:~/GIT/vehicle-command$ sudo systemctl stop TeslaBleHttpProxy.service
dglaude@dglaude-NUC5PPYB:~/GIT/vehicle-command$ sudo /home/dglaude/go/bin/tesla-control -vin XP7YYYYY1YY999999 -key-file private.pem -ble charging-set-amps 6
Error: ble: failed to enumerate device services: ATT request failed: input channel closed: io: read/write on closed pipe
dglaude@dglaude-NUC5PPYB:~/GIT/vehicle-command$ sudo /home/dglaude/go/bin/tesla-control -vin XP7YYYYY1YY999999 -key-file private.pem -ble charging-set-amps 6
dglaude@dglaude-NUC5PPYB:~/GIT/vehicle-command$```

Right now it mean that `vehicule-command` is working and `TeslaBleHttpProxy` is not working anymore. But the key is right and the hardware is capable...

Notice that the key created with `vehicule-command` is visible as unknown in the car UI (in French "Verrouillage" section) and can be renamed.

Some positive progress in my setup.
The whole daylight, we had to manually adjust the power level...
I was about to give a try to an MQTT alternative to this software with the hope that it would solve my problem.
But before that, I moved two Pi4 and my NUC closer to the car, I was already near, but now I am as close as possible without being outside. As a result, my two instances of TeslaBleHttpProxy one on each Pi4 are working as expected (the NUC does not work yet).
Maybe it is not related to the distance, maybe it is just that both machine have been off during the move and the new installation...
Still, it works for me (at least tonight). Either both stop working in a few hours or day... or maybe those few meter made the difference. If you have trouble, please give that a try.
I also suspect that Tesla may have included power saving change in recent software upgrade, and that could include BLE power/sensitivity or make the car harder to wake up for us.

Another occurence. After a timeout again:
Jul 28 16:20:00 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:20:00 INFO The command was successfully executed. command=charge_start Jul 28 16:20:00 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:20:00 DEBU sending command ... command=set_charging_amps Jul 28 16:20:01 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:20:01 INFO The command was successfully executed. command=set_charging_amps Jul 28 16:20:17 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:20:17 DEBU Connection Timeout Jul 28 16:20:17 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:20:17 DEBU Disconnect vehicle (A) Jul 28 16:20:17 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:20:17 DEBU Close connection (A) Jul 28 16:20:25 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:20:25 INFO received command command=set_charging_amps VIN=5YJSA7E54PF503416 body=map[charging_amps:2] Jul 28 16:20:25 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:20:25 INFO connectToVehicle ... Jul 28 16:20:25 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:20:25 DEBU trying connecting to vehicle attempt=1 Jul 28 16:20:25 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:20:25 DEBU Connecting to vehicle (A)... Jul 28 16:21:24 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:21:24 INFO received command command=charge_stop VIN=5YJSA7E54PF503416 body=map[] Jul 28 16:21:32 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:21:32 INFO received command command=set_charging_amps VIN=5YJSA7E54PF503416 body=map[charging_amps:2] Jul 28 16:22:24 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:22:24 INFO received command command=set_charging_amps VIN=5YJSA7E54PF503416 body=map[charging_amps:3] Jul 28 16:22:34 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:22:34 INFO received command command=set_charging_amps VIN=5YJSA7E54PF503416 body=map[charging_amps:4] Jul 28 16:22:59 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:22:59 INFO received command command=set_charging_amps VIN=5YJSA7E54PF503416 body=map[charging_amps:3] Jul 28 16:23:44 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:23:44 INFO received command command=set_charging_amps VIN=5YJSA7E54PF503416 body=map[charging_amps:3] Jul 28 16:24:09 DietPi TeslaBleHttpProxy[536]: 2024/07/28 16:24:09 INFO received command command=set_charging_amps VIN=5YJSA7E54PF503416 body=map[charging_amps:3] .... Jul 28 18:25:46 DietPi TeslaBleHttpProxy[536]: 2024/07/28 18:25:46 INFO received command command=set_charging_amps VIN=5YJSA7E54PF503416 body=map[charging_amps:2] Jul 28 18:26:31 DietPi TeslaBleHttpProxy[536]: 2024/07/28 18:26:31 INFO received command command=charge_stop VIN=5YJSA7E54PF503416 body=map[] Jul 28 18:27:24 DietPi TeslaBleHttpProxy[536]: 2024/07/28 18:27:24 INFO received command command=charge_stop VIN=5YJSA7E54PF503416 body=map[] Jul 28 18:29:14 DietPi TeslaBleHttpProxy[536]: 2024/07/28 18:29:14 INFO received command command=set_charging_amps VIN=5YJSA7E54PF503416 body=map[charging_amps:2] Jul 28 18:34:35 DietPi TeslaBleHttpProxy[536]: 2024/07/28 18:34:35 INFO received command command=charge_stop VIN=5YJSA7E54PF503416 body=map[] Jul 28 18:36:35 DietPi TeslaBleHttpProxy[536]: 2024/07/28 18:36:35 INFO received command command=charge_stop VIN=5YJSA7E54PF503416 body=map[] Jul 28 18:41:28 DietPi TeslaBleHttpProxy[536]: 2024/07/28 18:41:28 INFO received command command=charge_stop VIN=5YJSA7E54PF503416 body=map[]

There are now even more logs with version 1.2.2. Please use this version and report any error logs with this problem. Thank You!!

The Bug ist finally resolved with Version 1.2.4 :-)

Unfortunately it still seems to happen sometimes. :(

Sep 15 12:38:36 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:38:36 INFO sending command=set_charging_amps body=map[charging_amps:4]
Sep 15 12:38:36 DietPi TeslaBleHttpProxy[11114]: 2024-09-15T12:38:36+02:00 [debug] TX: 320208033a1212108f0e67054671d7009f643bff2618dfd79a0310073b08aec6d15756a66ee41ec4c537035207dfc8391437b7dd6a81010a430a4104ed711e034775d6dc32594edc8adb96eed0fba6e09807eec593bc449a9693d9ba476415de3edb6eb53a7cd735e98c961c3e6bdfc99afcbb54ee75bb5b9edd76782a3a0a10781854b66ccb43e863e90a29222647a4120ce2edc231fb788c4aa8bff5c618c903251cdb07002a109b5a4604be2dd78851cb9db2ba9936cf
Sep 15 12:38:37 DietPi TeslaBleHttpProxy[11114]: 2024-09-15T12:38:37+02:00 [debug] RX: 321212108f0e67054671d7009f643bff2618dfd73a02080352020a00920310073b08aec6d15756a66ee41ec4c537039a0310815aef109e4cf92a0483e53d2daf6788
Sep 15 12:38:37 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:38:37 INFO successfully executed command=set_charging_amps body=map[charging_amps:4]

Sep 15 12:38:50 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:38:50 INFO received command=set_charging_amps body=map[charging_amps:4]
Sep 15 12:38:50 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:38:50 INFO sending command=set_charging_amps body=map[charging_amps:4]
Sep 15 12:38:50 DietPi TeslaBleHttpProxy[11114]: 2024-09-15T12:38:50+02:00 [debug] TX: 320208033a1212108f0e67054671d7009f643bff2618dfd79a0310528f18485052005179132ae9dbc4c0745207f9bd44adadc0a16a81010a430a4104ed711e034775d6dc32594edc8adb96eed0fba6e09807eec593bc449a9693d9ba476415de3edb6eb53a7cd735e98c961c3e6bdfc99afcbb54ee75bb5b9edd76782a3a0a10781854b66ccb43e863e90a29222647a4120c7380b9159570e7c8c422667718ca03252adb07002a10c90e8e367d30e768b4915bb7fb0fe497
Sep 15 12:38:51 DietPi TeslaBleHttpProxy[11114]: 2024-09-15T12:38:51+02:00 [warn ] [528f18485052005179132ae9dbc4c074] Terminal transmission error: ATT request failed: input channel closed: io: read/write on closed pipe
Sep 15 12:38:51 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:38:51 DEBU disconnect vehicle (A)
Sep 15 12:38:51 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:38:51 DEBU close connection (A)
Sep 15 12:38:52 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:38:52 INFO connecting to Vehicle ...
Sep 15 12:38:52 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:38:52 DEBU trying connecting to vehicle attempt=1
Sep 15 12:38:52 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:38:52 DEBU connecting to vehicle (A)...
Sep 15 12:38:52 DietPi TeslaBleHttpProxy[11114]: 2024-09-15T12:38:52+02:00 [debug] Reusing existing BLE device
Sep 15 12:38:52 DietPi TeslaBleHttpProxy[11114]: 2024-09-15T12:38:52+02:00 [debug] Searching for BLE beacon S131821dd4fdd0f1aC...
Sep 15 12:38:52 DietPi TeslaBleHttpProxy[11114]: 2024-09-15T12:38:52+02:00 [debug] Connecting to BLE beacon b0:d2:78:0b:27:9a...
Sep 15 12:38:52 DietPi TeslaBleHttpProxy[11114]: 2024-09-15T12:38:52+02:00 [warn ] BLE connection attempt failed: ble: failed to enumerate device services: ATT request failed: input channel closed: io: read/write on closed pipe
Sep 15 12:38:52 DietPi TeslaBleHttpProxy[11114]: 2024-09-15T12:38:52+02:00 [debug] Reusing existing BLE device
Sep 15 12:38:52 DietPi TeslaBleHttpProxy[11114]: 2024-09-15T12:38:52+02:00 [debug] Searching for BLE beacon S131821dd4fdd0f1aC...
Sep 15 12:39:00 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:39:00 INFO received command=set_charging_amps body=map[charging_amps:5]
Sep 15 12:39:30 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:39:30 INFO received command=set_charging_amps body=map[charging_amps:5]
Sep 15 12:39:55 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:39:55 INFO received command=set_charging_amps body=map[charging_amps:5]
Sep 15 12:47:50 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:47:50 INFO received command=set_charging_amps body=map[charging_amps:5]
Sep 15 12:48:20 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:48:20 INFO received command=charge_stop body=map[]
Sep 15 12:51:00 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:51:00 INFO received command=charge_stop body=map[]
Sep 15 12:51:20 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:51:20 INFO received command=set_charging_amps body=map[charging_amps:3]
Sep 15 12:51:32 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:51:32 INFO received command=set_charging_amps body=map[charging_amps:4]
Sep 15 12:52:00 DietPi TeslaBleHttpProxy[11114]: 2024/09/15 12:52:00 INFO received command=set_charging_amps body=map[charging_amps:5]


Structured outputs

Feature Request
Newest gpt-4o model supports structured outputs, would be great to have it available.

Agree! Structured outputs would take so much pain away when you have to do a lot of JSON parsing.


I2C and UART driver blocks indefinitely (IDFGH-964)

Environment

Development Kit:  ESP32-Wrover-Kit
Module or chip used: ESP32-WROVER
IDF version: Master
Build System: Platform IO

Problem Description
There is a bug in the I2C and UART driver functions using the "ticks_to_wait" parameter.
In the beginning of the function the "absolute timeout time" is calculated:
portTickType ticks_end = xTaskGetTickCount() + ticks_to_wait;
Half-way the function the "remaing timeout time" is calculated using the following statement:
ticks_to_wait = ticks_end - xTaskGetTickCount();
This causes unexpected behaviour when calling the function with a low timeout. The worst case is when using zero (FreeRTOS "standard" for a quick polling without blocking).
In case of timeout 0, When a os tick event occurs between the "absolute timeout time" and the "remaining timeout" calculation (and this does happen) the xTaskGetTickCount is larger than the ticks_end value.
Causing the unsigned integer calculation to underflow and cause a timeout of<PHONE_NUMBER> os ticks instead of the expected zero.
Expected Behaviour
Function executes without blocking when using ticks_to_wait = 0
Actual Behaviour
Function blocks indefinitely
Steps to reproduce
See example below
Code to reproduce this issue
//Poll for received slave data
uint8_t rxData = 0;

while(i2c_slave_read_buffer(1, &rxData, 1, 0) > 0)
{
        printf("RX: %02X\n", rxData);
}

Temporarily workaround
Use ticks_to_wait = 1
but this causes the function to block 1 os tick (which is better than indefinitely ;))
Suggested solution
Check if the xTaskGetTickCount is lower or equal to the ticks_end. Otherwise use 0 as "remaining timeout time"

Hi @FaBjE thanks for your report. I have created a fix MR into our internal repo, it will be merged ASAP.

This issue is unresolved. Setting ticks_to_wait to 0 blocks the reading of values (it constantly returns 0) from the buffer indefinitely or until a new value as been added to the buffer. Setting ticks_to_wait to 1 will work as expected.


added form operand descriptors for replica, expose3scale. replace dep…

Current:-

After clicking on "create" button, status page show this error:

Removed deployment from statusDescriptors:

Added

Expose Via 3 Scale
Replicas

Updated Runtime to use text with field groups, urn:alm:descriptor:com.tectonic.ui:label is deprecated

example:

Thank you @akoserwal


load config from toml + other changes

Hi.
I've made a few changes to the code. Namely:

rename OBS::WebSocket to OBS::WS to avoid namespace conflict with websocket/driver ? Perhaps there is a better way to do this?
Add support for loading configuration from a config.toml file, but still allow passing cmdline arguments.
Separate the code in module OBS::WS::Protocol into individual files.
Added OBS::Connection module that holds SocketWrapper class and connect function.
start_driver method added to Client class.
run method in Client class to automatically start the driver if a block is passed.
an example connecting ruby-obs-websocket with voicemeeter
all files run through prettier

The purpose of these changes is to simplify the code from end-user perspective.
If any of these changes fit with your ideas for the code feel free to include them. If you decide not to merge I would ask kindly if you would include a way to load connection info from a configuration file, toml or otherwise.
Thank you for your time.

Thank you for being interested in contributing to this project. But your patch is quite large and contains too many different kinds of changes in one commit, which takes time for me to review. So the patch is not acceptable in its current form, but I think some of your ideas are very interesting and worth accepting.
If you are willing to revise your patch, please organize your changes into multiple commits so that each commit introduces a single feature, and submit them as separate Pull Requests for easier review. Thank you!
My thoughts on your ideas (not on your patch):

rename OBS::WebSocket to OBS::WS to avoid namespace conflict with websocket/driver ? Perhaps there is a better way to do this?

This should not be necessary. When both of the constants OBS::WebSocket from this gem and WebSocket from websocket/driver are in scope, you can distinguish them by using OBS::WebSocket and ::WebSocket, respectively.

Add support for loading configuration from a config.toml file, but still allow passing cmdline arguments.

I think this is a good enhancement for the library consumer. The configuration format is however up to the consumer; you prefer TOML, others YAML, and yet another XML. This library should not assume any one of them or depend on them.
An acceptable alternative would be to have a method that takes keyword arguments (or a hash) and set up a connection such as
def connect(uri:, password: nil)
  # setup a TCP socket and construct Client instance
end

With this method, users could use their preferred way to parse their configuration file:
connect(**JSON.load_file('config.json', symbolize_names: true))
# or
connect(**PerfectTOML.load_file('config.toml', symbolize_names: true))

Separate the code in module OBS::WS::Protocol into individual files.

Because the file protocol.rb is programmatically generated from the upstream API definition, please don't edit it (or split it) manually. Instead, you can make changes in codegen/generate-protocol to do so.
But I don't think there is a reason to split the file, as it should never be manually edited. For reference purposes, you can run rake doc to generate HTML documentation.

Added OBS::Connection module that holds SocketWrapper class and connect function.
start_driver method added to Client class.
run method in Client class to automatically start the driver if a block is passed.

+1 for the idea.
When I first designed this library, I wanted it not to depend on any specific WebSocket client implementation because there was no best one. So I intentionally omitted the connection-management feature from this library and delegated it to the library consumer.
But now I think websocket/drive is enough simple and suits common needs. And it is not easy to integrate other I/O schedulers such as EventMachine with Concurrent Ruby, on which this library heavily depends. So I'm for to add runtime dependency on websocket/driver and to introduce the connection-management feature specific for websocket/driver.
For the implementation:
I prefer OBS::WebSocket::Connection to be a Class but not a Module. It should not have any global state and be able to connect to multiple instances of OBS Studios simultaneously.
Also Client class should not touch WebSocket::Driver or TCPSocket. It makes us easier to maintain the code if connection management is contained in the Connection class.

an example connecting ruby-obs-websocket with voicemeeter

A real-world example is a nice-to-have.

all files run through prettier

Please don't. Massive code formatting makes it impossible to review the change and makes it very hard to follow the code history. Furthermore, without proper editor support in the maintainer's environment, the format is soon rolled back to its original state.

Hello. Thank you for your detailed response.
I figured there was a way to avoid the namespace conflict I just wasn't sure the correct way.
Regarding configuration, yes that is a good suggestion, a connect method that accepts keyword arguments.  That would satisfy my request without restricting the format type.
I will take a look into codegen/generate-protocol and rake doc.
Thank you for explaining why the connection management features are delegated to the user. Yes, if that can be integrated somehow that would be best imo.
Regarding prettier, understood. It was a nuisance to setup on vscode.
If I can figure out a way to implement my ideas in an acceptable way I will make some pull requests.
Again, thank you for your time.
I will close this PR now.


Error while trying to install

I get this error when i try to install how to fix?
The czech collumn at the top says Something with this key has already been added

Huh, you found a bug. Thanks for posting this.
Nevertheless you probably have an unsupported Crusader version. If that is the case you could circumvent it by installing the free Crusader HD Patch from FireFly.

That didnt work it happens every time I try to install it.

is this resolved?


Allow variable in include

I tried to use a variable in the include_absolute path, but it doesn't seem to work.
{% include_absolute {{ path }}.html %}

This is already supported in Jekyll's build-in include and include_relative functions.

+1

+1
This works fantastic for hard coding file names, but I'm dynamically including a bunch of files from an outside directory. My markup looks pretty much exactly like @mrksbnch's.

Hey sorry everyone for being late, I'll look into this issue some time this weekend :)

Fixed with https://github.com/tnhu/jekyll-include-absolute-plugin/commit/a87f625f0fd9aaeec5d3fcdbaf899f4b307a9d40. Thanks all!


sceneChange transition timing

Hi all,
I noticed that scene#switchTo occurs immediately, without waiting for even preview cubes / lower level tiles to load.
This results in black areas on page load, depending on initial view and actual cubes position. This is no longer an issue when switching to next scenes.
I have tried to reproduce this - see demo .
Wouldn't it be better to have an option for scene#switchTo  to wait for either specific tile level to finish loading or at least the preview level to load and then initiate the scene switch?
Any ideas how to fix this?
Thank you!

The switchScene implementation is already very subtle and I would prefer not to bake this additional logic into it. But I could be persuaded to add e.g. a Scene#isPreviewComplete method, which client code can then call to implement the switching logic as they desire.

I am actually doing something similar in my application, but seems to be unreliable and trying to figure out why. This is an excerpt of what I have in my textureLoadHandler attached to textureStore, listening for textureLoad:
var tileList = [];
layer.visibleTiles(tileList);
if(tile.z == 0) {
    previewFacesLoaded++;
    if(previewFacesLoaded == 6) { // PREVIEW OF THE LAYER IS LOADED
      console.log('preview LOADED');
    }
}

not sure if this is the correct and most efficient way to do it, though

In this case, my problem is not detecting when all preview cubes are loaded (that seems to be working with the above code), but timing the layer's visibility. After I create a layer I call the layer.setEffects({opacity: 0}); , before adding the textureLoad listener. After the preview loads, I tween the layer in.
What happens instead is that the preview cubes get displayed in pieces anyway (unpleasant to watch for end users), after the preview loads they disappear and then the tween starts (with opacity 0 to 1).


Humble petition: I modified and improved linux-drm-tip-git package and has pacaur issues

Hello.
I did a hard work with assistance from some people to improve a package I need because stable Intel graphics drivers are buggy in my system. I also need to so some testing to check if the issues are gone
Here's "my" package, I asked a lot people and had a git crash course. It's far from perfect, I acknowledge
https://aur.archlinux.org/pkgbase/linux-drm-tip-git/
It fails at building in some way, but I managed to install the generated packages from pacaur cache.
=> Finished making: linux-drm-tip-git r693733.5118c7fa9c87-1 (Wed Aug 16 04:06:19 CEST 2017)
==> Cleaning up...
:: Installing linux-drm-tip-git package(s)...
:: linux-drm-tip-git package(s) failed to install.
:: ensure package version does not mismatch between .SRCINFO and PKGBUILD
:: ensure package name has a VCS suffix if this is a devel package
linux-drm-tip-git]$ ls
90-linux.hook
drm-tip
linux-drm-tip-git.preset
linux.install config.i686
linux-drm-tip-git-headers-r693256.2d0288b5b28c-1-x86_64.pkg.tar.xz
linux-drm-tip-git-r693256.2d0288b5b28c-1-x86_64.pkg.tar.xz
linux.install.pkg config.x86_64
linux-drm-tip-git-headers-r693733.5118c7fa9c87-1-x86_64.pkg.tar.xz
linux-drm-tip-git-r693733.5118c7fa9c87-1-x86_64.pkg.tar.xz
PKGBUILD
--

I understand you're busy but: What can I do to improve the package and work correctly in pacaur? I'm really sorry, but I'm unable to find someone to assist me at improve the AUR package to get full pacaur compatibility.
Thanks in advance.

Looks like the version generated is correct, but something is fishy in the name generated of the split packages:

linux-drm-tip-git (OK)
linux-drm-tip-git-headers (instead of linux-drm-tip-headers-git)

The package array is missing too. See wiki reference. Try using package_linux-drm-tip-git() and package_linux-drm-tip-headers-git() instead of using the variable generated by your _package hack at the PKGBUILD bottom.
Also, note you can find support in this official forum: AUR Issues, Discussion & PKGBUILD Requests.


Reproduction of Plenoptic Video dataset

We are trying to reproduce the results on the plenoptic video dataset, but it is only using the cpu and not the gpu.

Hi sorry I'm late to the party but I'm going to leave this comment here for anyone that's facing memory problems with complex datasets (such as the multi-view Plenoptic/DyNeRF data set),
I've also encountered it with pretty much every other dynamic NeRF. Even if you load the training data on the GPU there's not enough memory.
I suggest you modify the code to actively load the data during training, though this will significantly decrease the speed of the method (as you'll be loading the training data from storage memory rather than RAM or GPU memory).
The other option is purchasing more RAM or using a compute system such as AWS, Kaggle, etc.


Cut errant rdf:List artifact

This Pull Request is a cleanup to side effects from what is currently suspected to have come from either Issue #406 , from an unrealized effect in the release of rdflib 6.2.0, or both.  The submitter believes risk from adoption, to UCO and downstream ontologies, is zero.
Somewhere in the chain between core rdflib, pyshacl, and rdf-toolkit.jar, the normalized Turtle content sometimes picks up redundant rdf:List artifacts that vary between runs.  The anonymous list cut in this patch has been seen to waver in how much of it is left as a detached blank node, here and in other CASE examples.
The first patch in this PR removes the orphaned list.  Guidance needs to be provided that, as long as this bug in the tool stack persists, the Make-managed generated output should not have it Git-tracked.
Review steps taken:

Tracking in Jira ticket OC-266
[x] Pull request is against correct branch
[x] CI passes in (CASE/UCO) feature branch
[ ] CI passes in (CASE/UCO) current unstable branch (a5691aa)
[ ] Impact on SHACL validation reviewed for CASE-Examples
[x] Impact on SHACL validation remediated for CASE-Examples
[ ] Impact on SHACL validation reviewed for casework.github.io
[x] Impact on SHACL validation remediated for casework.github.io (N/A)

I am aware this can potentially cause some merge conflicts for incoming proposals to UCO's develop branch.  However, those conflicts will be on whether these errant, orphan rdf:List entries should exist, and to what degree, which I hope we agree justifies keeping them out of the generated results.


incorrect structure type BALANCED_LINKS

BALANCED_LINKS used while this is nonexistent type.
It is actually should be RTL_BALANCED_LINKS.
fix: BALANCED_LINKS should be replaced with RTL_BALANCED_LINKS

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d6732fb0-1298-6690-f36f-d3b737f23b19
Version Independent ID: 9514456b-f6a0-72b7-a756-3d6f5eddda15
Content: RtlInsertElementGenericTableAvl function (ntddk.h) - Windows drivers
Content Source: wdk-ddi-src/content/ntddk/nf-ntddk-rtlinsertelementgenerictableavl.md
Product: windows-hardware
Technology: windows-devices
GitHub Login: @tedhudek
Microsoft Alias: tedhudek

Hi @PisarevSergey,
Thank you for reporting this. The topic is updated.
~ Mark
#please-close


fix(system component): don't dispatch loading state for users; faster loading, prevent reloads on tab change

resolves DEV-3530

would you consider to adjust this code according to official material documentation: https://material.angular.io/components/tabs/overview#tabs-and-navigation
Also users should not be loaded when "System Administration" or "All projects" tab is opened (see screenshot). It should be loaded only when user clicks on "All Users" tab.

Funny, it was my very intention to not let the tabs route, as it is a really, really bad UX. I prefer to have things ready without any waiting time when someone is changing tabs in a ui. It was not expensive to preload the users imho, but of value. Otherwise, when the tabs are routing, it is annoying: When a user navigates to system, then there is another loading time for when the tab is changed to /users. The users list is also destroyed after changing the tab back. Every tab change will reload the projects/all the users with all the users images again and again (which needs to be fixed there of course).

Thanks @domsteinbach. Its really better now.
Its not necessary to load users when projects tab is opened. Preloading data is a guessing game, possibly this data may never be used. Therefore this technique should be used only for exceptional cases. Also user wants to have latest data before starting working with it.
Lets have it as a common way to load data for tabs.


Issues with position:fixed

Hello,
first of all thanks for this really great plugin!
I have some weird issues when applying a contextmenu to elements that have a fixed position.
I've created a demo fiddle here (including steps to reproduce the issue I have):
http://jsfiddle.net/KcZNL/17/
It appears as if the position of the fixed element (the selector) is only determined once, but not updated?
I've reproduced this issue in FF 8 and Chrome 16ish.

Fiddled a fix http://jsfiddle.net/rodneyrehm/KcZNL/18/ - and baked it right into v1.4.4 :)

yay :)
thanks for your quick support, appreciated!


feat: minimum viable run functionality

Purpose

Define dependencies
Create a script to configure the required information on Julia and GenX
Create a script to launch a GenX Run.jl script
Document the process via a README

Closes #1, closes #9.
Usage examples
See the README for installation and usage instruction.
Time to review
15-30 minutes.

I also added a template Run.jl file, and logic to populate this template file with the configured GenX repo location if a Run.jl file is not present in the GenX project folder. This should enable people to start with just data and yml files, and be able to launch GenX without touching a single Julia script.


Remove jacoco/coveralls integration

It turns out Kotlin and JaCoCo/Coveralls don't work together (yet?). The error from the build log:
[ERROR] Failed to execute goal org.eluder.coveralls:coveralls-maven-plugin:4.3.0:report (default-cli) on project parent: Build error: Line number 67 is greater than the source file core/src/main/kotlin/com/genesys/pseudoloc/ExtendedAsciiConverter.kt size -> [Help 1]

This appears to be caused by a known defect. See https://github.com/trautonen/coveralls-maven-plugin/issues/102

Fixed in https://github.com/MyPureCloud/pseudoloc/pull/7


SliverFillRemaining Widget creates overflow with TextFields

Steps to Reproduce

Run flutter create bug.
Minimal reproducable MyApp class from the template.

class MyApp extends StatelessWidget {

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Bug demo',
      home: Scaffold(
        body: CustomScrollView(
          slivers: <Widget>[
            SliverFillRemaining(
              child: Column(
                children: <Widget>[
                  TextField(),
                  Container(
                    height: 400.0,
                  ),
                ],
              ),
              hasScrollBody: false,
            )
          ],
        ),
      ),
    );
  }
}

Click the textfield (opening the keyboard) and scroll down.

Expected results:
I expect that the layout works without any overflowing
Actual results:
The layout overflows when the keyboard is open from the bottom. Adding more textfields will increase the overflow.  Removing textfields and replacing with a button that forces the keyboard open works as well.
MaterialButton(onPressed: (){
                    SystemChannels.textInput.invokeMethod('TextInput.show');
                  }, child: Text("Open keyboard"),),

Logs

[✓] Flutter (Channel beta, v1.15.17, on Mac OS X 10.15.4 19E287, locale et-EE)
    • Flutter version 1.15.17 at /Users/siim/Binaries/flutter
    • Framework revision 2294d75bfa (6 weeks ago), 2020-03-07 00:28:38 +0900
    • Engine revision 5aff311948
    • Dart version 2.8.0 (build 2.8.0-dev.12.0 9983424a3c)

[✓] Android toolchain - develop for Android devices (Android SDK version
    29.0.0-rc2)
    • Android SDK at /Users/siim/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling
      support)
    • Platform android-29, build-tools 29.0.0-rc2
    • ANDROID_HOME = /Users/siim/Library/Android/sdk
    • ANDROID_SDK_ROOT = /Users/siim/Library/Android/sdk
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.4)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.4, Build version 11E146
    • CocoaPods version 1.8.4

[✓] Android Studio (version 3.6)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 45.0.1
    • Dart plugin version 192.7761
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)

[!] VS Code (version 1.43.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    ✗ Flutter extension not installed; install from
      https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

[✓] Connected device (2 available)
    • ONEPLUS A5010             • ec1cbc19      • android-arm64 • Android 9 (API
      28)
    • Android SDK built for x86 • emulator-5554 • android-x86   • Android 10
      (API 29) (emulator)

Hi @splangi
you can write this way
import 'package:flutter/material.dart';

void main() => runApp(MaterialApp(home: MyApp()));

class MyApp extends StatefulWidget {
  @override
  _MyAppState createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  @override
  Widget build(BuildContext context) {
    return SafeArea(
      child: MaterialApp(
        title: 'Bug demo',
        home: Scaffold(
          body: CustomScrollView(
            slivers: <Widget>[
              SliverList(
                delegate: SliverChildListDelegate([
                  TextField(),
                ]),
              ),
              SliverFillRemaining(
                child: Container(
                  height: 400.0,
                ),
                hasScrollBody: false,
              )
            ],
          ),
        ),
      ),
    );
  }
}

is it what you want to achieve?

@VladyslavBondarenko Unfortunately this is not what I want to achieve. I have a working workaround for the issue already (I wrap the textfields inside fixed height containers, which resolves the issue), but it's a hack and SliverFillRemaining(hasScrollBody: false) should support any view as it's child, including textfields.

I can't reproduce it with stable v1.12.13+hotfix.9, but can with dev 1.18.0-dev.5.0 and beta 1.17.0

/cc @Piinks This SliverFillRemaining issue may interest you.

Hey @splangi I have not been able to reproduce this. @VladyslavBondarenko also said above it hasn't been reproduced yet. Can you provide an image or further explanation of the bug you are experiencing? Thanks!

@Piinks
I mean this code sample is working fine with current stable, but when using current beta or dev channel, I can see the overflow.
(In the code sample I changed height to 600.0, because 400 px fits between the TextField and keyboard for the screen size of my emulator/simulator).
Left one - stable v1.12.13+hotfix.9, right one - dev v1.18.0-6.0.pre
(I used iOS and Android to show, but the case doesn't depend on the platform)

@Piinks
On the recording it's visible that the issue is related not to the keyboard, but to the TextField.
Left device - stable channel, no overflow with TextField.
Right device - dev channel, overflow with TextField, but not with another widget.

Ah! Thank you for clarifying! I will check this out again today.

Quick update, this does appear to be an issue with TextField. SliverFillRemaining checks the intrinsic height before laying out its children. During that check in SFR, the TextField reports 43 pixels for intrinsic height, but then reports 48 pixels as being allocated in the RenderFlex while laying out. Resulting in the 5 pixel overlap.

May be related to this change: https://github.com/flutter/flutter/pull/42449
Potentially related issue: https://github.com/flutter/flutter/issues/46160
I did find another workaround where wrapping the Container in an Expanded widget will prevent the overflow error from occurring.
I'm going to see about fixing the intrinsic sizing information reported by TextField. :)