mitsubishi2MQTT
mitsubishi2MQTT copied to clipboard
gysmo38
defrosting state
Needed defrosting state information from the pump. So that we can see when Mitsubishi heat pump is in "mad cycle" (=defrosting too often), and possible handle force restarts over home automation.
You can make your own logic by using the MQTT messages to see when the pump is defrost
When the heatpump goes to defrost, the compressor turns off (0hz), but action is still in heating And when defrost is finished, the compressor turns off again, and then on, when it starts heating again.
Example: (compressorFrequency == 0 && action = "heating") = Defrost
@Bobbyhax not a viable solution. All my units do not report compressorFrequency. Also rapid drop in power consumption happens without defrost. There is no way of wild guessing until SwiCago discoveres the missing bit.
@Sprinterfreak I'd love to be able to see defrost mode too. I think the best thing you can do to help someone decode the protocol is to use debug mode, and make a log of raw packets received during a time when you know the compressor is defrosting.
I patched my code like this to allow better debugging. I think the most valuable information would be a packet capture, split by message type like in my PR, over a period of time when you know the compressor went from not defrosting, to defrosting, to not defrosting, along with times of when it transitioned.
@Sprinterfreak @mbbush Has anyone considered byte 8 in the return from GET 0x09? On my system (which also doesn't report compressor frequency), this bit is normally zero, but periodically it changes to 2 for a minute or two. When this happens, the indoor fan turns off (which never happens any other time), and the power consumption drops. Soon after, it changes to 6 for 60 seconds, during which the indoor unit's fan comes on again. Then it changes to 4 (which I believe is preheating mode), and then back to zero, at which point the fan returns to normal speed. This sequence happens reliably during conditions you would expect defrost i.e. every few hours in cold and/or cool+humid weather.
That sounds like a promising discovery!
I haven't noticed this on mine, and I'm not currently in a position to check it.
I think you'll get better engagement with ideas like this if you post on the GitHub for the swicago HeatPump library which handles decoding the serial protocol.
Yeah, someone did post about 0x09 byte 8 in the Other Packets issue on SwiCago's repo as you mentioned. Not sure how much traction it got or if it got implemented, but people other than me definitely know about it. :-)
I'm curious too. Also if this bit represents the state of the indoor or outdoor unit as well. Both sides are capable of defrosting. If it is only the indoor unit's "special" state, there must hopefully be a whole (yet undiscovered) info packet containing all outdoor unit states or it really isn't available on multi-split's. Since the communication takes place over the power wires, I guess the bandwidth is fairly limited. There are lots of other parameters the outdoor unit has, such as outdoor temp, compressor freq and so on. Enough to fill an extra packet.
Re. indoor defrosting, would that happen only in summer? My system is new and I haven't had a "summer" yet. So if what I'm seeing is really defrosting, it's probably the outdoor unit.
FWIW, I get what looks like outdoor temp on GET 0x03 byte 10. It's pretty close when the (outdoor) fan is on, but it rises when the fan stops.
I spammed my indoor unit with every GET request between 0x00 and 0x7D, at which point the checksum goes negative. The only responses I got were the widely-known ones. My system has a branch box, and I wonder if that's obscuring some of the more "outdoor oriented" packets like compressor frequency. (The branch box has a CN100, but I haven't played with that yet.)
I know that Mitsu has at least three protocols -- M-Net, MA (two-wire thermostats with power), and whatever is on CN105. On my unit, there are dedicated M-Net wires that connect my branch box to the outside unit and I'm guessing there's more info available there. LenShustek has done some reverse-engineering on that here.
Re. indoor defrosting, would that happen only in summer? My system is new and I haven't had a "summer" yet. So if what I'm seeing is really defrosting, it's probably the outdoor unit.
Maybe. But on my multi-split, byte 0x03 of the 0x09 packet contain different values on each head on the system. They seem to not reflect the state of the outdoor unit. I didn't see defrosting so far because the unit is currently rarely used. Maybe the next days get a little colder. Then I try to watch it again.
It makes sense that the status byte applies to the individual indoor unit being queried as you say. Several modes like standby and preheating will be different across different indoor units (for example if one is calling for heat and another for cooling).
My hypothesis is that in the case of defrost, the indoor unit is saying "My status is 'inactive' because my outdoor unit is defrosting". It would be interesting to see if all indoor units report mode 2 at the same time, even though at other times the values will vary between them.
So indeed verified on multi-split's, all 0x09 byte 6 change to 2 if outdoor unit is defrosting.
mitsubishi2mqtt/HVACSchlZ/debug/packets {"packetRecv":"fc 62 01 30 10 09 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 52 "}
Nice. Did you happen to notice if the same value changed in the sequence 2 --> 6 --> 4 --> 0 as it did on my system? (I have an air handler so maybe different than mini-splits.)
I believe 4 is preheating, since it enters that mode every time the system goes from idle to actively heating (but before the fan speed rises), unrelated to defrosting. Not sure what 6 is. 0 seems to be the "normal" state.
I've not seen 6 so far. How long do you see 6? Guess, it could be purging or wait for valve actuators to be set?
Looking through my logs, it looks like the time for the "6" state varies between 20 and 90 seconds. (I'm only polling every 10s or so, so there's some error there.) I'd imagine that the valves would take a somewhat constant time, but it's possible that it's also waiting for some pressure or temperature to reach a certain value.