Shelly Binding

Updated PR#10815 to include

  • Feature #10090 New device#supplyVoltage channel for Shelly 2.5, 1PM and 1L
  • Feature #10737 Power Factor for Shelly EM (computed by the binding)
  • Change #10039 Info on “not reachable / timeout” should be warning, not info
  • Fix #10799 Missing Channel Definition for Vibration Events
  • Fix #10738 Shelly UNI - ADC Voltage units of measure missing
  • Fix #10111 Creating Equipment from Shelly Bulb Duo causes wrong min/max
  • README updated

Thanks Markus:

That looks great. I hope you didn’t mind the minor comments - just seemed better to make it consistent from the beginning.

Really appreciate your effort to make the change.

I’ve updated both build (3.0.3, 3.10M5)

@Mark_Viele Grüße, Markus I updated the 3.1M5 build
I noticed that the powrt factor is dimensionless (percent) so I changed the channel type. Please verify by deleting the thing, re-discover and then the channel should show xx% (Numer:Dimensionless)

I’m using 3.1M4 to control my Shelly Bulb. All perfect, except switching color/white mode.
Documentation for shellybulb mentions “control/mode” switch. But this channel is not available on my installation. Why?

1 Like

Hello Markus,

What kind of trigger can I use from a HT sensor when a deticated temperatur is reach?
It seems I have those triggers ready in the shelly binding:


Thanks for the answer…

Hi Markus,

Currently I’m testing with OH3.1M5 but have problems with the shelly button. When connecting the external power the status#lastUpdate field is updated with the current time but when I remove the power then I don’t get any update (no entry in event.log and openhab.log). The dw2 sensors are working fine. What I also see is that the button is version 2 but only version 1 exists in the binding.
Any idea how to troubleshoot this or is the version 2 not supported yet?

image

try updated DEV build for 3.1M5

I would Create a rule “when item htTtemp changed then (if tempItem > xx)”
otherwise trigger TEMP_OVER should do the job, but I never tried

It might be that the 2nd ext_power change is filtered, because the event type has not changed. The problem is that the device reports those updates as state, not as a event so the binding needs to filter duplicates. But you should have channel device#charger, which provides this info, so create a rule “when item charger changed”

The device goes also offline after about 10 hours
2021-06-18 14:34:57.856 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellybutton1-e09806a8fb75: Event triggered: EXT_POWER
2021-06-19 02:37:42.758 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellybutton1-e09806a8fb75: Thing goes OFFLINE: message.offline.status-error-watchdog

hi markus,
if we are on release build 3.1 which version should we install

The 3.1 from the dist is pretty close to the DEV build. However, this brings you back to the DEV if you want to get new features so the latest 3.1 DEV build is also fine

I am trying shelly also now…Looks promising…but I have some Problems:

Oh 3.2 snapshot
With shelly binding

Only working correct is temperature via shelly1 with addon and on/off of shelly plus.
Rest i get Not working!
No motion alarm…no data from shellyht or motion…nothing
Is the Bindung still buggy or do you habe a working config to share for
Shellymotion
Shellyht
Shell1
Shellplug
Shellyflood

Hope someone can help here…

I have al the aformentioned devices and they work pretty perfect with the binding…

if you want to use the shelly motion you need to set up your unicast adress in the motion itself (is the adress of you openhab server)

doesn’t the binding show al the shelly’s in your inbox?

Hi Jeroen,
I have All Devices online, but i get no Events or data…except of the 3 Temperature connected to the shelly1…i can turn on/off the shelly plugs

Do you have OH and devices on the same network or different IP subnets?
Do you see increasing counters in Shelly Manager? esp. CoIoT messages?
Use Shelly Manager and switch devices to Unicast mode. This makes sure that CoIoT event packets are send directly to OH rather than multicast to the network.

If this doesn’t fixes the problem turn on debugging “log:set DEBUG org.openhab.binding.shelly”

Hi Markus,

all devices are in the same network (192.168.0.0) and i have connection via the web browser to nearly every device - except the bad working shellyHT. I am running openhab3 on a NAS within a docker - all working well!! Sonos, KNX, ZWave (usb dongle on the NAS), unifi , avm, samsung… in the network 192.168.0.9/24 and 192.168.1.9/24 (each lan device diferent ip)
… than the mutlicast range i guess: 253.253.253.253/24
and 2 others… 10.8.0.1 and 10.0.5.1… no idea where they are from…
i have not marked a Primery IP-Adress…
“Use Shelly Manager and switch devices to Unicast mode.”
how to do this in shelly manager?

you could open the Shelly Manager by the browser: <oh ip>;>:8080/shellymanager if I have it correctly in mind (check doc)

enable the DEBUG log on the console and check for errors/events. Try to set 1 device to Unicast (using Shelly Manager or the device UI. Config changes may requested to let Docker service multicast traffic (depends on proper Docker network setup), an issue there would explain the symptoms

Mine is on:
http://OH_ IP:8080/shelly/manager

see, users are better than my mind :wink: (currently on vacation)

Was just at my desk so could check. Enjoy your holiday.