Irremoteesp8266: How to use common a/c framework?

[sheppy99]

Is there any documentation of how to use the new common a/c framework? For example if I want to turn my Fujitsu AC on I'd expect to send:
Power: ON
Mode: Cooling
Fan: Auto
Temperature: 18
Swing: On
How is this formatted in the MQTT message? Apologies if I've missed how to do this but I couldn't find it.
With my old lookup USB IR setup I had to record every IR message and play it back RAW, hopefully there is an easier way?

[crankyoldgit]

Instructions are in the source code: https://github.com/crankyoldgit/IRremoteESP8266/blob/master/examples/IRMQTTServer/IRMQTTServer.ino#L166

ir_server/ac/cmnd/protocol FUJITSU_AC
ir_server/ac/cmnd/model ARREB1E  // Or "3" or what ever the correct supported model is got your a/c
// The above should only need to be sent once. The ESP will remember that.
// The rest are just sent individually as you need/want to change them.
ir_server/ac/cmnd/power on
ir_server/ac/cmnd/mode cool
ir_server/ac/cmnd/fanspeed auto
ir_server/ac/cmnd/temp 18
ir_server/ac/cmnd/swingv auto

Or set it via the "Aircon" http page/interface & copy and use the ir_server/ac/stat/... payloads from you mqtt server. i.e. It sends the current status to the stat topics. Commands (changes) need to be sent to the cmnd topics.

[sheppy99]

I missed that thanks.
What happens when IRMQTTServer is used to control more than one AC and also 2 on the same channel? I've got 4 units that I'm planning to split over 3 channels.
Daikin2 is working well on Channel1 currently using a full string of bytes generated from OpenHAB
The AV Gear on Channel2 and 3 is working well
I'm about to introduce a Fujitsu on Channel4 maybe using the common a/c framework and
A different Fujitsu on Channel5 together with a Mitsubishi Electric
Is it easier with my case if I stick to generating the individual bytes for each unit and sending them to IRMQTTServer that way? Currently they send the RAW timings from a USB dongle that occasionally screws up.
Apart from the Daikin2 and the AV stuff its all at the design stage so I can do whatever makes sense, and it makes sense to take the easiest path

[crankyoldgit]

Currently it (the common a/c stuff) only supports the first channel.

Let me guess, I should anticipate a "feature request" issue soon to support a common a/c "climate" per channel. ;-)

[sheppy99]

TBH I reckon my usage case is getting pretty extreme and likely not worth the effort especially as I'm transferring an existing system. I seem to remember sometime back that the you told me the library is capable of working out the checksum? if it does what do you send it, for example a complete received string from IRMQTTServer is
33,1463001010FE09302101040000002882
which presumably includes its checksum, do I need to recreate this in full or can I leave off the last byte and it will work out the checksum?

[crankyoldgit]

I seem to remember sometime back that the you told me the library is capable of working out the checksum?

It only will calculate the checksum for a protocol if you send it via one of the supported C++ class methods. e.g. ac.setRaw(hex_code) or via the "common" a/c api.
Sending it via 33,1463001010FE09302101040000002882 methods. e.g. irsend.sendBlah(hex_code) does not calculate checksums for you. That approach assumes you know _exactly_ what you are sending and for it to _exactly_ what you ask.

See also: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Frequently-Asked-Questions#Why_is_the_raw_data_for_a_button_or_AC_state_always_different_for_each_capture
Only the "fluent" (aka "deep" or "detailed" support) level of support can calculate checksums typically.

[sheppy99]

Thanks for the clarification, I'll take a look in the Fujitsu files to see if I can work out how its done. As I have the Daikin working reliably it'll be easy to copy / edit / paste the generation code including the checksum bit. If I can't easily work it out I'll just record the raw codes, it doesn't take that long :-)

[crankyoldgit]

But I've already started on supporting multiple channels for the climate/common a/c interface... :-)

[sheppy99]

Hahahaha, well if you see it as a challenge then I'll test it for you if you give me a hand with implementing it, assuming it doesn't need its own broker due to the number of messages ;-)
I wonder if there's a case for sending and receiving the commands as JSON?
In the meantime I'd better get on with reverse engineering the ducted Mitsubishi

[crankyoldgit]

JSON is already in there. It's turned off by default I think. Read the comments/header file.

[crankyoldgit]

See: https://github.com/crankyoldgit/IRremoteESP8266/blob/master/examples/IRMQTTServer/IRMQTTServer.h#L101

[sheppy99]

Perfect, that makes life a lot easier. Regarding decoding the Mitsubishi Electric, how would you describe a checksum that takes one value in hex and takes it away from "F" to produce the checksum. For example if the original value is "3", the checksum is "C"
So far I've found the temperature, mode, power and fan speed do it this way with the ducted, as does the vane function which I just decoded to check my theory

[crankyoldgit]

So far I've found the temperature, mode, power and fan speed do it this way with the ducted, as does the vane function which I just decoded to check my theory

Excellent. I look forward to the Google Sheet spreadsheet link! ;-)

how would you describe a checksum that takes one value in hex and takes it away from "F" to produce the checksum. For example if the original value is "3", the checksum is "C"

I think you just did. That's a fine enough description for me to code up if you include the range of values it calculates over.

[sheppy99]

I've just updated the google sheet with an extra tab for the Mitsubishi Electric Ducted full decode, albeit the remote supports more features than I can test so I've stuck to the main ones plus "vanes" which isn't tested as its not supported by my unit. Same link as with Daikin2 -
https://docs.google.com/spreadsheets/d/1f8EGfIbBUo2B-CzUFdrgKQprWakoYNKM80IKZN4KXQE
Time to turn on JSON and check the Fujitsu has everything I need :-)

[crankyoldgit]

I've left some comments on the sheet.
Excluding the header bytes, I think the last half of the message is actually just a straight binary inversion of the first half. (Think of it as a straight bit flip)
i.e. No checksum at all actually.

e.g. 0x0 (0b0000) -> 0xF (0b1111), 0x1 (0b0001) -> 0xE (0b1110), ..., 0xC (0b1100) -> 0x3 (0b0011)

For example:

0x00C2C7040000FF3D38FBFFFF -> 0x00C2C7040000 and 0xFF3D38FBFFFF 
0x00C2C7040000 -> 0b000000001100001011000111000001000000000000000000
0xFF3D38FBFFFF -> 0b111111110011110100111000111110111111111111111111

[crankyoldgit]

I'll let you confirm that theory. But if it holds up, we may be able to shrink this protocol from 17 bytes down to 11 bytes.
i.e.
5 header bytes + 3 command bytes + 3 "fixed" bytes + 3 checksum bytes + 3 footer bytes == 5 header bytes + 3 command bytes + 3 "fixed" bytes (11 bytes) (and then just calculate & send the inverted command + fixed bytes (6 bytes)) == 17 bytes total

[crankyoldgit]

Also. let me know when you've got something working with the "climate"/common ac interface working and you're happy. I think I've got a version that works with multiple "climates" now that I'd like your help testing it when you're ready.

[sheppy99]

OK, I haven't done anything apart from decode the ducted unit and discover the compilation problem with JSON turned on doesn't work so far so whats the better way to proceed? Should I wait for the JSON compilation problem to be ironed out and then send JSON commands to one of my Fujitsu's or is it easier to add support for this ducted to the library and wire it as the default unit to test the existing single IRMQTTServer with? In my case I think using JSON makes adapting my current rules the easiest as they are all based upon sending a shorthand for what I need such as H21L which translates to Heating, 21Degrees, Low Fan Speed. The Daikin2 is worked in a similar manner albeit the protocol is created by serializing each bytes before sending.

[crankyoldgit]

I'll probably fix the JSON compile issue within an hour or so. Currently away from keyboard. :-)

[sheppy99]

I've started testing with JSON and I can't seem to get it to work, can you see anything wrong with sending

{"protocol":"FUJITSU_AC","model":1,"power":"on","mode":"heat","temp":20,"fanspeed":"auto}

to Testir_server/ac/cmnd

in the info page of IRMQTTServer it says

Last MQTT command seen: (topic) 'Testir_server/ac/cmnd/json' (payload) '{"protocol":"FUJITSU_AC","model":1,"power":"on","mode":"heat","temp":20,"fanspeed":"auto}' (21 seconds ago)
Yet I don't get a corresponding JSON confirmation from Testir_server/ac/stat/json
Sending json with all options copied and pasted from the stat topic with the temperature changed causes it to reboot

{"protocol":"FUJITSU_AC","model":1,"power":"on","mode":"cool","use_celsius":"on","temp":20,"fanspeed":"auto","swingv":"auto","swingh":"auto","quiet":"off","turbo":"off","econo":"off","light":"off","filter":"off","clean":"off","beep":"off","sleep":-1}

[crankyoldgit]

Are you building it with the Arduino IDE or with PlatformIO?
(The later uses MQTT_MAX_PACKET_SIZE=768) ... just seeing if that is the problem.)

[crankyoldgit]

Also, can you create a new issue for this/these "json" issues.

[sheppy99]

I’ll check that in the morning and will file an issue for anything that isn’t working :-)
It’s built with Arduino IDE so I’ll check it and retest if it’s not right

[crankyoldgit]

in the info page of IRMQTTServer it says

Last MQTT command seen: (topic) 'Testir_server/ac/cmnd/json' (payload) '{"protocol":"FUJITSU_AC","model":1,"power":"on","mode":"heat","temp":20,"fanspeed":"auto}' (21 seconds ago)
Yet I don't get a corresponding JSON confirmation from Testir_server/ac/stat/json

The reason you didn't get a corresponding confirmation is that json string isn't valid.
e.g.
"fanspeed":"auto} -> "fanspeed":"auto"}

But if you had gotten it to be valid, it would have crashed. :-/

I think I've found what was causing the crashing.
Technically "model" is a string, not an integer.
e.g.
"model":1 -> "model":"1"

But it shouldn't crash, that's a bug. My fixes stop it from crashing and handle the "model":1 case now too.

[sheppy99]

Your fix works thanks, I can now send JSON commands and get a full status returned

[crankyoldgit]

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