Sonoff RF Bridge + X-10 Pilight

[Kitar]

The Sonoff RF Bridge is not compatible with X-10 codes out of the box. I am trying to receive the X-10 RT504 handheld remote codes as well as EagleEye and some X-10 security stuff like door/window sensors. But the big item is the handheld remotes. As far as I can tell the old X-10 remotes are 310MHz in N. America.

I flashed the bridge with Tasmota and Portisch to see if the RF transceiver could be reprogrammed to work on the 310MHz. Again no progress here, however it may be possible with other libraries installed.

Another flash called Pilight for the Sonoff RF Bridge claims to be able to send and receive X-10 automation and security codes. Pilight is loaded in conjunction with OpenMQTTGateway.

So how can this work? Even if the radio now a Software Defined Radio, how would the antenna work on that wide a frequency range?

Any of you gurus done the Pilight flash ?

edit: it just occurred to me that the European X-10 market may have used 433MHz and that may be what Pilight bases their compatibility on.

[Guest]

I have a Sonoff bridge running on OMG/Pilight. It does not decode X10. As you highlighted, North american X10 frequency is 310Mhz and European is 433.

You will need RTL_433 to receive (but not send if I remember correctly)

Despite the name it handles frequencies from 500 kHz up to 1.75 GHz (RTL-SDR)

https://github.com/merbanan/rtl_433

And X10 is supported:

https://github.com/merbanan/rtl_433/blob/master/src/devices/x10_rf.c

Hardware:

USB2.0 DVB-T Stick :
https://a.aliexpress.com/_mscoMBt

To add a coax groundplane antenna:
https://a.aliexpress.com/_mP1Ggbp

I have it installed but haven't tested X10 yet.
documentation confirms compatibility though.

Will try to test my old X10 motion sensors when I have a chance a report back.

Hope this helps,

Yann

[Michael McSharry]

@123qweasd
What do you use to expose RTL_433 to HS?

[Guest]

-F option

= Output format option = [-F kv|json|csv|mqtt|influx|syslog|null] Produce decoded output in given format. Without this option the default is KV output. Use "-F null" to remove the default. Append output to file with :<filename> (e.g. -F csv:log.csv), defaults to stdout. Specify MQTT server with e.g. -F mqtt://localhost:1883 Add MQTT options with e.g. -F "mqtt://host:1883,opt=arg" MQTT options are: user=foo, pass=bar, retain[=0|1], <format>[=topic] Supported MQTT formats: (default is all) events: posts JSON event data states: posts JSON state data devices: posts device and sensor info in nested topics The topic string will expand keys like [/model] E.g. -F "mqtt://localhost:1883,user=USERNAME,pass=PASSWORD,retain=0,devices= rtl_433[/id]" With MQTT each rtl_433 instance needs a distinct driver selection. The MQTT Client-ID is computed from the driver string. If you use multiple RTL-SDR, perhaps set a serial and select by that (helps not to get the wrong antenna). Specify InfluxDB 2.0 server with e.g. -F "influx://localhost:9999/api/v2/write?org=<org>&bucket=<bucket>,token=<authtoken>" Specify InfluxDB 1.x server with e.g. -F "influx://localhost:8086/write?db=<db>&p=<password>&u=<user>" Additional parameter -M time:unix:usec:utc for correct timestamps in InfluxDB recommended Specify host/port for syslog with e.g. -F syslog:127.0.0.1:1514

[Guest]

Just noted that the X10 decoder seems to refer only to specific security devices so further testing will be required. As i said, i have a box of X10 devices laying around. Will try to test it out. Thx

[Michael McSharry]

In my xAP node for W800 I have full X10 decoding as well as decoding for many other 433 and 315 devices. It was done in VB6 so not directly usable here, but if the decoding becomes a stumbling block then I can likely port to .NET.

[Michael McSharry]

I gave rtl_433 a try with a 18" 1/2 wave whip antenna and tuned frequency to 310 MHz. I tried with MS13A and Palmpad X10 devices and neither showed any recognition by rtl_433. My W800 was seeing them so I know the signal is being transmitted. I tried a few other antenna types and also had no luck. I did not take any further steps other than confirming my software setup was correct by using a 433 Mhz frequency, antenna and keypad remote and did see the decoded signal.

The SDR radio is a nice device for investigation. It does run very warm so it must be taking up some power. It would not be my first choice if other options are available for a permanent install.

I installed rtl433mqtt and got it working, but the instructions on the website made some assumptions about what was already installed on the RPi. Google searches help when I ran into install and code build errors. Most of the instructions were taken from https://www.sensorsiot.org/install-r...-raspberry-pi/ but it also had some typos and missed the doxygen install. This install described below was done on a virgin RPi4 Buster.

Build and install rtl_sdr
cd ~
sudo apt-get install git git-core cmake libusb-1.0-0-dev build-essential
git clone git://git.osmocom.org/rtl-sdr.git
cd rtl-sdr
sudo mkdir build
cd build
sudo cmake ../ -DINSTALL_UDEV_RULES=ON
sudo make
sudo make install
sudo ldconfig
cd ~
sudo cp ./rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/
sudo reboot
# create file no-rtl.conf

sudo nano /etc/modprobe.d/no-rtl.conf
# add these three lines

blacklist dvb_usb_rtl28xxu
blacklist rtl2832
blacklist rtl2830

sudo apt-get doxygen
sudo reboot
lsusb
rtl_test -t

Build and install rtl_433
---------------------------
sudo apt-get install libtool libusb-1.0.0-dev librtlsdr-dev
rtl_sdr doxygen
git clone https://github.com/merbanan/rtl_433.git
cd rtl_433
sudo mkdir build
cd build
sudo cmake ../
sudo make
sudo make install

Install python3/pip
-------------------------
sudo apt-get update
sudo apt-get -y install python3-pip

Get rtl433-to-mqtt script
--------------------------------
https://github.com/mverleun/RTL433-to-mqtt (download zip or clone code).  I placed mine in the same folder as rtl_433
Extract the file config.py.example to config.py and setup MQTT environment.
Extract rtl2mqtt.py
execute in terminal window with "phython3 rtl2mqtt.py"

[Guest]

Thanks for the feedback Michael,

I had doubts as well based on the documentation provided for the X10 decode:

https://github.com/merbanan/rtl_433/...ices/x10_sec.c

While it does mention 310Mhz support,
"Tested with American sensors operating at 310 MHz e.g., rtl_433 -f 310.558M"

it seems like it will only support "DS10 & DS18 door/window sensor"

BTW did you manage to get MQTT messages for working devices ?


Yann

[Michael McSharry]

Yes, the MQTT part worked fine for the 433 MHz. I just added the step-by-step for others who may want to try.

I had a 4 button remote and it picked up the button I was using as a GS558 smoke alarm. I don't know why two sets of messages with different topics were sent. I was not paying close attention when I was pressing the button. My guess is that rows 6 to 11 will be the last device seen while1 through 5 will be the device-dependent data.

[Michael McSharry]

I took a look at rtl433's decoder x10_rf and it looks to assess House Code, Device Code, State and what looks like Security Code. This should cover most X10 things. There is some prechecks for CR12A (X10 Remote) that abort the remainder of the decode. Also packets under 32 bits are discarded. If I remember correctly the standard X10 devices are 32 or 40 bits and the security are longer. It has been many years since I last did the W800, MR26A and the powerline CM11A at the bit level.

If I'm in the mood tomorrow I will look deeper. Linux is not my natural environment so would need to learn how to add some debug provisions.

[Guest]

Yes, the MQTT part worked fine for the 433 MHz. I just added the step-by-step for others who may want to try.

Hi Michael,
where is your step by step located?

thx

[Michael McSharry]

Post #7 gives the steps to get mqtt messages using SDR dongle.

[Michael McSharry]

I downloaded the sources today for Windows environment and was able to get standard X10 RF on palmpad and motion sensor reporting via MQTT. It took me awhile to trace the code and determine that there is decoding for 167 devices, but only 138 or them were enabled. The X10_RF was one that was not enabled. When I enabled it with a source code change then the standard RF was being recognized at 310 MHz. There is also decoding for X10 security and it was enabled in the default source.

For those that want to do more with this the following is what I did with the source. In the subfolder devices is a file for each device that has been defined. If a new device is to be added then the file is added in this subfolder and then it is added as a line in file rtl_devices.h at the end. This makes for addition of new devices relatively easy once the encoding is known. I suspect in most cases it will be back to SDR Sharp or similar to capture the new device traffic to develop the decoding.

DECL(somfy_rts) \
[COLOR=#c0392b]/* Add new decoders here. */[/COLOR]

At the end of each decoder file is the parameters that the device uses for encoding. The one for the X10 RF is shown below. One of the properties is "disabled". It was set to 1 in the source and I changed it to 0 to enable this decoder and then the reporting of received X10 RF.

r_device X10_RF = {
.name = "X10 RF",
.modulation = OOK_PULSE_PPM,
.short_width = 500, // Short gap 500µs
.long_width = 1680, // Long gap 1680µs
.gap_limit = 2800, // Gap after sync is 4.5ms (1125)
.reset_limit = 6000, // Gap seen between messages is ~40ms so let's get them individually
.decode_fn = &x10_rf_callback,
.disabled = [COLOR=#c0392b]0[/COLOR],
.fields = output_fields,
};

[Guest]

Thanks Michael McSharry, great finding.
Sounds like excellent news for people who want to repurpose old X10 motion sensors, remotes, etc.
Really surprised that this was not documented or discussed on SDR forums....
Guess I'll open that dusty box in the garage and do some testing. I remember that the MS13/14's were running forever on 2xAAA batteries...

[Michael McSharry]

It turns out it was documented at https://github.com/merbanan/rtl_433 where the * in the table designates that it is disabled by default. The -R parameter is used to enable selective decoders and could be done this way rather than changing the source.

I also found an easier way to do MQTT without dealing with python. It use the Mosquitto client to do the LAN communications. I documented this project overall in Section 17.24 of mcsMQTT manual. http://mcsSprinklers.com/mcsMQTT.pdf

I also tried frequency hopping to cover both 433 and 310, but just cannot tune different frequencies fast enough. If one wants both 310 and 433 then they need two dongles.