Change shelly to detached mode

Configuration
1

In the past I used a switch to turn the lights on and off, and the bulbs are smart ZigBee bulbs. Of course they didn’t like that the mesh repeater (another bulb) got turned off and so they often lost reception.

Now I have Shelly 1pm in the switches. A few days this worked flawlessly as before. The shellys just did output what the input said.

So I wanted to change to detached mode. This allows more configuration. My idea is:

  • If the switch wasn’t changed in the last second, toggle the state. If it is on in any way, turn it off. If it was off, do a reasonable light.
  • If the switch already changed shortly before, change to next possible state. Bright, red, dark, whatever.

So I did a helper for the states. The states are named like the scenes.

helper input_select.flur_eg_zustand:
scene.flur_eg_aus
scene.flur_eg_mittel
scene.flur_eg_hell

Then I did an automation that actives the scene if the helper changes.

alias: Flur EG aktivieren
description: ""
triggers:
  - trigger: state
    entity_id:
      - input_select.flur_eg_zustand
conditions: []
actions:
  - action: scene.turn_on
    target:
      entity_id: "{{ states('input_select.flur_eg_zustand') }}"
mode: single

This works wonderful.

Now I wanted to implement the logic I explained above.

alias: Flur EG Schalter
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.lichtschalter_flur_eg_input_0_input
    from: "on"
    to: "off"
  - trigger: state
    entity_id:
      - binary_sensor.lichtschalter_flur_eg_input_0_input
    from: "off"
    to: "on"
conditions: []
actions:
  - if:
      - condition: template
        value_template: >-
          {{ now() > state_attr('automation.flur_eg_schalter','last_triggered')
          + timedelta(seconds=1) }}
        enabled: true
      - condition: not
        conditions:
          - condition: state
            entity_id: input_select.flur_eg_zustand
            state: scene.flur_eg_aus
        enabled: true
    then:
      - action: input_select.select_first
        data: {}
        target:
          entity_id: input_select.flur_eg_zustand
    else:
      - action: input_select.select_next
        data:
          cycle: true
        target:
          entity_id: input_select.flur_eg_zustand
mode: single

That value template which checks if the switch was toggled in the last second works fine when tested in the developer tools. It also works fine when tested by the menu in the automation editor. But switching the light switch and looking at the traces, that template always returns false!

Does anyone have an idea how to repair this?

Please note that the “next” logic works fine if the light is in state “aus” (off) already. It doesn’t matter if the switch was toggled more or less than a second ago, as the first entry after “aus” is the one the I define as “reasonable light” so that “next entry” and “first entry after aus” is the same.

Edit: OK, I got it. Of course the “last_triggered” state of the switch is “now” if it gets toggled. I need the one before or maybe just use the last state change of zustand.
The template is now fine I think:
{{ now() > states.input_select.flur_eg_zustand.last_changed + timedelta(seconds=1) }}

2

Just if someone does the same and thinks it is good idea: It is. But there is a small improvement I made. The list of state does not include the entity anymore. My current automations for Flur EG:

alias: Flur EG aktivieren
description: ""
triggers:
  - trigger: state
    entity_id:
      - input_select.flur_eg_zustand
  - trigger: state
    entity_id:
      - light.eg_flur_light_2
    from: unavailable
conditions: []
actions:
  - action: scene.turn_on
    target:
      entity_id: "{{ 'scene.flur_eg_' ~ states('input_select.flur_eg_zustand') }}"
mode: single

alias: Flur EG Schalter
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.lichtschalter_flur_eg_input_0_input
    from: "on"
    to: "off"
  - trigger: state
    entity_id:
      - binary_sensor.lichtschalter_flur_eg_input_0_input
    from: "off"
    to: "on"
conditions: []
actions:
  - if:
      - condition: template
        value_template: >-
          {{ now() > states.input_select.flur_eg_zustand.last_changed +
          timedelta(seconds=1) }}
        enabled: true
      - condition: not
        conditions:
          - condition: state
            entity_id: input_select.flur_eg_zustand
            state: aus
        enabled: true
    then:
      - action: input_select.select_first
        data: {}
        target:
          entity_id: input_select.flur_eg_zustand
    else:
      - action: input_select.select_next
        data:
          cycle: true
        target:
          entity_id: input_select.flur_eg_zustand
mode: single

Then the helper

input_select.flur_eg_zustand

has the states

aus
mittel
hell

and of course the 3 scenes

scene.flur_eg_aus
scene.flur_eg_mittel
scene.flur_eg_hell

that shall be activated need to exist.

For other bulbs there exist more states, but 3 are enough for the example. As long as you add a state name and the properly named scene for the device, it works fine.

Further information:

There is one device where the ZigBee reception is flaky. It gets unavailable quite often, and additionally it is in the bedroom where it is not wanted that the light is too bright when turned on.

I configured mode restart there for the action. Before turning off (state aus) it tried to activate the first mode, which is quite dark. It then really turns the shelly output off, because it otherwise sometimes didn’t respond.

When switching from dark to another, brighter state it checks if the device is available, otherwise it turns the power off for 2 seconds and then on again. Usually that helps to make it available again, and then the right mode can be set…

It is not that easy if the networks are not always working properly. Last night that shelly of the bedroom got unavailable 3 times for some time, seems its WLAN got bad reception. Just rebooted it and hope it will be reliable in the future. But I’m not sure how to deal with it if it is not. Then the detached mode wouldn’t be the right thing anymore, and the Shelly should handle the power for the bulb directly again, but I don’t like that idea.

So WLAN is unreliable, ZigBee is unreliable and both is needed to turn that switch in the bedroom. Really hoping that the permanent availability of the ZigBee bulbs in the hallway which I achieved by that change (shelly to detached mode) improves the mesh over the time.

I’ll improve all that over time. I want to have only one Skript with parameters which light and which scene should be activated. It should deal with the ZigBee Unavailable, so the logic to reset the bulb would be active anywhere if needed, not only in the bedroom where it is necessary.

But in the standard case having always good reception the above automations are fine.

3

I’ve been using the Detached Mode in the Shelly since 2021. I have seven Shelly 1s (Gen 1) and two Shelly Pro 4s. The bulbs being controlled are a mix of WiFi and Zigbee.

I’m lucky that I have very stable WiFi, thanks to Ubiquity access points. My Zigbee network is stable too, but it did require a repeater!

It has been rock solid. The only downside to this approach is a failure of software control makes the lights complexly uncontrollable.