UART unavailable on D1 Mini (ESP8226) after ~12hrs #70
Comments
|
hello @phidauex, |
|
I had last updated on April 1st, and re-pulled and updated again on April 3rd just in case. |
|
Ok sure you have the latest version. |
|
Issue happening again after a few days off - none of my other units are doing it so hardware issue is a real possibility. I do have a spare D1 Mini so if you don't see anything obvious in the code then I'll flash to a new unit and see how it works. I've also considered switching to an ESP32 device so I can have it run a bluetooth proxy as well! As an interesting side note, this gives a very clear view of the improvement from remote temperature sensing. When it stops updating the indoor unit switches back to internal temperature source, and my modulation gets terrible. Here is an image of two days of power readings - the arrows point to where I rebooted the ESP, and then when it stopped communicating with the UART again. Nice clean power modulation when it is running, then massive short cycling when it isn't! Proves the value of this project as a way to improve heatpump performance considerably.
|
|
Hello Sam, |
|
I have exactly the same setup, config and... issue. |
It would be great to get the full log before it starts to spam. |
add sensor to monitor connection so as to fixe #70
|
Hi guys, Then I've built a new sensor called hp_uptime_connection_sensor. It should help up to know when connection dropped down. You can test this by pointing to the issue branch like this: external_components:
- source: github://echavet/MitsubishiCN105ESPHome@echavet/issue70
refresh: 0sthen you can activate the new sensor by adding hp_uptime_connection_sensor option: climate:
- platform: cn105
name: ${friendly_name}
id: "esp32_clim"
...
hp_uptime_connection_sensor:
name: ${name} HP Uptime Connection
update_interval: 30s
...
supports:
...I've also temporally added in my yaml some template sensors to monitor other values. You can do so to add them in the diagnostic section of your device in HA. Of course, take care to change the climate device id (here esp32_clim) according to the one set in the climate section.sensor:
- platform: template
name: "dg_uart_connected"
entity_category: DIAGNOSTIC
lambda: |-
return (bool) id(esp32_clim).isUARTConnected_;
update_interval: 30s
- platform: template
name: "dg_hp_connected"
entity_category: DIAGNOSTIC
lambda: |-
return (bool) id(esp32_clim).isUARTConnected_;
update_interval: 30s
- platform: template
name: "dg_complete_cycles"
entity_category: DIAGNOSTIC
accuracy_decimals: 0
lambda: |-
return (unsigned long) id(esp32_clim).nbCompleteCycles_;
update_interval: 60s
- platform: template
name: "dg_total_cycles"
accuracy_decimals: 0
entity_category: DIAGNOSTIC
lambda: |-
return (unsigned long) id(esp32_clim).nbCycles_;
update_interval: 60s
- platform: template
name: "dg_nb_hp_connections"
accuracy_decimals: 0
entity_category: DIAGNOSTIC
lambda: |-
return (unsigned int) id(esp32_clim).nbHeatpumpConnections_;
update_interval: 60s
- platform: template
name: "dg_complete_cycles_percent"
unit_of_measurement: "%"
accuracy_decimals: 1
entity_category: DIAGNOSTIC
lambda: |-
unsigned long nbCompleteCycles = id(esp32_clim).nbCompleteCycles_;
unsigned long nbCycles = id(esp32_clim).nbCycles_;
if (nbCycles == 0) {
return 0.0;
}
return (float) nbCompleteCycles / nbCycles * 100.0;
update_interval: 60s |
|
You are a hero! |
|
Great work! I'm slightly gratified to see that someone else is experiencing the problem as well (a replacement D1 would be cheaper, but at least I know I'm not crazy). I've implemented the new sensors as well and I'll see if I can catch it in the act over the next day or two. |
|
I'm also having UART connection issues with D1 Mini, although it has never worked. I raise the query here, as hopefully I can provide some input if needed and also to help others with similar issues. I have tried 2 D1 Minis, and they never connect, so I don't think it's a hardware issue. There is a chance that it's because I'm just connected directly to the HP, but I have a version 2 D1 Mini, so it has the 5V pin. It seems some directly connected that people RX works, but with others it doesn't, so would like to know if there is a consensus if resistors are really needed or not with the V2 DI Mini? I have used the original esphome-mitsubishiheatpump library to send commands to the HP and that works well, but I'm getting NaN on the temperature and the mode never changes, so I suspect I just have a RX problem, hence this library is smart enough to know things aren't quite right. My config: And the logs I'm getting: 2400 baud worked for the esphome-mitsubishiheatpump library so I'm pretty sure that is OK. Interesting in anything else I can check, but I will get a 1k ohm resistor to try across the RX/G pin to see if that helps. Also I can try to get a voltage regulator, I see the AMS1117 works, but can you please share how this is connected? I was hoping as I have a V2 board it wouldn't be needed. Currently the voltage across RX and G is 3.3V, same for TX/G. I'm not sure if that's a good thing or not. Thanks. It's great that this library is being updated and maintained and I'd really like to run this as it seems to be a great evolution of the original |
Sure you're not crazy!! I'm not very surprised because I've already met these weird situations where the controller is losing its connection to the hp. And I'm not very proud of the way I managed to deal with that. When I decided to use the ESPhome UART abstraction (so as to support IDF) I noticed that the uart begin() method had become out of my scope. The UART is provided "as is" by the esphome interfaces with no way to connect or disconnect. This was disrupting the previous implementation mechanism and I did not handle that well. Hello, This component absolutely wants to get an answer from the heatpump. So you might be able to send commands but not to read the answer. In this case, no way to setup. I'm using a regulator on my D1 mini. It you just have to connect vin and ground from the heatpump to the input pins on the regulator (vin and gnd) and the output pins of the regulator (vout and gnd) to the vin and ground of the D1 mini. Or you can get an esp32 like the esp32s3 which will work with tx setup on gpio00 and Rx on gpio04. |
|
@phidauex : Do you still have troubles on one of your unit with the |
|
Unfortunately (fortunately?) I have not had the UART disconnect since running the update to the version with the diagnostic datapoints. Good luck? Or because there was a relevant fix somewhere in this code or the ESPHome version (2024.3.1)? I'm not sure. I'll keep watching the logs and hope for a disconnect that we can learn from. Curious if @bytniak has seen any disconnects since updating. |
|
Same here. 5 days, with no single "faulty" behavior spotted again. In my case, this time is also correlated with the change of weather and for last 5 days, the "faulty" AC is in the OFF mode. Before that the "faulty" AC was the one working almost 24/7 on heat mode, while the others were not. If it happens again that might bring more light to the direction of the issue. @phidauex could be that your misbehaving unit was the one the most utilized (any continuous non OFF mode)? |
|
well I guess it is thanks to the change on this->isUARTConnected_ that I don't set to false anymore in this version. |
|
@bytniak True, my misbehaving unit is my biggest indoor unit covering the largest room space, so it runs a lot more than the others. Things were warm earlier this week, but the last 24 hours have been cold and the unit has been running quite a bit, and still hasn't disconnected. Hopefully that is a sign that the |
|
jumping in because I have this error this is my conf |
|
sorry @baldarn and thank you for your message. - platform: uptime
name: ${name} Uptimethis will force espHome to include needed classe |
|
Just made the update in the climate.py file |
|
Thanks, I have ordered a regulator and will try that when it arrives to hopefully fix the UART connection issue. Something you may want to look at though is that if I do send a command, not that I expect it to work, that the log file just shows a continuous loop of these errors. Of course it's expected to error, but wonder if a code change can be made so that it doesn't continuously loop and does give up and stop when the UART connection has failed? Just to prevent log files filling up. Just a thought to evolve the code a bit more. Thanks |
Sure you're not crazy!! I'm not very surprised because I've already met these weird situations where the controller is losing its connection to the hp. And I'm not very proud of the way I managed to deal with that. When I decided to use the ESPhome UART abstraction (so as to support IDF) I noticed that the uart begin() method had become out of my scope. The UART is provided "as is" by the esphome interfaces with no way to connect or disconnect. This was disrupting the previous implementation mechanism and I did not handle that well. Hello, This component absolutely wants to get an answer from the heatpump. So you might be able to send commands but not to read the answer. In this case, no way to setup. I'm using a regulator on my D1 mini. https://www.amazon.fr/dp/B072FTMS89?ref=ppx_yo2ov_dt_b_product_details&th=1 Or you can get an esp32 like the esp32s3 which will work with tx setup on gpio00 and Rx on gpio04. |
You’re right. It’s necessary to find a way to reduce log spam. I can simulate this situation by physically disconnecting the reception pin (rx pin). This roughly mirrors what is happening in your case. Also, I could allow the component to send commands to the heat pump even though it can't receive any responses. Some projects have chosen this approach, resulting in a component that operates only in transmission mode, similar to an infrared remote control. This is why so many users report 'NAN' errors when they receive no valid data in return. However, I have opted for an implementation that requires bidirectional communication. This allows for a sort of protocol to unfold in the sequencing of exchanges. I'm not too fond of the idea of sending commands like messages in bottles. Thanks anyway for your feedback. I will try to correct this behavior. |
I completely agree with your approach which is why I'm hoping to get this working when the regulators arrive. I'm planning to use this setup even when I'm not at the house as it will be nice to pre-warm or pre-cool the room before getting home and knowing that the commands have worked will be key. Appreciate your work on this |
|
I had added a 3.3V regulator and I still can't connect. I will shift my issue update over to https://github.com/echavet/MitsubishiCN105ESPHome/issues/85 |
For what it's worth, I had the exact same experience, and fought a lot to make it work. I had quite a few ESP8266s lying around, and lots of people were saying that it works for them, so I was doubting my work and double-checking my cabling etc. In the end, I replaced the D1 Mini with an AtomU (ESP32) and it worked immediately. In a second unit, I used a Lolin C3 Mini (ESP32-C3), and while it had other entirely unrelated issues that I had to work around (in short: needed Simple boards with a chip from the ESP32 should cost < $5, so for me that's money well spent. YMMV :) |
On one of my D1 Minis (ESP8226), after approximately 12 hours of operation (not exactly, but more than a few hours, and less than a day), the unit throws a write error in the CN105 component due to the UART not being connected. This then spams the logs with the below warnings, and no more updates are made or received. This is running the most current branch. A reboot of the D1 solves the problem temporarily. I have not caught it in the act of failing, so there may be an illuminating log message that I'm missing.
My other 4 units do not seem to be having this trouble, so maybe I just have a bad D1 mini, but I wanted to share the log to see if it triggered any ideas.
Log Excerpt - the "could not write as asked" line repeats every few seconds, with the checkPendingWantedSettings spamming between.
UART and CN105 component configuration
The text was updated successfully, but these errors were encountered: