Shelly 1 state without changing the relay

Configuration
62

Thanks for the great explanation. I turned on the ignore state changes otpions you suggested but without any success.

After a bit more digging it appears the issue only occurs when the input is on and the lights have been turned off via HA frontend or voice. This leaves the input set to on and when HA reboots, the announce automation runs, the Shelly input is polled as on and the NR flow sees that as a change and turns on the light. If HA reboots and input is off then it doesn’t occur. I can live with that since I don’t know a way around that and considering it isn’t often that HA needs to reboot anyway.

You’ve been a legend with your help! Appreciate it!

63

It’s strange. Definitively some corner case.
I use detached modes occasionally and only with momentary switches so have no yet experience with that. During weekend I’ll try to use some spare Shelly I have in a drawer to simulate that and then back to you.

One thing in mind: don’t you have the input topic set to retained? Still not sure if it would be the rootcause… but worth to check. Note settings in Shelly affects only relay retain settings. If you find the input retained it’s likely set in HA mqtt entity configuration. I suggest to remove that settings. After removal, you have to remove the topic from mqtt (there is no other way afaik to remove reain)

64

I initially went with this solution as implemented here and many others.
But I don’t understand the need of the input boolean.
Why can’t we just toggle the light when the switch is turned off or on?

Basically like this:
image

1 Like
65

When you toggle the Shelly without input boolean you are cutting off power when you have not set it in detached mode. And cutting of power on smart bulbs is bad and they will degrade faster.

The input boolean is a mqtt value that registers the flip of the switch and not the relay. It changes in 0 to 1 and 1 to 0.

With that you can make the input boolean and when the boolean changes you can turn on/off your light

66

roupen is right. considering you are sending toggle to a light, you don’t need intermediate entity in between. every input change from on to off or off to on will call toggle method.
It’s not related to relay in any way

67

Correct. I thought this conversation was related to shelly in detached mode.
In detached mode, I would create a binary sensor that reads the mqtt message from the physical switch. It then toggles the smart bulb. There is no need for intermediate entities.
The light bulb would stay powered and it can be controlled from the physical switch or from the app.

68

@Kevin_Boutwell as promised I tested your use case.
Actually I have no good news :wink:

I connected Shelly1 in detached mode to physical toggle switch, configured it via MQTT, created switch entity based on Shelly input only. In NR I configured it to toggle my hue strip.

The first attempt to reproduce it was successful. It worked as you described. The strip turned on when HA was restarting. What is strange, the strip was ON, but the light switch in my GUI remained off. And I was not able to make it on. Since GUI button was inactive I had to use physical switch connected to the Shelly a few times to make GUI representation relevant.

Then I enabled “Previous state doesn’t exist” in trigger node configuration (see images in previous posts).
It fixed the situation. Because I wanted to be sure that it’s reproducible I unchecked this option. Unfortunately the issue is not manifesting anymore :frowning:

[{"id":"4b7bfc5a.62a6f4","type":"server-state-changed","z":"70a8b538.5e7c6c","name":"","server":"6cdd0bc8.b8e434","version":1,"exposeToHomeAssistant":false,"haConfig":[{"property":"name","value":""},{"property":"icon","value":""}],"entityidfilter":"switch.testdetached","entityidfiltertype":"exact","outputinitially":false,"state_type":"str","haltifstate":"","halt_if_type":"str","halt_if_compare":"is","outputs":1,"output_only_on_state_change":true,"for":0,"forType":"num","forUnits":"minutes","ignorePrevStateNull":true,"ignorePrevStateUnknown":true,"ignorePrevStateUnavailable":true,"ignoreCurrentStateUnknown":true,"ignoreCurrentStateUnavailable":true,"x":270,"y":280,"wires":[["66aa3520.14f19c","e272b7f6.3f5438"]]},{"id":"66aa3520.14f19c","type":"debug","z":"70a8b538.5e7c6c","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":670,"y":330,"wires":[]},{"id":"e272b7f6.3f5438","type":"api-call-service","z":"70a8b538.5e7c6c","name":"","server":"6cdd0bc8.b8e434","version":1,"debugenabled":false,"service_domain":"light","service":"toggle","entityId":"light.hue_strip_1","data":"","dataType":"jsonata","mergecontext":"","output_location":"","output_location_type":"none","mustacheAltTags":false,"x":680,"y":270,"wires":[[]]},{"id":"6cdd0bc8.b8e434","type":"server","name":"Home Assistant"}]

If you disable your NR flow, is it still enabling your lights on HA restart?

69

Hi Kevin. Finally, did you find a solution?

You could share your last flow version in node-red that maybe I use it too.

Thank you very much.
Dante

70

I had major problems with a Shelly 1 switch input delaying and often actually disconnecting the device from the network, needing a power-cycle to get it online again. Yes, the wiring was all correct.

I flashed it with ESPHome firmware, and now it works flawlessly. You can just about tell that the light switch isn’t directly operating the light, but it’s a small fraction of a second delay.

71

I’ll even give you one more… As this is what I finally got accomplished…

Rather then stealing/borrowing a line from another device on the same switch to enable you to use a single Shelley to control 2/3way circuit… You could do what I did which is to repurpose one of the Travelers that already SHOULD exist between the 2 switches to make it what I call a “Traveling Load”, then you will have both Line and Load in the box. I originally tried creating a putting Line on the repurposed Traveler but unfortunately the Shelly 1L’s can’t switch Hot like the Shelly 2.5 can.

Quick suggestion on switch config. I ran my switches as detached, letting the SW1 & SW2 signal perform the real control of my SmartBulbs (Lifx).

And to wrap it up I was pleasantly pleased to see that the latency for local switching is incredibly low (well under 1 sec), so I didn’t even have to set up MQTT. Simply used the two binary properties that the Shelly Integration publishes. The only quirk was that the Shelly really sees everything as a momentary input since we are running on nearly bear metal (and getting great response time). This does make for a somewhat ugly automation but a small price to pay for real simplicity…

  alias: Toggle Bedroom Hall Lights using Shelly
  description: ''
  trigger:
  - platform: state
    entity_id: binary_sensor.bedroom_hall_lts_channel_2_input
    from: 'on'
    to: 'off'
  - platform: state
    entity_id: binary_sensor.bedroom_hall_lts_channel_2_input
    from: 'off'
    to: 'on'
  - platform: state
    entity_id: binary_sensor.bedroom_hall_lts_channel_1_input
    from: 'off'
    to: 'on'
  - platform: state
    entity_id: binary_sensor.bedroom_hall_lts_channel_1_input
    from: 'on'
    to: 'off'
  condition: []
  action:
  - service: light.toggle
    target:
      area_id: bedroom_hall
  mode: single

- id: '1619923663932'
  alias: "Toggle Downstairs Bathroom lights using Shelly switch"
  description: 'Respond to switch changes'
  trigger:
  - platform: state
    entity_id: binary_sensor.downstairs_bathroom_lts_channel_1_input
    from: 'on'
    to: 'off'
  - platform: state
    entity_id: binary_sensor.downstairs_bathroom_lts_channel_1_input
    from: 'off'
    to: 'on'
  - platform: state
    entity_id: binary_sensor.downstairs_bathroom_lts_channel_2_input
    from: 'off'
    to: 'on'
  - platform: state
    entity_id: binary_sensor.downstairs_bathroom_lts_channel_2_input
    from: 'on'
    to: 'off'
  condition: []
  action:
  - service: light.toggle
    target:
      area_id: downstairs_bathroom
  mode: single

#.... etc... etc... etc...,