If solution found please do share - we are all in suspense! 
Clue …that will be because Nick is Chairperson of the local Lepidopterology Society in N.W Greater Manchester/Burnley area (total membership 1). 
In my case I think it is not caused by the temperature.
The node is self built and consists of a PIC microcontroller and an RN2483. The controller is checking on receiving mac_tx_ok after each transmit of data. It seems that for any reasons the RN2483 did not send mac_tx_ok and then my node stops running. Also I am using cnf, I will change to uncnf soon.
The indoor node is already running with uncnf without any problems.
I believe that with a 5 min interval you are likely therefore breaching the TTN FUP! Soon = now? 
The node ran last night without problems. Previously, I had it connected to one of these:
The Arduino and Dragino shield pair were plugged into the outlet labelled, “Always ON”. The IOT Relay controls a string of lights, and perhaps the voltage delivered to the AC adapter for the Arduino “sagged” under the load of the lights. The node off time was exactly that of the timer settings for the IOT Relay’s lights.
Once I removed the Arduino AC adapter from the IOT Relay and plugged it into the mains, the unit ran all night.
Seems unlikely. If you look at your mains power adapter, you’ll probably see it’s rated for fairly severe undervoltage, to the point where if things were dropping that far, I’d be more concerned about fire risk than LoRa packets.
You might have radio frequency interference from the lights though… or possibly a horrible amount of distortion of the mains waveform from an evil light supply, though I’d expect most switching adapters to survive that.
Are you really sure the times match? The recovery point seemed to be different on different days, and there was the one that didn’t fail.
My actual guess would be that this is just coincidence and the real cause is something else. Note that seeing the problem fixed would not confirm the theory; you’d have to be able to re-create the problem by this method.
Yes. The waveforms are dependent on that day’s temperature, and since those vary, they appear to be unmatched. Also, the middle of the waveform shows no loss of data, and the program I run to control the lights was off that day.
The lights were on last night, but the node was on the mains, not on the relay and I got payloads all night long. So the interference issue doesn’t jive.
Thank you for your comments. I feel a little sheepish about this. My Engineering skills are not what they used to be.
If the lights are really causing a brownout on the extension cord, you have a serious fire risk, not a LoRaWAN problem.
I really believe your LoRaWAN problem is something else.
If the lights are involved at all, it had better not be that much droop of the mains voltage but rather some other mechanism. Because if that is really it, you are in a quite dangerous situation, LoRaWAN project or no.
The airtime is 61.7ms, 5min intervall = 12 transmits per hour = 123.4ms per hour = 2.9616s per day.
I will delete the check of mac_tx_ok, the loss of some data is not a big problem for me.
No. You need to change the sending mode to unconfirmed, as otherwise each affordable transmission will prompt an unaffordably expensive (in terms of capacity) downlink in response - even if you ignore the result.
Its not the time (up or down) that is the problem - its the limit of number of downlinks! (Remember each time GW Tx’s your downlink it is unable to listen to every other node that may be transmitting an uplink - hence the limit for social responsibility.) Must confess I sometime find I have mis-configured a node or power up an off the shelf device only to find it breaches limit, or may deliberately configure as conf mode for short test (<10 Tx/Rx pairs) and get distracted or forget to switch off/change settings - am sure it happens a lot and to many people, but once aware should take immediate steps to correct where practical.
- At most 10 downlink messages per 24 hours, including the ACKs for confirmed uplinks.
Be aware the RN2483 (not the A) is known to stop sending data when the temperature drops below zero C.
@Jeff-UK: I changed to unconfirmed.
@kersing: I’m using RN2483A.
I’m thinking about changing the interval to 10min, but now I leave it at 5min and will see what will happen.
The node fails to communicate while the lights are on AND WHEN the AC adapter for the Arduino is connected to the Relay. It was my wild a** guess that the relay voltage was sagging. Perhaps that was a little reckless of me to suggest. Inteference/noise? Perhaps. I’d love to troubleshoot it and really understand. I am not concerned about a fire as the total wattage of the lights is perhaps 500W. I have a watt-meter. I will check that out.
Night 2, Arduino not connected to the IOT Relay, no data gaps. I still have to measure the power draw of the lights. There are 55 of them.
Do you have a way to safely measure the voltage at the power strip when the lights are on?
Something like a Kill-a-watt plug-meter would measure both the consumption and the voltage.
You could also plug in the node’s main’s power supply and measure the output of that while the lights are on…
Thanks - good idea. I have one of those and plan to use it. I wish I had more time during the week. I will do the measurements this weekend.