Problem with device force join request

Hello,
I have a problem with device.
I’ve registered device via OTAA and everything was going good. The device registered and and the connection was going well. The problem is that i’ve accidentally deleted the aplication in which the device was registered. When i created a new application and entered for second time the DevEUI and the APP Key the device is not pinging any uplinks. It is showing me that the device has not been activated. Is there a chance to force reset somehow the device so it can send a brand new join request?

1 Like

Powercycling the device would ussually force the rejoin, but you need physical access to the device.

For situations like this the OTAA device should have some kind of self-recovery process so it can find out it has lost the connection on its own. Ussually by not receiving any downlink message in certain time period.

Same issue if we change the Chirpstack server in the gateway.
No rejoin so I need to reset the node.

I remember this feature is implemented in LoRaWAN 1.1.

Interesting… No idea, never had a 1.1 device in hand. I guess you are refering to rejoin feature: Rejoin - ChirpStack open-source LoRaWAN® Network Server documentation
Does it also work for devices never seen on the server or just the ones that has been activated already tho…?

1 Like

Yea about the device, the device is for the consumption data transmission for water-meters. The problem is that once activated there is no powercycling option for security reasons, because the customer that is using it shouldn’t have the option to turn it off or reset it manually. The auto-rejoin is after it send 288 uplink requests, which is ~36 days. My problem is that when it is activated in successfully in application 1 and i have accidentally deleted it and created application 2 after entering the DevEUI and the APP Key the device is not pinging any new uplinks in the application 2 but it is showing the last 10 rows of the history from application 1. Probably it is still connected but the uplinks are not showing in the new application 2. In the manuals of the device there are downlink commands that can make the device to send uplinks more frequently and to request auto-rejoin way sooner but when i don’t see it as activated in the application 2 i cannot enqueue a downlink command. There should be some way to request that downlink manually somehow from the server I guess.

I’m providing the link to the device where you can find the manuals: https://www.bmeters.com/en/products/rfm-lr1/
There is actually a command for device reset: Hex(0305) → Base64(AwU=) and after sending this command as downlink the device will make a new join request, but dont really know how to send the command when i dont have the option to send it trough the new application. This is driving me crazy because i know that there should be a way to do it just cannot figure it out :face_with_monocle:

If the uplink packets are not up, then can not send downlink message.

Unless you can put back the appskey and nwkskey. Yes, session keys.

I am entering the DevEUI key and the application key and when i do that the history from the last uplinks sent to the previous application are showing but the device is set as inactive and it is not sending new uplinks at least not showing them in the new application

Yea, history is probably tied to DevEUI in redis and it may be left stored even after you delete device.

Those messages were stored when server had appSkey and nwkSkey (not just appkey, that is different key). Those keys are created when device sends join request and server accepts it. When deleted, the keys are lost.

Same as @datnus said, unless you have correct ones, you wont be able to receive/decode uplink payload or send any downlinks to the device.