I have a RAK5205 sensor connected to a RAK7258 gateway. I am using confirmed messages by the following AT command:
at+set_config=lora:confirm:X
However, if the gateway loses power and is turned back on, I no longer get any messages. Is there any way to fix this? If I deploy IOT devices that are hard to get to, I don’t want to have to reset them all if the gateway looses power or has to be restarted.
When you open the gateway again, the node will look for the corresponding frequency point when sending the data. Once the frequency point is successfully matched, the gateway will continue to receive the data. As shown in the figure, the error received before for the gateway is not open, and the confirmation packet will be sent after the corresponding success.
How long should this take? I waited a few minutes without any success.
I did some more testing. I turned on the gateway and turned on the sensor and verified they connected and sent data. I then turned the gateway off and then turned it back on.
I no longer get messages in the application live data view:
I see messages in the packet logger but do not find the ACK messages going out. (I have a picture but can only put one in per post.
You need to give orders
at+get_config=lora:status
at+get_config=device:status
Check the interval between each time you send data and the time it takes to search for GPS to determine how long it takes you to receive data.
The data you get here must be transferred after you open the page. It does not save the data you sent before.
The data here proves that some data has been uploaded to the gateway, but you must make sure that your node three-parameter configuration is the same as the configuration in loraserver, otherwise you will only see this data in the gateway log.
First of all I turned the GPS off. I also have 30s send interval. I am not having problems with the device sending data. When I power both on and reset the sensor, I see data in both the packet manager and the application Live Device Data fields. I have a problem if the gateway is power cycled.
Yes, I understand it does not save data from before. I am saying that there are no ACK messages sent from the gateway after the gateway power cycles. This is a problem because now the sensor does not know the gateway is getting the data so it retries multiple times and uses more power.
The DevEui, AppEui, and AppKey are the same in the device and the gateway. Like I said above, I see data in the Application Live Data before the gateway power cycles.
Why would the gateway stop sending ACK messages after it power cylcles? That is the big question that I want an answer to.
I still have not figured out how to fix this issue. Does anyone have any suggestions?
Are you using the built-in LoRaServer or are you connecting to an external server, like a cloud hosted instance of LoRaServer, or TTN, or something else?
Your mention of DevEui, AppEui, and AppKey makes it sound like you are using OTAA - Over the Air Activation. In that scheme a temporary session is created between the node and the server. Should the server lose state, it will not know anything about this session, and be unable to respond to the node, until the node guesses that is the problem and issues a new “join request”.
The ultimate lesson of LoRaWAN is that wherever the server is, it cannot be allowed to lose state.
If you are using LoRaServer you should be able to find a view that will show you the session details (if any) applicable to a node. In particular, does the server still think that device address 02000001 is assigned to this node?
I am using the built-in LoRa server. Is there a way to make a permanent state? I do not see a way where I can make sure my server always have power no matter what. Having to update firmware or settings and requiring a power cycle would also make that harder.
The Live Data view is the only node specific session details I can find which does not show me any messages.
What is your actual application?
If you are running the server in the gateway, that hopefully means you only have one gateway, which likely means a fairly small setup overall. Using ABP (“activation by personalization” or baking the two keys into the device itself) would simplify things a lot compared to OTAA registration, and reduce the number of things that can go wrong. If you then disable frame counter checks it would be nearly stateless.
Or if your really need OTAA you might consider using a server hosted in the cloud instead, and returning the gateway to the traditional role of being an RF to Ethernet translator with no real understanding of the data flowing through it, and no actual role in the conversation. Then you take care to persist the redis database and back up your server.
That’s not to say that on-gateway storage as these are intended to support can’t be made to work, but it’s a hard problem to solve thoroughly in a way that is reliable in all cases. And if someone actually steal your gateway from wherever it is installed, you still lose your session records…
