-
Notifications
You must be signed in to change notification settings - Fork 24
Gas consumption doesn't match in the sensoApp and HA #254
Comments
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. |
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:
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 |
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 |
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:
For 2023-11-20 gas consumption in the app is 74kWh, but 63kWh in HA
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
For 2023-11-22 (today) it's even worse. HA didn't import anything
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.
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?
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?
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?
The text was updated successfully, but these errors were encountered: