Irremoteesp8266: Multi Channel common ac framework support in IRMQTTServer troubleshooting

[sheppy99]

Development of multi channel common ac framework support in IRMQTTServer.
To make life easy I'll refer to the new version as multi and the old version as single.
I'll leave all settings in IRMQTTServer.h as default apart from
kNrOfIrTxGpios = 5;
MQTT_CLIMATE_JSON true
MQTT_DISCOVERY_ENABLE false
GPIO Outputs are left as already set in the web interface of:
IR LED 0 = GPIO12 - this is different to the default set in IRMQTTServer.h but hasn't been a problem previously
IR LED 1 = GPIO4
IR LED 2 = GPIO5
IR LED 3 = GPIO16
IR LED 4 = GPIO13
Receiving test will be done with AC's and the MQTT output of another ESP8266 running IRMQTTServer.

First tests suggest there is a problem with sending commands. The aircon example codes don't work and neither do MQTT Commands. All GPIO settings were remembered in the web interface. and I've tried swapping channel 0 and channel 5 over, and then back again with a reboot in between in case this is deceptive.
Sending a JSON command to ir_server/ac/cmnd/json gets me a valid looking reply on ir_server/ac/stat/json
Changing back to the single version with no other changes allows everything to work again.

[crankyoldgit]

If you can, can you enable debugging (in the IRMQTTServer.h file) and capture the serial output?

I'll look at it shortly.

[sheppy99]

0000000.044: IRMQTTServer v1.4.1-alpha has booted.
0000000.054: Mounting SPIFFS...
0000000.076: mounted the file system
0000000.077: config file exists
0000000.077: Opened config file
0000000.078: Json config file parsed ok.
0000000.079: Recovered Json fields.
0000000.081: Closing the config file.
0000000.084: Unmounting SPIFFS.
*WM: Adding parameter
*WM:
*WM: Adding parameter
*WM: hostname
*WM: Adding parameter
*WM:
*WM: Adding parameter
*WM: http_user
*WM: Adding parameter
*WM: http_pass
*WM: Adding parameter
*WM:
*WM: Adding parameter
*WM: mqtt_server
*WM: Adding parameter
*WM: mqtt_port
*WM: Adding parameter
*WM: mqtt_user
*WM: Adding parameter
*WM: mqtt_pass
*WM: Increasing _max_params to:
*WM: 20
*WM: Adding parameter
*WM:
*WM: Adding parameter
*WM: mqtt_prefix
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.1.110
0000003.041: WiFi connected. IP address:
0000003.041: 192.168.1.110
0000003.871: MDNS responder started
0000003.872: HTTP server started
0000005.074: client mqtt not connected, trying to connect
0000005.075: Attempting MQTT connection to 192.168.1.69:1886...
0000005.075: Using password-less mqtt connection.
0000005.087: (Re)Connected.
0000005.088: Subscription OK to:
0000005.088: ir_server/send
0000005.088: Subscription OK to:
0000005.089: ir_server/send_0
0000005.092: Subscription OK to:
0000005.094: ir_server/ac/cmnd/+
0000005.098: Subscription OK to:
0000005.100: ir_server/send_1
0000005.103: Subscription OK to:
0000005.106: ir_server/ac_1/cmnd/+
0000005.109: Subscription OK to:
0000005.112: ir_server/send_2
0000005.114: Subscription OK to:
0000005.117: ir_server/ac_2/cmnd/+
0000005.120: Subscription OK to:
0000005.123: ir_server/send_3
0000005.126: Subscription OK to:
0000005.128: ir_server/ac_3/cmnd/+
0000005.132: Subscription OK to:
0000005.134: ir_server/send_4
0000005.137: Subscription OK to:
0000005.140: ir_server/ac_4/cmnd/+
0000005.143: IRMQTTServer v1.4.1-alpha just booted
0000005.147: successful client mqtt connection
0000005.151: Started listening for previous state.
0000005.156: Subscription OK to:
0000005.159: ir_server/ac/stat/+
0000005.162: Subscription OK to:
0000005.164: ir_server/ac_1/stat/+
0000005.167: Subscription OK to:
0000005.170: ir_server/ac_2/stat/+
0000005.173: Subscription OK to:
0000005.176: ir_server/ac_3/stat/+
0000005.180: Subscription OK to:
0000005.182: ir_server/ac_4/stat/+
0000006.488: Receiving data by MQTT topic:
0000006.488: ir_server/ac/stat/power
0000006.488: with payload:
0000006.489: on
0000006.489: Checking for channel number in ir_server/ac/stat/power
0000006.494: Channel = 0
0000006.496: It's a climate state topic. Update internal state and DON'T send
0000006.603: Receiving data by MQTT topic:
0000006.604: ir_server/ac/stat/mode
0000006.604: with payload:
0000006.604: heat
0000006.604: Checking for channel number in ir_server/ac/stat/mode
0000006.609: Channel = 0
0000006.611: It's a climate state topic. Update internal state and DON'T send
0000006.719: Receiving data by MQTT topic:
0000006.719: ir_server/ac/stat/temp
0000006.719: with payload:
0000006.719: 28.0
0000006.719: Checking for channel number in ir_server/ac/stat/temp
0000006.725: Channel = 0
0000006.727: It's a climate state topic. Update internal state and DON'T send
0000006.834: Receiving data by MQTT topic:
0000006.834: ir_server/ac/stat/protocol
0000006.835: with payload:
0000006.835: MITSUBISHI136
0000006.835: Checking for channel number in ir_server/ac/stat/protocol
0000006.842: Channel = 0
0000006.844: It's a climate state topic. Update internal state and DON'T send
0000006.951: Receiving data by MQTT topic:
0000006.951: ir_server/ac/stat/fanspeed
0000006.952: with payload:
0000006.952: high
0000006.952: Checking for channel number in ir_server/ac/stat/fanspeed
0000006.958: Channel = 0
0000006.960: It's a climate state topic. Update internal state and DON'T send
0000007.067: Receiving data by MQTT topic:
0000007.067: ir_server/ac/stat/model
0000007.068: with payload:
0000007.068: 1
0000007.068: Checking for channel number in ir_server/ac/stat/model
0000007.073: Channel = 0
0000007.075: It's a climate state topic. Update internal state and DON'T send
0000007.183: Receiving data by MQTT topic:
0000007.183: ir_server/ac/stat/filter
0000007.183: with payload:
0000007.183: on
0000007.183: Checking for channel number in ir_server/ac/stat/filter
0000007.189: Channel = 0
0000007.191: It's a climate state topic. Update internal state and DON'T send
0000007.298: Receiving data by MQTT topic:
0000007.299: ir_server/ac/stat/clean
0000007.299: with payload:
0000007.299: off
0000007.299: Checking for channel number in ir_server/ac/stat/clean
0000007.304: Channel = 0
0000007.306: It's a climate state topic. Update internal state and DON'T send
0000010.218: Unsubscribed OK from:
0000010.218: ir_server/ac/stat/+
0000010.218: The state was recovered from MQTT broker. Updating.
0000010.220: Difference in common A/C state detected.
0000010.225: Finished listening for previous state.
0000010.228: Unsubscribed OK from:
0000010.231: ir_server/ac_1/stat/+
0000010.234: Finished listening for previous state.
0000010.238: Unsubscribed OK from:
0000010.241: ir_server/ac_1/stat/+
0000010.244: Finished listening for previous state.
0000010.249: Unsubscribed OK from:
0000010.252: ir_server/ac_1/stat/+
0000010.255: Finished listening for previous state.
0000010.259: Unsubscribed OK from:
0000010.262: ir_server/ac_1/stat/+
0000010.265: Finished listening for previous state.
0000011.072: Receiving data by MQTT topic:
0000011.073: ir_server/ac/cmnd/json
0000011.073: with payload:
0000011.073: {"protocol":"MITSUBISHI136","power":"off","temp":"28","mode":"heat","fanspeed":"high"}
0000011.080: Checking for channel number in ir_server/ac/cmnd/json
0000011.086: Channel = 0
0000011.088: It's a climate command topic
0000011.094: Difference in common A/C state detected.
0000011.098: Sending common A/C state via IR.
0000013.203: Receiving data by MQTT topic:
0000013.204: ir_server/ac/cmnd/json
0000013.204: with payload:
0000013.204: {"protocol":"MITSUBISHI136","power":"on","temp":"28","mode":"heat","fanspeed":"high"}
0000013.211: Checking for channel number in ir_server/ac/cmnd/json
0000013.217: Channel = 0
0000013.219: It's a climate command topic
0000013.225: Difference in common A/C state detected.
0000013.228: Sending common A/C state via IR.

[crankyoldgit]

I think I've found it. Update coming in a sec.
Btw. I've changed the defaults for this branch to match your changed settings so there is less grief when compiling/uploading etc. I've also turned on DEBUG too.

Just remind me before I merge I need to revert those settings. ;-)

[crankyoldgit]

My limited testing has it flashing a TX LED (a non IR led I have set up for testing). So please download and try out.

[sheppy99]

Sweet, I just discovered the faulty version does work with my AV stuff on a couple of the other channels. I'll update now

[crankyoldgit]

Yeah. The mistake I found was solely on the "climate" side of things. Everything else should be fine.

[sheppy99]

The examples work now, but commands via JSON don't.
Command string
{"protocol":"FUJITSU_AC","model":1,"power":"on","mode":"heat","temp":28,"fanspeed":"auto","swingv":"auto"}
and
{"protocol":"MITSUBISHI136","power":"on","temp":"28","mode":"heat","fanspeed":"high"}

[sheppy99]

Looks like you didn't save the .h file,. I changed it, recompiled and now the default is working.
Should I also be able to send commands to /ac_0/cmnd/json?

[crankyoldgit]

D'oh!. You are correct. I forgot to save before I pushed.

See: https://github.com/crankyoldgit/IRremoteESP8266/pull/903/commits/a83ba75e48438ea1dc6071bd3f56ebded083cce9

[sheppy99]

Next question, should I get the same result on the default channel by sending to
/ac_0/cmnd/json
/ac/cmnd/json
If I should then that isn't working. Do you need debugging info?

[crankyoldgit]

Next question, should I get the same result on the default channel by sending to
/ac_0/cmnd/json
/ac/cmnd/json

yes and no.

Sending to ir_server/ac_0/cmnd/json should produce the same climate change & IR message as sending to ir_server/ac/cmnd/json .. but the "stat" will always go to ir_server/ac/stat/...

If I should then that isn't working. Do you need debugging info?

When have I ever said no to more data. :) Bring it on.

[sheppy99]

Not sure it'll tell you anything because the ir_server/ac_0/cmnd/json message doesn't appear in it, although the 8th line down may be interesting.
Looking at line 5 suggests the channel number should be part of the JSON?

0002707.304: Receiving data by MQTT topic:
0002707.305: ir_server/ac/cmnd/json
0002707.305: with payload:
0002707.305: {"protocol":"FUJITSU_AC","model":1,"power":"on"
0002707.308: Checking for channel number in ir_server/ac/cmnd/json
0002707.314: Channel = 0
0002707.316: It's a climate command topic
0002707.320: json MQTT message did not parse. Skipping!
0002707.325: NO difference in common A/C state detected.
0002707.431: Receiving data by MQTT topic:
0002707.431: ir_server/ac/cmnd/json
0002707.431: with payload:
0002707.432: {"protocol":"FUJITSU_AC","model":1,"power":"off"}
0002707.435: Checking for channel number in ir_server/ac/cmnd/json
0002707.441: Channel = 0
0002707.443: It's a climate command topic
0002707.449: Difference in common A/C state detected.
0002707.453: Sending common A/C state via IR.

[crankyoldgit]

0002707.305: {"protocol":"FUJITSU_AC","model":1,"power":"on"

Your json line is missing a } at the end. It's correct. It doesn't parse without it.

[crankyoldgit]

Hmmm .. it seems to work on _1 .. but not _0 channel. Looking into it more.

[sheppy99]

The mqtt message has a } on the end - I just checked. It’s also generated in a different part of the rules file from the publish command so whatever’s sent shouldn’t have changed. There also wasn’t an entry for ac_0 at all, the things in the log were for successful commands as I tried it with the default and then with ac_0 before trying the default again

_{Sent with GitHawk}

[crankyoldgit]

So, looking at the code, the ESP isn't subscribing to ir_server/ac_0/cmnd/+
I'll try to send a fix for that shortly. In the mean time .. please test the other channels .. they should work fine. e.g. _1, _2, & _3 etc ...

[crankyoldgit]

@sheppy99 Hopefully it should be fixed for _0/cmnd now. My limited testing seems to indicate it does.

[sheppy99]

sending a json to any of the other channels gives a json back on ac/stat/json and individual commands back on the other channels.
For example sending
{"protocol":"FUJITSU_AC","model":1,"power":"on","mode":"heat","temp":28,"fanspeed":"auto","swingv":"auto"} to ir_server/ac_4/cmnd/json
doesn't give me a message on ir_server/ac_4/stat/json but it does give individual messages for every item in the json command on ir_server/ac_4/stat/
I thought, perhaps wrongly that a json command on an individual topic would give a response on the same individual topic. In my usage case it probably doesn't matter although if individual json stat messages come back it does allow error checking to be introduced which is what I do with my SOnOff's.
I can only test in MQTT terms now, but I'll add an extra channel and test it tomorrow.

[sheppy99]

I've just seen your fix, I'll quickly try it on channel 0

[crankyoldgit]

Yep, that's a bug. It should send a response back on ir_server/ac_4/stat/json .. looking into it. May take a while, it's near meal time.

[sheppy99]

No worries, I'm going to call it a night and stare at the bigger screen for a while.
The fix works, I now have one unit sending to /ac/ and the other sending to /ac_0/ by way of proof

[crankyoldgit]

And I think I've fixed the response back on ir_server/ac_4/stat/json too!

Thanks for the testing and feedback thus far.

[sheppy99]

That's working and I'm now sending RAW to ac_0 (the Daikin2) and ac_4 (Fujitsu Type 1 and Mitsubishi136) with the correct status coming back. I'll add ac_5 (Fujitsu Type 5) later. I figured I'd work towards standardising all using the common ac framework, so I've started verifying Daikin2 with the original remote, I'll put the test bytes in the google sheet and open an issue for any errors.
Thanks for working on this :-)

[crankyoldgit]

Huzzah!

But um, why are you sending Daikin2 as "RAW"?

[sheppy99]

we're likely talking about different things, I mean the RAW HEX strings such as 53,11DA2700013642F0280C8004B016240000A9C38911DA270000392600B0000006600000C1906038

[sheppy99]

I think I've found a bug, and its a good one. It won't turn on the Model 5 Fujitsu on channel 4 but it will on channel 5 with the same GPIO PIN. I'm swapping the GPIO's over and changing the publish command. My GPIO's are 16,4,5,12,13,14, GPIO13 is connected to the Fujitsu, and GPIO0 is set to receive although there's nothing connected to it.
ir_server/ac_4/cmnd/json doesn't work and ir_server/ac_5/cmnd/json does work.
In both cases I get a message back on the relevant /stat/json but nothing is sent. As I'm not physically changing the GPIO PINS it's unlikely hardware. IRMQTTServer is compiled for 5 Outputs.
EDIT: I just tested the defective output with an IR LED and the other receiving IRMQTTServer. dumb sending works on channel 4, but not ac sending, so the bug's related to the framework.
Whilst this is going on the Framework works on channel 3
This isn't urgent as I'll just use it on ac_5 for now, and I'm unlikely to get to look at any fix until late tomorrow or Sunday.

Debug from ac_4
0000112.885: {"protocol":"FUJITSU_AC","model":5,"power":"on","mode":"cool","temp":18,"fanspeed":"auto","filter":"on","swingv":"auto"}
0000112.894: Checking for channel number in ir_server/ac_4/cmnd/json
0000112.901: Channel = 4
0000112.903: It's a climate command topic
0000112.909: Difference in common A/C state detected.
0000112.913: Sending common A/C state via IR.
0000119.872: Receiving data by MQTT topic:
0000119.872: ir_server/ac_4/cmnd/json
0000119.873: with payload:
0000119.873: {"protocol":"FUJITSU_AC","model":5,"power":"off","mode":"cool","temp":18,"fanspeed":"auto","filter":"on","swingv":"auto"}
0000119.882: Checking for channel number in ir_server/ac_4/cmnd/json
0000119.889: Channel = 4
0000119.891: It's a climate command topic
0000119.897: Difference in common A/C state detected.
0000119.901: Sending common A/C state via IR.

debug from AC_5
0000037.029: ir_server/ac_5/cmnd/json
0000037.029: with payload:
0000037.029: {"protocol":"FUJITSU_AC","model":5,"power":"on","mode":"cool","temp":18,"fanspeed":"auto","filter":"on","swingv":"auto"}
0000037.039: Checking for channel number in ir_server/ac_5/cmnd/json
0000037.045: Channel = 5
0000037.047: It's a climate command topic
0000037.053: Difference in common A/C state detected.
0000037.057: Sending common A/C state via IR.
0000037.306: Receiving data by MQTT topic:
0000037.306: ir_server/ac_5/stat/fanspeed
0000037.307: with payload:
0000037.307: auto
0000037.307: Checking for channel number in ir_server/ac_5/stat/fanspeed
0000037.313: Channel = 5
0000037.315: It's a climate state topic. Update internal state and DON'T send
0000037.425: Receiving data by MQTT topic:
0000037.426: ir_server/ac_5/stat/json
0000037.426: with payload:
0000037.426: {"protocol":"FUJITSU_AC","model":5,"power":"on","mode":"cool","use_celsius":"on","temp":18,"fanspeed":"auto","swingv":"auto","swingh":"auto","quiet":"off","turbo":"off","econo":"off","light":"off","filter":"on","clean":"off","beep":"off","sleep":-1}
0000037.447: Checking for channel number in ir_server/ac_5/stat/json
0000037.453: Channel = 5
0000037.455: It's a climate state topic. Update internal state and DON'T send
0000067.420: Receiving data by MQTT topic:
0000067.421: ir_server/ac_5/cmnd/json
0000067.421: with payload:
0000067.421: {"protocol":"FUJITSU_AC","model":5,"power":"off","mode":"cool","temp":18,"fanspeed":"auto","filter":"on","swingv":"auto"}
0000067.431: Checking for channel number in ir_server/ac_5/cmnd/json
0000067.437: Channel = 5
0000067.439: It's a climate command topic
0000067.445: Difference in common A/C state detected.
0000067.449: Sending common A/C state via IR.
0000067.626: Receiving data by MQTT topic:
0000067.626: ir_server/ac_5/stat/power
0000067.626: with payload:
0000067.626: off
0000067.626: Checking for channel number in ir_server/ac_5/stat/power
0000067.632: Channel = 5
0000067.634: It's a climate state topic. Update internal state and DON'T send
0000067.742: Receiving data by MQTT topic:
0000067.742: ir_server/ac_5/stat/mode
0000067.742: with payload:
0000067.742: off
0000067.742: Checking for channel number in ir_server/ac_5/stat/mode
0000067.748: Channel = 5
0000067.750: It's a climate state topic. Update internal state and DON'T send
0000067.860: Receiving data by MQTT topic:
0000067.860: ir_server/ac_5/stat/json
0000067.860: with payload:
0000067.860: {"protocol":"FUJITSU_AC","model":5,"power":"off","mode":"off","use_celsius":"on","temp":18,"fanspeed":"auto","swingv":"auto","swingh":"auto","quiet":"off","turbo":"off","econo":"off","light":"off","filter":"on","clean":"off","beep":"off","sleep":-1}
0000067.881: Checking for channel number in ir_server/ac_5/stat/json
0000067.887: Channel = 5
0000067.889: It's a climate state topic. Update internal state and DON'T send

[crankyoldgit]

0000067.750: It's a climate state topic. Update internal state and DON'T send
0000067.860: Receiving data by MQTT topic:
0000067.860: ir_server/ac_5/stat/json
0000067.860: with payload:
0000067.860: {"protocol":"FUJITSU_AC","model":5,"power":"off","mode":"off","use_celsius":"on","temp":18,"fanspeed":"auto","swingv":"auto","swingh":"auto","quiet":"off","turbo":"off","econo":"off","light":"off","filter":"on","clean":"off","beep":"off","sleep":-1}
0000067.881: Checking for channel number in ir_server/ac_5/stat/json
0000067.887: Channel = 5
0000067.889: It's a climate state topic. Update internal state and DON'T send

The above data is interesting. It should stop listening to the "stat" topics shortly after booting e.g. about 5-10 seconds. It shouldn't be subscribed to that channel anymore. No idea if that is the problem you are seeing or not.

I honestly can't think of any reason why channel 4 would be different to 1, 2, 3, & 5 unless it failed to allocate the memory correctly.

I'll take a look over the code. In the mean time, I'd suggest you clear any RETAINed MQTT settings for the _4 channel in your MQTT broker.

[crankyoldgit]

Hmm .. just checking. How many TX gpios have you compiled for? i.e. what is kNrOfIrTxGpios set to?

If it is '5' .. then the channels that should be working are:

the 1st one: ir_server/ac/cmnd/json (which also responds on: ir_server/ac_0/cmnd/json)
the 2nd one: ir_server/ac_1/cmnd/json
the 3rd one: ir_server/ac_2/cmnd/json
the 4th one: ir_server/ac_3/cmnd/json
the 5th one: ir_server/ac_4/cmnd/json
ir_server/ac_5/cmnd/json in theory shouldn't do anything unless you've changed it to 6 TX gpios.

[crankyoldgit]

Fix for that earlier "bug" I saw has been pushed to the branch.
and "ah" I see you've must have changed it to 6.

[sheppy99]

kNrOfIrTxGpios = 6;
I was experimenting, I currently only need 5, but when the bugs fixed I'll move to 6 so I can separate the 2 AC's that are currently on the same channel. I redid the board for 7 channels for when I think of something else to automate :-) For now channel 6 is connected to an LED pointing at the other IRQTTServer so it can be used for testing

[crankyoldgit]

Left field things to think about/look at:

• The hard coded default RX GPIO is const int8_t kDefaultIrRx = 14; // <=- CHANGE_ME (optional)
  Maybe the code isn't changing the RX value via the GPIO page? Is that gpio you are having issues on?
• GPIO 13 is the on-board LED for most ESP dev boards ... maybe that's interfering? (e.g. I just configured my channels to match your settings and I noticed the ESP8266 module's on-board LED is now full on bright blue. :)

[sheppy99]

To test the latest stuff when I get time do I load the branch of the library updated for Daikin2 and then use this branch for IRMQTTServer?

_{Sent with GitHawk}

[sheppy99]

The weird thing is it’s not GPIO specific as I find the same one works when allocated to channel5 but not channel4. I will experiment though. It is like channel 4 is sending out on the wrong GPIO or not at all. I’ll also try allocating channel 4 to another GPIO that’s not GPIO14 or GPIO13

_{Sent with GitHawk}

[crankyoldgit]

I replicated your setup (without your hardware/pcb obviously) and I'm using the latest from that branch.

From my "info" page:
IR Send GPIO(s): 16 (default), 13, 5, 12, 4, 14
IR Recv GPIO: 0

I swapped 13 & 4 around as I have a traditional (RED) LED attached to GPIO 4, My on-board LED is ON by default now (due to being active low) because GPIO 13 is allocated as a TX.

I'm seeing the RED led flashing as you would expect (an IR led) it to when a message is sent.
e.g.
mosquitto_pub -h 10.0.0.4 -t testing/ac_4/cmnd/json -m '{"protocol":"FUJITSU_AC","model":5,"power":"on","mode":"cool","temp":18,"fanspeed":"auto","filter":"on","swingv":"auto"}'
All the logs and mqtt stat's match up with it working as expected.

So that's the same thing as your setup EXCEPT it's not GPIO 13.

[sheppy99]

Interesting. I’ll try GPIO5 on channel 4 to see what happens. I’ll also play with putting LED’s on the test version to see if the problem is the same

_{Sent with GitHawk}

[crankyoldgit]

just so it's clear. I had GPIO 4 (D2) allocated to the 5th TX LED, which is channel _4 .. and I had compiled it to have 6 channels like your setup.

[crankyoldgit]

and it was working as expected.

[crankyoldgit]

Set all 6 TX GPIOs to GPIO 4, and testing ac/cmnd/json, & ac_0/cmnd/json through ac_6/cmnd/json

All flashed the LED connected to GPIO 4, _except_ ac_6/cmnd/json which is to be expected as that's the 7th TX slot, and it isn't compiled to have that many.

And now I've put the RED led on GPIO 13 (D7 on my nodemcu board) and it works fine on _4. Go figure.

So, I feel it might be something GPIO 13 specific on your board, or something totally left-field or something. Or .. maybe my earlier fix fixed it. _shrug_

[sheppy99]

I’ll give it a test when I get chance. I’ll also spend some time trying to tie it down. Thanks for your help

_{Sent with GitHawk}

[sheppy99]

I updated it and nothing changed, so I downloaded MQTTExplorer and despite all the ac_4/stat retained messages looking OK I deleted them and restarted MQTTServer. It now works. I'll keep an eye on it for the rest of the weekend and let you know if it keeps working. Previously I used channel 4 for decoding tests so maybe something got left behind, it certainly had more stored topics than the rest of them.
Assuming all is well I'll split the 2 AC's that share a channel onto their own and then test the Daikin2 changes.
Ignore the close and reopen errors above, The GitHawk app has a confusing icon that closes and reopens issues

[crankyoldgit]

Excellent! Because I was out of ideas as to what might have been causing it, code-wise.

[sheppy99]

I’ll expand it to 6 channel use next week and give Daikin2 a full test. Thanks again for all your help

_{Sent with GitHawk}

[sheppy99]

An update to this, it’s working well with common ac framework on 4 channels so far.

_{Sent with GitHawk}

[crankyoldgit]

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