My first experience with LoraWAN, and I am already stuck…
I have got NASYS UL2030 luminaire controller
I have also got Kerlink Wirnet iStation gateway
The gateway is connected to TTN, I can see its heartbeat.
I created an application, registered the device (dev-EUI on the sticker), and tried to connect the controller to the application. To no avail.
I was able to see in the gateway traffic that there are Join requests received from the device, but the device did not connect to the application. In the traffic, I saw which app-EUI the controller was trying to join, so I created another application with that specific app-EUI.
Now, the device requests to join a correct application, but it cannot connect. I believe this is because the app keys are not matched. But, I see no way to access the device in order to configure it.
Any thoughts on origin of this problem and how I could overcome it?
Without getting into your immediate issue, that device doesn’t seem very compatible with TTN.
LoRaWAN is heavily biased towards uplink reporting and not downlink control, and substantially inefficient at downlink because transmitting to one node blocks a gateway from being able to receive from any others.
That’s even more true in the public TTN network, because downlink capacity is shared, and because class C unsolicited downlinks are not supported.
In TTN, a device can only receive downlinks in response to an uplink - so to get downlink commands this device would have to poll by periodically sending uplinks.
You may be able to get it registered on TTN, but it’s not going to work well there.
Thank you for your comment.
I wanted to register the device on TTN as a proof of concept only for the time being. I am new to this field and thought this would be a nice hands-on.
I believe this is because the app keys are not matched. But, I see no way to access the device in order to configure it.
According to the quick start guide:
The necessary data is on a separate sticker in the package (DevEUI,
AppEUI, AppKey).
It seems like you’re going only from the information on the device itself and what you saw over the air, but you need the information that was supposed to be on an additional sticker (maybe with a backing still on it?) in the package.
If that’s not the case you’ll have to get the application key from the device vendor.
I have received the keys from the device vendor. I find it odd that these are, per them, factory configured and not changeable by a customer.
Anyway, my device connects to the TTN, and up-sends a boot message. But, then TTN down-sends back a reset message (fport 51, payload FF, something I put into downlink queue when I had no keys and played fool). Although I cannot see the downlink queue, I see from the traffic that it is exactly what happens. And then my device resets and three minutes later joins the network again etc.
So, the question is, how can I see and flush the content of the downlink queue? I must be missing something.
However, I assume you scheduled a confirmed downlink? As the device is rebooting, it will not send a confirmation, which makes TTN repeat it, endlessly. If true, then the solution is to schedule the same (or some dummy) downlink, while ensuring to use “Scheduling: replace”, and not to select “Confirmed”.
Thank you for your reply. I deleted the device and registered it again, and now all is fine.
I must admit that this seems to be more complicated then I expected
For example, I am not sure about the exact meaning of first, last and replace scheduling. Could someone point me to the resources I could learn more from?
But First adds it first in the queue, Last adds it at the last item in the queue, Replace replaces an item in the queue - as I’ve never queued more than one item, and only rarely as downlinks render the gateway deaf whilst transmitting, I don’t know if it replaces the entire queue, the first or the last item.
