Thanks, I added the quotes, but still the same i just walked around the pir detector 3 time the light didn’t turn on just at the fourth time, maybe it’s a network latency issue 
I think it is equivalent to AND, the automation works, it turns the switch in the interface but not physically
Weird, because an AND condition is supposed to be formatted like this:
condition:
condition: and
conditions:
- condition: state
entity_id: 'group.g_shai_tracker'
state: 'home'
- condition: state
entity_id: 'group.g_alina_tracker'
state: 'home'Review your logbook. You should see the PIR sensor turn on 4 times and the automation trigger 4 times. If the PIR sensor isn’t triggering each time you have a seperate issue and not an automation issue. If your PIR is triggering 4 times but the automation didn’t trigger 4 times there is something holding it up.
The logbook is very helpful when diagnosing automation issues, however, if not trimmed down it can be a lot to sift through to get the data you want.
The automation triggers every time, for some strange reason it seems to be working better and more stable now
Thanks for helping!
A single condition can be formatted like this.
condition:
- condition: state
entity_id: group.g_shai_tracker
state: 'home'
Maybe its working if that first condition is met.
I would try the proper and format.
2 Likes
Sorry, my mistake, It’s Equivalent to OR it’s met if one of the groups state is ‘home’
Damn, It’s not working again, Same issue, the automation trigger i see it in the HASS interface, when triggering it manually the light turns on
I still don’t see how you can format it the way you have and not get an error in the logs about it. If you are using a current build, it should be:
condition:
condition: or
conditions:
- condition: state
entity_id: 'group.g_shai_tracker'
state: 'home'
- condition: state
entity_id: 'group.g_alina_tracker'
state: 'home'I can try it but it is not the problem, i see the trigger was executed, it’s like it doesn’t call the service
But it should generate an error without the proper formatting and I don’t understand why it isn’t. If it isn’t something is wrong as that formatting error should be excepted and caught. So that’s a bug for sure.
Remember there are three parts to this - the trigger, the conditions and the service. You can trigger it manually all day long, but if the conditions aren’t being met properly it won’t pass on to the trigger. So I think this could still be a contributing cause. Just sayin.
Again, I am personally more interested in why your formatting doesn’t generate an error. It should. And that is cause for a bug report IMO.
I tried your suggestion it works exactly the same as the syntax i used, the trigger triggers but it look like it doesn’t call the service the weird thing is when i manually click the automation trigger it executes and the light turns on
Just a thought - Check your sensor in dev states. Is it “on” or “On”? Case matters and I missed this once myself.
(I’m not giving up until you do. LOL Committed to helping you.)
Thanks so much for taking the time and for your patience i really appreciate it!
I have a simple one state 433Mhz pir sensor, I use the OpenMQTTGateway I can see the messages in MQTT broker.
The PIR sensor works fine the state is changing from on to off after 10 seconds like it should (I use an automation to change it from on to off after 10 seconds)
I see the light switch turn yellow in the HASS interface and that the automation was triggered
The light turns on without a problem from Alexa/manually/clicking the switch in HASS/clicking on the automation trigger
The conditions are not important because the same issue occurs when there are no conditions at all.
My configuration file is splitted
binary_sensor.yaml configuration:
- platform: mqtt
name: "Study room Motion Sensor"
qos: 0
state_topic: "home/433toMQTT"
payload_on: "2645158"
payload_off: "2645158off"
device_class: motion
My automations.yaml configuration:
- alias: 'Study room Motion Sensor Off Timer'
initial_state: 'on'
trigger:
platform: state
entity_id: binary_sensor.study_room_motion_sensor
to: 'on'
for:
seconds: 10
action:
service: mqtt.publish
data:
topic: 'home/433toMQTT'
payload: '2645158off'
retain: 'true'
- alias: Study room Motion Sensor Light ON
initial_state: 'on'
trigger:
platform: state
entity_id: binary_sensor.study_room_motion_sensor
to: 'on'
condition:
- condition: state
entity_id: group.g_shai_tracker
state: 'home'
- condition: state
entity_id: group.g_alina_tracker
state: 'home'
action:
service: switch.turn_on
entity_id: switch.study_room_light
You can see in the screenshots that the automation worked (for the interface at least) but the light didn’t turned on
@rpitera OK, I think i found a workaround for this issue, i have done some testing and so far so good
I’m calling the service twice with a delay of 1 second
- alias: Study room Motion Sensor Light ON
initial_state: 'on'
trigger:
platform: state
entity_id: binary_sensor.study_room_motion_sensor
to: 'on'
condition:
- condition: state
entity_id: group.g_shai_tracker
state: 'home'
- condition: state
entity_id: group.g_alina_tracker
state: 'home'
action:
- service: switch.turn_on
entity_id: switch.study_room_light
- delay: 00:00:01
- service: switch.turn_on
entity_id: switch.study_room_light
1 Like
I would post an issue in Github so you can see why this workaround works and if it’s a bug or not. I confess that I have had the same issue with some cUrl commands I send to my Foscams and I ended up using the same workaround; namely sending the commands twice.
I’m glad you found a hack but I’m sorry I couldn’t have been more helpful.
Just upgraded to 0.48 and guess what ?
It’s not working again…lol…
Shit.
BTW, I just realized it was a release week and was looking at the notes when you replied.
Is your sensor a Zwave device? Did you put in the option to use the old entity names?
That might be it.
No it’s a binary mqtt sensor component and my pie sensor is rf
Just a thought.
I’m upgrading here, let me see if anything pops out…