On Mon, Mar 11, 2019 at 08:50:33AM +0800, Mark Webb-Johnson wrote:
I'd do it myself, but I'm not really familiar with Python so it would be slow going.
Me too. I wonder if a first step might be to make the existing OVMS MQTT support more HA-friendly; I think it just needs an option to map '.' to '_' instead of '/' in topic names, and add a suffix.
Is there a problem with the current implementation (in ovms_server_v3)? Changing “.” to “/“ in metric names.
Is there any difference between monitoring prefix/v.b.soc vs prefix/v/b/soc in HA (or other systems)?
Having had a deeper look, I think metric names are fine the way they are. Using '/' has the advantage that clients can easily subscribe to a whole sub-tree of metrics using a wildcard (e.g. '.../metric/v/b/#'). It turns out that only HA's "MQTT discovery" component needs topic names to be flat---but these names don't actually mean anything; they just have to be unique within the discovery process. Metric values are handled by other HA components like "MQTT sensor", which have no restrictions on topic names, so they can be the same as they are on the OVMS v3 server. I updated my script so it preserves the metric topic names: https://ovms.caederus.org/mqtt/ha-pub2 The script's job has almost been reduced to crafting the HA auto-discovery messages. It is still copying values from the OVMS-v3 MQTT server to the HA MQTT server ("ovms_sub ... | ha_pub..."), but as there is no translation going on, that step could be omitted if OVMS and HA were configured to point to the same server (or if the two servers were bridged some other way, e.g. using mosquitto's 'connection' option).