I have just started using Beestat API and have been able to get thermostat and sensor data (detail and summary using thermostat.read_id, sensor.read_id, runtime_thermostat.read, runtime_sensor.read, runtime_thermostat_summary.read_id).
I was hoping that I could get some clarification on the following:
thermostat/sensor read_id: It appears that the high resolution data timestamp is in UTC. My thermostat/sensors are in America/Chicago, so -5 or -6 hours from UTC, so if I get data without adjusting for the time offset, it is actually off by the time difference. I was able to get the correct date range by adjusting for the time offset but I wanted to confirm if my observation was correct (or if there is a simpler way to get the data for the correct timezone).
runtime_thermostat_summary.read_id: Related to the above, is the summary data for UTC date or thermostat timezone date? Also, when filtering for a date range (eg: https://api.beestat.io/?api_key={MY_API_KEY}&resource=runtime_thermostat_summary&method=read_id&arguments={"attributes":{"thermostat_id":{MY_THERMOSTAT_ID},"date":{"value":["2026-05-01 00:00:00z","2026-05-22 00:00:00"],"operator":"between"}}} I get a date parse error but if using “>” it works correctly. Does this API not work for a date range or am I doing doing something wrong (I also tried the date without the time specified and that did not work either).
data refresh: How often is the data refreshed for the API? I tried getting the data for yesterday (2026-05-23) and it returned an empty array (2026-05-22 worked as expected). I also tried the thermostat.sync method and then re-did the API call but still got nothing. However, I can see the data for 2026-05-23 on the web app. Is that expected?
When reading runtime data (runtime_thermostat->read(), runtime_sensor->read()), you can specify the timestamp values in a wide range of formats.If you do not include a time zone, beestat assumes UTC. I didn’t actually test this, but I believe the parser will allow something like “2026-05-25 00:00:00 America/Chicago” which will automatically handle DST changes in UTC offsets. Generally speaking, all thermostat data is stored and returned in UTC.
The exception to that is runtime_thermostat_summary. Because that data is stored in aggregate by day, there’s no way to include time information and thus it is stored with your thermostat’s local date. There was also a parsing bug in this API call which should now be resolved and properly allow for date ranges. Let me know if you see any issues with this.
Look at the sync API calls in the documentation. If you are not actively using the beestat app, syncing slows down over time. You must manually call those sync endpoints to keep things up to date. Otherwise it will get stale. There are three - if you care about runtime data make sure to call runtime->sync() and wait for a response or use batching to fire off multiple calls at the same time.
Let me know if you have any other questions and thank you for including lots of details and examples!
Since I am using the API from Node-RED, I am using the Luxon library to do the date offset and that has worked. One thing I noticed - there are some days where the number of records in < 288. It did seem infrequent and I am assuming this doesn’t materially impact the data collection (eg: if there was a gap between say 11:10:00 and 11:25:00, is the missing data dropped or aggregated in the next bucket?)
That’s very helpful. Otherwise I would going to add up the detail and summarize!
My thermostat and sensor data is relatively stable and does not change, so would there still be a need to call thermostat.sync and sensor.sync?
I have used runtime.sync to refresh the data, but was not clear on how much delay there is. My current thinking is that I call runtime.sync at 1:00 local time and then the runtime_thermostat.read and runtime_sensor.read at 3:00 AM local time (I don’t need real-time data, just daily information). Is that enough of a time gap.
Also, does this sync both thermostat and sensor data?
One question on this API - it appears that specifying a date range does not work (qualifiers like “=”, “>” work). Is there a way to get data for a specific date range for a one time load (or missing data)? EDIT: it does work!
UPDATE: I am in the process of importing past data (starting January 2026). Are there any rate limits on Beestat API calls? EDIT: I put in a 30 sec delay between calls (thermostat detail, thermostat summary, sensor detail) and broke the data request in 14 day increments and I was able to get all the data without any problems.
This is usually caused by ecobee dropping data randomly for one reason or another. It’s not too frequent, but you could confirm this by exporting your data from ecobee’s Home IQ web portal and comparing to see if it’s missing from there, too.
It’s dropped. In the case of summaries, there is a field that tells you how many data points were included in that day’s data so you can infer what you need from that. Beestat calls this “Gap Fill” but that estimated value is not exposed in the API.
Generally no. Those calls are cheap though, so any time you sync your runtime data, I would just batch it with a thermostat sync and a sensor sync to be safe.
When you fire off that API call, it should sit and spin and not return a result until the sync is complete. If you don’t care about real-time an hour is more than enough. If you keep your data relatively up-to-date it should only take a few seconds.
runtime.sync will sync both thermostat and sensor history.
You’ll know when you hit it. You can send up to 200 requests per minute. If you hit it, you’ll get an error and just have to wait for it to cool down.
You can send up to 200 requests per minute. If you hit it, you’ll get an error and just have to wait for it to cool down.