Skip to content
This repository has been archived by the owner on Mar 19, 2024. It is now read-only.

Gas consumption doesn't match in the sensoApp and HA #254

Open
zolakt opened this issue Nov 22, 2023 · 3 comments
Open

Gas consumption doesn't match in the sensoApp and HA #254

zolakt opened this issue Nov 22, 2023 · 3 comments

Comments

@zolakt
Copy link

zolakt commented Nov 22, 2023

So, as the title says, the consumption rarely matches between the app and the HA integration.

I know you just get the data from the API, and display what you get, but some things are still weird. Both the app and the integration are using the same API, so the values can't differ when they are fetched.

Here are a few examples:

  1. For 2023-11-20 gas consumption in the app is 74kWh, but 63kWh in HA
    Screenshot (22 Nov 2023 11 07 54)
    image

  2. For 2023-11-21 it gets more weird. It seems HA just stopped importing after 08:00. So, instead of 68kWh that the app displays, HA shows just 10kWh
    image
    image

  3. For 2023-11-22 (today) it's even worse. HA didn't import anything
    Screenshot (22 Nov 2023 11 00 48)
    image

I know the integration doesn't fiddle with these numbers, but still you are using the same API, so these differences can't come from thin air. I have a few theories on what might be going on, but you have more experience with this, so maybe you can validate/invalidate them.

  1. For these smaller differences (e,g. 63 kWh instead of 74kWh), could this be timezone related? Due to timezone offset that either the app or the integration gets a few hours less (or more) data for the specified day?

  2. For this big differences, where it basically stops importing, I suspect the main problem is their API. It's terribly unstable, even when used through the sensoApp. Sometimes I need to change the temperature 5 times in the app (an open/close app a few times), until it finally picks it up. I don't know how you import this consumption data. Are there any webhooks (although I doubt given how crappy their API is) or do you just periodically call their API every hour or so? In case of the latter, if their API fails to respond, what do you do? If you do nothing and just wait for the next cycle, that would leave hourly gaps, and would explain this cutoff of data that I'm seeing. Would it be possible to implement some retry mechanism, so it keeps trying to get the hourly data until it finally gets it?

  3. If you do import data periodically every hour, and it would be a problem to do reties all the time, maybe it would make more sense not do to it every hour, and just to import the data for the whole day once (plus retires) after the day is over. Sure, you would have a one day delay, but I don't think that matters in the vast majority of cases. I doubt anyone sits by the screen and monitors this hour by hour continuously. I would rather wait a day to get correct data than having "real-time" corrupt data. An alternative would be not to mess with the frequency of imports, but just to add some service that could refetch the data retroactively. Wipe out everything that was there, and fetch the new data from the api. I could then have an automation for that, so it recalculates the previous day consumption sometimes in the night. The "real-time" fetching would still be there, even if it's corrupt, but at least tomorrow I would have correct data.

Also, is there something I could currently do to get out of the issue I'm having now, where it basically stopped importing?

@zolakt
Copy link
Author

zolakt commented Nov 22, 2023

Now I've spotted that all of these consumption sensors have become unavailable since yesterday. Only the consumption sensors were unavailable. The climate entities, and the others, worked fine, I don't understand why. Any ideas?

Btw. they became available again after restarting HA. However, it could happen again, and it would be good to know why. However, it still doesn't explain the first issue, when they are available, but the values in the app and integration don't match. Also now I have gaps in HA for the time they were unavailable, which I can't (or don't know how to) retroactively fill in.

image

@thomasgermain
Copy link
Owner

Hello,

thanks for the detailed report. The short answer is no, I don't use the same API as the "detailed" screen, mainly because of here: #135 (comment). I get the data from EMF report, which are reporting the daily consumption.

For 1), I don't think this is due to timezone (if your HA timezone is the same as multimatic one). The problem can happen for 2 reasons:

  • multimatic API doesn't refresh "fast enough", for example, the call at 23:59 doesn't report any new consumption, but the call at 00:01 the day after report the actual consumption of 23:59, so in HA these consumption is reported for the wrong day
  • the multimatic API is not reachable at all and the consumption is "lost"

For 2), the main reason is because the sensor are unavailable, because the API is not available. You should find more information in the logs .

For 4), as far as I know, there is no way to get these data. EMF report reports the daily consumption, but the update rate (at multimatic side) is +- 1h. The refresh rate at integration side is 2min, so even if there are multiple errors, normally, it should be fine.

One possible solution is to call Multimatic: request_hvac_update service every hour or so in an automation. It forces local devices to send their data to vaillant server. (It might gives error if you call this service too often, so IMHO no more than once a hour)

@zolakt
Copy link
Author

zolakt commented Dec 14, 2023

I see. Thanks for the explanation.

Maybe you are right that it's just the last hour of the day that gets logged into the next day. Now when I look at my screenshots again, it seems like everything is offseted by an hour, although the time scale in their app is so weird until you fully zoom in. I'll try to do a more detailed comparison.

If it's just offseted, I don't have a problem with that. I don't care that much about daily consumption, as long as it evens out, more or less, on a monthly level.

If it's not just the offset, I'll give request_hvac_update a try, and see if it helps. I'll let you know either way

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants