Create a UART driven dongle

[whaleygeek]

Idea partly inspired from here: https://github.com/whaleygeek/pyenergenie/issues/77

And mentioned here:

https://twitter.com/jmigreen/status/1123699248569229315

@jmigreen

Idea would be perhaps an Arduino Uno that drives the energenie radio via SPI - then a spi_uart.c that instead of using gpio_rpi.c, it sends via a serial port to the Arduino which then waggles the SPI lines to communicate with the RFM69 on the Energenie radio board.

This would allow the whole system to be run up on PC or Mac and tested away from the Pi.

[whaleygeek]

@jmigreen I have this little module currently in development, and am part way through porting the C drivers to it. When it is finished it will basically be a UART to Energenie interface you can plug into any computer. I'll also plan to write a marshalling library to be a drop-in replacement for the .so in this project, so you can seamlessly switch the .so and then run all this python code unmodified on a Mac/PC/Linux machine.

Might also interest @Achronite for the NodeRed library to give it a bit more of a wider user base across more platforms.

[whaleygeek]

RFM69HCW (sparkfun baseboard) now working with ATTiny85 - can switch any Energenie legacy (OOK) device on and off now.

Note the HCW part uses the PA_BOOST pin for TX instead of the RFIO pin and has an on-board 20dBm PA, so you have to set some registers different to the standard Ener314-RT board radio to get Tx to work.

[Achronite]

@whaleygeek hmmm interesting. Will it work for FSK/OpenThings too?

[whaleygeek]

@Achronite That is the plan, yes. Also want to write an OOK receiver as part of this work, so my devices can 'be' custom Energenie devices. One mode of it though will basically be an OOK/FSK dongle that allows me to run the full pyenergenie stack on my Mac instead of the Pi.

[whaleygeek]

I've got some interesting progress on this today. I have a little device that plugs into a USB socket on my Mac, appears as a serial port to the Mac. I can send a string of commands to it and send a 'looping schedule' of messages, that it then works through step by step and switches on and off any legacy (OOK) device.

The protocol is a very simple textual protocol that can be used from a serial terminal by a human, but also easy for a Python script to generate.

Interestingly, as I have full control over the burst length and delay slots in the schedule that is downloaded, I can do some clever things with interleaving messages to different devices to get better switching performance overall.

e.g. This command string sets address to CCCCC, sends 10 bursts of ON commands to channel 1 (so I can make the device learn the code), then runs a loop 5 times turning the switch on and off with 5 bursts and a 1 second delay between each. $ sets hex mode, @ sets the address to the previous value, V sends an ON command . is a delay, 10X sets the repeat times to 10, 5X sets the repeat times to 5, ^ sends an OFF command. { } are loop nests so 5{} repeats the commands in the loop 5 times.

    $CCCCC@ 10XV. 5{5XV.^.}

[jmigreen]

@whaleygeek That IS pretty cool. I had started to use Visual Studio Code to do remote editing of the python code on my Pi. Wish I had even half of the engineering knowledge required to make this thing happen. It looks awesome.

[whaleygeek]

Thanks @jmigreen !

I have the OOK (legacy) tx mostly wrapped up and working now. I just want to add a bit of extra error handling and a power level setting feature, then I will publish the legacy-tx in a new github repo, and then bring it in here with a UART C binding and provide a .so file that if switched in instead of the existing .so library, it functions identically for legacy-tx.

This will allow people (like you!) to then use all the legacy devices on PC/Mac/Linux without a Raspberry Pi.

I'll publish a simple circuit diagram and list of parts in the other github repo, the circuit is pretty easy to build on vero-board or on a breadboard even, as all the parts are 0.1in spacing.

[whaleygeek]

It's worth noting that I am thinking of re-writing the C code in this repo to directly support the new little command protocol of this new device as well, as it has some neat scheduling facilities for fast interleaving of messages across a range of different devices, and will also eventually allow a queued message to be stored and auto responded to, for sleepy devices like the eTRV.

[whaleygeek]

@jmigreen OOK transmit, FSK transmit, FSK receive all working now. Here are two separate voltage/power reading devices in my house, and one message from a neighbours device that fails the CRC check!

[whaleygeek]

@Achronite This work is progressing, slowly but surely!

[whaleygeek]

I took a bit of a diversion and created this for the CurrentCost IAM devices, but am moving back to the Arduino-Energenie work again: https://github.com/thinking-binaries/current-cost

Note that the CurrentCost is a selective slice of the Arduino Energenie project. It was so close that I just reused most of the code. @jmigreen @Achronite