Lamps have been turning on and off in the night, please help to troubleshoot

I saw in the morning that 2 lamps were on in my living room when we turned them off in the evening. Those specific 2 lamps are only integrated in one automation: when a Zwave smart switch’s state changes, it toggles the state of the lamps. It’s probably programmed to broadly, as it seems the automation is also triggered when the state changes to unavailable. Is it possible to somehow narrow it down to when state changes to “on OR off”, then toggle state of the lamp? Looking into HA, and here’s the log from the night that I saw:


etc… the whole night long
I also had this notification

I’m not sure how I can analyze exactly what happened there. My HA is not exposed to the outside internet so I don’t recognize this IP, not sure what that’s about

From what I could gather from the log, it looks like everything entity lost connection to the network simultaneously (all entities becoming unavailable) and then restored it.

  1. what could have caused it
  2. and how can I prevent this becoming unavailable issue in the future
  3. and how can I prevent that even if all lamps become unavailable and then re-gain connection, they don’t turn on?

Also side question, how can I actually analyze and parse logs in an easier way? When I open “home-assistant.log” in /config/ itself, the file is huge and it’s overwhelming to dig through all the random debug messages. Opening logbook in HA itself is oftentimes better, but I then have to explicitly pre-emptively activate for the messages from recorder to be sent to logbook as well in advance

hi there with automation, instead of broad trigger, try two trigers for on to off and off to on.

I can’t just keep creating 2 automations for every single button I program right, there has to be an easier way?
And it’s not exactly the point to catch a off->on or on->off change, as the smart switch could change its off/on state independantly of the smart lamp’s off/on state. I’m only interested when that state toggles, and ideally all other states like unavailable should be ignored

That is a docker IP address, that is from HA or an add-on communicating with another container… I’m sure someone can give you a more detailed explanation, but that is from your own system, so nothing to be concerned with security-wise. How is your system setup? If you can install the portainer add-on depending on your install method, that would probably be the easiest way to figure out what container it is coming from, although if you rebooted your entire host recently it is very possible it will have a new IP address.

… and as far as the automation goes, you would just want to use “from: off” and “to: on” or however you want it to operate, you can add multiple triggers in the same automation… but that would eliminate it triggering from being unavailable, by adding the “from:” to the trigger

How is your system setup?

my HA is installed on a Raspberry Pi3 itself, so no docker or VMs

I’ve changed the automation now, that seems to actually work. The trigger is no if either from: off or on changes to to: off or on. Hopefully that way any other state changes will be excluded.

My HA had another problem today in the night where lots of things became unavailable, looking at the history of the lamps it seems like while they also became unavailable, the automation didn’t trigger and hence they didn’t get turned on. So issue resolved this way and lessons learned I guess, also think through all the state changes that you actually care about.

Show us your automation’s code.

If you don’t filter on state (on or off) your automation will fire at all states including unknown or unavailable

You can have only one automation, just use multiple triggers, conditions and if/else or choose in action

alias: Schalter Tischecke Lampe
description: ""
  - platform: state
      - light.dimmer2_lampe_wohnzimmer_esstisch_2_2
      - "off"
      - "on"
      - "off"
      - "on"
condition: []
  - service: light.toggle
    data: {}
      entity_id: light.innr_lampe_wohnzimmer_tischecke
mode: single

I think I’ve narrowed it down now, this seems to do the trick nicely to only care about state changed between off and on and ignore any others. My HA went down again this night which caused all entities to become unavailable, and this state change from off->unavailable->off didn’t trigger the automation. Thanks y’all for points me to the right direction!