Hello, I am a collaborator of a technical office that deals with remote reading.
At the moment we only read one type of module applied on water meters, to be exact the module is RFM-LR1 by Bmeters.
In particular, I am writing to you and asking for information about a couple of things found on the Chirpstack portal.
A) Some of these modules join with our network server but do not report any Link margin and Battery information. I am attaching screenshots
B) Is it possible to move a module that has performed the join from an X application to a Y application always under the same network server? We have done this by removing the module from application X and putting it back on application Y but this module after this operation is no longer read by the gateway.
Nice. I didn’t realize that either. I changed the frequency from 0 to 1, and now get some info . I will have to think about what it is telling me though, as the batteries reporting back as “39.37%” are CR2032 3V powered devices and are at well over 3.0V (3.1V actually)… Should be much closer to 100%?
Lorawan MAC Versione:1.0.0
LoRaWAN Regional Parameters revision: A
ADR algorithm: Default ADR algorithm
Max EIRP: 0
Uplink interval (seconds): 0
In Join (OTAA / ABP) section:
Device supports OTAA (selected)
Neither other parameters confgured.
In Application / Device section we uset:
Device Name and Device Description as is (eg 19901014)
Device EUI as is for 19901014 (eg 70b3d5d7200409c3)
Once created device, we set Device Key.
Usually we wait device joined under a gateway linked to interned by our office connection; only after device joined to our chirpstack server, device will be mounted to water piper.
I have already linked these devices with the gateway (dragino lg308) and the TTN and although it was a bit difficult at the beginning, everything worked fine.
Well… The problema was the Re-join. I had to remove the battery to force a re-join. Now I have to look at the same thing that happened to you with the battery and the link.
You are right.
Re-join of this devices, without a correct unregistration, go under a particular procedure that foresees 30 day waiting period or remove batteries.
Please say me if you solve your issues doing it.
Best Regards
Hi Ivan
We not working under chirp-stack; we get queue messagees in real time and produce an external file with all informations needed that afterwards decode our application server.
Yes Ivan, we developed an MQTT integration under chirp-stack network linux server with Perl.
Another application on the windows server, the application server, get theese data files, decode payload and status messages and update database under SQL server, so clients get data with IIS.
All developed on AWS cloud.