Thanks again for this, its been working like a champ. I was fiddling with it today and I wonder if we missed the a "motion" metric? I noticed that I'm not seeing any of my motion devices in prometheus.
Hey, so glad to hear hubitat2prom is working out for you!
First things first, is motion one of the items in the HE_METRICS environment variable list? If not, it will need to be added and that may resolve this. If it is listed already let me know and I'll dig into it for a fix.
For a little bit of background, the last release (v1.2.6) supports "arbitrary" properties that aren't one of the named ones in the HubitatDeviceMetrics or DeviceSummaryAttributes classes. Here are two related unit tests. And if you've been looking through the code, this comment is out of date and should be removed. All this is to say that, in theory, as long as the correct metric name is in the HE_METRICS variable, it should gather that data.
ah, I was working off the list of metrics listed in HubitatEnv.cs which doesn't include motion. I added motion to he_metrics and now it shows up in prometheus, but the value is always zero.
I have a virtual motion switch in HE so I was able to create motion events, but no motion events showed up in Prometheus. That device is listed, but no motion events. All Zero.
I was working off the list of metrics listed in HubitatEnv.cs which doesn't include motion.
Thanks for letting me know. I have added an item to my backlog to improve this documentation.
Okay - so let's see if we can figure out why your metric values are 0.
I don't have any motion devices - can you paste the JSON content of the device summary and its attributes from the Maker API? That will help me debug with real data so I don't need to make assumptions. You can find all the device metrics at http://<hubitatIP>/apps/api/<id>/devices/all?access_token=..., and then you can search for just the motion device.
As well, do you happen to know exactly how the device behaves when reporting motion? I'm likely not going to get the nomenclature correct for motion devices, so bear with me.
For example:
- Does the device report a real-time motion event, immediately followed by a "no-motion" event? That would mean detected motion "values" are do not persist for any amount of time.
- Does the device report motion, and never reports "no-motion?"
- Does the device report motion then, after some amount of time, report "no-motion?"
- Does the device report motion, after which Hubitat decides when there is no motion?
- Something else?
And how often do you have Prometheus configured to scrape the hubitat2prom target? My suspicion is that the motion / no-motion events are occurring within the window between scrapes, which would mean hubitat2prom would never see the "motion" events.
ok, here's the json
{
"name": "Virtual Motion Sensor",
"label": "Doorbell Motion",
"type": "Virtual Motion Sensor",
"id": "1297",
"date": "2025-04-16T00:39:07+0000",
"model": null,
"manufacturer": null,
"room": null,
"capabilities": [
"MotionSensor",
"TemperatureMeasurement"
],
"attributes": {
"motion": "inactive",
"dataType": "NUMBER",
"values": null,
"temperature": "70"
},
"commands": [
{
"command": "active"
},
{
"command": "inactive"
},
{
"command": "setTemperature"
}
]
},
It looks like the currentValue toggles between active / inactive.
To answer your followup questions.
- This Device immediately emits an "active" event, and an "inactive" event after a configurable amount of time. The HE virtual motion device makes that configurable. I currently have it set to 15sec.
- I have a ThirdReality motion device that looks like it reports inactive after 30sec. (non-configurable) I don't know if its hard coded in the driver or if that's how HE treats motion sensors.
I see the problem of how if the time window where a sensor reports motion is smaller than my sampling window there could be missed events. I think that's something we'll just have to live with.
Edit: I just checked my prometheus scrape time for hubitat2prom. Looks like I currently have it set to 20s. (longer than my motion event) So I need to adjust 1 or the other to rectify that.
Awesome, thanks for the additional information. Indeed it sounds like the scrape interval is the issue. Frustratingly, it's one of those things that would appear to work inconsistently when those windows overlap.
If your Hubitat is otherwise not too busy, I have had Prometheus configured to scrape the hubitat2prom target as low as 15 seconds without noticing any problems. I haven't tried lower than that.
If you want to get clever, I can envision something like a virtual device that stays "active" for longer, triggered by an actual motion event, and tracking this metric in addition to the actual motion device. You could then query the metrics in a way to show "actual" versus "assumed" activity by using metrics from both the motion and virtual devices.
Another option would be Prometheus Pushgateway. I think it would be possible to set up a Rule Machine rule to "push" some metrics to, for which you can create a Prometheus target. I've never tried this before, so no promises. 
This Device immediately emits an "active" event, and an "inactive" event after a configurable amount of time.
Unfortunately, the way I originally wrote hubitat2prom has a limitation wherein some strings that represent a boolean state (1 or 0) have to be explicitly supported. Here's where that exists in v1.2.6. The "future" release v1.3.0-rc1 takes this in a different direction, but I haven't gotten back around to this in a while
Anyway, let me jump on this tomorrow and I can add support for active/inactive for v1.2.7. Or you can make the change and submit a pull request! I'm happy to work with you on that.
For the time being I have no problem adjusting my motion detection interval to be greater than the scraping interval.
As for the code change, I'll take a look during my lunch break (EST) as I'm a .net developer as well.
1 Like
