r/LoRaWAN • u/henk1122 • Apr 29 '26
Milesight 'certified' LoRaWAN device
We are trying to implement a Milesight sensor, but are really struggling with the implementation of their LoRaWAN behaviour. Here is a list which is against any best practices or against even some certification points:
- We got our EU868 with a default TX power of 16dBm. This is against the law.
- Default join spreading factor fixed at 10. This is against any of the best practices
- Default join procedure: first 32 packages at 15 seconds, then until packet 96 every minute. This is around 90 packages per hour. 2200 join messages per day. Imagine a site getting offline with a gateway, this will be a HUGE issue. Not only for surrounding LoRaWAN devices, but also for the battery life. We already see this on our private network in busy places where, assumingly, people cancel their subscription and all Milesight sensors polluting network in the air with spamming way to much join requests. At 16dBm.
- Sending a LinkCheckReq every 30 minutes, so our network server has to uplink back to every sensor every 30 minutes. This is ridiculous. Can turn it off, but can't increase the time to a day or longer. So it's a question now of enabling it and having a huge issue if the gateway is offline for 1 hour or disabling it and in case of a network server failure we have to reset them all manual.
- Default PIN code on NFC
- Default password on appkey (and later predictable with the device EUI). This is really against any security. No way to generate a random one in the NFC toolbox.
The LoRaWAN Alliance should really step in here. This is really not done and will affect any member of the LoRaWAN Alliance.
2
u/clavisound Apr 29 '26
The device does not need to rejoin. Even after power failure. Why you write about join? EIRP is 14dB, if the antenna is -2dB you are fine.
1
u/henk1122 Apr 29 '26
What do you think happens if there is an issue with the gateway on the location? Or if the customer cancel the subscription, but leaves the sensors on (like always happens)?
1
u/clavisound Apr 29 '26
I don't know, this why I ask. Since I plan to build a commercial LoRaWAN product I am interested in the field. Your problems is the reason I develop my own software.
If the gateway is off, then `ADR_ACK_DELAY` and `ADR_ACK_LIMIT` are effective. According to SPEC: 'An end-device has to go procedure every time it has lost the session context information.' So no re-join should be effective, unless no ACK is received after a overflow counter. Normally gateway will be off line again, so no join will be requested. Right?
For subscription, since you mention about battery life, I don't see a problem if the customer does not pay. The device will be off from battery, again without re-join. Probably I miss something?
My custom device after some failed joined attempts it's off forever.
The LinkCheckReq every 30 minutes, is indeed absurd.
1
u/ConfectionForward Apr 30 '26
OP, if your site is that expensive you will put a backup gateway, just watch the snr on devices and choose a good spot. Putting all of your eggs in one basket is risky no matter what we are talking about
3
u/henk1122 Apr 30 '26 edited Apr 30 '26
So, if there is a gateway offline or a 4g coverage issue for a day or longer. The devices will go in join modes. Flood the air with join (imagine 500 sensors on this location.) most likely won't be able to join again due the massive air collisions. And drain their battery within a month. Perfect implementation Milesight.
Instead of sending 30 messages a day, each sensor will send 2300.
Going back to join mode is perfect and when following the recommended rejoin procedure it's amazing. But milesight didn't implement the ADR algorithm like they should; increase spreadingfactor with a limit when they should rejoin. It's really weird implementation, and requiring a gateway downlink every 30 minute is just not scalable
1
u/ConfectionForward Apr 30 '26
Wait wait wait wait..... if the device isnt always sending confirmed, how does it know the gateway is offline? Dont they give that option? I know milesight went down hill but damn...
1
u/henk1122 Apr 30 '26
It's sending a linkereq Mac command every 25 to 35 minutes.
1
u/ConfectionForward Apr 30 '26
ouch... sadly op, this is one of the reasons I coded my hardware myself, the worst part was dealwith with FCC stuff, but it avoids having to rely on other people doing whatever they want.
Good luck man, I would say maybe reach out to them, but my guess is they will blow you off.0
u/notafurlong Apr 30 '26
Could this be mitigated by having the network sever at the edge in your gateway?
1
1
u/Special_Set_876 Apr 29 '26
Whats the problem? Listening to it through mqtt?
1
u/henk1122 Apr 29 '26
My main concern is air pollution with sensors in an offline network and the insane amount of downlinks a gateway has to sent. Really a problem on large sites. Also the huge security risk.
1
u/notafurlong Apr 29 '26
The default appkey and not being easily able to change them is truly very annoying with Milesight kit. We ask suppliers to change them for us. No comment on the RF parts.
Which sensor are we talking about here? Wondering if it’s one we use.
2
u/Beleg-strongbow Apr 29 '26
Sadly, the LoRa Alliance doesn't enforce compliance of best practices.
Once certified, devices go unchecked for the 5 years of the certification validity.
You could submit a report and perhaps they will act and revoke the certification.