I have a 433MHz door sensor that sends two codes (one for opened and one for closed). It is being captured by RFLink and espRFLinkMQTT and here is the output:
I can create an automation based on these sensors that would flip the boolean_input.
But what I don’t understand is that once the sensor gets the “ON”, there is nothing to turn it off. I feel like I would still need to add something to set the OPEN sensor to “OFF” when the CLOSED sensor gets an “ON” message?
I want to point out that your code won’t capture the door’s state when HA is not running (reboot etc).
If you don’t mind having yet another MQTT topic, it is possible to do the following:
create an automation with MQTT triggers that will publish the received state (ON/OFF) to a dedicated topic like house/ground_floor/door with retain: true
create a normal MQTT binary sensor for that topic - it will be your door sensor’s state
That way you’ll know the door’s last reported state even if you restart/shutdown your HA for a while (provided your MQTT broker is up and running).
you don’t need sensor.testdoorswitchopen, only bs_testdoorswitch.
you don’t need input_boolean as the data will be stored by MQTT broker.
you do need automations that trigger on state MQTT messages and publish ON/OFF and on “doorswitches/testdoorswitch” with retain: true
That’s why I need sensor.testdoorswitchopen - it reads the MQTT publish for opening since the switch itself sends one topic for open and a different topic for close.
Then I have those automations to do the publish commands for either the open or the close.
I’ve tested the following suggested solution and it works.
Step 1 - Create a binary_sensor to represent your door
Define a simple binary_sensor that subscribes to a “middleman” topic:
- platform: mqtt
name: 'Front Door'
state_topic: tmp/front_door
device_class: door
Restart Home Assistant to load the new binary_sensor.
Step 2 - Create an automation to manage the binary_sensor’s state
Create an automation that subscribes to both of the rflink’s topics. Depending on which topic triggers the automation, it will publish the appropriate state to the “middleman” topic.
After creating the automation, be sure to click Configuration > Server Controls > Reload Automations
Proceed to test and confirm it works properly.
NOTE
The automation disregards the received payload. All it cares about is which of the two topics triggered it.
If the topic’s name ends with the letter 'a' then that’s the topic (SelectPlus-065afa) responsible for indicating when the door is open so the automation publishes ON.
If the triggering topic’s name doesn’t end with 'a' (meaning it was triggered by SelectPlus-065af8) then it publishes OFF.
If you know the topic’s payload should NOT be ignored (perhaps because it not only reports CMD: ON but also CMD: OFF) then let me know and we can adjust the automation.
EDIT
Simplified the suggested solution; it no longer relies on a python_script.
well, it does not seem to keep the last state after HA reboot, does it?
and as the mqtt sensor is subscribed to a dummy topic, maybe it can be replaced with a template sensor or something more basic?
actually, going this route we arrive to the beginning of this story - it’s easier to use input_boolean + mqtt automation, no need for python_script.set_state and the last state will survive HA restart. If needed, input_boolean can be wrapped with binary template sensor.
No, you were right, the binary_sensor failed to maintain its state after a restart. Thanks for bringing that to my attention because, after reviewing my entire approach with fresh eyes, I was not only able to fix the deficiency, I simplified the solution.
It no longer relies on a python_script. The automation simply publishes the appropriate state to the binary_sensor’s topic (as a retained message). Easy-peasy.
I don’t know about “by design” but what I overlooked to take into account (in the first version I had posted) was that on startup the binary_sensor would look to its state_topic to determine its current state. The topic has no message so Home Assistant sets the binary_sensor’s state to off by default.
In the revised version, the automation no longer uses python_script.set_state and opts for publishing a retained message to the binary_sensor’s state_topic. This effectively stores the binary_sensor’s value. On startup the binary_sensor acquires this retained message and so its state is restored to whatever it was prior to restart.
I have a bunch of MQTT Sensors and MQTT Binary_Sensors configured like this and yet I managed to forget all about it when I created the original suggestion!
The code worked for me but I had to make a change to the binary_sensor to add the payload values.
- platform: mqtt
name: "TestDoorSwitch State"
state_topic: "doorswitches/testdoorswitch"
device_class: door
payload_on: on
payload_off: off
payload_available: "online"
payload_not_available: "offline"
Prior to this change, I was getting these errors in the log and it was not changing the state when I moved the switch back and forth.
2020-03-17 18:14:51 INFO (MainThread) [homeassistant.components.automation] Executing testdoorswitch-opened
2020-03-17 18:14:54 INFO (MainThread) [homeassistant.helpers.script] Script testdoorswitch-opened: Running script
2020-03-17 18:14:54 INFO (MainThread) [homeassistant.helpers.script] Script testdoorswitch-opened: Executing step call service
2020-03-17 18:14:55 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: TestDoorSwitch State with state topic: doorswitches/testdoorswitch. Payload: True, with value template None
After I added the payload items then it worked just fine. However, I did not try restarting HA to see if it retained the messages. I will have to give that a try and report back.
I recommend you try the example I posted above. The binary_sensor’s configuration is far simpler (uses default values) and it requires only one automation.
