Very much agreed, very confusing… I think the same would apply to trying different packet forwarders on the same network. I feel we already established that TTN does send the ADR commands, in RX2, on SF9, which works for some node(s), but:
Can you repeat this behavior (so: TTN sending an ADR downlink in RX2/SF9, that specific node consistently not changing its settings, TTN re-trying in RX2/SF12 which the node should not receive to start with) if you decode some more uplinks/downlinks? Or did that happen only once?
To ensure TTN does not use old ADR statistics, this might require you to re-register all nodes in TTN Console as maybe TTN preserves the statistics for a new OTAA Join. I’ve no idea; we could peek into the code. Or maybe just temporarily changing the AppKey will clear the statistics, like it clears the DevNonce then. Registration and temporarily changing the AppKey could be automated using the command line ttnctl.
What does this mean? Does that make them lose all their state? (Given the low frame counters, I assume they do.) Or does this only imply that they’ve not been sending for some time? For ADR, TTN doesn’t care how often a node sends; it cannot know if a node is just sleeping, or has been switched off. Unless, of course, the node’s internal state is lost. Like: does it re-join after a power cycle? Does it start at a specific SF after restarting?
But so does TTN, right, for some but not all nodes?
If one node is having problems then it seems to me the nodes are just not 100% the same. Different software, different radio module (RN2xx3?), different firmware in that radio module. Just return the faulty one?