433MHz interference and Logitech Harmony Ultimate Hub (universal remote)

I have had my OEM system (consisting of an EmonPi two EmonTx V3’s and several EmonTh V2’s) for about a month and a half. System is performing well and I am getting to grips with open source electrical and environmental sensor monitoring. All the various nodes are are registering in the inputs of local EmonCMS; even have SMA inverter monitoring and BMW connect drive monitoring via EmonHub to create specific nodes, all have many feeds logging on these various inputs. Nevertheless, over this period of time I have noticed that a node would drop out or that EmonCMS created a new node 5, 7 or 8 etc. with updated time of several hours or NA

I have not taken much notice of this (until last night) and have put it down to my inexperience and I have made an error with something; I have usually just deleted these spurious node inputs and every thing is fine. Last night while switching on my television and all the other devices to watch and hear programmes and different forms of media I notice that one device the audio SPDIF switch did not respond using the universal remote (Logitech Harmony Ultimate) and had to be individually switched on. I did not think much of it at the time but later when I was looking at the EmonCMS I noticed that one of the EmonTx’s had not been received, coincidently for the period of time I had these devices on. I presumed interference with my 433MHz spectrum and was therefore, wondering whether it would be possible to change the frequency of the system to 868 MHz in the firmware etc.

As the OEM system is new it is using the RFM69CW 433 MHz and have looked this up on this forum related to interference etc. but found that there are problems with the 868 MHz frequency and 4G. Not to mention more expense changing the RFM69CW modules and antenna (with potential interference form 4G) and changing the audio/visual equipment is prohibitively expense also.

Can anybody experienced in signal Tx/Rx offer a ‘cheaper’ solution/s?

You can probably improve the signal strength in the transmitters, and the sensitivity of the receivers, by converting the antennas to dipoles, or adding a ground plane. If it’s other transmitters being received that’s the problem, you don’t want to improve reception! It might be possible (I’d need to look at the RFM69 data sheet) to turn the sensitivity down, which should make it less likely that ‘foreign’ transmitters would be picked up. You could also reduce its sensitivity by de-tuning the antenna. The best way would be to turn down all the transmitters to the minimum necessary to adequately receive a signal, but that probably won’t be possible, unless you can de-tune their antennas. Is it possible to relocate the receivers that are affected (is it only the emonPi)?

To add to Roberts comments above.

Changing the frequency in FW isn’t a real option as the range on 433 stuff (antenna’s and support components) running at 866 is so short the unit would need to be on top of each other, in which case avoid the RF issues altogether and change to wired serial connections.

For the frames to reach emoncms they have to go through 2 sets of checks, the first is JeeLib CRC checks, which includes a fixed pre-amble and a defined group id before the interesting bits and the data payload itself.
If your other equipment is always/regularly using a similar pre-amble and format, you may get away with just changing the RFM group (currently 210) that would require changing at each device on the network and there are 255 to choose from. However if your equipment is just randomly slipping through the CRC checks because of an ever changing payloads it might affect all or most of the 255 channels.

The second set of checks is in emonhub, where “known nodes” are checked against the datacode(s) definition, the rogue nodes you see in emoncms are getting there as there are no definitions in emonhub.conf for emonhub to check against. So If (for example) you are getting “node 3” popping up regularly, you could define “node 3” as something quite specific and out or normal range so it always fails this test. eg

    [[3]]
        [[[rx]]]
            datacodes = b, h

only if something posing as node 3 is exactly 3 byte long will it be allowed to pass on to emoncms, any other size and it will be discarded. This is a work around and the consequence is that emonhub.log might fill up with “discarded” payloads but it should save you having to delete them on a regular basis.

As always, there will be loads of info to help you resolve this in emonhub.log, the RSSI values for both the offending payloads and the ones you need to keep. the frequency at which this is occurring, bear in mind not all the roque entries will have reached as far as emoncms, setting quiet = False in the [[RFM2Pi]] [[[runtimesettings]]] will ensure you also see all the payloads that fail JeeLib’s CRC in emonhub.log, you will also see the make-up of those that to make it through, with will help you block them.

It’s not only the EmonPi that screenshot was just an example, unfortunately I’ve not captured any others with screenshot. It would appear to be totally random, which node is affected by this phenomenon. I presume it would depend on when the A/V is switched on and what node/s are Tx/Rx so, they are coincident.

I’ll try changing the RFM group first.
Why was 210 chosen, was it for a specific reason?

Not to my knowledge, I seem to recall early JeeLib had a narrower range of groups like 1-211 (or something like that) so at some point it might have been the highest default group number that wouldn’t break backward compatibility for early JeeLib adopters, but I’m guessing a bit there.

There is no performance hit for any particular value(s), it is just a string of 8 bits that match or not, the frequency etc remains the same, there are no true “channels” as such.

BTW, can I just clarify the settings you mention regarding the emonhub.conf. I have:

[[7]]
nodename = emontx4
[[[rx]]]
names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
units = W,W,W,W,V,C,C,C,C,C,C,p

as an example, all other nodes are set up similarly; reading the EmonHub Configuration under section “3. ‘nodes’ Configuration - datacodes” by putting

[[3]]
datacodes = b, h

as you have suggested, infront of h, h,… would this not affect how EmonHub reads the transmitted packet by emontx4 (in this example); or am I miss understanding what you mean (still rather new to OEM settings and processes) or where it should go in the emonhub.conf?

Firstly, My bad. I posted the original emonhub config not the emonpi variant config which would require another sub-level eg

[[3]]
    [[[rx]]]
        datacodes = b, h

So I have now corrected my original post to avoid the same confusion to other readers.

Ok, so the example i have given is basically defining a non-existent node so that if any other devices in the house get through the JeeLib CRC checks, they will fail to get this check unless they are nodeid 3 and exactly 3 bytes long (data part of the payload).

So (for example) if you already have nodes 7, 8, 9 and 10 set up then adding dummy nodes for 1 to 6 and 11 to 31 would stop any non-defined data getting through unless it happens to be 3 bytes long (datacodes = b, h).

In reality you only need to set up dummy nodes to block the actual node ids that appear in emoncms and the format of the payload can be anything that the rogue payloads don’t fit, I chose a low odd number as most data types are 2,4 or 8 bytes.

We are not trying to edit the existing nodes here we are trying to block the rogue “new inputs” in emoncms, currently they have free pass through emonhub since there is no definition for them, hence the dummy nodes.

Ah yes, I understand now, this is for any non-legitimate nodes or unused nodes, which are not logging to feeds.

There is probably more investigation and amelioration possible. First check the spec of the audio SPDIF switch - is it FSK or OOK and what is the nominal frequency shown? Depending on the brand and especially if it is OOK, the actual frequency used varies considerably (often not crystal defined).
When the Harmony fakes up the control signals for the SPDIF switch it is probably swamping the EmonPi receiver section - fortunately the 433 MHz ISM band is quite wide and you could move the OEM center frequency some distance away from the interfering source within the same band.
This is a parameter level change only, not requiring hardware changes.
You could at least run an experiment by getting consistent failure (e.g. turn the quiet = Flase flag on and see a stream of bad CRC packets with the Harmony aimed at the EmonPi - then shift the Rx frequency of interest to one edge of the ISM band and repeat the test)
The frequency is just a parameter in the init call to the rfm12 support library running in rfm69 compatibility mode - probably easier to get at this on the EmonPi for a trial than the recompile/reburning needed for the sensor nodes if this is successful.
(Or just buy a different SPDIF switch that is not in the 433 MHz band :smirk: )

Your last option is the last resort for me, if all else is unsuccessful.

I’m rather a ‘newbie’ to the OEM hardware and open source software so, you will have to allow me some intellectual room while I acquire the level of knowledge require to experiment and make these kind of changes to my OEM system. I was only at the level of just starting to experiment with the voltage and CT calibration etc. but want to get an as stable and interference free system as is practically possible before continuing on with the calibration and then explore other suitable customisations and such.

I think, I understand the principle that you have mentioned i.e. find out, which part of the 433 MHz ISM band (range 433.05 - 434.79 MHz with a centre frequency of 433.92 MHz) the Harmony is working at; then change the frequency of my OEM system either higher or lower than or away from this frequency in the parameter the rfm12 support library?

In this experiment I will need to:

  • Change the “quiet = False” in the EmonHub.config

  • Use the Harmony remote system in close proximity to the EmonPi

  • I will be able to see the results in the EmonHub log file

  • Adjust the frequency parameter

in the init call to the rfm12 support library running in rfm69 compatibility mode

(this is where my level of knowledge dips - where do I find the appropriate file to change the 433 MHz parameter on the EmonPi?) I assume these are config files or such that I can edit with Vim or nano from CL

I can then iterate this process to see if or what part of the frequency band the harmony remote system does not have a significant effect on my OEM system, is this correct?

One further ask, and this might seem a rather naive question but, is the network group (OEM default 210) related to the level within the 433 MHz frequency band it is functioning? So, if the 433 MHz band can have 255 possible network groups (or is it 256 i.e. 0-255, is it possible to a network group zero?) then the a network group 210 would therefore be working at approximately 434.48 MHz?

You are on the right track - the carrier frequency change is done by selecting a different value in the C code for the RF Module init - others can probably point you at the required files.
The group number is a purely packet encoding convention - nothing changes about the physical parameters of the TX/RX packet.
Search on RFM12 over at jeelabs.org if you really want to dig some more.

P.S. It might be worth trying the original remote for the SPDIF switch - the cloned signals from the Harmony may be a poor copy.