I am setting up a WiFi Micro Gateway for MQTT to collect sensor data and push the data to my local MQTT broker. Within the setup instructions it states under Message Settings that:
Sensor Topic Format: Token based formatting for the message topic to which data will be written to when a wireless transmission is received by a sensor. Supported tokens are ::Sensor_ID:: ::Gateway_ID:: ::Node_ID:: ::Sensor_Type::
I need to use the ::Node_ID:: in the topic format to distinguish between the different sensors within the network. For some reason the topic does not include the sensors node id.
If you use ::Node_ID:: in the topic format and the Node_ID were set unique on each sensor wouldn’t the publish topic be different for all sensors just as it is with ::Sensor_ID::?
By default all sensors have a node_id set to 0. The Node id parameter on each sensor would need to be changed to be unique. It may be excluded as 0 is being ignored.
Can you explain what you are attempting to do? My guess is there is a better way to accomplish it than ::Node_ID:: in the topic.
As you can see both sensor’s data are published to the same topic and I expect it to be published on two separate topics. The first sensor data should be published on the topic “sensor/1” and the second on the topic “sensor/2”.
The system I am setting up is for collecting data within a warehouse. Because of the thick double-layered-fire-proof walls, and the customer’s request for location-based signal-namespacing I will be using several gateways and structure the incoming data using topic to specify location and equipment, “floor1/gateway1/sensor1”. This will probably be scaled up to the next floor. Then I want to use the same structure as for the first floor.
All these sensor data will be used further in different top-level system.s Using ::Node_ID:: instead of ::Sensor_ID:: makes is more efficient for further data processing, cleaner data structure and easier to maintain in the future.
I have seen example of this use case before so this should work the way I intend
Honestly I believe you may be the first person to attempt using ::Node_ID:: in the topic format. I will need to test on a device here to see why it’s not working. I just reviewed the code and I do not see any issues there. I will need to debug on a device which I don’t have on my desk at the moment.
Could you try adding ::Node_ID:: to the sensor message format to see if it gets added there? Something like:
{“::Sensor_ID::”:::Sensor_Data::,"node_id:::Node_ID::}
Let me know if you get a value for Node ID in the publish payload or not.
Everything within the broker is beeing subscribed to using wildcard # in the subscription definition. I also tried to subscribe to sensor/# , no Node_ID value.
I configured the message and topic formats identical to the formats within the example from the earlier community post and subscribed to ncd/#, no Node_ID value there either.
Then I defined the Sensor Message Format that you suggested (I belive the "node_id:::Node_ID:: is missing a ") .
{“::Sensor_ID::”:::Sensor_Data::,“node_id”:::Node_ID::}
No Node_ID value.
I was curious about the other Token definitions from the manual . So I tried every token that was listed in the Sensor Message Format:
{“::Sensor_ID::”:::Sensor_Data::,“node_id”:::Gateway_Data::} → works fine
{“::Sensor_ID::”:::Sensor_Data::,“node_id”:::Gateway_ID::} → works fine
{“::Sensor_ID::”:::Sensor_Data::,“node_id”:::Sensor_ID::} → works fine
{“::Sensor_ID::”:::Sensor_Data::,“node_id”:::Node_ID::} → does not work
{“::Sensor_ID::”:::Sensor_Data::,“node_id”:::Sensor_Type::} → does not work
{“::Sensor_ID::”:::Sensor_Data::,“node_id”:::Sensor_Data::} → works fine
As far as I can see the result I get deviates from what I read from the manual + other experiences.
I really hope this gets sorted out since I think this will be a good sensor network to use within our applications.
I was able to a couple bugs that would have prevented the ::Node_ID:: and ::Sensor_Type:: tokens from working at all. I corrected it in a firmware update. You can update your gateway using instructions here:
I am not sure if the instruction you sent me is performed as you intended. I must admit that this is starting to feel like I do not have the prerequisites that is needed to operate this device on such a level. I gave it a shot tough.
It says that it fails to connect… Tried both the run.bat and run_ns.bat several times each. The LED of the ESP32 starts blinking when I run the script. So some connection is going on I guess.
If you can’t see a quick way to deal with this I am tempting to ask if it is possible with another way. This is far more time consuming then what I expected. I am open to have a remote support meeting or to just ship the device back to you. Let me know what you think.
[{“problem”:“Failed to fetch device settings”,“message”:{“message”:“Failed to parse JSON”,“err”:{},“data”:{“nodeConfig”:false}}}]
It looks like the USB port on your computer is not able to reset the unit via the RTS/DTR lines. It’s a pretty common problem.
To resolve this during the flashing process you will see the terminal printing …_______ repeatedly. Once the … starts printing press and hold the RST button on the module near the USB connector. Just as the _______ starts to print release the RST button. It may take a couple tries to get it right. The key is to release that RST button as soon as the _______ begins to print.
Now after I have set up the wifi network configuration and hit “Save Setting” it boots up. Instead of trying to connect to the WiFi it goes straight to config mode (blue LED flashes).
Sorry but I was in a hurry last we spoke. The configuration settings of the broker was set up with wrong IP address. Works fine now + the ::Node_ID:: token seems to work!
Just want to share from my experience when reading NCD documentations (on this case and generally speaking). The instruction on this comment was easier to understand than within the How to update Micro Gateway Firmware - ncd.io because it was specific.
For example “hold the RST button on the module near the USB connector” made more sence than “hold the RST button on the device”. If there was pictures/screenshots included it would have been even more easier to understand.
