Archived Forum

I switch some Home Easy sockets using the Open Energy Monitor Pi2, the open source home automation system OpenHAB, and a RFXCOM transceiver. That setup supports many different 433MHz devices. OpenHAB is open source, and the RFXCOM costs around 100 Euros.

OpenHAB is very good once you get into it but the learning curve is practically vertical in places. You can also use the feed values for onward processing if you are running a recent version of OEM using MQTT which OpenHAB understands.

Hmmm looks good but I am after a more low cost, integrated solution that utilises the existing emon components if possible. Is the RFM69CW found on the RFM69Pi a transmitter as well as a receiver?

If so then providing the frequency is the same as the wireless plugs then sureley I can use it to send switch commands to the plugs as well?

Most of the remote mains sockets use a OOK (on-off-keyring) protocol, although the rfm12 and rfm69 are both capable of OKK it is not supported in the "compatibility mode" of JeeLib which is the current implementation for the rfm69.

​So whilst you could use the RFM69Pi for OOK you could not retain compatibility with other "OEM" devices at the same time. You could employ a second "Jee" device, eg a JeeLink (only 1 uart on the GPIO which is taken by the first "Jee" device ie RFM69Pi) (~£18-30) or you could attach a rfm01,12 or 69 (~£6) via the Pi GPIO SPI for OOK several blogs and guides out there OR you could venture into adding a cheap OOK TX (~£3 ebay) to either the GPIO (again lots of blogs on this) or the RFM69Pi's GPIO to make the OOK TX part of the RFM69Pi in a similar way to the provision on the emonPi (which I don't think has been utilised yet)

I think this is something that lots of users would like to see but there are so many different devices, libs and protocols that it gets a bit over whelming, but I expect there are just a few root device designs that are badged and reproduced by many manufacturers and then each is "hacked" by many users for a wide range of different applications and platforms etc which results in an uncountable number of small unverified solutions to wade through

When will the manufacturers work out publishing (or at least confirming) their protocol would make their product more desirable, as protecting their IP does them no favors, any tom, dick or harry can (and has) produced their own ?

Did you see Control RF Mains Plugs using the RFM12Pi 

Paul 

Also RFM12B OOK, you can find quite a bit searching OOK

Hi Paul, I know this is an old-ish thread, but my question applies to your last update - any reason why I can't just disable compatibility mode and use my RFM69CW as an OOK transmitter? I only have 2 nodes, emonTX and RPi with RFM69Pi board, both have the RFM69, so I am thinking I don't need to worry about compatibility mode?

Also as RFM69Pi board doesn't have the dedicated pins for attaching an OOK transmitter like on the emonPi board, I am not clear yet whether I can add an OOK transmitter to the RFM69Pi board, or anywhere else on the RPi?

@Paul,

So the use case would be a stream of 'normal' (i.e FSK) packets flowing between emonTx and RPi, with the occasional OOK command squeezed in, sent from the RPi?  Would the potential loss of a packet or two during this action be manageable/acceptable?

Superficially, the RFM69 has some great built in OOK capabilities - switch the mode to OOK and packets will interchange in this mode instead of FSK.  The rub is that the packet envelope (preamble, synch etc) is present and required - this is usually a clash at bit level with the command structure required by the plethora of OOK devices out there.

It is not a direct solution, but have you seen the work on RFM69 OOK over at sevenwatt.com ?

I know this discussion has moved onto using the RFM kit to do the OOK but of course transmitters and receivers for RF are very cheap.

I came across this great tutorial from Rui Santos about controlling switchable plugs using esp8266s.

One thing in the tutorial that is really useful is a section on how to work out what coding is being used by the plugs and remote contols. He explains how to use the RCSwitch arduino library to identify the codes. I had been trying to do this using other tools that display the actual waveforms and had given up. I'm going to go back to the light switches I was trying to hack using the method he describes.

I'll also add this link to one of the other OOK discussions from a year or so ago.

http://randomnerdtutorials.com/esp8266-remote-controlled-sockets/

I've just published a blog post using emonPi + OOK Tx to control LightWaveRF plugs, works very well for me: http://openenergymonitor.blogspot.com/2015/11/remote-control-of-lightwave-rf-plugs.html

@Ian - All current OEM devices and firmwares currently run using the rf12 library from JeeLib, for rfm12 devices this is native and for rfm69 devices it is a "compatibility mode", there is ook functionality in the rf12 lib only for rfm12's, it isn't available to the rfm69's in compat mode. to switch to the rf69 lib you would need to (at least) replace the rf12 functions used throughout every firmware on your rf network with rf69 functions, I haven't tried this so I cannot comment on whether there are any other requirements.

and then whether the fact rfm69's have ook capability means they can handle ook at the same time is another question. As far as I recall the rfm12 implementation (which wasn't native ook support) had to be switched from one mode to the other. 

@emjay - I think that would be the intention and as desirable as that is to get the rfm69 doing both, I personally would not entertain the packet loss when a dedicated ook tx is only a couple of quid. you are in a better position to confirm my less informed opinion that although there would still be some "effect" of 2 433 devices in close proximity but that would have much less impact than the effective blocking incurred by stopping the reception, switching to ook, transmitting and then switching back to resume reception?

@Glyn - excellent article I did read it through but haven't had a chance to try any of it out yet, but I do intend to. Maybe it's time to start compiling a ook wiki, there are a lot of different protocols out there and it would be good to promote re-using existing devices rather than buying new.

@Bramco - Although this particular thread was more about using an existing rfm2pi to ALSO operate ook devices I too think dedicated hw is the way to go, hopefully Glyns blog post and linked guides will all apply to all (or most) ook devices with a little editing once the "right" protocol is determined.

@Ian - if you have the RFM69Pi the extra IO in all accessible on the rfm gpio so adding a ook tx from the OEM shop and a bit of wire for an antenna is all you would need hardware wise and then you could just add the ook code to the rfm2pi sketch and make it accessible via the serial port or you could lift the rfm69pi using "stackable headers" to access the Pi gpio pins, either is possible and I would expect both to be simpler and better performing than trying to "dual purpose" the rfm69 transceiver.

Paul

@Paul,

It is unlikely that a faint incoming packet will avoid getting trodden on by the blast of an outgoing OOK command - the RFM69 max Rx signal input spec is quite generous, so there is some headroom there to avoid actual damage to the front end. But even with the OOK channel spaced as far as possible away in the same band, the RF chip front ends are just not that selective to cope unaided. Splitting as 433 OOK, 868 FSK will see a similar but much weaker effect, as long as the obvious second harmonic slot is avoided.

The OOK command packets are usually short on bits, but relatively long since the modulation rate is typically slow - so the Rx is blinded for this amount of time + some recovery time for the swamped front end.  I guess it all comes down to duty cycles plus a priori knowledge of the incoming packet pattern - e.g. timing the OOK command just after a successful incoming FSK packet decode is likely to be a "quiet" period.

I'm guessing the effects of either method could be minimized by using ack's. could a "radiated block" be avoided/reduced by putting some distance between the antenna? The alternative sounds complex to implement, not to mention no way of knowing (in most instances) what packet maybe due therefore it's size.

Possibly this is another good reason to consider polling the rf devices rather than just waiting for packets turn up, then it would just be a case of slipping the ook command into the schedule, same would apply for any outgoing commands, fsk or ook.

Paul

@Paul,

The problems of co-located Tx/Rx blocks have been there since the first spark transmitters - hence most RF communications channels are half-duplex to enforce a your turn/my turn discipline.  The common methods of separation are:

• Distance:  Not effective here - the OOK modules radiate furiously from the tank coil + the shared ground plane will cross-couple.
• Frequency:
  • same band/ different channel, unlikely to be enough due to Rx front end overload

  • different bands (433, 868Mhz) promising - may still need added Rx selectivity in antenna path

• Time:  the most promising - either random, based on low duty cycles with error correction if required for lost information or polled/time slot based as you suggest.

Wouldn't the typical use case have rare OOK command blocks compared to the data collection traffic? This would suggest the error correction method, provided the total traffic in the channel is low enough to accommodate the extra ACK/NACK activity.

re Distance - Is this a definite show stopping level issue or does it just not work well? the ook tx has been located right by the rfm on the emonPi and can even share the antenna, I was surprised by this but thought it unlikely to be untested, but the common ground plane hadn't crossed my mind.

re Frequency - Not a definite fix and the frequency restrictions would be a bind, both for users in countries  that only have the one band and for users that already have devices to connect to and/or network traffic to avoid. (plus some extreme IoT'ers may wish to run fsk and ook on both 433 and 868).

re Timing - I definitely think this by far the most promising, we currently struggle with a handful of nodes, with better synchronization all 32 (or 255 in rfm69 native) nodes could be used with room for ook and other transmissions too.

The typical use currently would probably be occasional  ook and regular data receipts over fsk, but it would be good to not be dependent on minimal use.

Could the ground planes be filtered? or would extending the power and data to a remote tx/rx rather than extending the ant work any better? like an active ook dipole tx & ant with a length of 3 core for pwr, gnd and data.

Paul