Sorry, I did not realize the old beta version expired once Athom changed the dev experience. New test version published here: https://homey.app/a/io.prometheus/test/
OK, reinstalled everything again with your test version. It is collecting data now.I shall post the graphs in some hours.
edit: this is after 30 minutes running:
edit: 3 hrs graph:
If i compare yours to mine, the time spent per device seems factor 10 higher. this was the case on my homey too, before the change below.
Can you try this:
edited this line (in the app.js file) :
after i made that change, my load went down.
I’m new with docker files. How can i change the yml file… it’s not on my local system. I installed the docker on my NAS
@Gruijter The problem here is that your Homey spends lots of time refreshing devices. Normally, updatedevicelist and registerdevice times should be more or less zero. I suspect that there is something (an app?) that cause the Homey to spam device changes events. Can you please create a diagnostic report for the Prometheus app and send me the UUID for it?
@matrover Actually, the system info loops looks quite normal. Of course it will always be a trade off between update frequency and system load. Note that this metric has its own y-scale in the chart, and that time spent does not equal system load (lots of async calls to the Homey APIs).
I only had the app running for 5 minutes when creating the report. Is that ok @Kyrcio ?
Thanks. I can see that the device update event is indeed triggered very frequently. I would have to add more logging to get a better understanding of why this is happening.
well, I have a lot of devices that each have a lot of updates E.g. my power plugs update every 10 seconds, and I have around 30 plugs or so. And another 50 devices updating every minute. And then I have apps monitoring these devices and turning them into new virtual devices. like the PowerByTheHour app.
@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.
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).
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.
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:
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?
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.