Sensors slow to update or not updating at all

[newlund]

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

[olalid]

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.

[olalid]

Btw, what sensors are you thinking of when you say "but there are others behaving the same way"?

[newlund]

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.

[olalid]

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 :)

[newlund]

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.

[asyvan]

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.

[olalid]

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.

[olalid]

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

[newlund]

@olalid I have enabled debug logging. Will let you know when it happens again

[olalid]

@asyvan the latest release should solve your problem, please have a look and see if works for you.

[asyvan]

@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.

[newlund]

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

[olalid]

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

[newlund]

reason_for_no_current was "limited_by_circuit_dynamic_limit"

Will send the log file to your email

[newlund]

This night all sensors updated the way they should. 👍

[olalid]

That is good. I will anyway mention this to Easee to let them know that there are improvements needed.

[TheMoen]

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.

[olalid]

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...

[olalid]

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.

[rawrgit]

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.

[olalid]

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?

[rawrgit]

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).

[olalid]

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...

[rawrgit]

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.

[rawrgit]

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?

[olalid]

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.

[newlund]

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.

[aifiks]

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? "

[olalid]

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.

[aifiks]

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.

[olalid]

Exactly which sensor(s) do you actually mean?
I thought you meant the equalizer energy sensors, but when you say to poll them before the hour mark, then I get puzzled because that would in many cases not be possible since some meters only output those values at the hour mark, so polling it before the hour mark would not make any difference whatsoever...?

[aifiks]

It's the Equalizer Import energy sensor I'm referring to. The response I received from Easee support led me to believe that it should be possible to poll this sensor at any given time to retrieve an updated value. However, your answer implies that polling is only meaningful after the hour mark. If this is the case, I understand why you're puzzled, and I realize that my preferences might not be fulfilled.

[olalid]

It has been my understanding that it is not the servers that are delaying the data from being sent out, but rather the equalizers that are randomly delaying the data before sending it to the servers.
(The electrical meters usually output the data very synchronized to the hour mark, some meters outputs the data more frequently also, but at least my meter does so only on the hour mark. Other values like power/voltage/current is more frequent of course.).
So if we poll before the data has actually reached the server we gain nothing, we would just get the value from the previous hour (again).
If that assumption of mine is incorrect then there is at least a possibility to improve it.

I guess, if it is the server that has the delay, then we can check at random time in the interval between 3 and 4 minutes past the hour mark if we did receive an update, and if not we try to poll the data from the servers.
Then we give the equalizer/server at least 3 minutes to push out the data, and we have plenty of time to poll and get a response before that 4.5 minute deadline.
That at least sounds worth testing...

[aifiks]

It seems I just have to acknowledge that fulfilling my wish of getting the value into Home Assistant and placing it on the right hour probably is impossible.

However, to overcome the issue of not receiving any value for a whole hour, if no new value is received in the current hour I think it will be useful to poll the server a few times leading up to the next hour mark.

I can also add that the issue of "empty" hours has happened more frequently this passed week. I've had 5 empty hours the last month, the last 4 happened from the 14. to the 20. this month.

[olalid]

I have been experimenting a bit with monitoring the equalizers energy sensors and polling if data has not been received a few minutes after the hour mark.
I have been running it for 5 days and so far it seems to improve how data is received in to HA. It is too short time to be sure, but I have no missed data at all in this period. Usually there is the occasional dropout of one hour every 3-4 days.

There is however a problem in that the values are not pushed out from the server unless there is a change in the value. Which is not a problem for the import energy sensor since it usually updates every hour, but the export energy sensor keeps the same value for large parts of the day due to solar energy not producing (and in fact this time of the year where I live also nothing is really produced during daytime either since the panels are covered with snow).
There is the occasional update being pushed out, but it is not at regular intervals, so it does not really help.

So this means the values are more or less being polled every hour, not only when actually needed...
Which makes it kind of useless to monitor if the data has been received, and I guess the reasonable implementation would be to just poll the values at a random time between lets say 1 and 3 minutes after the hour mark.

I will probably create a pull request in a few days so others can test too.

[olalid]

Hard to say if it is really an improvement, but I made a PR which polls some time between 2 and 3 minutes after each hour mark.
We will probably include it in a future release, but if someone want to test it before that and give some feedback on if it improves things or not it would be good.
See #383

[olalid]

The latest release now does a poll of the equalizer energy sensors shortly at a random offset after the hour mark.
It would be interesting to hear some feedback on if this improves things in any way for others.

In my installation I have not really seen any conclusive evidence, I can still see the occasional hour where there is a dropout of data. In those cases the poll just returns the old data from the previous hour.