Trouble with setting 'humidifierFunction' 'properties/set'

[aftertommy]

I have a Daikin うるさらx, which features a humidifier mode. In echonet lite, the humidifier mode is represented as:

{
    "operationStatus":"true", 
    "operationMode":"circulation", 
    "humidifierFunction":"on"
}

I've created a MQTT humidifier to control just the humidifier function:

    - name: "Master Bedroom Humidifier"
      unique_id: "master_bedroom_humidifier"
      device:
        manufacturer: DAIKIN INDUSTRIES,LTD
        hw_version: 010c0100
        identifiers: [master_bedroom_humidifier]
        suggested_area: Master Bedroom
        name: "Master Bedroom Humidifier"
      icon: mdi:air-humidifier
      device_class: "humidifier"
      min_humidity: 50
      max_humidity: 60
      qos: 1
      state_topic: "echonetlite2mqtt/elapi/v2/devices/master_bedroom_ac/properties"
      state_value_template: >-
        {% if value_json.operationStatus == 'false' %}
          OFF
        {% elif value_json.operationMode != 'circulation' %}
          OFF
        {% elif value_json.humidifierFunction == 'on' %}
          ON
        {% else %}
          OFF
        {% endif %}
      command_topic: "echonetlite2mqtt/elapi/v2/devices/master_bedroom_ac/properties/set"
      command_template: >-
        {% if value == 'ON' %}
            {"operationStatus":"true", "operationMode":"circulation", "humidifierFunction":"on"}
        {% else %}
            {"operationStatus":"false"}
        {% endif %}
      target_humidity_state_topic: "echonetlite2mqtt/elapi/v2/devices/master_bedroom_ac/properties"
      target_humidity_state_template: >-
        {{ ((value_json.humidificationLevel + 7) * 5) }}
      target_humidity_command_topic: "echonetlite2mqtt/elapi/v2/devices/master_bedroom_ac/properties/set"
      target_humidity_command_template: >-
        { "humidificationLevel":"{{ ((value / 5) - 7) | round }}" }

This gets represented as a switch with a humidity slider in HA:

The problem is that sometimes, flipping the switch to ON doesn't work. I can verify that the MQTT properties are being set:

11405   2023-03-27 20:48:09 [MQTT] prop changed: master_bedroom_ac humidifierFunction on
11404   2023-03-27 20:48:09 [MQTT] prop changed: master_bedroom_ac operationMode circulation
11403   2023-03-27 20:48:09 [MQTT] prop changed: master_bedroom_ac operationStatus true

But it looks like maybe the AC is sometimes not applying the humidifierFunction successfully:

11408   2023-03-27 20:48:10 [ECHONETLite] prop changed: master_bedroom_ac airFlowLevel auto
11407   2023-03-27 20:48:10 [ECHONETLite] prop changed: master_bedroom_ac operationMode circulation
11406   2023-03-27 20:48:10 [ECHONETLite] prop changed: master_bedroom_ac operationStatus true

I believe if operationMode isn't set to circulation first, then humidifierFunction can't turn to on.

If I had to guess, the AC isn't applying multiple echonetlite properties atomically. It's probably just applying each in a random order, so if it attempts to apply humidifierFunction before applying operationMode, it fails to do so. This causes the above MQTT Humidifier's switch to evaluate to off.

I'm not exactly sure how to solve this via just the current echonetlite2mqtt. It seems like I might have to write an automation that listens for a custom topic, then does a sequence of property sets on the unit.

Here are my logs:

echonetlite2mqtt_logs_internalsStatus-4.zip

[banban525]

This is a difficult issue.

This is probably due to the internal behavior of the air conditioner.

ECHONETLite2MQTT sends the received commands in order at regular intervals (default 100ms). The air conditioner may take more than 100 ms to change operating modes.

In addition, ECHONET Lite2MQTT receives the changed state after sending all commands. So it is normal for the state change log to be 1 second later.

Coincidentally, I also have a Daikin うるさらX, so I'll try it out.

[banban525]

I sent the following payload to my air conditioner. I tried 5 times and all worked fine.

{"operationStatus":"true", "operationMode":"circulation", "humidifierFunction":"on"}

I noticed there is no "humidifierFunction off" in your log. ECHONETLite2MQTT does not output logs if properties do not change.

"humidifierFunction" may be "on" even when your air conditioner is turned off.

Alternatively, the air conditioner may not notify the change of "humidifierFunction". In this case, ECHONETLite2MQTT keeps "humidifierFunction" "on".

You should check the "humidifierFunction" on ECHONETLite2MQTT Web UI or Daikin APP.

[aftertommy]

Thank you for trying it out. Hm. I certainly changing humidifierFunction between on and off while doing the following:

1. turn on fan_only on the HASS ac device (which sets operationStatus:true and operationMode:circulation)
2. turn on the humidifier on the humidifier device (for the same physical hardware -- this sets operationStatus:true, operationMode:circulation, humidifierFunction:on)

I may not have caught it in these logs, though. When you tried, did you do it via HA or just via MQTT?

[banban525]

I only sent MQTT commands. I didn't make a humidifier for HA.

But your humidifier idea in HA is a good one. I will try to make it later.

[aftertommy]

I’ve got a new setup where the MQTT HVAC sets it’s mode to a fake topic ([device]/virtual/mode/set), then there’s an automation that subscribes to that and sets the operationStatus and operationMode, then about 200ms sets the humidifierFunction (if necessary). There’s another automation that listens to the standard properties topic, and based on the json publishes to another fake topic ([device]/virtual/mode). The MQTT HVAC and Humidifier subscribe to this topic to show their mode. This seems to work a little bit better, but there are still times where the humidiferFunction seems to get dropped on the floor. It happens less, but still happens. I’ll try to get logs once I can repro again. iPhoneから送信2023/03/30 16:16、banban @.***>のメール: I only sent MQTT commands. I didn't make a humidifier for HA. But your humidifier idea in HA is a good one. I will try to make it later.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[aftertommy]

I was able to reproduce again. AC was off. I then did the following:

1. Turned the Humidifier ON (it turned on)
2. Turned the AC ON to Fan Only
3. Turned the AC OFF
4. Turned the Humidifier ON

You can see that I do send the humidifierFunction:on message, but there's no response from ECHONETLite. You can also see from earlier messages that the AC is in the state of humidifierFunction:off:

2023-03-31 11:19:30 | [MQTT] prop changed: dining_ac humidifierFunction on
2023-03-31 11:19:29 | [ECHONETLite] prop changed: dining_ac operationStatus true
2023-03-31 11:19:29 | [MQTT] prop changed: dining_ac operationMode circulation
2023-03-31 11:19:29 | [MQTT] prop changed: dining_ac operationStatus true
2023-03-31 11:19:14 | [ECHONETLite] prop changed: dining_ac humidifierFunction off

This is with the dining_ac device. This is with the delay in sending the humidifierFunction message (it happens more often without the delay).

echonetlite2mqtt_logs_internalsStatus-6.zip

[banban525]

I can see from your logs that this issue is occurring. But I don't know the cause of this issue.

I made a humidifier in HA. However, this issue did not occur.

There are two possible differences between you and me.

One might be the difference in air conditioner models. My air conditioner is AN-22YRS-W. If your air conditioner is a different model, it may behave differently.

Another one may be the difference in the execution environment of ECHONETLite2MQTT. I run ECHONETLite2MQTT on my desktop PC. If your execution environment is low spec, this issue may occur.

I'll try to come up with a solution this weekend.

[banban525]

I have two questions.

1. When the "humidifierFunction" did not turn on, did you check the internal status of the air conditioner with the Daikin APP or the request function of ECHONETLite2MQTT? The solution depends on whether the air conditioner has not received the "humidifierFunction" command or whether the ECHONETLite2MQTT has not received the "humidifierFunction" status.

2. Did changing "humidifierFunction" 200ms after changing "operationStatus" and "operationMode" work correctly?

I am thinking of one solution. This issue may be resolved if ECHONETLite2MQTT checks the status 1 second after sending the command and retries sending the command if necessary.

[aftertommy]

Thanks for looking into it. I have a number of different models from the same year — AN71YRBKP-W, AN25YRBKPS-W, and some others. It seems to happen across all of them.

I’ve got this hosted on a Raspberry Pi 4 with 8GB RAM. It doesn’t look like my CPU or memory are pegged with this running, for whatever it’s worth.

I really can’t thank you enough for all of your help with these. It really means a lot.

[aftertommy]

1. I checked the logs of ECHONETLite2MQTT. I did not think of checking the app — lemme try.
2. It still seems to happen sometimes?

[aftertommy]

I just turned on the humidifier, and the Daikin app showed it was humidifying. Then I turned on the AC to cooling, but the app showed it was still in humidifying. I then checked with the ECHONETLite2MQTT logs and confirmed that it sees the MQTT request, but the ECHONETLite properties don’t update.

[banban525]

My Daikin APP required a reload to see the current state. If you haven't reloaded, try it.

and... Since the Raspberry Pi has lower specs than the PC, it may have malfunctioned. I have one blank Raspberry Pi 4 so I can test it. But I want to try the command's retry function first.

[banban525]

@aftertommy

Sorry for the late reply.

I prototyped a feature that holds a property for a period of time. This is an unofficial feature. By publishing the following JSON, ECHONETLite2MQTT will continue to retry for 5 seconds.

{"operationStatus":"true", "operationMode":"circulation", "humidifierFunction":"on", "echonetlite2mqtt.hold":{"holdTime":5 "checkInterval":1}}

Properties are:

• holdTime: Time to hold the property (unit: seconds)
• checkInterval: Interval to check properties (unit: seconds) (default: 1)

Give it a try as it may fix your problem.

If you're running with docker, use the 'master' tag. If you're running node.js, clone the "master" branch.

[aftertommy]

Thanks! I would love to try it. Right now I have a custom dockerfile that curls the latest release:

RUN \
    curl -sSLf https://github.com/banban525/echonetlite2mqtt/archive/refs/tags/v2.2.0.tar.gz | tar xvz --strip-components 1

Would be at all possible to tag a release as a prototype or something? If not, I'll figure out how to change around my docker file.

[banban525]

I didn't mean to make a tag. Because this feature is still unofficial.

It looks like what you need is a tag.

I created a tag "v2.3.0-alpha".

[aftertommy]

Thank you! I'm sorry for the late reply -- I've been out for a bit and am now trying it out.

[aftertommy]

I upgraded to the alpha tag (thank you!) and gave it a shot, but it doesn't appear to be working. What's strange is that while I can confirm the MQTT topic is being updated, there doesn't appear to be any logs in ECHONETLite2MQTT.

Here's a value I've been setting on topic echonetlite2mqtt/elapi/v2/devices/living_ac/properties/set:

{"operationStatus":"true","operationMode":"auto","humidifierFunction":"off","echonetlite2mqtt.hold":{"holdTime":5 "checkInterval":1}}

MQTT Explorer confirms this is being set, but nothing appears to be happening. I've attached logs.

Thank you again for your help and I apologize for the delay.

echonetlite2mqtt_logs_internalsStatus-7.zip

[banban525]

I think your command, your topic and your version are correct. But there is no record received from MQTT in the log.

I don't know what causes this problem.

Just in case, I will deploy "v2.3.0-alpha" to my environment and test it.

[banban525]

I deployed "v2.3.0-alpha" to my environment and it worked fine.

I don't know why your ECHONETLIte2MQTT didn't work. I think there is a problem with your environment.

Could you please rebuild ECHONETLIte2MQTT or restart ECHONETLIte2MQTT and see if the issue is resolved?

[aftertommy]

I'm pretty sure this is a local issue. Thank you!