Sonoff RF Bridge. Strategies for receiving data

Skillet_ZA · October 25, 2019, 7:17am

Hi All

Trying to go convert to strategy 2 but getting this error in my HA log:

Error while executing automation automation.rfbridge_demultiplexer. Service not found for call_service at pos 1: Unable to find service python_script/rfbridge_demux

My first time configuring python scripts on the system so started from step one.

Anything specific I should look for?

francisp · October 25, 2019, 10:38am

Did you put python_script: in your configuration.yaml?

Skillet_ZA · October 26, 2019, 11:49pm

Thanks so much, @francisp. That was indeed my issue.

SteveDinn · October 27, 2019, 3:00am

Thought I’d show my independent implementation of the ‘de-multiplexer’ completely using HA’s templates. I am able to take advantage of the fact that my door sensors all have their open/close code differ by only the last character (‘A’ for open, ‘E’ for close):

klogg · October 28, 2019, 2:24pm

I like this.
One question though; what made you decide to raise an rf_signal_received event and then trigger a second automation based on it, rather than just have it all as one automation?

SteveDinn · October 28, 2019, 2:41pm

I have RF devices other than door sensors, and I like having the RF signals abstracted from the MQTT messages, when I write other RF-based automations. You could totally do it the way you’re suggesting. It’s just preference.

123 · October 28, 2019, 2:54pm

Is there anything I can improve in my original post to make it less likely that others make the same mistake?

This is what it currently states:

To make this work, you have to configure Home Assistant to use the python_script component.

Add python_script: to your configuration file.

Create the following sub-directory: config/python_scripts

Restart Home Assistant.

klogg · October 28, 2019, 4:00pm

Can I suggest:

Add python_script: to your configuration.yaml file

123 · October 28, 2019, 4:10pm

Your suggestion is already present in the existing text (third paragraph in the second section). It’s the first one of three steps.

Or are you suggesting only the first step should be shown and the other two removed??

klogg · October 28, 2019, 11:27pm

I’m just suggesting that “Add python_script: to your configuration file” might be a cause of some confusion and that explicitly mentioning the configuration.yaml might be better.

It was just an observation based my original experience when learning about HA combined with the fact that the entire HA config can be contained in one file, and usually is for new people. I sometimes think it can be generally confusing and not always clear what is being meant when the word ‘configuration’ s being used.

What yo had originally was clear to me but as you asked, I thought I’d give another view on it.

123 · October 29, 2019, 12:33am

… and done!

I also added a link to the python_script integration’s documentation. It now reads as follows:

To make this work, you have to configure Home Assistant to use the python_script component. Full instructions can be found in the documentation for the python_script integration. Here are the basic steps:

Add python_script: to your configuration.yaml file.

Create the following sub-directory: config/python_scripts

Restart Home Assistant.

ashscott · November 5, 2019, 8:38pm

I finally got around to this and, 53 binary sensor configs later, it’s all running.

Thank you so much for taking the time to do this. I really appreciate it.

yoman · November 13, 2019, 12:17pm

anybody have update updated config for Home Assistant 0.101.3?

francisp · November 13, 2019, 2:16pm

I run this python script since HA 0.95 Never needed to update the config, including for HA 0.101.3

sleeepy2 · November 13, 2019, 5:24pm

I use the NodeRed solution above created by 123 Taras that works great and as it’s in NodeRed the HA version shouldn’t make a difference

ashscott · November 28, 2019, 11:59am

This is a truly excellent solution and since changing to it my system is far more reliable and responsive.

I have 12 outdoor PIR sensors, all of the same Kerui P861 kind.

The 6 digit code equates to several hundred million combinations. Unbelievably, 4 of my 12 have duplicate codes! What are the chances?

Can anyone suggest a way around this other than just buying new ones?

The issue with new ones is that they may well come through with repeat codes again.

AhmadK · November 30, 2019, 8:22pm

I don’t think there’s one… And yes, there’s no guarantee that new ones won’t interfere, BUT you can try to sell them locally
Alternatively, if they have a tamper switch or contacts, you can try to convert them into wireless buttons.

ashscott · December 9, 2019, 9:42am

I’m consistently seeing errors in the log like the one below but with different random received codes:

I don’t have a device with that code (or any of the other random ‘Unknown RF Commands’) and I live so remotely that it’s highly unlikely to become from another property.

Firstly, could there be another reason for the codes being ‘received’?

And secondly, is there maybe a way in rfbridge_demux.py to eliminate the errors for received, unlisted codes?

And thirdly, are the generated errors anything more than an annoyance that can be safely ignored?

123 · December 9, 2019, 1:26pm

I’ve purposely crafted the python_script to report unknown RF codes. I suggest you add the code to the python_script’s dictionary so it will be received (quietly) and published to home/34FE3A. You can then leave this topic unused. Alternately, if you’re curious to learn more about this mysterious RF code, associate the topic to an MQTT Sensor and then, after a week or so, look at its history. Maybe its pattern of turning on and off will provide a clue about its source.

ashscott · December 9, 2019, 1:41pm

Thank you. I should have know you’d considered this already.

This is such a great addition and I really appreciate your time on this.