Replies: 2 comments 1 reply
-
|
`2024-01-25 23:17:44.966 ERROR (MainThread) [custom_components.tesla_custom] Unexpected error fetching tesla_custom data: [Errno -3] Try again During handling of the above exception, another exception occurred: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): Hmmm, looks like it started prior to midnight, so that rules out the Scheduler. I'm wondering if that immediately prior error from the Tesla integration actually triggered the rate block initially, and then BT didn't handle the error very well and keeps retrying every 30-40 seconds. The rest of the log is full of the BT errors. |
Beta Was this translation helpful? Give feedback.
-
|
We have an extra piece of code for Homematic IP devices. So the Nest device could also be added. But we would need to check how. |
Beta Was this translation helpful? Give feedback.
-
|
Would be good to understand the handling around a HTTP 429 response (https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429) and either implement a Fibonacci backoff re-retry, or just give up after x many attempts. I'm pretty sure the initial rate limit was not caused by BT but some other service that also uses Google APIs eg Alexapy, Tesla, Plex, but then BT definitely maintained the rate limit via constant retries. |
Beta Was this translation helpful? Give feedback.
-
I currently use a Nest Gen3 thermostat controlling a boiler that feeds central heating radiators with a mix of standard TRV's and some smart TRVs.
Google / Nest does not sell their external temperature sensor in the UK, so you are stuck with measuring the temperature in a single location via the Nest thermostat (in my case, the entrance hallway). In theory, you could buy multiple Nest thermostats but at GBP£219 each that's a lot more expensive than a Sonoff SNZB-02 temperature sensor at $8.49.
I was hoping to use BT to control the Nest Thermostat based on temperature sensors in another room (the main living room) and have local loops for the rads with smart TRVs (mostly upstairs) linked to occupancy sensors to adjust the target temperature based on occupancy of the room. For example, if my wife isn't in her craft room, drop the local smart TRV target temp down by 2C.
So I setup a BT virtual thermostat based on the Nest thermostat being the "real thermostat" entity, and the sonoff device being the temperature sensor. This seemed to work well during testing.
The next step was the replace the Nest-native Schedule with a schedule in HA using Neilsfaber's scheduler. Seemed to work OK initially but this morning I woke up to a cold house.
The schedule was set so that at midnight (00:00) it dropped the Nest target temp to 14C. Note that the house temp never drops that low, probably doesn't go below 17-18C, 14C is just a convenient set point to say "don't heat up overnight unless it's a really, really cold night".
So, wake up the morning, central heating isn't on, house is a bit chilly at 17.2C. Manually use BT to crank up the target temperature and get error message in the UI:
Failed to call service climate/set_temperature. Error setting climate.hallway temperature to {'entity_id': ['climate.hallway'], 'temperature': 21.5): Error from API: 429: RESOURCE_EXHAUSTED: Rate limited for the ExecuteDeviceCommand API for the user.: Too Many RequestsLooking at the Google Nest API that's called by the HA Nest integration I can see that, yes, starting from midnight it was hammering the Google API with about 4 requests second, which caused the API to impose rate throttling.
In the end, I disabled the BT virtual thermostat, the schedule etc and re-started HA and the requests stopped, as you can see in the graph above.
As it stands right now, I don't really know where the issue resides - the scheduler (doubtful), BT (possibly) or the HA-Nest integration itself (probably) but something was stuck in a re-try loop (I think). I'm fairly new to HA so still working out where everything is/isn't logged to try and dig a bit deeper.
Anyway, my questions are:
Beta Was this translation helpful? Give feedback.
All reactions