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
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.
Hi,
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.
Hi,
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.
Hey,
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:
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:397) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:1227) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:1137) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:1047) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:982) ~[?:?]
at org.openhab.binding.ecovacs.internal.api.impl.EcovacsApiImpl.handleResponse(EcovacsApiImpl.java:349) ~[?:?]
at org.openhab.binding.ecovacs.internal.api.impl.EcovacsApiImpl.sendIotCommand(EcovacsApiImpl.java:297) ~[?:?]
at org.openhab.binding.ecovacs.internal.api.impl.EcovacsIotMqDevice.sendCommand(EcovacsIotMqDevice.java:97) ~[?:?]
at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.lambda$15(EcovacsVacuumHandler.java:575) ~[?:?]
at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.doWithDevice(EcovacsVacuumHandler.java:798) ~[?:?]
at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.pollData(EcovacsVacuumHandler.java:574) ~[?:?]
at org.openhab.binding.ecovacs.internal.api.util.SchedulerTask.run(SchedulerTask.java:95) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
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:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:833) [?:?]
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:836) ~[?:?]
at com.google.gson.internal.bind.TypeAdapters$15.read(TypeAdapters.java:421) ~[?:?]
at com.google.gson.internal.bind.TypeAdapters$15.read(TypeAdapters.java:409) ~[?:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.readIntoField(ReflectiveTypeAdapterFactory.java:212) ~[?:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$FieldReflectionAdapter.readField(ReflectiveTypeAdapterFactory.java:433) ~[?:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:393) ~[?:?]
... 17 more
Is there a way to gather more detailed information, about whats going wrong?
BR
Sönke
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.