Closed BerndDA closed 1 year ago
Hi,
I don't think moving the evaluation of criticalBatteryState is wrong here. The naming here is actually a bit confusing, according to the documentation, the flag holds three data points:
Bit 0 Smart Lock Battery State Critical Bit 1 Charging Flag Bit 2-7 Smart Lock Battery in %
The evualuation will publish all three if a single one has changed, that includes battery percentage. My guess is that it isn't published after 30 minutes because the battery level hasn't changed, which is the correct behavior.
You are perfectly right. This is because the value did not change. I guess what got me confused is that other subtopics of battery/* are published like configured, even if there is no change in the value (seems to be the case for voltage). I will set the time interval when calculating time series values to something that is bigger than the timeframe between 2 values. This should do it for my case :) Thanks a lot!
I should actually add checks there. The voltage comes from a a different call ("Query interval battery").
Hello, first thanks for this amazing project! I am using it for 2 months now, because Homekit integration was not reliable (too big distance between Homepod and SmartLock).
Expected Behavior
The MQTT value for battery/level should be written/updated according to the configuration value set in "Query interval lock state (seconds)"
Current Behavior
The battery/level topic gets once updated after a reboot of ESP32. Afterwards the value gets only updated (only once again), if the lock reports a critical battery level
Possible Solution
In NetworkLock.cpp (line 261) evaluate battery level independent from flag criticalBatteryState and publish the value to MQTT.
Steps to Reproduce
References
a similar observation was mede here:
162
BR Bernd