Irremoteesp8266: Incorrect functions In common ac framework for Daikin2

[sheppy99]

I've tested the common ac framework against my Daikin2 Remote and looking at the MQTT JSON output on ir_server/ac/stat/json It works the AC, but a few functions are incorrect.
I've put the results in the google sheet on a new tab called "framework." For each error I've added a set of strings to the "test sheet" tab selected function (column A), byte/nibble controlling it (column B) the correct value (column C) and the full string of the message (column D)

[crankyoldgit]

For the record, that's: https://docs.google.com/spreadsheets/d/1f8EGfIbBUo2B-CzUFdrgKQprWakoYNKM80IKZN4KXQE/edit#gid=671122011

[crankyoldgit]

Any chance you could stack/format the correct and incorrect codes above each other? Makes it easier for me to see the difference.
e.g.

Correct | Comment | Byte | Correct Value | raw
-- | -- | -- | -- | --
Correct |Auto | 28L | A | 53,11DA2700014942B0280C8004B016240000AAC35D11DA270000093C00A0000006600000C190600E
Wrong| | | | 53,11DA2700014A42B0280C8004B016240000AAC35E11DA270000093C00B0000006600000C190601E

[sheppy99]

Will do in future, I was doing it from a decoding perspective,
Having reread your comment would you like me to redo all of them?

[crankyoldgit]

I was waiting till you told me you found all the errors etc before I started in earnest

[sheppy99]

That's all of them, there's only the intelligent eye which IIRC we removed, and the default is off which is how I run it. At some stage I need to see if there is a solution to it moving the vanes when it switches from cooling to heating, in the middle of the night as the noise wakes me up, but it does that when the relevant IR bits which aren't changed between modes.

[crankyoldgit]

Blah blah blah ... https://github.com/crankyoldgit/IRremoteESP8266/tree/daikin2_changes

Doesn't contain the multi stuff ... blah blah blah.

[sheppy99]

Sweet, will test it in the morning, currently trying to work out why my second Fujitsu won't work from the ESP - swapping channel over electrically to a different working port doesn't change it, both ports work the other Fujitsu, yet it works with both remotes and also the raw fed USB dongle. Its the only one I'm running without a stick on IR LED.

[crankyoldgit]

Branch updated for SwingH stuff.

[sheppy99]

Thanks very much for all your help, will give it a test tomorrow and report back

[sheppy99]

Good Morning, I'm reworking my IR PCB to add more channels, and changing the IR LED for the High Wall Fujitsu to a stick on unit, will test Daikin2 once its done

[crankyoldgit]

Good luck

[sheppy99]

7 channels and its getting a bit crowded. Other GPIO's brought out in case they are ever needed.

Is IRMQTTServer likely to work at both decoding and sending at the same time, if I join 2 GPIO's together on the sane device and call one an output and one an input could I get the full sent byte string?

[crankyoldgit]

If you tie an output to an input at the electronics level I think you're in for a world of trouble. But electronics is not my forte. Far far from it.

[sheppy99]

There is a way of doing it safely by using a current limiting resistor between pins to limit the current in case both pins are set as output, maybe on startup and put out different voltages. The question is more about whether I can send a packet and have it send and decode it at the same time. Has the ESP8266 got enough power to do that?
On another note I've spent all day chasing a possible bug in the multi version so I'll likely test this next week now

[crankyoldgit]

The question is more about whether I can send a packet and have it send and decode it at the same time. Has the ESP8266 got enough power to do that?

Can it do it, yes. There is an option in there to enable it. The default is it stops listening for the brief time it's sending. e.g. ~1/10th of second or so. The better questions is "Should you?". It depends if the receiver module can see the TX IR LEDs and if you have it configured to re-transmit incoming IR a/c messages.

[crankyoldgit]

In all the other issue traffic, I'm not sure if you tested this or not, and if so, what the feedback was?

[sheppy99]

I haven’t yet, although I have just recompiled it to 7 channels and had a fight getting the framework to work again. This time around it was ac_3 playing up. Multiple changing of GPIO’s around and several clears of retained messages finally got it all to work so DAIKIN2 is next for testing. Is it a lot of work to add a “delete all retained messages and reboot” option?

[crankyoldgit]

Log a feature request. :)

[sheppy99]

done! This will be fantastic when its finished!!!

[crankyoldgit]

I must admit, I'm concerned what might be causing the corruption.
As you've got it (multi) all working. I might back out your "personal" settings and merge the "multi" branch to master, and then you can have the dakin2 stuff and multi at the same time.

[sheppy99]

My guess is its down to swapping channels around with different AC's. and possibly that the broker hasn't cleared all the messages before its read them again. If it does it again I'll unplug IRMQTTServer, clear the messages and then plug it in again. Its downstairs so I haven't done that yet.
I've now got a spare channel pointing at a receiver so I can do the Daikin2 test easier.
I'll head out to Jaycar now if you want to do the merge and I'll change my settings on compile when I get back if you want to merge it

[crankyoldgit]

Branch https://github.com/crankyoldgit/IRremoteESP8266/tree/daikin2_changes has been updated to the current master branch (i.e. the Multi stuff)

[sheppy99]

I'm wondering if I've got the correct branch - take a look at the Fan tests and Swing Vertical on the spreadsheet. I used the examples from the sheet and sent the full hex string to the receiver and its decoding isn't correct. I used the link in the last post and downloaded the zip file. IRMQTTServer is showing v1.4.1-alpha

[crankyoldgit]

I don't think I saw the "vertical" stuff before, or if I did, I missed it. Sorry.

Also, to be fair. I'm very confused by the structure of the "Test Sheet". Especially Cols A-D
If you could be clear or verbose as to what the issues are, that would be grand.

[sheppy99]

Sure, can you tell me what states are available in the framework for :
swingv and fanspeed please

[crankyoldgit]

See: https://github.com/crankyoldgit/IRremoteESP8266/blob/master/src/IRsend.h#L44-L113

[crankyoldgit]

Another update to the branch. Most of the feedback/comments are in the spreadsheet now.
I've added unit tests to confirm my theories/comments in the spreadsheet's comments.
e.g. I think you've recorded something incorrectly for the anomalous fan speed setting. i.e. It reads as medium to me, not auto.

[sheppy99]

All tests good now apart from swingv which is OK apart from setting swing or auto on the remote both decoding as auto. Seem to remember you were coding auto on the remote as off in framework?
auto on the remote means it does whatever it thinks is the best for its current mode. As the flap motors on my unit make more noise than the fan I don't use either of those modes

[crankyoldgit]

Seem to remember you were coding auto on the remote as off in framework?

Yep. I missed part of what was required to change it. My bad.

I just updated the branch and it should fix that as of now. Let me know how it goes.
(also the branch now has the option to enable clearing of the retained settings, you will need to enable that at compile time for it to show up.)

[sheppy99]

Clear messages works, but the vertical swing is proving a bit tricky to tie down. positions 1-6 work and both swing and auto on the remote come up as auto in the framework BUT after reading the manual it seems there could be more to it. Extra modes "Breeze" "Circulate" and "Auto" have other options hidden away in the setup menu to do with the magic eye. I'll try and tie it down later this week

[crankyoldgit]

I've changed the "native" swingv values for auto & swing to what I think they should be.
Download and try it out please.
"Breeze" "Circulate" are not going to be supported under common. If they are received via IR, they will be interpreted as "native" auto, which per your request, is mapped to "common"s off.

[crankyoldgit]

FYI, the changes mentioned above are included in the newly released version of the library (v2.6.6).