Shelly Binding

Add-ons Bindings
,
712

During autodiscovery, the binding determines the functionality of the devices. Unfortunately, there might be differences between the MQTT given information and what is available with the REST and/or CoIoT (CoAP) interface. Please note that Shellys own documentation is error prone…
If the latest firmware updates made this available via REST and CoIoT, it should be no problem to enhance the binding.

713

Hi Hans,

As stated the shelly plug does announce the value to the MQTT broker, the same way the plug-s does. So the value seems to be there, and it seems to be valid aswel. I also mentioned i have no clue how the bindings are build and if these use MQTT or another protocol. So i guess you might be right the values are not being announce via REST or ColoT (no idea what these are)

But i could add the shelly as a general MQTT thing and read the same values, so that is a solution for this but i’d rather use this binding because the rest does seem to work properly

714

The Shelly Binding is REST API based.
Could you post here the JSON output of http://<Plug_Device_IP>/status please?

1 Like
715

I will share this with you this evening, i am not able to reach the shellie device outside my own network (i use a VPN connection but i get a diferent IP, seems like the shelly does not have a GW or does not do routing)

716

IS this what u are looking for?: (i omitted some data)

{“wifi_sta”:{“connected”:true,“ssid”:“Very-Secret”,“ip”:“even.more.secret.:-)”,“rssi”:-84},“cloud”:{“enabled”:false,“connected”:false},“mqtt”:{“connected”:true},“time”:“18:38”,“serial”:1,“has_update”:false,“mac”:“A81B6A7BXXXX”,“relays”:[{“ison”:true,“has_timer”:false,“overpower”:false}],“meters”:[{“power”:0.00,“is_valid”:true,“timestamp”:1576780733,“counters”:[0.000, 0.000, 0.000],“total”:17670}],“update”:{“status”:“idle”,“has_update”:false,“new_version”:“20191216-090203/v1.5.7@c30657ba”,“old_version”:“20191216-090203/v1.5.7@c30657ba”},“ram_total”:64620,“ram_free”:41568,“fs_size”:83081,“fs_free”:23845,“uptime”:82803}

717

Yes, perfect. As you can see there is a power meter data.
@markus7017 would you check it please?

718

ok, I changed the xml to include the additional values and provide a build by end of weekend
this will be the latest snapshot incl. the info how to install on 2.4/2.6 M-builds

1 Like
719

@markus7017 sorry for the following stupid question: How can i update once you release a new version? i am on the stable 2.5 release.

720

So I’ve upgraded to 2.5 stable, my rollershutters seems to perform right, but I can see something strange about my HT sensors. (should I deleted and removed all my shelly things?).

I turned on manually the HT sensor and I get this log:

2019-12-20 16:45:25.305 [vent.ItemStateChangedEvent] - Shellyht58f736_BatteryLevel changed from 98.00 to 100.00
2019-12-20 16:45:25.334 [vent.ItemStateChangedEvent] - Shellyht58f736_Humidity changed from 61.50 % to 66.00 %
2019-12-20 16:45:25.337 [vent.ItemStateChangedEvent] - Shellyht58f736_Temperature changed from 22.00 °C to 20.90 °C

==> /var/log/openhab2/openhab.log <==
2019-12-20 16:45:27.361 [WARN ] [y.internal.handler.ShellyBaseHandler] - shellyht-58f736: Alarm condition: LOW_BATTERY

So the first thing is I have an alarm of LOW_BATTERY with battery at 100%,
the second is that the last updated item (linked to device#lastUpdate channel) does not change, it’s stucked since the OH upgrade.

721

I have some issues with the shelly plug:

2019-12-20 21:26:30.508 [WARN ] [y.internal.handler.ShellyBaseHandler] - shellyplug-xxxxxx ERROR: Unable to process command for channel shelly:shellyplug:xxxxxx:relay#output: Shelly API call failed: Timeout (6000 ms) (class java.io.IOException)

Stack Trace: [org.openhab.binding.shelly.internal.api.ShellyHttpApi.request(ShellyHttpApi.java:492), org.openhab.binding.shelly.internal.api.ShellyHttpApi.setEventUrls(ShellyHttpApi.java:442), org.openhab.binding.shelly.internal.api.ShellyHttpApi.setRelayEvents(ShellyHttpApi.java:370), org.openhab.binding.shelly.internal.api.ShellyHttpApi.setEventURLs(ShellyHttpApi.java:359), org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.initializeThing(ShellyBaseHandler.java:226), org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.handleCommand(ShellyBaseHandler.java:271), sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method), sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62), sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43), java.lang.reflect.Method.invoke(Method.java:498), org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152), org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59), com.sun.proxy.$Proxy338.handleCommand(Unknown Source), org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:74), org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48), sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method), sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62), sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43), java.lang.reflect.Method.invoke(Method.java:498), org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152), org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52), java.util.concurrent.FutureTask.run(FutureTask.java:266), java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149), java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624), java.lang.Thread.run(Thread.java:748)]

Not sure if this is binding related, could well be the plug as well. It also responds slow when using the built in webinterface to switch power on and off.

722

I broke the antenna of a Shelly2.5. Since then its really slow sometimes, because of bad WiFi.

Did you try the plug in a better position (e.g. close to the router)?

723

Yes i did, the wifi signal is fine. its close to one of my s plugs and these perform very well to be honest. much better then the big plug. I only bought the big plug for my washing machine but it sees my WM only uses max 2300 watt so should be able to do it with a plus s.

724

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 :crazy_face:

anything else?

1 Like
725

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.

726

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

727

“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.

1 Like
728

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.

729

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:

Install DEV/SNAPSHOT build of the binding

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

1 Like
730

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

731

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)