Repository navigation
Conversation
| :returns: Seconds to wait before calling again. | ||
| """ | ||
| await self._post_connect() | ||
| return KEEP_ALIVE_INTERVAL |
There was a problem hiding this comment.
Remove _post_connect() and use _keep_alive() instead like here.
There was a problem hiding this comment.
keep-alive task never restarts after a BLE reconnect, That'd leave the f3800 (and that 250w charger) unsubscribed after any drop, let me look into this.
|
I will probably end up doing a release next week or the week after which I will include this in, just make sure its fixed by then. |
61f13f5 to
70050d1
Compare
|
I suppose I should also point out that you might be polling for telemetry rather than subscribing to pushes from the device as intended. There are 4 modes of operation when it comes to this, with some devices implementing multiple. Some devices send telemetry updates unprompted, some devices need a one time message to be sent and will then send any changes without the need for any further messages (post-connect), some devices need a message sent every 10 seconds for them to keep sending updates (keep-alive), and some devices allow you to directly request a status update even if nothing is happening (poll). I suspect what you want is either a keep-alive or a post-connect but what you have here is a poll command, since you only get updates every 60 seconds and your keep-alive interval is 60 seconds. It should be possible to either send one post-connect to get updated when anything changes or a periodic keep-alive every 10 seconds and get updated when anything changes. A poll looks like this. A keep-alive looks like this. A post-connect looks like this. Its also possible that none of this is needed and the reason you were not seeing any updates was because your device is idle (they only send data when something changes or you request it). |
| # Start a keep-alive task if its not running already | ||
| if self._keep_alive_task is None: | ||
| # (The task ends by itself when the connection drops, so restart it on | ||
| # every successful (re)connection, not just the first.) |
There was a problem hiding this comment.
Good catch, I never noticed this happened.
Good point, I looked at the timing. After 4040 I get a full snapshot within ~1-4s, but on a unit under load I also get unsolicited c402 updates between re-sends. So it does look like a subscribe rather than just a poll, and an idle unit only answers the subscribe. I'm not sure yet whether the subscription expires. I was having some weird issues before. I'll run a single post-connect subscribe for a while with the unit under load and report back. If changes keep coming, I'll switch this back to post-connect only. |
The keep-alive task was cancelled on disconnect but never reset to None, so after an automatic reconnect it was never started again and devices relying on a keep-alive stopped receiving telemetry. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
jfarre20
changed the title
70050d1 to
37c40bc
Compare
|
a single post-connect subscribe works fine, so I dropped that part and this PR is now just the reconnect fix |
This branch has not been deployed
2 participants
The keep-alive task is cancelled on disconnect but never reset to
None, so after an automatic reconnect it never started again. Devices that rely on a keep-alive (e.g. the Prime 250W charger) would then stop getting telemetry. It's now reset on disconnect, and a finished task is also restarted on connect.The F3800 keep-alive originally in this PR has been dropped. Tested a single post-connect subscribe (#82) for 35+ min and every change was pushed within ~1 s; the silence I saw was just the units being idle.
Tests pass (421).
🤖 Generated with Claude Code