Problems with the neighbours

[Stevanov]

I'm a volunteer at the local Makerspace and we use mysensors as a nice and simple way to hook up peoples projects to our local network without having dozens of ESP8266s or whatever all over the place. About half a year ago a new tech company moved in next door and it seems that during the evening hours the employees there get to work on hobby stuff because since then our Controller is being flooded with temperature, gas, light, motion etc, sensors that isn't ours. There are at least 40 sensors in the list that aren't created by us. Weve also had problems of their sensors that have an ID that one of our sensors also uses, overriding stuff in our database, creating some very odd power usage and temperature graphs.

I've thought of solving this with the signing or encryption thing. But it seems that that is computationally complex and wed need to add the little SHA chip to most our devices. Sadly i think we need to reprogram all our stuff. It doesn't seem like the neighbours mind our sensors messing with their network.

My question is does anyone have any recommendation? We do have code available for almost all devices in our net so it should be doable to reprogram most of them. I'm not so much worried about security, it's just annoying that the neighbours' stuff gets into our database.

Maybe theres an option to switch channels or to do some sort of handshake, a passphrase, or whatever? The signing and security page on the mysensors website seems sort of theoretical and i cant really find any examples of what to do. (I can't imagine it's as simple as only setting #define MY_SIGNING_SOFT and #define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 in every sketch)

Any input would be very much appreciated!

[kted]

It's even simpler than that. Just add a line as the one below:

#define MY_SIGNING_SIMPLE_PASSWD "mypassword"

[kimot]

@stevanov
It seems, that both of you use MySensors in "outofbox" state.
You do not write which radio module are using.
If RFM69 - change netwotk ID, with NRF24 change channel or network ID
Somewhere in config files.

MyConfig.h

#define MY_RF24_CHANNEL (76)
/**
 * @def MY_RF24_BASE_RADIO_ID
 * @brief RF24 radio network identifier.
 *
 * This acts as base value for sensor nodeId addresses. Change this (or channel) if you have more
 * than one sensor network.
 */
#ifndef MY_RF24_BASE_RADIO_ID
#define MY_RF24_BASE_RADIO_ID 0x00,0xFC,0xE1,0xA8,0xA8
#endif

/**
 * @def MY_RFM69_NETWORKID
 * @brief RFM69 Network ID. Use the same for all nodes that will talk to each other.
 */
#ifndef MY_RFM69_NETWORKID
#define MY_RFM69_NETWORKID (100)
#endif

Of course you must reprogram all nodes and gateway :o(

Or talk with your neighbours and ask them using different network ID if they only starting building their network and have got smaller number of sensors.

[alowhum]

@kted said in Problems with the neighbours:

#define MY_SIGNING_SIMPLE_PASSWD "mypassword"

Or you can use:
#define MY_ENCRYPTION_SIMPLE_PASSWD "mypassword"

In this case it uses less memory, and hides the actual data from your neighbours. So I prefer this option, personally. If you are using the RFM69 radio, you even get encryption for 'free', as it's part of the hardware.

[Stevanov]

Thank you all, i'll definitely try to change channels and use the

#define MY_ENCRYPTION_SIMPLE_PASSWD "mypassword"

This last options means i have to compile the raspberry gateway again, correct? I see it has an AES flag in the ./configure and the config. I assume that's what i have to use?

Were utilizing the cheaper NRF24 radios for our network

[alowhum]

@Stevanov I don't know exactly, I use a serial gateway so I just have to also put

#define MY_ENCRYPTION_SIMPLE_PASSWD "mypassword" in my gateway too, and then everything is done.

[Stevanov]

@alowhum said in Problems with the neighbours:

MY_ENCRYPTION_SIMPLE_PASSWD

From what i can gather on the git repo i see that MY_ENCRYPTION_SIMPLE_PASSWD is only used in MyTransportRFM69.cpp, so it seems that for the NRF24 that we use we are going to have to do some other trickery to get encryption to work.
I prefer the encryption over switching a channel but i'm struggling to find out how it works

[OldSurferDude]

In the old days, yes, in the days before DHCP we had a similar problem on our cat 2 ethernet. I went over to the other guy and told him he was using my IP address. We went to the sysadmin and we agreed that he would use this range and I would use that. Done.

I suggest you talk to your neighbor. I suspect that they are clueless that they're messing with your network.

Consider this a lesson in design for robust networks and being neighborly.

[alowhum]

@Stevanov I'm pretty sure it also works on NRF24, using a software version. The RFM69 supports encryption via the hardware. Perhaps that's the difference you're spotting.

[skywatch]

@Stevanov

Your best bet is still to simply change to a different unused channel.

Nrf24l01+ has over 100 channels available, why insist on using one in use by someone else nearby?

Even if you do encrypt all data the radios will still suffer due the the high level of signals around swamping the receiver front ends and reducing sensitivity adn increasing liklihood of packet collisions.

Far better to find a clear channel and use that, but it's up to you at the end of the day.

[Stevanov]

@skywatch while i obviously agree with the fact that i we can best change channels, i figured that while we're at it we might as well add encryption too. I don't insist on using any specific channel. I couldn't care less what channel's being used

That said, i tried recompiling my pi gateway wih the password and one sensor to start with using #define MY_ENCRYPTION_SIMPLE_PASSWD "mypassword" (shut off all other sensors). But i'm seeing all sorts of erroneous messages coming by, the one node is showing up on the gateway as a different ID every time.

I'll whip up a simple serial gateway next time i get the chance and try to use #define MY_ENCRYPTION_SIMPLE_PASSWD "mypassword" on both to see if the problem lies with how i configure the pi gateway

THanks for all the input everyone so far