GUVWAF

The downside of adding a watchdog is that it hides (potential serious) bugs. Especially since the maximum timeout you can set is relatively short and it requires workarounds like this...

> Sorry for the late answer, vacation time got me :-D No problem, we're all doing this for fun :) > my test devices had uptimes between 3 and 14...

> Just to make it clear :-D the 3 hour reboots was after having only the 8 seconds timeout, so no need to debug into that ;) Ah, I see....

Yes, that sounds correct. Currently the timestamp when the packet was actually received is not stored and send with the packet upon request.

I think we can make this work. Currently we do store a relative time in the StoreForward history, but we can change it to an absolute time if we have...

It may be you're unlucky and one of your private channels ends up with the same hash as LongFast with `AQ==` (it's only a 1-byte hash, so collision is possible)....

@Th3H0ff that doesn't matter. When receiving a packet, the node doesn't know which key to use to decrypt. For that, there is a 1-byte hash in the header as a...

Since NodeInfo is not sent very often and this might not be a static setting, maybe we could add a uint32 to DeviceTelemetry instead? That could indicate the last connection...

Yes, I also don't mean that this should be set by the client. The firmware can determine when a client was last detected. If people are setting this initially but...

What about an enum with multiple states for "attendance"? E.g. never, always, daily, weekly, monthly or even "bot"? It would maybe not even take up more than a bool on...