Calculate water consumption

[kopierschnitte]

Thanks for this great project!

I was wondering if anyone has an idea on how to calculate the water consumption out of the values we get from the sensors.

Now that we know what kind of data the HMI gets, it sounds obvious to me that Cozytouch is also just "calculating" this. Or at least tried until the recent server update.

Maybe a formula regarding the temperature drop in conjunction with the water capacity?

[tspopp]

Hey, can you provide some examples how the water consumption value looked like, since I never had cozytouch working with my heatpump. With example I mean information like: what is the dimensional unit (litres or more granular?) and is it a counter value which is rising over time or is it showing the water consumption at this point in time?

Maybe this information is present within the protocol, but yet unidentified since it's not shown by the HMI 🤷‍♂️ . Actually within the "energy message" (id 67) there is a value which is rising over time but yet unidentified what it actually is... (byte 9 and 10).

If there is some fancy calculation formula, we can only try to re-engineer by looking at recorded and timestamped values and see if there is some correlation between water usage and temperature.

[kopierschnitte]

Thanks for taking a look:

The value is measured in centilitres (100 per litre) and increments (total counter). While developing the iobroker script for cozytouch, I've seen that this value has to be requested from a linked server and not the one, I'm querying for temperature and states.

The Cozytouch-App also refuses to display these values since a few weeks "due to a rework of the calculation" ... but I guess that's more an application issue.

If you do see some incrementing counters I'll bet they could be interesting 😉

[kopierschnitte]

Sorry ... my fault: The Cozytouch-Server offers a state called V40WaterVolumeEstimationState and it's measured/returned in litres since installation.

[tspopp]

I've been looking up V40WaterVolumeEstimationState in google and somebody mentioned that this value is a wrap around counter value at 65536 (uint16 max). Same applies to my unknown counter value which is also uint16 and wrapping around.

Therefore I decided that it is very likely that the unknown counter value is the water consumption value you are looking for. Please try the changes on my branch and give some feedback if this new introduced value shows the same behavior as the missing volume value: https://github.com/tspopp/AquaMQTT/tree/t/unknownCounter :)

    - name: "Aquawin Total Water Consumption"
      state_topic: "tortuga/aquamqtt/energy/waterConsumption"
      unit_of_measurement: "l"
      state_class: total_increasing

Looking forward! 😄

[kopierschnitte]

First test looks promising! At least, it displays exactly the same value I'm getting from OverKiz.
Well done ;-)

[tspopp]

Nice! One more attribute in the protocol seems to be clarified 🎉 🥳

Are there more attributes shown in cozytouch, which AquaMQTT currently does not have? We might try to locate them in the protocol as well...?

[kopierschnitte]

Glad to see that you've still got a perfect overview of the protocol ;-)
I've seen no other values. Therefore, I will happily disable the cozytouch implementation.

Maybe we should leave this issue open until it's merged into main?

[tspopp]

Haha, yes, actually that single unknown counter was bugging me... Glad to have it resolved ;)

Yes, will take care this evening 👍

[kopierschnitte]

There's one thing I've noticed while testing this new feature: After a reboot of AquaMQTT, it initially publishes a value of 0 to the broker.
As I'm using iobroker's SourceAnalytix adapter to track the water consumption and it needs to detect value overflows, the adapter thinks, such an overflow happened. Therefore, the entire calculation is wrong after this point.

Maybe it's possible to delay the initial value sent until "real values" appears on the bus?

[kopierschnitte]

Sorry, there might be another thing: I've noticed that the counter didn't increase within the last 12h although I'm quite sure it should have.

It could be related to the time I've taken my Cozybridge offline. Maybe the HMI somehow "triggers" this reading (through an external command issued by Cozytouch)?

Or, even worse, the value is indeed originating from the Cozytouch servers, based on their calculations, and pushed back to the HMI bus (which makes no sense because this value isn't visible on the HMI).

[tspopp]

Good point. I need to check what is causing a 0 after boot. Actually it should only publish values if a message has been received, so the "initial" values should be values already sent by the heat pump 🤔

[tspopp]

Regarding the data, I see readings on my AquaWin heat pump as well, so it shouldn't be bound to cozytouch, cause I never had that. Let's inspect that value further and maybe we are able to determine the magic from the cozytouch servers?

[kopierschnitte]

Okay, that sounds promising ;-)
Upon further investigation, I've noticed that there are several other values which were updated at the same time (and no further):

• energy.totalEnergyWh
• energy.powerHeatpump
• energy.powerTotal
• main.stateFan
• main.stateHeatpump
• main.statePV

But it occured around 7am and at this time, the target temperature was already reached and the device effectively did nothing. Also my external Shelly controlling the PV-input went to false around this time. Therefore I think that these values might be true.

I also don't see any (rising) packet drops, CRC errors or unhandled messages. Also, other values like temperature are coming in every second.

A simple power cycle didn't change anything yet.

Let's see what happens as soon as the device starts heating again ;-)

[kopierschnitte]

Sorry to spam this issue further ;-)

Now the counter did increment but it seems to me that it's rather coupled to the water production instead of consumption as it increases steadily around 1l/min while the heatpump is working.

This makes sense to me because the system can't really measure the water extraction without having somekind of sensor. Also it shows why the Cozytouch app only showed past consumptions (day before).

If that's the case, then the user needs to do some math in order to use these values.

By comparing the starting and final value of a day, one can tell the amount of heated water ... and that's more or less the amount of extracted water from the day before, isn't it?

[tspopp]

I like that kind of spam 😉 😄 Yeah, production makes more sense. But looking back the past day will still just give you a history in regards to production, not consumption? And these kind of maths you will get from Homeassistent for free for any counter values.

The only way to determine consumption is by determining a production value which is always needed without any actual consumption. For example, if your heat pump is idling the whole day, keeping temperature for example at 53°C it will produce ~100 litres (just some random value) of hot water. If you are aware of that value, you can calculate actual consumption by subtracting 100l from the overall daily produced value.

Does that make sense? 🤔

[kopierschnitte]

Well, yes, I guess that's exactly the same problem, the Cozytouch developers are thinking about these days ;-)

Just for beginning, I've started using this counter as somekind of performance counter by just measuring the time between a change (which seems to be always 1l). Then I can estimate "litres per hour". That's great to see the eficiency of the heatpump and a nice tool to calculate the actual costs per litre. It's also good to see that enabling the heating element instantly shows an effect on this value.

For now I'll start playing a little bit with these values and maybe get an idea on how to do those consumption calculations.

[tspopp]

I prepared the PR for water production (renamed) and I will merge that, leaving the discussion for water consumption open.

There's one thing I've noticed while testing this new feature: After a reboot of AquaMQTT, it initially publishes a value of 0 to the broker. As I'm using iobroker's SourceAnalytix adapter to track the water consumption and it needs to detect value overflows, the adapter thinks, such an overflow happened. Therefore, the entire calculation is wrong after this point.

Maybe it's possible to delay the initial value sent until "real values" appears on the bus?

How did you reboot while you experienced that zero value? The whole heatpump using AC on/off together with AquaMQTT, or only AquaMQTT using OTA or via a hard reset? AquaMQTT is configured in MITM mode? I am trying to figure out how that zero appeared, since AquaMQTT does not publish any initial values.... 🤯

[kopierschnitte]

To be honest, I don't remember exactly. It could also happened while flashing the Arduino again because I forgot to change the Wifi credentials after pulling sources. Therefore, OTA went dead end :-(

It could be a situation where the controller is online, connected to the HMI but not connected to the main body.

Yes, it's configured MITM

[kopierschnitte]

Thanks for your commit. After uploading I've noticed that neither the new "energy.totalWaterProduction" nor the "energy.totalXXXHours" counters get updated. But I also don't get any dropped or failed transmissions.

Other values/counters (like powerXXX) are fine.

The test branch worked fine.

Is it working in your case?

UPDATE: Sorry, my fault. The totalXXXHours-counters work as expected. I didn't wait enough ;-)
But the new totalWaterProduction remains steady (but with a correct initial value).

UPDATE 2: Okay, after about 90min the counter raises again. Wasn't aware of this delay but it seems that's out of our "scope".

[kopierschnitte]

Okay, everything's fine and great now. Closing this because AquaMQTT does everything it can do. In my opinion, other calculations/assumptions should be done within the middleware...