Ecovacs Vacuum Cleaners Binding [3.2.0;4.0.0)

Hmm, looks like we need to crank up logging further. Please set logging to TRACE (same line in console, just with TRACE instead of DEBUG), repeat the disable/enable cycle and share the new log.

here it is - TRACE level logtail:

19:19:02.160 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘ecovacs:ecovacsapi:e1fa023830’ changed from UNKNOWN to UNINITIALIZED
19:19:02.175 [DEBUG] [scovery.EcovacsDeviceDiscoveryService] - Stopping Ecovacs discovery scan
19:19:02.188 [TRACE] [scovery.EcovacsDeviceDiscoveryService] - BackgroundScan: Cancelled
19:19:02.194 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘ecovacs:ecovacsapi:e1fa023830’ changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
19:19:12.299 [TRACE] [scovery.EcovacsDeviceDiscoveryService] - BackgroundScan: Scheduling to run in 60 second intervals
19:19:12.310 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘ecovacs:ecovacsapi:e1fa023830’ changed from UNINITIALIZED (DISABLED) to INITIALIZING
19:19:12.322 [DEBUG] [cs.internal.handler.EcovacsApiHandler] - Initializing Ecovacs account ‘e1fa023830’
19:19:12.328 [TRACE] [cs.internal.handler.EcovacsApiHandler] - API Login: Scheduling to run in 0 seconds
19:19:12.331 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘ecovacs:ecovacsapi:e1fa023830’ changed from INITIALIZING to UNKNOWN

And what happens afterwards? No additional log lines?
(The transition to UNKNOWN is expected, but it should transition to either ONLINE or OFFLINE afterwards, so there’s stuff running after the transition to UNKNOWN)

No additional log after unknown. The thing status remains “unknown” after that.

And remains like that permanently, say for at least a minute? (Reason for the question is that HTTP requests have a timeout of 30s set)

For hours.
I also installed the shelly binding using californium?!? I am not sure if that helps.

I double checked the code and think there must be something fishy in the state of your OH core framework, because …

… this line indicates the API login was scheduled (asynchronously, but immediately). I’d expect the execution of that login to produce another line like

XX:XX:XX.XXX [TRACE] [cs.internal.handler.EcovacsApiHandler] - API Login: Running one-shot

If that does not happen, it seems like the thing handler thread pool (which is supposed to provide a thread which then executes the API login task) is blocked. I’m not sure how/why, though. A thread dump might help - see e.g. here how to create one.


I tried to find out about possibilities of printing thread debug information. jstack wasnt available or I didnt find it. there are some possibilites in the karaf console that might help on a habian.

however, I restarted the system and now ot works without problem.

Thanks you so much for your support.


now the bridge is online but the bot is offline.
Is a deebot T20e OMNI supported by the binding?
kind regards

No, it isn’t (at this point). Please see this section of the docs. If you provide the log line, I can provide the required file contents.


i’ve got a DEEBOT T20 OMNI, which does not work properly with the latest openhab 4.1.0. All values of group “Last Clean Run” are NULL.

The log shows the following error:

2024-01-01 19:26:43.247 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: java.lang.IllegalStateException: Expected a string but was BEGIN_OBJECT at line 1 column 34 path $.error
	at$ ~[?:?]
	at ~[?:?]
	at ~[?:?]
	at ~[?:?]
	at ~[?:?]
	at org.openhab.binding.ecovacs.internal.api.impl.EcovacsApiImpl.handleResponse( ~[?:?]
	at org.openhab.binding.ecovacs.internal.api.impl.EcovacsApiImpl.sendIotCommand( ~[?:?]
	at org.openhab.binding.ecovacs.internal.api.impl.EcovacsIotMqDevice.sendCommand( ~[?:?]
	at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.lambda$15( ~[?:?]
	at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.doWithDevice( ~[?:?]
	at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.pollData( ~[?:?]
	at ~[?:?]
	at java.util.concurrent.Executors$ ~[?:?]
	at ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:?]
	at java.util.concurrent.ThreadPoolExecutor$ [?:?]
	at [?:?]
Caused by: java.lang.IllegalStateException: Expected a string but was BEGIN_OBJECT at line 1 column 34 path $.error
	at ~[?:?]
	at$ ~[?:?]
	at$ ~[?:?]
	at$1.readIntoField( ~[?:?]
	at$FieldReflectionAdapter.readField( ~[?:?]
	at$ ~[?:?]
	... 17 more

Is there a way to gather more detailed information, about whats going wrong?



The new devices apparently have a different response for the logs endpoint. This will require code changes. Can you please create an issue on GitHub, to make sure I don’t forget about it? Thanks.

No problem: [ecovacs] T20 Omni values not recognized · Issue #16187 · openhab/openhab-addons · GitHub

HI. Since a few Days the binding alternatingly changes from online to offline. Thats the error

org.openhab.binding.ecovacs.internal.api.util.DataParsingException: Empty JSON payload

Kind regards

You got a T20e, right? What exactly does 'since a few day’s mean? Did it work before?
Additionally, it would be good if you could double check with a 4.2 snapshot…I fixed quite a bit of stuff (e.g. cleaning log) for newer models there.

Yes T20e. It worked very well before, I cannot exactly say since when.

Maybe I better wait until 4.2 will be official. I had some bad experience with the snapshots…

Thank you!

The problem with that approach is that if there’s issues remaining at release time, those can’t be fixed anymore.
You don’t necessarily need to run a snapshot as your production system; running it in parallel on another PC is completely sufficient: download zip, unpack, start, install Ecovacs addon, create account thing, accept robot thing, done.
It would be good if we could continue the discussion in your T20e issue since I’ll also need to provide a new custom device desc for the snapshot there.