search

LordMike / MBW.BlueRiiot2MQTT

Utility to map between Blue Riiots pool API, and Home Assistant MQTT
47 stars 2 forks source link

Update interval based on last attempt, not last measurement #46

Closed ggggh closed 3 years ago

ggggh commented 3 years ago

Looking at the logs, it seems the next measurement time is calculated as a delta from the current time (for example, current time plus 1 hour 15 minutes). Shouldn't it be based on the last reported measurement time instead?
So, if the script schedules a reading at 10AM and that reading shows that the last good measurement was actually at 9AM, it should schedule the next reading at 10:15, not at 11:15. At the moment I'm nearly an hour out of synch on my readings, and I think that's the reason

LordMike commented 3 years ago

It should already be the last measurement timestamp (auto only, excluding bluetooth measurements) + the interval, which the API reports to 4320s iirc (01:12:00).

The code is here. In it, the values _lastAutoMeasurement (09:00:00 in your example) and _measurementInterval (01:12:00) should give you a next update at 10:12:00.

Could you post some logs showing this is not the case?

There is some further logic to prevent infinite loops, such as if your blue device misses a reading. In that case, the next reading would be in the past, which means "fetch now".. And continue to be that for approx. an hour..

ggggh commented 3 years ago

Ahh...I think I figured out what 's happening. It seems a TZ issue, but harmless.

It says this: [2021-04-20 18:53:45+02:00 INF] [MBW.BlueRiiot2MQTT.Service.PoolUpdater.SingleBlueRiiotPoolUpdater] New data ready for pool 'Home' at 04/20/2021 17:52:33 (interval 01:12:00). Waiting 00:58:47.7504072

The 17:52 confused me as it was in the past, so I thought it was the last measurement time; I realize now it is the next planned measurement time, but that it is just shown on a different TZ than the log entries (2 hours earlier than system time).