Irremoteesp8266: Daikin weekly program

[MassiPi]

hello,
i can't understand the use of the "setWeeklyTimerEnable" and "setCurrentDay" functions.
I mean, i understand what they do, but they are useless if i can't setup the timer (on and off) day by day, and as far as i have understoood this is not possible with the library (the timers are just one shot, i assume).
am i wrong?
thanks

[crankyoldgit]

You'll probably need to consult a manual for the Daikin device to find out how it operates. I just implement the controls that users tell me exist in the messages.

See #704 for some background on when it got added.

Maybe @NetNerd , @sillyfrog , @samtd, or @sheppy99 may be able to assist you as they have Daikin A/C units.

[NetNerd]

So, the reason for those being included is simply that they're part of the main control messages which are always sent for any changes (unlike the actual schedule settings which as you noticed aren't implemented).

Day of week is related to timekeeping, like the current time. And weekly timer enable is a bit that disables weekly timer schedules completely (at least on my unit).

If they couldn't be set, it would be impossible to fully control and maintain the correct state (for a system where remotes and/or weekly schedules may also be used sometimes) unless data is regularly received from a remote -- the current day of the schedule would constantly reset and weekly timers may be accidentally enabled or disabled.

[crankyoldgit]

Thanks @NetNerd, that rings some bells.

[sheppy99]

I'm a bit late to the party with this one but I'm happy to help. I've got one of these http://daikin.com.au/our-product-range/split-system-air-conditioning/us7 with added WiFi adapter. I control it using IR as WiFi doesn't expose Quiet Fan speed amongst other things. I'm a bit out of date with this library as everything has been working perfectly and I've left it alone. Assuming nothing has changed, one obsticle to getting timers working was the library always sent an unset time field which IIRC will reset the time to "unset" everytime the library is used and the remote will then set it again when it is used. Last time I had the LED's on the unit turned on it was complaining about something which may have been the time, but as I use timers in OpenHAB I ignored it.

[NetNerd]

It looks like the model you have uses the Daikin2 protocol @sheppy99. Is that correct?

It looks like IRDaikin2 does have a setCurrentTime function you can use, though I don't see any for day of week there.
I always update time in the library from NTP before sending anything to keep it set correctly.

[sheppy99]

It looks like the model you have uses the Daikin2 protocol @sheppy99. Is that correct?

It looks like IRDaikin2 does have a setCurrentTime function you can use, though I don't see any for day of week there.
I always update time in the library from NTP before sending anything to keep it set correctly.

IRDaikin2 - Correct

I use IRMQTTServer to send everything in common AC framework mode, and last time I looked it didn't set the clock, although that was a long time ago. Using IRMQTTServer to send a complete hex string with the time set within it did set the time on the unit, but as it didn't seem to offer anything useful I didn't worry about it.

Regarding days of the week I don't remember decoding that bit, so it likely never made it into the orignal command translation spreadsheet. I use OpenHAB to turn mine on based on bedroom temperature and a bunch of other things which works well, although the rules are a bit complex compared to a simple timer

[NetNerd]

Ah, right. As I understand it, MQTT messages are pretty much directly relayed to the aircon without modification.

Perhaps adding an option to set NTP time in it could be useful, but that isn't really my domain here and that discussion would be best moved to another issue.

[sheppy99]

All good, please let me know if i can help with anything, although as its been working reliably I don't want to poke it with a stick if theres no reason :-)

[crankyoldgit]

Correct. IRMQTTServer currently doesn't support the concept of time/date. NTP could be added, but honestly, if you're using IRMQTTServer, you're better off doing timer/timed control using a Home Automation system e.g. OpenHAB, Home Assistant, etc etc. You can do more things/better time controls etc using that then with the in-protocol systems if the A/C even supports it.

The IRac class does support the current time, but does not support timers or the day of the week. If you want that level of feature, you have to use the native class object for your particular A/C. e.g. The IRDaikinESP class. There is just too much variance between how different manufacturers handle/approach timers to be able to have a consistent model to use within the common IRac framework.

[crankyoldgit]

@MassiPi Has this been answered sufficiently?

[crankyoldgit]

Chase up ping before marking this issue stale/closed etc.

[MassiPi]

hello,
well yes, this was answered: the weekly program was not developed so those option are just to fill the "common" command payload.
i did not know the weekly program had a different datagram! well this shoul be reverse engineered, let's see if i can find some spare time.. to be honest i don't even need this feature, but it's a mess this wonderful library has an hole like that :)
do you think the receiver part of the library can help in reverse engineering or shoul i start back from timings of high and low levels? i did that some years ago for the command itself and it was really long :)
thank you all

[NetNerd]

I did dump some data and figure out the general format in the discussion from #704 (direct link to pastebin here https://pastebin.com/t4GnEQHd)

It should be pretty straightforward to fill in the blanks and implement if needed, but it's pretty large and I suppose would have some fairly heavy memory requirements (I'm thinking ~5K, but I'm not sure about the library architecture off the top of my head and that could be pretty far off). It might not really be worth the footprint for most users, but I guess the decision on that is up to @crankyoldgit.

[crankyoldgit]

@MassiPi

do you think the receiver part of the library can help in reverse engineering

Yes. Worst comes to worst, auto_analyse_raw_data.py should be able to turn it into hexadecimal. Happy to add capturing it (the timer datagrams) as a supported protocol to generate a state code etc.

@NetNerd

It should be pretty straightforward to fill in the blanks and implement if needed, but it's pretty large and I suppose would have some fairly heavy memory requirements (I'm thinking ~5K, but I'm not sure about the library architecture off the top of my head and that could be pretty far off). It might not really be worth the footprint for most users, but I guess the decision on that is up to @crankyoldgit.

It probably won't be 5K expensive, probably only 1-2K
We could add it, but I suspect it isn't really worth it or used that much as you indicate.
e.g. If you really want to do "timers", and you've got access to a fully programmable ESP chip, you're far better off just controlling the device via Arduino code (or MQTT/Home Automation/Tasmota/ESPEasy/etc) than with the built-in timers in the A/C.
Why be limited to only one timer per day? Or the rounded 10 min start/end times? With code/scripts, you can do far more than just basic on/off etc with far better time accuracy.
Hence why timers are always at the bottom of the list for feature-adding priority. They can be implemented (better) elsewhere, with minimal effort, and far greater functionality.

[crankyoldgit]

well yes, this was answered

Thanks for the confirmation. Closing.