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.
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 
2 Likes
Hi, sorry I am not too active here. Main discussion going on at Github. Yes there is a 1.0.1 version out for test supporting the Homey Pro 2023, at least theoretically. I received some positive reports from the early testers.
Iāve also set up a donate link. I will do my best to support all these new Homey devices that Athom decided to release, but If I happen to get enough donations, I will at least promise to use them to buy a newer Homey Pro device to use for testing. I have absolutely zero use for one of them myself, as the trusty old Homey 2016 solves all my home automation needs. I stress that donation is absolutely volontary and I will do my best to support the newer devices regardless, but I would lean more on the community for testing.
This issue tracks Homey Pro 2023 support: Homey Pro (Early 2023) Ā· Issue #35 Ā· rickardp/homey-prometheus-exporter (github.com)
3 Likes
