-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sems Portal Nightly Midnight Zero is double dipping upsetting HA Recorder #94
Comments
I'm also seeing this exact same issue since 28th Dec. Unfortunately I can't see a way to use an automation to disable the SEMS service for a period of time, as that would have been a quick workaround within HA. Only other thing I can thing of as a workaround for now is to create a new template sensor in HA that copies the value of the original sensor from this integration and stop this sensor from updating between 00:00 - 00:15, you would then have to add this sensor to the energy dashboard for it to reflect correctly. Hardly ideal but would achieve the desired outcome! Any help from @TimSoethout would be greatly appreciated! |
As a workaround I've done a few things, as yet I am not 100% sure if it's sorted it (and its only a bandaid). So the issue as ew know is the double dip ... the import kwh and export kwh all go to zero around midnight, then dip back to some form of the previous days numbers but not exactly (all of which is data coming from Sems Portal, yet doens't show up in the reports you can run from sems portal CSV export) . SemsPortal accounting bug of some sort which came in as soon as they fixed the bigger bug which was KWH metrics weren't resetting at all (for days, even on semsportal). So the issue is HA seeing that zero'ing, followed by data - and thinks its new usage (hooray for generating power from the moon right??). I did initially try using an automation that does a Utlility meter reset (as pictured below) ... but even so the "consumed" power would still show (and util meter calibrate doesnt apply to that). So I went a step further and actually turned off the recorder from 11.59pm to 1230am, my idea being not recording any energy data at all therefore it disregards what it sees. In theory turning off the recorder should actually do the whole trick but i added in the zero'ing automations as a bit of a scatter-gun approach. If this doesnt work, another idea I had was I might just disallow HA from being able to talk to the internet between midniht ad 1230 ... so it never gets exposed to the data from the double dip (it's back to zero by 1215 usually). I've not yet confirmed if this actually works (before anyone goes following down this line). |
Thanks for the update @davidsonimagerygmailcom I've come up with a similar workaround for now and will update tomorrow if it has helped. YAML for the automation below, you must have disabled polling on the integration first (Open integration, click 3 dot menu, system options, turn off 'Enable polling for updates') Also untested so don't do this if you're unsure, I'll provide an update tomorrow advising if I had any luck with this or not. Automation is triggered every minute to update the entities in the list. You'll need to change these to match your entity ids, I just added all entities associated with the integration.
|
You could even apply the logic of missing the first zero'ing entirely (as you'll get it after 1215 anyway) ... kinda why I went for 1159pm (bypass the whole shemozzle) |
I wasn't sure if it needed to reset to zero at midnight for the energy dashboard to calculate it correctly.
|
Good point. Not sure! |
How would we define every 30 seconds for polling instead of minute? I wonder if ; trigger:
is permissible (please excuse my amateurism!) |
Ok, so based on the fact that we don't really know when the data will spike after zeroing the first time and that the first zeroing may not be exactly at midnight I've modified things slightly and added a second automation. The first automation is same as above however I've removed the condition so it'll run every minute no matter what. The second automation will trigger when the entity hits 0, it will then disable the first automation wait fifteen minutes and then enable it again. This way we don't have to worry about exact timing from the SEMS side. Automation 1
Automation 2
|
Re 30 second polling, you would just need a second action, one covers 00 seconds the other covers 30 seconds.
|
Done and working well, i might just to go straight to using your method and see what happens tonight (it's 3pm here). |
Another option:
|
Glad to hear it worked @davidsonimagerygmailcom Now I need to figure out why it didn't work for me! Hahaha. |
Thanks for that, I might have made it more complex than it needed to be haha! |
Just found this one, seems similar issue (possibly the same?) |
Hi all, great that you've found a workaround. I'm currently limited in time and energy to work on this, but I'm happy to merge a fix if someone provides it. :) |
Yeeepp that's what first caught my eye ... I was perplexed how I'd made so much power from the Moon, and who was running around pulling huge loads at midnight :) |
Ok went back to my original suggestion and worked perfectly last night. So for those looking for a workaround, the YAML code below works well, create a new automation and use this, make sure you change the sensors in the entity_id list to match your sensors. You also need to disable polling on the 'GoodWe SEMS PV API' integration (Open integration, click 3 dot menu, system options, turn off 'Enable polling for updates')
|
Thanks for the automation to resolve the midnight double dip issue @skreza. I have also noticed that at around the same time this issue started, i am now seeing a gap in my house consumption between 10pm and midnight, is anyone else seeing this too? it's happening on my main SEMS homekit integration sensor sensor.homekit_91000hkuxxxxxxx. Any thoughts? It was happening prior to disabling to my polling and moving to the automation for updating entity. I should note that my grid import stats are unaffected between 10pm and midnight which makes this ever stranger. |
Im also seeing this, but it is for the 'current consumption' value, not the running daily total which the energy dashboard uses. So its not impacting the $ calc on the enegy dashboard, but is annoying that the other dashboard I setup has a gap in data |
Confirming same issue for me also, however my data is blank from 9pm - midnight, I wonder if this is time zone based? I'm in Melb so currently +11 UTC. I hadn't noticed this as I don't look at house consumption all that much, I have another integration that pulls data from a Powerpal on my meter and tend to look more at grid import power rather than ongoing house consumption. As @justinmaiuto mentioned, the total consuming is still correct though so data in energy dashboard should still be pretty accurate. Data in SEMS portal looks fine, pretty weird issues but unfortunately I'm no dev, so trying to fix the source code is above my expertise! |
so you lose 3 hours of data? weird! Im brisbane so im +10 UTC |
The double dip issue is still there, tested last night. Goodwe support (when they choose to respond to repeated followups) simply say "I can see from my end that the inverter is back online and the readings are showing. Without any regard to the extensive outlining of my information prior to them. The issue doesn't appear to SemsPortal because whatever this "zero'ing" procedure is that they're doing, it's not being ingested by the sems graph / portal data. Have repeatedly asked to have the issue escalated to the team whom actually look after the back end databases but falls on deaf ears. back to leaving the polling off between 2359 and 0020 |
Deleted the last comment about 1130pm uptick, as realised internet had been down and homekit wasn't reporting usage for several hours. Disregard for anyone that read it before I deleted. |
Try and handle bug in the goodwe api where it returns zero when close to midnight. @see TimSoethout#94
Thanks everyone for your input into this. @skreza I've implemented your automation and data looks spot on today, so thanks for sharing. |
Hi @TimSoethout, I seem to be having issues with this after daylight savings has started here in Melbourne Australia. I've changed the integration to stop upating the entities now from 1am - 1:10am (ie. what was previous 12am - 12:10am before daylight savings), but it doesn't seem to be working? |
@BrutalDeluxe20 I'm Melb based and haven't had any issues post daylight savings. Based on previous comments, you mentioned you changed to automation polling rather than using the SEMS polling in the integration. How have you got it configured currently? Mine is still on the automation as per: #94 (comment) |
Hi @skreza, yes I have it setup as you do. So have disabled polling in the GoodWe SEMS API integration and then use an automation to run every minute to manually update the various entities with the break around midnight. I did only have 10 minutes I think, so have extended that to 20 as per comment #94 and will see how it goes tonight. Just strange it seemed to stop working for me when DLS started? |
It also could be ralated to the component only recovering after some time, and counting all the previous hours to the current hour. Sometimes you get graphs like that then. |
Hi Guys, Firstly hello and thanks for writing this great API. It's been at the heart of dashboards we have running on wall mounted displays in our home.
I appreciate this is likely a SemsPortal issue not this HACS integration, but wanted to pick brains.
So over Christmas break noticed that figures for exported and imported kwh weren't updating at midnight at all.
That seemingly got resolved, but now find once it resets, a minute later sems portal reverts to the previous days reading ... for roughly 7 minutes, before zero'ing a second time. This of course causes Home Assistant to see fresh kwh amounts of consumption (both imported and exported power) ... and adds phantom data to the recorder. Screenshots attached.
As a work around, is there a sensible way to get this integration to simply **not ** perform any queries between 00:00 and 00.15? (ie if it doesn't do a query during these times, it never gets exposed to the transient dodgy data?
I did fire an email off to GoodWe support but I'm not sure it is reaching the team whom actually administrate the accounting part of semsportal.
The text was updated successfully, but these errors were encountered: