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 -->
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 -->
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 -->
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 -->
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 -->
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 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Hi
Can we please get device firmware version information added to the mqtt info that is sent to Home Assistant?
Howdy! Version info how so? Firmware? Hardware? Remoteterm?
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
So that would only include your own node; other nodes/contacts don't expose their firmware version. Is that what you're meaning?
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
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.
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
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.
Ok