I moved to HA 2 months ago and sometimes find things don’t go as expected and think nothing of it because I’m still fine tuning. Pareto principle, but 99/1 not 80/20
Anyway. But now I caught HA as it choked and the times before probably did.
I have a room with 2 lamps and 2 exactly the same automation with the only difference of the lamps themselves.
I do not want to talk about my automation, why not one, or groups.
One of my basic concepts is every lamp gets its own rule. No mixing
Summary:
Both lamps should be switched off by their own automation and a common trigger (PIR absent 3m). One automation is running, the other is not. In the trace function of the non-functioning automation, the PIR does not trigger after the said 3 minutes either.
Main Question:
I don’t necessarily want to cling to this problem specifically.
I want to know how the automations behave in parallel operation when e.g. identical things happen at the same time. Is there anything to consider?
I just think about how when I moved my automations to HA in October 2022 I stumbled across the undocumented property of automations that when you save automations the automation engine is restarted and all timers/delays are reset. Figuring this out took me a lot of time and nerves. Always thought my automations had errors. Fortunately this is fixed since 11/2022.
My Setup is a RPi, latest Raspbian lite 32bit and a HA Core Installation 2022.11.5.
Unfortunately, it is not easy to reproduce it. Especially this case I have observed 3 times in 5 weeks.
I will first change the delay of one of the automations to 3m01s.
EDIT:
Sry. I do not know if I have formulated my question correctly.
How can it be that one and the same trigger at the same time triggers only in one automation? In the vast majority of cases (99%) it triggers both automations correctly.
Are there any problems with the processing of this operation? I am not a programmer. I can only try to imagine what is going on. The RPi is not overloaded at all. load average is <0.20 most of the time
Please format code correctly: you might have an indentation error and we can’t tell. Use the </> button.
First step I’d take is to strip out all the device cruft and simplify it (checking that the state of the sensor is on for motion, off for clear):
trigger:
- platform: state
entity_id: binary_sensor.p_schlaf
id: pir_0
from: 'on'
to: 'off'
for:
minutes: 3
I would expect that to work as a simultaneous trigger in as many automations as you want to write.
Is it always the same lamp that fails to come on? Please post the full code of both, properly formatted. We would expect it to work, so the logical hypothesis is that your code has a problem. Without it in full, we cannot eliminate that possibility.
In the first attempt I will start to extend the delay of an automation by 1 second so that both don’t have to trigger at the same time anymore.
and in the second attempt change from “device” to “state”. but here again with 3m0s delay for both automations.
I still have to write an automation that notifies me when one of the two lamps does not turn off.
but i have to ask now why “state” and not “device”?
I have already read many threads and can remember that already once someone wrote “prefer state”. do not know what his reason was.
Using device gives more unnecessary code, more possibilities for problems to creep in. It’s probably not the cause of your problems here, but just makes for simpler, neater code. Also get rid of the zero-time for: block.
I’m confused at what you’re trying to achieve here. You have a motion trigger that turns the light on, then a trigger that fires when the light turns on. The second run might overlap the first, but you’re using mode:single. Try mode: queued instead. Automation modes - Home Assistant
I don’t like device either, because of the device_id.
If you have to change a lamp, you have more work to adjust everything again because of the id. With state you don’t have to do anything in the ideal case, if you don’t make any mistakes when renaming.
zero time is unfortunately generated when working in the visual editor. i always have to switch to the yaml editor and delete zero time by hand.
i was afraid that i would have to justify myself because of my automations.
I’m not sure if you want to hear the answer
in advance:
my lamp control from the push buttons comes directly from deconz/phoscon, because dimming in home assistant is not implemented so nicely.
with action:device:turn_off/turn_on Hue lamps are switched on and off really nice and smooth.
with action:service:light.turn_on/light.turn_off lamps are turned on and off hard. no intermediate steps. only 1/0 - on/off
Transition does not work below a brightness of 5%.
since I want to make sure lamps always have color_temp = 366 (wife and kids play with colors from time to time) and we appreciate the soft on and off, I have to go this way.
The automations:
opt1 is self explaining. if pir on; turn on, set bri + col.-temp.
two steps because of point 2+4
op2 is for adjustments only.
if for example a lamp is switched on by the HA UI, a button on the wall or HomeKit, the brightness (preconfigured/changing variable) and the color_temp should always be corrected.
there is no overlap. transition=1s in option 1 prevents execution of option2 in single mode.
Unfortunately, the problem concerns option 3. pirX has to trigger two automations, but it triggers only one of them in rare cases.
I’m still testing. but through the control automation I detect misbehavior more often and immediately look into the trace function. i’ll get back to you with a summary
I give up! I tried everything and decide my automaton is correct.
This is impossible. how could a off service turn a light on?
and by the way the last action from trace is a turn on service what’s even wrong because the light is off at this moment and a condition blocks tuning on but whatever. the above picture tells me im not able to fix anything.
for me its like this. a bug in the basic functionality that should not exist. and its bold to say its a breaking change. its a bug, a mistake or issue.
its annoying to see how much energy people spent to integrate new devices and functions and forgot it’s about working automation and not to integrate everything just because you can. less is more.
yes im in rage and frustrated
An entity’s state will be reverted if the physical light it represents fails to promptly reply to a transmitted command.
Scenario:
Physical light is on.
Entity representing the physical light is on.
Send turn off command.
Entity representing the physical light is set to off.
Physical light fails to promptly reply that it was turned off.
Entity representing the physical light is set back to on.
This is a common scenario for devices experiencing marginal communications with Home Assistant. Sometimes the transmitted command isn’t received by the target device, or the device’s reply isn’t received by Home Assistant.