Shelly Binding

markus7017 · December 21, 2019, 3:42pm

it’s a bug, gets fixed with next build

channel was removed on the device level, check on those on meter or sensor level (see README)

Power meter was added for the Plug (same as for the Plug-S)

README gets updated

and German translation is coming

anything else?

markus7017 · December 21, 2019, 3:47pm

With regards to timeout errors: This is still a miracle.

Of course you need to have a stable WiFi connection, otherwise API calls could get lost. Check device#wifiSignal shows at least 1, better 2; in addition check the log for WEAK_SIGNAL messages
@igi and were able to reproduce some of that and reported to Shelly, at least unexpected reboots caused by http events got better
AFAIKI’m not aware of any problems in the binding with relates to this, but who knows

I’ll add a channel to the device group, which counts those timeouts (for the snapshot release only). Maybe that helps to narrow the problem to specific devices, device types etc.

Anyways you could run a ping endless test and see if there a packet losses.

StefanH · December 22, 2019, 10:04am

Hi all,

stupid question, why are some of my shelly1 devices shown as

shelly:shellydevice:xxxxxx

vs

shelly:shelly1:xxxxxx

?

I assume it has something to do with shelly admin credentials that had not been set when I added the thing.

best regards
Stefan

markus7017 · December 22, 2019, 11:15am

“shellydevice” is the thing type for a password protected Shelly Device. Once the password is set the Channel definition will be switched to the correct thing type. However, this does not change the thing type, which was originally set by the discovery.

The problem: I can’t query the device type unless set password is set. The API is only accessible with the correct credentials. From my point of view this is a mis-design in the API, but it is what it is.

So you need to use shellydevice:xxx for all password protected devices and shelly1… for those, which are not protected. Work around: Run the discovery without userid/password, add the thing, edit to set the credentials in the thing configuration and then re-enable the userid/password on the device. In this case all thing types in the JSON DB can be derived from the device type.

markus7017 · December 22, 2019, 11:16am

The first part of the German translation is available: https://github.com/markus7017/openhab2-addons/blob/shelly-25final-2/bundles/org.openhab.binding.shelly/src/main/resources/ESH-INF/i18n/shelly_de.properties

This covers channel/group labels and descriptions.

Missing part are the status messages (mostly those for COMMUNICATION_ERROR)

Let me know anyone wants to contribute another language. However, my language skills are limited to German and English.

markus7017 · December 22, 2019, 5:29pm

The 2.5 release version of the binding does no longer include the Californium libs. Those libraries are required to implement the CoIoT / Coap protocol. Those need to be installed on pre-2.5 final installations. openHAB 2.4 is still supported (at the moment), but 2.4 and 2.5 pre-releases require the installation of Gson 2.8.5 and the Californium libs.

At the moment I have 3 build locations

The official openHAB 2.5 install package providing the released version when installing with PaperUI
The official 2.5 SNAPSHOT build. Please be aware of limited stability.
My private 2.5 DEV build. This is the latest build, could be instable. Once initial testing has been done I checkin to the SNAPSHOT repo.

I’m waiting on the information how the official path going forward will be. At the moment it looks like having

one repo/branch for openHAB 3.0 and
one branch for 2.5 updates (backports from 3.0)

This will allow to provide fixes and enhancements for the time given until openHAB 3.0 becomes available (at least stable milestone builds).

I will cleanup the interims status once the path forward has been clarified.

If you want to use the version released with openHAB 2.5 final

The final release could be installed as usual using PaperUI:Addons:Bindings:Shelly
This version works fine. However, in between some bugs (e.g. LOW_BATTERY alarm for sensor devices, input channels for Dimmers) has been fixed and new features are implemented (e.g. German translation). If you want to get access to these you need to switch to the dev/snapshot build - see below:

If you want to use the SNAPSHOT/DEV build you can NOT install this using PaperUI. Make sure that the release version is not installed. You can NOT run the SNAPSHOT on top of the version you install with PaperUI.

Beta users, which want to use the latest 2.5 DEV/SNAPSHOT builds:
you need to remove the old installation. Some of the channels have been renamed etc.
To be on the safe side

delete all Shelly Things from your system
stop openHAB, wait a minute
delete the binding jar from the addons folder
run “openhab-cli clean-cache”
cleanout the JSON DB so that there are NO remaining shelly entries

DEV/SNAPSHOT users, which want to use the latest 2.5 DEV/SNAPSHOT builds:

Stop openHAB and wait a minute
Run “bundle:list | grep Gson” on the openHAB console and check if Gson 2.8.5 (or newer) is installed (sometimes version 2.7 is installed, which doesn’t solve the dependencies).
If not: Download the gson from http://central.maven.org/maven2/com/google/code/gson/gson/2.8.5/gson-2.8.5.jar
and copy the jar to the OH addons folder
Now install the Californium libs
Run “bundle:list | grep Californium” and check if the libs are already installed (e.g. when the Tradfi binding 2.5 is also installed), otherwise
Download https://repo1.maven.org/maven2/org/eclipse/californium/californium-core/2.0.0/californium-core-2.0.0.jar and copy to addons folder
Download https://repo1.maven.org/maven2/org/eclipse/californium/element-connector/2.0.0/element-connector-2.0.0.jar and copy to addons folder

Install DEV/SNAPSHOT build of the binding

Perform the above mentioned installation steps.
If you want to use the official SNAPSHOT release
download https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/addons/bundles/org.openhab.binding.shelly/2.5.0-SNAPSHOT/org.openhab.binding.shelly-2.5.0-SNAPSHOT.jar
OR
If you want to use the latest DEV version download https://github.com/markus7017/myfiles/blob/master/org.openhab.binding.shelly-2.5.0-SNAPSHOT.jar?raw=true
Usually the DEV version is newer than the SNAPSHOT release from the above link.
Copy the downloaded jar into openHAB’s addons folder.
Start openHAB and wait until it is fully initialized

If everything was install correct a “bundle:list” output show be similar to this:

245 │ Installed │  80 │ 2.8.5                  │ Gson
246 │ Installed │  80 │ 2.0.0                  │ Californium (Cf) Core
247 │ Installed │  80 │ 2.0.0                  │ Californium (Cf) Element Connector
248 │ Installed │  80 │ 2.5.0.201912112158     │ openHAB Add-ons :: Bundles :: Shelly Binding

Please let me know if you have problems installing the new build or this doc can be improved.
This information could also be found in READMEbeta.md

Kellermeister · December 25, 2019, 10:36am

It is possible to control the blind position of venetian blinds with shelly 2.5?

markus7017 · December 25, 2019, 11:06am

If have no blinds, but from my understanding it should after you performed a calibration. This sets the min/max position and then you could set a certain percentage (using the control channel)

markus7017 · December 25, 2019, 12:05pm

Did you verified the latest build? This should be fixed.

https://github.com/markus7017/myfiles/blob/master/org.openhab.binding.shelly-2.5.0-SNAPSHOT.jar?raw=true

The following changes are made

German translation of groups/channels/UI messages (binding config doesn’t work yet)
Fix for LOW_BATTERY alarm
Fix input channels for Dimmer + RGBW2
Fix timing issue for protected devices changing thing type after setting the credentials
Change: Full meter for Plug (like Plug-S)
New option brightnessAutoOn in thing config to suppress Auto-ON for lights (e.g. dimmer)
Enhanced channel cache to keep switch state and value of the brightness channel as separate states to avoid log entries like OFF (state) followed by 0 (value)
Update lastUpdate channel only if some other meter/sensor data has changed → reduce logging
README updated, READMEbeta included in DEV repo (myfiles)

Please note: This is a DEV release

alexxio · December 25, 2019, 3:13pm

Hi,
As I’m Italian I have to wait to get up from the table these days
I’ll try it ASAP.

Thanks for you work and merry Christmas!

markus7017 · December 25, 2019, 3:26pm

Merry Xmas all of you

dilisi · December 25, 2019, 4:49pm

hi,

I have successfully used the shelly binding with openhab 2.5 (Shelly HT and Shelly4pro). But I have a small problem with the Shelly HT. After I restart openhab, the Shelly HT things remain in the “UNKNOWN” state. Even if the sensor sends an update, the state of the things remains “UNKNOWN” and the sensor values are not displayed/updated. The only way I can fix the problem is to manually activate the Shelly HT and manually “reactivate” the Shelly Things.
Does anyone know if there is another way to fix the problem?

markus7017 · December 25, 2019, 5:39pm

This is not normal. The thing should stay Initializing until the next event is processed and then switch to ONLINE

which build are you using?
what’s shown in the logfile?

dilisi · December 25, 2019, 6:13pm

binding-shelly - 2.5.0
openhab.log shows the following, although I do not know if they are relevant. Otherwise, events.log and openhab.log show nothing regarding the Shelly HTs:

2019-12-25 17:35:17.389 [WARN ] [org.eclipse.jetty.server.HttpChannel] - /rest/events
javax.servlet.ServletException: javax.servlet.ServletException: A MultiException has 1 exceptions. They are:

java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_2,3,19320965) has been shut down

 at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:88) ~[bundleFile:?]
 at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.20.v20190813]
 at org.eclipse.jetty.server.Server.handle(Server.java:494) ~[bundleFile:9.4.20.v20190813]
 at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:374) ~[bundleFile:9.4.20.v20190813]
 at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:268) ~[bundleFile:9.4.20.v20190813]
 at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) ~[bundleFile:9.4.20.v20190813]
 at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) ~[bundleFile:9.4.20.v20190813]
 at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) ~[bundleFile:9.4.20.v20190813]
 at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) ~[bundleFile:9.4.20.v20190813]
 at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) ~[bundleFile:9.4.20.v20190813]
 at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) ~[bundleFile:9.4.20.v20190813]
 at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:135) ~[bundleFile:9.4.20.v20190813]
 at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) [bundleFile:9.4.20.v20190813]
 at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) [bundleFile:9.4.20.v20190813]
 at java.lang.Thread.run(Thread.java:748) [?:1.8.0_152]

Caused by: javax.servlet.ServletException: A MultiException has 1 exceptions. They are:

dilisi · December 25, 2019, 6:27pm

For testing I have created a new Shelly HT Thing. The status goes instantly to “UNKNOWN”. I can’t see anything in the log. When removing it there is the following message:

2019-12-25 19:20:49.809 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:d73573b0’ changed from UNKNOWN to REMOVING
2019-12-25 19:20:49.818 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:d73573b0’ changed from REMOVING to REMOVED
2019-12-25 19:20:49.859 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:d73573b0’ changed from REMOVED to UNINITIALIZED
2019-12-25 19:20:49.899 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:d73573b0’ changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)

markus7017 · December 25, 2019, 7:06pm

try this build:
https://github.com/markus7017/myfiles/blob/master/org.openhab.binding.shelly-2.5.0-SNAPSHOT.jar?raw=true

dilisi · December 25, 2019, 8:46pm

It shows the same behaviour. But I found log entries now (they appeared earlier too). Interesting is that the status of Shelly4Pro also shows “UNKNOWN” first, but then goes to the status “ONLINE”:

2019-12-25 21:36:31.278 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:97247717’ changed from UNINITIALIZED to INITIALIZING
2019-12-25 21:36:31.312 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:97247717’ changed from INITIALIZING to UNKNOWN
2019-12-25 21:36:31.321 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:b4fa05dd’ changed from UNINITIALIZED to INITIALIZING
2019-12-25 21:36:31.338 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:b4fa05dd’ changed from INITIALIZING to UNKNOWN
2019-12-25 21:36:31.346 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:8f096f99’ changed from UNINITIALIZED to INITIALIZING
2019-12-25 21:36:31.368 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:8f096f99’ changed from INITIALIZING to UNKNOWN
2019-12-25 21:36:31.377 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:6d9f9601’ changed from UNINITIALIZED to INITIALIZING
2019-12-25 21:36:31.396 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:6d9f9601’ changed from INITIALIZING to UNKNOWN
2019-12-25 21:36:31.431 [hingStatusInfoChangedEvent] - ‘shelly:shelly4pro:1128feb0’ changed from UNINITIALIZED to INITIALIZING
2019-12-25 21:36:31.454 [hingStatusInfoChangedEvent] - ‘shelly:shelly4pro:1128feb0’ changed from INITIALIZING to UNKNOWN
2019-12-25 21:36:31.467 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:af54f3ba’ changed from UNINITIALIZED to INITIALIZING
2019-12-25 21:36:31.489 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:af54f3ba’ changed from INITIALIZING to UNKNOWN
2019-12-25 21:36:31.506 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:4906561d’ changed from UNINITIALIZED to INITIALIZING
2019-12-25 21:36:31.528 [hingStatusInfoChangedEvent] - ‘shelly:shellyht:4906561d’ changed from INITIALIZING to UNKNOWN

2019-12-25 21:36:34.781 [hingStatusInfoChangedEvent] - ‘shelly:shelly4pro:1128feb0’ changed from UNKNOWN to ONLINE

markus7017 · December 25, 2019, 9:13pm

I completely removed setting status to UNKNOWN
Are you sure you are using the correct jar?

How do you install the binding - you can’t do this with PaperUI when using a DEV release, see above.

Did you deleted the things & cleaned the cache before copying this build to the addons folder?

dilisi · December 25, 2019, 9:50pm

I try it now on a new openhab2 installation. No bindings activated. I have the following error log entries:

2019-12-25 22:45:53.541 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.shelly-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.shelly [203]
Unresolved requirement: Import-Package: org.eclipse.californium.core; version="[2.0.0,3.0.0)"

    at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]

markus7017 · December 25, 2019, 10:01pm

you need to follow the instructions: