For configuring V3 Vibration Sensors (Single Channel, Dual Channel, Predictive, Standalone) we have been using Node-Red. When we deploy several, (50-60) we need to give each a unique nodeId, so that they don’t transmit all at the same time, due to the RTC and the default nodeId 0.
To do this configuration we set out those 50-60 sensors and one by one open up Node-Red, set the nodeId, and manually press the reset/config, etc, until they are all configured. We’ve setup dashboards to double check our config and make sure the nodeId, the mode, and the ODR all get set properly.
Is there an easier way to mass configure? I know part of the answer is the OTF config, but that seemingly wont work when you have 50-60 that are all on nodeId 0. The OTF WILL work once they all have their unique nodeIds.
If there is not an easier way to mass configure that I am missing, would it be possible, that if nodeId = 0, for the sensor to choose random offset for its transmission interval?
If the sensor had a random transmission interval when nodeId=0, and did NOT use the RTC, then configuring them over to a specific nodeId should be possible given some time.
The random offset chosen would still need to be contained within the transmission_interval so as to not overlap into the next transmission_interval.
assuming transmission interval = 30 minutes, or 1800 seconds.
If nodeId = 0, the transmission interval would become 'transmission_interval + rand(0-1790)
Yes, these are the units with the QR labels on them.
Ive been pondering this for a bit, even if you made this an optional setting, and defaulted it .
Set this as defualt
UseRTCOnNodeID_0 = True
Then the sensors would continue to work the same way they do now, for anyone for whom this does not matter.
Then if I had 50-60 NodeId0 sensors, I could OTF Config that UseRTCOnNodeID_0 to False, to get them to a distributed randomized transmission pattern, and from there I can OTF config them into an organized pattern.
Some people at my company has asked me if we could just have NCD configure them, but I don’t think that is the answer yet either, as the NodeId organization needs to work for a given deployment.
So 50-60 sensors at a deployed site need to have non overlapping NodeIds, for that physical site, against that gateway, with that panId.
Please let me know your guys thoughts! I don’t intend to put any more work on you guys configuring them when they come out. Trying to think of ways we can programatically solve for it.
So what I’m thinking is this is done in sets or deployments as you put it.
The way I see this working is you would take a group of sensors(50-60). Scan their QR codes and upload that list of addresses to a Node-Red flow. The Flow would listen for transmissions from sensors and check to see if the sensor that checked in is in this set by reviewing the list of addresses in this set. if it is then assign it the next available check in offset(Node ID). It would then add that sensor to a list of devices that is ready to go. Once all devices are in the “Ready to go list” you could ship them out to the deployment site.
The QR Code has that whole URL encoded, but stripping off the URL and getting back to just the MAC should be easy enough. We just need an array of Xbee MAC addresses right?
Two questions:
If they are all on nodeId 0, then doesnt their FLY come at the same time, and configuring them becomes difficult? (I am assuming the CONFIG back to the sensor is a broadcast maybe, I could be conflating this with the time domain request)
I had not quite figured out how to programatically send a CONFIG for NodeId. There was a seperate thread where Bhaskar responded about how to listen for FLY and send the config and then close the FLY, but I had not had a chance to put all of that logic together. Would you be using a similar method, responding to those FLY?
In my head, this config could take overnight. You scan in the sensors to config, let them sit overnight, come in in the morning and they are all configured.
right now node red always sets RTC. @jacob can you disable that. so that node red will only set node id when users sets it. if not all nodes will have random interval.
I’ll need to get more up to speed as to how the OTF configuration and the RTC functionality works on the devices in the latest firmware but it seems this should be possible. The trick will be scanning the QR codes on the devices, and sending those addresses to the Node-Red flow. I have not attempted that yet, I’m envisioning some sort of app on the phone that would scan the QR code and then relay the MAC address back to Node-Red via something like an HTTP request.
@Bhaskar I updated the library to make setting the RTC optional on types 80, 81, 82, and 84
@kstokes The OTF config does not use broadcast addresses it will use the mac address of whatever sensor it receives a FLY command from. If there’s a sensor node without a MAC address assigned it will configure all sensors of the designated type in the same way. If it does have a MAC address it will only apply the configurations to that device.
Mixing the device nodes that do not have a MAC address and one that do have a MAC address will cause the configurations to override each other so if you use device nodes without MAC addresses configured you will want to make sure OTF Config is not selected unless you want to en masse configure all sensors of a particular type in the exact same way.
@Bhaskar
If the RTC clock is disabled, and the sensor goes back to random, that might be all we need.
However I am sure you guys included it for a reason.
It might be interesting to see how the sensor networks (summary data and FFT) work in the distributed RTC=OFF mode, versus how they work in a nicely configured non overlapping nodeId network.
So if I read that right, we don’t need a firmware update, setting the RTC optional can be done via Node-Red? Thank you for this change.
Your other statement about FLY being to a specific MAC is great news. I had thought it was broadcast but was not sure. I understand your comments about mixing the Wireless Devices nodes, ones that have a specific mac will only change settings on that sensor, but if we leave one open, it will re-config all sensors of that type. That makes sense.
I have done one or two deployments where I copied and pasted the nodes and typed mac addresses into each node to get them to flip over to the proper nodeId, and while it worked great, it took some effort to setup a Wireless Device node for each sensor.
@TravisE_NCD_Technica I’ve got a 2D bar code scanner on order, I can work on getting a QR code scan to populate to an array in the Flow or Global variable.
I also don’t expect you guys to write all of this (unless you want to and it is interesting). If you would just be able to tell us the Hex payload to send out to configure to a specific nodeId (I am pretty sure this is already in the docs) (and can we configure other things at the same time, or is that separate payloads?)
Using what Bhaskar provided in the link below, combined with one more payload, the payload to set to a specific NodeId I think would be what finishes this off.
@kstokes
That is correct. As long as you have the latest version of the FLY capable firmware. The older versions of FLY were in alpha phase. The new FLY commands can be recognized because you will get OTN and OTF messages in Node-Red. There was an older version that just sent a FLY command, but it wasn’t reliable and we dropped support for it.
One thing that I might be able to add is support for a global context variable. Basically add an if check into the config event of the library that says is this this particular global variable populated? If so load all configurations from it instead and ignore everything except whether it should be configured or not. This could be used as an advanced feature to allow a function node to programmatically set up configurations for a swath of devices at once. I’d have to do some brainstorming to give you a better idea of how this would work, but it should be possible with a bit of careful implementation.
Probably end up something like having your flow have a switch node to pluck out the starting RUN packets, parse these through a function node in the flow that then populates a config object keyed by mac with a programmatically assigned node_id based on the index of when they check in. Because it’s keyed on the RUN which comes before the fly it should happen on the very first FLY command that is generally sent shortly after the RUN.
@jacob
Right now im tracking every sensor transmission and its nodeId into some global arrays.
I’ve got one just overall by sensor, and then another array grouped by nodeId so I can see the distribution and see where we have overlap.
I setup a quick NodeRed dashboard to take input from a barcode scanner, and insert the MAC scanned into an array, and calculate the next nodeID to assign to it.
I’ve tried it a few times but I suspect my radio commands are off.
To send radio commands, I set msg.payload.data to the hex buffer of what I want to send I believe, something like this:
Sensor sends FLY message
This is now and indication that the sensor is checking if the modem wants the sensor to go into a temporary configuration mode. If no response is detected within ~2-4 seconds (apologies I can’t remember the exact amount of time) then the sensor will go back to sleep as usual.
Gateway responds with the command [0xf4, 0x4f, 0x00, 0x00, 0x65, 0x32]
This is the modem telling the sensor that it should go into configuration mode.
Sensor responds with an OTN package.
This lets the gateway know that the sensor is in config mode and ready for config commands. The sensor will stay in this mode until ~60 seconds have passed OR the modem sends a command to end the configuration.
At this point the Modem will send all of the configuration commands.
Once all configurations have been made the modem will send the command: [0xf4, 0x4f, 0x00, 0x00, 0x65, 0x33]
This tells the sensor to go to sleep and resume normal operation.
The sensor responds with an OTF message
This indicates to the modem that it is no longer accepting configuration commands.
We went this route to make sure all configurations have enough time to be sent in one cycle while also maintaining battery life as much as possible.
It looks like my original transmissions were far too long, and looking through the ncd-red-wireless-2 it looks like you guys do some concatenation to form the payload for transmission.
I changed my first transmission to the command you specified in step 2, but still did not receive any response from the sensor when I sent it that command in response to its FLY. (I don’t see an OTN from the Wireless Gateway node).
The two sensors I am testing with, one has a Firmware 4, and the other has Firmware 6.Those are just what I have on hand, I don’t expect the Firmware 4 to work (it has the old style firmware connector and so is a little more difficult to hook up to flash).
I think I will need to fire up XCTU to watch the FLY interaction from the ncd-red-wireless-2 library, it feels like I am missing something minor and silly here.
Travis and I are doing a dive into smoothing out mass configuration of devices.
Travis will be out of the office until Tuesday and he has the QR code scanner we’re building the configuration list with of so I can’t get you a finalized version until the middle of next week.
What our plan is right now is to have you use a physical handheld QR code scanner which can feed in as a serial port, have node-red read that serial port to populate a list, have node-red check FLY packets against that list to configure or not, and finally populate a “finished” list that shows all confirmed configured MAC addresses.
As far as the commands you’re currently sending it looks like you might be adding in the address into the payload which we just take from the msg.payload.address that you’re setting. That may be the issue.
What you see from the Gateway Node when you send the correct OTN request should look like this:
{“topic”:“sensor_mode”,“payload”:{“mac”:“00:13:a2:00:41:f0:42:b4”,“type”:80,“nodeId”:0,“mode”:“OTN”,“lastHeard”:1660250018338},“_msgid”:“0c71dea48553eb89”}
This is what we are using to trigger the OTN response:
Thank you Jacob, I am excited to see what you guys come up with.
I put together a quick Node-Red dashboard that accepted text input (QR Code Scanner configured as keyboard). When scanned with our QR Codes, extracts out the sensors MAC and would then just add it to an array object with the next nodeId in sequence as desiredNodeId. I then added a column for currentNodeId. This is the beginnings of a sort of Desired State configuration.
Longer down the road, we’ve been asked to be able to adjust things like ODR dynamically.
I know adjusting ODR is possible now, with the OTF, just not exactly automatically.
Do you think this mass configuration you guys are working on could be used to try to push those types of settings as well?
If that is too far forward, please just ignore that for now. NodeId alone would be a huge win.
Great minds think alike @kstokes. I think we are heading down the same path here. Was a bummer, we were so close to having something ready to do some in depth testing Thursday, then I had to go and spoil the mood.
Hoping to have something for you next week at some point to take a look at.
Will your scanner mount as a serial port to the OS? That is how I was using ours.
