Closed bifurcated closed 2 years ago
sensorpush documentation sensorpush source (message by IssueLinks)
Hey there @bdraco, mind taking a look at this issue as it has been labeled with an integration (sensorpush
) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
I should also mention that I've power cycled the SensorPush sensor, moved it closer to my Bluetooth modules, and reloaded the integration from the Integrations dashboard with no effect.
Both inkbird and sensorpush rely on the insertion order of the mfr data on linux because both of these vendors abuse the mfr data fields.
On linux it probably fails once the same mfr id gets reused.
It probably works fine on macos because bleak only has this problem with bluez
We likely need a better way to detect new data on linux with these devices
I'm not sure we can fix this since bleak doesn't give us access to the underlying packets.
We will need all the Bluetooth debug log entries for the device from before and after the data goes wonky to see if we can come up with a fix
Unfortunately, I don't have logs from before the data went wonky. I could stand up another HA instance and try to replicate the problem with existing sensors.
If you reboot the host it should normalize for a few hours before it gets into a bad state again. If you collect from startup you should have enough within a day
OK, I'll give that a shot.
Here's a log from last night to this morning, where both SensorPush and InkBird were working and at the end only SensorPush is working. Govee works throughout, best I can tell.
I included the Govee sensor log data in case it was useful, but grepped out a bunch of obvious noise from other random bluetooth devices in the air, erring on the side of inclusion.
Based on the sensor graph, the first InkBird stopped recording around 1:24:31 and began behaving again briefly between 2:38:06 and 2:49:32. The other InkBird began glitching around 2:09:07.
Thanks. I'll try to come up with a way to strip out the garbage data for sensorpush first. If that works out we can apply it to Inkbird as well
I'm updated to 2022.8.5 and things appear to be working well thus far after 12+ hours. Thanks for the quick fix! I'll update if the problem isn't ultimately resolved.
The problem
I have a SensorPush HTP.xw that, prior to updating to either 2022.8.2 or 2022.8.3 (not sure which), was updating values in HA on a frequent basis and working just fine.
Without changing the location of that sensor (and thus introducing possible connectivity issues), it began to update very infrequently, to the point where the actual temperature/humidity/pressure readings were substantially different from what HA was reporting. I confirmed that the SensorPush app was reading correctly, and was accurate.
I enabled debug for bluetooth. Updates appear to be sent to HA, but not recorded. In an 8 hour period today, HA has received 477 updates from the sensor, but 477 data points are not logged in the sensor entity.
Here's summary proof of the updates being received by HA:
[core-ssh config]$ grep SensorPush home-assistant.log | grep advertisement_data I wc -l 477 [core-ssh config]$
I've attached a screen cap of the sensor graph, as I wasn't sure how else to show that the updates weren't recorded.
My 2 Inkbird IBS-TH2 sensors are exhibiting similar behavior, with 1081 updates sent in a similar period, and few apparent recorded updates.
In the event that it is useful information, my Govee BLE sensors, of which I have > 10, are working perfectly.
I'd be happy to capture more debug information if you can tell me what you would like to see.
What version of Home Assistant Core has the issue?
2022.8.2+
What was the last working version of Home Assistant Core?
2022.8.1
What type of installation are you running?
Home Assistant OS
Integration causing the issue
SensorPush
Link to integration documentation on our website
https://www.home-assistant.io/integrations/sensorpush
Diagnostics information
No diagnostics file available, but here's a screenshot of the sensor graph.
.
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Additional information
No response