Issue with Shelly Binding, rules and shelly 1

Setup, Configuration and Use Scripts & Rules
1

Hi,
I’m running openHAB 3.1 on Windows 10.

I’ve installed Shelly Binding and included my Shell 1, which is attached on a toggle switch, to openHAB Shelly Binding.

When I turn on the light on/off with the switch, in openhab via the item or via alexa it works without any issue and all events and the previous state of the shelly will be recognized correctly.
The only issue I have is with a rule. So e.g. I have a door contact sensor, when this gets an update to OPEN then I send to the Shelly Item sendCommand(“ON”).

Now the issue I have: the shelly relay (and therefore the light) also turns on successfully by rule, but when I want to turn off the light again with the phsysically toggle switch, I need to turn it two times. It looks like openHAB doesn’t communicate the new state to the shelly 1 when I change it by rule via sendCommand(“ON”)

my item:

Switch Flur "Flur" <light> (Flur, UntenAlle, pGroup) ["Lighting"] {channel="shelly:shelly1:e0980696937f:relay#output"}
type or paste code here

my rule:

rule "Flur an bei Tuer auf"
when
	Item TuerSensorHT received update OPEN
then 
		Flur.sendCommand("ON")
end

the event part started when the door contact opens incl. the rule sendCommand event to shelly:

event: message
data: {"topic":"openhab/items/TuerSensorHT/state","payload":"{\"type\":\"OpenClosed\",\"value\":\"OPEN\"}","type":"ItemStateEvent"}

event: message
data: {"topic":"openhab/items/TuerSensorHT/statechanged","payload":"{\"type\":\"OpenClosed\",\"value\":\"OPEN\",\"oldType\":\"OpenClosed\",\"oldValue\":\"CLOSED\"}","type":"ItemStateChangedEvent"}

event: message
data: {"topic":"openhab/items/Flur/command","payload":"{\"type\":\"OnOff\",\"value\":\"ON\"}","type":"ItemCommandEvent"}

event: message
data: {"topic":"openhab/items/Flur/statepredicted","payload":"{\"predictedType\":\"OnOff\",\"predictedValue\":\"ON\",\"isConfirmation\":false}","type":"ItemStatePredictedEvent"}

event: message
data: {"topic":"openhab/items/Flur/state","payload":"{\"type\":\"OnOff\",\"value\":\"ON\"}","type":"ItemStateEvent"}

event: message
data: {"topic":"openhab/items/Flur/statechanged","payload":"{\"type\":\"OnOff\",\"value\":\"ON\",\"oldType\":\"OnOff\",\"oldValue\":\"OFF\"}","type":"ItemStateChangedEvent"}

the event part when using the physical toggle switch to turn the light off again:

event: message
data: {"topic":"openhab/items/Flur/command","payload":"{\"type\":\"OnOff\",\"value\":\"ON\"}","type":"ItemCommandEvent"}

so the toggle switch / shelly again sends falsely an ON instead of OFF.
Thanks for your help.

2

These look like openHAB event bus MQTT messages, nothing to do with traffic to Shelly?

3

this text is copy pasted from the openhab/rest/events bus. So the communication inside of openhab and the devices.
I’m not running anything via MQTT and I dont have a MQTT Broker.

4

Alright. I suppose most people use events.log for this, because you get timestamp info to see timing relationships. But no external traffic shows either way.

What makes you think this openHAB internal command originates from Shelly? I’d expect a state update.

5

Because, when I turn on the light in openHAB UI it turns on. When I go to the toggle switch, it goes off. When I say via voice to alexa to turn on the light, it turn on. When I go to the toggle switch, it goes off.
When a rule sends the sendCommand(“ON”) to the light, it turns on. When I go to the toggle switch, it keeps on and in event you can see, that the toggle switch sends for what ever reason again an ON instead of OFF.

6

And

These are identical processes within openHAB. The binding cannot distinguish if a command comes from UI or rules, so it won’t be able to influence the Shelly to behave differently either.

Conclusion; are your rules sending commands to a different Item than your UI?

There is some funny cross-connection here, state updates from Shelly would not normally result in commands at openHAB, these are different things.

I suspect if you disable autoupdate on your Item temporarily (this kills the ‘prediction’ stuff), you might find that you’re not getting updates from Shelly at all.

7

items files:

Contact TuerSensorHT "Tuersensor HT" <DoorWindow> (TuerFensterKontakt, pGroup) ["Contact"] {channel="zwave:device:9fd791fc7a:node3:sensor_door"}
Switch Flur "Flur" <light> (Flur, UntenAlle, pGroup) ["Lighting"] {channel="shelly:shelly1:e0980696937f:relay#output"}

UI view:

image
image735×640 15.5 KB

rule code:

rule "Flur an bei Tuer auf"
when
	Item TuerSensorHT received update OPEN
then 
		Flur.sendCommand("ON")
end

So I would answer with yes. Mhhh

8

Show us an events.log of your UI controlled exercise. And then of your rule exercise.

9

Isn’t this related to Shelly device settings, available on Shelly’s IP-address or in Shelly manager (http(s)://OpenhabIP/shelly/manager)? There are some options about how Shelly reacts to physical switch toggle.

10

Sorry guys, I hadn’t much time the last days…

Today I have exchanged my cross connection toggle light switch (3 toggle switch for hall way) with momentary switchs. Changed the shelly 1 from toggle to momentary and it work like it should.

So I assume there is a bug in shelly (even if I cant believe it after years of development…). But that’s what I figured out

11

I haven‘t read through all of this thread. If I understand it correctly you have to set Button Type to Edge Switch within your shelly device

12

No.

the past situation: 3 toggle switch cross connected for one hallway light. shelly was setupped as toggle switch.

new stiuation: changed to 3 momentary switchs. shelly configured to momentary switch. Since then, the event report works in all ways.