Parse message from itho daalderop autotemp and spider

[tomkooij]

This is a reboot of #69

I have a winters worth of packet.logs and I have studied the Itho daalderop manual and servicetool. I think I understand most of the messages.

I want to at least fix the AssertionErrors that clutter my home-assistant.log but also would like to add some functionality to ramses_cc (so let's add the messages to ramses_rf first).

TODO:

• [x] 3110 heat_demand and cooling/heating status.
• [x] 22d0 cooling/heating status
• [x] 22c9 fix error and add cooling/heating status
• [x] 4e02 fix error and parse message
• [x] 4e04 fix error (contents currently unknown)
• [x] add 4e0d, 4e15 and 4e16 (contents not really known) just fix errors
• [ ] ~the messages are now in the HVAC domain, but its really heating. (Itho autotemp is an UFC) change this...~
• [ ] Fix tests

[tomkooij]

@zxdavb I added a parser test for 3110. In a gitter message some months ago, you suggested I add tests like tests/systems which are much more elaborate and difficult. I might be able to do this, once I get everything sorted...

Is this kind of test okay? Would you like more info/docs/tests?

(My main goal is to add the heat_demand and heating/cooling status from this message to the Home Assistant entities, so I can view them in HA.)

[zxdavb]

Tom, this is great.

I'll have time for a review when I get home, approximately tomorrow.

[zxdavb]

BTW, I'm thinking to keep this in HVAC domain.

• CH/DHW domain is Honeywell or 100% compatible
• HVAC is everything else

When I say CH/DHW, I mean devices that only do a true subset of that, and not additional packets.

[tomkooij]

The tests currently FAIL on two items:

[...]
tests/test_apis_heat.py::test_set_0004 FAILED  
[...]
tests/test_ramses_schema_wip.py::test_codes_idx_mutex FAILED                                                                                                                                                                                                                             

tests/test_apis_heat.py::test_set_0004 fails on master on my system as well, so I'm disregarding that.

The mutex one seems clear: I need to add new codes to the sets on the bottom of ramses_rf/protcol/ramses.py: CODE_IDX_*

But I do not seem to get it. I do not understand to which list to add the new codes.

[zxdavb]

Tom, this is fantastic work and I will definitely get it merged.

OK, some quick thoughts...

Your commit is too complicated. For example, you should ideally have one per code (multiple commits per code would be OK).

I would ideally like tests on both:

• all (command) codes, e.g.: 10e0, 22c9, etc., and
• all device classes, e.g.: Spider gateway, Itho HRU, etc.

Finally, there is a real need to make architectural changes, which will affect (really, is driven by) HVAC devices. However, I suggest we get your work merged, then maybe you can help me with that further down the line.

[zxdavb]

I have a winters worth of packet.logs and...

It would help if you sent me a packet log dump to test off too.

[zxdavb]

Let's start with 3110...

[tomkooij]

I'll move the 3110 changes to a new PR #78. Let's try to do one at a time. I'll cherrypick out of this.

[zxdavb]

I think we can bank 3110 (includes a parser test), but do have a look at it, and let me know.

[zxdavb]

@tomkooij This autotemp looks like an UFH manifold - but seems intended to be connected to a heat pump.

What can you connect it too, other than UFH? What about DHW?

How many circuits does yours have?

[tomkooij]

@tomkooij This autotemp looks like an UFH manifold - but seems intended to be connected to a heat pump.

What can you connect it too, other than UFH? What about DHW?

How many circuits does yours have?

The autotemp is an UFH manifold but is also a controller. It has connected room thermostats. Usually a thermostat for each "zone", except for the bathroom which does not have a separate thermostat. All communication between autotemps and thermostats (spider) is done using RF.

The master autotemp calculates heat demand and determines when to heat or cool. The WPU "heatpump" is just a slave. The heat demand and mode is sent to the master thermostat using RF and the heatpump is wired to that thermostat using OpenTherm. The autotemp cannot tell the WPU to actually start heating. It just gives heat demand and de heatpump needs to decide when to actually fire up the compressor and start heating.

The WPU does not respond to or send RF, it recieves information from the main room thermostat via OpenTherm.

DHW is determined by the master thermostat (spider). The autotemp UFH has no knowledge about DHW. Except for "repeaters" and HGI-80 devices I don't think there are other devices that can talk to the autotemp.

My setup: My downstairs master autotemp (02:250704) has a single connected room thermostat (21:033160 which is also the main thermostat connected to the heatpump by wire/OpenTherm). There are 4 valve circuits which open/close together. My upstairs slave autotemp (02:250984) has 5 thermostats connected (5 bedrooms and a bathroom, which does not have a thermostat) 9 circuits. (6 zones).

[zxdavb]

@tomkooij Did you see my questions re: the 4Exx parsers?

We could knock those off next - no need to submit a PR, just let me know the answers to my questions.

[tomkooij]

@tomkooij Did you see my questions re: the 4Exx parsers?

We could knock those off next - no need to submit a PR, just let me know the answers to my questions.

@zxdavb Sorry I missed your questions. All comments refer to 3110. I see no comments at all around 4e02 or similar. !?

[zxdavb]

Woops - my bad - didn't submit the review. Have a look now.

[tomkooij]

Woops - my bad - didn't submit the review. Have a look now.

I'll have a look after lunch today!

[zxdavb]

I'll have a look after lunch today!

Just so you know: I'm in Australia (GMT+10).

[tomkooij]

@zxdavb Done. I think 4e15 is interesting as it has the same information / matches as 3ef0. 4e0d and 4e16 are just unknown... Cannot find a pattern.

4e01 would be nice to have (to make visible in HA in a proper autotemp device along with 3110)

[zxdavb]

@tomkooij

The tests currently FAIL on two items...

I am stuck/working on 4E0D - it has opened a can of worms.

This happens occasionally - I make assumptions that turn out not to be true, then I go and get stuck in a rabbit hole... eventually (like now), I find I have to do a small refactor.

[zxdavb]

To be clear - I will put all the 4Exx parsers in.

[zxdavb]

The autotemp is an UFH manifold but is also a controller. It has connected room thermostats. Usually a thermostat for each "zone", except for the bathroom which does not have a separate thermostat. All communication between autotemps and thermostats (spider) is done using RF.

This is exactly how evohome is set up.

In evohome the room stats are bound to the master thermostat (called: controller), although the UFH manifold (HCC80) could have stats bound directly to it, it's just not implemented that way anymore.

I would describe it as: the master thermostat is the controller - the UFC (Autotemp UFH controller) is slaved to it (as is the WPU). The room stats are slaved (bound) to the UFC.

The way I look at it is like this: each slave makes the call for heat to it's master, which itself is a slave to an upstream master, and so on... Eventually, the final master (controller) passes on a call for heat (or cool) to the provider (heat pump / boiler / relay).

[tomkooij]

I tested the latest master (including 4E01 / 4E02): works fine! Thanks so far!

[zxdavb]

@tomkooij Regarding 4E15, I was thinking about:

NOTE: has been edited

2022-08-21T19:00:33.119082 072  I --- 21:034158 02:250676 --:------ 4E15 002 0000  # {'_flags': [0, 0, 0, 0, 0, 0, 0, 0], 'state': 'is_idle', 'is_dhw_ing': False}  # idle
2022-08-21T02:07:53.248113 064  I --- 21:064743 02:250708 --:------ 4E15 002 0001  # {'_flags': [0, 0, 0, 0, 0, 0, 0, 1], 'state': 'cooling', 'is_dhw_ing': False}  # cool_active
2023-03-19T12:05:35.319025 082  I --- 21:057565 02:250677 --:------ 4E15 002 0002  # {'_flags': [0, 0, 0, 0, 0, 0, 1, 0], 'state': 'heating', 'is_dhw_ing': False}  # ch_active (heat_active)
2022-08-21T02:07:11.017807 065  I --- 21:064743 02:250708 --:------ 4E15 002 0004  # {'_flags': [0, 0, 0, 0, 0, 1, 0, 0], 'state': 'is_idle', 'is_dhw_ing': True }  # DHWing
2022-08-21T15:00:21.012129 045  I --- 21:033160 02:250704 --:------ 4E15 002 0005  # {'_flags': [0, 0, 0, 0, 0, 1, 0, 1], 'state': 'cooling', 'is_dhw_ing': True }  # cool_active *and* DHWing
2022-08-21T15:00:21.012129 045  I --- 21:033160 02:250704 --:------ 4E15 002 0006  # {'_flags': [0, 0, 0, 0, 0, 1, 0, 1], 'state': 'heating', 'is_dhw_ing': True }  # contrived: ch_active *and* DHWing

... but I think I'll go with:

2022-08-21T19:00:33.119082 ...  I --- 21:034158 02:250676 --:------ 4E15 002 0000  # {'_flags': [0, 0, 0, 0, 0, 0, 0, 0], 'is_cooling': False, 'is_heating': False, 'is_dhw_ing': False}
2022-08-21T02:07:53.248113 ...  I --- 21:064743 02:250708 --:------ 4E15 002 0001  # {'_flags': [0, 0, 0, 0, 0, 0, 0, 1], 'is_cooling': True,  'is_heating': False, 'is_dhw_ing': False}
2023-03-19T12:05:35.319025 ...  I --- 21:057565 02:250677 --:------ 4E15 002 0002  # {'_flags': [0, 0, 0, 0, 0, 0, 1, 0], 'is_cooling': False, 'is_heating': True,  'is_dhw_ing': False}
2022-08-21T02:07:11.017807 ...  I --- 21:064743 02:250708 --:------ 4E15 002 0004  # {'_flags': [0, 0, 0, 0, 0, 1, 0, 0], 'is_cooling': False, 'is_heating': False, 'is_dhw_ing': True }
2022-08-21T15:00:21.012129 ...  I --- 21:033160 02:250704 --:------ 4E15 002 0005  # {'_flags': [0, 0, 0, 0, 0, 1, 0, 1], 'is_cooling': True,  'is_heating': False, 'is_dhw_ing': True }
2022-08-21T15:00:21.012129 ...  I --- 21:033160 02:250704 --:------ 4E15 002 0006  # {'_flags': [0, 0, 0, 0, 0, 1, 1, 0], 'is_cooling': False, 'is_heating': True,  'is_dhw_ing': True }  # contrived: ch_active *and* DHWing

Any thoughts before I push the button? Can you confirm the payload - especially of the latter?

[tomkooij]

@tomkooij Regarding 4E15, I was thinking about:

NOTE: has been edited

2022-08-21T19:00:33.119082 072  I --- 21:034158 02:250676 --:------ 4E15 002 0000  # {'_flags': [0, 0, 0, 0, 0, 0, 0, 0], 'state': 'is_idle', 'is_dhw_ing': False}  # idle
2022-08-21T02:07:53.248113 064  I --- 21:064743 02:250708 --:------ 4E15 002 0001  # {'_flags': [0, 0, 0, 0, 0, 0, 0, 1], 'state': 'cooling', 'is_dhw_ing': False}  # cool_active
2023-03-19T12:05:35.319025 082  I --- 21:057565 02:250677 --:------ 4E15 002 0002  # {'_flags': [0, 0, 0, 0, 0, 0, 1, 0], 'state': 'heating', 'is_dhw_ing': False}  # ch_active (heat_active)
2022-08-21T02:07:11.017807 065  I --- 21:064743 02:250708 --:------ 4E15 002 0004  # {'_flags': [0, 0, 0, 0, 0, 1, 0, 0], 'state': 'is_idle', 'is_dhw_ing': True }  # DHWing
2022-08-21T15:00:21.012129 045  I --- 21:033160 02:250704 --:------ 4E15 002 0005  # {'_flags': [0, 0, 0, 0, 0, 1, 0, 1], 'state': 'cooling', 'is_dhw_ing': True }  # cool_active *and* DHWing
2022-08-21T15:00:21.012129 045  I --- 21:033160 02:250704 --:------ 4E15 002 0006  # {'_flags': [0, 0, 0, 0, 0, 1, 0, 1], 'state': 'heating', 'is_dhw_ing': True }  # contrived: ch_active *and* DHWing

... but I think I'll go with:

2022-08-21T19:00:33.119082 ...  I --- 21:034158 02:250676 --:------ 4E15 002 0000  # {'_flags': [0, 0, 0, 0, 0, 0, 0, 0], 'is_cooling': False, 'is_heating': False, 'is_dhw_ing': False}
2022-08-21T02:07:53.248113 ...  I --- 21:064743 02:250708 --:------ 4E15 002 0001  # {'_flags': [0, 0, 0, 0, 0, 0, 0, 1], 'is_cooling': True,  'is_heating': False, 'is_dhw_ing': False}
2023-03-19T12:05:35.319025 ...  I --- 21:057565 02:250677 --:------ 4E15 002 0002  # {'_flags': [0, 0, 0, 0, 0, 0, 1, 0], 'is_cooling': False, 'is_heating': True,  'is_dhw_ing': False}
2022-08-21T02:07:11.017807 ...  I --- 21:064743 02:250708 --:------ 4E15 002 0004  # {'_flags': [0, 0, 0, 0, 0, 1, 0, 0], 'is_cooling': False, 'is_heating': False, 'is_dhw_ing': True }
2022-08-21T15:00:21.012129 ...  I --- 21:033160 02:250704 --:------ 4E15 002 0005  # {'_flags': [0, 0, 0, 0, 0, 1, 0, 1], 'is_cooling': True,  'is_heating': False, 'is_dhw_ing': True }
2022-08-21T15:00:21.012129 ...  I --- 21:033160 02:250704 --:------ 4E15 002 0006  # {'_flags': [0, 0, 0, 0, 0, 1, 1, 0], 'is_cooling': False, 'is_heating': True,  'is_dhw_ing': True }  # contrived: ch_active *and* DHWing

Any thoughts before I push the button? Can you confirm the payload - especially of the latter?

4e15 it is the mode the WPU is in. it is either heating or cooling or dhw. It cannot do heating and dhw at the same time. Technically cooling and DHW might be possible aa cooling does not require the compressor to run.

So best go with the second option to leave everything open.

Payloads are correct although I have not seen 5 and 6.

[zxdavb]

@tomkooij Can you check/confirm the following:

We have (largely) merged the (equivalent of the) changes in:

• ramses_rf/protocol/const.py
• ramses_rf/protocol/parsers.py
• ramses_rf/protocol/ramses.py

Parser tests have been added/tweaked.

We still need to check/resolve:

• 01FF: ???
• 22C9: zone_idx or ufh_idx for Spider (it is ufh_idx for evohome)
• 22D0: ???
• 3110: I think should be action and not mode
• 3120: everything, incl. adding code_3120.log
• 3EF0: ???
• 4E01: tidy up ramses.py & parser
• 4E0D: issues with the meta-parser for idx
• 4E15: ???
• 4E16: add tests

[tomkooij]

01FF I don't think I have 01FF packets in my log.

22C9 has zone_idx it is the unique number of room with thermostat. So that should be a zone.

22D0 is difficult: UFC send this I message all the time: I --- 02:250704 --:------ 02:250704 22D0 004 00010000 However it is only sent my master UFC. The upstairs slave UFC never sends this.

The master thermostat (connected to the WPU, i.e. the "controller") send this to the UFC master:

2023-04-05T07:22:46.515060 037  W --- 21:033160 02:250704 --:------ 22D0 008 0304001E14030020
2023-04-05T07:22:46.573032 056  I --- 02:250704 21:033160 --:------ 22D0 004 03010000

It is certainly some kind of status message, only the cool-mode bit ('payload[2:4] & 0x10') is known, but already in the parser:

heating 22D0 008 0304001E14030020
cooling 22D0 008 0314001E14030020

(end of 22D0)

3110 mode or action... It should be mode, because the actual status "action" is not in this message. Only 4E15 has the actual action, the state the heatpump is in.

3120 no new information. I see no relation to heating/cooling or whatever.

3EF0 I will work on this. I certainly should be able to decode this. WIP.

4E02 has mode: heat while 3110 (and everything else?) has mode: heating.

4E15 works fine: The name of this message could be heatpump_state (As it is a message sent by the master thermostat that relays the state of the heatpump to the UFC)

Thanks again for all the work! I'll try to figure out 3EF0

[tomkooij]

My bad, but I guess 3ef0 is already well known and parsed. I checked the output against the behaviour of the system today: works fine.