[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.

[juergenRe]

I just openend a PR #872 to implement the formatting part of your request.

[juergenRe]

Concerning the "real-time" data I have been looking around in the docs and the phone app to understand what are the options available. As far as I understand, the radio is designed to capture data in defined time delays, so sampling with a constant rate. This will allow the radio to enter sleep mode in between and save energy. There a messages to the radio defining these sample rates.

But I did not find a message to trigger a sample immediately, which will be needed to realize your request. So, the CLI cannot implement this for the moment. An update to the radio communication specs need to be done first.

This is my actual understanding, please correct me if I am wrong.

[ogarcia]

But I did not find a message to trigger a sample immediately, which will be needed to realize your request. So, the CLI cannot implement this for the moment. An update to the radio communication specs need to be done first.

It may be necessary to make some changes to the firmware, but I'm a bit lost there.

[juergenRe]

Yes, I agree. But then you need to post it in the firmware section... I can't do changes to the firmware.

[ogarcia]

Yes, I agree. But then you need to post it in the firmware section... I can't do changes to the firmware.

I'm not so sure that changes need to be made to the firmware, because the Android app retrieves telemetry data from the node once per minute, and it's getting that from somewhere.

Just like the Android app, the Python client should be able to do this.

[juergenRe]

That conforms with what is written in the docs: when you are connected directly to the radio, it will update the deviec metrics every minute (but, as far as I understand here, not the other telemetry data).

But your point is valable: somehow the radio need to know about the direct connection.

Currently I try to set up some telemetry on my devices, to better understand how it behaves. Maybe I find something then.

[juergenRe]

I did some tests with my devices. You have been right, --request-telemetry --dest <node> will request the data from the node you specify. Those data will always be actual data.

Of course you need to activate the sensors you want to transmit data within the moduleConfig.telemetry part. But in this sense you will get "real-time" data.

The info output will not show telemetry data except the device metrics. Probably because only device metrics is always present and all other parts will be optional. From my understanding, info shall just give an overview of the settings/data of the local node, so telemetry data of distant nodes go beyond this scope.

But this is not really a limitation: just repeat the meshtastic call for the telemetry data you are interested in and you should get the data you want.

One additonal remark: the --request-telemetry does not work the first time after a reboot, I opened an issue to this (#874)