Comissioning a network, PAN-ID, Frequency selection ??

[GaryStofer]

How is a MySensor network commissioned?

Is there a PAN id that distinguishes your network from the neighbors, and if so, how is this PAN-ID generated and disseminated to a fledgling network.

In the source I see mentioning of a PAN-ID as well as a Channel #define. But with hard codded values you would have to compile the code specifically for each network.

Also I see there is a concept of a persistent NodeID which, as far I understand, is doled out by the controller (or is it the gateway). If you bring up two new sensors at the same time, how do you know which sensor got which ID?

Do sensors have friendly names that are assigned by the end user to distinguish the bathroom from the bedroom window sensors?

Thanks -- Gary

[Chaotic]

@GaryStofer

I can answer the second question.

  // Startup and initialize MySensors library. Set callback for incoming messages. 
  gw.begin(); 

  // Send the sketch version information to the gateway and Controller
   gw.sendSketchInfo("Temperature Sensor", "1.0");

The gateway will respond with a NodeID after you do the gw.begin. Your Node will then send the name (in this case Temperature Sensor) so you can change the name there.

Depending on what gateway/controller you are using you may not see that through. I'm using a MQTT gateway with openhab and while the nodes are sending the name Openhab does not use them (that I'm aware of)

[hek]

There is no mechanism for distribute "PAN"-ids today. We've had some discussions about it earlier in combination of multi-gateway setups where it would be possible in combination of some kind of inclusion mode where gateway and sensor communicate at a fixed pan-address during inclusion while they interchange the new PAN address.

This would however be complicated if we also allow inclusion through repeaters at the same time.

You should not try to add two sensors simultaneously. This could lead to two sensors with the same id (bad) or if id is fethed through repeaters that one of the sensors won't get any response to their first request (not as bad). This is normally not a problem in a home environment where you deploy one sensor at the time.

The naming of sensor is mainly used to distinguish them at the controller side.

[GaryStofer]

Thanks for the reply --

An other network I have been using before did this following sequence to have unique PAN-ID.

The fresh out of the box gateway creates a random number from radio noise and uses that for the long panID from that point out.

A fresh out of the box node binds to the strongest network and stores the PANid in it's eeprom. An already commissioned node can bind to a new network by booting with a button pressed on it.

It's pretty simple and works well as long as you are close to the gateway when you bind the node.

G

[hek]

@GaryStofer

There is no way of retrieving radio noise from the NRF-radio and the functions for detecting signal strength is very primitive. Besides the radio filters radio transmissions in the hardware and only exposes messages with correct PAN to the layers below. So there must be a fixed "PAN" for initial communication.

[GaryStofer]

Ahh -- Yes I recall now, same problem on the SI44xx chips.

So maybe a "bind" mode that uses a know fixed ID (maybe all F's) in conjunction with a random PAN_ID that is compiled into the gateway only. The randomness is controlled by the build process or it could be a sequenced number etc.

Bind mode on the gateway would use the known fixed ID and it would only respond to GetPan_ID requests from nodes. The mode would be entered during boot, detected by a button press or jumper. The gateway would not exit bind mode until it is rebooted with the jumper removed.

The end/router nodes would be built with the fixed ID programmed in the EEprom (hence all F's) and would therefore know that it has not gotten a PAN_ID yet. It would then enter a loop asking for a PAN_ID from the gateway, using said fixed ID . The end/router node would indicate a successful exchange of the PAN_ID by setting it's LED (on PB5/SCK ) and entering an indefinite loop after storing the PAN_ID in the eeprom.

The end/router would have an option to ease the EEPROM during the boot of the node by detecting a switch closure or jumper to force a rebind to a different network.

So from a user's point of view to bind a node you place a jumper on the gateway and the node then power both. Wait until you get a green light on the node. at which point you remove the jumpers and reset both.

When playing with the PAN ID yesterday I noticed that the lower 8 bits (I think) showed some strange behavior. Is the library using the data pipes, and therefore 7:0 is not actually usable in the PANID?

Gary