Minor details

[spfmoby]

Some details I've seen : 1/ the initial IP (before firest wifi configuration) is 192.168.1.1 : Do you have a reason to choose this one as 192.168.4.1 seems to be a kind of standard for this situation? 2/ The wifi connection timeout is a bit on the short side. I don't know why (maybe the distance between the access point and the AC in the attic, but I had the same issue a few months ago with another esp8266 very close to the AP) but the connection time for me is often more than 10 seconds. It can lead to reboots, and even resets of the configuration. I suggest to change it to something more like 20000 ms instead of 10000 (line 1474). 3/ I don't know if I am alone, but I always have a difficult time to compile your code. I have the Swicago library in my personal folder, but I have an error when compiling: mitsubishi2mqtt:1056:1: error: 'heatpumpSettings' does not name a type To be able to compile I have to move a copy of the heatpump.cpp and heatpump.h in the folder where the .ino is and remove the #include heatpump.h in the .ino Strange behavior, not sure if it is specific to my configuration or not. 4/ Same thing, probably very related to my own installation, but since I managed to make MQTT work (I installed HA to try it, but it was the same with the [non properly working] mqtt domoticz plugin), the ESP is very very unresponsive. Even when doing something like a simple ping, it changes from 2 or 3ms to timeouts. I don't understand what happens. At the beginning I thought that the ESP was overloaded by the MQTT traffic of the other things on the network... but since I moved the configuration to a separate MQTT server on the HA node, the Mitsubishi2mqtt ESP is the only device connected to this MQTT server... So maybe it has no relation with MQTT and it is just something related to the weather, the phase of the moon or... :-) who knows. How can I try to debug what happens as I can't plug an usb cable on the ESP in the attic? For information the Rssi is between -73 and -76dB which is not very good, but is it too much?

[gysmo38]

@spfmoby 1/ Not really. Do you have an issue with it? Normally the portal shoul open automatically. If there is a problem, we can change it. 2/ Ok I will update it 3/ No problem on my side 4/ For me no latency but I have a good WIFI coverage (betwween -40 and -56 dB). I experience latency with wire problem between HVAC and ESP. Check there is no contact between pins. Maybe this point explain the point 2.

[austwhite]

@spfmoby On the MQTT Latency issues, this may be a HA issue more than a firmware issue. HA MQTT Climate can sometimes lag. The WiFi signal at -73 to -76 will mostly work with MQTT, but you may get packet loss at that low signal which wil result in some MQTT messages not getting through, or settings unexpectedly reverting to previous settings. Have you tried adding an additional access point or maybe temporarily moving one closer to see if it makes a difference? Just as a note, 10 seconds is a really long time for an ESP to connect to WiFi.

[spfmoby]

Thanks for the answers. 1/ -> no issue, just a simple note as I have some other devices which uses the same kind of behavior (first boot with AP mode and an open network) and they all uses 192.168.4.1 as their AP IP. No idea why. 2/ thanks 3/ ok, I will investigate if I am alone with this problem. 4/ I don't think this is HA related. The latency I experience is really within the mitsubishi2MQTT web interface or even with a simple ping of the wemos ip. I don't know what happens, but the behavior is really strange, sometimes it is working perfectly as expected and sometimes I have timeouts when calling the /control or /status web page. One day I also totally lost the control of the esp, I checked the wifi and I had a "HVAC_xxxxx" waiting to be configured. No idea what happened. I had a power failure those last days, so maybe it is related... not sure. I'm sorry for not beeing able to be more specific, I know it is not very helpful. My access point is a Ubiquiti NanoHD, I set the 2.4Ghz power to the maximum, it is attached to the ceiling so it is a little bit difficult to move but I will try something in the coming weeks (it is a little bit difficult at the present time stuck at home with the wife and kids)

[austwhite]

@spfmoby If it drops and is showing the fallback AP, then it is losing WiFi connection. That does sound like a WiFi signal issue, or a dodgy ESP board.

[spfmoby]

The other solution is to go to the attic and open the metal box that contains all the electronic parts of the AC. I think that because the wemos is inside a metal box is not helping :( Maybe I should think of a way to put it outside of this box.

[spfmoby]

I checked in the Ubiquiti Unifi interface and yes the esp went back to the HVAC_xxxx just after the power loss. The access point (and the whole network gear at home) is on a UPS, so the Wifi connection stayed online during the power cut, the AC (and the wemos) on the other side were shut down and restarted when the power returned.

[spfmoby]

Some news about the compilation error : I downloaded the latest versions of swicago and put the 2 files (HeatPump.cpp and HeatPump.h) in a C:\Users\Myusername\Documents\Arduino\libraries\HeatPump folder I downloaded the latest version of Mitsubishi2MQTT and tried to compile the files without any modification. I still get the "mitsubishi2mqtt:1149:1: error: 'heatpumpSettings' does not name a type" error ! I tried some other ways to import the swicago library, like putting the zip file (downloaded from github) on my desktop, then in the arduino IDE " Sketch > Include Library > Add .ZIP Library" Same problem. What should I do? I am on Windows 10, the ESP8266 library is the latest (2.6.3)

[mrg50]

Thanks for pointing out number 2. This sometimes happens drops to the fallback AP after a I change a configuration. I’ve just been working around this.

[gysmo38]

I close, it is an old subject.