MIIO Binding - Roborock S4Max no longer getting Last Cleaning Details

Add-ons Bindings
1

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?

2

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)

3

Hi @marcel_verpaalen

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:

4

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.
5

@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.

6

sure. You can find the jar here
https://verpaalen.com/openhab/org.openhab.binding.miio-4.2.0-SNAPSHOT.jar

7

@marcel_verpaalen

Thanks for this!

I’m running 4.1.1 on openhabian.

I removed the current binding and then dropped .jar you linked into /usr/share/openhab/addons.

I then restarted OH and am getting some errors. Not sure if there are other changes targeted for 4.2 which make this incomparable with 4.1.1 or if there is an issue. Logs here: 2024-02-06 13:52:32.821 [ERROR] [ernal.basic.MiIoDatabaseWatchService] - bundle - Pastebin.com

8

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.

9

@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!

10

@marcel_verpaalen

Actually looks like I am not getting Cleaning End - that is staying at NULL. LMK if you need me to post log.

11

yes pls

13

@marcel_verpaalen

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?

14

Got it…

15

@marcel_verpaalen

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 ran a cleaning cycle and this did not change.

The .jar I grabbed I extracted from this .kar:
https://ci.openhab.org/job/openHAB-Distribution/lastSuccessfulBuild/artifact/distributions/openhab-addons/target/

It appears to be dated after your changes were incorporated, but is it possible this doesn’t have the latest change?

Thanks again for your work on this!

16

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

1 Like
17

Hi @marcel_verpaalen

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”

image
image777×601 46.7 KB

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]]

image
image694×536 38.9 KB

With this response

  • 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

Appreciate any help you can provide here!

18

thanks @tommycw10 indeed this needs bit more attention.

background: This isssue started when I tried to fix the clean-record responses for the newer models.
new and old robots have different responses and I tried to make a universal way ( the new models have the date in a text format, rather than in the epoc, so I convert first to a text format, than process it with the new format parser… somewhere in the conversions it goes wrong).
I expect this issue arrises when users have specific date format settings. I think I need to find a new way that does not depend on the date settings on the user device.

19

Thanks @marcel_verpaalen. I really appreciate the work you have done on this!

20

Hi @marcel_verpaalen

I have now upgraded my openHAB from v4.1.3 to v4.2.1. Since then, the times cleaning#last_clean_start_time and cleaning#last_clean_end_time no longer match.

The times are both 01.01.70 01:33:44.

If I look in cleaning#last_clean_record I see the following, which is also the explanation for this date:

{"start":"2024","begin":null,"end":"2024","duration":0,"area":0.77,"clean_time":null,"error":0,"finished":0,"complete":null,"start_type":2,"clean_type":3,"finish_reason":60,"dust_collection_status":null,"map_flag":null}

It seems that start and end are parsed as timestamp?

My modelId is roborock.vacuum.s5e.

The associated debug log looks like this:
Received response for device 0F989D8D type: CLEAN_RECORD_GET, result: [[1724174413,1724174459,46,770000,0,0,2,3,60]], fullresponse: {"result":[[1724174413,1724174459,46,770000,0,0,2,3,60]],"id":7028}

21

I have created this as a bug issue:

1 Like