Shelly Binding

Add-ons Bindings
,
1848

I use also with static IPs without any problems.

1 Like
1849

yep, how should the device report an push event when the button is detached?

1850

you need to delete and re-discover thing when the IP changes, the binding def. works with devices using a static ip

1851

If you want to use the action urls you need to disable CoIoT events

  • binding config
  • thing config
    the binding will reinitialize the thing and set the urls, which you also see in the device ui
1852

I did it already. I see in the logs that it goes through the various devices but the action URLs are not touched. They are not removed when you activate COAP and they are not set when you deactivate it. I’ve only being able to have them set at the initial inclusion (that was probably before COAP/CoIoT support).

1853

But the button IS reporting events. I’m using the input channel to switch my hue lights on and off when the button is pressed. As far as I know the detached mode means that button events are not directly reported to output but are still reported by the Shelly device. The only thing that is not working for me is the trigger.

1854

we are talking about different things

  • In general Coap and action urls are independent from each other. However, the binding does not register action urls if Coap is enabled, because Coap is event driven and provides more information than those urls. The binding has the AutoCoToT feature in the binding settings to activate Coap automatically when firmware 1.6+ is detected.
  • When AutoCoIoT and Coap events are disabled the binding registers the selected action urls at thing initialization. If this is not working something musst be wrong. Delete the thing and re-discover.
  • You need to select momentary button mode to receive the push events. The device doesn’t generate those in detached mode. However, you could do the mentioned trick and trigger when the output is switched so the event gets fired on the output side, not on the input side. In this case you can‘t use the trigger channel, but the rule could trigger when the output item changes on/off.
  • The input channel represents the on/off status of the SW connector. In switch mode this corresponds to the on/off state of the input Atem. In momentary button mode you get on top the push events (short, long, 2xs etc)

Ig you disable Coap, enable the action urls and don‘t see the url registration in the DEBUG log something is wrong. Please provide the log extract showing the complete thing initialization.

1855

Voltage reading from Shelly1PM and Shelly 2.5.
I would like to monitor the current (not just power) from these devices. The voltage is available in the Shelly UI (and the binding has it available in the EM) but the binding doesn’t make it available. Is there any possibility of including it?
I’d also like a bit more granularity in the RSSI value. Again the dBm value is available in the UI but the binding only gives 0-4

1856

This is not available, one reason for the EM

No plans

1857

Sorry, it’s my fault: i have textual config files and defined the things with their domainnames. After changing the Shelly to a static IPs it is required to restart the dns-server (Fritzbox in my case). Otherwise the dns-server answered with wrong IPs and therefor the binding can’t work.

1858

Is there a list what Shelly devices are supported in what version of the shelly binding. I have OH 2.5 but that version is not supporting the Shelly button 1 and the window sensor.

1859

Is shelly motion integrated in the last snapshot for 2.5?
Greets

1860

Just got the new Shelly Bulb RGBW GU10 . OpenHAB is detecting it (PaperUI/inbox), but shows as “shelly:shellyunknown” under device. Realise this is a very new device, anything information i can post to help integration of this new device? (I.e. information i can provide given that i have the bulb that will help).

1861

Quick data point: i manually configured the ‘Thing’ using “shelly:shellybulb:xxx” and this seems to work. The binding doesn’t detect the GU10 as a ‘shellybulb’, but it seems to use the same commands.

1862

you habe to switch to the DEV build, the release version is based on OH 2.5. There is no way to get additional features into that stream. The DEV build is pretty sable

Check README for a list of supported devices

—

Latest DEV build: 2.5.13 - 3.1.0 - README - Installation - Bugs/Features - Firmware Index - Firmware Archive - API Doc
Note: The binding version included in the final OH 3.0 distro is significantly older than the DEV build. I can’t make it in-time. Make sure you deleted older versions of the binding when installing the 2.5.13-SNAPSHOT or 3.1.0-SNAPSHOT if you are already on OH 3.

1863

same; switch fi the DEV build, G10 is supported
same for Shelly Motion

2 Likes
1864

added today my new ShellyMotion (OH3.1M1, Shelly Dev-Binding)
Log says Firmware too old - but device is already on latest firmware.
Maybe a small bug or improvement for/within the binding, Markus? :slight_smile:

[WARN ] [y.internal.handler.ShellyBaseHandler] - shellymotionsensor-60a4XXXXXX: WARNING: Firmware might be too old, installed: v1.0.3/20210211-193341 (770a8cb1), required minimal v1.5.7.
1865

latest firmware for Motion is 1.0.4, I‘m not site if this is in the official repo, let me know

ok, it‘s simpel
Motion is a completely new firmware starting with 1.0.x and this is of course < 1.5.7
Let me check if I could detect the hardware generation and then allow 1.0+

1866

I updated the DEV build, please check

1867

Hi Markus,
Thanks for your perfect information.
It is working fine.