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.