Sending command from chirpstack user platform to LoRa node

1

Hi,
At the Chirpstack User platform, I am trying to send some control data, like the time interval for the LoRa node to send sensor data. How can I do it?

For example, I want node A to send sensor data every 10s, but node B to send every 20s, etc. How can I send this command from the chirpstack user platform over to the node?

Hope to hear from you soon.

Regards,

2

Two ways:

  1. Usually sensor OEM’s console supports this function. You will need to set up HTTP integration.
  2. If you’re on intranet (as I am), it’s more complicated: a) you’ll need to get vendor literature on how to encode packets to affect your configuration, then go HERE to turn this string of hex bytes into base64, and then paste that into “Device” tab for each device and scroll down to “Enqueue downlink payload”, paste base64 string, specify port, and click “Enqueue Payload”. It usually takes my sensors up to 1hr to reflect change - you can watch “LORAWAN FRAMES” tab to see what’s going on.

If you’re on intranet and know how to use ChirpStack API (which I don’t), you just need to do step 2a and rest will be “less tedious”.

3

Hi @fmgst,
Thanks for your reply. I don’t quite get what you mean.

Yes, I am on intranet too.

First we need to setup the downlink method, right? But how to setup the downlink method?

Regards

4

LoRaWAN is a bit clunky in this regard and understanding what to do is non-trivial. I say this up front so that you don’t think it’s ChirpStack’s fault for this process being so cryptic.

Take a RadioBridge RBS301-TEMP-EXT-US sensor that I want to configure to send periodic reports every 4 hours (which they don’t recommend, for valid reasons). You have to dig up its manual which describes the hex bytes that the sensor needs to get from you to understand your command:

rbs_periodic
rbs_periodic622×562 40.3 KB

So, periodic reports are piggy-backed on the main downlink (a bit of foreshadowing :-)):

rbs_downlink

Now what? You’ll need to locate their Common Sensor Messages PDF and tease out the whole sequence. And then you’re still not sure what that sequence needs to be…

Cue a small violin playing a sad tune…

Is it normal to have fleeting feelings of being dim and inadequate when trying to figure out the string of bytes needed to set an existing sensor to do something special, in the middle of a busy day, of doing something completely different? Asking for a friend :-/

It’s only occasionally that I stumble on a considerate vendor that provides their user-base with a web-based encoder/decoder widget, such as https://neon-configurator.twtg.io/ which are ATEX Zone 1 certified & intended for refineries (and priced accordingly), but this is an exception. Most vendors push their consoles (and data plans) and consider intranet customers “outliers” who can be safely ignored (which perhaps we are). But, I do wish that someone, someday adds an “plugin” to ChirpStack that allows users to define downlink encoders for their sensors. I’m too busy & not smart enough to do that.

Stop that violin!

After a few months of that (royal) PITA, here’s my current “plan B”. I dedicated a gateway, this time on the Internet, that I provisioned with quantity ONE of each TYPE of sensor for EACH vendor that I utilize in my installation. These sensors sit in my office and do nothing except allow me to “trigger” an uplink, on my timeline/short notice. Then, I use the VENDOR’s console to configure a custom down-link for the ONE TYPE of sensor and “send it”. When it is enqueued, I extract that sequence of bytes and save it and what it means to a spreadsheet of “previously used sensor config downlinks”, which also serves as a changelog of sensor configurations. Grrr.

Only here, at this point, does ChirpStack and my REAL sensors enter the picture.

You go to the particular device for which you now have a “secret sequence” and you ensure the sequence is base64 encoded and paste resulting gibberish into the “Device” tab for each device and WAY down below all the (wonderfully useful!) status and stats to the “Enqueue downlink payload” section - don’t forget to specify a port such as “1” - and click “Enqueue Payload”.

image
image843×801 33.2 KB

This will transfer your gibberish to the “Downlink queue” just below where you sent it. You have some time to delete it, if you change your mind. Note: you have time because nothing will happen until you sensor sends an Uplink - only then will the Downlink go out; I think it’s using the slot for Uplink ACK to send the Downlink. That’s why I have the ONE sensors in my office - pushing these to send an Uplink is my way to “game” when Downlink goes out :slight_smile:

It usually takes my sensors some time to reflect the change I sent - you can watch “LORAWAN FRAMES” tab to see what’s going on. I just give them 1hr to “process” my order before I bother again, to play it safe. The proverbial sword of low data-rate does cut you on uplinks and downlinks :slight_smile:

That’s where I’m at.

If you have a better flow, PRETTY PLEASE BEGGING YOU PLEASE comment with it. Thanks!