NodeID networking naming format

[mrpaulpaul]

Hi all,

I've been playing with the Moteino a bit and just got a question about networking with the Moteinos.

Is there a reason for the Gateway.ino having a GatewayID=1 and NodeID=2 while the Node.ino has a NodeID=1?

Also, if I were to add another node, would this then use Node.ino with NodeID=3? I am curious as to the logic with naming nodes.

Thanks,
Paul

[Felix]

Is there a reason for the Gateway.ino having a GatewayID=1 and NodeID=2 while the Node.ino has a NodeID=1?

Hi Paul,
Can you link the files you are referring to where this is true? You either wrote it backwards or this is someone else's implementation.
It all comes down to having unique IDs for each node. Otherwise it's chaos.

[TomWS]

Hi all,

I've been playing with the Moteino a bit and just got a question about networking with the Moteinos.

Is there a reason for the Gateway.ino having a GatewayID=1 and NodeID=2 while the Node.ino has a NodeID=1?

Also, if I were to add another node, would this then use Node.ino with NodeID=3? I am curious as to the logic with naming nodes.

Thanks,
Paul

It's a good question, Paul, but, no, I don't think the intended purpose of the examples is to demonstrate or propose a programming practice with respect to node/gateway naming.  As you set up your own networks you are perfectly free to choose (almost - 255 is used for BROADCAST) any combination of sender, target, and network IDs that fit into your way of organizational thinking.

For my purposes, I have well-defined network IDs that isolate House, Landscape, Workshop into their own 'networks'.  Then I limit Gateway IDs to 1 - 8, simply because I don't need very many Gateways within a single network. Node 9 I reserved for unconfigured Gateways.

Then NodeIds begin at 10 and go up to 249.  250 I've reserved for unconfigured Nodes.   With this method, when I deploy a new Gateway, it 'happily' (My Motes are always happy) starts up at node 9 and, from my Home Page I can get to it (I know it's ID) and can reassign to a range of 1-8 depending on what's already deployed on that network. 

With Nodes, when first deployed, start up with NodeID 250.  When they start, they broadcast to their network that they are 'seeking' a Gateway.  Any Gateways that 'hear' that message, send their device descriptor to that node (Node 250).  Node 250 then saves the Gateway ID of the response with the highest RSSI, and, when it's sure it's gotten all responses (a brief period of time after the last reception), it selects that one Gateway and 'registers' itself.  That registration then gets posted to the Home Server where, now knowing what Gateway it's connected to, can send a new permanent Node Id to that newly deployed node.  Start up generally happens so fast that I end up seeing the whole transaction on my Snooper after it's completed...

I'm sure this is FAR more than you were seeking, but just wanted to give you a range of ideas (from free-wheeling to very structured).

Tom

[TomWS]

<snip>
Is there a reason for the Gateway.ino having a GatewayID=1 and NodeID=2 while the Node.ino has a NodeID=1?
<snip>

And to answer your 'real' question, in the Node.ino sketch 'NodeID'=1 is used as the Target id (AKA the Gateway) and, as Felix pointed out, needs to match the GatewayID of the gateway.  "NodeId" is just a local variable name, but admittedly confusing in this case.

Tom

[Felix]

Right, so in general in all my sketches the NodeId refers to THIS node that is being loaded with the sketch. Any GATEWAYID refers to the central node with NodeId=1. That's generally my pattern.

[mrpaulpaul]

Thanks Felix, Thanks Tom, for the quick response and insight!

Felix, you are right, I swapped the two while writing the sentence.
https://github.com/LowPowerLab/RFM69/blob/master/Examples/Gateway/Gateway.ino
https://github.com/LowPowerLab/RFM69/blob/master/Examples/Node/Node.ino

I have a clearer picture of the usage of NodeIDs and GatewayIDs now. So, the NodeIDs are used to identify unique nodes and the GatewayIDs are used to identify the gateway to talk to. Right?

I think I was confused as I was building an application where a sender would talk to multiple receivers (thus this is a node script talking to multiple gateway scripts), and assumed the sender was the gateway. My mistake  Thanks for clarifying it all! One more question, for this application though, would it be better for the sender to use something like,
radio.sendWithRetry(255, payload, sendSize)
rather than to loop through the GatewayIDs?

@Tom thanks for the ideas on the usage of node/gateway ids. Your setup of the nodes/gateways is pretty organized and clever!  I Like!

Paul

[TomWS]

Paul, the thing to keep in mind is that for any communication link, there is a sender and (hopefully) there is one or more receivers.  The notions of Node and Gateway makes sense only if you have a Star network (one Gateway in the middle of a bunch of nodes).  With the Moteino SW you could implement practically any network topology you want, including Peer to Peer.  So 'Node' to 'Node' is equally valid if that's what you need.

The send() and sendWithRetry() methods allow a 'sender' (could be a Node, a Gateway, or a Peer) to send to a 'Target' (Could be a Gateway, Node, or Peer).  The RFM69 API doesn't make a distinction, it's your model and implementation of the network that makes the distinction.  Think Sender 'sends', Target receives.

Using a target address of 255 (or, properly RF69_BROADCAST_ADDR) will send to all listening 'Motes' on that network, but it also 'bothers' all 'Motes' on that network if you really only want to send to a few.   The other downside of Broadcast is that you can not get an Ack from more than one receiver so you don't know if everyone got the message.

Tom