#ble on esphome statically vs ble proxy

1 messages · Page 1 of 1 (latest)

dusk lintel
#

I'm comparing humidity values of the same xiaomi sensor via two different integrations - one is statically defining the sensor on an esphome, the other is using the same esphome as a ble proxy. The graphs of the ble proxied data are very interesting, they stair step up in .1 % increments until they are .9, then fall back down to the starting .0 value. This repeats consistently every 50minutes. Is turning on debugs for the esphome integration the best palce to start? (this happens with multiple xiaomi sensors and multiple esphome devices) I know I'll have to figure out how to read the ble advertisements but before I go down that path I want ot make sure its at least in the right direction.

dusk lintel
#

hmm i wonder if its a value precision thing. but i would expect the ble proxy value to get rounded up when it goes above .5

#

but for sure, the static defined esphome humidity version is integers only in its precision. but i think the ble proxy version still has something odd going on since its not rounding up.

slim umbra
#

I vaguely recall that ble monitor (from which the parser is forked) had some special casing in the entity to handle a stair case pattern. I don’t think it was ever implemented in the xiaomi_ble integration

dusk lintel
#

It's really odd. Like a loop or something that keeps adding to the value. I didn't think it's coming from the sensor (stock fw) since esphome doesn't do a similar thing

#

Looking through the ble_monitor code see if I can find something like that

#

Looks like it does an int on it

#

Nice memory! Thanks for replying.

#

Changing precision in ha would probably result in a blockier square wave effect since ît will round.

dusk lintel
#

adding a simple model check and then int() on the sensor publish is working well enough. the esphome logic does some firmware version checking but I didnt see that info readily available in the praser.py, i may try a PR and see if gets accepted