Additional sensors

[dennisvbussel]

As stated in #2, I could not get the humidity/speed sensor to work so I removed them and implemented additional sensors such as the co2, temperature and flow sensors of the HRU which are reported inside the status message.

Feel free to try them out and adept it to your own coding style.

I'm not so sure about the update interval of the HRU/Co2 Remote so I will monitor if this is sufficient to reliably use these sensor values.

[x3e]

Hey, that's awesome. thanks for sharing!
I'll test this out in the coming days to see if it works for my unit as well.

Out of curiosity, how did you find the location of these sensors values? Did you find any useable documentation on these messages? Or just trial an error?

If the "timer" value in the status message is 16bit, does that mean that the time in TimerMessage.cpp should be 16 bit as well? I don't really get the reasoning (of the manufacturer) behind multi-day timers...

[dennisvbussel]

The Co2 is easy to find out by comparing with another sensor in the same room. The others were also easy to find out since my HRU unit has a small display that shows flow and temperatures.

I'm not too sure about that timer value, I just assume it is 16 bit. Could try to make the settime 16 bit and check the response.

Also I'm suspecting that the Co2 sensor communicates it's Co2 value with the HRU using a different message. Only manual actions on the remote get's that value to update... How else could it regulate Co2?

[dennisvbussel]

Attached an interesting log file:

The first byte form my remote is 0x1C however, the HRU seems to use 0x3C as first byte. What is also interesting is that 0x18 is used. Could this be a broadcast message? Perhaps my spider thermostat sync the ventilation state to this broadcast message.

Is your system using 0x3C as first byte for response? Have to check if the incoming packet is filtered on this first-byte. Maybe skipping or adding 0x3C as first-byte will improve the receiving part of the remote.

logs_mk-wtw-co2-itho_logs.txt

[x3e]

At first, I thought that that first byte was device specific. But later I learned that the protocol is based for a great part on the "RAMSES II RF" protocol.

This is some interesting documentation on what that first byte normally means:
https://github.com/ghoti57/evofw3/wiki/Message-Body

Based on that, the first bytes denotes the type of packet:
0x0*: Request
0x1*: Write
0x2*: Information
0x3*: Response

It's a bit weird though, that there doesn't seam any 0x0* packet in your log that the device is responding to...

[dennisvbussel]

At first, I thought that that first byte was device specific. But later I learned that the protocol is based for a great part on the "RAMSES II RF" protocol.

This is some interesting documentation on what that first byte normally means: https://github.com/ghoti57/evofw3/wiki/Message-Body

Based on that, the first bytes denotes the type of packet: 0x0*: Request 0x1*: Write 0x2*: Information 0x3*: Response

It's a bit weird though, that there doesn't seam any 0x0* packet in your log that the device is responding to...

Well, If I understand the Message-Body correctly:
0x1C (0b0001 1100) is a write and includes addr0 + addr1
0x3C (0b0011 1100) is a response and includes addr0 + addr1

The remote is not sending a request but a write and the HRU replies with a response.

I fixed the status message response parsing in commit fddb3dc
Not sure if switch -> button change is wanted. I guess I'll leave that up to you.

Last action from my side is to verify the flow rates. The values seems a bit off now.

[x3e]

Thanks. I'm verifying the implementation with my unit, but seems like we have very different fields available:

Seems more or less logical, since my unit is just ventilation box, and it seems like you have a heat recovery ventilation or heat pump, right? Can you report the model of your central unit?

Mine is an CVE-S ECO SE by the way

[dennisvbussel]

The unit that I have is a HRU ECO 300. It seems that your payload is constructed differently than mine. Perhaps this message is not 1/1 over different models.