Stop warning about every dropped vendor request - #43
Merged
Merged
Conversation
The vendor hangs up on about one request in ten even on a good day, and the retry in forward() already covers it. Logging each one as a warning put 491 lines into a live Home Assistant log in four days, the third noisiest source there. Those are debug now. What gets a line is the verdict changing: once when the vendor is judged unreachable, once when it comes back. That is the same thing the reachability sensor reports. Two smaller things the same log turned up: A /pings entry whose value is null, which is what a repaired non-finite reading becomes, now gets skipped instead of failing float() and taking the whole body with it. Nine /pings bodies a day still fail on the live install with the error at char 46, exactly where a 1.#INF00 clock sits. The repair already handles the clock, so something else in those bodies is bad too. A non-finite value is the likeliest guess but it has not been seen, so a failed parse now quotes the first 400 bytes of the body and the next one will say. Home Assistant 2026.9 deprecated via_device in favour of via_device_id, and the old form stops working in 2027.8. The pump now names its parent by registry id when the running version knows that form, and falls back to the old one when it does not. The id comes from registering the service device during setup, since looking it up with async_get_device is deprecated in the same release.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The vendor hangs up on about one request in ten even when it's healthy, and the retry in
forward()already absorbs that. Logging each one as a warning came to 491 lines in four days on a live install. Those are debug now. The log gets one line when the vendor is judged unreachable and one when it comes back, which is the same thing the reachability sensor reports.Also in here:
/pingsentry with a null value (what a repaired non-finite reading turns into) gets skipped now, so it no longer failsfloat()and takes the whole body down. A live install still sees about nine/pingsparse failures a day, erroring at char 46, which is exactly where a1.#INF00clock sits. The clock repair already covers that, so something else in those bodies is wrong too. I don't know what yet, so a failed parse now quotes the first 400 bytes of the body.via_deviceanddevice_registry.async_get_device, and both stop working in 2027.8. The pump now names its parent withvia_device_id, using the id from registering the service device during setup, and falls back tovia_deviceon releases that don't have the new key.Tests: 261 pass. Every new test fails against the old code. Running on a live 2026.9.3 install since 2026-09-24 00:16 UTC: neither deprecation is logged any more and the pump is still linked to the service device. The vendor hasn't dropped a request since the deploy, so the new transition line hasn't had a chance to show up live yet.