Health Status Messages?

[snelson-senet]

Health status messages are mentioned in the online documentation Transmit Confirmation section:

"There is no feedback to the LNS if a frame could not be sent (e.g., because it was too late, there was a conflict with ongoing transmit, or the gateway’s duty cycle was exhausted). These conditions are summarized in health status messages and do NOT trigger an individual response."

What is the health status reporting interval and where can I find the message format?

[beitler]

Thanks for your question. The documentation has to be understood prophetically in this regard ;-) In the current release, no status messages are sent. I will remove its mention from the docs for now. We have this feature on our roadmap and it will be included in future releases.

[snelson-senet]

@beitler Thank you for the update. Another question for you while I have your attention. Does the current release support Class B Beacons? I have found via code search the RAL API to transmit a beacon, but could not determine if it is currently being used, presumably by a beacon scheduler.

[tonysmith55]

@beitler, just looking for an update. Do you have an estimate when the "stat":{...} messages will be included in basics station? I understand it is on your roadmap, just don't know how far away it is.

I also have a suggestion, could you add "temp" to the string for the SX1302, much the same as in the SX1302 UDP packet forwarder.

[sagar-patel-sls]

@ogimenez-smtc when "stat:{...}" message will be included in the basic station? when this feature release?

Thanks

[beitler]

In the context of this discussion, I would like to point you to a useful feature, which probably satisfies the needs of many users who ask for status message support:

The way Basic Station addresses the topic of status messages from day one, is via generic events. Station supports the injection of arbitrary messages into the LNS protocol from the outside via named pipes (https://doc.sm.tc/station/conf.html?highlight=cmd#configuration-files). To create the named pipe (aka 'fifo'), type mkfifo cmd.fifo in station's home directory (restarting station is required after the fifo is created). Then, during runtime any external process on the host system (with write access to the named pipe) can inject JSON messages towards the LNS, like this:

echo '{"msgtype":"event", ...}' > cmd.fifo

In practise, let's say a solar powered gateway could have a cron job firing a script which collects all the necessary metrics from the different places, then constructs a JSON-formatted event and pushes it to the LNS via:

echo '{"msgtype":"event", "type": "status", "battery": 52, "solar": 123, "temp": 4, "last_full": 4201}' > cmd.fifo

This requires that the LNS just forwards the msgtype:event message through to some event log or MQTT topic, etc. to make it available to the application.

While I agree that a default set of internal metrics sent autonomously by Station makes a lot of sense, I think with the method described above most needs for status reporting are already satisfied. Wouldn't you agree?

Excerpt from my comment on TheThingsNetwork/lorawan-stack

[JoToSystems]

Thanks for the feedback, very interesting feature. A more generic feature, which can achieve the same end result (and more) is always better. Will have a look.

[smtc-bot]

Thank you for your inquiry.

Customers are encouraged to submit technical questions via our dedicated support portal at https://semtech.force.com/ldp/ldp_support.

We invite all users to visit the LoRa Developer Portal Forum at https://forum.lora-developers.semtech.com and to join the thriving LoRa development community!