Recently I implemented an ESP8266 based 433MHz RF receiver. It updates an MQTT topic (alarm/home/code) when it receives any code from various passive infrared motion sensors, door/window sensors, remotes, etc.
When you are in a room moving about, the PIR motion sensor detects your motion & updates the MQTT topic, causing my automations to run which are triggered as below:
trigger:
platform: state
entity_id: sensor.alarm_code
state: "13612512"
The MQTT topic is updated multiple times for each trigger of the PIR motion sensor, but if it is the same sensor that triggers & sends the code (eg: moving about in the same room over time) even though the code is resent & the topic updated, that code doesn’t change.
The problem is the state trigger appears to need the new state to actually differ from the old state, in order to trigger the automation.
To get around this, I have programmed my ESP8266 to send a blank (’’) update to the MQTT topic & then send the code, so the state trigger detects the change & runs the automation.
I would propose a state_changed trigger (the current state trigger) as well as a state_updated trigger, so you can choose if you only want your automations to run when the state actually changes, or whenever the state is updated.
This would be necessary for instance if an intruder entered the home & spent some time in the one room, unplugging the TV & HiFi. With the current state trigger I would only get one automation run when they enter the room & no more until they trigger another sensor in another room. It would be good to have multiple triggers so I know that they are still in that particular room. It also applies to my presence detection algorithms.
Shouldn’t the ESP send a non motion state when the PIR stops detecting motion? That way you know there’s motion as long as the state is motion. If motion stops and then starts again you will get a new trigger.
I think you can solve your problems by adjusting the trigger settings on the PIR, ie how long it keeps its state until detecting new changes, and by writing your automations to suite your expected behavior.
Unfortunately the PIR only sends a single code when it detects movement & sends nothing once it stops detecting any movement. These sensors are primarily used in conjunction with home alarms, where a single code sent when movement is detected is all they need to trigger the siren.
This behaviour however is unlike the door/window sensors which use a magnet/reed switch combo. They send a code when opening & a different code when closing.
The ESP doesn’t know what device/sensor has sent the code to it, since it is all wireless over 433MHz. It simply updates the MQTT topic each time it receives a new code.
I also have had to filter the codes I act upon in my automations, since I seem to be picking up my neighbours 433MHz alarm sensors too…
With the workaround I posted above I can quite happily move throughout my house, triggering various PIR sensors & having the room lighting turn on when I enter & off as I leave. Home Assistant has been fantastic for integrating all my previously separate systems together & I’d like to help improve it where I can. I think a state updated trigger could benefit a few other situations as well, not just my own.
Reading your post again, you already had the workaround which basically is the same as I suggested. Sorry for not reading properly.
I agree that it would be handy to have a state_updated trigger in some situations.
Have you tried the MQTT trigger? I think that triggers whenever there’s a new message on a topic, or optionally only if the message payload matches the configured payload. You could combine that with a template that checks the payload and code to identify the PIR that was triggered or use the optional payload check and have different triggers and automations.
Yes, I was originally using the MQTT trigger which did suit my current application somewhat. As I was writing it the thought that in the future I may be requiring an automation to run from the state of a sensor that isn’t based around MQTT occurred to me, so I figured I’d post this thread.
It looks like this won’t be too much of an issue though, with these new apps that have just been released. I can see myself migrating my automations over to python very quickly. They can be updated on the fly, that’s a huge advantage not having to restart Home Assistant every time I update a script or automation.
Thanks for your input Martin, as this is the first contact with the community I’ve had it’s nice to see there are helpful people out there!