SOLVED: Hmm, trying to use tasmotized sonoff rf bridge

[fribse (Kenneths Teknik)]

I’ve flashed a sonoff rf bridge with tasmota following @DrZzs excellent videos, I’ve created a Home Assistant User for mqtt, which I’ve entered into the config of the rf bridge.
Looking at the bridge’s console, I can see the sensor events being generated.

It shows like this:

15:14:38 MQT: tele/rfbridge/RESULT = {"RfReceived":{"Sync":14110,"Low":480,"High":1380,"Data":"12345E","RfKey":"None"}}
15:14:54 MQT: tele/rfbridge/RESULT = {"RfReceived":{"Sync":14040,"Low":480,"High":1390,"Data":"12345A","RfKey":"None"}}
15:15:04 APP: Serial logging disabled
15:15:19 MQT: tele/rfbridge/STATE = {"Time":"2019-06-03T15:15:18","Uptime":"0T00:10:19","Vcc":3.141,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":28,"Wifi":{"AP":1,"SSId":"SSID","BSSId":"","Channel":1,"RSSI":100,"LinkCount":1,"Downtime":"0T00:00:04"}}
15:15:47 MQT: tele/rfbridge/RESULT = {"RfReceived":{"Sync":14060,"Low":480,"High":1380,"Data":"12345E","RfKey":"None"}}
15:15:53 MQT: tele/rfbridge/RESULT = {"RfReceived":{"Sync":14100,"Low":480,"High":1390,"Data":"12345A","RfKey":"None"}}

For me as an unexperienced, that looks ok.

Looking in Mosquitto log (not quiet logs)

1559571293: |-- mosquitto_auth_acl_check(..., client id not available, homeassistant, tele/rfbridge/RESULT, MOSQ_ACL_READ)
1559571293: |-- aclcheck(homeassistant, tele/rfbridge/RESULT, 1) CACHEDAUTH: 0
1559571318: |-- mosquitto_auth_acl_check(..., client id not available, usermqtt, tele/rfbridge/STATE, MOSQ_ACL_WRITE)
1559571318: |-- url=http://127.0.0.1:8080/superuser
1559571318: |-- data=username=usermqtt&password=&topic=&acc=-1&clientid=
1559571318: |-- aclcheck(usermqtt, tele/rfbridge/STATE, 2) SUPERUSER=Y by http
1559571318: |--  Cached  [E38221D75E70ACACA6850D2A744F72719044E46F] for (client id not available,usermqtt,2)
1559571347: |-- mosquitto_auth_acl_check(..., client id not available, usermqtt, tele/rfbridge/RESULT, MOSQ_ACL_WRITE)
1559571347: |-- aclcheck(usermqtt, tele/rfbridge/RESULT, 2) CACHEDAUTH: 0
1559571347: |-- mosquitto_auth_acl_check(..., client id not available, homeassistant, tele/rfbridge/RESULT, MOSQ_ACL_READ)
1559571347: |-- aclcheck(homeassistant, tele/rfbridge/RESULT, 1) CACHEDAUTH: 0
1559571353: |-- mosquitto_auth_acl_check(..., client id not available, usermqtt, tele/rfbridge/RESULT, MOSQ_ACL_WRITE)
1559571353: |-- aclcheck(usermqtt, tele/rfbridge/RESULT, 2) CACHEDAUTH: 0
1559571353: |-- mosquitto_auth_acl_check(..., client id not available, homeassistant, tele/rfbridge/RESULT, MOSQ_ACL_READ)
1559571353: |-- aclcheck(homeassistant, tele/rfbridge/RESULT, 1) CACHEDAUTH: 0

Again, as a completely inexperienced mqtt user, I think this looks ok, not really sure about the ‘cliend it not available’ thing.

So I made some binary sensors:

• platform: mqtt
  state_topic: “tele/rfbridge/RESULT”
  name: “Entré dør”
  value_template: ‘{{value_json.RFReceived.Data}}’
  payload_on: “12345A”
  payload_off: “12345E”
  device_class: door
  qos: 1

But I don’t see the state change in Home Assistant? Can anybody enlighten the dimwitted?

[DeadEnd]

@fribse

mosquitto_auth_acl_check(…, client id not available …

I haven’t used your setup, but from that log, it looks like the clients are not connecting to your mosquitto. They are being denied access.

You can use an mqtt client for your PC and subscribe to # to see all topics on your MQTT broker. Use this to see if the RF bridge messages are actually getting posted to MQTT first.

I have a feeling both RF bridge and HA are not being allowed.
Two fixes for this I can think of:

1. you either need to remove the auth requirement (allow anonymous logins) on your broker, OR
2. you need to add/check/confirm that the logins you are using are setup correctly on the broker.

Good luck!
DeadEnd

[DeadEnd]

Here is a post that looks to cover the same issue.
They might have a solution that works for you.

Mosquito update 4.1 - ACL messages in logs

It’s not a breaking change and didn’t break anything for my system… Perhaps instead of ranting you can post the broker config here?

post #44 has some instructions on how one person fixed it.

Another post on it… they fixed it by removing the manual configuration, and enabling discovery instead.

Sonoff MQTT - Client id not available

Can anyone help me understand what’s going on here? I have two Sonoffs TH 10’s connected to my network and both setup in HA (Hass.io) running on RPI 3B+ Both are visible on the network and can be controlled from the Tasmota GUI. In HA, I’m having problems with one of the switches. (sonoff_3270). When I use the toggle button in the HA GUI the Sonoff will turn on and the state in HA changes to ON. However when I try to turn it off again the switch will toggle to the off position and then back …

[fribse (Kenneths Teknik)]

Thankyou, I’ve now tried going with anonymous, and it still doesn’t work.
So I’ve removed the mosquitto to try and add it in again.

I only have the ‘battery alert’ package, and now the rf bridge on tasmota, so it’s not a big deal.
If I subscribe with the username and password I’ve also given the rfbridge to # I can see a lot of messages about the battery monitor, which sort of drowns out the rfbridge.
So I made a subscribtion to “tele/rfbridge/RESULT”, and there I see the data appear:

{“RfReceived”:{“Sync”:14170,“Low”:480,“High”:1390,“Data”:“12345E”,“RfKey”:“None”}}

So for me it looks like mosquitto does receive it.
If I look under integrations->mosquitto broker I can see all the battery sensors, but not the bridge, did I miss a step somewhere?

[DeadEnd]

@fribse

So for me it looks like mosquitto does receive it.

Yes, if you are seeing the topic being published, then everything before HA sounds like it is working.
If you have battery sensors that are working in HA too, then I would say it isn’t the broker setup in HA either. It is sounding like the configuration.yaml is incorrect.

Can you check and confirm that what you have is within the binary sensor section? It by chance it is in another portion of the configuration.yaml then that would explain it. If possible can you post your configuration.yaml (clean out any confidential information) and make sure to put three ` above and below so it is displayed correctly in the forum.

I think your issue is just in the configuration.yaml… alternatively, if you have discovery turned on, you could just comment it out, and see if HA automatically creates it for you.

DeadEnd

[fribse (Kenneths Teknik)]

Ok, the config for the binary sensors looks like this:

binary_sensor:
  - platform: command_line
    name: 'Flightradar24 radar'
    command: curl 192.168.1.14:8754/ > /dev/null && echo on || echo off
    scan_interval: 180
    payload_on: "on"
    payload_off: "off"
  - platform: meteoalarm
    country: 'DK'
    province: 'København og Nordsjælland'
    language: 'da'
  - platform: command_line
    name: 'FR24 alive'
    command: curl -X GET http://192.168.1.14:8754 > /dev/null && echo on || echo off
    scan_interval: 60
    payload_on: "on"
    payload_off: "off"
  - platform: command_line
    name: 'Dump1090 alive'
    command: curl -X GET http://192.168.1.14 > /dev/null && echo on || echo off
    scan_interval: 60
    payload_on: "on"
    payload_off: "off"
  - platform: command_line
    name: 'NAS853A alive'
    command: curl -X GET http://192.168.1.27:1352 > /dev/null && echo on || echo off
    scan_interval: 60
    payload_on: "on"
    payload_off: "off"
  - platform: command_line
    name: 'NAS659 alive'
    command: curl -X GET http://192.168.1.26:1357 > /dev/null && echo on || echo off
    scan_interval: 60
    payload_on: "on"
    payload_off: "off"
  - platform: command_line
    name: 'Mail (POA) alive'
    command: curl -X GET http://192.168.1.3:7180 > /dev/null && echo on || echo off
    scan_interval: 60
    payload_on: "on"
    payload_off: "off"
  - platform: command_line
    name: 'Mail (MTA) alive'
    command: curl -X GET http://192.168.1.3:7181 > /dev/null && echo on || echo off
    scan_interval: 60
    payload_on: "on"
    payload_off: "off"
  - platform: command_line
    name: 'Mail (GWIA) alive'
    command: curl -X GET http://192.168.1.3:9850 > /dev/null && echo on || echo off
    scan_interval: 60
    payload_on: "on"
    payload_off: "off"
  - platform: command_line
    name: 'Mail (Antispam) alive'
    command: curl -X GET http://192.168.1.9 > /dev/null && echo on || echo off
    scan_interval: 60
    payload_on: "on"
    payload_off: "off"
  - platform: command_line
    name: 'Survaillance alive'
    command: curl -X GET https://www.domain.dk:8888/cgi-bin/surveillance/index.html > /dev/null && echo on || echo off
    scan_interval: 60
    payload_on: "on"
    payload_off: "off"
  - platform: mqtt
    state_topic: "tele/rfbridge/RESULT"
    name: "Entré dør"
    value_template: '{{value_json.RFReceived.Data}}'
    payload_on: "12345A"
    payload_off: "12345E"
    device_class: door
    qos: 1
  - platform: mqtt
    state_topic: "tele/rfbridge/RESULT"
    name: "Køleskabs dør"
    value_template: '{{value_json.RFReceived.Data}}'
    payload_on: "54321A"
    payload_off: "54321A"
    device_class: cold
    qos: 1

[DeadEnd]

Thanks!
I don’t see any of the battery sensors you mentioned earlier.
These are also using the RF-bridge?
Are they setup in your configuration.yaml file?

So far the only thing I see that is off is that for your sensor “Køleskabs dør” both payloads are the same.
I expect this sensor will have a problem due to this - but I would expect these two MQTT sensors to be shown even with this error.

[fribse (Kenneths Teknik)]

No, the battery sensor thing made by @NotoriousBDG uses MQTT to create and maintain the sensors, so that I don’t have to define them one by one, that’s a very cool thing, but a different topic
All the binary sensors defined do show up in the UI, just not change in state for the mqtt ones.

Oh, the payload thing, yes, well, due to the anonymizing that slipped, sorry

[fribse (Kenneths Teknik)]

Hey, did I clean up something in the configuration?
I don’t see an mqtt entry anywhere, or is that not supposed to be there with the later versions of HA?

[DeadEnd]

@fribse

I don’t see an mqtt entry anywhere

That would be a problem
I assumed that since you have the battery sensors working it was setup - but it sounds like they are going through some other system and being sent to HA through some other means…

CORRECTION (to my earlier comment):
I think this might depend on how you have the mqtt broker setup.
Since you said the integration menu in HA shows MQTT - you previously were only using auto discovery for entities. Adding “mqtt:” to your configuration.yaml allows manually configured devices.

SO - if you remove or comment out what you have in your configuration.yaml, the two devices could be automatically discovered.
Or you need to add “mqtt:” and its associated fields to your configuration.yaml to enable the manual configuration.

I hope that makes sense… and that I’m not completely wrong
It’s a little confusing since there are multiple ways to do it.

[DeadEnd]

One other question - are you getting anything in the HA log?
There might be something there to shed some light on the problem.

[fribse (Kenneths Teknik)]

You are right, there is something in the HA log:

2019-06-03 18:59:51 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'dict object' has no attribute 'RFReceived' (value: {"RfReceived":{"Sync":14200,"Low":480,"High":1390,"Data":"312B0E","RfKey":"None"}}, template: {{value_json.RFReceived.Data}})
2019-06-03 18:59:51 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: entry door with state_topic: tele/rfbridge/RESULT
2019-06-03 18:59:51 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'dict object' has no attribute 'RFReceived' (value: {"RfReceived":{"Sync":14200,"Low":480,"High":1390,"Data":"12345E","RfKey":"None"}}, template: {{value_json.RFReceived.Data}})
2019-06-03 18:59:51 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: fridge door with state_topic: tele/rfbridge/RESULT
2019-06-03 18:59:54 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'dict object' has no attribute 'RFReceived' (value: {"RfReceived":{"Sync":14150,"Low":480,"High":1390,"Data":"12345A","RfKey":"None"}}, template: {{value_json.RFReceived.Data}})
2019-06-03 18:59:54 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: entry door with state_topic: tele/rfbridge/RESULT
2019-06-03 18:59:54 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'dict object' has no attribute 'RFReceived' (value: {"RfReceived":{"Sync":14150,"Low":480,"High":1390,"Data":"12345A","RfKey":"None"}}, template: {{value_json.RFReceived.Data}})
2019-06-03 18:59:54 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: fridge door with state_topic: tele/rfbridge/RESULT
2019-06-03 19:00:06 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'dict object' has no attribute 'RFReceived' (value: {"RfReceived":{"Sync":14100,"Low":490,"High":1380,"Data":"12345E","RfKey":"None"}}, template: {{value_json.RFReceived.Data}})
2019-06-03 19:00:06 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: entry door with state_topic: tele/rfbridge/RESULT
2019-06-03 19:00:06 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'dict object' has no attribute 'RFReceived' (value: {"RfReceived":{"Sync":14100,"Low":490,"High":1380,"Data":"12345E","RfKey":"None"}}, template: {{value_json.RFReceived.Data}})
2019-06-03 19:00:06 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: fridge door with state_topic: tele/rfbridge/RESULT
2019-06-03 19:00:14 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'dict object' has no attribute 'RFReceived' (value: {"RfReceived":{"Sync":14260,"Low":480,"High":1390,"Data":"12345A","RfKey":"None"}}, template: {{value_json.RFReceived.Data}})
2019-06-03 19:00:14 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: entry door with state_topic: tele/rfbridge/RESULT
2019-06-03 19:00:14 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'dict object' has no attribute 'RFReceived' (value: {"RfReceived":{"Sync":14260,"Low":480,"High":1390,"Data":"12345A","RfKey":"None"}}, template: {{value_json.RFReceived.Data}})
2019-06-03 19:00:14 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: fridge door with state_topic: tele/rfbridge/RESULT

So that looks interesting (I also tried renaming the entities to english words, to make sure that there were no problems with danish characters.

[DeadEnd]

Can you try something… (after reviewing, the second suggestion - white space - is more likely the issue… single vs double quotes is only an issue when you have both)

Change the single quotes:

value_template: ‘{{value_json.RFReceived.Data}}’

to double quotes?

value_template: “{{value_json.RFReceived.Data}}”

I don’t know the code and how it handles syntax… but I’ve found other users solved this issue by doing this… random, but might work.

The only other thing i see is that many examples have a single white space between the brackets and the value… so you could also do this if the above doesn’t work (I so far only found that it is required for Jinja2… but I have zero knowledge of it).

value_template: “{{ value_json.RFReceived.Data }}”

DeadEnd

[fribse (Kenneths Teknik)]

Darned, I tried both, a space and double quotes.

[wseay (Walter Seay)]

Doing this from work, so I may edit later. But I can relate to your frustration. Here is how I was able to pull a Weather Sensor via MQTT.

- platform: mqtt
  state_topic: "rtl433/sensor/Acurite_5n1_sensor/49"
  name: "Wind Direction"
  value_template: '{{ value_json.wind_dir }}'

So your value_template would be:

- platform: mqtt
  state_topic: "<your topic>/RFReceived"
  name: "Your Sensor Name"
  value_template: '{{ value_json.Data }}'

[123 (Taras)]

@fribse

No matching payload found for entity

You are getting these errors because the RF bridge uses one topic to represent the states of many sensors (a bad practice). That means each sensor receives its values from that one topic as well as the values intended for other sensors.

One of your sensors expects to receive these two values:

    payload_on: "12345A"
    payload_off: "12345E"

However, it can also receive values used by the other sensor:

    payload_on: "54321A"
    payload_off: "54321A"

So when it receives the other sensor’s values they don’t match either payload_on or payload_off so Home Assistant reports:

No matching payload found for entity

The solution is to use a template. See ‘Strategy 1’ in the following post:

Sonoff RF Bridge. Strategies for receiving data

Here are two strategies for receiving payloads published by a Sonoff RF Bridge (flashed with Tasmota firmware). Strategy 1: value_template In this strategy, all sensors are subscribed to the same topic published by the RF Bridge. The topic's structure depends on how you defined it when you configured *your* RF Bridge. This example will use `tele/RF_Bridge/RESULT`. Change that to whatever you have set for your Bridge. Because all sensors are subscribed to the same topic, a sensor will receive pa…

Your sensor configuration will look like this example:

- platform: mqtt
  name: 'Entré dør'
  state_topic: 'tele/rfbridge/RESULT'
  value_template: >-
    {% if value_json.RfReceived.Data == '12345A' %}
      {{'ON'}}
    {% elif value_json.RfReceived.Data == '12345E' %}
      {{'OFF'}}
    {% else %}
      {{states('binary_sensor.entre_dor') | upper}}
    {% endif %}
  device_class: door

NOTE
I’m not sure how Home Asssitant converts “Entré dør” into an entity_id so I used binary_sensor.entre_dor. You may need to modify that in the example I provided.

[DeadEnd]

Thanks @123!
I’m still new around the system and didn’t even realize he was using the same topic for multiple sensors (and the effect it would cause). Now that you point it out it makes complete sense!

I’m using a SDR connected via USB, so I don’t have this issue. Glad you pointed it out - I’ll remember it next time I’m trying to help someone

[fribse (Kenneths Teknik)]

@123

• platform: mqtt name: ‘Entré dør’ state_topic: ‘tele/rfbridge/RESULT’ value_template: >- {% if value_json.RfReceived.Data == ‘12345A’ %} {{‘ON’}} {% elif value_json.RfReceived.Data == ‘12345E’ %} {{‘OFF’}} {% else %} {{states(‘binary_sensor.entre_dor’) | upper}} {% endif %} device_class: door

You are absolutely right, and it works like a charm now, it did translate it to entre_dor. Ok, so becuase the RF bridge only has one topic, it is compensated for in HA, that is a very cool solution.
Thankyou @123 for the solution, and thankyou @DeadEnd and @wseay for the debugging, I’ve learned a lot!