I’ve been using openHAB with the MIIO binding for years with my Roborock S4Max vacuum. Recently I noticed that the items under the Last Cleaning Details are no longer getting updates:
Cleaning Start
Cleaning End
Cleaning Area
Cleaning Duration
Error
Cleaning Finished
All of these items just stay set as “NULL”. Everything else that I have items linked to seems to be fine.
I’m running openHAB 4.1.1 on openhabian on an RPI4.
Does anyone know if something change with the recently released versions of OH?
the roborock vacuums have multiple versions of last cleaning details responses.
Can you please send a debug log with a full refresh (preferably the first full refresh after binding (re)start) so I can see the exact responses your vacuum gives (and if there is some error shown)
Thanks for getting back to me on this. I’m not sure what it means for a full refresh, but I logged after starting a cleaning of a small room and let it finish and go back to the dock. I figured it should have sent the last cleaning details at the end of this. Log here:
Thanks for the log…
yes I can see the issue. Something wonky is happening with the date parsing.This will be fixable.
18:06:06.386 [DEBUG] [rnal.transport.MiIoAsyncCommunication] - Could not inform listener org.openhab.binding.miio.internal.handler.MiIoVacuumHandler@c8a451: 2024-02-05T18:05:35-05:00[America/New_York] is not in a valid format.:
java.lang.IllegalArgumentException: 2024-02-05T18:05:35-05:00[America/New_York] is not in a valid format.
@marcel_verpaalen - this is great. Thanks for the super fast fix! LMK if you need me to test out anything. I don’t have a build env set up anymore, but if you have a jar for me to drop in and test out, I’m more than happy to do that.
yes, that looks ugly. Most of the times the next version snapshots just work on the earlier version.
As the change is already merged, can you try tomorrows ‘official’ snapshot build (to exclude it was my complile that went wrong). If it is relate to 4.2 snapshot not being compatible, we can maybe try to build it on top of the 4.1 release.
@marcel_verpaalen
So this morning I pulled down the latest snapshot of the addons, extracted out the miio .jar and dropped it into /usr/share/openhab/addons. This time it worked and I immediately got new values for all of my Last Cleaning Details. So there must have been some build issue that lead to those errors before.
Anyway, thanks for the help on this and the quick fix!
I stopped the binding and captured debug log on the restart. I don’t see a big error this time. I do see a response to CLEAN_SUMMARY_GET on line 29 with a bunch of unit time stamps, not sure how these map out to the different values. Maybe there is an issue getting this parsed and mapped the Cleaning End?
Today I grabbed the latest .jar and dropped it in my /usr/share/openhab/addons dir and restarted the binding. I now get a date filled in for Last Cleaning End, but it appears that both last cleaning start and last cleaning end are both set to (about) the unix epoch
2024-02-10 12:17:14.208 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘lastEnd’ changed from NULL to 1970-01-01T00:33:44.000+0000
I’m not sure . I think that is updated after every PR. I have multiple parallel .
I’ll sure not check the coming week as I’m on holidays.
But based on the change, both the start and end date should have changed.
The issue was that I filled the start field twice, first with the start date and then overwritten it with the end date. Result… End date was never updated, start date was updated with the end date.
Suggest to pull in from the snapshot build in a few days once more. If the issue remains ill need to look but deeper. Let me know than
I wanted to pick this issue back up. I think your last change here DID work in that now my Cleaning End got set where previously it was not. The issue is that both my Cleaning Start and Cleaning End are both set to 12/31/1969 @ 7:33:04 PM. This does not change when I run a cleaning cycle as I think it is being (re)set as the same value.
This is a really interesting value BTW. As you know, these dates are set with a unit time stamp.
A Unix timestamp of “0” = January 1, 1970 12:00:00 AM
However, since I am at GMT-5 Unix timestamp of “0” = December 31, 1969 7:00:00 PM GMT-05:00
The Date I am seeing here is December 31, 1969 7:33:44 PM GMT-05:00 which INTERESTINGLY would be a Unix timestamp of “2024”
It seems likely that somehow 2024 is being passed as a Unix timestamp and being converted to 12/31/1969 @ 7:33:44 PM (in my timezone) but 2024 is likley actually the year. Is it possible the CLEAN_RECORD_GET response is somehow being converted from Unixtime 2x?
From my original pastebin:
CLEAN_RECORD_GET, result: [[1707313379,1707315083,1704,25887500,0,1,2,1,52]]
Cleaning Start should be 1707313379 and get converted to Wednesday, February 7, 2024 8:42:59 AM GMT-05:00, but it is set to December 31, 1969 7:33:44 PM GMT-05:00
Cleaning End should be 1707315083 and get converted to Wednesday, February 7, 2024 9:11:23 AM GMT-05:00, but it is set to December 31, 1969 7:33:44 PM GMT-05:00
