[Enhancement] There should be a way to get all the information from your node in real time

[ogarcia]

Currently, the only way (at least the only one I have been able to find with the current documentation) to obtain all the information from your own node is to use the node list, filtering by the node's id !XXXXXXXX. This obtains the information from the last time your node reported its status, which is far from real-time information.

There should be a way to obtain all the data from your own node without having to report it to the mesh in any way, a simple query of “give me my info” that returns a dictionary similar to the one you get when you query the node list, but with real-time information. This would allow you to use the node as, for example, a weather station and collect your own metrics at a much lower rate than those sent to the mesh.

[juergenRe]

Could you please give an example of what exactly you want to transmit immediately (best would be to copy the output from the CLI here)? With which command you retrieve it today? I assume "--info", but I am not sure... thx.

[ogarcia]

On the one hand, the info command (something I would generally include in all commands) should have a --json or --yaml modifier so that the information it returns can be parsed in some way. On the other hand, as far as I know, there is no command that allows you to obtain real-time telemetry from the node. With --nodes you can see it, but it is not in real time; it is from the last time the report was sent.

IMHO, those would be two major improvements that could be included in the CLI.

[juergenRe]

For the format of the --info I agree - this has been one of the first things I stumbled over when I first used the CLI a few weeks ago... My impression is that the CLI is not thought from an automation point of view - but one major usage is to automate and script things when using a CLI or API. For me there seems to be a partial mismatch and room for improvement.

But for your second point I am still not sure what exactly you have in mind. What does the term "telemetry" exactly mean here? What data do you want to get? As an example I paste the (partial) contents of my test node:

    "position": {
      "latitudeI": 471072768,
      "longitudeI": 73138176,
      "altitude": 437,
      "latitude": 47.1072768,
      "longitude": 7.3138176
    },
    "deviceMetrics": {
      "batteryLevel": 101,
      "voltage": 4.189,
      "channelUtilization": 1.4766667,
      "airUtilTx": 0.02461111,
      "uptimeSeconds": 65
    },

These are the data I associate with your question about "telemetry". Is this correct? Or do you have more (potential) data in mind? We also might think about actual temperature if there is a sensor or the number of messages passed (I am not sure if this is possible at all).

[juergenRe]

From my current analysis I can see the following:

1. When connecting to a radio, the CLI first gets all configuration data and the nodes list.
2. However, the node_info protobuf will not always transfer the part deviceMetrics - this seems to be handled by the radio itself. position on the other hand is transferred always, evtl. when you set a fixed position (need to test what happens when no fixed position is set and no GPS is on board)

The question then is: is there a request protobuf to get all actual deviceMetrics upon request?

[ogarcia]

The question then is: is there a request protobuf to get all actual deviceMetrics upon request?

That's the point. The data you get is from the last time it was transmitted by radio, but it's not in real time.

On the other hand, it gives you the node's position and basic metrics, but it lacks the rest of the metrics that the telemetry module provide, such as temperature, humidity, barometric pressure, etc.

That's what I mean in this enhancement / feature request:

1. It is impossible to obtain real-time metrics.
2. The telemetry module metrics are missing.

[juergenRe]

OK, thank you. I understand now for what to look out.