Hi @cslorabox, you are, of course, entirely correct. This is the choice between dumb-sensor & central-computing vs. edge-computing.
In my career in oilfield automation both were used with very little in the middle. Most of the automation is dumb-sensor & central-computing. The main edge-computing exceptions were sensors for rotating equipment vibration analysis where only the Fourier Transform is uplinked and InfraRed image analysis looking for fires and equipment hotspots where only alerts are uplinked.
The unreliable nature of any radio network creates difficulties for both dumb-sensor and edge computing. They are just different difficulties.
Using LoRaWAN we deployed a number of Eolane “bob assistants” using Cartesiam AI for monitoring rotating equipment.
Actually I see it as more of a “design issues with LoRaWAN” issue in terms of the premium cost of downlinks in the protocol, especially in a class A only setting such as TTN.
“Edge” computing wouldn’t be able to do things like ramp up the reporting at nodes nearby one that gets an anomaly in order to be able to watch it spread in real time.
Though yes, for the single node interest, with the connectivity currently available, a tiny bit of “edge computing” in the sense of having a triggered ramp-up behavior in the node (which could be tuned by commands) could make sense. There’s a balance there, too - how much should one node ramp up, and how much should it consider that its neighbors may soon need to as well, making claiming more airtime not without issue.
Depending on many different design / environmental factors, mostly power & timing, nodes can switch to a mesh mode to inform those close by that things need to be escalated.
Makes more sense to do it with a scheduled multicast downlink; a mesh wouldn’t really work without creating clock synchronization for receive windows, and the network server does that best.
Not only does that avoid potential conflict between multiple nodes trying to autonomously transmit in their peeer’s receive window, it also means that the same periodic receive window can be used for maintainer or infrastructure originated messages.
The issue isn’t that these things can’t be done, but that LoRaWAN both as a matter of design and especially in the limited form implemented by TTN doesn’t do them.