-
Notifications
You must be signed in to change notification settings - Fork 5
Document ways of setting purifier, night, circulator modes #13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
This coincides with feedback I have gotten from other users as well. One note is that some people with LN-models that have these features on the remote might not have access to the over CN105. It seems to be tied to either older firmware on the unit and/or older production dates. I am trying to make some sense out of it. |
|
For reference I probably have the latest EU production run units (bought in Greece in June 2025). They notably ship with a feature to pair the included MAC-577IF2-E Wi-Fi adapter directly from the remote. By holding the temp button before powering on you can either set it into AP or WPS mode. So this probably uses a new group code and unit-to-adapter route to make that happen. The unit will also beep until the Wi-Fi adapter reports pairing complete. The adapter itself uses firmware version 40 which is unique as older adapters are not updatable beyond version 37. |
I have the same functionality on a 2024-06 production model. It would be great if you could jump over to this thread and provide those unit capabilities packets/identity commands with your indoor unit model and production month. |
|
Will do. Just as additional context for what I'm talking about here - in EU we are using MelCloud and not Kumo Cloud, but it's really the same thing. I should also add that data can be directly pulled off the Wi-Fi adapter now and set again - entirely locally via the /smart endpoint on the exposed http server. The encryption protocol has recently been broken via the research here: ncaunt/meldec#2 So this is currently how I operate my unit locally from HA after banning the adapter from the cloud, which is why I've been looking to update the existing documentation here, as it's by far the most complete. As the adapters talk the same hex command strings externally, it's quite convenient for cross research. Basically anyone with a recent HVAC can now document data. Older adapters also expose Telnet which allows logging of the set data strings to the unit. For reference my adapter automatically pulls and exposes the following groups: 1A I have not seen documented anywhere, possibly that's related to the new WiFi pairing feature. |
|
That's awesome. I did not know that someone had cracked that one. I am
based in Europe myself and know about the whole Melcloud Home-thing.
There are other undocumented functions/set-packets that have not been
reported to mUART yet. I have some myself that I am testing a bit more
before doing any writing.
…On Wed, 1 Oct 2025, 17:52 Marwin M, ***@***.***> wrote:
*dragonbane0* left a comment (muart-group/muart-group.github.io#13)
<#13 (comment)>
Will do. Just as additional context for what I'm talking about here - in
EU we are using MelCloud and not Kumo Cloud, but it's really the same thing.
I should also add that data can be directly pulled off the Wi-Fi adapter
now and set again - entirely locally via the /smart endpoint on the exposed
http server. The encryption protocol has recently been broken via the
research here: ncaunt/meldec#2 <ncaunt/meldec#2>
So this is currently how I operate my unit locally from HA which is why
I've been looking to update the existing documentation here, as it's by far
the most complete. As the adapters talk the same hex command strings
externally, it's quite convenient for cross research.
For reference my adapter automatically pulls and exposes the following
groups:
02 = Settings
03 = Temps
04 = Error
05 = Timer
06 = Operation State
09 = Run State
1A = Unknown
42 = HVAC Options
1A I have not seen documented anywhere, possibly that's related to the new
WiFi pairing feature.
—
Reply to this email directly, view it on GitHub
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BOE5W4CJRLZ4GRM2OZGCRNT3VP2DRAVCNFSM6AAAAACH74D6IWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNJXGA2TQOJXHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Thanks as always for the contributions and detective work!
This is fascinating because, as you said, this is essentially a unit->adapter control flow (though I suspect that the adapter is actually polling for a flag to determine if it should enter setup-- maybe via that 1A packet?) The 1A packet's existence is documented here but I haven't seen any details other than that it's also generated by Kumo adapters. |
That's 0xA1 although I did wonder if that one is a typo/flip as it's quite similar to 0x1A :P |
PS: Personal testing on my MSZ-LN25VG2W EU unit with ECONO COOL seemingly shows that
0x42 - HVAC Optionsprobably does not track ECONO COOL activation state and it's not replacing the CIRCULATOR mode/byte I don't have. I did not try setting the CIRCULATOR byte yet in0x08 - Set Run Stateto see if it has any effect, hence I kept the note intact for now. Purifier and Night Mode works as expected