Sonoff rf bridge: "Post processing" received codes to produce more meaningful MQTT events

[Steve Davies]

Hi Home Automatiion hackers,

Tasmota on the RF Bridge does a good job of converting received rf codes into MQTT messages.

But it doesn't know anything about the devices sending those messages - just passes on what it receives.

This often means that automations in HomeAssistant are needed in order to do things like "turn off again after 5 seconds" 

What about another layer in Tasmota that offers some common post-processing options like this?

My ideal would be that each RF device ends up publishing to its own MQTT topic - so something like /home/pirlounge with {"motion":1}, and then after a few seconds automatically a /home/pirlounge with {"motion":0}.  

A DHT22 or similar hacked onto a Sonoff Basic could similarly get its own topic by the same approach.

But of course to do this Tasmota would need quite a lot more code to match rf "Data"s to device, etc.

Perhaps another idea is to have some external program that reads the RfReceived messages published by the bridge, processes them and pushes the post-processed codes back into MQTT for Homeassistant or NodeRed.

I know that MQTT433gateway produces this sort of event because it uses ESPILight library which has this sort of parsing.  But in that case I think that you lose the simple raw version.  So it would be great to have a bit of both on top of the nice Tasmota environment. 

I'm interested in comments,

Thanks,

Steve

[Piotr Antczak]

How about rules?

on RfReceived#Data do

backlog publish /home/%value% {"motion":1};delay 50;publish /home/%value% {"motion":0}

endon

or something like this:

on RfReceived#Data=<code_sent_by_your_pir_sensor> do

backlog publish /home/pirlounge {"motion":1};delay 50;publish /home/pirlounge {"motion":0}

endon

where %value% will be the rf code sent by your device (the code received by RF Bridge) and "delay 50" is "wait 5 seconds" 

[Phil]

my approach using node red has been to subscribe to the bridge events and on receipt of a known code process the flow accordingly. 

seems to work ok and im happy with the division of functionality

[Piotr Antczak]

... I haven't tested those rules, but you can catch the sense.

[Steve Davies]

Hi, thanks to both of you.

I think I will take the Nodered approach - i’ve made one quite clean flow that adds a pir name, room name etc to the event payload, hen I can do the timeouts in one place and use the pir name to change the state of a corresponding homeassistant Mqtt binary sensor.

(By the way - is there any sensor type in HA which is intended to be only changed via the HA API?)

Steve

[Christian Lyra]

Hi All,

I don't see the point... The automation in Homeassistant is a trivial one, so instead of doing that you want to add another layer of complexity with Nodered? For the PIR type you don't even need a automation! I was not aware of this, but later discovered int the HA forum. I have this on my config:

sensor:

 - platform: mqtt

    name: "rfbridge2"

    state_topic: "home/rfbridge2/tele/RESULT"

    value_template: '{{ value_json.RfReceived.Data }}'

    expire_after: 1

binary_sensor::

- platform: template

    sensors:

      quartinho_rf:

        friendly_name: Quartinho

        value_template: '{{ is_state("sensor.rfbridge2", "7F6XXX") }}'

        delay_off: '00:00:40'

        device_class: motion

There's two nice "tricks" here. First the use of templates, so you don't need the topics for each one, and second the "delay_off". One nice thing about that is if motion is detected again delay_off is "reseted", and you can have a different value for each of your PIRs.

--
You received this message because you are subscribed to the Google Groups "SonoffUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Christian Lyra
PoP-PR/RNP

[Steve Davies]

Hi Christian,

On Mon, 15 Oct 2018 at 13:34, Christian Lyra <pop...@gmail.com> wrote:

 

I don't see the point... The automation in Homeassistant is a trivial one, so instead of doing that you want to add another layer of complexity with Nodered? For the PIR type you don't even need a automation! I was not aware of this, but later discovered int the HA forum. I have this on my config:

sensor:

 - platform: mqtt

    name: "rfbridge2"

    state_topic: "home/rfbridge2/tele/RESULT"

    value_template: '{{ value_json.RfReceived.Data }}'

    expire_after: 1

binary_sensor::

- platform: template

    sensors:

      quartinho_rf:

        friendly_name: Quartinho

        value_template: '{{ is_state("sensor.rfbridge2", "7F6XXX") }}'

        delay_off: '00:00:40'

        device_class: motion

There's two nice "tricks" here. First the use of templates, so you don't need the topics for each one, and second the "delay_off". One nice thing about that is if motion is detected again delay_off is "reseted", and you can have a different value for each of your PIRs.

Thanks for the helpful posts.  Those making tutorials etc don't see to know about these options.

Checking my understanding:

  in the definition of the mqtt sensor for the events coming from the rf bridge, the "value_template" kinda "extracts" the Data item.

  in the definition of the actual quartinho_rf sensor you then test that value via the 'is_state" ?

That looks useful.

For me I would say that programming logic in Nodered is much more accessible for me - I'm a programmer, so expressing logic with YAML specifications isn't intuitive for me; and the debugging is much harder.  But I know its mainly a matter of taste.

Steve

[Christian Lyra]

Hi Steve,

Checking my understanding:

  in the definition of the mqtt sensor for the events coming from the rf bridge, the "value_template" kinda "extracts" the Data item.

  in the definition of the actual quartinho_rf sensor you then test that value via the 'is_state" ?

Yes, you are right. You can have as many template sensor as you want by just changing the  RF code in the "value_template: '{{ is_state("sensor.rfbridge2", "XXXX") }}' line.

For me I would say that programming logic in Nodered is much more accessible for me - I'm a programmer, so expressing logic with YAML specifications isn't intuitive for me; and the debugging is much harder.  But I know its mainly a matter of taste.

yes... it's mostly about taste, but I guess that doing the automation inside HA is more efficient and doesn't introduce lags or delays. I may be wrong...

 

--

Christian Lyra
PoP-PR/RNP