Replies: 9 comments 1 reply
-
|
Since a few weeks ago Senec likes to let the total values jump up and down. That's why a fix was introduced so that the values are only accepted by the integration if they're higher than the last recorded values. But that also means that if the values jump up and then down to the correct numbers then the integration won't accept that and will stay on the high numbers until mein-senec.de has caught up. I guess the integration needs some kind of plausibility check that it also won't accept values that are too high if they're not doable by the device. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @bobthebuilder4711 , |
Beta Was this translation helpful? Give feedback.
-
|
@h4nnes please blame Senec (which seams to be the right default reaction)... HoHoHo |
Beta Was this translation helpful? Give feedback.
-
|
@marq24, Senec: No comment… Merry Christmas all! |
Beta Was this translation helpful? Give feedback.
-
|
I did not take anything from you as complain - no worries... I am start thinking about the suggestion from @bobthebuilder4711 if it would be possible to check for "implausible" increments as well - but this would (IMHO) imply to predict the expected increments over time AND predict the future creativity of Senec developers... :-) |
Beta Was this translation helpful? Give feedback.
-
|
Maybe the best course of action would be to introduce a "prove of concept" riemann sum automatically with the integration, that sums up the values of the "now" parameters. If they defere too much from the "total" values provided by the API (difference daily) the prompt by the API should be ignored. |
Beta Was this translation helpful? Give feedback.
-
I am looking forward to your PR ;-) I have to admit that in my professional carrier (+40 years) I have wrote just to many lines of code in order to "correct" things other devs should have made "just right" - That's why I really like open source - if there is a bug/issue, you can fix it at the source [just like I did it with the incorrect cookie handling in the aio-http lib - now everybody will benefit from that]. This would make any kind of artificial patch framework obsolete - which anyhow will generate also false-positives for sure. |
Beta Was this translation helpful? Give feedback.
-
|
Sadly you are right. Its just stupid that this was changed anyhow. Although a "Data security"-neighbour told me, that in the first half of 2024 (new law) the data provided by hardware HAS TO BE STORED locally and the distributor HAS TO ASK if he is allowed to copy the data into cloud solutions. Maybe then they simply revert to the totals on the local system. But that is propably "Wunschdenken" :-D I´m just annoyed, that for the webapi I have today 0 house consumption and yesterday trice as much as actually...Should have gone with the riemann sum from day one... |
Beta Was this translation helpful? Give feedback.
-
|
So far I only know one person with a Home V4 and they don't have this problem. So this seems to be limited to V2.1 and V3. The V2.1 has a maximum charge and discharge rate of 2.5kW. The V3 can charge with 2.5kW and discharge with 3.75kW. 2.5kW means 2.5kWh per hour. Divided by 60 that's 0.042kWh per minute. And since senec updates in a 5 minute interval we take that times 5 and arrive at 0.208kWh per 5 minutes. For 3.75kW that's 0.0625kWh per minute or 0.3125kWh per 5 minutes. So every time these values jump by more than 0.22kWh or 0.32kWh then that's implausible because it's impossible to do for the hardware. Yesterday at 14:50 the accuimport of my V2.1 jumped by 2.74kWh. At 14:35 the accuexport jumped by 1.58kWh. Both way above the 0.22kWh. So that could be easily discarded. And shortly after that they went even higher. But since we would have discarded the first jump this would be an even higher jump and would be discarded as well. So what I'm suggesting and what I'm going to add to my script as well: Don't just ask HA for the last stored value but also for the timestamp when that value was stored. Then calculate the difference between now and that stored timestamp. If the difference is below 5 minutes then assume it is 5 minutes. On one hand that's the update rate of mein-senec.de for V2.1 and V3 devices. On the other hand that's the recorder interval of Home Assistant. If the difference is above 5 minutes then don't change it. That covers the case if HA didn't update because it was restarted for example. And it covers the case that HA simply can't access mein-senec.de for some time. Now divide the received new value by the difference in minutes to get the kWh consumption per minute. If the result is above 0.042kWh (or 0.0625kWh for the discharge of the V3) then discard that new value. Basically the same is true for grid import and export and even for PV production. (But here you can actually have much higher currents.) V2.1 owners can circumvent this for the PV production by simply directly asking their separate inverters for their production values. That's what I've been doing since September with my SMA inverters. And grid import and export can be asked from your digital electricity meter directly with a cheap Volkszähler (example: https://www.amazon.de/Hichi-TTL-Stromz%C3%A4hler-SmartMeter-Volksz%C3%A4hler/dp/B0CH95T7X4 ). But let's say that you can't do this (for PV because you've got a V3) or don't want to get additional hardware. Then you could still add fields in the config that tell the integration how much power the different sensors could reasonably see. A normal grid connection usually has 63A fuses. Times 230V that's 14.49kW. And since you usually have three phases the grid connection can take up to 43.47kW. My grid connection actually jumped by 97.76kWh. Since that is for a time frame of 5 minutes you divide that by 5 and multiply it by 60 to get to kw => 1173,12kW. So again much higher than my grid connection can handle. I've got 28kWp on my roof. The jump for PV was 11,15kWh. Divided by 5 and multiplied by 60 that is 133,8kW. And that too is much higher than my roof could ever provide. Bottom line that means the integration would need to know how much kWp you've got on your roof and if you've got a V2.1 or V3 and the number of battery packs. For the grid connection I would provide a config field as well but pre-populate it with 43.47kW for 63A fuses and 3 phases (which isn't true everywhere but most common in Germany). Edit: I think that one Home V4 isn't affected because it was activated in summer of 2023 and the problems with jumping values were first located to be in May of 2022, so long before this V4 started recording. I'm starting to get the feeling that this is maybe an out of sync data storage on senec's side. You poll once and get the data from server A and then you poll again and get data from server B that is either missing days or has additional data that server A doesn't know about. But that's of course nothing we can fix. |
Beta Was this translation helpful? Give feedback.
-
|
New comment with a different solution: If the problems really stem from data inconsistencies before 2023 then why not just stop using the total value and instead we use the value from 01.01.2023 up until the current day: So this is the webpage for that: And that is the api call the webpage executes: 1703329200000 corresponds to Sat Dec 23 2023 12:00:00 GMT+0100 So for tomorrow the timestamp would be 1703415600, resulting in this api call with the days +1: And we can even ask for the total amount up until 31.12.2022 with this call: 2983 days is as far as the web gui lets me go into the past. But you can also use a higher number and it will work the same. So basically what you do is ask for the totals up to 31.12.2022 once and save that somewhere. And then you only ever ask for the data since 01.01.2023 and add the saved value. You don't even have to go super far back. If someone sets up the integration the first time, you can just ask for the total up until yesterday and save that value and the unix timestamp and then always use that as your base value for future api calls. If you are super unlucky and that first call to get the historical total values includes the wrong data then you can just delete and reinstall the device in HA and name everything the same. That way the historical total values are freshly queried and hopefully correct this time without losing any recordings made by HA. |
Beta Was this translation helpful? Give feedback.
-
Hi,
Since today I get some weird values from the webAPI.
E.g.: senec_web_gridimport_total = 12.954,96 kWh, but the value from the app and also from mein-senec is 12.884,84 kWh
Any idea why I have this wrong values with my V3 hybrid duo?
Thanks!
Hannes
Beta Was this translation helpful? Give feedback.
All reactions