Energy Data 1D, 1MIN, 1MO all read 0 since this week's update #261
Comments
|
I agree last 2 revs have issues... I fell back to the rev I put the pull request in that resulted in 18.1 (core pyemvue project)... I put in bug report as well on that project today for 18.3, but didn't realize failure was broader than just balance readings. Install file editor mod and change requirements line.. Change the version back to 18.2 or 18.1 if those worked better for you.. For me 18.1 was "ok", 18.2 and 18.3 not so much. I fell back to the code I put in pull request to add retries until project tests their code better before releasing. (I know it works for me.) "requirements": ["git+https://github.com/DabblerIOT/PyEmVue"], You will have to restart after editing file to get new dependency to update. Cheers. |
|
Very odd that you're seeing it consistently not able to retrieve any info. Implies to me that it either didn't set up the devices correctly or that the usage response is not returning any data. There was a change to how devices were set up, previously it only looked at the first response from the usage request and now it builds it primarily from the device tree, so there's a chance there's a difference there. Does the Emporia app also show 0s or missing devices when on the home page set to "min" and the time set to "now"? If it's missing there, it will likely be missing from Home Assistant. Since you mentioned it only being since the update that's not likely the be the issue but it's always a good check. A good number of reports of missing data I've seen have been the connection between the clamp and main device being flaky, usually because it got pinched or slightly pulled out when putting the cover back on the panel. That would usually be the case for individual channels, not generally all the data. You could try deleting the integration, rebooting, then setting it up again. That would set up the devices fresh and the sensors should all reattach to the previous ones if the names haven't changed. That would avoid any mismatch of data from before the update and after. You mention having switches, how is your hardware set up? I assume a single Vue2 with 16 individual circuit monitors and a handful of smart plugs, all nested under the one device? You can try @DabblerIOT's suggestion, I'd be curious if you see any difference with that. The primary difference there is the number of retries and how long it waits between retries. If you're always getting no data back it might not make a difference, if you only get data back after many retries then it could help but there's something more serious going on since it's not normal to never get data back on the first call. |
|
I have the same issue since the update (0.9.2). The HA does not get values, but 0. It seems the update broke something for me also. 2024-03-03 11:20:07.138 INFO (MainThread) [custom_components.emporia_vue] Found 2 Emporia devices with 2 total channels |
|
Emproia App shows full data and trending. Not a single instance of loss in its data. Tired deleting and re-integrating to HA but I am getting the same results. I'm monitoring 2 homes. V1 with 8 and a V2 with 16. V1 has been offline on Emporia's app since October. I'm unable to troublehoot in person and suspect an internet issue. V1 hasn't caused any issues thus far with HA since its outage. Just shows offline. All smart plugs are nested under the V2 at my home. All smart plugs can be triggered by HA with no delay or error. I'm going to roll it back soon and I'll let you know the results. Appreciate the insight. |
|
I think 18.1 and my test won't be happy with down devices.
So that may not be helpful.
…On Sun, Mar 3, 2024 at 2:34 PM DrMik-1 ***@***.***> wrote:
@magico13 <https://github.com/magico13>
Emproia App shows full data and trending. Not a single instance of loss in
its data.
Tired deleting and re-integrating to HA but I am getting the same results.
I'm monitoring 2 homes. V1 with 8 and a V2 with 16. V1 has been offline on
Emporia's app since October. I'm unable to troublehoot in person and
suspect an internet issue. V1 hasn't caused any issues thus far with HA
since its outage. Just shows offline. All smart plugs are nested under the
V2 at my home. All smart plugs can be triggered by HA with no delay or
error.
I'm going to roll it back soon and I'll let you know the results.
Appreciate the insight.
—
Reply to this email directly, view it on GitHub
<#261 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BGBTIU2OXTSHE3TXDPGWSQDYWN3LBAVCNFSM6AAAAABEDTXTMSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZVGI3TGNZSGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I rolled it back to 18.1 using HACS. All devices are now reporting data. Let me know if you want any additional info about my setup to help you troubleshoot this issue. Thanks! |
Clarification question, did you roll back the version of the Emporia integration via HACS, and to which version? v0.8.1/v0.8.3? The two separate Vues, one of which is offline, is definitely important information so thank you for sharing that. @csipu do you also have separate Vues or any offline devices? I may be able to replicate that setup, I have a Vue1 as a sub-device of my Vue2 and I can move that in the Emporia app and then unplug it to see what happens. Not sure what that will do to the longer term data but I suppose we'll find out. |
Interesting, your account appears to say you have two devices on it, id 165911 and id 281466. The former is reporting None and the latter is not returning in the data at all. Still seems like it might be related to the two devices, one offline idea. I'm working on testing that situation now but running into issue with my development environment. I'll hopefully have something later today for you both to try. |
|
I have an Emporia EV charger, it can be the 2nd device. |
|
Just turned the EV charge on, disable/enable the service and now I get data! |
|
I tried to validate my concept, but the HA lost the Emporia integration as a service. I have removed the integration from the HACS and readded the Emporia. Now during the integration config I have added the user+pwd and I got an error. Is there a way to purge the previous user config to the Emporia? |
Generally a reboot will either make the configured one visible so you can remove it, or will complete the removal process. I recommend waiting a little bit, I'm pretty sure I found what the cause of this was and am about to push a fix. |
|
@magico13 I was going to run my code with more retries as a test to see if no missing data with 10 retries... (lol)... But I can switch to a pre release to help verify if you want some more testing. |
|
I pushed something up to the master branch here that is working correctly on my dev environment and not working on my server, currently trying to figure out what is different between them. I believe the main source of the problem is that the offline device will always not report data and if we happen to find that first in the list then the retry code would stop looking and retry immediately. It would keep doing this every retry and never actually look at the data for the other device. I am attempting to fix that by fully looking through the list, taking whatever good data we do find, but still retry if we find that data is missing. Each retry if we have good data for a device then we take it so by the end of the retries we should end up still having data for the online device and none for the offline. There's room for improvement there since we shouldn't retry for devices that we know are offline but that will require additional work, as a quick fix this seems like it should work. If you go into HACS and choose "redownload" and then choose "master" for the version then that should pull the latest. Like I said though, it's working in my dev environment and doesn't seem to be behaving correctly in my actual server so I am not sure what's up with it. Edit: I figured out my problem, I had previously pointed directly at a branch on github of PyEmVue so it wasn't actually downloading the new version from PyPi despite the code being different. After forcing it to install the new version of PyEmVue it started working correctly. |
|
Same here. I had to roll back to 0.8.3 to get it working again. |
|
I have a Gen 1 power monitor that recently stopped reporting only the minute entity for each monitored circuit. Reboots did nothing, but after downgrading from 0.8.3 to 0.8.1 in the manifest and rebooting everything was fixed. One thing to note was that the disabled entities were reported as "disabled by the integration" in home assistant, not reporting 0 values. |
v0.8.1 using HACS and selecting the version. |
|
Can everyone who is seeing this please try installing the "master" version through HACS and report back? I believe that should fix it since it removes another remnant of the code that was throwing out the data if anything was missing, it should now fully use what data it retrieved instead of cutting out early. |
|
I have update the integration and still 0 for me. |
I downloaded the 'Master' v7cec1a8 and it seems to be working fine. It seemed to take a long time to initialize but all the numbers are there and updating. |
|
Leave it on master, v0.9.2 does not have this fix in it yet. I wanted to verify the issue was fixed before rolling that out to everyone. I will bump up to v0.9.3 with the fix likely later today. The startup is definitely going to be slower in these situations because the retries are going to run and the total of the delays it uses is at least 30 seconds. I will look into making that smarter so it can ignore devices that have been offline for a while but from just the one API call in isolation it can't detect the difference between an offline device that's not likely to come back online and the API temporarily omitting data for a device. After startup it shouldn't be too noticeable, but it will add an additional 30 second delay to data being updated. |
|
@magico13 Running test. All looks good right now. (Only 30 minutes run). :) Do you have a text file of the json return with one meter online / one meter offline? Curious what it looks like. Thanks again. |
|
@DabblerIOT sure, here's the setup I was testing with yesterday. 7466 is a Vue1 usually nested under the 86116 Vue2 but for this I set it to standalone and then unplugged it. I'll throw in a status response from around then too, I am already regularly calling that to make sure the outlets and chargers are in the correct state so I should be able to use that to determine which devices to exclude from the usage polling, just need to figure out the best way (or at least an acceptable way) to get that data to where it needs to be. UsageResponse_MissingCoDevice.json |
|
2 retries hit status request? then use new isconnected data to omit retry
/ failure = true for that device? this way won't double api hits until we
suspect a device is down
mainstream bms stuff normally does this on a minute basis.. but another
request on a local bus is cheap and wont annoy anyone.
also my data and logs don't look very different polling every minute as
opposed to every two minutes. Get same data back 5 out of 10 times.
Half as many chances to get bad responses?? lol i know sad.
thanks for sharing responses
…On Mon, Mar 4, 2024 at 2:16 PM Mike Marvin ***@***.***> wrote:
@DabblerIOT <https://github.com/DabblerIOT> sure, here's the setup I was
testing with yesterday. 7466 is a Vue1 usually nested under the 86116 Vue2
but for this I set it to standalone and then unplugged it.
I'll throw in a status response from around then too, I am already
regularly calling that to make sure the outlets and chargers are in the
correct state so I should be able to use that to determine which devices to
exclude from the usage polling, just need to figure out the best way (or at
least an acceptable way) to get that data to where it needs to be.
UsageResponse_MissingCoDevice.json
<https://github.com/magico13/ha-emporia-vue/files/14486153/UsageResponse_MissingCoDevice.json>
StatusResponse_MissingCoDevice.json
<https://github.com/magico13/ha-emporia-vue/files/14486154/StatusResponse_MissingCoDevice.json>
—
Reply to this email directly, view it on GitHub
<#261 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BGBTIU2NVVTLTLRMQCSCCKLYWTCBXAVCNFSM6AAAAABEDTXTMSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXGI4DMNJZGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Sorry that didn't make sense.. if you change to poll every 2 minutes (which is closer to guarantee you will have new data from api)... every 2 minutes You would be at.. 1440 request per day for minute data which would leave room for other requests to stay below the ask of 2000 or less a day from api maker. This type of interval is fine for most things... 1 min vs 2 min not a big deal... if you are sorting out what circuit something is on, use the actual emporia app, and it updates faster somehow.. Or this may be odd thought, if we REALLY want new data each minute, request second data, and multiply correctly to get power. Hmmm... I just don't see a reason to request, what is duplicate data half the time at the 1 min setting. Easy to mod local copy of ha code to play... :). Just thinking. Cheers. Thanks again for hard work sorting this out. Hope most realize that reason for issues with 1 min data isn't this projects code, but unreliable api that we are reading, which isn't the norm in this type of thing. |
|
Had issue with browser update killing my test code... updated it to plugs I added and on first request got bad data in.. Will rework my test code to keep stats on how bad api is with errors on requests like this... dead serious first request with 6 devices came back like this. |
|
Ran test doing 6 device get usages with counter... have data in javascript console request:570 null:77 About 7 hours of run Clicked clear instead of copy half asleep this morning. Will wait to get more responses with nulls and look and see what devices are null, if it is normally first, or any. From my earlier testing it is worse in the early am. Data from 18.4 is clean (well at least both vue2 data is). Will look closer later. So the retry and assembling valid data logic looks to be working very well. |
|
Seen multiple with all plugs null and vue devices ok. Counting plug nulls, and view nulls separately now, have not seen a vue error looking back through nulls for last couple hours. errorallplugsnullvueok.json If it turns out that the plugs are more problematic... I may ditch them and get another make of output. Really just using plugs now to turn off vampire loads (ifit treadmill doesn't turn off screen backlight), and stuff like that. |
|
Of course it seems that the Emporia web service is offline at the moment. No data being returned and unable to log into the web site. It's not just me, right? |
|
From USA east coast.. api is still up (have test code that just updated 3:30 pm eastern time time is UTC in json file |
|
From USA, West Coast. Tried the redownload Master and it worked! Seems to be fine at the moment. Thanks for this. |
|
FWIW, it looks like the problem was XFinity DNS. Switched to OpenDNS and I can log in. Changed DNS on the WiFi and devices connected. |
|
Think there will be another fix to not retry on known down devices in a better way in future. @magico13 minute requests from my test code: request:237 plug:55 vue:0 API is worse in the morning for me, will let it run. Kind of crazy how many more errors on the plugs vs vue2 devices. 3 of the plugs that have null data on some requests are in same room as router and arn't having any ping fails or things like that, so I think connection is good. So 23% of my 2 vue, 4 plug requests result in at least one plug with error response (returning null, when it's really not). api issue. I am Comcast in the east, dns here working fine.. weird. Always forget that can cause all kind of issues if it is wonky. my dns with Xfinity is 75.75.75.75 and 75.75.76.76 which seem to be fine here. |
|
Vue2 still failing, had typo in my count logic. :(. Not with frequency of plugs. Test running overnight. |
|
request:1141 plug:110 vue:4 just over 19 hours run.. plugs returned null 110 times, vue2 devices 4 6 devices polled, 2 vue2, 4 plugs |
|
Hello can anyone share is home assistant automation that restart emporia vue intégration when 1min sensor goes unavailable ? Mine is not working thanks |
|
update it and pick the master repository.. with hacs. (Make sense?). there have been some problems with api giving bad data which is being worked through. |
I don't have an automation, I just remember to re-start the Emporia integration a few minutes after every time I re-start Home Assistant. For some reason, the 1 minute sensors don't work directly after a re-start until I re-load the integration. This is may have been fixed in the new version which is still a work in progress. Under HACS Integrations, select 'Redownload' from the three dots menu in the top-right corner and select 'Master' at the bottom of the version drop-down list. |
|
I am running on a vm image of home assistant with haos on a Synology 920+ nas, and I don't have any issues on startup. Maybe I am on overpowered hardware compared to others? |
|
Same Issue HA reporting all O's Removed integration and reinstalled. Now it errors attempting to log the integration into Emporia |
|
Also - erroring out on attempting to login. (Tried changing DNS host since I'm on Comcast and that didn't change anything.) Looks like this broke when I updated the HA server/application earlier this month. Currently running HACS provided 9.3 tried rolling back to 8.1 and 8.3 without success. I've got a vue2 with 16 monitored circuits. Error: |
I'm relatively new to HA so apologies if I don't have all the information.
Since updating the integration this week. All energy data reads 0. Integration still works with no errors or warnings. I can also control all emporia switches.
I'm running a VM with the following:
Emporia v0.9.2 Bump PyEmVue to v0.18.3
Core 2024.2.5
Supervisor 2024.02.1
Operating System 12.0
Frontend 20240207.1
2024-03-02 21:42:49.340 INFO (MainThread) [custom_components.emporia_vue] Got None usage for device 229784 channel 1,2,3 scale 1MIN and timestamp 2024-03-02T21:42:42-06:00. Instead using a value of 0
2024-03-02 21:42:49.340 INFO (MainThread) [custom_components.emporia_vue] Could not find usage info for device 229784 channel 1
2024-03-02 21:42:49.340 INFO (MainThread) [custom_components.emporia_vue] Could not find usage info for device 229784 channel 2
2024-03-02 21:42:49.340 INFO (MainThread) [custom_components.emporia_vue] Could not find usage info for device 229784 channel
................................................................
(ALL OTHER SENSORS WITH SAME MESSAGE)
....................................................................
2024-03-02 21:43:07.553 INFO (MainThread) [custom_components.emporia_vue] Integrating minute data into day sensors
2024-03-02 21:43:07.554 DEBUG (MainThread) [custom_components.emporia_vue] Finished fetching sensor data in 0.001 seconds (success: True)
2024-03-02 21:43:12.704 DEBUG (MainThread) [custom_components.emporia_vue.switch] Finished fetching switch data in 0.415 seconds (success: True)
The text was updated successfully, but these errors were encountered: