Mqtt to HA improvement with version information #155

Closed
opened 2026-10-05 02:00:31 +02:00 by adam · 8 comments
Owner

Hi
Can we please get device firmware version information added to the mqtt info that is sent to Home Assistant?

Hi Can we please get device firmware version information added to the mqtt info that is sent to Home Assistant? <!-- github-sync-id:4306022002 -->
adam closed this issue 2026-10-05 02:00:31 +02:00
Author
Owner

Howdy! Version info how so? Firmware? Hardware? Remoteterm?

Howdy! Version info how so? Firmware? Hardware? Remoteterm? <!-- github-comment-id:4292753831 -->
Author
Owner

Sorry =) firmware. We are trying to get all to version 1.14+ and would be very beneficial to see which ones need to be updated

Sorry =) firmware. We are trying to get all to version 1.14+ and would be very beneficial to see which ones need to be updated <!-- github-comment-id:4292769102 -->
Author
Owner

So that would only include your own node; other nodes/contacts don't expose their firmware version. Is that what you're meaning?

So that would only include your own node; other nodes/contacts don't expose their firmware version. Is that what you're meaning? <!-- github-comment-id:4293021759 -->
Author
Owner

Correct. I am talking about the mqtt node info that it sends to Home Assistant under 8h checks.
Also, a lot of repeaters use default "hello" password for read only access to some info. Version is available to read only under owner info

Correct. I am talking about the mqtt node info that it sends to Home Assistant under 8h checks. Also, a lot of repeaters use default "hello" password for read only access to some info. Version is available to read only under owner info <!-- github-comment-id:4293163575 -->
Author
Owner

So for 8 hr checks, you're talking about repeaters; are you meaning collecting version info from repeater telemetry? We only publish repeaters that are opted into telemetry gathering to MQTT, and that requires having already logged in with a password that gets you added to the ACLs. So you're meaning adding firmware version to those up-to-eight repeaters that you already have admin for into MQTT? I don't think that's something that's super valuable to be fetching on a regular basis; the assumption is that these are repeaters you already have admin for. I get the sense that maybe you're trying to capture a general picture of mesh upgrade status, which isn't really a use case the HA MQTT is optimized for -- more about keeping tabs on your own corner of the mesh.

Maybe I'm misunderstanding.

So for 8 hr checks, you're talking about repeaters; are you meaning collecting version info from repeater telemetry? We only publish repeaters that are opted into telemetry gathering to MQTT, and that requires having already logged in with a password that gets you added to the ACLs. So you're meaning adding firmware version to those up-to-eight repeaters that you already have admin for into MQTT? I don't think that's something that's super valuable to be fetching on a regular basis; the assumption is that these are repeaters you already have admin for. I get the sense that maybe you're trying to capture a general picture of mesh upgrade status, which isn't really a use case the HA MQTT is optimized for -- more about keeping tabs on your own corner of the mesh. Maybe I'm misunderstanding. <!-- github-comment-id:4293203549 -->
Author
Owner

If you manage multiple, it's super valuable
I also mentioned that read only user can get version info from any repeater that allows read only access

If you manage multiple, it's super valuable I also mentioned that read only user can get version info from any repeater that allows read only access <!-- github-comment-id:4293289135 -->
Author
Owner

Yeah, I get where you're coming from.

Ultimately, re: auth, yeah any repeater that grants you ACLs is sufficient to grab data off of.

However, there are two pieces of general design objectives that lead me away from this. First, the automatic telemetry fetch is already a concession to convenience; in general, I don't want RemoteTerm being a source of automated traffic on the mesh, contributing to noise; this feature would add an additional radio call (ver) to every repeater for a feature that I don't think falls within the purview of most repeater owners' needs (voltage, temperature, sensors, etc.). Second, HA integration is intended for real-time action. We're interested in home automation, dashboards around frequently-changing data, entity triggers, etc., not as a kitchen sink of data integration.

RemoteTerm provides a very open API that can be used to interrogate repeaters programmatically; tracking a personal set of repeater status seems much more suited to that than doing so in HA. I don't disagree that it would be possible or convenient to do so, but I also don't think HA is the right place for that kind of data to be managed in, given my design goals.

I think this is going to be a no for now, sorry.

Yeah, I get where you're coming from. Ultimately, re: auth, yeah any repeater that grants you ACLs is sufficient to grab data off of. However, there are two pieces of general design objectives that lead me away from this. First, the automatic telemetry fetch is already a concession to convenience; in general, I don't want RemoteTerm being a source of automated traffic on the mesh, contributing to noise; this feature would add an additional radio call (`ver`) to every repeater for a feature that I don't think falls within the purview of most repeater owners' needs (voltage, temperature, sensors, etc.). Second, HA integration is intended for real-time action. We're interested in home automation, dashboards around frequently-changing data, entity triggers, etc., not as a kitchen sink of data integration. RemoteTerm provides a very open API that can be used to interrogate repeaters programmatically; tracking a personal set of repeater status seems much more suited to that than doing so in HA. I don't disagree that it would be possible or convenient to do so, but I also don't think HA is the right place for that kind of data to be managed in, given my design goals. I think this is going to be a no for now, sorry. <!-- github-comment-id:4293325260 -->
Author
Owner

Ok

Ok <!-- github-comment-id:4293566028 -->
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/Remote-Terminal-for-MeshCore#155