Is ShellyForHass good?
I’ve noticed that Shelly firmware allows configuration of url - s on events, e.g. Long press of second switch. Using this polling could be theoretical disabled even over http…
1 Like
After a lot of reading, learning, installing home assistant more than once and finding the first big obstacle to be resolved by a shelly1 factory reset… I am not officially stuck.
My setup:
2 light switches to control 1 light with a smart bulb
1 shelly1 installed correctly (I hope) - detached mode
Home Assistant out of the box with a minimum setup to support MQTT
My goal:
Use any of the switches to turn the light on or off
Debug log:
2020-10-27 17:19:55 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on shellies/shelly1-10521CF32190/input/0: b'1'
2020-10-27 17:19:55 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on shellies/shelly1-10521CF32190/input/0: b'0'
With this I set up an automation which does not work and this is where I am stuck. My automation script right now is the following:
platform: state
entity_id: binary_sensor.shelly_1_10521cf32190_input_0
from: '0'
to: '1'
I did however try a lot of combinations with and without from and On and Off as values. Nothing seems to work and any hint into the right direction would be greatly appreciated. The trigger part works fine when I click on “Execute”
As I understood you are configured Shelly1 to communicate through mqtt.
But I’m missing how did you get to this sensor? How it has been created? Or what has created it for you?
Is it mqtt sensor? BTW it should be binary sensor imo since it can have 2 states only.
I used the discovery script from this thread which created quite a few entities which includes the “binary_sensor.shelly_1_10521cf32190_input_0” one.
In the examples here I have seen event toggles from On to Off which makes sense but the debug log shows those b’1’ and b’0’ entries which I think are part of the problem.
Update… and feeling stupid… Using “on” and “off” works so well but “On” and “Off” does not work very well… 
So I finally started testing out the ShellyForHASS HACS integration. I have the switch sensor enabled. I can see the state of my other shelly switches that are NOT momentary. However the one I want to see the state is conencted to a momemtary input. IE it just will get a pulse on/off. Does the shelly and/or integration not detect a quick pulse?
Note I have this shelly connected to MQTT and in MQTT it does see the switch input change, so this seems to be an integration issue.
Reading more on the ShellyForHASS and I may know why it is not working. I may not be using CoAP mode since my shellies are on another network and using discovery by ip. If it is not using CoAP would that prevent it from seeing the updates for the sensor?
If you are using 2 shellies to control a single light I assume this is to overcome a 3-way light switch issue. Have you tried using the shelly actions to have the shellies control themself? I believe they have this feature in the newer firmware as a way to handle this situation directly without the need of a server. Advantage here is that if HA is offline the switches still will function to control the light (wifi still has to be online).
While using 2 shellies to achieve 2/3-way switch layout seems to me to be overkill, using toggle action sent via http api or mqtt should be enough. Isn’t it?
What fw changes are you expecting in regard of this?
So using 2 shellies is one way to solve the 2/3-way switch issue depending on how the house is wired. If the house has power to the Light and not the switch you can use just a single shelly mounted in the light. Or if the house is wired with power to the switch then you need to do what Komplizio did with 2 shellies or if you are lucky and the switch that has the common connect to the light (IE the one that does not have HOT to it) and that one has another switch in the same gang box on the same circuit with a HOT you can power the shelly off of that HOT and maintain a 3-way switch with just a single Shelly. But that has a lot of “ifs”.
I do not think anyone expects FW changes regarding this. I was just stating that the current FW on the shelly actually supports having two shellies communicate without needing a server between them or added rules to accomplish a virtual 3-way switch.
Hey @kedante Did you ever find a solution for this? I am encountering the same thing of lights switching on after a Hassio reboot. My automation is built in NodeRED but it essentially exactly what you posted above.
Hi @Kevin_Boutwell. No, unfortunately I still have the problem 
!
I think it depends what state is the “input_boolean” when there is a reboot.
But I don’t understand why if I have a certain state, on reboot it should change.
It would seem that restarting affects the state. if you find a solution let me know.
Just took a look on your mqtt entity definion. Why you created the entity based on shelly input?
Set it to use output of shelly device (relay/0 or relay/1 depending on device). then it will follow the actual state of the shelly, not the input
My entity is setup the same using the Shellies Discovery Script. My understanding is that input monitors the state of the switch and not the relay.
your assumption is wrong.
There is not something like switch state separated from relay state. Especially considering number of posdible input types, you cannot define switch state based on those.
There are: input state and relay state. If I had to, I could call relay state a switch state thought.
input reflects state of input. It gets value of 1 when voltage is connected to input terminal, 0 when no voltage. Note, it follows exactly a way how switches work. for momentary buttons, the input is set to 1 only in the moment when button is pressed. It has value 0 if button is released regardless if a light is turned on or off.
Relay/0 reflects state of the first relay. 1 when turned on, 0 when off. Always. Regardless button type, initial state after power loss or even a way of how relay is controlled (physical buton, api, mqtt etc). the same for relay/1 (second relay) if applicable.
I really doubt that discovery registers Shelly relays in a way how you have said. It would make impossible to use momentary buttons, reverted buttons, toggle buttons in direct way (without special customization on HA side) and also issuing problems with default state on (as in your case).
This is why I always discourage from using layers you have no control over. By setting mqtt entities manually you would have never done such mistake in interpretation.
Based on how you explain it it seems as though it is still set up correctly. Using input, I do want to monitor whether terminal 0 is receiving voltage or not. Basically indicating whether the switch is flipped or not. You mentioned to use output instead, could you elaborate a bit on that?
The issue I am encountering is not on power loss, it is on a HA reboot. Upon reboot something is turning the lights on (switching the boolean somehow) and I am not sure what that is. Here is my NR flow https://bit.ly/3rH3JnO
You need to answer yourself what you need:
- to intercept physical switch changes - then you need to monitor the input
- to display relay/light state in HA - then you need to monitor the relay
But in most cases you are using “input” only to trigger state change, and state to display relay/light state
As I wrote those things are decoupled from each other. Let’s consider physical toggle switch and Shelly device configured to work with “Edge” to toggle lights.
If you toggle physical switch from 0 to 1 it will cause Shelly relay turn on. But then if you disable the switch using HA? the input will remain 1 while relay turned off. After HA restart, the light is still off while input is 1 which might be interpreted that the light is on. Which obviously is not true.
I’m looking at your NR flow. At first I really don’t understand why you are copying physical switch state into input_boolean. I had all my lights controlled by Shellies and never had to do that. But maybe you have your reasons. Anyway without seeing how are your nodes configured it’s impossible to answer your question. Paste the flow code here (you can find export option in hamburger menu in top-right corner)
I’m running the Shelly in detached mode. Relay always on and connected to a few Hue lights. This is why I am monitoring the input and if I turn on the lights via voice, or HA front end. A boolean is the only way I could think to make that work, then stumbled upon this thread. I am trying to get an edge style switch but in detached mode.
NR flow:
[
{
"id": "a323193c.4daf28",
"type": "tab",
"label": "Bathroom",
"disabled": false,
"info": ""
},
{
"id": "52f650b8.0064",
"type": "server-state-changed",
"z": "a323193c.4daf28",
"name": "Bathroom Switch Boolean",
"server": "db4d7e4c.c3fd4",
"version": 1,
"exposeToHomeAssistant": false,
"haConfig": [
{
"property": "name",
"value": ""
},
{
"property": "icon",
"value": ""
}
],
"entityidfilter": "input_boolean.bathroom_switch",
"entityidfiltertype": "exact",
"outputinitially": false,
"state_type": "str",
"haltifstate": "on",
"halt_if_type": "str",
"halt_if_compare": "is",
"outputs": 2,
"output_only_on_state_change": true,
"for": 0,
"forType": "num",
"forUnits": "minutes",
"ignorePrevStateNull": false,
"ignorePrevStateUnknown": false,
"ignorePrevStateUnavailable": false,
"ignoreCurrentStateUnknown": false,
"ignoreCurrentStateUnavailable": false,
"x": 230,
"y": 600,
"wires": [
[
"ea3fb2bc.f5304"
],
[
"c2ba62f1.6a8ba"
]
]
},
{
"id": "ea3fb2bc.f5304",
"type": "time-range-switch",
"z": "a323193c.4daf28",
"name": "",
"lat": "55.58746",
"lon": "12.98149",
"startTime": "02:00",
"endTime": "06:00",
"startOffset": 0,
"endOffset": 0,
"x": 570,
"y": 540,
"wires": [
[
"7dd7701d.42187"
],
[
"e2d528cc.f97a28"
]
]
},
{
"id": "e2d528cc.f97a28",
"type": "api-call-service",
"z": "a323193c.4daf28",
"name": "Day Scene",
"server": "db4d7e4c.c3fd4",
"version": 1,
"debugenabled": false,
"service_domain": "scene",
"service": "turn_on",
"entityId": "scene.bathroom_on_day",
"data": "",
"dataType": "jsonata",
"mergecontext": "",
"output_location": "",
"output_location_type": "none",
"mustacheAltTags": false,
"x": 830,
"y": 580,
"wires": [
[]
]
},
{
"id": "7dd7701d.42187",
"type": "api-call-service",
"z": "a323193c.4daf28",
"name": "Night Scene",
"server": "db4d7e4c.c3fd4",
"version": 1,
"debugenabled": false,
"service_domain": "scene",
"service": "turn_on",
"entityId": "scene.bathroom_on_night",
"data": "",
"dataType": "jsonata",
"mergecontext": "",
"output_location": "",
"output_location_type": "none",
"mustacheAltTags": false,
"x": 830,
"y": 500,
"wires": [
[]
]
},
{
"id": "c2ba62f1.6a8ba",
"type": "api-call-service",
"z": "a323193c.4daf28",
"name": "Off Scene",
"server": "db4d7e4c.c3fd4",
"version": 1,
"debugenabled": false,
"service_domain": "scene",
"service": "turn_on",
"entityId": "scene.bathroom_off",
"data": "",
"dataType": "jsonata",
"mergecontext": "",
"output_location": "",
"output_location_type": "none",
"mustacheAltTags": false,
"x": 820,
"y": 660,
"wires": [
[]
]
},
{
"id": "990c4f16.c26cf",
"type": "server-state-changed",
"z": "a323193c.4daf28",
"name": "Bathroom Physical Switch",
"server": "db4d7e4c.c3fd4",
"version": 1,
"exposeToHomeAssistant": false,
"haConfig": [
{
"property": "name",
"value": ""
},
{
"property": "icon",
"value": ""
}
],
"entityidfilter": "binary_sensor.shelly_1l_84cca8ada4ab_input_0",
"entityidfiltertype": "exact",
"outputinitially": false,
"state_type": "str",
"haltifstate": "on",
"halt_if_type": "str",
"halt_if_compare": "is",
"outputs": 2,
"output_only_on_state_change": true,
"for": 0,
"forType": "num",
"forUnits": "minutes",
"ignorePrevStateNull": false,
"ignorePrevStateUnknown": false,
"ignorePrevStateUnavailable": false,
"ignoreCurrentStateUnknown": false,
"ignoreCurrentStateUnavailable": false,
"x": 230,
"y": 120,
"wires": [
[
"3ec4b3e0.38e60c"
],
[
"4b760d56.2fabb4"
]
]
},
{
"id": "3ec4b3e0.38e60c",
"type": "api-call-service",
"z": "a323193c.4daf28",
"name": "Toggle Input Boolean Switch",
"server": "db4d7e4c.c3fd4",
"version": 1,
"debugenabled": false,
"service_domain": "input_boolean",
"service": "toggle",
"entityId": "input_boolean.bathroom_switch",
"data": "",
"dataType": "jsonata",
"mergecontext": "",
"output_location": "",
"output_location_type": "none",
"mustacheAltTags": false,
"x": 620,
"y": 80,
"wires": [
[]
]
},
{
"id": "4b760d56.2fabb4",
"type": "api-call-service",
"z": "a323193c.4daf28",
"name": "Toggle Input Boolean Switch",
"server": "db4d7e4c.c3fd4",
"version": 1,
"debugenabled": false,
"service_domain": "input_boolean",
"service": "toggle",
"entityId": "input_boolean.bathroom_switch",
"data": "",
"dataType": "jsonata",
"mergecontext": "",
"output_location": "",
"output_location_type": "none",
"mustacheAltTags": false,
"x": 620,
"y": 160,
"wires": [
[]
]
},
{
"id": "62740d4a.3f7244",
"type": "server-state-changed",
"z": "a323193c.4daf28",
"name": "LIghts on/off Manually",
"server": "db4d7e4c.c3fd4",
"version": 1,
"exposeToHomeAssistant": false,
"haConfig": [
{
"property": "name",
"value": ""
},
{
"property": "icon",
"value": ""
}
],
"entityidfilter": "group.bathroom",
"entityidfiltertype": "exact",
"outputinitially": false,
"state_type": "str",
"haltifstate": "on",
"halt_if_type": "str",
"halt_if_compare": "is",
"outputs": 2,
"output_only_on_state_change": true,
"for": 0,
"forType": "num",
"forUnits": "minutes",
"ignorePrevStateNull": false,
"ignorePrevStateUnknown": false,
"ignorePrevStateUnavailable": false,
"ignoreCurrentStateUnknown": false,
"ignoreCurrentStateUnavailable": false,
"x": 220,
"y": 320,
"wires": [
[
"ecaa71c3.de78f"
],
[
"15dfec44.3a02f4"
]
]
},
{
"id": "ecaa71c3.de78f",
"type": "api-call-service",
"z": "a323193c.4daf28",
"name": "Toggle Boolean on",
"server": "db4d7e4c.c3fd4",
"version": 1,
"debugenabled": false,
"service_domain": "input_boolean",
"service": "turn_on",
"entityId": "input_boolean.bathroom_switch",
"data": "",
"dataType": "jsonata",
"mergecontext": "",
"output_location": "",
"output_location_type": "none",
"mustacheAltTags": false,
"x": 590,
"y": 280,
"wires": [
[]
]
},
{
"id": "15dfec44.3a02f4",
"type": "api-call-service",
"z": "a323193c.4daf28",
"name": "Toggle Boolean off",
"server": "db4d7e4c.c3fd4",
"version": 1,
"debugenabled": false,
"service_domain": "input_boolean",
"service": "turn_off",
"entityId": "input_boolean.bathroom_switch",
"data": "",
"dataType": "jsonata",
"mergecontext": "",
"output_location": "",
"output_location_type": "none",
"mustacheAltTags": false,
"x": 590,
"y": 360,
"wires": [
[]
]
},
{
"id": "db4d7e4c.c3fd4",
"type": "server",
"name": "Home Assistant",
"addon": true
}
]
thnx for code and explaining your reasons. Yeah… seems to be valid. will look at this on the evening. Now I’m at work
Thanks! I should be working as well…
OK. I suppose I know what happens.
Short version
Set your state nodes as on image below and try if it improves somehow. You can also play with previous state doesn’t exists to cover even more situations (see longer version below)
Long version
When HA is being restarted, it’s getting lost states of MQTT entities until you refresh them. Such entities have
unavailable state set.In case of Shellies configured via mqtt, you have to force them to send their announce messages to mqtt (I believe you have some automation for that) in order to make HA update their states with valid values.
In the meantime NR is still working and is registering those changes (to and from invalid states like unknown/unavailable). It causes sudden lights toggle, because the only condition you set in this node is that new state differs from previous one.
In other words, your flow reacts not only on changes between on and off input states, but also on transitions between them and unavailable state.
With proposed settings NR will ignore all invalid transitions. Once HA set valid states, everything should work properly.
In addition you can simplify your flow by removing state condition. Since call service node reacts on ANY message and we already excluded all invalid state transitions as well as subsequent messages with the same states,call service node should receive messages of valid transition between on and off states only
It’s not tested by me, so there might be still some corner cases or shortcoming. But now you should have an idea. I hope it will help you.
1 Like