1 Min sensor update timing

[tmorse305]

I just setup your integration so I'm still trying to understand how it all works. I noticed that the updates coming in from the Emporia plug are slower than I would have expected. For example it takes 2 sometimes 3 minutes for the energy value to update after there has been a change in the load on the plug. Even the status of the plug (on/off) is delayed by minutes. Here is an example, I manually shutoff the Emporia plug using the button. 2 minutes later the power drops to 0. 2 more minutes later the plug is updated to show that it is off.

Is this the expected behavior or do I have something mis-configured? How often does your integration pole the Emporia API?

Thank you for any advice.

[magico13]

Power is polled once a minute and the data returned is the average power over the last minute, not the instantaneous power at that point (which matches what the Emporia app displays at the one-minute level). Plug state is polled less frequently, I believe it's every five minutes but I might have tweaked that in the pre-release version which contains a bunch of updates. If you trigger it from Home Assistant in any way then it polls the state right away, for better or for worse because the Emporia API hasn't always updated in time, so it's generally just when you change it outside of Home Assistant that there's a delay.

[tmorse305]

Thank you for your reply. I see it taking 2 even 3 minutes for the power to update. You have a 1 minute pole time, If you are poling the 1 min value from Emporia, they also have a 1 minute update time too. Since those are asynchronous timers I could imagine it taking 2 minutes. Maybe there's a way that it might get close to 3. Does that logic make sense?

If the switch is toggled in HA you said that the status is poled right away, does it also pole the power too?

Thanks.

[magico13]

Yeah I think something like that definitely happens. Home Assistant runs a timer that triggers every 60 seconds, then the integration asks for the data for the current time, but the API could return slightly older data. Those compound to a noticeable delay. Unfortunately without local access we're not allowed to poll more frequently than once a minute. There's a hardware hack to replace the firmware with ESP Home but you lose the cloud connection, for better or for worse.

[tmorse305]

OK, thanks. I think I can work with the delay now that I know what to expect. I'm using it to create a notification when the washer is finished so an extra minute or even 2 isn't a big deal. I appreciate your help! Thanks again for creating the integration.

[magico13]

That's an automation I have as well. It starts when the power goes above a certain level, then notifies when it drops back down. Sometimes the API reports bad data (0 or unavailable) so I recommend waiting for the level to drop and stay low for a few minutes.

[tmorse305]

Right now my automation is a simple, 'when it drops below x notify me'. I'll bet your explanation about possible bad data explains why I received a random notification that it was done when we weren't using it. I guess I need to make the automation a little more sophisticated. Thanks for the heads up.

[JTertin]

Indeed the API (presumably) does return zero, and more frequently than I'd like to see. Nothing catastrophic, but wondering if this is typical for other users across a 1-week period?

[twister36]

@JTertin - I also see my 1MIN entities dropping to zero every few seconds, which is effecting any automation on these devices.

[amscanne]

I think had the same issue with occasional bad data with the 1-minute sensor, but #152 seems to have addressed it for me. I’m not sure how Emporia is generating/saving minute data points, but this just ensures the API request time is clamped to the end of the last full minute.

[DabblerIOT]

Seeing same behavior in ha logs... so the odd behavior is due to the time/date tags returned by emporia with the data?

Thanks. Don't like this.

[DabblerIOT]

Sorry to narc this... but I'm pretty sure the ha core scheduling code isn't doing what we "think" it is. Not sure if a bug, or expecting to get the polling code run every minute is too much of an expectation for ha.

Will try to dog it down. Think have the bad updates sorted out in the pmvue core project. Just waiting to get more runtime on fixes so I can put in pull request. Need to do some testing before I ask question upstream so I don't look too stupid. May float a redit question instead as its less formal than git in my opinion.

I really don't think the odd timing of pull requests and delays are 100% due to us or emporia. I'm pretty sure it's ha. Either that or a really weird bug in this project or pyemvue...

A typical request when api is responding right (which is 99.9% of the time) takes less than 1/4 second. So updates being this janky doesn't make much sense to me... when emporia app that uses same api gets data very very fast compared to 1 minute.

Cheers.

[DabblerIOT]

Did some testing and added more logging. we are polling data every one minute correctly, and new data (with small changes) is showing up in ha gui. For some reason history entry isn't written every time.

Posted question on ha log.

Also values should not be rounded to the watt. A fraction of a watt is still a fraction of a watt.

Will continue to dog down.

[DabblerIOT]

Think all working ok now. api data not always changing as fast as I assumed. Maybe they can throttle things to keep their servers happy. Think we are good now.