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.
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.
Hi,
Sorry if this is answered but I m looking to specify room id for sportArea if I m not using standard Room id like A, B, C.
How can I set room id if I m using labels?
Thanks
Set it back to ādefaultā temporarily to see the letter, then set it back. Letters donāt change when switching to room names.
1 Like