Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow overriding the device id regex per metric #116

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

wmoss
Copy link

@wmoss wmoss commented Jan 4, 2023

This allows the regex used to extract the device id to be overriden per metric. This required a little reorganizing of where the device id is parsed from the topic (and therefore how it's passed between functions). The default parsing remains the same.

This is useful (in my installation) with the availability topic created by Zigbee2MQTT. It creates topics like, zigbee2mqtt/thermostat/availability for availability. The main topic, zigbee2mqtt/thermostat, has the main set of metrics (and correctly parses using the default device id regex) but then zigbee2mqtt/thermostat/availability has {"state":"online"}. With this change, I can add a config that looks like this,

 - prom_name: availability
   mqtt_name: state
   help: Device availability (from Zigbee2MQTT)
   type: gauge
   device_id_regex: "zigbee2mqtt/(?P<deviceid>.*)/availability"
   string_value_mapping:
    # A map of string to metric value.
    map:
     online: 1
     offline: 0

and then get a bunch of metrics that look like this,

availability{sensor="living_room",topic="zigbee2mqtt/living_room/availability"} 1 1672873723990
availability{sensor="bedroom",topic="zigbee2mqtt/bedroom/availability"} 1 1672873723964
availability{sensor="thermostat",topic="zigbee2mqtt/thermostat/availability"} 1 1672873723964

This allows the regex used to extract the device id to be overriden per metric. This required a little reorganizing of where the device id is parsed from the topic (and therefore how it's passed between functions). The default parsing remains the same.
@wmoss
Copy link
Author

wmoss commented Jan 8, 2023

Hey @hikhvar just wanted to bump this and see what you thought. I'm very happy to discuss more if you think there's a better way to implement this or any other comments you have. I should have created an issue so we could have discussed it beforehand, but I was in the code and on a roll getting my setup working so I figured I'd just make the changed.

Copy link
Owner

@hikhvar hikhvar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @wmoss,
sorry for the late response. I somehow missed the notification for this PR.

Could you please add some documentation to the Readme for this feature?

@wmoss
Copy link
Author

wmoss commented Jan 9, 2023

No worries, thanks for taking a look!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants