Multi-unit support

[BurntBrunch]

I have a brand new and somewhat unorthodox setup: one outdoor MXZ-SM36NAM2-U1, an indoor MSZ-GL09NA and a SVZ-KP30NA. The units are connected through a branch box, not via a CITY-MULTI network.

I installed a D1-form-factor esp32 on the GL09NA mini split and found a couple of interesting things:

1. The esp claimed a FAN mode but the wireless remote for the unit does not support one. I don't think this mini split can do fan only - I don't see how that would work in the service manual. Is there any interest in starting a static database of capabilities, based on data from the manuals? It could be entirely optional but if your model is in it, we'd know for sure what we can do (I saw the discussion re: complete autoconf).

2. I noticed that compressor frequency always read as 0.

I have since removed the device because I want to establish a few things first:

1. What is our understanding of multiple refrigerant addresses systems? Do they just look like a single refrigerant system on the CN105? AFAICT from manuals of the remote controllers, it's the PAR remotes (over the two-wire port) that can access values based on refrigerant address. I haven't seen this in any CN105 manual.

2. Is there any interest in me adding a passive mode that only sniffs packets and broadcasts them over the network? I really wonder if some of the bits that we don't know the meaning of are refrigerant addresses.

[KazWolfe]

The esp claimed a FAN mode but the wireless remote for the unit does not support one.

As of right now, we ship with a default set of mostly-sane capabilities. It's up to the end user to configure their settings appropriately based on what their unit can (or can't) do. You've already found the larger autoconf discussion on this, so I won't go in depth about that.

I also have plans to start a Google Sheets or similar doc over on https://muart-group.github.io/ to track what units support what as part of this project. Model numbers and all will be probably useful eventually.

Re your unit specifically: it seems strange that you don't have a fan-only mode. It might be worth trying to send the command anyways and seeing what happens; sometimes these units do have hidden capabilities. At the very least, they do tend to ignore invalid commands decently well.

I noticed that compressor frequency always read as 0.

I've observed similar with my branch-box unit. Compressor frequencies aren't returned by all units in general, and I currently suspect that the branch box completely discards that information. This is normal, and something we have yet to figure out a way to work around.

What is our understanding of multiple refrigerant addresses systems?

Our current understanding is that CN105 and the IT protocol only support communicating to/talking with the head unit that it connects to. This seems to follow Mitsubishi's service documentation which encourages users to waste their money buy a Kumo Cloud for each unit that is connected.

Compare to, as you pointed out, M-NET, where everything communicates over a single shared network. To my knowledge, nobody has done sufficient work with the M-NET protocol yet, so we don't really know much about it. In theory (at least, according to the service manuals), you should be able to access any head unit from M-NET, but I'm not quite sure how to start digging into all this.

Is there any interest in me adding a passive mode that only sniffs packets and broadcasts them over the network?

Funny you should mention this, as passive mode and sniffing has come up recently. At present, passive mode is only useful for cases where there's a Kumo Cloud or MHK downstream of our ESP. As such, I'd like to consider actually making passive mode a compile-time flag and removing the toggle switch as a user-controllable passive mode toggle has the potential to cause some serious annoyances if we move forward with #30.

[BurntBrunch]

I also have plans to start a Google Sheets or similar doc over on https://muart-group.github.io/ to track what units support what as part of this project. Model numbers and all will be probably useful eventually.

Why not put this in the repo as structured data? Bonus points if we tied it to the build process and convert a model number in the yaml into a set of capabilities?

Also, a lot of this data is extractable automatically from the manuals. I'm sure we can write a prompt for a sufficiently powerful LLM to do the grunt work. Could probably build an authoritative database of function codes too.

Re your unit specifically: it seems strange that you don't have a fan-only mode. It might be worth trying to send the command anyways and seeing what happens; sometimes these units do have hidden capabilities.

I'll try it anyway when I next install it.

I've observed similar with my branch-box unit. Compressor frequencies aren't returned by all units in general, and I currently suspect that the branch box completely discards that information.

Interesting, noted.

Our current understanding is that CN105 and the IT protocol only support communicating to/talking with the head unit that it connects to.

So something like the MAC-334IF therefore creates an M-NET network in front of the IT port, not through it? That seems to align with the system design diagrams in the manual, for what it's worth. Interesting that it requires a refrigerant address to work but I guess that's the MA vs M-NET networks and not something to do with the network through the branch box?

I really wonder if the M-NET network through an adapter like that at least gives you the raw thermistor values of the unit it's connected to.

As such, I'd like to consider actually making passive mode a compile-time flag and removing the toggle switch

I was really mostly thinking about sniffing the traffic if I put one of these adapters in front of the unit. I'm starting to doubt that'd be useful, though.

Runtime toggling is only really useful for development, makes sense to put it behind a build flag imo.

[KazWolfe]

Why not put this in the repo as structured data? Bonus points if we tied it to the build process and convert a model number in the yaml into a set of capabilities?

We could, but at that point I'd prefer to put the energy into autoconf honestly, since that'll be the most authoritative data source we have access to. I'm not opposed to making it structured data either, but that may be a bit complex to maintain overall (since there are a lot of units across all the regions that use CN105).

So something like the MAC-334IF therefore creates an M-NET network in front of the IT port, not through it?

To my understanding, yeah. I don't think it has any ability to see anything not exposed by the IT protocol or talk "behind" the network; or at least I haven't found a way to do this yet.

I did write a script to "scan" one of my units for hidden commands and found only one which we already half-knew about anyways. I'm not really sure how many secrets these devices hold...

I was really mostly thinking about sniffing the traffic if I put one of these adapters in front of the unit. I'm starting to doubt that'd be useful, though.

I don't think it will be as the CN105 port doesn't actually broadcast data. Basically every single packet needs to be requested from the device on the other end and I don't think we've ever seen the heat pump send data unsolicited.

[samphonic]

Hey there! Had my watch setting wrong for this repo and missed this, sorry I didn't respond earlier.

I have a very similar setup actually with an MXZ compressor connected to two MSZ-GL06NA units and an SVZ-KP30NA via a branch-box. I can share a little of what I've discovered:

The esp claimed a FAN mode but the wireless remote for the unit does not support one.

It can do fan-only mode! I learned that there's some weirdness with a branch box where refrigerant will flow through all the units if any of them are calling for e.g. heat. So I will sometimes use fan mode on the wall unit as a sort of heating-light where it will blow warm air when the SVZ is heating, but won't request heat on its own.

I noticed that compressor frequency always read as 0

Yup, same. Even on the SVZ I just get 0, but it sounds like this is common for a lot of people. I'm not sure exactly what it takes to get compressor frequency available, but I too suspect the branch-box is not forwarding that information. Maybe someday if I get time and I'm feeling brave I'll poke around the CN100 connector in the branch box, or see if there's a connector outside on the compressor.

I just finished PR #42 that removes the Active (Passive) Mode Switch 😉 and makes it a compile-time setting. As @KazWolfe said, the communication over the CN105 port seems to strictly require a request sent to the unit before it will send any information; I've never seen any spontaneous activity from the unit itself.

And I can confirm that at least in all of my testing communication is limited to individual units. Would love to tinker with the PAR communication someday too, but that's probably a bigger project than I have time for, haha.