[Daikin] The channel "specialmode" can be read but not modified from OH (both 2.5.12 and 3.1)

I have a Daikin AirConditioner unit with a WiFi control module BRP069B41.
I can control the Indoor unit with the Android App. From openHAB, thanks to the Daikin binding, I can control all the parameters except the specialmode.
I only managed to make openHAB display the specialmode, when modified by the android App (or by the remote control, of course), but openHAB cannot modify it.

I noticed this behavior as I am upgrading to openHAB3 and I wished to implement all available channels on the MainUI. This behaviour occurs in OH3 both with textual configuration and with UI configuration. I then tried also in my OH2.5 installation and I found the same.

Let me start from the OH2.5 configuration which is shorter

Thing definition

daikin:ac_unit:ZonaNotte [ host="192.168.27.25" ] // thing

Working Items

Switch Zn_OnOff "Stato ZonaNotte [%s]" { channel="daikin:ac_unit:ZonaNotte:power" }
String Zn_Mode "Modalità [%s]" { channel="daikin:ac_unit:ZonaNotte:mode" }
Number:Temperature Zn_SetTemp  "Zn SetPoint [%.1f]" {channel="daikin:ac_unit:ZonaNotte:settemp" }
String Zn_Fan_Speed    "Fan Speed[%s]"     { channel="daikin:ac_unit:ZonaNotte:fanspeed" }
String Zn_Fan_Movement "Fan Direction[%s]" { channel="daikin:ac_unit:ZonaNotte:fandir" }

Non working item

String Zn_SpecialMode  "SpecialMode [%s]"  { channel="daikin:ac_unit:ZonaNotte:specialmode" }

I send commands and get states through the sitemap with the mapping options

Selection item=Ms_Mode mappings=["AUTO"="Auto", "DEHUMIDIFIER"="Dehumidifier", "COLD"="Cold", "HEAT"="Heat", "FAN"="Fan"]
                        Setpoint  item=Ms_SetTemp   step=0.5
Selection item=Ms_Fan_Movement mappings=["STOPPED"="Stopped", "VERTICAL"="Vertical", "HORIZONTAL"="Horizontal", "VERTICAL_AND_HORIZONTAL"="Vertical&Horizontal" ]
Selection item=Ms_Fan_Speed mappings=["AUTO"="Auto","SILENCE"="Silent","LEVEL_1"="Level1", "LEVEL_2"="Level2", "LEVEL_3"="Level3", "LEVEL_4"="Level4", "LEVEL_5"="Level5"]
Selection item=Ms_SpecialMode mappings=["OFF"="Off", "STREAMER"="Streamer", "ECO"="Eco", "POWERFUL"="Powerful", "POWERFUL_STREAMER"="Powerful&Streamer", "ECO_STREAMER"="Eco&Streamer"]

Notice that the informations on the specialmode channel of the binding documentation is not correct for my wifi adapter (maybe due to some firmware upgrade? I do not know).
For example, when both options “Powerful” and “Streamer” are actived by the Android App the item Zn_SpecialMode contains the string POWERFUL_STREAMER, while in the docs this is documented as POWERFUL & STREAMER. The same for ECO_STREAMER instead of ECO & STREAMER. I therefore adpated my sitemap to reflect the values that are read by openHAB.

When the options are activated by the Android App, the Selection item in the sitemap is updated, but if I use the selection item to change the options (i.e. selecting off) nothing happens and after a minute the selection item switches back to the original state. This is what I understand from the events.log

2021-08-15 18:18:18.021 [vent.ItemStateChangedEvent] - Ms_SpecialMode changed from ECO to ECO_STREAMER
2021-08-15 18:18:46.199 [ome.event.ItemCommandEvent] - Item 'Ms_SpecialMode' received command OFF
2021-08-15 18:18:46.225 [nt.ItemStatePredictedEvent] - Ms_SpecialMode predicted to become OFF
2021-08-15 18:18:46.264 [vent.ItemStateChangedEvent] - Ms_SpecialMode changed from ECO_STREAMER to OFF
2021-08-15 18:19:18.383 [vent.ItemStateChangedEvent] - Ms_SpecialMode changed from OFF to ECO_STREAMER

The first line reflects the update of the item due to the action of the AndroidApp.
The second,third and fourth lines represent what happens when I select off on the sitemap.
Finally, the last line represents the update of the item by the Daikin binding that reads the state of the daikin controller.

As I said, the same behavior apply in OH3. I am practicing with the UI with textual configuration (I know, it is not recommended, but I’m old style…) but I also stepped back to the UI configuration. In practice, while the other channels (such as fandirection) are recognized and the stateDescription metada is set correctly by the daikin binding, the specialmode channel have an incorrect stateDescription metada

This is a query with the REST API of a working item

{
  "link": "http://oh3:8080/rest/items/DkZn_Fan_Movement",
  "state": "STOPPED",
  "stateDescription": {
    "pattern": "%s",
    "readOnly": false,
    "options": [
      {
        "value": "STOPPED",
        "label": "stopped"
      },
      {
        "value": "VERTICAL",
        "label": "vertical"
      },
      {
        "value": "HORIZONTAL",
        "label": "horizontal"
      },
      {
        "value": "VERTICAL_AND_HORIZONTAL",
        "label": "vertical and horizontal"
      }
    ]
  },
  "commandDescription": {
    "commandOptions": [
      {
        "command": "STOPPED",
        "label": "stopped"
      },
      {
        "command": "VERTICAL",
        "label": "vertical"
      },
      {
        "command": "HORIZONTAL",
        "label": "horizontal"
      },
      {
        "command": "VERTICAL_AND_HORIZONTAL",
        "label": "vertical and horizontal"
      }
    ]
  },
  "editable": false,
  "type": "String",
  "name": "DkZn_Fan_Movement",
  "label": "AC Fan Direction ZonaNotte",
  "tags": [
    "Control"
  ],
  "groupNames": [
    "gEquip_DkZn"
  ]
}

while this is a query for the item linked to the specialmode channel

{
  "link": "http://oh3:8080/rest/items/DkZn_SpecialMode",
  "state": "ECO_STREAMER",
  "stateDescription": {
    "pattern": "%s",
    "readOnly": true,
    "options": []
  },
  "editable": false,
  "type": "String",
  "name": "DkZn_SpecialMode",
  "label": "AC SpecialMode ZonaNotte",
  "tags": [
    "Control"
  ],
  "groupNames": [
    "gEquip_DkZn"
  ]
}

I tried to manually set the metadata stateDescription with the textual configuration (as i am doing for my other textual settings, based on this very informative post ).
The result was similar to OH2.5, the linked item showed changes of the airconditioner mode but did not allow to modify it.

In summary, this seems to be a bug that dates back to openhab2 and which has been ported to OH3 unchanged. Is this information enough to raise an issue or should I add something else?

Thank you for your attention,

Hi all, quick ping on this thread,
I’ve just had a new Daikin ductless system installed, and I’m planning to get it connected to openHAB.
In general, are folks happy with the performance of the current Daikin binding, especially on OH3?
I don’t see a lot of traffic recently on the forum on the Daikin binding, so I’m a bit stuck on whether that means “no news is good news, the binding works great” type of situation, or alternatively “yeesh this doesn’t work well and nobody is using it anymore”?
Thanks for your feedback.

Except for the bug that i documented, the binding works reliably in oh 3.

@Lionello_Marrelli Looking through the code, it appears that only specialmode-powerful can be set (on/off). specialmode itself is / should be a read only channel.

Is setting specialmode-powerful not working for you?

Thank you for looking into this issue.
I have not tested specialmode-powerful yet. I will test in the next days.
I was assuming that specialmode behaviour was similar to fandirection. The horizontal and vertical movements are in fact set separately in the android app and in the remote, while they are set by the openhab channel string simultaneously.
If specialmode-powerful works it means that it should be necessary to implement something like specialmode-eco and specialmode-streamer?

Try contacting @LukasA83 - I believe he was the one who added this feature - I don’t know his username on this forum.

@Lionello_Marrelli I’ve had a look into this mode, and I concluded that the binding should offer these channels instead:

channel desc
specialmode The special mode (OFF, ECO, POWERFUL).
streamer Turns the streamer mode on/off for the air conditioning unit.
  • Streamer can be turned on/off independently of whether eco, or powerful is enabled.
  • Eco and powerful are mutually exclusive. You can only have Eco, or Powerful, but not Eco AND Powerful at the same time - that wouldn’t make sense.

So it makes more sense to split them into two independent channels.

Furthermore, both the channels above should be read/write, so one can change them via the binding.

What do you think?

I can make the changes to the binding. Would you be able to do some tests for me once I’ve made the changes?

@Lionello_Marrelli here’s a jar file to test:

Thank you for your effort. I will be able to test in the weekend

v0.0.2 with a small bug fix in streamer channel

Sorry, but I am unable to find the jar file to copy in the openhab-addon directory: is it available, or should it be built from sources? Unfortunately I do not know how how to build jar files for openhab.

The jar is on that page. Here’s a direct link to download: https://github.com/jimtng/openhab-addons/releases/download/daikin-specialmode-v0.0.2/org.openhab.binding.daikin-3.3.0-SNAPSHOT.jar

1 Like

The test version works as expected.
In detail: I tested the binding and with my test setup, freshly installed openHAB 3.3.0.M1 on my raspberry. Both the specialmode and streamer channels work as expected. I used the UI to create items linked to the channels and I was able to change from normal to eco and to powerful with the first channel and from streamer off to streamer on with the second one.
Moreover, when these options were changed from the android app, the openhab items were updated.

Many thanks you for fixing this issue!
Lionello

PS. I marked as solution the post showing the download link. When the binding will be fixed in the distribution i will probably remove it (if possible)

Thanks for testing and providing a detailed feedback. I have submitted a PR to include the changes:

1 Like

@Lionello_Marrelli can you test whether you are able to change from powerful mode back to normal mode?

@pschlosser reported that changing from powerful to normal isn’t working for him.

@JimT Sorry for not answering earlier. I am using my test system with OH 3.3 release on my raspberry. I installed the standard Daikin binding from the UI. Switching from normal to eco or from normal to powerful actually works, while I can confirm that switching from eco to normal or from powerful to normal DOES NOT work. Switching from eco to powerful and viceversa still works.

I then removed the standard Daikin binding and then used the test one available at this link.
Switching from powerful to normal now works as expected, but switching from eco to normal still does not work. I tried several times to switch from eco to normal. After a while the item value goes back to ECO. So reading is correct but setting the normal value from eco does not work.

In the openhab log I saw one warning line from the daikin binding, but i was not able to reproduce it

 [WARN ] [ing.daikin.internal.DaikinWebTargets] - Error setting special mode. Response: 'ret=ADV NG'

I’m leaving my test system as it is now, if further tests are needed.

@Lionello_Marrelli thanks for testing and reporting the result.

I have a new version to be tested when you’ve got a moment please:

This version sets the spmode_kind to the current spmode_kind (1 for powerful and 2 for eco) when setting set_spmode=0 (i.e. changing to normal).

@JimT After reinstalling the add-on, clearing cache to remove some errors in the openhab log and restarting openhab twice, I can confirm that the change from ECO to normal now works as expected with version 0.0.3

Thanks for testing. PR created to fix this: [daikin] Fix changing specialmode from ECO to NORMAL by jimtng · Pull Request #13230 · openhab/openhab-addons · GitHub