[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]

Changing the mode element from the url parameters makes the API forget everything about the previous mode.

Executing IP/aircon/set_demand_control?en_demand=1&mode=0&max_pow=55 leads to ret=OK,type=1,en_demand=1,mode=0,max_pow=55,scdl_per_day=4,moc=0,tuc=0,wec=0,thc=0,frc=0,sac=0,suc=0 when executing "get_demand_control". Even if you send any previous schedule settings together with the above parameters the result is still the same. Switching from mode=0 to mode=1 results in "max_pow" being set to "100" even if you send a different value with "max_pow".

[Jogobo]

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

40-100 or 0 if demand control shall be disabled in the schedule.

[jimtng]

I've just refactored the schedule handling a bit:

• You can specify in your json just the day(s) you're interested in, i.e. don't have to have empty days. Sorry.. would you mind testing this again? I hope I haven't broken anything (else)

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

[jimtng]

Changing the mode element from the url parameters makes the API forget everything about the previous mode.

Executing IP/aircon/set_demand_control?en_demand=1&mode=0&max_pow=55 leads to ret=OK,type=1,en_demand=1,mode=0,max_pow=55,scdl_per_day=4,moc=0,tuc=0,wec=0,thc=0,frc=0,sac=0,suc=0 when executing "get_demand_control". Even if you send any previous schedule settings together with the above parameters the result is still the same. Switching from mode=0 to mode=1 results in "max_pow" being set to "100" even if you send a different value with "max_pow".

OK, so this means there's no need to "preserve" the max_pow whilst in the AUTO mode.

I'm open to doing the calculation based on the given schedule. Here are the currrent assumptions:

• When the day has no schedule, max_pow is assumed to be 100, i.e. demand control for that day is disabled?
• TBH my brain so far had completely been tuning out how to interpret the schedule, but now I need to understand it.
• Are the schedules ordered by sequence (mo1, mo2, mo3, ...) or are they ordered by time (e.g. moX_t)? My guess is that they should be ordered by time? So the current max power in effect is determined by going through the smallest time to the largest time entry, stopping when current time is between the current entry and the next entry?
• The concept of "day" and "time" (i.e. minutes from midnight as specified in the schedule) is obviously in reference to the date/time that is currently being held by the AC unit. Knowing this data is crucial to interpreting the schedule. Do you know how to get the current date/time from the AC unit? Without this information, we could be way off.

[jimtng]

We could probably "assume" the local date/time is the same as the aircon's date/time, and write a caveat in the manual that if you want to "use" the data, you need to make sure the time is sync'ed. Otherwise it can just be ignored. It's better than 100 anyway, right?

[Jogobo]

Okay...

Setting a schedule works. Mode changing works.

Changing from mode=1 to another mode: schedule is lost. Is there a way to preserve the schedule settings when the users switches modes temporarily? Changing from mode=0 to mode=2: "max_pow" is reset to 100. It would be nice when the previous "max_pow" value is sent together with mode=2 so that changing back to mode=0 can use the stored value in "max_pow".

When the day has no schedule, max_pow is assumed to be 100, i.e. demand control for that day is disabled?

I see it as a weekly schedule. When Tuesday has no schedule the last entry from Monday continues. But I have never used the demand control schedules and do not know if my assumption is true.

Are the schedules ordered by sequence (mo1, mo2, mo3, ...) or are they ordered by time (e.g. moX_t)? My guess is that they should be ordered by time? So the current max power in effect is determined by going through the smallest time to the largest time entry, stopping when current time is between the current entry and the next entry?

ret=OK,type=1,en_demand=1,mode=1,max_pow=100,scdl_per_day=4,moc=2,mo1_en=1,mo1_t=660,mo1_p=90,mo2_en=1,mo2_t=600,mo2_p=0,tuc=0,wec=0,thc=0,frc=0,sac=0,suc=0 As you can see the entries are ordered by number. Means first entry is the first being added in the app, no matter what time is set. I think nothing speaks against ordering the entries by time.

The concept of "day" and "time" (i.e. minutes from midnight as specified in the schedule) is obviously in reference to the date/time that is currently being held by the AC unit. Knowing this data is crucial to interpreting the schedule. Do you know how to get the current date/time from the AC unit? Without this information, we could be way off.

Luckily I'm getting a feeling on how the Daikin developpers have chosen the names for their functions. Getting current date and time: IP/common/get_datetime results in ret=OK,sta=2,cur=2024/7/15 12:57:13,reg=eu,dst=1,zone=43

sta: ? cur: current date and time reg: region of installation "eu" = Europe. I don't know the values for other regions dst: "1" = daylight saving enabled, "0" = disabled zone: ?

[jimtng]

Changing from mode=1 to another mode: schedule is lost. Is there a way to preserve the schedule settings when the users switches modes temporarily? Changing from mode=0 to mode=2: "max_pow" is reset to 100. It would be nice when the previous "max_pow" value is sent together with mode=2 so that changing back to mode=0 can use the stored value in "max_pow".

The max_pow and schedule are currently sent back to the aircon. Verify this using debug logging.

So simply sending them won't result in getting them back. we have to store both max_pow and schedule, correct?

Getting current date and time: IP/common/get_datetime results in ret=OK,sta=2,cur=2024/7/15 12:57:13,reg=eu,dst=1,zone=43

That's great! But, does it work on all models (which means we can add another channel), or do we just do this internally while getting the demand control, or just assume the time is sync'ed and not ask for this at all.

[Jogobo]

So simply sending them won't result in getting them back. we have to store both max_pow and schedule, correct?

Correct.

That's great! But, does it work on all models (which means we can add another channel), or do we just do this internally while getting the demand control, or just assume the time is sync'ed and not ask for this at all.

As this function is part of the "common" folder I assume that it depends on the wireless module in the aircon. I have BRP069B4x modules and all of them return the current date and time. The newer modules from the C-series have dropped WLAN API support, so nothing to care about. If we could find someone with the old A-series installed, he/she might confirm that it works too with these modules.

[jimtng]

When the day has no schedule, max_pow is assumed to be 100, i.e. demand control for that day is disabled?

I see it as a weekly schedule. When Tuesday has no schedule the last entry from Monday continues. But I have never used the demand control schedules and do not know if my assumption is true.

Implementing this is quite tricky. I'll have to look into this next week.

Meanwhile, I implemented saving the schedule / maxpower as requested. Please test it. I haven't tested it, and I haven't had a chance to write a test for it, but I'm planning to.

EDIT: Ooops sorry, I forgot to SAVE the file before compiling! Things have been crazy around here and I've been super distracted today.

[jimtng]

Here it is with the schedule/maxpower saving org.openhab.binding.daikin-4.3.0-SNAPSHOT.jar.txt

[jimtng]

And here is the one with max power channel calculated from the schedule settings (when mode = scheduled) as you requested. It takes into account the weekly schedule, so if nothing is set for the day or the time is earlier than the earliest schedule for that day, it looks back to previous days with enabled schedule.

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

Once you've confirmed that it's working, I'll work on the docs, then open a PR to merge it.

[Jogobo]

I digged a little deeper into the schedules. As mentioned before I do not regard them as useful, but anyways...

When you setup a schedule for Monday 10:00 and limit "DemandControl" to, let's say, 60% and on Monday 11:00 "DemandControl" is disabled the result of "get_demand_control" looks like mo1_en=1,mo1_t=600,mo1_p=60,mo2_en=1,mo2_t=660,mo2_p=0. When you use the Onecta app you see that after the second entry Monday looks the same as a day with no schedule. So I think when a day has no entries it should be treated like "DemandControl disabled". Meaning that if Monday ends with "60%" and Tuesday has no entries or the first entry on Tuesday is after midnight "DemandControl" should be disabled at midnight on Tuesday.

Another question: What about setting up a new schedule on Wednesday at 12:00 with we1_en=1,we1_t=600,we1_p=70,we2_en=1,we2_t=840,we2_p=0? Will demand power be activated as the update time of the schedule lies within the 70% time of the schedule?

[jimtng]

When you setup a schedule for Monday 10:00 and limit "DemandControl" to, let's say, 60% and on Monday 11:00 "DemandControl" is disabled the result of "get_demand_control" looks like mo1_en=1,mo1_t=600,mo1_p=60,mo2_en=1,mo2_t=660,mo2_p=0. When you use the Onecta app you see that after the second entry Monday looks the same as a day with no schedule.

I agree with this so far

So I think when a day has no entries it should be treated like "DemandControl disabled". Meaning that if Monday ends with "60%" and Tuesday has no entries or the first entry on Tuesday is after midnight "DemandControl" should be disabled at midnight on Tuesday.

Have you tested/confirmed this? I'd like to know what happens when you have one single schedule on Monday that sets it to 60%, and no other schedules in other days. What would happen on Tuesday etc?

The main point is whether the demand control "resets" at midnight back to "no demand control", or whether it continues whatever the last setting was for the preceding day.

PS have you tested the storing/restoring of maxpower / schedule like you requested above?

[Jogobo]

I will setup a schedule for today and see what happens tomorrow with no schedule. Today it's cloudy and quite cold so the aircon will be off the whole day.

I updated to openHAB 4.2 (from 4.1.3) yesterday and now I get a bunch of errors when adding the binding snapshot:

2024-07-17 08:39:56.234 [ERROR] [daikin.internal.DaikinHandlerFactory] - bundle org.openhab.binding.daikin:4.3.0.202407160433 (331)[ org.openhab.binding.daikin.internal.DaikinHandlerFactory(475)] : Error during instantiation of the implementation object java.lang.IllegalArgumentException: argument type mismatch at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?] at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77) ~[?:?] at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?] at java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) ~[?:?] at java.lang.reflect.Constructor.newInstance(Constructor.java:480) ~[?:?] at org.apache.felix.scr.impl.inject.internal.ComponentConstructorImpl.newInstance(ComponentConstructorImpl.java:326) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:286) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:115) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:1002) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:975) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:920) ~[?:?] at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:220) ~[org.eclipse.osgi-3.18.0.jar:?] at java.security.AccessController.doPrivileged(AccessController.java:318) [?:?]

[jimtng]

updated to openHAB 4.2 (from 4.1.3) yesterday and now I get a bunch of errors when adding the binding snapshot:

That's a strange error, i.e. I don't know what it's about. I don't think it's related to the changes that I made, but quite likely it is...? Can you try clearing the cache and tmp please? (stop OH -> clear -> start)

[jimtng]

Today it's cloudy and quite cold

Are you in the southern hemisphere like I am? :D

[Jogobo]

That's a strange error, i.e. I don't know what it's about. I don't think it's related to the changes that I made, but quite likely it is...? Can you try clearing the cache and tmp please? (stop OH -> clear -> start)

Already did that after updating. Found out that the official Daikin binding was loaded by "addons.cfg". Removed the entry, cleaned cache again and now snapshot works.

Are you in the southern hemisphere like I am? :D

No, northern hemisphere seems to have the same weather conditions... :D

[Jogobo]

PS have you tested the storing/restoring of maxpower / schedule like you requested above?

Storing schedules and max power works. Editing a schedule on a sitemap Input item=schedule_item does not work because the double quotes are replaced by &quote; after entering the values Log shows: 2024-07-17 09:39:03.613 [WARN ] [internal.handler.DaikinAcUnitHandler] - Invalid schedule: {"sunday":[enabled:true,power:85,time:240],"saturday":[],"tuesday":[],"wednesday":[],"thursday":[],"friday":[],"monday":[{"enabled":true,"time":653,"power":90},{"enabled":true,"time":654,"power":50}]}. com.google.gson.stream.MalformedJsonException: Expected ':' at line 1 column 8 path $.

[jimtng]

Editing a schedule on a sitemap Input item=schedule_item does not work because the double quotes are replaced by &quote; after entering the values Log shows: 2024-07-17 09:39:03.613 [WARN ] [internal.handler.DaikinAcUnitHandler] - Invalid schedule: {"sunday":[enabled:true,power:85,time:240],"saturday":[],"tuesday":[],"wednesday":[],"thursday":[],"friday":[],"monday":[{"enabled":true,"time":653,"power":90},{"enabled":true,"time":654,"power":50}]}. com.google.gson.stream.MalformedJsonException: Expected ':' at line 1 column 8 path $.

This is a problem in Sitemaps, not with the binding, although it does need to be fixed.

[jimtng]

The Android app doesn't convert it to " but it has a different issue. I entered {"test":[]}, it would send that correct string to the Item, but then it stripped everything after :. Two separate bugs to deal with! Still not related to the binding though. I did that on an unlinked test item.

I hope you're not letting users enter json strings directly on your UI though.

[Jogobo]

I hope you're not letting users enter json strings directly on your UI though.

I do not plan any user interaction. I have quite complex rules for adjusting the power for heating and cooling depending on the actual and desired room temperature. As the temperature measuring from the indoor units is far off the real room temperature there is no way to achieve the desired room temperature without adjusting the max power. Last winter I was able to keep the room temperature within 0.1°C. Now, in summer, I am able to keep the desired room temperature on point.

[jimtng]

Android issue: https://github.com/openhab/openhab-android/issues/3756 Web client issue: https://github.com/openhab/openhab-webui/issues/2675

[Jogobo]

Okay, this was unexpected...

I set up a schedule with just one entry. Then I waited until the schedule was synchronized with the cloud and checked the schedule in the Onecta app. Surprisingly the single entry is shown as scheduled for the whole week. So it seems my first assumption is correct. The last entry defines what is valid now, independant from the day it was defined.

[jimtng]

I set up a schedule with just one entry. Then I waited until the schedule was synchronized with the cloud and checked the schedule in the Onecta app. Surprisingly the single entry is shown as scheduled for the whole week.

That means I won't need to change the current implementation! Just to confirm:

• When you only have one schedule on one particular day, and all the other days contain no schedules, then essentially it's the same as MANUAL mode, right?