No, sending clean to the command channel (state is read only) should work (and does for me on an N8). I’d need a TRACE log to see what’s wrong in your case.
I hope that helps, after triggering the rule this error occurs.
The channel still changes to “clean” but doesn’t affect the vacuum to start.
==> /var/log/openhab/openhab.log <==
2023-05-12 21:50:38.576 [INFO ] [b.core.model.script.Wallswitch rules] - Deebot starten
2023-05-12 21:50:38.641 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler@1aeabcd': java.lang.IllegalStateException: Expected a string but was BEGIN_OBJECT at line 1 column 34 path $.error
com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected a string but was BEGIN_OBJECT at line 1 column 34 path $.error
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:226) ~[bundleFile:?]
at com.google.gson.Gson.fromJson(Gson.java:963) ~[bundleFile:?]
at com.google.gson.Gson.fromJson(Gson.java:928) ~[bundleFile:?]
at com.google.gson.Gson.fromJson(Gson.java:877) ~[bundleFile:?]
at com.google.gson.Gson.fromJson(Gson.java:848) ~[bundleFile:?]
at org.openhab.binding.ecovacs.internal.api.impl.EcovacsApiImpl.handleResponse(EcovacsApiImpl.java:312) ~[?:?]
at org.openhab.binding.ecovacs.internal.api.impl.EcovacsApiImpl.sendIotCommand(EcovacsApiImpl.java:260) ~[?:?]
at org.openhab.binding.ecovacs.internal.api.impl.EcovacsIotMqDevice.sendCommand(EcovacsIotMqDevice.java:97) ~[?:?]
at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.handleCommand(EcovacsVacuumHandler.java:170) ~[?:?]
at jdk.internal.reflect.GeneratedMethodAccessor370.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy3002.handleCommand(Unknown Source) [?:?]
at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:85) [bundleFile:?]
at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
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.lang.IllegalStateException: Expected a string but was BEGIN_OBJECT at line 1 column 34 path $.error
at com.google.gson.stream.JsonReader.nextString(JsonReader.java:824) ~[bundleFile:?]
at com.google.gson.internal.bind.TypeAdapters$15.read(TypeAdapters.java:380) ~[bundleFile:?]
at com.google.gson.internal.bind.TypeAdapters$15.read(TypeAdapters.java:368) ~[bundleFile:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:131) ~[bundleFile:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:222) ~[bundleFile:?]
... 26 more
==> /var/log/openhab/events.log <==
2023-05-12 21:50:38.574 [INFO ] [openhab.event.ChannelTriggeredEvent ] - homematic:HmIP-WRC6:a2426c6bb7:000B5D8995AE2B:5#BUTTON triggered SHORT_PRESSED
2023-05-12 21:50:38.579 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'DeebotCommand' received command clean
2023-05-12 21:50:38.605 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'DeebotCommand' predicted to become clean
2023-05-12 21:50:38.612 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'DeebotCommand' changed from ON to clean
DeebotCommand.sendCommand(“clean”)
is correct right? cause I tried it without " "as well, but that didn’t work either.
It helps partially 
The response obviously is unexpected; so to see how exactly the response looks like, I need a TRACE log as mentioned (run log:set TRACE org.openhab.binding.ecovacs in the CLI console).
ok, that is weird, after setting the log, I’ve tried to reproduce it and out of nowhere it works like from a magic hand :D?
that’s very weird, the configuration is the same, nothing changed…
now it’s working fine, also if I deactivate the log again.
But I’ve discovered today a log entry coming from the ecovacs binding after a reboot.
It’s reproducible for me after every restart.
2023-05-14 12:49:27.309 [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
is there something interesting in it ? or do I need to set a log level again ?
greetings
My guess is this was a temporary glitch / failure in the cloud API. It’s a bit unfortunate since we can’t debug the error handling further now, but glad that it works now. Let.me know if you see the issue again.
That one is harmless and is due to the binding being built against a snapshot instead of the release version.
It’ll go away in 4.0 when the binding is shipped with the distribution
1 Like
The issue happened a few time since then, but I didn’t find time to look into it until now.
The two things account and the bot are ONLINE and the only message that is written regularly is [scovery.EcovacsDeviceDiscoveryService] - Ecovacs discovery found 0 devices.
When sending a command I see the line:
[TRACE] [vacs.internal.api.impl.EcovacsApiImpl] - E000<some ID>: Sending IOT command Clean with payload <ctl td="Clean"><clean act="s" deep="1" p="<some area>" speed="standard" type="SpotArea"/></ctl>
Even after a few minutes no other line is logged (except the “Ecovacs discovery found 0 devices”).
How do I trigger an auto empty? Sending the command trigger with the item as a switch doesn’t seem to do anyhting.
Item
Switch BasementDeebotAutoEmpty "Basement Deebot Auto Empty [%s]" {channel="ecovacs:vacuum:283f5c6e31:E07207894B09HDQJ0300:settings#auto-empty"}
sitemap
Switch item=BasementDeebotAutoEmpty mappings=["trigger"="Empty"]
Can you share a log of trying to initiate a trigger with the log level for org.openhab.binding.ecovacs set to TRACE?
What you could try is making the item a String one. This should make it work, albeit it’s kind of a workaround. I’ll think about a proper solution.
I tried setting as a string and nothing showed up in trace log, same thing as a switch to, it does trace out right if i send on and off.
A string item ought to work. Have you tried removing the quotes around the value?
Switch item=BasementDeebotAutoEmpty mappings=[trigger="Empty"]
Hello.
I have a problem connecting my Ecovacs Deebot Slim2 Series.
Handler EcovacsVacuumHandler tried updating the thing status although the handler was already disposed.
The Binding it self was super easy. The device was found via discovery but after Connecting i got the Error above.
I have no clue, where the problem is.
Could someone help?
It would be interesting too see the log entries before that error message. It suggests the binding crashed for some reason, but without the log for that happening it’s hard to tell why exactly.
Hi Danny,
Great work, I installed and set up the binding and it works right away. Deebot X1e OMNI.
Cheers Alexander
Hello. I would like to have support added for the DEEBOT N79. Here is what I see in my log.
2023-12-10 09:45:59.665 [INFO ] [acs.internal.api.impl.EcovacsApiImpl] - Found unsupported device DEEBOT N79 (class 126, company eco-legacy), ignoring.
I tried adding a line in a custom device list in my user data folder, but no luck.
That only works in 4.0. Did you use the distro (non marketplace) version of the binding when trying this?
Otherwise we can try to tackle N79 support, but only together: I’d build a binding jar (for 4.0 or 4.1 snapshot) and you’d install and try it and provide debug logs … and that maybe a few times. Would you be able to do that? I can’t do it by myself because I don’t own such a device.
Not sure which binding I have installed. Looks like both maybe? I would have to update to 4.0 or 4.1. I can do that and let you know and I would be willing to test.
Marketplace…especially considering…
…you seem to run 3.x still?
In any case, you don’t necessarily need to update now. Maybe running a second OH instance just for debugging would also be an option for now. Once support is finished, it’ll likely land in 4.2, at which point you’ll need to update to either 4.1 (with manually built binding) or 4.2.
Hey guys, I am using openhab 4.0.4. I cannot connect to the ecovacs server via the api. I am using my Password and Email but the thing status remains “unknown”.
Does anyone know what could be the reason for that?
What exactly do you mean by that?
Enabling debug logging for the binding (log:set DEBUG org.openhab.binding.ecovacs in Karaf console), disabling + re-enabling the bridge thing and providing the log for said enable attempt would help with figuring that out
That is what I could get from the log, kind regards.
17:07:30.650 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘ecovacs:ecovacsapi:e1fa023830’ changed from UNKNOWN to UNINITIALIZED
17:07:30.661 [DEBUG] [scovery.EcovacsDeviceDiscoveryService] - Stopping Ecovacs discovery scan
17:07:30.672 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘ecovacs:ecovacsapi:e1fa023830’ changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
17:07:40.299 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘ecovacs:ecovacsapi:e1fa023830’ changed from UNINITIALIZED (DISABLED) to INITIALIZING
17:07:40.311 [DEBUG] [cs.internal.handler.EcovacsApiHandler] - Initializing Ecovacs account ‘e1fa023830’
17:07:40.315 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘ecovacs:ecovacsapi:e1fa023830’ changed from INITIALIZING to UNKNOWN
17:07:54.159 [INFO ] [pport.EventAdminConfigurationNotifier] - Sending Event Admin notification (configuration successful) to org/ops4j/pax/logging/Configuration