easee_hass
easee_hass copied to clipboard
nordicopen
Sensors slow to update or not updating at all
Question
Hi!
Sometimes I have to reload the integration to get the latest sensor updates. For example sensor.laddbox_cost_day but there are others behaving the same way.
Is there a setting for how often the integration should poll the easee API?
BR/Nicklas
What version of the integration are you using?
0.9.46
Anything in the logs that might be useful for us?
No response
Additional information
No response
Most of the sensors are not polled at all, the data is pushed from the servers over signalr stream. The exception is the cost sensors and the schedule sensors. The cost sensors are quite new in the integration, and we are struggling a bit to get them to work in a good way. Generally we try to avoid polling as much as possible since the cloud API have a lot of rate limitations etc, so we try to poll only when we expect the value to have changed. For the cost sensors we trigger a poll when the lifetime sensor value changes, and after midnight. But we are getting strange values from the API under certain circumstances. I have just not had time to dig deep enough in this yet to figure out how to solve it.
The short answer is that we are aware of that the cost sensors behave strange and we will fix it as soon as we can figure out how.
Btw, what sensors are you thinking of when you say "but there are others behaving the same way"?
Thank you! :)
Mostly cost sensors but I had the same problem with sensor.laddbox_dynamic_circuit_limit a while ago. Also laddbox status sensor. It locked on an old status until I reloaded the integration. Perhaps it was due to temporary issues with the Easee API.
Both of those sensors use data pushed over signalr, so at least it is not a polling problem. My gut feeling is that what you saw there was a server side problem. Sometimes when they post problems on the status page, you can see that data is missing or delayed from the servers. So it is worth checking there when you see issues (https://status.easee.com/) In any case, if you notice it again, let us know.
Cost sensors is as I said above different though, so that is a real bug, if it is on the server side or in our code I can not tell right now :)
Had problems this morning with sensors not updating. Laddbox power, laddbox current and dynamic circuit limit as seen in the screenshot. They are stuck on previous values even if the charging has stopped. According to status.easee.com there were no issues with the API this morning.
When I reloaded the integration they all updated to correct values.
I am trying to use state_eqAvailableCurrentP1 (etc) from sensor.garage_equalizer_limit. But it hasn't updated in several hours. However, using Easee app I can see the data in the app changes correctly. So somehow this integration does not correctly pick up these changes as they are pushed. Or it fails to pull them if that is the case.
Yes, I am seeing something strange too which is probably what you are seeing. The data is received, but sometimes the sensors does not update correctly. I am investigating.
Ok, I found the issue with state_eqAvailableCurrentP1/2/3. They are incorrectly defined in the library, so they never update, they just get the initial value. Easily fixed.
This is however a problem with that specific data so it does not really apply to the original issue. @newlund if you enable debug logs, perhaps you can see more what is going on when this happens again. If you place this in your configuration.yaml, you should get more detailed logs:
logger:
default: info
logs:
pyeasee.easee: debug
custom_components.easee: debug
@olalid I have enabled debug logging. Will let you know when it happens again
@asyvan the latest release should solve your problem, please have a look and see if works for you.
@asyvan the latest release should solve your problem, please have a look and see if works for you.
Thank you. Will try tomorrow and let you know.
This night the sensor.laddbox_status got stuck in "ready_to_charge" during the whole charging session. The other sensors updated fine. I have a log but I'm not sure if it is ok to post here? Perhaps better to send in email?
It charged between 1:00-6:00
What was your reason_for_no_current sensor showing during the ready_to_charge period?
You can send the log file to olal (a) plea.se
reason_for_no_current was "limited_by_circuit_dynamic_limit"
Will send the log file to your email
That is good. I will anyway mention this to Easee to let them know that there are improvements needed.
I am having this issue too, equalizer updated the secound i reactivated it. Both power and energy was stale.
I am considering automating the reactivation, since i am using the power entity in my automations.
I must say that it generally works fine without any issues.
It happens now and then for me too that the sensors stop updating, not often though. The connection to the servers has in these cases not disconnected, it is just that the servers stops sending updates. As you say restarting the integration helps because a new connection to the servers seem to solve the problem. Maybe we should try to add some watchdog type thing where the server connection is restarted if there has been no messages received for a certain time period...
Note though that I am now talking about cases where all sensors stop updating, not only a specific one or a missed state change etc.
Im not sure if sensor.xx_cost_per_kwh had a solution, but i just wanted to let you know that I am pushing new cost_per_kwh value to Easee every hour and see the change in the Easee-app but the value will not update in HA unless the sensor/integration is reloaded in HA. If i reload the integration after this hourly push it will not behave as expected on the car status. I have noticed that my car has reported "completed" i HA late in the evening, but when the car wants to pre-heat in the morning it will not as the status has changed from "completed" to "awaiting_start" some time in the night. So the reloads throughout the night seems to have changed the cars status and then it will not pre-heat.
I have turned off the hourly "reload_config_entry" and the pre-heat works fine in the morning. Though, the sensor is not being updated hourly in HA.
Yes, well, that is the behaviour I would expect since cost_per_kwh is not part of the data that the servers push out, so it will not update unless you reload the integration. I guess we could add that when the service is called we also write the same value to our local copy of the cost data... (Note that the discussion above is not about this sensor, but rather the ones called sensor.xxx_cost_day/month/year, which are polled when we think it makes senses to do so. So the discussion above does not really apply here).
It sounds very puzzling that reloading the integration would have that effect on the charger, I am sure we do not do anything apart from reading status when we start up, so I do not understand why that would change the behaviour of the charger. What was the state of your "reason_for_no_current" sensor during the "awaiting_start" mode?
It sounds very puzzling that reloading the integration would have that effect on the charger, I am sure we do not do anything apart from reading status when we start up, so I do not understand why that would change the behaviour of the charger. What was the state of your "reason_for_no_current" sensor during the "awaiting_start" mode?
That sensor you are asking about was not enabled so i have no history of it when "something" happened to make the car not preheat. I enabled it after your reply here. Although the "awaiting_start" is the current status as my car is now awaiting the time to start accordingly to my smart-charging NR-flow. The status for "reason_for_no_current" right now with "awaiting_start" is "Max dynamic charger limit too low". The charger has been given the "action_command":"pause" so it will not start until the timed "action_command":"resume" is given by the customized flow receiving "lowest price"-data from Powersaver.no node called "Lowest Price". Adding a screenshot of the apexcard showing this as the "green window".
I have no idea what/if the reloading caused the car not to preheat, but the reloading was the only deviation/new thing in a very well used and functional setup that I have been using for months. So i assumed it was the reloading-every-hour that did something to trip off the preheating. I might ofc be wrong for all i know.
So for now its not reloading and I don't get the "cost_per_kwh" into my HA. That is less important than a preheated car in the early morning. If you would like for more data I could enable it again, but then you'd have to tell me what you need in advance(like debug if it exists and such).
It is not powersaver that pauses the charger at the end of that green period then? Just speculating here, I am not using powersaver myself so not sure how it integrates with HA...
It is not powersaver that pauses the charger at the end of that green period then? Just speculating here, I am not using powersaver myself so not sure how it integrates with HA...
In my flow powersaver itself does not pause if in/outside the "low price" window. Powersaver just gives info for other nodes to start/stop charging. I suspect the Easee-wallbox to be needing a hard reboot so I will be turning off the fuse to fully restart it later today. Will enable the reload of the integration and see if a wallbox-restart does the trick.
My suspicions were right and this worked without issues after the Easee-charger was restarted properly by flipping the fuse for 5 minutes.
To circle back to my initial reason for commenting here; cost_per_kwh It was mentioned(in a facebook-post) that Easee does not calculate price per hour but per session. If that is correct then this sensor is not very useable anyways since most sessions run more than one hour at a time? Do you happen to know anything about this assertion?
OK, that is good news.
I have unfortunately no knowledge about how they calculate the cost for a charging session. It could be either way.
According to Eease support the charging cost used is the price per kwh when you plugged the cable in. Not very useful... :) I asked quite a while ago if this could be changed to the actual charging cost when charging and it was in planning. But now I guess Eease have other things to prioritize.
Most of the sensors are not polled at all, the data is pushed from the servers over signalr stream.
@olalid I recently submitted a request to Easee, seeking information on how to obtain hourly consumption data from their servers in a manner that allows me to receive the values in Home Assistant before the clock transitions to a new hour. Currently, I typically receive the values approximately 11-12 seconds into the new hour. However, on occasion, it takes over 4.5 minutes to retrieve these values, leading to a shift in the hourly consumption statistics in Home Assistant by 1 hour. In some extreme cases, the information is delayed for more than one hour, resulting in an hour with seemingly no energy usage; instead, the usage is then included in the statistics for the subsequent hour.
The answer I got was this: "We provide the data based on these timestamps to not overload our servers, if you want to get more information more frequent you can use our API to enebale more frequent data updates."
So, is it possible to make the integration to request information more often? If so, could this be addressed, please? "
Well, I am pretty sure that when they answered you they did not mean "you can ask the guys developing the HA integration to make synchronised polls from more than 3000 clients at the exact same time to our servers". Which would be the result if we try to poll for data directly after the hour mark from all Easee HA integrations in use currently. So it would be sort of a DoS attack, although very short.
If they mean something else than polling, I need more info to understand what they mean. It would be great to solve this, but that answer does not help me understand how.
Thank you for the quick reply.
Perhaps the integration could be configured to randomly select a time within, let's say, the 59th minute of each hour. Subsequently, it could provide a qualified estimation for usage during the remaining seconds of the hour. This way, the hourly consumption could be updated in time to align with the correct hour in the energy dashboard in Home Assistant.