Further work on Daikin2 Protocol

[sheppy99]

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:

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

[crankyoldgit]

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

[sheppy99]

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]

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

[sheppy99]

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]

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]

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]

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

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]

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]

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

[crankyoldgit]

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]

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 notifications@github.com<mailto:notifications@github.com> 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 GitHubhttps://github.com/markszabo/IRremoteESP8266/issues/644#issuecomment-473773382, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMTzpOvwbJ5rVteeWzJ4GpdN2zH0UVauks5vXyHzgaJpZM4b4Eq6.

[crankyoldgit]

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

[sheppy99]

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]

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]

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]

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

[crankyoldgit]

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

[crankyoldgit]

@sheppy99 Any updates?

[sheppy99]

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]

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

[crankyoldgit]

How's the jetlag?

[sheppy99]

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]

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

[sheppy99]

Thanks, I'll give it a try

[crankyoldgit]

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]

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]

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

[sheppy99]

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]

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]

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

[crankyoldgit]

done