Lost communication Adapter < Pump

[Jabol86]

@ElVit

I am using the latest released version which is on the website

external_components:
  - source:
      type: git
      url: https://github.com/ElVit/esphome_components/
    components: [ panasonic_heatpump ]

Unfortunately, the communication between the module and the pump is lost again for a long time and the esp does not query the pump as planned :(

If I manually change any settings in the esp32, the data from the pump is refreshed but only once.

Originally posted by @Jabol86 in #13

The biggest problem is working on the schedule from the application, because the water heating simply does not turn on if there is no communication ;/

[Jabol86]

I had to cancel the schedule in the app :( When the pump lost connection with the adapter (even though it was frequently flashing white as it should), the scheduled elements in the pump schedule, such as water or house heating, didn't change. ;/

I can't tell you how many times my wife was furious that the bath water was cold. ;/

[ElVit]

Hi @Jabol86,
has the communiction ever worked before?
If yes, you can try to use an older tag version e.g.

external_components:
  - source:
      type: git
      url: https://github.com/ElVit/esphome_components
      ref: '0.0.4'
    components: [ panasonic_heatpump ]

Sorry for the late reply but I do the development of this component in my free time.
So I can not always provide fast bugfixes.

Can you please show me your esphome yaml and log?
(keep in mind to redact your passwords)

[Jabol86]

The problem is that communication works without any problems, but then at some point it disappears and then suddenly returns for unknown reasons.

I know you were supposed to set it so that when communication with the module drops, the esp32 will ask, but I don't see that happening. Unless I missed something in the configuration.

My oversight was that I didn't add the UART configuration
uart_client_timeout: 10s

I've added it now and will let you know in a few days.

[psopso]

My solution is in file panasonic_heatpump.cpp in function send_request. Near end of function I have changed code to:
if(requestType != RequestType::NONE){
// Update last request time when request was sent
this->last_request_time_ = millis();
}
Now it seems to be OK.

[Jabol86]

My solution is in file panasonic_heatpump.cpp in function send_request. Near end of function I have changed code to: if(requestType != RequestType::NONE){ // Update last request time when request was sent this->last_request_time_ = millis(); } Now it seems to be OK.

How did you edit it? Where would it be saved in the code?

as you can see the green line shows that the readings from the pump were not transferred from the pump to the esp :(

#################### o_kot - MASZYNOWNIA ######################

#################### konfiguracja
esphome:
  name: ${hostname}
  friendly_name: Maszynownia
  comment: ESP32-C3
 

esp32:
  board: esp32-c3-devkitm-1
  framework:
    type: esp-idf

# Enable logging
logger:
#  level: INFO
  

#################### OTA/API

ota:
  - platform: esphome
    password: !secret ota

api:
  encryption:
    key: !secret api

#################### standardowe wifi
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  reboot_timeout: 5min

################### ap w razie problemów z wifi
  ap:
    ssid: '${hostname}.ap'
    password: $main_pswd
    ap_timeout: 2min

captive_portal:
    
web_server:
  port: 80
  version: 3

#################### TEMOMETR DS18B20
one_wire:
  - platform: gpio
    pin: GPIO5

substitutions:
  pin_rx_hp: GPIO1  # heatpump reads data (RX) on this pin    (yellow)
  pin_tx_hp: GPIO0  # heatpump sends data (TX) on this pin    (green)
  pin_tx_wm: GPIO4  # WiFi module sends data (TX) on this pin (white)
  pin_rx_wm: GPIO3  # WiFi module reads data (RX) on this pin (blue)
  hostname: 0_kot
  main_pswd: '********.${hostname}'

#external_components:
#  - source:
#      type: git
#      url: https://github.com/ElVit/esphome_components
#      ref: heatpump_esphome_2025.11
#    components: [ panasonic_heatpump ]

external_components:
  - source:
      type: git
      url: https://github.com/ElVit/esphome_components/
    components: [ panasonic_heatpump ]

uart:
  - id: uart_heatpump
    tx_pin: $pin_rx_hp
    rx_pin: $pin_tx_hp
    baud_rate: 9600
    data_bits: 8
    parity: EVEN
    stop_bits: 1
  - id: uart_cz_taw1
    tx_pin: $pin_rx_wm
    rx_pin: $pin_tx_wm
    baud_rate: 9600
    data_bits: 8
    parity: EVEN
    stop_bits: 1

#################### encje #####################################################    

panasonic_heatpump:
  id: my_heatpump
  uart_id: uart_heatpump
  uart_client_id: uart_cz_taw1
  log_uart_msg: true
  update_interval: 5s
  uart_client_timeout: 10s

binary_sensor:
  - platform: panasonic_heatpump
    top0:
      name: "PC status"
    top26:
      name: "PC Defrost status"
    top60:
      name: "PC Grzałka status"
    top69:
      name: "Sterilization State"
    top2:
      name: "Force DHW State"

    uart_client_timed_out:
      name: "UART Client Timed Out"      

      

text_sensor:
  - platform: panasonic_heatpump
    top4:
      name: "PC Tryb pracy"
    top20:
      name: "PC Kierunek zaworu 3D"
    top44:
      name: "PC Błędy"


number:
  - platform: panasonic_heatpump
    set5:
      name: "Set Z1 Heat Request Temperature"
      min_value: -5.0
      max_value: 5.0
      step: 1.0
    set11:
      name: "Set DHW Temp"



select:
  - platform: panasonic_heatpump
    cool_mode: false
    set4:
      name: "PC Tryb BOOST"
    set9:
      name: "PC Tryb pracy"



climate:
  - platform: panasonic_heatpump
    cool_mode: true
    tank:
      name: "Nerv Dom"
      min_temperature: -5.0
      max_temperature: 5.0
      temperature_step: 0.5    

switch:

  - platform: panasonic_heatpump
    set1:
      name: "Pompa Ciepła ON/OFF"

#################### POMPA CWU
  - platform: gpio
    pin: 
      number: GPIO10
      inverted: true
    id: relay
    name: "Cyrkulacja"
    icon: "mdi:pump"
    on_turn_on:
      - logger.log: "Pompa CWU ON"
      - switch.turn_on: relay
      - delay: 16min
      - logger.log: "Pompa CWU OFF"
      - switch.turn_off: relay
    restore_mode: RESTORE_DEFAULT_OFF

#################### PERGOLA
  - platform: gpio
    pin: 
      number: GPIO8
      inverted: false
    id: relay1
    name: "Św. Pergola"
    restore_mode: RESTORE_DEFAULT_OFF

#################### POMPA GRUNTOWA
  - platform: gpio
    pin: 
      number: GPIO9
      inverted: false
    id: relay2
    name: "Pompa gruntowa"
    restore_mode: RESTORE_DEFAULT_OFF
  
sensor:
  - platform: panasonic_heatpump
    top1:
      name: "PC Przepływ pompy"
    top5:
      name: "PC Zasilanie temperatura"
    top6:
      name: "?PC Powrót temperatura"
    top7:
      name: "PC Temperatura zadana"
    top8:
      name: "PC Kompresor częstotliwosć"
    top9:
      name: "PC Temperatura CWU zadana"
    top10:
      name: "PC Temperatura CWU"
    top11:
      name: "PC godziny pracy sprężarki"
    top12:
      name: "PC uruchomienia sprężarki"
    top14:
      name: "PC Temperatura zewnętrzna"
    top15:
      name: "PC Wytważana energia CO"
    top16:
      name: "PC Zużycie energii CO"
    top33:
      name: "Room Thermostat Temp"
    top40:
      name: "PC Wytważana energia CWU"
    top41:
      name: "PC Zużycie energii CWU"
    top49:
      name: "Main Hex Outlet Temp"
    top50:
      name: "Discharge Temp"
    top51:
      name: "Inside Pipe Temp"
    top52:
      name: "Defrost Temp"
    top53:
      name: "Eva Outlet Temp"
    top54:
      name: "Bypass Outlet Temp"
    top55:
      name: "Ipm Temp"
    top62:
      name: "PC Wentylator 1"
    top63:
      name: "PC Wentylator 2"
    top64:
      name: "PC Ciśnienie"
    top65:
      name: "PC Prędkość pompy"
    top67:
      name: "PC Kompresor prąd"
    top93:
      name: "PC Obciązenie %"
    top95:
      name: "Max Pump Duty"

  

#################### sygnał wifi
  - platform: wifi_signal
    name: "${hostname}_linkquality"
    update_interval: 360s
    unit_of_measurement: dBm
    device_class: signal_strength
#################### czas pracy
  - platform: uptime
    name: "${hostname}_uptime"
    update_interval: 360s
    icon: mdi:clock-outline

#################### TEMOMETRY

  - platform: dallas_temp
    address: 0xfe0120502be3c528
    name: "pc_zas_temperature" 
    update_interval: 120s
    filters:
      - delta: 0.5
    

  - platform: dallas_temp
    address: 0xa60120502bcefd28
    name: "pc_pow_temperature" 
    update_interval: 120s
    filters:
      - delta: 0.5

  - platform: dallas_temp
    address: 0xe701204fe311af28
    name: "co_zas_temperature"   
    update_interval: 120s
    filters:
      - delta: 0.5

  - platform: dallas_temp
    address: 0xf2012050581cb928
    name: "co_pow_temperature"
    update_interval: 120s
    filters:
      - delta: 0.5

  - platform: dallas_temp
    address: 0x3601205048d11b28
    name: "cwu_temperature"
    update_interval: 120s
    filters:
      - delta: 0.5

  - platform: dallas_temp
    address: 0xc801205059eae128
    name: "cyr_temperature"
    update_interval: 120s
    filters:
      - delta: 0.5

  - platform: dallas_temp
    address: 0x9801205039d72028
    name: "buf_pow_temperature"
    update_interval: 120s
    filters:
      - delta: 0.5
    

  - platform: dallas_temp
    address: 0x530120502832e528
    name: "buf_zas_temperature"
    update_interval: 120s
    filters:
      - delta: 0.5 



#################### restarty
button:
  - platform: restart
    name: "Restart"
    id: reboot
  - platform: safe_mode
    name: "Safemode"
    id: reboot_safe

[psopso]

I copied the project into my own GitHub repository. There I can modify the code and test it. My fix only addresses the case where the ESP32 does not recognize that the TAW1 has stopped sending messages and that the ESP32 needs to send them instead. It does not address the other issue you mention, where the ESP32 does not receive messages from the heat pump. However, this happens to me as well (occasionally). In that case, surprisingly, the messages do reach the TAW1, but not the ESP32, and therefore the sensors in Home Assistant are not updated.

[Jabol86]

I copied the project into my own GitHub repository. There I can modify the code and test it. My fix only addresses the case where the ESP32 does not recognize that the TAW1 has stopped sending messages and that the ESP32 needs to send them instead. It does not address the other issue you mention, where the ESP32 does not receive messages from the heat pump. However, this happens to me as well (occasionally). In that case, surprisingly, the messages do reach the TAW1, but not the ESP32, and therefore the sensors in Home Assistant are not updated.

For me, when TAW1 isn't sending queries to the pump, the sensors aren't refreshing. I have the latest version of the script, and it's still happening. I thought the author had added a script to check communication, but either I'm doing something wrong or I misunderstood the fixes.

[psopso]

That is exactly what my fix addresses. If I understand it correctly, it will be necessary to wait until the author fixes it. Author had added a code to check communication, but code is not functional.

[Jabol86]

That is exactly what my fix addresses. If I understand it correctly, it will be necessary to wait until the author fixes it. Author had added a code to check communication, but code is not functional.

Ahh, exactly! I thought I was doing something wrong. So the author's previous fix unfortunately doesn't work. Thanks. So we're waiting for a fix :)

[ElVit]

@psopso: Thanks for the hint.
Yes you're right, currently the polling request message is sent to often.
I will fix it.
If you find more issues and have already a solution for it,
you are welcome to fork my repository and create a pull request.

@Jabol86: Your yaml looks good.
Hopefully the fix from @psopso will solve your issue.
The line uart_client_timeout: 10s is actually not needed,
because the default value of this option is already 10s.

[oxyde42]

I had a similar problem when I tried to replace my temporary implementation for my HeishaMon large PCB with this component. However, I couldn't figure out this loop(). So I first decoupled the loop() from the UART handling and operated the UARTs with threads. However, this means that the component is no longer compatible with Arduino and the ESP8266. I first tested my change on a C3. Now it runs smoothly on an ESP32-S3 with 2 MB PSRAM (HeishaMon large PCB).
The current implementation is available as “oxyde42-patch-1” here: https://github.com/oxyde42/esphome_components/tree/oxyde42-patch-1
I would be very happy if this work could be incorporated into the ElVit component.

[ElVit]

Hi @oxyde42,
thanks for your contribution. This is quite an interesting approach.
I will test it on my esp32-s2 and give you feedback how it is working for me.
If it is working I will upload your changes to my repo.

Also I do not see a problem if this component will no longer work with the arduino framework and also not with the ESP8266.
Imho there is not really a need of using an ESP8266 since the ESP32-S2 is more powerfull and cost almost the same.

[oxyde42]

Hi ElVit,
I encountered the problems with flush() using the debug component from ESPHome.
If you would also like to provide a configuration example for the HeishaMon large PCB, it is attached.

sample - HeishaMon large.yaml