meshtastic
[Feature Request]: Add a client last connected timestamp to NODE_INFO
Platform
Cross-Platform
Description
Often its unclear which nodes in a mesh are monitored, and which are infrastructure -- especially when the current recommendation is for most nodes to be client or client_mute.
This feature request is to add a timestamp to NODE_INFO, indicating when an interactive application was last connected to the node (via BLE, serial, or HTTPs). This could then be reflected in the node list (similar to last heard), so as to give some indication of which nodes are actively monitored.
I like this idea, but NodeInfo (specifically User) is something we have to guard pretty heavily against growth unless it's deemed a necessary addition, since it's such a prevalent packet on the mesh and also gets stored for each node on the device's constrained filesystem.
What about a boolean on the DeviceMetrics proto? true if something is connected via serial, tcp or bluetooth. false otherwise.
What about the device metrics packet? Those are more frequent, and it could just be one bit (is a client currently connected)?
how about a boolian value of if the node has been connected to in the last 24 hours
its still extra data , but as its an abstraction the data load is less
Jumping in here per GUVWAF's suggestion following this conversation on Discord. This timestamp functionality could be merged with my request for Read Receipts, as per below:
Feature Request: Show read receipts on the sender's node when a direct message is read by the target node.
Proposal: When the target node reads a DM, send a read receipt back to the sender. This should be disabled by default to minimize unnecessary network traffic.
For example, what could be done is send an additional bool with the ACK on a direct message that indicates whether there is currently a client connected to the node.
For example, what could be done is send an additional bool with the ACK on a direct message that indicates whether there is currently a client connected to the node.
I like this idea for DMs, but I think there's a more general need in the nodes list somehow. I don't DM most nodes, but would still like to know which are monitored