IRMQTTServer and AKB74955603

[kzagatti]

Moving from #1513

@crankyoldgit good morning!

Upload/use a very small intermediate OTA program. e.g. https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266HTTPUpdateServer/examples/WebUpdater/WebUpdater.ino Load this between using IRMQTTServer and Tasmota

Good news, compiled WebUpdate.ino and managed to go back/forth with Tasmota and IRMQTT - so the issue is indeed related to the memory size. Did not try with IRMQTTServer's minimal though (tried but it failed compiling, probably something my side too). But it's good to share with this community the plan B.

I honestly haven't used this feature in ages. I'll try to take a look to see what I can see.

Must confess I don't really understand what this was supposed to do... Instead of configuring the entity at configuration.yaml it would show up "magically"?

I'll also need to know the "state" of the MQTT topics too to debug this. e.g. Is the model topic set etc? and what the "web page" thinks things are set too.

Sorry, does this print shows you the web page info you mentioned?

Now for the MQTT debug, I restored the power topic at configuration.yaml, set a listener to ir_server_quarto/#, booted and turned the A/C on, fan mode. These are all the messages I got:

Message 27 received on ir_server_quarto/ac/stat/mode at 10:36 AM:
fan_only
QoS: 0 - Retain: false
Message 26 received on ir_server_quarto/ac/stat/power at 10:36 AM:
on
QoS: 0 - Retain: false
Message 25 received on ir_server_quarto/ac/stat/mode at 10:36 AM:
off
QoS: 0 - Retain: false
Message 24 received on ir_server_quarto/ac/stat/power at 10:36 AM:
on
QoS: 0 - Retain: false
Message 23 received on ir_server_quarto/ac/cmnd/mode at 10:36 AM:
fan_only
QoS: 0 - Retain: false
Message 22 received on ir_server_quarto/ac/cmnd/power at 10:36 AM:
ON
QoS: 0 - Retain: false
Message 21 received on ir_server_quarto/log at 10:36 AM:
Finished listening for previous state.
QoS: 0 - Retain: false
Message 20 received on ir_server_quarto/log at 10:36 AM:
The state was recovered from MQTT broker.
QoS: 0 - Retain: false
Message 19 received on ir_server_quarto/ac/stat/light at 10:36 AM:
on
QoS: 0 - Retain: false
Message 18 received on ir_server_quarto/ac/stat/swingv at 10:36 AM:
Highest
QoS: 0 - Retain: false
Message 17 received on ir_server_quarto/ac/stat/fanspeed at 10:36 AM:
Min
QoS: 0 - Retain: false
Message 16 received on ir_server_quarto/ac/stat/temp at 10:36 AM:
16
QoS: 0 - Retain: false
Message 15 received on ir_server_quarto/ac/stat/model at 10:36 AM:
3
QoS: 0 - Retain: false
Message 14 received on ir_server_quarto/ac/stat/protocol at 10:36 AM:
LG2
QoS: 0 - Retain: false
Message 13 received on ir_server_quarto/log at 10:36 AM:
Started listening for previous state.
QoS: 0 - Retain: false
Message 12 received on ir_server_quarto/log at 10:36 AM:
IRMQTTServer v1.5.2 just booted
QoS: 0 - Retain: false
Message 11 received on ir_server_quarto/status at 10:36 AM:
Online
QoS: 0 - Retain: false
Message 10 received on ir_server_quarto/log at 10:36 AM:
(Re)Connected.
QoS: 0 - Retain: false
Message 9 received on ir_server_quarto/log at 10:36 AM:
Reboot requested
QoS: 0 - Retain: false

The A/C beeps as if it was turning off first, then I think comes the second command setting the mode and turns it on properly. And sorry for the long message, but you also mentioned the model topic. I couldn't find a way to set the model on the HA side - am I missing something?

Thanks

[crankyoldgit]

Must confess I don't really understand what this was supposed to do... Instead of configuring the entity at configuration.yaml it would show up "magically"?

Kind of. HA's MQTT Discovery is all about devices announcing themselves via MQTT telling HA that it exists, and what attributes/topics etc it has/uses, so that it can be edited via the HA user interface etc. i.e. Not having to edit configuration.yaml.

Sorry, does this print shows you the web page info you mentioned?

Yep.

I couldn't find a way to set the model on the HA side - am I missing something?

No. It has to be done via MQTT or the IRMQTTServer's Web UI.

Looking at your MQTT log, I notice a number of things:

1. The .../stat/... topic messages should have retain set on them. i.e. Retain: true in your logs. Having retain set is important/vital for normal operation after reboots.
   See:
   

   IRremoteESP8266/examples/IRMQTTServer/IRMQTTServer.ino

   Lines 199 to 216 in b6368bd

   	* NOTE: These "stat" messages have the MQTT retain flag set to on. Thus the
   	* MQTT broker will remember them until reset/restarted etc.
   	*
   	* The code will also periodically broadcast all possible aircon/climate state
   	* attributes to their corresponding "ir_server/ac/stat" topics. This ensures
   	* any updates to the ESP's knowledge that may have been lost in transmission
   	* are re-communicated. e.g. The MQTT broker being offline.
   	* This also helps with Home Assistant MQTT discovery.
   	*
   	* The program on boot & first successful connection to the MQTT broker, will
   	* try to re-acquire any previous aircon/climate state information and act
   	* accordingly. This will typically result in A/C IR message being sent as and
   	* saved state will probably be different from the defaults.
   	*
   	* NOTE: Command attributes are processed sequentially.
   	* e.g. Going from "25C, cool, fan low" to "27C, heat, fan high" may go
   	* via "27C, cool, fan low" & "27C, heat, fan low" depending on the order
   	* of arrival & processing of the MQTT commands.

2. It took me a while to realise your MQTT log is in reverse order to most logs. Most logs are newest entries at the bottom, oldest at the top. Your's are the opposite.
3. Is there any chance you can increase the time resolution of time stamp in your mqtt logging program. i.e. include Seconds, or even milliseconds? That would be helpful to see what actions were done etc.
4. The log seems to show everything happened at 10:36 is that really correct?

If I'm reading it (log) correctly, You told it to reboot. It rebooted successfully. It read the previous state from retained MQTT messages. That state did not include the power or mode settings for some reason. At this point, depending how it was built, it may have sent the state via IR to the a/c. As there was no saved state for power & mode, IIRC it defaults of off for both. It then received a power (on) & mode (fan) message(s). Assuming it was compiled with MQTT_CLIMATE_HA_MODE set to true, which binds power off and mode off together. i.e. either turns it off. It should turn "on" when it gets the "fan_only mode message.

I just checked my HA config:
https://github.com/crankyoldgit/Home-AssistantConfig/blob/047dd931ec7d74e7ad00517cea8d6674d3734000/configuration.yaml#L846-L886

I too, clearly have disabled the power topic to cope with HA's different way of doing things.

Re: MQTT climate discovery FAILED to send.

Looking at the code, the reason that message is likely generated is because the MQTT Discovery message is too long/big for the MQTT library to handle. i.e. Choose a larger value of MQTT_BUFFER_SIZE. The default is:

IRremoteESP8266/examples/IRMQTTServer/IRMQTTServer.h

Lines 119 to 123 in b6368bd

	#ifndef MQTT_BUFFER_SIZE
	// A value of 768 handles most cases easily. Use 1024 or more when using
	// `REPORT_RAW_UNKNOWNS` is recommended.
	#define MQTT_BUFFER_SIZE 768 // Default MQTT packet buffer size.
	#endif // MQTT_BUFFER_SIZE

[kzagatti]

So I think everything is fine and it's all working OK! Let's close the thread then?
Answering your comments:

2. It took me a while to realise your MQTT log is in reverse order to most logs. Most logs are newest entries at the bottom, oldest at the top. Your's are the opposite.

Haha sorry, this is how HA/mqtt shows it.

3. Is there any chance you can increase the time resolution of time stamp in your mqtt logging program. i.e. include Seconds, or even milliseconds? That would be helpful to see what actions were done etc.

Agree, but couldn't find a way to set that but I believe that the message number helps

4. The log seems to show everything happened at 10:36 is that really correct?
   Yep!

Looking at the code, the reason that message is likely generated is because the MQTT Discovery message is too long/big for the MQTT library to handle. i.e. Choose a larger value of MQTT_BUFFER_SIZE.

Well, this doesn't actually seems worth it :-D

Again, @crankyoldgit, I appreciate your work and if there's anything I can do to help you or the community, count me in!

Best

[crankyoldgit]

No worries. Thanks for getting back to us. Closing.