Will do. I’ve asked core maintainers about this in my PR, because I’m far from being an OSGi expert.
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
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!
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 !!!
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.
here you go:
2022-04-10 10:08:57.569 [DEBUG] [nternal.handler.EcovacsVacuumHandler] - E0001076117607100181: 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:233) ~[bundleFile:?]
at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.lambda$11(EcovacsVacuumHandler.java:484) ~[bundleFile:?]
at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.doWithDevice(EcovacsVacuumHandler.java:680) ~[bundleFile:?]
at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.connectToDevice(EcovacsVacuumHandler.java:483) ~[bundleFile:?]
at org.openhab.binding.ecovacs.internal.api.util.SchedulerTask.run(SchedulerTask.java:82) [bundleFile:?]
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) [?:?]
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) ~[bundleFile:4.3.3]
at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java:192) ~[bundleFile:4.3.3]
at org.jivesoftware.smack.tcp.XMPPTCPConnection.loginInternal(XMPPTCPConnection.java:402) ~[bundleFile:4.3.3]
at org.jivesoftware.smack.AbstractXMPPConnection.login(AbstractXMPPConnection.java:528) ~[bundleFile:4.3.3]
at org.jivesoftware.smack.AbstractXMPPConnection.login(AbstractXMPPConnection.java:485) ~[bundleFile:4.3.3]
at org.openhab.binding.ecovacs.internal.api.impl.EcovacsXmppDevice.connect(EcovacsXmppDevice.java:221) ~[bundleFile:?]
... 10 more
2022-04-10 10:08:59.895 [DEBUG] [nternal.handler.EcovacsVacuumHandler] - E0001076117607100181: Failed communicating to device, reconnecting
org.openhab.binding.ecovacs.internal.api.EcovacsApiException: org.jivesoftware.smack.SmackException$NoResponseException: No response received within reply timeout. Timeout was 5000ms (~5s). While waiting for establishing TLS
at org.openhab.binding.ecovacs.internal.api.impl.EcovacsXmppDevice.connect(EcovacsXmppDevice.java:233) ~[bundleFile:?]
at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.lambda$11(EcovacsVacuumHandler.java:484) ~[bundleFile:?]
at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.doWithDevice(EcovacsVacuumHandler.java:680) ~[bundleFile:?]
at org.openhab.binding.ecovacs.internal.handler.EcovacsVacuumHandler.connectToDevice(EcovacsVacuumHandler.java:483) ~[bundleFile:?]
at org.openhab.binding.ecovacs.internal.api.util.SchedulerTask.run(SchedulerTask.java:82) [bundleFile:?]
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) [?:?]
Caused by: org.jivesoftware.smack.SmackException$NoResponseException: No response received within reply timeout. Timeout was 5000ms (~5s). While waiting for establishing TLS
at org.jivesoftware.smack.SmackException$NoResponseException.newWith(SmackException.java:93) ~[bundleFile:4.3.3]
at org.jivesoftware.smack.SynchronizationPoint.checkForResponse(SynchronizationPoint.java:317) ~[bundleFile:4.3.3]
at org.jivesoftware.smack.SynchronizationPoint.checkIfSuccessOrWait(SynchronizationPoint.java:160) ~[bundleFile:4.3.3]
at org.jivesoftware.smack.SynchronizationPoint.checkIfSuccessOrWaitOrThrow(SynchronizationPoint.java:131) ~[bundleFile:4.3.3]
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectInternal(XMPPTCPConnection.java:944) ~[bundleFile:4.3.3]
at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.java:417) ~[bundleFile:4.3.3]
at org.openhab.binding.ecovacs.internal.api.impl.EcovacsXmppDevice.connect(EcovacsXmppDevice.java:214) ~[bundleFile:?]
... 10 more
Thanks
Okay, that one is easy: see solution here. This is a problem with OSGi dependency management which I asked about in my PR, but I did not receive a reply for it yet.
Hey,
i’ve got some trouble with the binding when restarting my openhab(ian).
After restart the plugin is shown as installed, but the things are uninitialized and have no configuration.
This behaviour is reproducable in my installation.
After removing and installing the plugin from the marketplace it works again and the things are getting back online again.
What if’ve observed is the following error message within the openhab.log, which seems to be an problem with resolving some dependencies.
2022-04-13 20:56:05.495 [WARN ] [internal.service.FeaturesServiceImpl] - Can't load features repository mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/3.3.0-SNAPSHOT/xml/features
java.lang.RuntimeException: Error resolving artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.3.0-SNAPSHOT: [Could not find artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.3.0-SNAPSHOT] : mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/3.3.0-SNAPSHOT/xml/features
at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:121) ~[bundleFile:?]
at org.apache.karaf.features.internal.service.RepositoryImpl.<init>(RepositoryImpl.java:51) ~[bundleFile:?]
at org.apache.karaf.features.internal.service.RepositoryCacheImpl.create(RepositoryCacheImpl.java:51) ~[bundleFile:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.getFeatureCache(FeaturesServiceImpl.java:611) [bundleFile:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.ensureCacheLoaded(FeaturesServiceImpl.java:582) [bundleFile:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.listRequiredRepositories(FeaturesServiceImpl.java:514) [bundleFile:?]
at org.apache.karaf.deployer.features.FeatureDeploymentListener.bundleChanged(FeatureDeploymentListener.java:247) [bundleFile:?]
at org.apache.karaf.deployer.features.FeatureDeploymentListener.init(FeatureDeploymentListener.java:90) [bundleFile:?]
at org.apache.karaf.deployer.features.osgi.Activator$DeploymentFinishedListener.deploymentEvent(Activator.java:86) [bundleFile:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.registerListener(FeaturesServiceImpl.java:296) [bundleFile:?]
at org.apache.karaf.deployer.features.osgi.Activator.doStart(Activator.java:53) [bundleFile:?]
at org.apache.karaf.util.tracker.BaseActivator.start(BaseActivator.java:92) [bundleFile:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl$2.run(BundleContextImpl.java:814) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl$2.run(BundleContextImpl.java:1) [org.eclipse.osgi-3.16.300.jar:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:806) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:763) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1028) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:371) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.Module.doStart(Module.java:605) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.Module.start(Module.java:468) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1849) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1842) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1785) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1747) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1669) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345) [org.eclipse.osgi-3.16.300.jar:?]
Caused by: java.io.IOException: Error resolving artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.3.0-SNAPSHOT: [Could not find artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.3.0-SNAPSHOT]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.configureIOException(AetherBasedResolver.java:803) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:774) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:555) ~[?:?]
at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:123) ~[?:?]
at java.net.URL.openStream(URL.java:1140) ~[?:?]
at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:114) ~[bundleFile:?]
... 29 more
Suppressed: shaded.org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.3.0-SNAPSHOT
at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:403) ~[?:?]
at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:215) ~[?:?]
at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:192) ~[?:?]
at shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:247) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:767) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:555) ~[?:?]
at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:123) ~[?:?]
at java.net.URL.openStream(URL.java:1140) ~[?:?]
at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:114) ~[bundleFile:?]
at org.apache.karaf.features.internal.service.RepositoryImpl.<init>(RepositoryImpl.java:51) ~[bundleFile:?]
at org.apache.karaf.features.internal.service.RepositoryCacheImpl.create(RepositoryCacheImpl.java:51) ~[bundleFile:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.getFeatureCache(FeaturesServiceImpl.java:611) [bundleFile:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.ensureCacheLoaded(FeaturesServiceImpl.java:582) [bundleFile:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.listRequiredRepositories(FeaturesServiceImpl.java:514) [bundleFile:?]
at org.apache.karaf.deployer.features.FeatureDeploymentListener.bundleChanged(FeatureDeploymentListener.java:247) [bundleFile:?]
at org.apache.karaf.deployer.features.FeatureDeploymentListener.init(FeatureDeploymentListener.java:90) [bundleFile:?]
at org.apache.karaf.deployer.features.osgi.Activator$DeploymentFinishedListener.deploymentEvent(Activator.java:86) [bundleFile:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.registerListener(FeaturesServiceImpl.java:296) [bundleFile:?]
at org.apache.karaf.deployer.features.osgi.Activator.doStart(Activator.java:53) [bundleFile:?]
at org.apache.karaf.util.tracker.BaseActivator.start(BaseActivator.java:92) [bundleFile:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl$2.run(BundleContextImpl.java:814) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl$2.run(BundleContextImpl.java:1) [org.eclipse.osgi-3.16.300.jar:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:806) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:763) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1028) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:371) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.Module.doStart(Module.java:605) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.Module.start(Module.java:468) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1849) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1842) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1785) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1747) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1669) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) [org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345) [org.eclipse.osgi-3.16.300.jar:?]
Caused by: shaded.org.eclipse.aether.resolution.ArtifactResolutionException: Error resolving artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.3.0-SNAPSHOT
at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:413) ~[?:?]
at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:215) ~[?:?]
at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:192) ~[?:?]
at shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:247) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:767) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565) ~[?:?]
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:555) ~[?:?]
at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:123) ~[?:?]
at java.net.URL.openStream(URL.java:1140) ~[?:?]
at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:114) ~[bundleFile:?]
... 29 more
When i check the active bundles in openhab-console the file-bundle gets listed as active:
346 ¦ Active ¦ 80 ¦ 4.3.3 ¦ smack-resolver-javax
350 ¦ Active ¦ 80 ¦ 0 ¦ wrap_file__var_lib_openhab_tmp_kar_org.openhab.binding.ecovacs-3.3.0-SNAPSHOT_org_lastnpe_eea_eea-all_2.2.1_eea-all-2.2.1.jar
After reinstall the “real bundle” is available and active too
351 ¦ Active ¦ 80 ¦ 4.3.3 ¦ smack-java7
352 ¦ Active ¦ 80 ¦ 4.3.3 ¦ smack-resolver-javax
353 ¦ Active ¦ 80 ¦ 3.3.0.202203091202 ¦ openHAB Add-ons :: Bundles :: Ecovacs Binding
356 ¦ Active ¦ 80 ¦ 0 ¦ wrap_file__var_lib_openhab_tmp_kar_org.openhab.binding.ecovacs-3.3.0-SNAPSHOT_org_lastnpe_eea_eea-all_2.2.1_eea-all-2.2.1.jar
So due i’m not that familar with the osgi bundle handing here and this might be a problem with dependencies, does anyone else can reproduce this issue,
or is this a more general bug within the marketplace bindings? In that case i would open an issue in openhab-core.
Here are my system information
runtimeInfo:
version: 3.2.0
buildString: Release Build
locale: de-DE
systemInfo:
configFolder: /etc/openhab
userdataFolder: /var/lib/openhab
logFolder: /var/log/openhab
javaVersion: 11.0.10
javaVendor: Azul Systems, Inc.
javaVendorVersion: Zulu11.45+27-CA
osName: Linux
osVersion: 5.10.103-v7l+
osArchitecture: arm
availableProcessors: 4
freeMemory: 58791288
totalMemory: 212209664
bindings:
- ahawastecollection
- astro
- avmfritz
- denonmarantz
- deutschebahn
- ecovacs
- exec
- heos
- mqtt
- netatmo
- network
- ntp
- tankerkoenig
- tradfri
clientInfo:
device:
ios: false
android: false
androidChrome: false
desktop: true
iphone: false
ipod: false
ipad: false
edge: false
ie: false
firefox: false
macos: false
windows: true
cordova: false
phonegap: false
electron: false
nwjs: false
webView: false
webview: false
standalone: false
os: windows
pixelRatio: 1.5
prefersColorScheme: light
isSecureContext: true
locationbarVisible: true
menubarVisible: true
navigator:
cookieEnabled: true
deviceMemory: 8
hardwareConcurrency: 8
language: de-DE
languages:
- de-DE
- de
- en-US
- en
onLine: true
platform: Win32
screen:
width: 2560
height: 1440
colorDepth: 24
support:
touch: false
pointerEvents: true
observer: true
passiveListener: true
gestures: false
intersectionObserver: true
themeOptions:
dark: light
filled: true
pageTransitionAnimation: default
bars: filled
homeNavbar: default
homeBackground: default
expandableCardAnimation: default
userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/100.0.4896.75 Safari/537.36
timestamp: 2022-04-13T19:12:12.950Z
Hi, great job!
Confirming it is working perfectly with Deebot Ozmo 905 that I have.
Just a question: I see in the channels there is last-clean#last-clean-map that I don’t have when configuring the Thing. Since from the Ecovacs app I can see the map with the last cleaning (or better for the clean history), I’m wondering if it is just an option to enable.
I tried all command and they are working, like I’m able to control which room to clean using the spotArea command
No, this isn’t an option to enable, but depends on a device capability list contained in the binding. I’ve included the mapping capability now, so it should work with the new release. You’ll have to recreate the thing for the vacuum (once), though, for the missing channels to appear.
Very good. All is almost working.
For the channels last-clean#last-clean-map and last-clean#last-clean-mode I’m getting NULL and UNDEF.
I see data coming:
This is the list of MQTT topic I’m receiving:
iot/atr/BatteryInfo
iot/atr/BigDataCleanInfoReport
iot/atr/ChargeState
iot/atr/CleanedMap
iot/atr/CleanedPos
iot/atr/CleanedTrace
iot/atr/CleanReport
iot/atr/CleanReportServer
iot/atr/CleanSt
iot/atr/MapP
iot/atr/Pos
iot/atr/trace
Is there any other test I can do?
If required full log, of course I will upload
Clean logs are polled, not updated via MQTT event message. You can search for ‘cleaning logs’ in the log to find the place where the respective HTTP request is done.