Ecovacs Vacuum Cleaners Binding

It looks like the Java country code for the UK is ‘GB’, while the server is named ‘uk’. Nothing you can do about it; I’ll have a look into it and let you know when I have a fix for that.

1 Like

Brilliant. Thanks for such a quick reply :slight_smile:

I just published an update, it should hopefully work fine in the UK now :wink:

Thanks @maniac103
It looks like it’s using the right server now but I’m getting a login failure.
Here is the DEBUG log

2022-02-27 12:53:31.070 [DEBUG] [s.internal.handler.EcovacsApiHandler] - Initializing Ecovacs account 'ecovacsapi'
2022-02-27 12:53:31.355 [DEBUG] [s.internal.handler.EcovacsApiHandler] - Ecovacs API login failed
org.openhab.binding.ecovacs.internal.api.EcovacsApiException: Login failed
	at org.openhab.binding.ecovacs.internal.api.impl.EcovacsApiImpl.portalLogin(EcovacsApiImpl.java:170) ~[?:?]
	at org.openhab.binding.ecovacs.internal.api.impl.EcovacsApiImpl.loginAndGetAccessToken(EcovacsApiImpl.java:105) ~[?:?]
	at org.openhab.binding.ecovacs.internal.handler.EcovacsApiHandler.lambda$0(EcovacsApiHandler.java:122) ~[?:?]
	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:834) [?:?]

I have the Ecovacs App installed on my phone and I can connect to that with my username and password. I’ve tried changing the password and I can still connect using the App but not through OpenHAB.

Can I confirm that I should be using the same credentials as when I connect using the App?
Is there anything I can change here that will help diagnose the issue? If you have the API call to log in, I can try it here in Postman - if that helps?

Please try again with today’s update. From the source code of sucks it looks like the API wants the country code in upper case letters, while in my last changes I used ‘uk’ (lower case). For all other countries it worked ‘by accident’ because the Java API outputs country codes in upper case.

Yes, that’s definitely the case.

Hi @maniac103 - definitely making progress! The bridge is connecting successfully now. I see this in the logs :

2022-03-01 07:41:32.087 [DEBUG] [s.internal.handler.EcovacsApiHandler] - Initializing Ecovacs account 'ecovacsapi'
2022-03-01 07:41:57.654 [DEBUG] [s.internal.handler.EcovacsApiHandler] - Ecovacs API initialized
2022-03-01 07:41:57.655 [DEBUG] [covery.EcovacsDeviceDiscoveryService] - Starting Ecovacs discovery scan
2022-03-01 07:41:58.018 [DEBUG] [covery.EcovacsDeviceDiscoveryService] - Ecovacs discovery found 1 devices

When I add the new device though (adding it from the Inbox in the UI), I see this :

2022-03-01 07:45:06.115 [DEBUG] [nternal.handler.EcovacsVacuumHandler] - E0001099017609490009: Initializing handler
2022-03-01 07:45:06.181 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001099017609490009: Connecting to XMPP
2022-03-01 07:45:11.872 [DEBUG] [nternal.handler.EcovacsVacuumHandler] - E0001099017609490009: Failed communicating to device, reconnecting
org.openhab.binding.ecovacs.internal.api.EcovacsApiException: org.jivesoftware.smack.SmackException: No supported and enabled SASL Mechanism provided by server. Server announced mechanisms: [PLAIN]. Registered SASL mechanisms with Smack: [SASL Mech: SCRAM-SHA-1-PLUS, Prio: 100, SASL Mech: SCRAM-SHA-1, Prio: 110, SASL Mech: X-OAUTH2, Prio: 410, SASL Mech: ANONYMOUS, Prio: 500]. Enabled SASL mechanisms for this connection: null. Blacklisted SASL mechanisms: [SCRAM-SHA-1-PLUS].
	at org.openhab.binding.ecovacs.internal.api.impl.EcovacsXmppDevice.connect(EcovacsXmppDevice.java:231) ~[?:?]
	at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.lambda$5(EcovacsVacuumHandler.java:480) ~[?:?]
	at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.doWithDevice(EcovacsVacuumHandler.java:671) ~[?:?]
	at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.connectToDevice(EcovacsVacuumHandler.java:479) ~[?:?]
	at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.lambda$0(EcovacsVacuumHandler.java:200) ~[?:?]
	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:834) [?:?]
Caused by: org.jivesoftware.smack.SmackException: No supported and enabled SASL Mechanism provided by server. Server announced mechanisms: [PLAIN]. Registered SASL mechanisms with Smack: [SASL Mech: SCRAM-SHA-1-PLUS, Prio: 100, SASL Mech: SCRAM-SHA-1, Prio: 110, SASL Mech: X-OAUTH2, Prio: 410, SASL Mech: ANONYMOUS, Prio: 500]. Enabled SASL mechanisms for this connection: null. Blacklisted SASL mechanisms: [SCRAM-SHA-1-PLUS].
	at org.jivesoftware.smack.SASLAuthentication.selectMechanism(SASLAuthentication.java:361) ~[?:?]
	at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java:192) ~[?:?]
	at org.jivesoftware.smack.tcp.XMPPTCPConnection.loginInternal(XMPPTCPConnection.java:402) ~[?:?]
	at org.jivesoftware.smack.AbstractXMPPConnection.login(AbstractXMPPConnection.java:528) ~[?:?]
	at org.jivesoftware.smack.AbstractXMPPConnection.login(AbstractXMPPConnection.java:485) ~[?:?]
	at org.openhab.binding.ecovacs.internal.api.impl.EcovacsXmppDevice.connect(EcovacsXmppDevice.java:221) ~[?:?]

I had a quick search this morning and found this - does it help?

No. The problem is simple: you need the smack-sasl-javax bundle. What I do not understand is why OH core/Karaf doesn’t install it automatically on binding install, since it is actually listed as dependency.

Short term solution for you: go to OH console and do bundle:install https://repo1.maven.org/maven2/org/igniterealtime/smack/smack-sasl-javax/4.3.3/smack-sasl-javax-4.3.3.jar and restart OH, the XMPP login should work afterwards.

Hi @maniac103
I’ve installed that bundle and everything is working. Thank you so much for your help. :+1:
If there’s anything I can do to help determine why that dependent bundle didn’t install, please let me know.

Will do. I’ve asked core maintainers about this in my PR, because I’m far from being an OSGi expert.

1 Like

Hey,

thanks for your great work. I’m using the sucks fork via mqtt, which crashes from time to time, which is really annoying.

So i’ve installed the binding, added credentials and my Debot 950 was super easy configured.

But i’m experimenting some trouble :confused:

I’ve configured and tested everything - worked fine - changed my rule for starting cleaning at 8 am
to use the new rule but nothing happens.

After suspending and resuming the vauum thing it worked again.
So i’ve grepped through the log files and found something interesting:
At 3:11 am one other binding (DeutscheBahn Timetable) switched offline and online shortly afterwards.
Yepp the good old 24h DSL breakup - unbelievable in 2022 but here it is.
So i’ve not checked the source yet (but i’ve planned to perform a review) you wrote something
about sockets for xmpp listening.

This may be an conclusive explanation for this behaviour.

So maybe any kind of “is connection established” seems to be required.

What do you think?

  • Sönke

I’m a bit confused: You say you have a Deebot 950, but that one uses MQTT, not XMPP?
What do you mean by ‘is connection established’? The binding already listens for MQTT disconnection events and reconnects in that case. The MQTT library also should continously issue ping messages to check server connectivity. Additionally, MQTT disconnections should only affect updating some state channels, not issuing commands (as those are sent via a REST API) … this is different from the XMPP case where commands are sent over the XMPP connection.
That being said, I just tried it myself on my 950, and indeed it seems there’s sonething off there (the event listener didn’t notice water plate being attached/detached) … I’ll investigate that, but it’ll take some time as it obviously doesn’t trigger immediately.

Hey,

sorry for the confusion:

Previously i’ve used this docker-container

that connects to ecovacs api and allows control and status updates to/from openHAB via mqtt.

About the communication between the ecovacs-api and robot i didn’t care (until now).
So i don’t know yet the implementation details right now (which api is used for which action),
i’ve just observed that after reconnection no more status updates are received and commands don’t work
until devices is disabled and enabled.

‘is connection established’ - Yes that’s the question, i don’t have any idea on that, due i’ve not yet
checked the implementation details. I’ll try to find some time to check the source, and will let you know wheter i’ve got an idea.

Thanks for your support!

1 Like

Hi there,
First of all, thanks a lot for the binding.
I have installed it and the account can go online, but when I try add a deebot, it shows the following error and get disconnected:

2022-03-09 10:05:28.287 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'ecovacs:vacuum:464077d55c:E0001076117607100181' changed from INITIALIZING to ONLINE
2022-03-09 10:05:28.290 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: sending command GetBatteryInfo, retry 0
2022-03-09 10:05:28.419 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: Received command response XML <ctl id="94871143" ret="ok"><battery power="100"/></ctl>
2022-03-09 10:05:28.431 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: sending command GetChargeState, retry 0
2022-03-09 10:05:28.558 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: Received command response XML <ctl id="51893249" ret="ok"><charge type="SlotCharging"/></ctl>
2022-03-09 10:05:28.569 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: sending command GetCleanState, retry 0
2022-03-09 10:05:28.740 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: Received command response XML <ctl id="48727702" ret="ok"><clean speed="standard" st="h" t="100" a="100"/></ctl>
2022-03-09 10:05:28.750 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: sending command GetWaterBoxInfo, retry 0
2022-03-09 10:05:28.881 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: Received command response XML <ctl id="51791744" ret="ok" on="1"/>
2022-03-09 10:05:28.890 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: sending command GetError, retry 0
2022-03-09 10:05:29.020 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: Received command response XML <ctl id="96222439" ret="ok"/>
2022-03-09 10:05:29.036 [DEBUG] [nternal.handler.EcovacsVacuumHandler] - E0001076117607100181: Scheduling next poll in 0s, refresh interval 5min
2022-03-09 10:05:29.039 [DEBUG] [nternal.handler.EcovacsVacuumHandler] - E0001076117607100181: Polling data
2022-03-09 10:05:29.043 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: sending command GetCleanSum, retry 0
2022-03-09 10:05:29.210 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: Received command response XML <ctl id="63016501" ret="ok" a="000000748" l="000096420" c="000000143"/>
2022-03-09 10:05:29.223 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: sending command GetCleanLogs, retry 0
2022-03-09 10:05:29.402 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: Received command response XML <ctl id="77809718" ret="ok"><CleanSt a="007" s="1646548201" l="0495" t="a" f="a"/><CleanSt a="008" s="1646548719" l="0710" t="a" f="a"/><CleanSt a="011" s="1646706614" l="1302" t="a" f="a"/><CleanSt a="007" s="1645842605" l="0670" t="a" f="a"/><CleanSt a="003" s="1645843403" l="0411" t="a" f="a"/><CleanSt a="012" s="1646015405" l="1317" t="a" f="a"/><CleanSt a="000" s="1646016746" l="0051" t="a" f="a"/><CleanSt a="007" s="1646188198" l="0782" t="a" f="a"/><CleanSt a="010" s="1646189816" l="1578" t="a" f="a"/><CleanSt a="009" s="1646360995" l="0989" t="a" f="a"/></ctl>
2022-03-09 10:05:29.414 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: sending command GetCleanSpeed, retry 0
2022-03-09 10:05:30.922 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: sending command GetCleanSpeed, retry 1
2022-03-09 10:05:32.428 [TRACE] [.internal.api.impl.EcovacsXmppDevice] - E0001076117607100181: sending command GetCleanSpeed, retry 2
2022-03-09 10:05:33.930 [DEBUG] [nternal.handler.EcovacsVacuumHandler] - E0001076117607100181: Failed communicating to device, reconnecting
org.openhab.binding.ecovacs.internal.api.EcovacsApiException: No response for command GetCleanSpeed
	at org.openhab.binding.ecovacs.internal.api.impl.EcovacsXmppDevice.sendCommand(EcovacsXmppDevice.java:154) ~[?:?]
	at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.lambda$12(EcovacsVacuumHandler.java:555) ~[?:?]
	at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.doWithDevice(EcovacsVacuumHandler.java:702) ~[?:?]
	at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.pollData(EcovacsVacuumHandler.java:519) ~[?:?]
	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) [?:?]
2022-03-09 10:05:33.936 [DEBUG] [nternal.handler.EcovacsVacuumHandler] - E0001076117607100181: Data polling completed
2022-03-09 10:05:33.937 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'ecovacs:vacuum:464077d55c:E0001076117607100181' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)

FYI, my deebot model was OZMO 610.

Thanks.

Does the app allow clean speed control for your model?

No clean speed control .
Thanks.

@phui Should be fixed in the new release I just uploaded.

@soenke That issue should hopefully fixed now as well. If the connection still breaks up after some time, please enable trace logging log:set TRACE org.openhab.binding.ecovacs in Karaf console, restart (disable + enable) the vacuum thing, wait until it breaks again and then send me the log.

It works perfectly now !!!
Thanks a lot !!! :slight_smile:

@maniac103 Works fine since your update now! Thanks!

Just try update to 3.3 milestone 3 and the binidng not work, ecovac account can go online but my ozmo 610 can’t, fall back to 3.3 milestone 2 work again perfectly.
Thanks.

Please share the log.

Edit: I just tried with a completely fresh OH 3.3 M3 install and installed the binding from the Marketplace. It worked totally fine with my OZMO 950 (which is the only device I have), so either something’s off in your installation or something’s off regarding XMPP. Either way, I’d need to see a log file.