experimental implementation of fan control including 'Auto'

[absalom-muc]

Just uploaded a new version v2.6R1 with an experimental implementation of the fan control including 'Auto'. It is based on testing with the WF-RAC.

The implementation of the new fan control is not final, it is for your testing only. The original fan control is still available, and I expect no side effects. However, I don't recommend this version for productive use.

In addtion to the MQTT topics described here the topic Fan2 is supported by the new fan control implementation:

topic	r/w	value	comment
Fan2	r/w	"1", "2", "3", "4", "Auto", "1-IR", "2-IR", "3-IR", "4-IR", "Auto-IR", "n?"	Fan level

Only the values "1", "2", "3", "4", "Auto" can be written. When you receive these values then you have controlled the fan via MHI-AC-Ctrl. You should see the values "1-IR", "2-IR", "3-IR", "4-IR", "Auto-IR" when you use the infrared remote control and not MHI-AC-Ctrl. The format "n?" is for debugging purposes. If you see it, please inform me with a description of the history.

This implementation works for me, Please try it with your MHI-AC. For the testing please don't mix the usage of the old/new fan implementation. Use the MQTT topic Fan or Fan2, but not both. During my tests I had at the beginning the effect that the expected MQTT response "1-IR", "2-IR", "3-IR", "4-IR", "Auto-IR" came only after I used the Fan2 commands. So far I don't understand the effect in detail. If you understand it please give me feedback.

In general I would appreciate your feedback if the new fan implementation works for you.

note: Since my AC doesn't support vanes left/right and 3D I can't test the way how WF-RAC controls it, unfortunatelly.

[DYLaKo]

Awesome!

I managed to get my hands on a WF-RAC, so after the holidays I will connect it and try to capture the vanes left/right and 3D auto.

[Aesculapius]

I've tried it on one of the units. One thing I found with the HomeAssistant integration, is that the default payload for Auto-mode isn't accepted for fan Auto-mode. I'm using lower-case modes with HomeAsssitant. I've edited MAHI-AC-Ctrl.h to set all payloads to lower-case ("auto"). But still the mode is only set correctly if I set MHI-AC-Ctrl/Set/Fan2 to "Auto" (capital A).

When I do that with MQTT Explorer, the mode seems to be set correctly.

It's actually quite minor as I seem to be able to reconfigure HA to just accept capital Auto..

[mjszwo]

I also tried v2.6R1 and I can confirm what Aesculapius said.

Awesome!

I managed to get my hands on a WF-RAC, so after the holidays I will connect it and try to capture the vanes left/right and 3D auto.

Can't wait. At this point the left/right vanes reset to neutral/forwards when I change the vertical vanes, which is quite inconvenient.

[niclet]

I have bought a WF-RAC for my SRK35ZMX-S Unfortunately, even if options are available in the app, it doesn't change anything on the AC itself, and they revert automatically to previous values in the app. I'm afraid that if the IR remote doesn't trigger anything on your CNS connector today (as it was the case on mine), it will never work through CNS. It is probably available only for recent models or future models only :-(

[absalom-muc]

I've tried it on one of the units. One thing I found with the HomeAssistant integration, is that the default payload for Auto-mode isn't accepted for fan Auto-mode. I'm using lower-case modes with HomeAsssitant. I've edited MAHI-AC-Ctrl.h to set all payloads to lower-case ("auto"). But still the mode is only set correctly if I set MHI-AC-Ctrl/Set/Fan2 to "Auto" (capital A).

When I do that with MQTT Explorer, the mode seems to be set correctly.

It's actually quite minor as I seem to be able to reconfigure HA to just accept capital Auto..

Fan mode "Auto" is currently hard-coded in MHI-AC-Ctrl.ino. I'll fix it in the next version. For your testing you could replace if (strcmp_P((char*)payload, "Auto") == 0) by if (strcmp_P((char*)payload, "auto") == 0)

[absalom-muc]

I have bought a WF-RAC for my SRK35ZMX-S Unfortunately, even if options are available in the app, it doesn't change anything on the AC itself, and they revert automatically to previous values in the app.

I believe it is a bug of your WF-RAC, at least the basic settings should work (mode, set temp etc.). If you can't exchange it, you could check it by using WF-RAC in parallel to MHI-AC-Trace.

[niclet]

I have bought a WF-RAC for my SRK35ZMX-S Unfortunately, even if options are available in the app, it doesn't change anything on the AC itself, and they revert automatically to previous values in the app.

I believe it is a bug of your WF-RAC, at least the basic settings should work (mode, set temp etc.). If you can't exchange it, you could check it by using WF-RAC in parallel to MHI-AC-Trace.

Sorry for misunderstanding. All usual settings are working correctly. I was speaking about « auto » and « 3D »

[absalom-muc]

I have bought a WF-RAC for my SRK35ZMX-S Unfortunately, even if options are available in the app, it doesn't change anything on the AC itself, and they revert automatically to previous values in the app.

I believe it is a bug of your WF-RAC, at least the basic settings should work (mode, set temp etc.). If you can't exchange it, you could check it by using WF-RAC in parallel to MHI-AC-Trace.

Sorry for misunderstanding. All usual settings are working correctly. I was speaking about « auto » and « 3D »

Ah, o.k. Thanks for clarification. I see the same effect for "vanes left/right" and "3D". Is it really "fan auto" which doesn't work for your AC?

[kARTechnology]

Will test fan LR and 3d auto..i have a unit that supports outdoor silent(it caps outdoor compressor speed to 40%) any idea about this?

[absalom-muc]

Just updated to v2.6R2 with (planned) final implementation of Fan "Auto". Please consider that there is a new constant for it in MHI-AC-Ctrl.h #define PAYLOAD_FAN_AUTO "Auto" Might be relevant especially for HomeAssistant user.

[kARTechnology]

Will test fan LR and 3d auto..i have a unit that supports outdoor silent(it caps outdoor compressor speed to 40%) any idea about this?

any update on this?

[DYLaKo]

I can't get 2.62 working on home assistant somehow something changed. I see the mqtt mesages in explorer. But HA down't accept them anymore. If i flash back to 2.52 it works again.

Can you share a screenshot of your MQTT messages in MQTT Explorer when using version 2.62 and 2.52?

[rwijnhov]

To get 2.6r2 to work in HA I Changed the MQTT 'PAYLOAD_MODE' in MHI-AC-Ctrl.h:

Auto -> auto Stop -> stop Dry -> dry Cool -> cool Fan -> fan_only Heat -> heat

[glsf91]

Is this experimental implementation of fan control removed from v2.6r2 again ? If yes, why ?

I also see now only fan1,2,3. No 4 and no auto when changing fan with IR I have a SRK35-ZS-W

[absalom-muc]

The experimental implementation was replaced by the final implementation, please check Version.md.

I also see now only fan1,2,3. No 4 and no auto when changing fan with IR

Where do you see/miss something? Have you checked the log file?

[glsf91]

Where do you see/miss something? Have you checked the log file?

When changing the fan with de remote control I see in MQTT explorer only Fan with the values 1,2 or 3. I don't see Fan=4 or Fan=auto.

I have to hookup my computer for the logfile. I will do that soon.

[glsf91]

When increasing fan speed I see in the log:

16:33:54.481 -> status=66 topic=Fan payload=2
16:33:56.825 -> status=135 topic=THI-R1 payload=42
16:34:00.802 -> status=134 topic=IU-FANSPEED payload=4
16:34:05.766 -> status=66 topic=Fan payload=3
16:34:06.816 -> status=133 topic=THO-R1 payload=-1
16:34:08.835 -> status=141 topic=COMP payload=56.00
16:34:14.804 -> status=142 topic=CT payload=3.29
16:34:16.811 -> status=144 topic=TDSH payload=33
16:34:17.857 -> mhi_ac_ctrl_core.loop error: -4
16:34:26.875 -> mhi_ac_ctrl_core.loop error: -4
16:34:26.875 -> status=147 topic=OU-EEV1 payload=141
16:34:36.825 -> status=135 topic=THI-R1 payload=44
16:34:40.800 -> status=134 topic=IU-FANSPEED payload=6
16:34:56.800 -> status=144 topic=TDSH payload=33
16:34:59.397 -> mhi_ac_ctrl_core.loop error: -4
16:35:06.841 -> status=147 topic=OU-EEV1 payload=140
16:35:08.305 -> mhi_ac_ctrl_core.loop error: -4
16:35:16.799 -> status=135 topic=THI-R1 payload=43
16:35:18.834 -> status=136 topic=THI-R2 payload=50
16:35:20.822 -> status=134 topic=IU-FANSPEED payload=8

A second after seeing "topic=IU-FANSPEED payload=6", I switched to fan speed 4. Some later you see topic=IU-FANSPEED payload=8 so it is increased. But without seeing "topic=Fan payload=4" Switching to fan Auto, same behaviour.

Hope this helps.

Edit: when sending 4 to the set/Fan topic then the airco fan is changing to 4 and also the Fan topic is showing 4. When I now change the fanspeed with the remote control, the fan topic is indeed showing 1-4 and auto.

Because I don't use any automation, would it be possible to show all fan speeds without sending first to the set/Fan topic ?

edit2: When I reset the wemos it is still working. Power off and on airco (with remote control) also keeps working. When I cut off the power (mains) of the airco the problem comes back.

So Fan = 4 en Auto (with remote control) is not working after power off and power on mains until you set the Fan.

[absalom-muc]

To make sure that my understanding is correct: Once you use set/Fan then it outputs always the right value, also after power off/on. Only when completely removing the power supply of the AC then the switch to '4' via IR-RC is not outputed until you use set/Fan Please confirm (I ask because not sure to understand the difference between "Power off and on airco (with remote control) also keeps working." and "not working after power off and power on mains ")

[glsf91]

Yes, you are correct. Not only 4 is not working but also "Auto". Only fan =1,2,3 is working Power on/power off is indeed button on remote control. "not working after power off and power on mains " is indeed removing 230V (mains) from airco.

[absalom-muc]

o.k. thanks, then I've an idea how to fix it - will be added to my todo list.

[sauermouth]

Just wanting to tell I'm very happy with the addition of being able to set the fan speed to 'Auto'. This makes it possible to set the fan to powerfull at night (higher COP, better warmth distribution) and set it to Auto in the morning.

I can confirm I had the same scenario as @glsf91 regarding Mode 4 and Mode 'Auto' not being published to MQTT when send via IR. The unit handles the commands, but it is just not displaying it on the MQTT topic. Only after I send Mode 4 or Auto manually via script, the IR info is coming through as intended.

Kudo's for this feature 😀

[absalom-muc]

I can confirm I had the same scenario as @glsf91 regarding Mode 4 and Mode 'Auto' not being published to MQTT when send via IR. The unit handles the commands, but it is just not displaying it on the MQTT topic. Only after I send Mode 4 or Auto manually via script, the IR info is coming through as intended.

Is it necessary to send Mode 4 or Auto via MHI-AC-Ctrl or is it sufficient to send any Fan mode via MHI-AC-Ctrl ? Thank you.

[glsf91]

What I observed: After toggling 230V my Fan was 3 in the topic (same as shown on remote). When sending 3 again to set/Fan, 4 and Auto (by remote) was still not working. Then I send 4 to set/Fan and it starts working. I did some more tests: Fan was auto on remote and Fan topic before toggling 230V. After toggling 230V fan=3 was shown. When sending set/Fan = 1, 2 or 3, auto and 4 was still not working. When sending Auto, it starts working again.

So sending only 4 or Auto will start it working again.

[absalom-muc]

I believe setting fan Auto after reset is an appropriate work around, please add mhi_ac_ctrl_core.set_fan(7); // set fan AUTO to the end of the setup function. Please check it.

[glsf91]

This is indeed solving the problem. What I did: AC was running Fan=4. Power off IU with RC power off button. Power off mains (230V) and power on mains again, Fan becomes (in MQTT) 3 and 1 sec later Auto (IU is still off). When then power on IU with the RC button, then the Fan will became the same fanspeed (=4) as on the remote. So this is working fine.

But it has some side effects:

• when the eps reboots (or reset) the Fan will always go to Auto
• when power on the IU with the set/Power instead of the RC, the Fan will always go to Auto (of course this is only the case when this is the first power on after the mains was disconnected)

I think the first drawback is more worse then the problem.

[absalom-muc]

Thank you for your testing. Then we leave it as it is until we have a better idea.

[glsf91]

I was just thinking: What can be done is setting the Fan to Auto only with the following conditions:

• power status of AC must be Off
• this is the first power status after the initial status_power_old = 0xff

This means it cannot be done in the setup() but has to be done only the first time when status_power_old is not 0xff anymore. mhi_ac_ctrl_core.loop(80) must run one time successful. Or it can be captured in MQTT_subscribe_callback.

When the the AC is running (power=On) and the ESP resets, the power status will not be Off but On the first time after mhi_ac_ctrl_core.loop(80) was running. So with a running AC the Fan will never be set to Auto. This will solve my first mentioned side effect (which was my biggest problem).

When the AC is not running (Power=Off) and the ESP resets, the power status will be Off the first time after mhi_ac_ctrl_core.loop(80) was running. So the Fan will be set to Auto. When using the RC to switch on the AC, the Fan will be set again to the value on the remote. So no problem. Only when using set/Power to power on the AC, the Fan will be changed to Auto which can be another value then before. On the other hand, when not doing this and the Fan was before Auto or 4, the Fan topic will show the wrong value. Same will be happen when the mains (230V) was cut off and came back again.

I don't know if and how it interferes with using POWERON_WHEN_CHANGING_MODE.

How do you think about this ?

[absalom-muc]

Soundes reasonable for me. When this topic is really annoying you, you could consider storing the status in the EEPROM. But it seems that we have very different use cases. In my home MHI-AC-Ctrl is running for months w/o reseting or unpowering the AC. So for me this topic is very minor and I don't plan to invest time for it - sorry.

btw: I'm thinking about quitting my work on MHI-AC-Ctrl due to my job and other hobbies. Would you be interested in adopting MHI-AC-Ctrl here on Github?

[glsf91]

No problem. If I have some time I can try if I can find a nice solution in the code and make a pull request.

That would be very pity if you have to quit. You have done a lot of nice work and a lot of knowledge about this. I have to think about this. Problem is also my time and lack of a lot of knowledge. Doing some small change I can manage. Also I'm not a real programmer. Thanks for offering.

[rwijnhov]

If you need anyone to take over. I am willing to do so. Would be a shame if this project would get lost.

[glsf91]

I have made the solution as described above. I have to test it and then will make a pull request.

[kARTechnology]

Auto Mode working as expected...great progress..... Setting hi-power mode is making fan=3..

[glsf91]

I think we can close this one