easee_hass
easee_hass copied to clipboard
FR: Schedules on Chargers (No need to poll)
Noticed some GET requests to the basic_charge_plan and weekly_charge_plan, and heard from @olalid that you poll for schedule info. Which I guess probably makes sense since the chargingSchedule observation via SignalR was either not emitted, or unreliable.
You don't need to do that anymore, observation 62 contains a json string containing the schedule that's stored on the charger (whether it be a weekly or basic charge plan).
/// Charging schedule [json] [String] static const int ChargingSchedule = 62;
Closing this since this seems to have changed and it is again necessary to poll for schedule info (which we do every 10 minutes).
@olalid
They are working on re-introducing Observation 62 (it was accidentally removed when they moved to a new way of storing schedules on the chargers). Should be possible with a cloud side change, that might be released in the coming 2 weeks.
observation 62 is back.
The parsing of the data from observation 62 is rather complex to shoehorn in to the integration, so opting for a solution which still uses polling, but only polls when observation 62 is received.
Hmm. Seems like observation 62 is not sent out anymore. Has it been disabled again?
It should be, let me check now. Which API endpoint are u using to set the schedules?
yeah, thats frustrating, ill try and find out more info tomorrow - it didnt work for me either.
We poll /api/chargers/EHxxx/basic_charge_plan and /api/chargers/EHxxx/weekly_charge_plan, but we were planning to only poll when observation 62 was received. Which obviously will not work if 62 is not sent out. I have mainly tested by changing the schedule in the app, so not really setting them from HA. It did work some weeks ago when I tested last time.
Yup, i found out today, the Cloud guys broke it again when migrating to a new system. I'll let u know once its fixed, sorry for the inconvenience again, and I really appreciate u looking to implement your suggested change here.
Finally I got around to removing the polling completely. (Well it falls back to polling if the SignalR stream does not connect, but otherwise not).
Excellent, thank you.