Further work on Daikin2 Protocol #644

sheppy99 · 2019-03-16T22:53:27Z

Since deploying IRMQTTServer to control a Daikin2 device I've suffered intermittent operation and have gone back to first principles to try and flush out the problems. This thread is to inform anyone else trying to get this working as well as document anything I've found.

The first change is changing the carrier frequency from 38KHz to 36.7KHz after measuring the waveform. This has improved things, and has been incorporated in the latest version of the library 2.5.6 however all is still not stable. Problems take several days to show up, so I will only update this when I'm reasonably sure changing something has helped.

The next thing I've discovered is the MSB part of the hexadecimal pair in Byte 6 changes depending on whether the AC should be ON or OFF after the IR command. So far I've found

4 = After this command AC is ON
C = After this command AC is OFF

The LSB half of the hexadecimal pair remains unchanged as 256 x current minutes past midnight
I've yet to find out whether any other parts of this byte change with any other function, or whether any timer functions change this.

I will update this post when:

a few days has passed and the thing is still working reliably
if I discover any other functionality from this byte
if I discover any other bytes that do anything useful or need changing

@sheppy99

According to @sheppy99 in #644, power on/off control also depends on the MSB of state[6]. i.e. MSB = 1 (off), MSB = 0 (on)

crankyoldgit · 2019-03-17T00:11:49Z

Hey @sheppy99 I've updated the code per your comment in the branch "Issue644", please let me know if that works/fixes it.

sheppy99 · 2019-03-17T00:14:30Z

Thanks for the update. As I generate the full hex string including checksums from within OpenHAB I’m not sure how I can test it apart from with the IR Dump Program?

crankyoldgit · 2019-03-17T01:00:22Z

IRrecvDumpV2 from that branch should report the correct status. (i.e. based on that extra bit)

sheppy99 · 2019-03-17T01:17:08Z

Perfect, will give it a whirl later in the week. So far the modifications are working, but I’ve been here before. My guess is without that bit set the IR only worked if it was already OFF, and then when ON the IR only worked part of the time before it received a command over WiFi. My first iteration was simply replaying captured RAW signals and I never checked what they were

sheppy99 · 2019-03-17T04:01:15Z

Update:
It’s not totally fixed yet, I just had to send a command 4 times before it responded. I know there are issues with some Arduino core versions especially 2.4.x so I’m using 2.5 beta 3, what version do you use @crankyoldgit

crankyoldgit · 2019-03-17T12:07:03Z

I'm using 2.5.0 of the core library. I found that 2.4.2 was very unhappy network connectivity-wise.
With 2.5.0 I've had 843 mqtt disconnects over ~39 days of uptime. With 2.4.2 I was getting many thousands and a lot of missed mqtt IR commands.
TBH, 2.3.0 was the most stable for me network-wise. I'd typically only have 10's of disconnects in a similar period. I'd still be using it except for the network security issue.

However, that's just the networking side of it. The IR stuff should be invariant across the range of ESP8266 core libraries. So, I'd suggest sending the code via the web interface to test/confirm, or check the stats info to see if your commands are making it to the device or not. (That's one of the reasons that stat stuff is there because all of the problems I had with 2.4.x)

sheppy99 · 2019-03-17T21:35:00Z

@crankyoldgit I've just added a layer of verification to my OpenHAB rule that waits for a second after every send and then checks that it has received the same command back on topic ir_server/sent.
I'll watch it for a few hours and see if anything fails.
Is there any way the IR would not be sent but that topic would be updated?
3 disconnections over 1 Day, 8 Hours currently so if it is dropping out regularly it hasn't noticed.
V2.4.x dropped several times per day on my Tasmota SOnOffs and V2.5.beta3 seems stable on the same devices

sheppy99 · 2019-03-18T01:12:18Z

Update: Just discovered OH was dropping the leading 0 when the time byte was less than 0x10, instead of providing 0x0F it was providing 0xF which was throwing the whole string out by one half byte. This occurred at Midnight for 15 minutes, then once every 256 minutes after midnight for 15 minutes.
Further testing ahead!

crankyoldgit · 2019-03-18T03:23:37Z

Is there any way the IR would not be sent but that topic would be updated?

Yes, if for some reason the sendBlah() function would reject the data/bit length etc and not send with that input, then it wouldn't send it and silently fail, while the rest of the program thinks it succeeds.
That scenario is very unlikely IMHO, but technically possible.

Update: Just discovered OH was dropping the leading 0 when the time byte

If that's in the middle of your string, then yep, it's going to produce an invalid code for your A/C.

sheppy99 · 2019-03-18T03:30:46Z

That explains why it didn’t give a complaining beep!

crankyoldgit · 2019-03-18T05:19:44Z

You could/should probably add a length check to your OH code generation routine, if it hex string isn't the correct length, log an error.

sheppy99 · 2019-03-18T05:36:12Z

That’s an idea. In reality I only generate the time, temperature and 2 checksums, the rest is done via either fixed values or value substitution. I’d already discovered this banana skin in the checksum but failed to apply my fix to the time.

…

Sent from my iPhone On 18/03/2019, at 6:19 PM, David Conran <[email protected]<mailto:[email protected]>> wrote: You could/should probably add a length check to your OH code generation routine, if it hex string isn't the correct length, log an error. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#644 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMTzpOvwbJ5rVteeWzJ4GpdN2zH0UVauks5vXyHzgaJpZM4b4Eq6>.

@sheppy99

According to @sheppy99 in #644, power on/off control also depends on the MSB of state[6]. i.e. MSB = 1 (off), MSB = 0 (on)

crankyoldgit · 2019-03-26T22:50:17Z

Just a note that this issue is waiting on @sheppy99. Nothing needs to be done at present till an issue is found etc.

sheppy99 · 2019-03-27T02:29:59Z

And it worked perfectly for a few days before it stopped a couple of days ago, never to work again. Round about the time it stopped I noticed IRMQTTServer had rebooted. The LED measures 1.15Volt Drop, suggesting its still OK, and my scope shows pulses on the LED wires whenever I send commands. Temporarily adding a standard LED in parallel with the IR LED shows flickering whenever IR is sent.Each send is returning the same command to OpenHAB via MQTT suggesting the Comms between OpenHAB and the ESP are working. A quick analysis of a non working sent packet shows its valid and both checksums are correct.
SO I just replaced the stick on emitter and it works again. I also noticed a negative voltage across the LED so I've added an inline diode as a quick and dirty bodge in case the iPhone charger I'm using to power the ESP is sending out spikes that are killing the LED, or if there's some weird interaction with the Huzzah ESP modules onboard regulator.
The new IR LED has a volt drop of 1.086V, so not much difference, but crucially the latest one works.
Lets see if this setup lasts!

crankyoldgit · 2019-03-27T05:48:44Z

FYI, you can verify if the IR LED is working by using a digital camera (e.g. in your phone) and you should see be able to see it blink when it transmits. Typically digital cameras can see into Intra-red just enough to show the illumination. No visible activity etc means you've probably over-voltaged/over-current/let-out-the-magic-smoke out of the IR LED.

And yes, the IR LED should be OFF 99.999% of the time. i.e. Only ever ON/Flashing when transmitting.

I've personally found IR LEDs are very easy to kill, but the cheapo 5mm ones off ebay etc have been fine thus far. I killed about half a dozen in testing/designing/building, and then they've been rock-solid in real-use (2+ years).

It really sounds like your circuit/power supply is frying them, to be honest. Or they could be crap quality. Who knows. Good luck.

sheppy99 · 2019-03-31T22:55:59Z

It's been 5 days now since I swapped the IR LED and as its still working I'm transferring a few settings to IR.
I've discovered is the lowest valid temperature setting on cooling is 18, sending anything lower is a valid command, and the unit resets the temperature to 18. This occurs immediately with IR and after a few seconds when sending via WiFi. The 18 degree minimum setting is already documented in the decoding sheet, so this post is for information only.

crankyoldgit · 2019-04-01T07:16:25Z

Okay. I'll create a PR shortly to set it to a min of 18C for Daikin2. Thanks for the info.

@sheppy99

@sheppy99 has found that the daikin2 A/Cs have a min temp of 18C. Add unit test coverage for IRDaikin2's `set/getTemp()` Ref: #644

@sheppy99

Per: #658 (comment) @sheppy99 believes this different min temp is only in cool mode. Adjust and add tests for this. Ref #644

@sheppy99

\@sheppy99 has found that the daikin2 A/Cs have a min temp of 18C when in Cool mode. Add unit test coverage for IRDaikin2's `set/getTemp()` Ref: #644

crankyoldgit · 2019-04-30T14:09:15Z

FYI, this has been included in the newly released v2.6.0 of the library.

crankyoldgit · 2019-05-18T02:29:38Z

@sheppy99 Any updates?

sheppy99 · 2019-05-18T02:50:08Z

Nothing other than I got back from holiday yesterday and Jetlag sucks! The AC is working OK albeit I haven’t updated anything for weeks.
Once my brain starts working again I’ll update things and report back as I guess I’m a long way out of date.
What version would you like me to test? Currently I assemble the full string in OpenHAB before sending it, would it help with development if I got the ESP to do some of the work?

crankyoldgit · 2019-05-18T05:20:28Z

The master branch is probably preferable at this point. Thanks. Enjoy the jetlag.

crankyoldgit · 2019-05-31T12:11:10Z

How's the jetlag?

sheppy99 · 2019-06-01T00:59:39Z

Much better thanks, have moved on to persuading the Daikin to switch between heating and cooling reliably by sending it different temperature commands. Simply changing modes makes it reset its vanes no matter how I set them which wakes me up when it does. Its too clever for its own good that thing!

Quick question, where is the easiest way to get the firmware for an OTA update? I'm using Arduino IDE

crankyoldgit · 2019-06-01T01:22:26Z

I believe these are the rough steps: https://randomnerdtutorials.com/bin-binary-files-sketch-arduino-ide/

sheppy99 · 2019-06-01T05:21:39Z

Thanks, I'll give it a try

crankyoldgit · 2019-06-11T11:46:30Z

Friendly chase up.

FYI, with the latest versions of IRMQTTServer, you can now control a lot of the common A/C settings via html/MQTT. i.e. You may not need to synthesise a code in Openhab anymore.

sheppy99 · 2019-06-12T00:07:36Z

Thanks for the chase :-)
Life has got in the way, and updating to the latest and greatest is on the todo list. Do you have any documentation on what IRMQTTServer needs when working in the normal mode?
Currently I'm struggling to get it to change over automatically without temperature spikes which is proving a challenge so I need to get that working before I can work on normalising the rest of it.
As the IR bit is stable I'm happy for you to close this and I'll reopen it if I find anything wrong.

crankyoldgit · 2019-06-12T02:08:36Z

The documentation is here: https://github.com/markszabo/IRremoteESP8266/blob/master/examples/IRMQTTServer/IRMQTTServer.ino#L157

sheppy99 · 2019-06-12T02:19:46Z

Thanks very much, this has grown considerably since I last played with it! I'll bear it in mind when I have time to take another look. Thanks also for your continuing support, you've created a superb bit of code!
If you live in either the Brisbane or Cairns area I'd like to buy you a beer next time I'm across the ditch

crankyoldgit · 2019-06-12T02:22:24Z

Brissy. So, sure. But I won't hold you too it.
Plus the jetlag is horrible, coming from NZ, you'd lose 2 hours AND ten years when coming to QLD. ;-)

sheppy99 · 2019-06-12T02:25:21Z

hahahaha, don't be so sure, things aren't that rosy over here.... How can I take this convo onto email?

crankyoldgit · 2019-06-12T02:35:42Z

done

crankyoldgit added a commit that referenced this issue Mar 17, 2019

Improve Daikin2 power on/off.

5a8111e

According to @sheppy99 in #644, power on/off control also depends on the MSB of state[6]. i.e. MSB = 1 (off), MSB = 0 (on)

crankyoldgit added the enhancement label Mar 17, 2019

crankyoldgit mentioned this issue Mar 17, 2019

Improve Daikin2 power on/off. #647

Merged

crankyoldgit added a commit that referenced this issue Mar 18, 2019

Improve Daikin2 power on/off. (#647)

7c5a162

According to @sheppy99 in #644, power on/off control also depends on the MSB of state[6]. i.e. MSB = 1 (off), MSB = 0 (on)

crankyoldgit added the more info label Mar 26, 2019

crankyoldgit added a commit that referenced this issue Apr 1, 2019

Update Daikin2's min temp to 18C

dc9c1d7

@sheppy99 has found that the daikin2 A/Cs have a min temp of 18C. Add unit test coverage for IRDaikin2's `set/getTemp()` Ref: #644

crankyoldgit mentioned this issue Apr 1, 2019

Update Daikin2's Cool mode min temp to 18C #658

Merged

crankyoldgit added a commit that referenced this issue Apr 1, 2019

Change only cool mode's min temp to 18C for Daikin2

0aeac59

Per: #658 (comment) @sheppy99 believes this different min temp is only in cool mode. Adjust and add tests for this. Ref #644

crankyoldgit added a commit that referenced this issue Apr 1, 2019

Update Daikin2's Cool mode min temp to 18C (#658)

f132de4

\@sheppy99 has found that the daikin2 A/Cs have a min temp of 18C when in Cool mode. Add unit test coverage for IRDaikin2's `set/getTemp()` Ref: #644

crankyoldgit closed this as completed Jun 12, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Further work on Daikin2 Protocol #644

Further work on Daikin2 Protocol #644

sheppy99 commented Mar 16, 2019

crankyoldgit commented Mar 17, 2019

sheppy99 commented Mar 17, 2019

crankyoldgit commented Mar 17, 2019

sheppy99 commented Mar 17, 2019

sheppy99 commented Mar 17, 2019

crankyoldgit commented Mar 17, 2019

sheppy99 commented Mar 17, 2019 •

edited

Loading

sheppy99 commented Mar 18, 2019

crankyoldgit commented Mar 18, 2019 •

edited

Loading

sheppy99 commented Mar 18, 2019

crankyoldgit commented Mar 18, 2019

sheppy99 commented Mar 18, 2019 via email

crankyoldgit commented Mar 26, 2019

sheppy99 commented Mar 27, 2019 •

edited

Loading

crankyoldgit commented Mar 27, 2019 •

edited

Loading

sheppy99 commented Mar 31, 2019 •

edited

Loading

crankyoldgit commented Apr 1, 2019

crankyoldgit commented Apr 30, 2019

crankyoldgit commented May 18, 2019

sheppy99 commented May 18, 2019

crankyoldgit commented May 18, 2019

crankyoldgit commented May 31, 2019

sheppy99 commented Jun 1, 2019

crankyoldgit commented Jun 1, 2019

sheppy99 commented Jun 1, 2019

crankyoldgit commented Jun 11, 2019

sheppy99 commented Jun 12, 2019

crankyoldgit commented Jun 12, 2019

sheppy99 commented Jun 12, 2019

crankyoldgit commented Jun 12, 2019

sheppy99 commented Jun 12, 2019

crankyoldgit commented Jun 12, 2019

Further work on Daikin2 Protocol #644

Further work on Daikin2 Protocol #644

Comments

sheppy99 commented Mar 16, 2019

crankyoldgit commented Mar 17, 2019

sheppy99 commented Mar 17, 2019

crankyoldgit commented Mar 17, 2019

sheppy99 commented Mar 17, 2019

sheppy99 commented Mar 17, 2019

crankyoldgit commented Mar 17, 2019

sheppy99 commented Mar 17, 2019 • edited Loading

sheppy99 commented Mar 18, 2019

crankyoldgit commented Mar 18, 2019 • edited Loading

sheppy99 commented Mar 18, 2019

crankyoldgit commented Mar 18, 2019

sheppy99 commented Mar 18, 2019 via email

crankyoldgit commented Mar 26, 2019

sheppy99 commented Mar 27, 2019 • edited Loading

crankyoldgit commented Mar 27, 2019 • edited Loading

sheppy99 commented Mar 31, 2019 • edited Loading

crankyoldgit commented Apr 1, 2019

crankyoldgit commented Apr 30, 2019

crankyoldgit commented May 18, 2019

sheppy99 commented May 18, 2019

crankyoldgit commented May 18, 2019

crankyoldgit commented May 31, 2019

sheppy99 commented Jun 1, 2019

crankyoldgit commented Jun 1, 2019

sheppy99 commented Jun 1, 2019

crankyoldgit commented Jun 11, 2019

sheppy99 commented Jun 12, 2019

crankyoldgit commented Jun 12, 2019

sheppy99 commented Jun 12, 2019

crankyoldgit commented Jun 12, 2019

sheppy99 commented Jun 12, 2019

crankyoldgit commented Jun 12, 2019

sheppy99 commented Mar 17, 2019 •

edited

Loading

crankyoldgit commented Mar 18, 2019 •

edited

Loading

sheppy99 commented Mar 27, 2019 •

edited

Loading

crankyoldgit commented Mar 27, 2019 •

edited

Loading

sheppy99 commented Mar 31, 2019 •

edited

Loading