Introduce Gateway ID

[axillent]

To support multi gateway setup an additional support is needed to natively distinguish radio nodes connected to different gateways but with some crossing in range area.

Currently a multi gateway setup requires to hack library with BASE_ADDRESS or to hack sketches with radio-channel
BASE_ADDRESS is preferred because it is found that using different radio-channels does no guaranteed that their will be no collisions on air

[Yveaux]

@axillent said:

BASE_ADDRESS is preferred because it is found that using different radio-channels does no guaranteed that their will be no collisions on air

Differentiating only by using BASE_ADDRESS will definately lead to collisions.
Why do you expect collisions when using different channels?

[axillent]

@Yveaux Why you see collisions by using BASE_ADDRESS?

Currently we are differentiating 8 bits in 40 bits of nordic address
My Idea is to add 8 bits as gateway ID and it will be in total 16 bits address space
nordic will guarantee no collisions

in simple way there is no need for cross segment routing
etc. each gateway will manage a separate address space with 254 isolated devices.
it is actually as it is now with a single gateway

I'm requesting to make additional 8 bits of BASE_ADDRESS dynamically selected while configuring two and more gateways

About radio channels I got collisions from my experience.
I'm setting a multi-gateway network and found that channel=76 and channel=80 are not differentiating
There is no any guarantee that other selection will helps in all conditions

[Yveaux]

@axillent As you were talking about collisions on different radio channels I assume you mean **radio **collisions.
The (base) address is part of the header of each message sent by the nRF24.
When different radios start sending on the same channel simultaneously, a collision occurs, no matter what you set the address to.

When using different addresses on the same radio channel all radios within range will receive all packets, but will return only the ones which match the configured address. This property I used for building a wireless sniffer for nRF24 radios.

[axillent]

@Yveaux yes, I'm about radio collisions

scenario 1. As it is now
look, you have two gateways and two devices with absolutely same BASE_ADDRESS and RADIO_ID and only channels are different
time to time the messages will mix up
you will be never able to distinguish

scenario 2. As requested in this feature request
two gateways and two sensor nodes will have different BASE_ADDRESS, make no sense which RADIO_ID they will have
they will have probably (but not necessary) same channel

it is possible that their will be a radio collision because of same or close channels
but it will never lead to the collisions at application level, because nordic will take care by filtering out not matching address

I prefer scenario 2 and this why I'm requesting Gateway ID

[Yveaux]

@axillent said:

@Yveaux yes, I'm about radio collisions

Ah, that's settled then ;-)

time to time the messages will mix up

I was just surprised about message mixup for neighbouring channels.

So if I understand you right, you've seen messages on one channel being received on another channel when they use the same address?

[axillent]

@Yveaux said:

So if I understand you right, you've seen messages on one channel being received on another channel when they use the same address?

yes
i've prepared 3 gateways (http://forum.mysensors.org/topic/922/custom-made-ethernet-gateway-based-on-atmega128) and 3 wall sensors (http://forum.mysensors.org/topic/971/small-wall-outlet-sensor-node)
to be installed on 3 levels at house
because of a limited distribution across levels I've already have ethernet switches & wifi access points on 3 levels
the idea is to put MySensors gateway near wifi access point to have similar coverage without using repeating nodes

during tests I found that for example 76 and 80 channels are interlacing. 85 and 80 may be not interlacing but I cannot be sure

[DNKROZ]

Hi.

That's the same problem I'm facing at my house, multiple levels, also the radios don't have enough coverage to reach the far end of the same floor (PA's radios do, but I only use them on the GW and MQTT GWs, can't use them on battery powered sensors for obvious reasons), so the multiple gw distribution system should be an ideal solution for me and people living in "castles" or "Faraday cages" XD

Currently I have moved from a serial gw to Ethernet and MQTT gws (one Ethernet and one or two MQTTs), I find the Ethernet GW to be more stable than the MQTT ones (Client or Broker, same DIY PCB, I just pop out one nano and place the other) , your scenario 1, also some messages get mixed from time to time, even using different channels. Some times the GWs stop looping and I need to restart them, funny thing is that connecting to them in order to debug if they are running seem to jump-start the loop again.

So my vote goes for scenario 2 also, plus, it should be interesting for the Ethernet GWs to act also like MQTT Clients and/or Brokers, because the IOT community is clearly taking that approach in their effort to "standardize" all the chaos that exists today. I think we should keep things as simple as possible, I've read this post:

http://forum.mysensors.org/topic/887/future-network-topology-for-discussion

And I think it's a superb idea, clustering the whole network into more easy to manage subnetworks, each one with a different topology connecting to a Network (TCP) controller through their GWs, all the complicated stuff should be done by the "Controller" the subnetworks should be as dumb as possible, leaving the heavy duty processing to the controller.

I know this isn't much, I wish I knew more about all of this, but I hope my experience will be useful.

Regards.