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:
So, periodic reports are piggy-backed on the main downlink (a bit of foreshadowing :-)):
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”.
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
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
That’s where I’m at.
If you have a better flow, PRETTY PLEASE BEGGING YOU PLEASE comment with it. Thanks!