Support for ducted units with Zones

[andybotting]

I've just had a 16kW ducted unit installed which is zoned with actuators. I've got a Wemos D1 mini with this project running on it and it works great, minus the support for zones.

I've also got the official WiFi adapter, and I am able to use EchoNet (local) but it also lacks zone support. I can use MelView (AU) which does work with zones, but I'd love to see proper zone support for an local solution that doesn't depend on the cloud.

There's not much info around for zone support that I've found except for this one comment that looked promising.

SwiCago/HeatPump#39 (comment)

Just wondering if this looks like something that could be added to the current codebase without too much work? With a bit of guidance, I could try and throw something together to see if it works.

[samphonic]

Hey there, sorry for so long without a response, other stuff has pulled my attention away from this project for a while.

The information in that thread does seem to suggest that zone support can be added without too much trouble.

As I said, I'm a bit involved in other projects at the moment, but if you're willing to take a stab at it yourself, the basic steps would be something like:

Alright, actually as I was typing these out, there's a lot of pieces. It's not super difficult because there are lots of examples of how stuff works from the existing packets, but there's still a lot of moving pieces. So I think a better place to start would be to just work on getting the zone state to start with, and then move on to setting it and HA integration later.

So to start with, to read the state, you'll need to.

• Branch from dev
• Add the new packet type byte here.
• Add GetRequest and GetResponse classes for the packet to this file.
• Insert process_packet declarations after this line. You'll need to still do both Request and Response here so that Requests forwarded from a theoretical MHK2 or Kumo are sent along properly.
• In this file, add an implementation of to_string() for at least the Response packet. This is also where you'd eventually implement stuff like set_zone_number(...) or get_zone_active(...) when you need it later.

Now, in theory, you'll be able to see the current state of the zones (as formatted by your to_string() function) in your logs. You might need to turn on verbose logging like this

logger:
  level: VERBOSE
  logs:
    sensor: WARN

However the heat pump will only generate packets if they've been requested, so you'll also have to ask the heat pump for the zone info. For that you'll need to add your GetZoneRequest packet here. Something like

 hp_bridge_.send_packet(GetZoneRequest::get_instance(zoneNumber));

maybe? I haven't fully dug into the composition of those packets.

---

If all that works, then you'll at least be sending something to (and hopefully getting something back from) the heat pump that will be visible in the logs, and that'll make any additional small tweaks easier to work out.

I'm sorry I don't have the time now to do this myself, but it would also be very tricky since I don't have a zoned system on which to test. I'm more than happy to help with any sticky parts along the way though via this issue as I have time.

---

Basically after you're seeing the info in the logs, the high-level next steps are:

• Add "switches" to the ESPHome component to act as the zone status/control in Home Assistant, and update them accordingly when packets are received.
• Handle the switches being flipped in HA by generating a SetZoneRequest packet and sending it. This basically has all the same steps as above but for the Set packet instead.

[andybotting]

Hi @Sammy1Am - thanks a lot for your reply.

I had a go last week of putting something together, and quickly realised that there is actually lots of things that need to be added. I think it basically follows along with that you've mentioned, except I branched from edge.

andybotting@dab2f29

It doesn't work yet, but I haven't had time to look at why. If you have time, I'd love if you could have a look and just see if there's any obvious issues.

I had some issue with my esp8266 with my code when I enabled verbose logging, so I was in the process of setting up an esp32 instead, but I must have had the serial config wrong - got no response from the unit. This week I hope to have a look and try and get the verbose logging working.

[samphonic]

except I branched from edge

😬

That's going to make things difficult.[1] I'll take a look, but as annoying as it'll be, you should definitely use dev instead. Sorry about the confusion.

Took a quick look at the code:

• I misunderstood the thread you sent when they said the packet "type" was 0x15, and that's actually the "command" which you did correctly. My instructions are a little wrong now, but it seems like you figured all that out anyway :)
• Probably long-term it'll be better to define the zones in the ESPHome config file (like defining temperature sources) so that we're not limited to an arbitrary number / hard-coding names. No reason it would cause things to not work though, and can always be changed later.

It's hard to diagnose without seeing packet logs, but I suspect what's missing is adding your packet after this line so that the controller will request the zones from the heat pump (the heat pump will never send anything on its own).

I had some issue with my esp8266 with my code when I enabled verbose logging, so I was in the process of setting up an esp32 instead, but I must have had the serial config wrong - got no response from the unit.

The ESP8266 logging can be touchy because it only has two UARTs and the MITP code can use one of them for the thermostat, but this conflicts with its normal logging abilities. ESP32 should be okay, but the pin assignments are different, and sometimes weird stuff can happen because of strapping pins. This example config works on an ESP32-C3, but that might be a different board that what you're using.

[1] There's a whole backstory with the ESPHome project, but basically they have new rules about how the components are structured and the whole thing needed to be rebuilt so it meets these guidelines (e.g. you can't actually reference the Switch class in your component). It's not totally different from the edge branch, but different enough that merging probably isn't going to happen easily.