ENER314-RT / RF69 and multiple power strips?

[megatron-uk]

Hi,

Is there any method for a single ENER314-RT to control more than one ENER010 4-way power strip?

I've got 5 or 6 of the ENER010 strips (and probably need a few more, eventually) in my AV/gaming room and want to replace them all (and the dozen fiddly little remotes) with a touchscreen controller powered by a Pi.

I'm having difficulty working out whether it's actually possible to do that, or whether the ENER314-RT has to be paired to a particular socket or power strip first. All of my kit is the older, green button devices.

I see there isn't a way (short of leaving the Pi to try every single address) to identify remote id's yet though.

John

[megatron-uk]

Ah, I see that use case is referenced in https://github.com/whaleygeek/pyenergenie/issues/85. Could we add that to the documentation so that it is clear?

The standard offering from Energenie of controlling 4 devices is, shall we say, a bit limiting.

[Achronite]

The ENER314-RT adaptor can control multiple power strips AFAIK. You just need to assign a different house code / zone to each strip. The older ENER314 adaptor can only control 1 strip as it has a built-in house code which cannot be changed. It is possible to control 6 devices per house code on both devices, but it is not 'officially supported'; the node-red node that I am currently developing allows for 6 devices per zone.

[megatron-uk]

Thanks, I think I'll pick up either the ENER314-RT or the RFM69 radio module that it uses; as there doesn't appear to be any active components on the ENER314-RT apart from the module I assume it should work the same?

The problem with the ENER314-RT from my perspective is the form factor - I've already got an SPI based touchscreen hat plugged in that I want to use for this project, so at the very least I need to use a different GPIO pin for the CE signal. To do that it seems I may need to edit: https://github.com/whaleygeek/pyenergenie/blob/master/src/energenie/drv/spis.c

Has anyone ran the ENER314-RT with the pyenergenie spi driver alongside another device using SPI?

[whaleygeek]

Just edit the pin constants in spis.c, it should work fine. It was designed with that purpose in mind.

On Mon, 8 Apr 2019, 12:36 John Snowdon, notifications@github.com wrote:

Thanks, I think I'll pick up either the ENER314-RT or the RFM69 radio module that it uses; as there doesn't appear to be any active components on the ENER314-RT apart from the module I assume it should work the same?

The problem with the ENER314-RT from my perspective is the form factor - I've already got an SPI based touchscreen hat plugged in that I want to use for this project, so at the very least I need to use a different GPIO pin for the CE signal. To do that it seems I may need to edit: https://github.com/whaleygeek/pyenergenie/blob/master/src/energenie/drv/spis.c

Has anyone ran the ENER314-RT with the pyenergenie spi driver alongside another device using SPI?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/whaleygeek/pyenergenie/issues/106#issuecomment-480795479, or mute the thread https://github.com/notifications/unsubscribe-auth/AD5cAfZ0d3b0Joz0nEEilEGDEXUrKjO7ks5veynDgaJpZM4cgKli .

[megatron-uk]

That's great news. I'll give that a go as soon as the radio module arrives and report back here. My code (minus any integration with pyenergenie at present) lives here: https://github.com/megatron-uk/sdlRFController

[megatron-uk]

Well my RFM69 module has arrived - need to connect it up on some different pins to my touchscreen; which also uses SPI, but I'm hoping to try that tonight.

[whaleygeek]

Sounds good - please report back how it goes. I designed the system to allow this mode of working, but never tried it. I do have some RFM69 modules here now, so if you get stuck I can try to help debug your mods.

[megatron-uk]

Ok, not a success. Yet.

Turns out that the touchscreen uses both CE0 and CE1 to toggle between display and the touch overlay. So I'm out of luck with the standard SPI0 implementation and appears I'll have to enable SPI to get the second port. Fortunately I'm using a Pi 2B and I have nothing on pin 35, 36, 38 or 40 which is where it moves MOSI, MISO, SCLK and CE0 to.

Out of time tonight though, I can hear the glare I'm getting from SWMBO for spending time on the computer :D

[whaleygeek]

Hi John,

As the pyenergenie library uses a built-in software SPI, you can use any GPIO pins for the SPI port for the radio (not just those labelled as SPI).

[megatron-uk]

Doh! Of course....

So I'm now changing the wiring to as follows:

pi pin, gpio number,    colour, function
-       -   black,  gnd
-       -   brown,  3.3v
38,         20, green,  mosi
35,     19, blue,   miso
40,     21, grey,   sclk
36,     16, purple, ce1
37,     26, orange, reset
33,     13, yellow, G0/DIO0

I changed hrfm69_test.c and spi_test.c to reflect the new GPIO numbers and it appears to work:

$ ./hrfm69_test 
start
reset...
reading radiover...
36
standby mode
writereg 1 4
testing...
config
writereg 2 8
writereg 5 0
writereg 6 0
writereg 7 108
writereg 8 122
writereg 9 225
writereg 25 65
writereg 3 26
writereg 4 11
writereg 45 0
writereg 46 0
writereg 55 0
writereg 56 240
writereg 60 15
transmitter mode
writereg 1 12
wait for modeready,txready in irqflags1
irqflags1,2=176,0
tx repeats in a single burst:238

I presume that output is something along the lines of what is expected?

Also, the LCD screen no longer goes funky when I do that, so that's a bonus of not trying to share CE0/CE1 which it was using both of :)

[whaleygeek]

If you get something other than 0 or 255 for the radiover, it means the radio has responded to a register read. Looks good.

[megatron-uk]

Not getting response from my sockets yet. Everything appears to be working on the software side, but no relays clicking as of yet. With trace turned on, the driver reports:

radio_init
reset...
reading radiover...
36
radio_standby
writereg 1 4
_wait_ready
writereg 2 8
writereg 5 0
writereg 6 0
writereg 7 108
writereg 8 122
writereg 9 225
writereg 25 65
writereg 3 26
writereg 4 11
writereg 45 0
writereg 46 0
writereg 55 128
writereg 56 0
radio_transmit
writereg 1 12
_wait_ready
_wait_txready
radio_send_payload
config
writereg 60 15
tx multiple payloads in a single burst
irqflags1,2=176,0
writereg 1 4
_wait_ready

That's just doing a very basic:

#!/usr/bin/env python3

import time
import energenie

energenie.init()
s = energenie.Devices.ENER002((0x7bbff, 1))
s.turn_on()

However, I will admit that I probably didn't save myself any time (or money, ultimately) by getting a bare RFM69 module. I'll probably revert to getting one mounted on a carrier with the rx/tx led and space for an antenna, such as the adafruit one.

[whaleygeek]

can you send a pic of what you have attached to the ANT pin? It needs to be a quarter wave measured for 433MHz. I wound a bit of insulated solid core hookup wire round a pencil and soldered onto ANT pin on my sparkfun breakout board

[megatron-uk]

It's just a straight wire (a single line stripped from an IDE cable, as I'm using for the rest of the Pi to radio hookup wired) - 16.4cm, or as close as I can make it.

[megatron-uk]

The replacement Adafruit RFM69HCW arrived and it's all hooked up (much neater, I may add!), but I'm still not getting any response from my sockets.

I've a proper 433Mhz edge mount sma antenna on the way, but until then I've replaced the straight length of wire and am using a coiled spring antenna that was listed as suitable for 433MHz operation. The Pi is on my desk and one of the ENER010 socket strips is underneath, so no more than 1M away.

[megatron-uk]

Okay, I don't think this thing is actually transmitting. I've got the Pi and the RFM69HCW radio sitting no more than 6 inches away from the same DVB-T antenna + USB stick that picked up all of the home codes from the Energenie remotes and there's not a sausage being shown even if I leave it looping indefinitely:

energenie.init()
s1 = energenie.Devices.OOKSwitch((0x7bbff, 1))
while True:
    s1.turn_on()
    time.sleep(3)
    s1.turn_off()
    time.sleep(3)

No output from rtl_433 at all, and then as soon as I press the actual ENER002-C remote that corresponds to 0x7bbff:

$ rtl_433 -X 'n=name,m=OOK_PWM,s=248,l=656,r=6656,g=604,t=160,y=0'

rtl_433 version 18.12-194-g5ed62fc branch master at 201904101337 inputs file rtl_tcp RTL-SDR

Registered 99 out of 125 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 62-63 67-71 73-100 102-103 108-116 119 121 124-125 ]
Found Fitipower FC0012 tuner
Exact sample rate is: 250000.000414 Hz
Sample rate set to 250000 S/s.
Tuner gain set to Auto.
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2019-04-21 20:27:27
model     : name         count     : 1             num_rows  : 1             rows      : 
len       : 1            data      : 0
codes     : {1}0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2019-04-21 20:27:27
model     : name         count     : 1             num_rows  : 1             rows      : 
len       : 1            data      : 0
codes     : {1}0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2019-04-21 20:27:27
model     : name         count     : 13            num_rows  : 13            rows      : 
len       : 25           data      : 7bbff08, 
len       : 25           data      : 7bbff08, 
len       : 25           data      : 7bbff08, 
len       : 25           data      : 7bbff08, 
len       : 25           data      : 7bbff08, 
len       : 25           data      : 7bbff08, 
len       : 25           data      : 7bbff08, 
len       : 25           data      : 7bbff08, 
len       : 25           data      : 7bbff08, 
len       : 25           data      : 7bbff08, 
len       : 25           data      : 7bbff08, 
len       : 25           data      : 7bbff08, 
len       : 25           data      : 7bbff08
codes     : {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2019-04-21 20:27:29
model     : name         count     : 14            num_rows  : 14            rows      : 
len       : 25           data      : 7bbff18, 
len       : 25           data      : 7bbff18, 
len       : 25           data      : 7bbff18, 
len       : 25           data      : 7bbff18, 
len       : 25           data      : 7bbff18, 
len       : 25           data      : 7bbff18, 
len       : 25           data      : 7bbff18, 
len       : 25           data      : 7bbff18, 
len       : 25           data      : 7bbff18, 
len       : 25           data      : 7bbff18, 
len       : 25           data      : 7bbff18, 
len       : 25           data      : 7bbff18, 
len       : 25           data      : 7bbff18, 
len       : 25           data      : 7bbff18
codes     : {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18

There's clearly at least some level of device interaction working, since the C driver code is able to read register values back (hence the report of radiover 36), but is it possible that it's not fully initialising the radio, or putting it in to transmit mode or similar?

I'm loathe to buy the official Energenie radio module, as I'd have to hack it to bits to get it to fit anyway - I'm already using a GPIO interceptor board since my touchscreen/display covers the entire length of the pin headers (though doesn't use them all).

[whaleygeek]

Did your new rfm module work in the standard pins as per the Energenie board?

Have you wired the RESET line in too?

On Sun, 21 Apr 2019, 20:38 John Snowdon, notifications@github.com wrote:

Okay, I don't think this thing is actually transmitting. I've got the Pi and the RFM69HCW radio sitting no more than 6 inches away from the same DVB-T antenna + USB stick that picked up all of the home codes from the Energenie remotes and there's not a sausage being shown even if I leave it looping indefinitely:

energenie.init() s1 = energenie.Devices.OOKSwitch((0x7bbff, 1)) while True: s1.turn_on() time.sleep(3) s1.turn_off() time.sleep(3)

No output from rtl_433 at all, and then as soon as I press the actual ENER002-C remote that corresponds to 0x7bbff:

$ rtl_433 -X 'n=name,m=OOK_PWM,s=248,l=656,r=6656,g=604,t=160,y=0'

rtl_433 version 18.12-194-g5ed62fc branch master at 201904101337 inputs file rtl_tcp RTL-SDR

Registered 99 out of 125 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 62-63 67-71 73-100 102-103 108-116 119 121 124-125 ] Found Fitipower FC0012 tuner Exact sample rate is: 250000.000414 Hz Sample rate set to 250000 S/s. Tuner gain set to Auto. Tuned to 433.920MHz. Allocating 15 zero-copy buffers

---

time : 2019-04-21 20:27:27 model : name count : 1 num_rows : 1 rows : len : 1 data : 0 codes : {1}0

---

time : 2019-04-21 20:27:27 model : name count : 1 num_rows : 1 rows : len : 1 data : 0 codes : {1}0

---

time : 2019-04-21 20:27:27 model : name count : 13 num_rows : 13 rows : len : 25 data : 7bbff08, len : 25 data : 7bbff08, len : 25 data : 7bbff08, len : 25 data : 7bbff08, len : 25 data : 7bbff08, len : 25 data : 7bbff08, len : 25 data : 7bbff08, len : 25 data : 7bbff08, len : 25 data : 7bbff08, len : 25 data : 7bbff08, len : 25 data : 7bbff08, len : 25 data : 7bbff08, len : 25 data : 7bbff08 codes : {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08, {25}7bbff08

---

time : 2019-04-21 20:27:29 model : name count : 14 num_rows : 14 rows : len : 25 data : 7bbff18, len : 25 data : 7bbff18, len : 25 data : 7bbff18, len : 25 data : 7bbff18, len : 25 data : 7bbff18, len : 25 data : 7bbff18, len : 25 data : 7bbff18, len : 25 data : 7bbff18, len : 25 data : 7bbff18, len : 25 data : 7bbff18, len : 25 data : 7bbff18, len : 25 data : 7bbff18, len : 25 data : 7bbff18, len : 25 data : 7bbff18 codes : {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18, {25}7bbff18

There's clearly at least some level of device interaction working, since the C driver code is able to read register values back (hence the report of radiover 36), but is it possible that it's not fully initialising the radio, or putting it in to transmit mode or similar?

I'm loathe to buy the official Energenie radio module, as I'd have to hack it to bits to get it to fit anyway - I'm already using a GPIO interceptor board https://shop.4tronix.co.uk/products/gpio-interceptor-gpio-breakout-for-40-pin-raspberry-pi since my touchscreen/display covers the entire length of the pin headers (though doesn't use them all).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/whaleygeek/pyenergenie/issues/106#issuecomment-485277099, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7FYAM77JWODZ5ZWCS6HYLPRS7ETANCNFSM4HEAVFRA .

[megatron-uk]

This is it hooked up:

pi rfm69hcw radio

and the Pi side of things:

pi case and breakout

And I've used the Adafruit documentation for the connections:

The pins are: VIN - Pi 3.3 (also tried 5v since VIN is rated 3.3-6v) Ground - Pi GND Enable (not used) G0 - Pi 33 / GPIO 13 SCK - Pi 40 / GPIO 21 MISO - Pi 35 / GPIO 19 MOSI - Pi 38 / GPIO 20 CS - Pi 36 / GPIO 16 RES - Pi 37 / GPIO 26

Here's the new defines in radio.c:

#define RESET     26
#define LED_GREEN 27   // (not B rev1)
#define LED_RED   22
#define CS        16    // CE1
#define SCLK      21
#define MOSI      20
#define MISO      19

Also spis.c is the same as the above. One thing that doesn't seem to be defined anywhere is the interrupt pin. But that's also not defined on the Energenie documentation either:

energenie wiring diagram

Though pretty much every other RFM69 variant does include an interrupt line either G0 or DIO0 depending on the breakout board (http://www.kittley.com/2018/04/05/blog-rfm69-pi/).

[whaleygeek]

Other things to check, what variant of rfm do you have? Some are pre tuned on the module for a different frequency band and have different C and R fitted for the tuned tank. You will get terrible attenuation if its the other module for the other band.

If you run the code into fresh air with no board fitted, radiover will probably be 0 or 255 depending on how the MISO pin floats, that would double confirm you really are talking to the radio and point at an RF problem.

If you check the hoperf 69 chip datasheet, you can configure one of the DIO pins to output the non modulated baseband signal and should see tx payloads on a scope or logic analyser if you have one, again helping to point at a possible RF problem

On Mon, 22 Apr 2019, 13:10 John Snowdon, notifications@github.com wrote:

This is it hooked up:

pi rfm69hcw radio https://github.com/megatron-uk/sdlRFController/blob/master/docs/pi_radio.jpg

and the Pi side of things:

pi case and breakout https://github.com/megatron-uk/sdlRFController/blob/master/docs/pi_case.jpg

And I've used the Adafruit https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-breakouts/pinouts documentation for the connections:

The pins are: VIN - Pi 3.3 (also tried 5v since VIN is rated 3.3-6v) Ground - Pi GND Enable (not used) G0 - Pi 33 / GPIO 13 SCK - Pi 40 / GPIO 21 MISO - Pi 35 / GPIO 19 MOSI - Pi 38 / GPIO 20 CS - Pi 36 / GPIO 16 RES - Pi 37 / GPIO 26

Here's the new defines in radio.c:

define RESET 26

define LED_GREEN 27 // (not B rev1)

define LED_RED 22

define CS 16 // CE1

define SCLK 21

define MOSI 20

define MISO 19

Also spis.c is the same as the above. One thing that doesn't seem to be defined anywhere is the interrupt pin. But that's also not defined on the Energenie documentation either:

energenie wiring diagram https://github.com/megatron-uk/sdlRFController/blob/master/docs/ener314rt_wires.jpg

Though pretty much every other RFM69 variant does include an interrupt line either G0 or DIO0 depending on the breakout board ( http://www.kittley.com/2018/04/05/blog-rfm69-pi/).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/whaleygeek/pyenergenie/issues/106#issuecomment-485403246, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7FYAN65SBC7LUPAOQQZTTPRWTLZANCNFSM4HEAVFRA .

[megatron-uk]

So without a board plugged in, I get the following radiover result:

$ ./hrfm69_test 
start
reset...
reading radiover...
0
unexpected radio ver, not 36(dec)

So there's definitely some comms going on over the MOSI/MISO connection when it's plugged in.

Unfortunately I don't have access to anything more advanced than a Fluke multimeter - neither a scope or a logic analyser. The radio module should be a 433MHz RFM69HCW - the Adafruit instructions mention either a red dot on top of the radio controller for 433 specification or green/blue for 900Mhz. Mine is red.

I have just seen this note on another forum specifically regarding the reset pin for the Adafruit board:

For future reference (in case someone else stumbles on this thread): It seems Adafruit made a design mistake by always pulling reset high. Also, their datasheet states RST - this is the Reset pin for the radio. It's pulled high by default. Pull down to ground to put it into reset which is clearly wrong - pulling RST to low takes the radio out of reset mode.

Should I disconnect RST and ground it instead?

[megatron-uk]

So connecting RST direct to ground (Pi pin 39) makes no difference - radiover still works (so the power-on-reset function of the RFM chip must clearly do all the initialisation that is needed to put it in a state where it can be talked to over SPI), but there's still no transmission from the board either to my power sockets or being picked up by rtl_433.

[whaleygeek]

Reset is active high, as per this code in radio.c:

void radio_reset(void)
{
    gpio_high(RESET);
    delayms(150);

    gpio_low(RESET);
    delayus(100);
}

While reset is not strictly required, noise on the SPI when all lines are tri-stated (the normal state when the pyenergenie library is not in use) could cause spurious writes to registers. The radio.c config tables are partial, meaning they only change registers that change from the reset defaults. So I would always advise wiring reset through to the pyenergenie library and allowing it to control it.

[megatron-uk]

RST is back to being controlled by the GPIO pin and I've thrown a whole load more debugging in radio.c.

I'm reading back carrier frequency, bitrate and data mode registers at init and after each _config() call to switch between FSK/OOK and send/receive, just so that I can be sure that the registers are actually being set.

I'm fairly sure that all of that is working correctly, as I see the following sequence of calls with my (while true, socket.power_on(), socket.power_off()) Python code:

// Output from radio_init() below

[radio.c:301]   : Radio_init
[radio.c:315]   : Reset...
[radio.c:319]   : Radio Ver 36
[radio.c:191]   : Data mode 00
[radio.c:198]   : Radio carrier frequency 0xe4 + 0xc0 + 00 = 0xe4c000
[radio.c:204]   : Radio bitrate 0x1a + 0xb = 0x1a0b (6667)
[radio.c:403]   : Radio to standby mode

// Output of each while loop, below

[hrfm69.c:26]   : Writing register 1 0x4
_wait_ready
[radio.c:353]   : Data mode set to OOK
[hrfm69.c:26]   : Writing register 2 0x8
[hrfm69.c:26]   : Writing register 5 00
[hrfm69.c:26]   : Writing register 6 00
[hrfm69.c:26]   : Writing register 7 0x6c
[hrfm69.c:26]   : Writing register 8 0x7a
[hrfm69.c:26]   : Writing register 9 0xe1
[hrfm69.c:26]   : Writing register 25 0x41
[hrfm69.c:26]   : Writing register 3 0x1a
[hrfm69.c:26]   : Writing register 4 0xb
[hrfm69.c:26]   : Writing register 45 00
[hrfm69.c:26]   : Writing register 46 00
[hrfm69.c:26]   : Writing register 55 0x80
[hrfm69.c:26]   : Writing register 56 00
[radio.c:191]   : Data mode 0x8
[radio.c:198]   : Radio carrier frequency 0x6c + 0x7a + 0xe1 = 0x6c7ae1
[radio.c:204]   : Radio bitrate 0x1a + 0xb = 0x1a0b (6667)
[radio.c:369]   : Data mode 0x8
[radio.c:412]   : Radio transmitting...
[hrfm69.c:26]   : Writing register 1 0xc
_wait_ready
_wait_txready
radio_send_payload
config
[hrfm69.c:26]   : Writing register 60 0xf
tx multiple payloads in a single burst
irqflags1,2=176,0
[hrfm69.c:26]   : Writing register 1 0x4
_wait_ready
[radio.c:353]   : Data mode set to OOK
[hrfm69.c:26]   : Writing register 2 0x8
[hrfm69.c:26]   : Writing register 5 00
[hrfm69.c:26]   : Writing register 6 00
[hrfm69.c:26]   : Writing register 7 0x6c
[hrfm69.c:26]   : Writing register 8 0x7a
[hrfm69.c:26]   : Writing register 9 0xe1
[hrfm69.c:26]   : Writing register 25 0x41
[hrfm69.c:26]   : Writing register 3 0x1a
[hrfm69.c:26]   : Writing register 4 0xb
[hrfm69.c:26]   : Writing register 45 00
[hrfm69.c:26]   : Writing register 46 00
[hrfm69.c:26]   : Writing register 55 0x80
[hrfm69.c:26]   : Writing register 56 00
[radio.c:191]   : Data mode 0x8
[radio.c:198]   : Radio carrier frequency 0x6c + 0x7a + 0xe1 = 0x6c7ae1
[radio.c:204]   : Radio bitrate 0x1a + 0xb = 0x1a0b (6667)
[radio.c:369]   : Data mode 0x8
[radio.c:412]   : Radio transmitting...
[hrfm69.c:26]   : Writing register 1 0xc
_wait_ready
_wait_txready
radio_send_payload
config
[hrfm69.c:26]   : Writing register 60 0xf
tx multiple payloads in a single burst
irqflags1,2=176,0

At the very least, the register writes to set carrier frequency and data mode seem to be working - the radio starts out at a different carrier frequency (0xe4c000), but does appear to switch to 433.92MHz (0x6C7AE1) correctly.

[whaleygeek]

You can route the baseband payload (raw data bits) to pin DIO2 by configuring the RegDIOMapping1 register. Store value 0x01 into register 0x25

Add this to radio.c somewhere in the config_OOK table, rebuild the code, and it will then insert this into the configuration that is downloaded when the radio configures into OOK mode for legacy socket switching.

https://github.com/whaleygeek/pyenergenie/blob/master/src/energenie/drv/radio.c#L148

{0x25, 0x01}, // DATA on pin DIO2

When the radio is idle, the DATA pin will probably be permanently low. When transmitting it will have a manchester encoded bitpattern on it.

OOK payloads are 16 bytes long, repeated 8 times, sent at 4800bps, bytes are 8 bits long, which makes the full burst just over 200ms long. So you should probably be able to see the difference on your fluke meter for an 'all low' followed by a 200ms burst of what is manchester encoded data.

Here is a typical payload, that will be repeated 8 times.

0x80 0x0 0x0 0x0 0x8e 0xe8 0xee 0x88 0x8e 0xe8 0xee 0x88 0x8e 0xe8 0xee 0x8e

According to the datasheet, pins can source and sink 1mA of current, not enough to switch an LED on, but if you could arrange for a simple transistor in circuit it would be.

If your python test code repeatedly transmits a switch_on with no delays, you'll probably get a reading on your fluke when it should be transmitting.

[megatron-uk]

Okay, did that and connected the fluke up in 300mV DC mode to DIO2 and ground. It definitely pulses when the radio_send_payload debug text from radio.c is printed on screen - pauses whilst my (while true) loop does a time.sleep() and then pulses again. That sequence matches my power_on, wait, power_off infinite loop.

I'm afraid with the limits of my multimeter (a Fluke 75 from the mid 90's) that's about all I can see.

[whaleygeek]

Can you get GnuRadio working with your RTL dongle? That way you could easily build a spectral plot of the 433MHz spectrum and see if there is any RF actually being emitted. I have a GnuRadioCompanion project that demods the payloads and displays them on a GnuRadio virtual scope plot, that I used to debug some radio glitching a couple of years ago. That would give you some good visibility.

---

David Whale, B.Sc (Hons), MIET Software Engineer

On Mon, 22 Apr 2019 at 20:01, John Snowdon notifications@github.com wrote:

Okay, did that and connected the fluke up in 300mV DC mode to DIO2 and ground. It definitely pulses when the radio_send_payload debug text from radio.c is printed on screen - pauses whilst my (while true) loop does a time.sleep() and then pulses again. That sequence matches my power_on, wait, power_off infinite loop.

I'm afraid with the limits of my multimeter (a Fluke 75 from the mid 90's) that's about all I can see.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/whaleygeek/pyenergenie/issues/106#issuecomment-485514882, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7FYAOB4W7W45LOA6PM7VDPRYDRVANCNFSM4HEAVFRA .

[whaleygeek]

P.S. Forget trying to build/install GnuRadio natively, it's a real pain. I downloaded a pre-rolled Ubuntu CD ISO image from the web with it all pre installed, and I boot my Mac from a USB memory stick to get GnuRadio working. It was much less pain and saved lots of grey hairs!

---

David Whale, B.Sc (Hons), MIET Software Engineer

On Mon, 22 Apr 2019 at 23:04, David Whale david@thinkingbinaries.com wrote:

Can you get GnuRadio working with your RTL dongle? That way you could easily build a spectral plot of the 433MHz spectrum and see if there is any RF actually being emitted. I have a GnuRadioCompanion project that demods the payloads and displays them on a GnuRadio virtual scope plot, that I used to debug some radio glitching a couple of years ago. That would give you some good visibility.

---

David Whale, B.Sc (Hons), MIET Software Engineer

On Mon, 22 Apr 2019 at 20:01, John Snowdon notifications@github.com wrote:

Okay, did that and connected the fluke up in 300mV DC mode to DIO2 and ground. It definitely pulses when the radio_send_payload debug text from radio.c is printed on screen - pauses whilst my (while true) loop does a time.sleep() and then pulses again. That sequence matches my power_on, wait, power_off infinite loop.

I'm afraid with the limits of my multimeter (a Fluke 75 from the mid 90's) that's about all I can see.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/whaleygeek/pyenergenie/issues/106#issuecomment-485514882, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7FYAOB4W7W45LOA6PM7VDPRYDRVANCNFSM4HEAVFRA .

[whaleygeek]

Here is the GRC project I used with GnuRadio, in case you decide to take that route. OOK_djw.grc.zip

[whaleygeek]

I probably got the LiveCD ISO from somewhere like this... https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment

Originally I booted it by burning it to CD and booting from an external CD drive, but I refined on this by working out how to build a booting USB image given that ISO image and a bit of fiddling with the ubuntu startup disk maker from another Ubuntu live CD ISO, I think.

[megatron-uk]

Hi David. I've got Mint 19 on my desktop so I'll give it a go tomorrow.

[megatron-uk]

So I've got gnuradio-companion working, and it plots a scope from the DVB tuner with background noise.

However, I don't see anything change when I run the power_on/power_off test loop from the Pi. Do I need to make any changes to the settings of the grc project to get it to show up? I've tried altering the scales of the x and y-axis but I'm not really sure what I'm doing.

[megatron-uk]

I've caved and ordered an actual ENER314-RT. I'll have to unplug my screen to try it, but it will at least test whether everything else is working and if it's the RFM69 module at fault.

I'd still like to get this other one working though.

[whaleygeek]

Can you check the labelling of the RF69 chip as per the table below, just in case the chip and the pen mark on the board are not consistent...

[megatron-uk]

Part number is really difficult to make out having removed the red paint, but it's over 3 lines under the 'H' logo, and I'm fairly sure it reads as:

RF69
1819
W4H223

There's nothing close to matching any of those part numbers above :(

[megatron-uk]

I've also just checked the no-brand RF69W I bought before this one, and having not been paint marked it's easier to make out:

RF69
1832
W4U223

[megatron-uk]

My ENER314-RT arrived today and has the following markings:

RF69
1448
W2V996

Haven't had a chance to try it yet as I'm at work.

[whaleygeek]

Hmm. I think the HopeRF69 chip is the same in all cases, but there are different R C and L fitted to the boards that are used on different bands. Those further numbers are probably chip revision and batch codes from manufacture.

So the different bands are I think due to (a) what is written to the freq synth registers and (b) the R C and L fitted on the module. It's possible your module has been mis-labelled (it is only a pen mark). You are more likely to get a working configuration with the official Energenie radio board as they only distribute the 433 band version.

[megatron-uk]

Ok, preliminary findings:

1. Had to change the SPI settings in radio.c and spis.c back to defaults (naturally). Though the ENER314-RT radio wouldn't initialise at that point. I had to disable SPI in /boot/config.txt before it would work (even with nothing else plugged in to SPI0).

2. The board shows signs of life; the red transmit led pulses in time with my while loop. I still get no response from my socket relays.

3. There is some sign of a signal in gnuradio, but it's incredibly noisy:

I need to swap back my Adafruit board and restart gnuradio with the settings I capture the above image with and see if there was anything there with that board that I was just losing in all of the noise.

Are the ENER002-C remotes just mega powerful when they're in use compared to these RF69 based boards?

Edit: No definitely still nothing, even amongst the noise, for the Adafruit module. Is there something specific about the Energenie module compared to a generic RF69? Neither of those two units I've got show any life - has anyone had any success with a non-Energenie branded RF69?

[whaleygeek]

Yes, because I use a software SPI, you do need to turn off the hardware SPI for those pins to be available as general purpose IO pins. I have an outstanding issue to update the docs to make this clearer.

There is some anecdotal evidence on other github issues, that the signal strength is lower with the ENER314-RT board compared to the hand remotes. I checked the settings a while back and it seems to be set at the highest power level, although I haven't experimentally checked this yet with gnuradio set up as a power meter (using the FFT plot), so it was inconclusive.

Did you capture your house code from your RF remote using the rtl program, or have you put your sockets into learn mode and 'learnt' what the radio is transmitting? In the early days I had different effects by re-learning the real thing that was transmitting. I'm not sure to what clock resolution the legacy plugs resolve and how much clock drift they suffer from, but again there was some anecdotal evidence that they could learn pretty much anything, and if the RF remote (cheap handheld battery device) was learnt and at one end of the timing, and the Ener314-RT+pyenergenie at the other end of the timing, there would sometimes be a discrepancy.

Also, some users reported other devices in their house transmitting on the ISM 433 band causing significant interference, and one person reported never getting it to work in his house with a previously known working setup.

It would be worth capturing the plot with no transmission (to get a sense of background noise or interference), sending with the RF hand remote, and sending with each of the two boards, to spot any correlations.

[megatron-uk]

I captured the house codes from all 6 of my remotes using rtl_433, but it's an interesting exercise to put the sockets in learn mode again and see if they relearn anything whilst the Pi is broadcasting.

I have to admit that without anything (I'm aware of) broadcasting, the signal in gnuradio is still very noisy:

That's as near as I can make the scale to the previous plots; there's quite a bit of hiss.

[megatron-uk]

Well I can confirm now that getting one of my ENER010 strips to relearn against the ENER314-RT and pyenergenie does, in fact, work - I put the strip in learn mode and sent socket.power_on() a couple of times and the power strip clicked into life after the learn light went out.

This is using the same house code that originally activated a different ENER010 (which rtl_433 recorded as 0x7bbff,).

Using that original remote won't activate this newly learnt power strip.

Using pyenergenie and that code will.

I think your suspicion that there is some clock skew going on could be on the money - all things being equal that house code and the original remote should be activating both sockets, but it doesn't.

I now need to try the same thing with the other RF69 modules and see if the same behaviour applies - I'm not sure it will, as there does appear to be an RF transmission issue with those compared to the official module.

[whaleygeek]

Aha! good progress!

The ENER314-RT and those RFM69 modules should use the same underling HopeRF module, so you might want to visually compare them to see if you can spot any obvious differences. Sometimes there are multiple landing pads for the R and C, and jiggling them to different positions changes the resonant tank configuration - so check that they 'look' identical in layout as a first pass.

[whaleygeek]

Second pass might be to see if you can measure the R's and C's (unpowered) with your fluke to see if there is any difference in values.

Also, if your antenna configuration/style is different, it's possible we may need to fiddle with the filter parameters and attenuation to correctly match to a different antenna. The Antenna on the Energenie board is pre-matched with the values we load into those config registers at startup. If you have Arduino code for those other RFM69 modules, check what values they write to the following registers and adjust in pyenergenie accordingly...

0x11 PA selection 0x12 PA power ramp 0x5A high power PA 0x5C high power PA

[whaleygeek]

I think if you over-power the antenna outside of it's spec (might be different if it is a chip antenna rather than a bit of wire), you might get some saturation that could cause some horrible noise across the spectrum

[whaleygeek]

Those sockets can learn up to two codes. If you learn the pyenergenie first, then put it back into learn mode and press your RF remote, the strip should then respond to both (both will be sending the same code, but with a different clock skew, but as the legacy plugs learn almost anything that looks like a bit pattern, they will now respond to both).

If you learn again, the earlier learnt item is overwritten (only 2 stored codes can be stored in the memory of those legacy devices)

[whaleygeek]

Also worth sending the FFT plot of the spectrum (I might have put an FFT plot in the project already but it's easy to add right at the receiver end, not at the demod end, if it is missing. You'll see a peak mid plot when you press the button or run your script - will be interesting to see what the signal to noise ratio is on that FFT plot when transmitting (a) from pyenergenie and (b) from the RF hand remote.

[whaleygeek]

Also, to correctly attribute some external help I had here, I learnt how to build that GRC OOK visualiser by following this great online SDR course, one of the later lessons (lesson 8) shows you how to build an OOK decoder.

https://greatscottgadgets.com/sdr/

[megatron-uk]

Since you've been such a massive help, your wish is my command:

ENER002-C

ENER314-RT

It's not a huge difference, but the SNR of the hand remote is better, I'd say about 3db.

In regards to the layout of the pcb, the original RF69W no-name board I've got appears (visually) identical to the ENER314-RT in terms of number and placement of the components. The module on the Adafruit carrier board is clearly different though as it's supposed to be the high-power RF69HCW variant. The orientation, antenna pads, oscillator shape and number/location of passive components all differ.

Here are the modules up close:

Energenie RF69W

No-brand RF69W

Adafruit RF69HCW

But, here's one that's going to blow your socks off....

Using the same relearn technique as with the ENER314-RT I've just gotten my original, £4 RF69W module to work. Yes, the crappily soldered, no-carrier board one in the image above.

But you have to set the power-strip to relearn again. Using the same code that I just forced it to learn with the ENER314-RT module. This means that it's not only the house code that pairs the devices, but it's a specific combination of house code and radio module.

Here's the FFT trace for it:

That's with a trailing wire as an antenna, so it's definitely not as good as the ENER314-RT in its present incarnation. Sufficient to control a socket on my desk about 4 feet away though.

There's clearly a difference in signal that the sockets are picking up on between radio modules, this probably means that if you've got multiple RF69 modules around the place in a fairly large home automation setup, they're likely not all able to control the same legacy devices.

[megatron-uk]

.... it also means that the house codes from the remotes are essentially a red herring. As, at least in my case, the sockets clearly don't recognise those existing, learnt, codes when they're transmitted by pyenergenie using any of those radio modules above.

[whaleygeek]

Thanks for the plots, interesting info.

There is some additional background that might explain all that. When I picked up the C demo code from Energenie, I re-engineered it all from first principles, but had to use their code as the only known reference (as there is no specific data about how the legacy plugs work apart from their C code). I had similar correspondence troubles to you initially with the RF hand controllers.

I bought a SDR setup and installed GNURadio, learnt how to build an OOK monitor from those videos I sent a link to earlier, and monitored the output from both pyenergenie and my RF hand remote. I noted an error in my baud rate calculations and corrected that in the register setup, but then things got a bit strange and pyenergenie stopped working.

On further investigation by plugging the audio output feed I created in GRC to my scope and using cursors, I discovered the bit time was in correspondence with the RF remote, but that there was a spurious extra bit at the start of the preamble, and this seemed to be confusing the legacy devices.

I monitored the DIO line as I explained earlier and the spurious bit wasn't there. So I fiddled with the transmit sequence and managed to remove that spurious bit before the preamble and it all burst into life again. The same code from the RF remote coded into pyenergenie switched the same single learnt code. My hypothesis was that the spurious bit was a PA power-up facet.

I don't unfortunately have sight of any of the design details of the legacy OOK devices nor their source code, so the only reference is the Energenie original C code, which they basically modified from a manufacturer (HopeRF) supplied demo, from what I can see.