Sensor topic tokens on the WiFi Micro Gateway for MQTT

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 i use the sensor_id token each sensor data is published on different topics. Using sensor_id is not an option.

Is there something wrong with the firmware on the gateway?

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.

Hi Travis,
Thanks for the quick response!

I have configured unique node_id on each sensor as shown in the configuration below.

If I drop the ::Sensor_ID:: within the Sensor Topic Format I get this result:

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 :smile:

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:
Let me know if you get a value for Node ID in the publish payload or not.

Looking forward to hear your conclusion after the testing.

FYI this has been done before, ref. this
community post

In MQTT Explorer what topic are you subscribed to? sensor/#?

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 ") .
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.

Sorry for the delay.

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:

Let me know if this corrects everything for you.

Thank you,

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.

By the way, the gateway is not working now… :sweat_smile:

[{“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.

Let me know if you’re able to get that to work.

Something did happen. Let me try to configure the gateway once more.
It is the firmware number [3] WiFi MQTT Gateway that is the one?

Yes, option 3 is the correct firmware.

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).

It sounds like there is a setting missing. Can you provide screen shots of the configuration you are saving to the Gateway?

I just flashed a device here using the same procedure just to verify and my MQTT Gateway connected to the broker as expected after saving settings.

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! :smile:

Thanks a lot for the help @TravisE_NCD_Technica :ok_hand:

1 Like

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 - 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.

1 Like