I am using HASSIO 0.89.1 on raspberry, I am not able to find : home-assistant-homeassistant:/usr/src/app/homeassistant/components/mqtt/binary_sensor.py
how did you do it?
Thank you very much.
I was able to imported on nodred, was the quotes used are not valid, I found the following: A flow must be valid json in order to import. You can paste it into https://jsonlint.com to see what errors are detected. after changing the quotes to " now is working
Since v0.89.0-ish custom-components requires all component files, the workaround is unusable especially when uploading via Configurator.
Iāve added a new issue (https://github.com/home-assistant/home-assistant/issues/22172)
I was finally able to apply the patch suggested, but I copied all under MQTT for v0.9 under my custom-folder then commented those 4 lines in binary_sensor.py suggested by kanga_who, this was after successfully using nodRed suggestion by jwoodard80 but in my case having many rf senseros, it was just cleaner doing this directly with the binary_sensor.yaml, I downloaded ver 0.9 from https://github.com/home-assistant/home-assistant/releases and from the home-assistant-0.90.0.zip file i copied the complete mqtt folder inside homeassistant/components/ folder into my custom_components folder, them comment the 4 suggested lines, and I have no more warnings when I have an RF sensor, triggering in a different mqtt bibary_sensor. but fully agree with wmrato this should be reverted on the official release and not being patched
Hi all.
Iām running 0.90.1 and Iāve used @kanga_who suggestion but itās not working. I still have many errors.
Iāve put in the ācustom_componentsā folder an additional folder named āmqttā and inside Iāve placed the ābinary_sensor.pyā file with the 4 lines commented.
What am I doing wrong ?!?
I offer another solution to prevent the āNo matching payloadā message from appearing.
For an MQTT Binary sensor, the default for payload_on is ON and for payload_off itās OFF (i.e. uppercase). On the other hand, the state of a binary_sensor can either be on or off (i.e. lowercase). Keeping this important distinction in mind, we can use it to construct a value_template that ensures the payload always matches something and never nothing.
This example assumes Data=2C8D0A indicates the door is open and Data=2C8D0E indicates the door is closed. Hereās the important part, if the payload contains neither 2C8D0A or 2C8D0E, it reports the binary_sensorās current state. In other words, no matter what it receives in the payload, the value_template always reports a valid state.
- platform: mqtt
name: 'Bathroom Door'
state_topic: 'tele/RF_Bridge/RESULT'
value_template: >-
{% if value_json.RfReceived.Data == '2C8D0A' %}
{{'ON'}}
{% elif value_json.RfReceived.Data == '2C8D0E' %}
{{'OFF'}}
{% else %}
{{states('binary_sensor.bathroom_door') | upper}}
{% endif %}
device_class: Door
If you have a sensor that does not report an off state then you can compensate by using the off_delay option.
In this example, Data=E5D30E indicates the motion sensor is on but thereās no command available to indicate when the sensor is off. I have set off_delay: 15 so the motion sensor will automatically set itself to off after 15 seconds.
- platform: mqtt
name: 'Hallway Motion'
state_topic: 'tele/RF_Bridge/RESULT'
value_template: >-
{% if value_json.RfReceived.Data == 'E5D30E' %}
{{'ON'}}
{% else %}
{{states('binary_sensor.hallway_motion') | upper}}
{% endif %}
off_delay: 15
device_class: motion
8 Likes
I have the same problem, but I can not resolve with off_delay function.
Iām using it for alarming ON and alarming OFF.
So delay is not option, because I can not turn OFF alarm by time, but need to read OFF dataā¦
Maybe (I will try this week) my solution for alarming is allways to use ON function but with diferrent received dataā¦ based on that maybe I can do actionā¦ will seeā¦
I agree. The example I provided was applicable for a motion sensor.
Your situation requires turning an Alarm on and off. Obviously any time-based solution to turn it off is inappropriate.
I donāt see how you can do what you need using a single RF button that sends one state. You would need to use two such buttons, one to set Alarm to on and another button to set the Alarm to off.
Iām using 2 alarms in HA, one with DSC and one with HA.
For HA Iām using button A and button B, for DSC Iām using button C and button D.
I have RF key with 4 buttonsā¦ The problem is that now Iām using 2 Sonoff RF bridge receives, so I must figure how to manage thisā¦ but firstly RF bridge No.1 must be working to turn ON/OFF (currently only ON is working - before was working all fine)ā¦ I will report with code how I did itā¦
Are you getting āNo matching payload found for entityā WARNING messages in your log?
Yesā¦ But before 0.90.x was working fineā¦
Thatās the story of Home Assistant in a nutshell.
I took another route to āsolveā this issue/limitation.
Iāve created a flow in NodeRed for each sensor that listen on the common MQTT topic (letās say ā/home/OpenMQTTGateway/433toMQTTā) and then publishes āonā/āoffā to a topic dedicated to that specific sensor based on the RF codes.
Here is one of the flows:
[{"id":"e888d4cc.d27748","type":"mqtt in","z":"36c2f961.cc6cc6","name":"","topic":"home/OpenMQTTGateway/433toMQTT/#","qos":"0","datatype":"auto","broker":"6398ff0c.afd62","x":160,"y":230,"wires":[["d77d794e.908848"]]},{"id":"d77d794e.908848","type":"json","z":"36c2f961.cc6cc6","name":"value","property":"payload","action":"","pretty":false,"x":160,"y":280,"wires":[["291ede36.c1bf02"]]},{"id":"291ede36.c1bf02","type":"function","z":"36c2f961.cc6cc6","name":"Vlad DoorA","func":"value = msg.payload.value.toString();\nif (value == \"3169034\") {\n msg.payload = \"on\";\n return msg;\n} else if (value == \"3169038\") {\n msg.payload = \"off\";\n return msg;\n} else {\n return null;\n}\n","outputs":1,"noerr":0,"x":360,"y":280,"wires":[["32e87ea3.ff8ad2"]]},{"id":"32e87ea3.ff8ad2","type":"mqtt out","z":"36c2f961.cc6cc6","name":"","topic":"/home/sensor/door/vladrooma","qos":"1","retain":"false","broker":"6398ff0c.afd62","x":650,"y":280,"wires":[]},{"id":"6398ff0c.afd62","type":"mqtt-broker","z":"","name":"mosquitto-hassio","broker":"localhost","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""}]I am on 0.90.1 and the only way to make it works is to copy the entire folder /components/mqtt from the source code and copy it to custom_components/ commenting the LOGGER lines on binary_sensor.py
I think copying only the file binary_sensor.py does not works because of dependencies.
With the full folder I am getting warnings override for: mqtt.switch, mqtt.sensor, mqtt.light and the one we need mqtt.binary_sensor
Your solution is what I offered to someone else in this thread. I used an automation but the principle is the same, namely you create a ādemultiplexerā. Payloads from the single topic are re-published into individual topics.
home/rtl_433 ==> DEMUX ----> home/sensor1
|
|---> home/sensor2
|
|---> home/sensor3
|
|---> home/sensor4
|
|---> home/sensor5
home/sensor1 ==> Sensor1
home/sensor2 ==> Sensor2
home/sensor3 ==> Sensor3
home/sensor4 ==> Sensor4
home/sensor5 ==> Sensor5
I also posted the demultiplexer automation in the same thread. Itās for payloads from rtl_433 but easily adapted for other RF bridges.
BTW, if you are using OpenMQTTGateway, thereās a post within this thread, by @1technophile , explaining how to make it publish to one topic per sensor. If you make his suggested modification, thereās no need for demultiplexing.
EDIT
Hereāsanother example of demultiplexing and is for a Tasmota-based Sonoff RF Bridge and assumes Sync contains a unique identifier for each RF button.
Iām using 0.90.1 and can confirm that the solution I provided above does not need a custom MQTT component. My MQTT binary_sensor is using the 0.90.1 release version of the MQTT component and, with my suggested solution, the sensors do not cause the āNo matching payload ā¦ā message to appear.
BTW, if you are using OpenMQTTGateway , thereās a post within this thread, by @1technophile , explaining how to make it publish to one topic per sensor. If you make his suggested modification, thereās no need for demultiplexing.
Well, itās one topic per value as far as I understood. I have a door sensor that sends 2 codes, and I would need a binary_sensor subscribed to these 2 topics (can this even be done?).
Anyway, the demultiplexer solution gives me more control and with less configuration in home assistant.
I may have stumbled upon your post about the automation demultiplexer while trying to figure this out and this was what inspired me to go this route.
So, for that, I want to say thanks 
1 Like
I also use Node-red and, when I first encountered this issue, my first thought was to create a flow to demultiplex the MQTT topic. Then I challenged myself to create an automation to do it ā¦ and it was easier than I thought. Whether Node-red or an automation, as long as it gets the job done.
Apparently that ātopic per valueā approach is best suitable suitable for one-code devices.
But in a case like yours thereās still hope.
For example, you can create 2 automations (each subscribe to its topic) that change state of an input_boolean, and a template sensor that reflects its state if you prefer something fancier that a toggle switch in your GUI.
I havenāt tired it yet (too many devices to convert), but it should work.
I believe there are other ways to do that, anyone?
If not upgrading that often, can still do brain surgery with a hammer and modify the binary_sensor.py directly in the site-packages folder It will be overwritten each time a new HA version is installed, though.
Best way to solve this is to reverse the PR that introduced the warning in the first place.