Yep, that’s the problem. The cleaning pad washing/drying introduces some new states, which the binding needs to be updated for. Last update added ‘drying’, today’s update added ‘washing’ 
Please try again with the new update.
Thanks, I think we’re almost there. Now the binding stops receiving MQTT messages after some time and I haven’t found an exception or something that might cause this. This MQTT message seems to be the last one that I always get, after which I receive no further MQTT messages. Polling continues to work fine though:
2023-01-16 21:11:56.309 [TRACE] [internal.api.impl.EcovacsIotMqDevice] - E07515513D1FP6CH0019: Got MQTT message on topic iot/atr/onFwBuryPoint-bd_sysinfo/93192f79-3cfe-47e1-91ef-14ef1f4fc7d2/1vxt52/MlT3/j: {"header":{"pri":1,"tzm":120,"ts":"1673899914051","ver":"0.0.1","fwVer":"2.3.9","hwVer":"0.1.1","wkVer":"0.1.54"},"body":[{"signal":-41,"uptime":" 19:57:53 up 1 day, 4:15, 0 users, load average: 0.98, 1.27, 1.60, POWER_RESET","meminfo":"593072,417328","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914038"},{"signal":-41,"uptime":" 19:58:53 up 1 day, 4:16, 0 users, load average: 1.06, 1.24, 1.56, POWER_RESET","meminfo":"593424,416976","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914038"},{"signal":-40,"uptime":" 19:59:53 up 1 day, 4:17, 0 users, load average: 1.31, 1.27, 1.55, POWER_RESET","meminfo":"593044,417356","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914038"},{"signal":-41,"uptime":" 20:00:53 up 1 day, 4:18, 0 users, load average: 1.38, 1.31, 1.55, POWER_RESET","meminfo":"593144,417256","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914038"},{"signal":-43,"uptime":" 20:01:53 up 1 day, 4:19, 0 users, load average: 1.94, 1.45, 1.58, POWER_RESET","meminfo":"593260,417140","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914038"},{"signal":-43,"uptime":" 20:02:53 up 1 day, 4:20, 0 users, load average: 1.28, 1.35, 1.53, POWER_RESET","meminfo":"593748,416652","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914038"},{"signal":-42,"uptime":" 20:03:53 up 1 day, 4:21, 0 users, load average: 1.87, 1.49, 1.57, POWER_RESET","meminfo":"592888,417512","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914038"},{"signal":-42,"uptime":" 20:04:53 up 1 day, 4:22, 0 users, load average: 1.56, 1.47, 1.56, POWER_RESET","meminfo":"592864,417536","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914038"},{"signal":-42,"uptime":" 20:05:53 up 1 day, 4:23, 0 users, load average: 1.50, 1.46, 1.55, POWER_RESET","meminfo":"593000,417400","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914038"},{"signal":-42,"uptime":" 20:06:53 up 1 day, 4:24, 0 users, load average: 1.54, 1.46, 1.54, POWER_RESET","meminfo":"593256,417144","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914038"},{"signal":-42,"uptime":" 20:07:53 up 1 day, 4:25, 0 users, load average: 1.24, 1.39, 1.52, POWER_RESET","meminfo":"592908,417492","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914039"},{"signal":-42,"uptime":" 20:08:53 up 1 day, 4:26, 0 users, load average: 1.64, 1.50, 1.55, POWER_RESET","meminfo":"592760,417640","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914039"},{"signal":-42,"uptime":" 20:09:53 up 1 day, 4:27, 0 users, load average: 1.71, 1.56, 1.56, POWER_RESET","meminfo":"592968,417432","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914039"},{"signal":-42,"uptime":" 20:10:53 up 1 day, 4:28, 0 users, load average: 1.55, 1.57, 1.57, POWER_RESET","meminfo":"592432,417968","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914039"},{"signal":-42,"uptime":" 20:11:53 up 1 day, 4:29, 0 users, load average: 1.53, 1.56, 1.56, POWER_RESET","meminfo":"592952,417448","pos":"-2,548","isvalid":1,"mapid":"2054994424","ts":"1673899914039"}]}
Also, I get a message like this when rebooting and/or loading the add-on. Might it have something to do with the stuff above?
2023-01-16 21:05:58.526 [WARN ] [internal.service.FeaturesServiceImpl] - Can't load features repository mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/3.4.0-SNAPSHOT/xml/features
java.lang.RuntimeException: Error resolving artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.4.0-SNAPSHOT: [Could not find artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.4.0-SNAPSHOT] : mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/3.4.0-SNAPSHOT/xml/features
at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:121) ~[?:?]
at org.apache.karaf.features.internal.service.RepositoryImpl.<init>(RepositoryImpl.java:51) ~[?:?]
at org.apache.karaf.features.internal.service.RepositoryCacheImpl.create(RepositoryCacheImpl.java:51) ~[?:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.getFeatureCache(FeaturesServiceImpl.java:611) ~[?:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.getFeaturesById(FeaturesServiceImpl.java:645) ~[?:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.refreshFeatures(FeaturesServiceImpl.java:1236) ~[?:?]
at org.openhab.core.karaf.internal.FeatureInstaller.processConfigQueue(FeatureInstaller.java:222) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: java.io.IOException: Error resolving artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.4.0-SNAPSHOT: [Could not find artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.4.0-SNAPSHOT]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.configureIOException(AetherBasedResolver.java:803) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:774) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:555) ~[?:?]
at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:123) ~[?:?]
at java.net.URL.openStream(URL.java:1165) ~[?:?]
at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:114) ~[?:?]
... 12 more
Suppressed: shaded.org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.4.0-SNAPSHOT
at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:403) ~[?:?]
at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:215) ~[?:?]
at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:192) ~[?:?]
at shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:247) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:767) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:555) ~[?:?]
at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:123) ~[?:?]
at java.net.URL.openStream(URL.java:1165) ~[?:?]
at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:114) ~[?:?]
at org.apache.karaf.features.internal.service.RepositoryImpl.<init>(RepositoryImpl.java:51) ~[?:?]
at org.apache.karaf.features.internal.service.RepositoryCacheImpl.create(RepositoryCacheImpl.java:51) ~[?:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.getFeatureCache(FeaturesServiceImpl.java:611) ~[?:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.getFeaturesById(FeaturesServiceImpl.java:645) ~[?:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.refreshFeatures(FeaturesServiceImpl.java:1236) ~[?:?]
at org.openhab.core.karaf.internal.FeatureInstaller.processConfigQueue(FeatureInstaller.java:222) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: shaded.org.eclipse.aether.resolution.ArtifactResolutionException: Error resolving artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.4.0-SNAPSHOT
at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:413) ~[?:?]
at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:215) ~[?:?]
at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:192) ~[?:?]
at shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:247) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:767) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:555) ~[?:?]
at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:123) ~[?:?]
at java.net.URL.openStream(URL.java:1165) ~[?:?]
at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:114) ~[?:?]
... 12 more
And what does the device do at that point? If it’s sitting idle, receiving no MQTT messages might be OK/normal. In that case - what happens when triggering some action via app?
Also, can you give a log with a bit more context? What happens before that line?
Edit: Another question: If the MQTT events stop while the device is active, how long does it take until that happens? When disabling + enabling the vacuum Thing, is the time until messages stop again similar or different?
That’s ‘normal’. Reason is the binding being built against version 3.4.0-SNAPSHOT of openhab-core, but that version not being available anymore in the respective repository. Since 3.4.0-SNAPSHOT (which the binding wants) and 3.4.0 (which is installed; likewise applies to 3.3.0/3.2.0) are compatible as far as the binding is concerned, that message is not a problem in practice and the binding still should work fine.
That is good to know, thanks.
Well, its kinda sitting idle, means it is sitting in its station not doing anything except charging. The binding stopped receiving MQTT messages when battery was at 54%, the app continued to shop proper battery percentages (56% about 5 mins later), but openHAB stayed at 54%, where its at even right now. That was about 12 hours ago, so its definitely full by now, but openHAB doesn’t get updated as it seems. Although you might be right and there are no MQTT messages to be received due to the device being idle, but there should probably be a mechanism to update on battery status and stuff anyway, since one might want to trigger another cleaning run as soon as the battery is fully charged or something.
The log was rather uninteresting really, otherwise I would have posted it. It just continued to receive MQTT messages and polls all the time, with one final battery message coming in before receiving the MQTT message I posted above and going silent afterwards MQTT-wise. No exceptions, no log message out of the normal.
If it’s still charging, it’s definitely supposed to receive further MQTT messages about the charge state update.
OK, you’re right, I just re-initialized the thing and started a cleaning run. After 10 to 15 minutes, it stopped receiving MQTT messages again, although its still cleaning at this moment. I copied the entire events.log and openhab.log files to a pastebin from the moment where I reload the thing. I cannot see a problem, but maybe you can. Thanks in advance, prepare yourself for alot to read… :(. And let me know if I can help you further.
events.log: Ecovacs Log events.log - Pastebin.com
openhab.log: Ecovacs log openhab.log - Pastebin.com
It’s indeed a parsing failure of that system status MQTT message. I reproduced by copy’n’pasting it verbatim into the code and triggered an MQTT message on my device I’ll have a look into it and let you know when I found the issue.
Edit: I’ve done a new release which should have this fixed.
The release with invalid JSON messages being ignored? Yep, that did the trick. Binding is running fine so far here, thanks.
I recently got a T8 after I saw it is supported in OH with your binding, thank you for this!
Now I’m in the progress of converting my Xiaomi Vacuum rules to the T8.
Is it possible to send the vacuum to specific coordinates and just stay there, doing nothing? I had a rule for my Xiaomi where it would go to a specific spot, every saturday, to get his bin emptied.
rule "Stofzuiger legen"
when
Item StofzuigerLegen received command ON
then
actionCommand.sendCommand("app_goto_target[25863,24807]")
StofzuigerLegen.sendCommand(OFF)
end
And in the app I also see accessories usage, other components. Which has a lifespan of 30 hours and includes wiping off the dust, remove hairs, cleaning the sensors etc. Would it be possible to add this channel?
Unfortunately that doesn’t seem to be possible. One can tell the robot to e.g. ‘move left’, but not to given coordinates.
Yes, I can add that.
1 Like
Would that be possible to do from within this binding, or do I need to use sucks and setup some shell scripts for OH to call? Move 1m forward would be enough for my use case.
Great!
And another request; Would be nice to reset the accessories usage from within OH. That way we never have to use that (horrible) Ecovacs app again.
From my understanding you can’t do this with sucks either, can you? One can only say ‘move’ and ‘stop’, but not how far to move; this is only decided by the time between the commands.
That shouldn’t be a big problem to do.
1 Like
I abused the customArea in combination with the stop command to get what I want:
rule "Stofzuiger T8 legen"
when
Item StofzuigerLegen_T8 received command ON
then
DeebotOZMOT8ActionsCommand.sendCommand("customArea:-537.000000;74.000000;510.000000;0.000000")
stofzuigerLegen = createTimer(now.plusSeconds(10), [|
DeebotOZMOT8ActionsCommand.sendCommand("stop")
stofzuigerLegen = null
])
StofzuigerLegen_T8.sendCommand(OFF)
end
1 Like
Hello, are you planning to integrate the DEBOOT OMNI X1e? It doesn’t seem to be working at the moment. Thanks and Greetings
Hi,
I have OH 3.4.2 and binding installed from Marketplace.
I have a strange behaviour, trying to explain. When my Deebot T9+ finish to clean, it does not update battery and state for long time. Looking at the log at trace level, I can see the binding that do polling to API but do not request for battery and state. If I pause robot Thing (not the API) and restart it, I can see in binding’s logs, that battery and state are requested.
Is this correct behaviour?
Thanks
As I don’t have this device, I can’t add support for it by myself. If you’re able to provide logs and ready for some back-and-forth for debugging, send me a PM and we can try to add support for it.
It’s correct behavior that battery and state is only requested once. It’s supposed to update via events afterwards.
This sounds like the same issue as here, which should be fixed since January. Are you sure you’re on the latest version? You can check using bundle:list | grep ecovacs.
If you’re on the latest version, please provide a log with TRACE enabled for the ecovacs binding.
Ok I will collect a set of logs and I will Update shortly. Thanks
openhab> bundle:list | grep ecovacs
269 │ Active │ 80 │ 0 │ wrap_file__openhab_userdata_tmp_kar_org.openhab.binding.ecovacs-3.4.0-SNAPSHOT_org_lastnpe_eea_eea-all_2.2.1_eea-all-2.2.1.jar
openhab>
Damn, this worked differently last time I checked, but maybe that was in my debug environment. 
What does the ‘Updated’ line in the binding info page (Settings → Bindings → Choose Ecovacs one) say?
