[APP] Prometheus.io exporter

@Gruijter It is not the state changes that trigger device update events (https://developer.athom.com/docs/api/HomeyAPI.ManagerDevices.html#.event:%22device.update%22), rather updates to device metadata. I have created version 0.2.7 which improves logging (in addition to a larger timeout on device updates). Could you please try that and do the diagnostics report again? This should at least tell us which driver is the culprit.

0f57321f-2f87-4cc2-a449-e6330b6fe8b9

Only one update made it to the logs, but the device was LS120P1_Σpower with driver id power. Do you know which app it is?
I think I could optimize the device refresh (I made the assumption that device metadata changes are rare), but maybe having a look at what the app does gives some insight into what data changes?

EDIT: I think I found the app (https://github.com/gruijter/com.gruijter.powerhour/blob/master/drivers/generic_device.js) (your app? :). I wonder if it is the call to device.setSettings with every poll that cause the device change to be triggered.

It is from PowerByTheHour (one of my own apps).

Edit: lol
I have to check why that app is doing setSettings every poll. It would only poll at midnight by the way.

No, it is doing setSettings at every meter change, so that might be a lot indeed.

Cool. I only had a brief look at the code but it looked like it was calling it with every call to updateMeter, which seemed to be triggered by some listener. Maybe the Homey will actually trigger a device changed event with every call even if nothing changed?

I could maybe make the Prometheus app more robust by checking for the stuff I care about, but it may be less than trivial, I have to check.

1 Like

I also had to disable it. I like that the way how it looks and that logs are better stored than on Homey itself but it makes my Homey unusually slow. Hope it can be fixed in a new version.

hi @Daniel.007

Did you try this: Prometheus.io exporter
(few posts up)

Question, I’ve the issue that the “homey_device_measure_temperature” key has a lot of different temperatures, some of them (of a specific device type from one vendor) are reporting not a room but the device temperature - which is not important for end users. So I need to filter the device temperatures out. However I have no option to filter, exception for the “name”. As I know the device/type and app, is there any option to add a key/value-pair for the device-type and/or the app? Today I see the following keys:

  • device
  • instance
  • job
  • name
  • zone
  • zones

Hi all

Is this APP still working? I see the discussion stopped May 20, so I wondered if it has stopped?

If not, how is the CPU load going?

And in the end. For a novice, how to make this work? I have grafana and I’ve downloaded the app. Does it have to be done by CLI? How do I then change the configfile to state the local IP-address?

-Stian

Hi @StianD

The app is still working, CPU load is normal.
To install it, follow the guide here: GitHub - rickardp/homey-prometheus-exporter: Prometheus.io exporter for Homey

This app only provides an webpage (http://YOUHOMEYIP:9414/metrics) which a Prometheus server can scrape. Grafana then has to be configured to the prometheus server as a data source

I am the creator of the app and still use it continuously. I don’t hang around here much anymore (mostly because my home automation set up is quite stable as it is and “just works”) but if there are problems/feature requests, GitHub is the best place for those.

1 Like

Long time no update. New version is out that will add a device “class” label that exports the device class (light, socket, etc). This is useful to group power consumption by device type, for example.

The current live version unfortunately has a bug with older (<8) Homey firmware, where it will crash on some device updates. The reason for the crash is that I used too new JavaScript syntax, which apparently was not supported on older devices.

I have submitted a new version that fixes this, and also fixes a bug with internal profiling when system clock skewed (probably due to NTP update).

1 Like

Thanks a lot @Kyrcio for pushing the new version! I’m gonna use the device “class” for sure! Is there any option to be more specific like a device driver name additionally to the device class? Or do you have any other device specific options?

I’ve just opened a new bug report (Very high CPU load with v0.2.10 · Issue #25 · rickardp/homey-prometheus-exporter · GitHub). I’ve massive CPU load issues with the app… I can’t have it enabled as the load is that high that we see an impact for all other apps…

device driver name additionally to the device class

Version 0.3.0 adds support for driver app/id (“driver” and “driver_id”). It is available on Prometheus.io App for Homey | Homey for testing.

CPU load issues with the app

Thanks for the detailed report. Please see my response in the issue.

Version 0.3.3 should see significantly lower CPU usage by sacrificing latency on storage stats. It seems the API calls to get this info has become more expensive in newer Homey versions (or is possibly caused by popular apps). This issue affected some but not all users, and it is not clear why.

If you on version 0.3.3 still have problems with high CPU usage, please create an issue on GitHub with a diagnostic report and some timing stats from the “Homey Exporter” dashboard.

1 Like

Hey all,

It may be my homey, but in my config, the Prometheus app keeps crashing. I can’t get it to run stable for longer than 10 mins.

Is this happening to more people?

Hi, @Kyrcio are you planning to update this app to SDK3? so it will be supported on the new Homey Pro 2022

Really hope so because i like/use it a lot :slight_smile:

2 Likes

Now there seems to be a test version for the HP2023: Prometheus.io | Homey

1 Like