Hello!
I am running beestat locally following the instructions at Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
This is run in a proxmox lxc ubuntu 22.04 container.
The issue is thermostat and sensor detail (the actual temp over time graphs) appear to update every 15-25 minutes. Where can this interval be adjusted - say every 5 minutes (or less)?
Thank you
Maybe, but probably not.
Two things affect this:
You can change the ‘sync’ cache setting in api/runtime.php from 300 seconds to something lower if you like. This setting tells beestat not to sync your runtime data more than once every 300 seconds (5 minutes).
You will then want to decrease the frontend polling interval to match. That’s in js/beestat/poll.js. Change it from 60000 * 5 to something lower. This value is in milliseconds, so changing the 5 to a 1 would poll once per minute.
Ultimately you’re at the mercy of when ecobee pushes updated data, though. That’s the biggest factor here.
Note that the “current” thermostat and sensor values (top two cards) update much quicker, but this data is from a different source and is more limited and not suitable to use to update the runtime chart.
Thank you for the reply.
I suppose caching the “current” tstat/sensor data locally is beyond the scope of this project. It would require some more direct access to the device itself rather than going through the ecobee api. Also seems like this would be reinventing the wheel in a way.
I vaguely recall reading of homeassistant with direct polling of the device using homekit integration. I haven’t gone down that rabbit hole yet as there are some caveats (like loss of custom comfort settings).
Can you elaborate on your last sentence above regarding data for the top 2 cards. Not suitable for the runtime chart because…?
One of the goals here is to get data as real time as possible. On the flip side, temperatures typically don’t change quickly. A five minute delay on either say can’t amount to more than a few tenths of a degree.
Correct. This is actually not even possible outside of HomeKit. I believe one of the requirements of obtaining a HomeKit integration is direct access, so that’s the only platform with that capability.
As for the two data sources, refer to this image:
Ecobee API Reference:
GET /thermostat
GET /runtimeReport
The /thermostat call has more recent data, but importantly, it only returns current data. I can’t go back in time with this call. Last time I looked I think it was missing things like comfort profile info or something else as well.
The /runtimeReport call runs ~15 minutes behind, but importantly, it can provide historical data.
So theoretically it would be possible to use the /thermostat endpoint while beestat is open to update parts of the Thermostat Detail chart quickly. Then augment that with the /runtimeReport endpoint to fill in the blanks. Then when you’re not using beestat, fall back to only using /runtimeReport.
With my limited time it’s easier to keep things simple and just accept the short delay on the Detail charts. Would love to explore this more one day, though.
Perhaps you can help resolve another issue.
With the self hosted instance I’m not seeing any occupancy detail under sensor detail, just a an empty box. This is not the case when accessing app.beestat.io.
I downloaded data from both using the download data option in the 3 dot menu, upper top right corner. For the self instance, it shows all 0’s under the 2 sensor occupancy columns. Not so for the app.beestat.io. I tried updating the code with git pull but same result.
Any suggestions? Thank you
I am in discord too, if that will make this easier to debug & troubleshoot. Just need an invite.
Big thanks go out to @ziebelje for working with me throughout the day today to troubleshoot and figure why this occupancy data was missing. I’ll let Jon explain more if he wants, but in a nutshell, it had to do with a datatype mismatch of sorts in the beestat.sql file.
For the technically-minded, a the occupancy on the runtime_sensor table was created as a tinyint(1), but the database structure export had it as tinyint, which is shorthand for tinyint(3).
MySQL doesn’t have a “boolean” data type, so these values get returned as normal integers. I prefer to have boolean values in the code, so beestat looks at the length of the field to determine if that’s the intent and goes from there.
In this case, a field length of 3 was wrong. We updated the database column to the correct type and everything started working again.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
