Open brujoand opened 1 year ago
Ah, found this in the logs now:
File "/config/custom_components/easee/controller.py", line 421, in refresh_sites_state File "/config/deps/lib/python3.10/site-packages/pyeasee/charger.py", line 230, in get_state state = await (await self.easee.get(f"/api/chargers/{self.id}/state")).json() File "/config/deps/lib/python3.10/site-packages/pyeasee/easee.py", line 129, in get File "/config/deps/lib/python3.10/site-packages/pyeasee/easee.py", line 142, in check_status File "/config/deps/lib/python3.10/site-packages/pyeasee/easee.py", line 61, in raise_for_status pyeasee.exceptions.TooManyRequestsException: {'message': 'Too Many Requests'} 2022-10-18 09:38:10.729 ERROR (MainThread) [custom_components.easee.controller] Got server error while fetching schedule 2022-10-18 09:38:10.775 ERROR (MainThread) [custom_components.easee.controller] Got server error while fetching weekly schedule
Any way to increase the polling interval?
In the next release we will change the polling of the schedules such that the schedules are only polled when there is an actual change. (Which we can know because of data that is pushed over signalr). But it is a general problem that the servers sometimes does not respond correctly, and if this change will help you with your problem I do not know. If you want to try it out you can download the current master from github, where some pending PR where recently merged. We will release a new version soon though, just need a bit of time to test it first. After that release is done, lets revisit this and see if it helped.
Worth knowing is that if you are seeing that /api/chargers/{self.id}/state poll failing it means that the intial state poll of the charger state failed. This polling normally only happens once after restart of HA, since all updated status information is transferred using signalr after that, but if the intial poll fails it will retry periodically until it succeds. Until then some things may be behaving strange since some of that data is missing and will cause strange and seemingly unrelated errors.
In any case, I would recommend using the service for set_circuit_dynamic_limit instead of setting a schedule. When you set it to 5 or less the charger will pause and wait until set_circuit_dynamic_limit is called again and raised to 6 or more. So you can easily control when the car will charge using that. You can basically call it as often you like, it will internally determine if the new limit set is an actual change before calling the API.
Thanks, I tried using master but the same problem persists unfortunately. Could be that I've just been hammering the API so I'll try to disable the integration for a while and see if that helps.
Well, maybe. It could be worth-while to turn on debug printouts, potentially you could get more information from that. Like this:
logger:
default: info
logs:
pyeasee.easee: debug
custom_components.easee: debug
So there's a few thing I'm noticing:
2022-10-19 08:47:20.701 DEBUG (MainThread) [pyeasee.easee] Not found (404: {'type': 'https://tools.ietf.org/html/rfc7231#section-6.5.4', 'title': 'Not Found', 'status': 404, 'traceId': '00-16f69d2038a1f9bced52b5a84be5c11c-0994b07bd44f7485-00'} https://api.easee.cloud/api/chargers/ID/weekly_charge_plan)
2022-10-19 08:47:20.701 DEBUG (MainThread) [pyeasee.easee] Got other exception from status: NotFoundException
2022-10-19 08:47:20.701 DEBUG (MainThread) [custom_components.easee.controller] Schedule: <pyeasee.charger.ChargerSchedule object at 0x7f631b7a4c10> None
Which is a bit odd I guess? Or does that just mean I don't have a weekly schedule set?
Also this, is interesting to me because the DateTime format when calling the service is explicitly not localized, but when we are calling their API we are at UTC, is that intentional? Or rather, is that what the API expects?
2022-10-19 08:47:24.527 DEBUG (MainThread) [custom_components.easee.services] execute_service: set_basic_charge_plan {'charger_id': 'ID', 'start_datetime': datetime.datetime(2022, 10, 19, 6, 0), 'stop_datetime': datetime.datetime(2022, 10, 19, 12, 0), 'repeat': False}
2022-10-19 08:47:24.527 DEBUG (MainThread) [pyeasee.easee] POST: /api/chargers/EH9QSZ9A/basic_charge_plan ({'json': {'id': 'EH9QSZ9A', 'chargeStartTime': '2022-10-19 04:00:00+00:00', 'chargeStopTime': '2022-10-19 10:00:00+00:00', 'repeat': False, 'isEnabled': True}})
In any case, I would recommend using the service for set_circuit_dynamic_limit instead of setting a schedule. When you set it to 5 or less the charger will pause and wait until set_circuit_dynamic_limit is called again and raised to 6 or more. So you can easily control when the car will charge using that.
Yeah, I've seen this mentioned a few times and it's probably the approach I'll end up with. I just had good experience using the schedule through Tibber, so I wanted to try to re-implement that with this integration.
Yes, the API does return 404 when you do not have a schedule set, take it leave it that is how it works :) All dates/times are UTC in and out form the API, it does not understand time zones so we have to convert back and forth between what we present in the UI and what we accept as input. So neither of those things are actual errors. But sometimes other APIs return 404 too, which makes little sense.
The problem
I've installed the latest version of easee_hass through HACS, running on the latest version of HA.
Everything seems to be working great except the basic schedule setup. First of all I can't get the binary_sensor for the basic schedule to work, it's always disabled even when there is a basic schedule set on the robot.
The reason I even want that sensor is to determine if my call to the 'set_basic_charge_plan' works. I currently have an automation that fetches price data from nordpool, converts the datetime format and updates the basic schedule with the next period where I'd like to block charging. The problem is that this works 1 out of 5 times with no error message, which I assume is problems with the easee cloud service, or just a delay between the cloud and the unit. But if I could only get the binary sensor to tell me if the schedule has been applied or not, it would at least compensate. Any tips on how to debug or get that sensor up and running?
Version of Easee integration having the issue?
0.9.45
Version of Home Assistant Core having the issue?
2022.10.4
Anything in the logs that might be useful for us?
Additional information
No response