The issue here is that some single-channel forwarders (such as the
tftelkamp version) do not support downlink messages. As we mostly focus our development on real gateways (multi channel with downlink support), single-channel-no-downlink gateways are easily forgotten.
We recently implemented an optimization in our backend that connects gateway streams when the gateway is active, and disconnect when the gateway becomes inactive. As some gateways don’t see much traffic, we can’t base this “state” on the uplink messages that are received from those gateways. However, all forwarders (except these single-channel-no-downlink ones) ping the server every 5 seconds, so we decided to use these pings to determine whether the gateway is active or not.
As a result of this choice, forwarders that don’t “ping” for downlink messages are assumed “offline”, and this results in the uplink traffic received from these gateways is not being handled correctly. I’m working on a solution for this.
The problem that @asier mentions is unrelated. For some reason the console does not correctly reconnect to the NOC when the connection breaks. This results in the “NOC connection timed out” message, message counters being 0 and traffic not showing in the “Traffic” view of the console. Messages should still be delivered to applications, because that does not need the NOC.