RFM69(HW) 433Mhz interference with other home devices?



  • Hi,

    I'm currently testing a mysensors setup with:

    • RPI4 GW (32bit OS) with RFM69HW 433MHz, SW Signing and RFM69 encryption
    • Sensebender node with RFM69HW 433MHz, HW signing and RFM69 encryption and SHT21
    • Arduino mini pro-based node with RFM69 433MHz, HW signing, RFM69 encryption and SHT21

    So far, I was able to get the 2 nodes working, reporting basic temperature and humidity.
    It doesn't work flawlessly all the time, I must say. Sometimes it just stops working and I don't know why. After a reboot on the PI/nodes it gets back on track. I'm still trying to find some patterns.
    To know it is working, I simply "tail -f /tmp/mysensors.log" file. Not sure if it's the best way to do it, but it's the possible one so far because I don't have any northbound controller configured yet.
    [Edit] It seems that when MySensors GW "stops working" (or stops logging, to be more accurate) is when the other 433MHz devices don't work either. Nevertheless, it seems to recover by itself. May be a node that enters a faulty state and jams the frequency. I'll continue testing.

    Anyway, I've realized that my other 433MHz devices don't work anymore. For instance, the garage gate, that works with a normal 433MHz remote, simply stopped working. I'm also still trying to find some patterns, but it seems that if I reboot the nodes I can use the garage gate for a while. I'll be doing further testing and will report here.

    Meanwhile, I'd just like to ask around if this is a common phenomenon and if so, what can be done to overcome it.

    Summing up everything up: Is it common to have 433MHz interference with other home devices when having a Mysensors NW mesh based on RFM69(HW) 433MHz (with signing and/or encryption)? If so, how to overcome it?

    Cheers,
    Joaoabs


  • Hero Member

    Hey @joaoabs ,

    no this is not an intended behaviour. The usage of the frequencies 433 MHz, 868 MHz etc. is limited by regulations. The devices aren't allowed to continously send packets and block a frequency.

    I myself am using RFM69(HW) but in 868 MHz mode and Homematic devices that use the same frequency. Works without a problem!

    Try to figure out which node jams the frequency by disabling all nodes and switch them on one by one and checkout at which time your garage door stops working.



  • I've seen some blocking on a RFM69 868 MHz node wich was running on a very low voltage. I have a Lime SDR that I took in Spectrum Analyzer mode and was able to see the jamming!



  • Well,

    After removing some counters cycles on a node, I can state I have the MySensors GW working non-stop for 24h now with 2 nodes without any noticeable issue. Both nodes are using Encryption and Signing.
    The nodes are simply reporting temperature and Humidity every minute or so. Will try now the behavior with actuator nodes (relay).

    In the log I can see it isn't perfect yet. There are quite a few signing failures. The node #80 is 6 meters away from the gateway with line-of-sight, which concerns me a bit because when I place the nodes in the final locations, I'm sure the radio path will not be better than this. I'm assuming that the signing is failing due to radio issues - I might be wrong.

    Dec 03 17:46:12 DEBUG TSF:MSG:READ,80-80-0,s=20,c=1,t=0,pt=7,l=5,sg=1:14.0
    Dec 03 17:46:12 DEBUG SGN:BND:NONCE=326B170BBDFD3CE66C91DE485E2C465D98434C6917C4D7269DAAAAAAAAAAAAAA
    Dec 03 17:46:12 DEBUG SGN:BND:HMAC=602409810E55FA10445022FEECCB08697878B9F0FD1652B9303FF9D543B240FD
    Dec 03 17:46:12 DEBUG SGN:VER:OK
    Dec 03 17:46:12 DEBUG GWT:TPS:TOPIC=mysensors-out/80/20/1/0/0,MSG SENT
    Dec 03 17:46:13 DEBUG TSF:MSG:READ,80-80-0,s=40,c=3,t=16,pt=0,l=0,sg=1:
    Dec 03 17:46:13 DEBUG SGN:SKP:MSG CMD=3,TYPE=16
    Dec 03 17:46:13 DEBUG SGN:SKP:MSG CMD=3,TYPE=17
    Dec 03 17:46:13 DEBUG TSF:MSG:SEND,0-0-80-80,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
    Dec 03 17:46:13 DEBUG SGN:NCE:XMT,TO=0
    Dec 03 17:46:13 DEBUG TSF:MSG:READ,80-80-0,s=40,c=1,t=1,pt=7,l=5,sg=1:63.0
    Dec 03 17:46:13 DEBUG SGN:BND:NONCE=854FF116C7AA8566A8176AAA1A319BE95D90D8417AA92EDB3EAAAAAAAAAAAAAA
    Dec 03 17:46:13 DEBUG SGN:BND:HMAC=C54BAC9E3FE050E9170CEE17AB23836A98EA270ADFC089A4523E27610D587E88
    Dec 03 17:46:13 DEBUG SGN:VER:OK
    Dec 03 17:46:13 DEBUG GWT:TPS:TOPIC=mysensors-out/80/40/1/0/1,MSG SENT
    Dec 03 17:46:14 DEBUG TSF:MSG:READ,80-80-0,s=21,c=3,t=16,pt=0,l=0,sg=1:
    Dec 03 17:46:14 DEBUG SGN:SKP:MSG CMD=3,TYPE=16
    Dec 03 17:46:14 DEBUG SGN:SKP:MSG CMD=3,TYPE=17
    Dec 03 17:46:14 DEBUG TSF:MSG:SEND,0-0-80-80,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
    Dec 03 17:46:14 DEBUG SGN:NCE:XMT,TO=0
    Dec 03 17:46:14 DEBUG TSF:MSG:READ,80-80-0,s=21,c=1,t=0,pt=7,l=5,sg=1:8.0
    Dec 03 17:46:14 DEBUG SGN:BND:NONCE=BA1DABAF567A20CEABF5CFC35D638E7A1A3E5CF94204D96935AAAAAAAAAAAAAA
    Dec 03 17:46:14 DEBUG SGN:BND:HMAC=8735CDA75D1148784B3D73601E7A4199DB44CFD039C75584EBA9ADD24897355A
    Dec 03 17:46:14 DEBUG SGN:VER:OK
    Dec 03 17:46:14 DEBUG GWT:TPS:TOPIC=mysensors-out/80/21/1/0/0,MSG SENT
    Dec 03 17:47:15 DEBUG TSF:MSG:READ,80-80-0,s=20,c=3,t=16,pt=0,l=0,sg=1:
    Dec 03 17:47:15 DEBUG SGN:SKP:MSG CMD=3,TYPE=16
    Dec 03 17:47:15 DEBUG SGN:SKP:MSG CMD=3,TYPE=17
    Dec 03 17:47:16 DEBUG TSF:MSG:SEND,0-0-80-80,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
    Dec 03 17:47:16 DEBUG SGN:NCE:XMT,TO=0
    Dec 03 17:47:16 DEBUG TSF:MSG:READ,80-80-0,s=20,c=1,t=0,pt=7,l=5,sg=1:14.0
    Dec 03 17:47:16 DEBUG SGN:BND:NONCE=EF0F98582847EC766BDBC6FB13B7920FCB68CA984C600DA0FBAAAAAAAAAAAAAA
    Dec 03 17:47:16 DEBUG SGN:BND:HMAC=7AB74FA813953F8965393306FFF67FCA429DCE7F293E08357B9AAE4B0D33C5C1
    Dec 03 17:47:16 DEBUG SGN:VER:OK
    Dec 03 17:47:16 DEBUG GWT:TPS:TOPIC=mysensors-out/80/20/1/0/0,MSG SENT
    Dec 03 17:47:17 DEBUG TSF:MSG:READ,80-80-0,s=20,c=1,t=0,pt=7,l=5,sg=1:14.0
    Dec 03 17:47:17 DEBUG !SGN:BND:VER ONGOING
    Dec 03 17:47:17 DEBUG !SGN:VER:FAIL
    Dec 03 17:47:17 DEBUG !TSF:MSG:SIGN VERIFY FAIL
    Dec 03 17:47:17 DEBUG TSF:MSG:READ,80-80-0,s=20,c=1,t=0,pt=7,l=5,sg=1:14.0
    Dec 03 17:47:17 DEBUG !SGN:BND:VER ONGOING
    Dec 03 17:47:17 DEBUG !SGN:VER:FAIL
    Dec 03 17:47:17 DEBUG !TSF:MSG:SIGN VERIFY FAIL
    Dec 03 17:47:18 DEBUG TSF:MSG:READ,80-80-0,s=20,c=1,t=0,pt=7,l=5,sg=1:14.0
    Dec 03 17:47:18 DEBUG !SGN:BND:VER ONGOING
    Dec 03 17:47:18 DEBUG !SGN:VER:FAIL
    Dec 03 17:47:18 DEBUG !TSF:MSG:SIGN VERIFY FAIL
    

    We can see in the log that the same node/child have both successful signing as well as failed signing.

    This signature failure isn't critical for temp/Humidity readings (even if it fails now, it will be fine in the next round), but for actuator nodes (where you really want something to be turned on/off) it will be a concern.

    I haven't noticed any other 433MHz interference (but only used the garage remote a couple of times during the day).

    It can be that a buggy node sketch makes the RFM69 unstable and jams the frequency. One of the side effects is that there are no entries in the GW log and therefore it seems is it down. Well, something to take into consideration when coding the nodes.

    My 2 cents


Log in to reply
 

Suggested Topics

  • 10
  • 3
  • 5
  • 18
  • 2
  • 2
  • 1
  • 12

196
Online

9.9k
Users

10.4k
Topics

107.3k
Posts