Shelly PLUG lost WLAN leads to "ON" when back in WLAN

Configuration
1

Hi,
I am “playing” with an automation that should switch the TV “ON”. Setup:
A shelly PLUG is turned on and gives power to a SAT Receiver (which starts immediately, and gives power to the broadlink M4) and it gives power to the TV, which needs to be turned on manually. (This is where the M4 comes in).

So all three devices are turned on with the Shelly plug. Shelly can be turned on be pressing a remote button, of by turning it on as a device. Everything fine so far. After that, I wait, until the broadlink is there (which sometimes works, but is not the issue), broadlink turns on TV, than broadlink switches to channel 1, and a timer is started, that should turn the TV off, after a specifiv time (different story). See automation code below.

alias: FB2 SZ TV an
description: ""
triggers:
  - type: not_opened
    trigger: device
    device_id: 04acf1b0153fe951e2cf78a3ff792ad9
    entity_id: 5af740eb177e951214294fc59ef24318
    domain: binary_sensor
    enabled: true
  - device_id: 246f975fda2c988cfbaf2191496860fa
    domain: bthome
    type: button_1
    subtype: press
    trigger: device
  - type: turned_on
    device_id: 43a4c443aacd1601e448464b4b5f3caa
    entity_id: 659c86f9bc37d6413f0a967a0b6ab230
    domain: switch
    trigger: device
    id: SZ-TV-plug-ein
    enabled: false
  - trigger: state
    entity_id:
      - switch.shellyplusplugs_a0a3b3e7a284_switch_0
    from:
      - "off"
    to:
      - "on"
    id: SZ-TV-plug-ein
conditions: []
actions:
  - if:
      - condition: trigger
        id:
          - SZ-TV-plug-ein
    then: []
    else:
      - action: switch.turn_on
        metadata: {}
        data: {}
        target:
          entity_id: switch.shellyplusplugs_a0a3b3e7a284_switch_0
  - wait_for_trigger:
      - device_id: 5fcb9d21ad68a2701b16c5a0bfba3e51
        domain: device_tracker
        entity_id: 8d08e8c2c076ef12ed2adecb2717656b
        type: enters
        trigger: device
        zone: zone.home
    timeout:
      hours: 0
      minutes: 0
      seconds: 35
      milliseconds: 0
  - delay:
      hours: 0
      minutes: 0
      seconds: 10
      milliseconds: 0
  - action: remote.send_command
    metadata: {}
    data:
      num_repeats: 1
      delay_secs: 0.4
      hold_secs: 0
      device: TV-FB
      command: tv-on-off
    target:
      entity_id: remote.sz_remote_de_b0_4b_broadlink
  - delay:
      hours: 0
      minutes: 0
      seconds: 21
      milliseconds: 0
  - action: remote.send_command
    metadata: {}
    data:
      num_repeats: 1
      delay_secs: 0.4
      hold_secs: 0
      device: TV-FB
      command: 1
    target:
      entity_id: remote.sz_remote_de_b0_4b_broadlink
  - choose:
      - conditions:
          - condition: time
            after: "10:00:00"
        sequence:
          - alias: Timer auf 2:00 setzen
            action: timer.start
            metadata: {}
            data:
              duration: "02:00:00"
            target:
              entity_id: timer.sz_tv_aus
      - conditions:
          - condition: time
            after: "20:00:00"
        sequence:
          - alias: Timer auf 90 Minuten setzen
            action: timer.start
            metadata: {}
            data:
              duration: "01:30:00"
            target:
              entity_id: timer.sz_tv_aus
mode: single

As you see the automation also was triggered when the PLUG was turned “ON”. But “plug turned on” is also triggered, if the Shelly “disappears” from the WLAN for a “millisecond” and comes back. This happens “occasionally”, I donno why, but rarely enough, that it IMHO does not matter.
The problem now arises (IMHO), when (as I did) check if the device is on, as I was confused a little. The german translation correctly says “unavailable” (nicht verfügbar) when it is basically “off WLAN”, but if it comes back, it says “ON (eingeschaltet)”, which I personally would rather translate to “verfügbar (available)”, or what did I miss?

See screenshot from what I got:

shelly-plug-away-on
shelly-plug-away-on689×527 36.5 KB

thank you for enlighten me.

Juergen

2

You can probably use a not_from: unavailable clause in there.
It should be the state when the device is “nicht verfugbar”.

You should also change you automation to use entity IDs instead of device IDs.
It is hard to read, when you have no idea what entity it actually act on in a line and you will set up yourself up for chaos later when you need to replace a device, because your will not be able to reuse the device IDs.

3

Hi,
I also noticed that it is hard to read, but I clicked it together in the frontend, and this is what HA did with it. I have no idea how this can be fixed. I noticed, that this happens with Devices, that are in my HA before a certain release.

I solved the question for myself with checking if the switch of the plug is turned on/off. I just wanetd to find out, if the translation is confuding,or is there for a reason. If confusing, it should be changed, but if for a reason, the reason might be valuable for me.

plus I do not know if my solution is “good/right” in the way “as designed for HA”. I try to get a style that works “perfect” rather than it “just works” and I do not know why, as this kicks you sooner or later in complicated environments. As I use a screwdriver to get a screw in a hole and not a hammer, and if I only have a hammer, I’d rather buy a screwdriver. :slight_smile:

thanks
Juergen