-
Notifications
You must be signed in to change notification settings - Fork 836
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Daikin SetTemp to half degrees #1829
Comments
If you can decode and work out in the protocol how it does half degrees, we can add it. |
I used the IRrecvDumpV3 example and recorded 2 signals: 1st is 21,5°C 11:01:42.763 -> Protocol : UNKNOWN 2nd is 22,0°C 11:01:48.850 -> Timestamp : 000022.580 I would have expected to have more bytes the same, but they look totally different. The remote used is an ARC466A67 I think the dump works, if more sinals needed, no problem. |
It says unknown, which means the protocol is not detected. Verify that your receiver is good. If you still get unknown after that, then please post a full temperature range (lowest to highest) Ang give all the raw data. Please include model of unit as well. (All this is covered in the FAQ) |
Ok, fist of all some more information: Manufacturer DAIKIN The remote ist called ARC466A67 Now the full list from 18,0°C to 32,0°C in 0,5 steps 19:03:05.621 -> Timestamp : 000465.020 |
I'm supprised, and maybe you have an hint. Is it possible that the AC does understand different protocols? |
Yes, We have seen some A/Cs accept multiple different protocols before. It might be to help owners who've lost their original remote. Dunno. Our previous raw data samples of a So, it's fairly clear your remote uses a different protocol. i.e. Not one the library supports. No reason it can't, it just needs a lot of work. That probably also explains the "it doesn't do half degrees" issue. If you really want support, we/you will have to follow https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-IR-protocol & https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol |
We should have enough to do step one already with the above raw dumps? |
Because the AC is also controlable with the DAIKIN App, I can confirm that at least the half degree steps are transmitted via IR. I can read the changes from the app. Personally I think this could be an approtch by the manufacturer to be better than others and therefore I think some effort should be spent to get this solved also for future devices. I puttet all my output in individual files (named without comma) and run them via your python script. The output is very simmelar if 2 steps are compared (example 18,0 and 18,5 degrees, Find it also in the list of files marked with *.out.txt 18,0 °C: Guessing encoding type: Guessing key value: Decoding protocol based on analysis so far: kBitMark(UNEXPECTED)00000GAP(25108) Total Nr. of suspected bits: 317 18,5°C Guessing encoding type: Guessing key value: Decoding protocol based on analysis so far: kBitMark(UNEXPECTED)00000GAP(25110) Total Nr. of suspected bits: 317 I marked the difference in bold , maybe you can tell me based on your experieance if it makes sense to continue 180.txt |
Thanks for the extra data. I'll look at coding up basic (ie. hex) support for it soon. |
I did some more capturing: Cooling 21°C Fan Auto Off (but set to Cooling 21°C Fan Auto) Cooling 21°C Fan Level 1 Cooling 21°C Fan Level 2 Cooling 21°C Fan Level 3 Cooling 21°C Fan Level 4 Cooling 21°C Fan Level 5 Even more modes you find in the files atteacehd. I also run the python program |
- Add `sendDaikin312()` & `decodeDaikin312` routines. - Unit test coverage for new protocol. - Bit Ordering assumed to be the same as other Daikin Protocols. For #1829
@AntonWert I've written the code to do basic sending and decoding of your 312 bit / 39 byte Daikin A/C Protocol. As we have plenty of other Daikin Protocols, we are fairly sure we have the correct bit ordering for the protocol, as they all use the same. i.e. You can skip: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#determining-the-bit-order-of-the-protocol Good luck with the analysis in advance, looking forward to hearing from you soon. |
I'm currently bussy during the week, I will test on weekend and come back to you. Thanks for the effort so far |
I already had a peak to look inside, and based on the changes i found sendDaikin312 Do I have to call the function myselv? or should I define something like #define SEND_DAIKIN312? |
Just run If everything works as it should you don't need to look at the raw data any more, and instead only look at the "code" |
Thank you. I was compleatly on the wrong path and thougt i should transmitt the data to the AC. Now I got it. Well, 1st result: 21:43:48.481 -> Timestamp : 000005.589 Now I should use the spreadsheet to decode the data as in the example above |
- Add `sendDaikin312()` & `decodeDaikin312` routines. - Unit test coverage for new protocol. - Bit Ordering assumed to be the same as other Daikin Protocols. - Update supported model information For #1829
I could not wait , and have tested a loot of settings in an XLS Shee t Following Results: Resluts: |
And here is my XLS |
Any chance you could upload this to Google docs or sharepoint and share the link (don't forget to set public readable) one reason is that not everyone has a xlsx reader. |
Not really, but I could save as CSV |
I created a PDF so everyone could at least read the data |
Is there something I can now provide? |
I will try to find time to look at this. I've been very busy of late with other things. |
The FAQ explains next step. |
Dears, I used this .ino file to witch was the former exaple, to confirm that the built is compilable: (please rename to ino, i was not able to upload the ino file) I added the class based on Daikin2 into these files: May anyone (or even better @crankyoldgit - may you confirm) that this was the right way? Also I would be happy about any comments/help/advice.... |
Thanks, i need to emulate an ARC466A67, but i'm actually not able to compile a firmware with DAIKIN312. Still didn't understand which parts of DAIKIN312 are already part of the stable build Tasmota 12.3.1. Does anybody know if the "Bedarfssteuerung" is accessible via ir? |
Hi, got a build on my own with your changes, but it does not work. :( Always getting: Sending: I tried to debug, but didn't get it. I don't know why the vendor list ends with "BOSCH144", but in "IRremoteESP8266.h" it ends with "DAIKIN312". I tried to shorten it there and in "IRtext.cpp", but without success. Any ideas? My settings: ARC466A67 with Perfera (2MXM40N + FTXM20R + FTXM20R) and Pearl NX-4519-675 |
With the Files I posted above, it was compailable for me using latest Arduino. |
@AntonWert can you compile an tasmota-ir version and upload it? I still get the "wrong vendor" failure. Maybe my call is still wrong: |
First of all, I was able to test now my version with the real DAIKIN AC and got it to work (at least fo far for the functions I need). But I built with Arduino. @Nawile : I do have Platform IO and downloaded the current source of tasmota. I was able to built the tasmota-ir as supplied from github.
I replaced the 2 files (latest version atteaced) in the subfolder |
Thanks @AntonWert . Getting the puzzle piece by piece. I can compile and send DAIKIN312 via "IRSend". Maybe this was my Problem. @AntonWert: How can you send (encode) the parameter like The "IRHVAC" command still doesn't work, because several entries aren't made in files "IRac.cpp" and "IRac.h". I wasn't able to made them, because i still don't understand the encode parameter to build correct classes. |
Just for clarification. I use the library (and did therefore the extention) on a WemosD1mini. For sending the data to the AC i do have my own function:
These functions seem to work since I posted them. @Nawile: with these circumstances, what do you mean with encode parameters? this is done by the IRDaikin312 class now |
Ok, here we go. :) I modified the files "IRac.cpp" and "IRac.h" and got an runable image. I just used code from DAIKIN2. Now i need some more modification to add parameters for "eye" and others. Now i got some issues and questions:
@AntonWert, thanks. And it's pitty, that you aren't using Tasmota. Edit:
|
Thanks for your feedback @Nawile . |
Here are my actual versions: I'm trying to support the eyes... |
I could not stop and just had a look on struct state_t |
I've added them to I'm also don't understand why the eye-state isn't shown in the console output. I guess it is using Edit: EyeAuto seems not to be the "comfort airflow" (ca). Maybe the ca is part of SwingH similar as the "indoor unit quiet operation" is part of fanspeed. SwingH positions or "comfort airflow" would be very nice features to use. Edit2: Eye seems not to work and swapped in decode.
|
So first of all for the swing. I checked the manual and there it is stated that you only can turn on swing, or stop it at the current position. According the manual there is no option for a fixed positoning. With the eye it seems to be difficult to test, but maye it is fixed now due to moving from byte 13 to 36 from my remote IR debuggung. |
ir_Daikin.h.txt |
Yeah great. I had to uncomment all the positions, because .cpp has to be adapted... Realy great would be control off comfort airflow. |
That is strange. |
Yes, i think so. My smart home device send with std Tasmota ir an DAIKIN-protocol and it stops. I can test on tuesday again. |
If I chek the IR signals of my remote, I can clearly see the bit turning the function on. And it does so, as you have confirmed. @Nawile have you confirmed this with the onecta app? |
@AntonWert : The Onecta app doesn't show the state of the eye. You can't control ist there. Daikin makes imho a poor job building their firm-/software. Maybe there is just an delay. I'll test it asap (Just got ill). But the test is just viewing the device behavior. |
Is there a possibility to get the new develloped code now in the official project? |
@Nawile: There was just an update to the Onecta app binging new functions, maybe this helps |
Sorry, i've got to much to do und had no time. Hope this will change soon. There ist an firmware update available, but it seems to be faulty. The "Bedarfssteuerung" seems to vanish, if you are using Perfera like me. But i need "Bedarfssteuerung", so i'm not going to update. Daikin also seems not interested in fixing these things soon. |
I did the update, and found no issue rigth now. Do you have any idea how to get this library officially changed with the new features we added? |
Hi, Canwe find a way, to add this to the man library? |
You need to submit your code as a PR, that is how code gets merged into the main branch. See: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests |
Sorry, I do neither have GIT nor any forked library. |
Hello,
great library, works well with my Daikin.
Just one thing: with the origianl remote you can set the temperatures to half degrees. But the temperature parameter is only int. Is there a chance to add the half degrees as well?
The text was updated successfully, but these errors were encountered: