[Daikin] New datapoints for demand control

[Jogobo]

New datapoints have been discovered. Is it possible to add them to the binding?

Demand Control (manual)
http://DAIKIN-IP/aircon/set_demand_control?lpw=&en_demand=1&mode=0&type=1&max_pow=[40-100]

Demand Control (automatic)
http://DAIKIN-IP/aircon/set_demand_control?lpw=&en_demand=1&mode=2&type=1&max_pow=[40-100]

Demand Control (OFF):
http://daikin-ip/aircon/set_demand_control?lpw=&en_demand=0

Demand Control (State):
http://daikin-ip/aircon/get_demand_control?lpw=

More detailed information can be found here 1

[jimtng]

See more details in #17036. In the future please post more info here to keep it all in one issue. Any further information would be helpful to whoever is going to implement this. Alternatively a PR from you would be welcomed too.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/daikin-brp069b4x-new-datapoints/154256/6

[jimtng]

@Jogobo, thanks for the detailed description in #17036
Can you tell me more about scdl_per_day?

[Jogobo]

scdl_per_day seems to be a read-only parameter telling how many scheduled events per day are allowed, as the Onecta app only allows 4 timer events per day.

Please be aware that for disabling demand control it is enough to send en_demand=0, which automatically sets mode=0 and max_pow=100. To set a fixed value, all three values have to be sent like en_demand=1&mode=0&max_pow=<value>. To change mode it seems that en_demand=1 has to be sent as well.

In the Onecta binding mode can have four values: "Auto, Scheduled, Fixed, OFF". The first three are the desired mode values, "OFF" is handled as en_demand=0.

[jimtng]

This is going to create a lot of channels

demandcontrol
demandcontrolmode
demandcontrolmaxpower
demandcontrolmondaycount
demandcontrolmondayenable1
demandcontrolmondaytime1
demandcontrolmondaypower1
demandcontrolmondayenable2
demandcontrolmondaytime2
demandcontrolmondaypower2
demandcontrolmondayenable3
demandcontrolmondaytime3
demandcontrolmondaypower3
demandcontrolmondayenable4
demandcontrolmondaytime4
demandcontrolmondaypower4
demandcontroltuesdaycount
demandcontroltuesdayenable1
demandcontroltuesdaytime1
demandcontroltuesdaypower1
demandcontroltuesdayenable2
demandcontroltuesdaytime2
demandcontroltuesdaypower2
demandcontroltuesdayenable3
demandcontroltuesdaytime3
demandcontroltuesdaypower3
demandcontroltuesdayenable4
demandcontroltuesdaytime4
demandcontroltuesdaypower4
demandcontrolwednesdaycount
demandcontrolwednesdayenable1
demandcontrolwednesdaytime1
demandcontrolwednesdaypower1
demandcontrolwednesdayenable2
demandcontrolwednesdaytime2
demandcontrolwednesdaypower2
demandcontrolwednesdayenable3
demandcontrolwednesdaytime3
demandcontrolwednesdaypower3
demandcontrolwednesdayenable4
demandcontrolwednesdaytime4
demandcontrolwednesdaypower4
demandcontrolthursdaycount
demandcontrolthursdayenable1
demandcontrolthursdaytime1
demandcontrolthursdaypower1
demandcontrolthursdayenable2
demandcontrolthursdaytime2
demandcontrolthursdaypower2
demandcontrolthursdayenable3
demandcontrolthursdaytime3
demandcontrolthursdaypower3
demandcontrolthursdayenable4
demandcontrolthursdaytime4
demandcontrolthursdaypower4
demandcontrolfridaycount
demandcontrolfridayenable1
demandcontrolfridaytime1
demandcontrolfridaypower1
demandcontrolfridayenable2
demandcontrolfridaytime2
demandcontrolfridaypower2
demandcontrolfridayenable3
demandcontrolfridaytime3
demandcontrolfridaypower3
demandcontrolfridayenable4
demandcontrolfridaytime4
demandcontrolfridaypower4
demandcontrolsaturdaycount
demandcontrolsaturdayenable1
demandcontrolsaturdaytime1
demandcontrolsaturdaypower1
demandcontrolsaturdayenable2
demandcontrolsaturdaytime2
demandcontrolsaturdaypower2
demandcontrolsaturdayenable3
demandcontrolsaturdaytime3
demandcontrolsaturdaypower3
demandcontrolsaturdayenable4
demandcontrolsaturdaytime4
demandcontrolsaturdaypower4
demandcontrolsundaycount
demandcontrolsundayenable1
demandcontrolsundaytime1
demandcontrolsundaypower1
demandcontrolsundayenable2
demandcontrolsundaytime2
demandcontrolsundaypower2
demandcontrolsundayenable3
demandcontrolsundaytime3
demandcontrolsundaypower3
demandcontrolsundayenable4
demandcontrolsundaytime4
demandcontrolsundaypower4

Does this look like what you'd expect?

I'm thinking that this should just be one channel containing a json data for all the schedule fields (mondayxxx - sundayxxx).

so:

• demandcontrolenable
• demandcontrolmode
• demandcontrolmaxpower
• demandcontrolschedule (json string containing the daily schedule details)

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/daikin-limiting-power-on-local-api/157181/2

[Jogobo]

To support the whole DemandControl feature, yes.
Personally I am not much interested in the scheduled events as it seems of no big use. Wheather and temperature do not change on a weekly base.

[jimtng]

EDIT: The channels are read-only at the moment. It doesn't yet allow sending a command to the aircon unit.

@Jogobo Please test this jar file. It's a fake .txt file because github doesn't allow uploading a .jar file. Just rename and remove the extension.

org.openhab.binding.daikin-4.3.0-SNAPSHOT.jar.txt

You can see the channels in the MainUI, they are:

demandcontrolenabled - Switch
demandcontrolmode - String (AUTO | MANUAL | SCHEDULED)
demandcontrolmaxpower - Numeric:Dimensionless - intended for percent value
demandcontrolschedule - a JSON string containing the demand control schedule

{
  "monday": [
    {
      "enabled": true,
      "time": 0,
      "power": 100
    },
    {
        "enabled": true,
        "time": 100,
        "power": 50
    }
  ],
  "tuesday": [

  ],
  ...
}

[jimtng]

This version supports setting the demand control:

org.openhab.binding.daikin-4.3.0-SNAPSHOT.jar.txt

[Jogobo]

Enabling demand control does not work. In general setting demand control is picky.

For a fixed value setting must contain "?en_demand=1&mode=0&max_pow="
For "Auto" setting must contain "?en_demand=1&mode=2&max_pow="
For "Scheduled" there has to be a schedule first.
For disabling demand control the setting "?en_demand=0" is sufficient.

If you do not follow these rules the return value is always "PARAM NG" and demand control is not changed.
That's why I suggested to copy the behaviour of the Onecta Binding. There is no seperate channel to activate or deactivate demand control. The mode channel is a selection of the four values ["OFF", "Auto", "Scheduled", "Fixed"]. "OFF" is translated into "en_demand=0".

Please keep in mind that "en_demand=0" resets "mode" to "0" and "max_pow" to "100".

[jimtng]

Enabling demand control does not work.

Yup, I found some bugs. Working on it.

That's why I suggested to copy the behaviour of the Onecta Binding. There is no seperate channel to activate or deactivate demand control. The mode channel is a selection of the four values ["OFF", "Auto", "Scheduled", "Fixed"]. "OFF" is translated into "en_demand=0".

Agreed.

For "Scheduled" there has to be a schedule first.

Can you clarify this please? What do you mean "first" here? Do we need to send the schedule first, and send another set command to scheduled, or did you mean that the schedule has to be included in the one message (which is what I would think)

[jimtng]

I will I make it so:

• When maxpower received a command, it automatically sets the mode to MANUAL, and equally,
• when schedule is set, it automatically sets the mode to SCHEDULED

[Jogobo]

Can you clarify this please? What do you mean "first" here? Do we need to send the schedule first, and send another set command to scheduled, or did you mean that the schedule has to be included in the one message (which is what I would think)

"Scheduled" is quite complicated. To set a schedule you have to send a command with references to all days of the week. If there is no schedule for Tuesday you have to send "tuc=0".
To set a schedule where demand control is enabled with "50%" on Mondays at 12:00 and disabled on Mondays at 13:00 you have to send
<IP>/aircon/set_demand_control?en_demand=1&mode=1&&moc=2&mo1_en=1&mo1_t=720&mo1_p=50&mo2_en=0&mo2_t=780&mo2_p=100&tuc=0&wec=0&thc=0&frc=0&sac=0&suc=0
"enable/disable", "time" and "power" must be send for every schedule entry.

Now, when you change mode from "1" you have to read the current settings and store the schedule somewhere. Otherwise the schedule is lost.

As I wrote before setting "en_demand=0" resets "mode" to "2" and "max_pow" to "100".
"get_demand_control" returns the previous "mode" and "power" when you send "mode=[0|2]&max_pow=X" together with "en_demand=0".
"get_demand_control" returns the schedule when you send "en_demand=0&mode=1&[all schedule settings]". Nevertheless you have to send the schedule settings together with "en_demand=1&mode=1" when you enable demand control again.

In general "get_demand_control" returns the values sent with "en_demand=0" which makes it possible to restore the previous settings with "en_demand=1".

[jimtng]

@Jogobo thanks for the feedback and info. I'm going away tomorrow for a week (computer-free), but hoping that you could get a working version before then.

Could you please test this one?

org.openhab.binding.daikin-4.3.0-SNAPSHOT.jar.txt

• Removed the "demandcontrolenabled" channel
• The demandcontrolmode now accepts OFF|MANUAL|SCHEDULED|AUTO

[Jogobo]

OFF|MANUAL|SCHEDULED work, AUTO does not.

Item linked to channel "Demand Control Max Power" shows "1 one" as value. Can be set by a slider on a sitemap but displays "1 one" again after setting.

[jimtng]

Thanks! Can you try changing your Item for maxpower to a plain Number item, no dimension (not even Dimensionless).

[Jogobo]

Plain Number works

[jimtng]

Please try this one...
change maxpower's item type to Dimmer, but Number should also work. In fact try both and let me know, so I can document it.

Hopefuly this fixes AUTO but please re-test manual and schedule

org.openhab.binding.daikin-4.3.0-SNAPSHOT.jar.txt

[Jogobo]

Mode:
OFF: Does not work in this version
AUTO: works
SCHEDULED: works
MANUAL: works

Power:
Dimmer: works
Plain Number: Does not work (values <= 1)

[jimtng]

Thanks for testing. Let's hope this one works:

org.openhab.binding.daikin-4.3.0-SNAPSHOT.jar.txt

Power will have to be Dimmer now. I've removed the code that accepts Number (didn't work anyway).

[Jogobo]

Mode settings work.
Max power setting with dimmer works.

Is it possible that In SCHEDULED mode "max_pow" reflects the power setting from the schedule and is read-only in this case? Otherwise the current demand control value is not visible to the user.

[jimtng]

Is it possible that In SCHEDULED mode "max_pow" reflects the power setting from the schedule and is read-only in this case? Otherwise the current demand control value is not visible to the user.

How would you get the power setting from the schedule? Is it reported in the max_pow from get_demand_control request, or is it something that needs to be calculated based on the currentschedule ?

If it's the latter, then I'd say no, not that it isn't possible, but I think this is something that needs to be calculated by user script. I understand that this is debatable and I'm not set on this yet, and I understand the convenience this would provide. However, doing so would mask/hide the current manual max_pow value. I'm not sure if the ac unit preserves this or not? If not, then maybe we can do as you suggested.

If it's returned by get_demand_control, I guess you wouldn't have raised this issue because it would've done it already.

Making the demandcontrolmaxpower "read only" conflicts with the mechanism where setting it would automatically set the mode to MANUAL, i.e. because it can't be set during schedule mode. But even if we decided to provide (derive) the current max power based on the given schedule, it doesn't have to be read-only does it?

So other than the refinements being discussed here, does this now work correctly?

[Jogobo]

To set a schedule where demand control is enabled with "50%" on Mondays at 12:00 and disabled on Mondays at 13:00 you have to send
YOUR_IP/aircon/set_demand_control?en_demand=1&mode=1&&moc=2&mo1_en=1&mo1_t=720&mo1_p=50&mo2_en=0&mo2_t=780&mo2_p=100&tuc=0&wec=0&thc=0&frc=0&sac=0&suc=0
"enable/disable", "time" and "power" must be send for every schedule entry.

This was slightly incorrect. To achieve this you have to send

YOUR_IP/aircon/set_demand_control?en_demand=1&mode=1&&moc=2&mo1_en=1&mo1_t=720&mo1_p=50&mo2_en=1&mo2_t=780&mo2_p=0&tuc=0&wec=0&thc=0&frc=0&sac=0&suc=0

[jimtng]

This was slightly incorrect. To achieve this you have to send

YOUR_IP/aircon/set_demand_control?en_demand=1&mode=1&&moc=2&mo1_en=1&mo1_t=720&mo1_p=50&mo2_en=0&mo2_t=780&mo2_p=0&tuc=0&wec=0&thc=0&frc=0&sac=0&suc=0

This part is irrelevant to the binding, i.e. the binding merely passes through whatever schedule you gave it, straight to the ac unit, and interpreting it back. All it does is translate between the json syntax and the ac GET request parameters

[Jogobo]

Should be important for documenting the JSON format for schedules.
_en=1 means this schedule element is enabled, _en=0 means this schedule element is disabled.
_p=0 means demand power is disabled at the time defined by the _t element.

[jimtng]

Thanks, yes that's an important thing to document. I presume the _p should also be restricted to 40-100 just like max_pow?

[Jogobo]

First test:

• Binding set Mode = Manual, Power = 75
• HTTP change max_pow=55: Item shows 55 after poll 👍
• Binding change mode from Manual to Auto: max_pow stays 55, item stays 55 👍
• Binding change mode from Auto to Manual: max_pow stays 55, item stay 55 👍
• Binding change mode from Manual to OFF: max_pow becomes 100, item becomes 100
• Binding change mode from OFF to Manual: max_pow stays 100, item stays 100 (expected 55) 👎

Second test:

• Binding set Mode = Manual, Power = 75
• Binding change Mode = Scheduled: max_pow becomes 100, item becomes 100 after poll
• Binding change Mode = Manual: max_pow stays 100, item stays 100 (expected 75) 👎

Third test:

• Binding set Mode = Manual, Power = 75
• HTTP send en_demand=1&mode=1&wec=2&we1_en=1&we1_t=910&we1_p=55&we2_en=1&we2_t=912&we2_p=0&&moc=0&tuc=0&wec=0&thc=0&frc=0&sac=0&suc=0: mode item becomes Scheduled, power item becomes 100
• 15:10 to 15:12: power item becomes 55, max_pow at 100 👍
• after 15:12: power item becomes 100 👍
• Binding change Mode = Manual: [moc,tuc,wec,thc,frc,sac,suc] become 0, power item stays 100 (expected 75) 👎
• Binding change Mode = Scheduled: [moc,tuc,wec,thc,frc,sac,suc] stay 0 (expected previous schedule) 👎

[jimtng]

Thanks for doing the tests. Please try this version:

org.openhab.binding.daikin-4.3.0-SNAPSHOT.jar.txt

[Jogobo]

First test:

• Binding set Mode = Manual, Power = 75
• HTTP send en_demand=1&mode=1&frc=2&fr1_en=1&fr1_t=548&fr1_p=55&fr2_en=1&fr2_t=550&fr2_p=0&...: mode item becomes Scheduled, power item becomes 100
• 09:08 to 09:10: power item becomes 55, max_pow at 100 👍
• after 09:10: power item becomes 100 👍
• Binding change mode = Manual: [moc,tuc,wec,thc,frc,sac,suc] become 0, power item stays 100 (expected 75) 👎
• Binding change mode = Scheduled: get_demand_control returns ...&frc=2,fr1_en=1,fr1_t=548,fr1_p=55,fr2_en=1,fr2_t=550,fr2_p=0&... 👍

Second test:

• Binding set mode = Manual, power = 75
• get_demand_control returns en_demand=1,mode=0,max_pow=75 👍
• Binding set mode = Scheduled: get_demand_control returns ...&frc=2,fr1_en=1,fr1_t=548,fr1_p=55,fr2_en=1,fr2_t=550,fr2_p=0&... 👍
• Binding set mode = Manual: get_demand_control returns mode=0,max_pow=75, power item delayed (should it not change immediately?) = 75 👍

Third test:

• Binding set mode = Manual, power = 75
• set_demand_control?max_pow=55&...: get_demand_control returns ...&mode=0,max_pow=55&..., power item 55 👍
• Binding set mode = Auto: get_demand_control returns ...&mode=2,max_pow=55&..., power item 55 👍
• Binding set mode = Manual: get_demand_control returns ...&mode=0,max_pow=55&..., power item 55 👍
• Binding set mode = OFF: get_demand_control returns ...&en_demand=0,mode=0,max_pow=100&..., power item 100 👍
• Binding set mode = Manual: get_demand_control returns ...&en_demand=1,mode=0,max_pow=55&..., power item 55 👍
• set_demand_control?en_demand=0: get_demand_control returns ...&en_demand=0,mode=0,max_pow=100&..., mode item OFF, power item 100 👍
• set_demand_control?en_demand=1&mode=0&max_pow=40: mode item Manual, power item 40 👍
• Binding set mode = Scheduled: get_demand_control returns ...&frc=2,fr1_en=1,fr1_t=548,fr1_p=55,fr2_en=1,fr2_t=550,fr2_p=0&... 👍 👍
• set_demand_control?en_demand=1,mode=2,max_pow=80: mode item Auto, power item 80 👍
• Binding set mode = Manual: get_demand_control returns ...&mode=0&max_pow=40&..., power item 40 👍

If the scheduled power value no longer overwrites the stored manual power value I think that will be it.

[Jogobo]

Sorry, but after waiting a couple of minutes with mode = OFF and then set mode = Scheduled the previous schedule is not restored. I have to do some more testing to investigate further.

[jimtng]

Please try this one.

org.openhab.binding.daikin-4.3.0-SNAPSHOT.jar.txt

[Jogobo]

First test:

Binding set power = 75: mode = Manual, power = 75 👍
HTTP send ...&mode=1&tuc=2&tu1_en=1&tu1_t=535&tu1_p=90&&tu2_en=1&tu2_t=540&tu2_p=50&moc=0&wec=0&thc=0&frc=0&sac=0&suc=0: mode item becomes Scheduled, before 08:55 Power = 50, at 08:55 Power = 90, at 09:00 Power = 50 👍 👍
Binding change mode = Manual: get_demand_control returns ....mode=0,max_pow=100,... (expected max_pow=75) 👎
Binding change mode = Scheduled: get_demand_control returns ...,mode=1,moc=0,tuc=2,tu1_en=1,tu1_t=535,tu1_p=90,tu2_en=1,tu2_t=540,tu2_p=50,..., mode = 50 👍
Binding change mode = Auto: get_demand_control returns mode=2,max_pow=100 👍
Binding change mode = Scheduled: get_demand_control returns ...&mode=1,moc=0,tuc=2,tu1_en=1,tu1_t=535,tu1_p=90,tu2_en=1,tu2_t=540,tu2_p=50&..., mode = 50 👍
Binding change mode = Off: get_demand_control returns ...,en_demand=0,mode=0,max_pow=100,... 👍
Binding change mode = Scheduled: get_demand_control returns ...,mode=1,moc=0,tuc=2,tu1_en=1,tu1_t=535,tu1_p=90,tu2_en=1,tu2_t=540,tu2_p=50,..., mode = 50 👍

Second test:

Binding set mode = scheduled, power = 75: get_demand_control returns ...,en_demand=1,mode=0,max_pow=75,... 👍
Binding change mode = Auto: get_demand_control returns ...,en_demand=1,mode=2,max_pow=75,... 👍
Binding change mode = Manual: get_demand_control returns ...,en_demand=1,mode=0,max_pow=75,... 👍
Binding change mode = Off: get_demand_control returns ...,en_demand=0,mode=0,max_pow=100,... 👍
Binding change mode = Manual: get_demand_control returns ...,en_demand=1,mode=0,max_pow=75,... 👍
Binding change mode = Auto: get_demand_control returns ...,en_demand=1,mode=2,max_pow=75,... 👍
Binding change mode = Off: get_demand_control returns ...,en_demand=0,mode=0,max_pow=100,... 👍
Binding change mode = Manual: get_demand_control returns ...,en_demand=1,mode=0,max_pow=75,... 👍
HTTP send en_demand=0: get_demand_control returns ...,en_demand=0,mode=0,max_pow=100,..., mode = Off, power = 100 👍
HTTP send en_demand=1&max_pow=55&mode=0: get_demand_control returns ...,en_demand=1,mode=0,max_pow=55,..., mode = Manual, power = 55 👍
Binding change mode = Scheduled: get_demand_control returns ...,tuc=2,tu1_en=1,tu1_t=535,tu1_p=90,tu2_en=1,tu2_t=540,tu2_p=50,... 👍

It looks like changing a schedule from 3rd party overwrites the manual value in the binding. The rest seems to be perfect by now.

[jimtng]

It looks like changing a schedule from 3rd party overwrites the manual value in the binding. The rest seems to be perfect by now.

Yes, that was by design. Should it not do that? Err I really should read things properly before commenting! This shouldn't happen.

[jimtng]

1. Binding set power = 75: mode = Manual, power = 75 👍
2. HTTP send ...&mode=1&tuc=2&tu1_en=1&tu1_t=535&tu1_p=90&&tu2_en=1&tu2_t=540&tu2_p=50&moc=0&wec=0&thc=0&frc=0&sac=0&suc=0: mode item becomes Scheduled, before 08:55 Power = 50, at 08:55 Power = 90, at 09:00 Power = 50 👍 👍
3. Binding change mode = Manual: get_demand_control returns ....mode=0,max_pow=100,... (expected max_pow=75) 👎

I've put numbers in the above steps for easier reference.

Did you let the binding poll the new status between step (1) and (2) above? The binding only saves the maxpower / schedule during its polling. So if you did step (2) before the binding had a chance to poll the new max_power, it wouldn't have saved it.

Can you confirm this?

I can make the binding save the maxpower / schedule immediately, in addition to during polling to close this gap. It was done this way several revisions ago :)

[jimtng]

Here's a version that immediately saves the maxpower / schedule when it's set through the binding, in addition to during polling:

org.openhab.binding.daikin-4.3.0-SNAPSHOT.jar.txt

[Jogobo]

I just did the following test:

• switch mode to Off
• get_demand_control returns en_demand=0,mode=0,max_pow=100 immediately
• waited until power item shows 100
• switch mode to Manual
• get_demand_control returns en_demand=1,mode=0,max_pow=55 immediately
• waited 2 minutes (polling every minute)
• send a schedule with set_demand_control
• waited until demand control item shows Scheduled
• switch to Manual
• power item shows 100

I think this is due to the fact that when you send a schedule with set_demand_control max_pow is set to 100 automatically until a schedule entry changes max_pow to some other value. The device internal schedule management does not seem to go back to the last schedule entry by timeline and sets the appropriate value from the schedule. Looks like internal clock "day,hour,minute" equals schedule entry then set max_pow to schedule_pow.

[jimtng]

• switch mode to Off
• get_demand_control returns en_demand=0,mode=0,max_pow=100 immediately
• waited until power item shows 100
• switch mode to Manual
• get_demand_control returns en_demand=1,mode=0,max_pow=55 immediately
• waited 2 minutes (polling every minute)
• send a schedule with set_demand_control
• waited until demand control item shows Scheduled
• switch to Manual
• power item shows 100

Did you wait until the binding polled for new info (1 minute after switching to manual in the last step)?

[Jogobo]

Can the binding poll return a different value than what is returned by get_demand_control?
As switching to Manual made get_demand_control return en_demand=1,mode=0,max_pow=100 immediately there should be no difference waiting a minute.
Still have to do my tests with the latest version you uploaded here. My latest test results were written and posted while you uploaded your latest update.

[jimtng]

Can the binding poll return a different value than what is returned by get_demand_control?

no, it can't. The poll result should give the same thing asget_demand_control

As switching to Manual made get_demand_control return en_demand=1,mode=0,max_pow=100 immediately there should be no difference waiting a minute.

In your bulleted list above, you said "power item shows 100" which is not the same as saying get_demand_control. The power item gets its value updated after a poll. Until the next poll, it simply keeps the same value as it had before.

[Jogobo]

Sorry for this unclear documentation.

So once again (and I hope I did not forget anything):

• changing binding mode from Manual to Scheduled makes get_demand_control return max_pow=100 immediately
• max_pow stays at 100 even when a scheduled value becomes valid (binding shows the scheduled value in power item)
• changing binding mode from Scheduled to Manual leaves max_pow at 100 and changes binding power to 100
• changing binding mode back to Scheduled leaves max_pow at 100 and changes binding power to the scheduled value

Conclusion:

• max_pow only represents the valid power value in mode=0 but is resetted to 100 on every mode change
• binding may only save max_pow when binding changes mode from 0 or binding mode and polled mode both are 0
• when polling returns a mode different from the current mode in the binding and the polled mode is not 0 max_pow most probably was reset to 100 before polling and the value of max_pow must not be saved in the binding
• when binding changes mode to 1 the saved schedule must be sent together with the mode change
• when binding polls mode=1 and the current binding mode is different from 1 the saved schedule in the binding has to be overwritten with the polled schedule
• when binding mode and polled mode equal 1 the polled schedule has to be stored in the binding

[jimtng]

what is the binding's maxpower value before the following step? This would be the value that will get saved and restored later.

• changing binding mode from Manual to Scheduled makes get_demand_control return max_pow=100 immediately

So far so good. This is fine, and shouldn't affect the binding's saved value.

• max_pow stays at 100 even when a scheduled value becomes valid (binding shows the scheduled value in power item)

This is also fine and the value of binding's maxpower channel during scheduled mode is not being saved.

• changing binding mode from Scheduled to Manual leaves max_pow at 100 and changes binding power to 100

This would happen if at the very top above (before switching from manual to scheduled), the maxpower whilst in manual mode was 100.

• max_pow only represents the valid power value in mode=0 but is resetted to 100 on every mode change

This is fine. The binding does not save this value unless the polling says that it's currently in manual mode.

• binding may only save max_pow when binding changes mode from 0 or binding mode and polled mode both are 0

Yes.

• when polling returns a mode different from the current mode in the binding and the polled mode is not 0 max_pow most probably was reset to 100 before polling and the value of max_pow must not be saved in the binding

Yup, this won't be saved when mode != 0.

• when binding changes mode to 1 the saved schedule must be sent together with the mode change

Yes.

• when binding polls mode=1 and the current binding mode is different from 1 the saved schedule in the binding has to be overwritten with the polled schedule

Yes.

• when binding mode and polled mode equal 1 the polled schedule has to be stored in the binding

Yes.

At this point, I'm not exactly sure what the problem is.

As I understand it:

• When binding changed mode from scheduled to manual, it restored the binding's demandcontrolmaxpower channel to 100
• However, it isn't yet clear to me whether this is incorrect. I haven't established that the binding is doing something wrong based on all the steps you've described.

Can you please try the following steps:

• Set to manual mode, and set max_pow to 80. This can be done either using the binding, or using the phone app, or using http set_demand_control
• Wait until the binding shows MANUAL and demandcontrolmaxpower channel is set to 80.
• Change to schedule mode, using any means (app, binding, or set_demand_control
• Give it 1-2 minutes until binding shows SCHEDULED and whatever demandcontrolmaxpower channel is set to
• Use the binding (this part is important, don't use other methods) to change mode to MANUAL. The max_pow should be set to 80 here.

If the above steps failed, and max_pow somehow got set to 100, please turn on debugging

log:set trace org.openhab.binding.daikin

Then do the steps and paste the logs please.

[jimtng]

Sorry I've just had a look. You need to set the log level to trace not debug.

[Jogobo]

I followed your steps and set demandcontrolmaxpower to 80. Checked API with get_demand_control and then used set_demand_control to set a schedule which changed demandcontrolmaxpower to 90 and demandcontrolmode to Scheduled. Then I used the binding and changed demandcontrolmode to Manual. demandcontrolmaxpower switched back to 80. 👍

Used the binding and changed demandcontrolmode to Off.

• get_demand_control shows max_pow=100 immediately
• waited until demandcontrolmaxpower shows 100 %
• set a schedule with set_demand_power and waited for demandcontrolmode to show Scheduled 👍
• demandcontrolmaxpower changed to 90 % (the scheduled value) 👍
• used the binding and changed demandcontrolmode to Manual
• get_demand_control immediately showed mode=1,max_pow=80 👍
• demandcontrolmaxpower stayed 90 % until the next poll, then changed to 80 % 👎 👍

First of all, with the latest version the problem seems to be gone or my tasting was not as precise as it should have been. Great work!

Just one little thing: when changing demandcontrolmode to Manual the stored demandcontrolmaxpower value is sent too. Is it, by design, necessary to wait for the next poll before showing the stored value in demandcontrolmaxpower?

[jimtng]

Just one little thing: when changing demandcontrolmode to Manual the stored demandcontrolmaxpower value is sent too. Is it, by design, necessary to wait for the next poll before showing the stored value in demandcontrolmaxpower?

I had considered this exact situation. Whilst I can set demandcontrolmaxpower immediately to the set value, doing so violates the role of the binding, that is to provide you with the actual value reported by the device. That is why it's waiting for the next poll before the value is updated.

I did make an exception with the maxpower under scheduled mode, because the unit doesn't report anything useful for that channel anyway.

If it's important to you that the maxpower channel immediately updates after setting to manual mode, I can implement REFRESH handling for the maxpower channel, at which, it will do an immediate poll. This will require you to send a REFRESH command to (any) one of the channels.

[jimtng]

I suppose it's probably highly unlikely that the value set for maxpower is rejected by the device. I can update the channel immediately, knowing that on the next poll, it will get the actual value from the device anyway. Would you prefer this instead of waiting for the next poll?

[Jogobo]

When you want to change mode in the API to 0 it does not work until you send it together with en_demand and a value for max_pow.
If binding demandcontrolmode is Off and you change it to any other value demandcontrolmode does not stay Off until the next poll, which returns en_demand=1 from being 0 before changing the value of demandcontrolmode, but changes to the desired value immediately.
I think setting demandcontrolmode to Manual is a sub-case of the above. max_pow is sent together with en_demand and mode. So the moment demandcontrolmode is set to Manual demandcontrolmaxpower cannot have a value different from the value for max_pow sent together with the mode change.
Imagine the poll interval is set to 5 minutes instead of 60 seconds. demandcontrolmaxpower would reflect a wrong value the binding "knows" of being wrong. A user not being deep into the way the binding works would regard this as not working.

[Jogobo]

I suppose it's probably highly unlikely that the value set for maxpower is rejected by the device.

If any of the 3 mandatory values en_demand, mode, max_pow for changing to Manual is not accepted, the whole command is not accepted. So there seems to be no way demandcontrolmaxpower could be different from max_pow directly after sending the values.

[jimtng]

Imagine the poll interval is set to 5 minutes instead of 60 seconds. demandcontrolmaxpower would reflect a wrong value the binding "knows" of being wrong. A user not being deep into the way the binding works would regard this as not working.

This is how it works for all the channels on the binding. For example, AC is off, binding power is off. You send an ON command to the power channel, it would send the API request to turn on the AC, but the binding's power channel will still say off, until the next poll.

This is why I don't want to deviate from this behaviour. You need to poll to get the actual status from the device, and not make assumptions.

[Jogobo]

I do not agree with that. I know that the general behaviour of bindings is send a command to the device and wait for the result, then show the result in the channels.

It is kind of philosophical whether the result code ret=OK from set_demand_control already is the confirmation that the values sent are accepted and set by the device or if it needs a poll to confirm the values.

Changing demandcontrolpower from Off to any other value cannot be done isolated from other device parameters. set_demand_control?en_demand=1 does not work, set_demand_control?mode=0 does not work, set_demand_control?max_pow=80 does not work. You have to send the "multi-channel-call" set_demand_control?en_demand=1&mode=0&max_pow=80 to the device for the desired action.
When this is initiated by setting demandcontrolmode to Manual the channel shows Manual immediately and not after the next poll. Same should go for the other parameters send with set_demand_control.

In my opinion when the result is ret=OK this is the confirmation of the device that all channels are set as desired. If there was no other way to set the device parameters a poll would not be necessary at all.

Polling, in this case, is only necessary to reflect changes not coming from the binding itself. Worst case is it takes "poll interval" until the changes made elsewhere arrive at the binding. But this is by design and mostly well documented.

[jimtng]

It is kind of philosophical whether the result code ret=OK from set_demand_control already is the confirmation that the values sent are accepted

I agree with this in theory, although I have no way to confirm this. Can you try sending a set_demand_control with some invalid values, e.g. en_demand=1,mode=0,max_pow=20 and checking to see whether you'd get ret=OK or not? Then issue a get_demand_control and see what it says for all those fields.

When this is initiated by setting demandcontrolmode to Manual the channel shows Manual immediately and not after the next poll

I believe this is incorrect. You may be observing this behaviour because your Item is set to autoupdate. Try setting autoupdate to false, send a command to the demandcontrolmode, and then check the state of the item. You'll find that it remains at the old value, until the next poll when it's updated by the binding.

[Jogobo]

set_demand_control?en_demand=1&mode=0&max_pow=7 returns ret=PARAM NG. Tested for some other values below 40 and the result was the same. When the return value is ret=PARAM NG the result of get_demand_control is always the same (means unchanged since the last set_demand_control with ret=OK).

I believe this is incorrect. You may be observing this behaviour because your Item is set to autoupdate.

Correct. Forgot about autoupdate as it is enabled by default.

This would lead to a more complex programming depending on the item's autoupdate setting. If set_demand_control?en_demand=1&mode=0&max_pow=40 returns ret=OK then

• if it was initiated by demandcontrolmode=Manual and autoupdate of demandcontrolmaxpower is true set demandcontrolmaxpower to the value of the sent max_pow
• if it was initiated by demandcontrolmaxpower=40 and autoupdate of demandcontrolmode is true set demandcontolmode to Manual immediately

[jimtng]

The thing is, to be consistent, we'd have to do this "proactive update" for all the channels. The way to do it is this:
When we send a set_xxxx http request and receives a ret=OK response, we should update the channel that initiated that command, and any other related channels that have changed because of it, e.g. demandcontrolmode+maxpower.

Whilst I'm not against this, I believe that is a big enough change that warrants its own separate PR. I do think it would make for a nicer and more responsive experience for the binding users, without compromising in "information integrity".

I will finalise and submit this PR as is for now, without this automatic channel update.

[Jogobo]

Whilst I'm not against this, I believe that is a big enough change that warrants its own separate PR.

Fair enough. Thank you for your patience and time. There was a lot more to do than only adding some more channels.

[jimtng]

Thanks for doing all the tests! :)