So we’ve been using Chirpstack for a while now but every now and then, when we send a command to our ABP-activated smart light device to change its light intensity, the device doesn’t seem to receive the command. It happens randomly at time and we’re trying to identify the root of the problem. Is it a Chirpstack problem or a hardware problem or a LoRaWAN problem?
We’re currently using AS v3.13.2, GB v3.9.2 and NS v3.11.0
Some loss is to be expected: TTN “best practices” literature states that you should expect about 10% of packets to be lost. It’s on you to anticipate this and employ forward-error correction to ensure it doesn’t affect you adversely.
And how can we employ this forward-error correction?
Very much depends on your data architecture but I’d start with github: https://duckduckgo.com/?q=forward%20error%20correction%20github&ia=web
Is it hardware-based? Because its something that we can’t modify since its from our client. Other than the hardware (gateway & end device), we have full access to Chirpstack.
Can you implement any of the suggestions in section 4.3 of this guide? That may be your only option - you will have to do something to increase odds your data comes from sensor node to ChirpStack.
The only option I can think of from that guide is using Confirmed Message and that’s another problem that we’re having. When we send a confirmed message to turn on the light, it doesn’t work. But just right after that when we send the same command as an unconfirmed message, the device received and responded to it.
In a very general way, TTN’s “Limitations” page explicitly states that LoRaWAN is not suitable for your very example (Controlling lights in your house).
That said, there are deeper reasons why sensor nodes would not support confirmed messages.
This article explains that some implicit confirmation is built into LoRaWAN already.
This paper shows that the performance of a single LoRaWAN cell can significantly degrade when the fraction of nodes that require confirmed traffic grows excessively […] To reach the best performance, it is necessary to carefully choose the maximum number of transmission attempts for confirmed packets, based on the node density and traffic load.
This paper has hints for sensor node firmware.
Likely not what you (nor I) wanted to hear.
Our client products are smart city street lights. Our part is just to create a platform to help them use their street lights. But we have worries about the reliability when we were testing out their devices with the platform. Can’t be telling our client that their solution’s not working 
I guess for now we have to find alternative means to inform the user that sometimes the device will not get the downlink. Thanks for the help though. Learn alot from this 
It sounds like your clients haven’t implemented a scheme suitable to their goals, so actually, explaining why it’s not going to work is exactly what you should do at this point, as that’s the only way you can begin the joint process of evolving the system into one which actually could work.
Given these are streetlights, they should have mains power, and given mains power, you can simply operate in Class C “always listening” mode - though they’ll probably need firmware changes to support that. The beauty of this, is that you can just send a command, and not have to wait until the node polls with an uplink.
Then, indeed, you either need to get the node firmware fixed to support confirmed downlink, or to send its own application level custom confirmations that it has turned on or off as requested, or you need to at least make it so that in every periodic status uplink, it’s reported if the light is or isn’t on. Then if the light should be on but isn’t, you can send another turn on command.
The absolute last thing you want to do is start deploying hardware when the firmware doesn’t yet viably support the needed use case.
The streetlights are configured in Class C right out of the gate. Don’t get me wrong, the lights are working. We can send command and the light do send back uplinks as a response, it’s just the inconsistency of the transmission that worries us since most of the action done through our platform is actually sending out a sequence of commands. If one of those commands wasn’t transmitted, than the action was incomplete.
So what’s the problem?
Radio systems are unreliable, until wrapped in a retry layer.
Send the command; wait a bit to check for a response indicating it was received, if not send, it again.
Turning on street lights doesn’t sound like something that has to be executed too precisely in time, a few minutes +/- shouldn’t matter since the proper time is a judgement call to begin with.