search

Arnold-n / P1P2MQTT

Monitor and control Daikin/Rotex (hybrid/Altherma) heat pumps via the 2-wire P1/P2 thermostat interface with an ATmega328P, ESP8266, and electronics. The P1P2Serial library and P1P2Monitor program perform low-level bus operation, the P1P2-bridge-esp8266 program interprets data from/to MQTT supporting Home Assistant MQTT discovery. P1P2Serial may also be used for other Japanese Home Bus System based standards: DIII-NET (F1/F2) bus, Mitsubishi M-Net bus, Toshiba TCC-Link, Hitachi H-link, Panasonic/Sanyo SIII-Net, Haier, York, and others.
Other
326 stars 62 forks source link

Auxiliary mode disabled after reboot #108

Closed fuecy closed 4 months ago

fuecy commented 4 months ago

Hi Arnold

Iam not sure if i do something wrong. I have put my controller in auxiliary mode using telnet L1 and it works awesome. The documentation says (L state info maintained in EEPROM) however when shutdown the power or the wifi connection is lost (and i guess it reboots), the auxiliary mode is off again. So i would expect the auxiliary mode stays enabled after reboot or is it intended otherwise

P1P2/S/018 [ESP] P1P2-bridge-esp8266 v0.9.42 P1P2/S/018 [ESP] Compiled Sep 29 2023 08:53:51 P1P2/S/018 [ESP] E-Series P1P2/S/018 [ESP] ESP_hw_identifier 1 P1P2/S/018 [ESP] Connected to MQTT server P1P2/S/018 [ESP] MQTT Clientname = P1P2_018 P1P2/S/018 [ESP] MQTT User = P1P2 P1P2/S/018 [ESP] MQTT Server = 192.168.xx.xx P1P2/S/018 [ESP] MQTT Port = 1883 P1P2/S/018 [ESP] ESP reboot reason = 0xFF P1P2/S/018 [ESP] outputMode = 0x3002 P1P2/S/018 [ESP] outputFilter = 1 P1P2/S/018 [ESP] mqttInputByte4 = 0 P1P2/S/018 [ESP] EEPROM version = 0 P1P2/S/018 [ESP] To ATmega: ->V<- P1P2/S/018 [MON] 2024-06-29_23:19:44 Verbose 3 P1P2/S/018 [MON] 2024-06-29_23:19:44 P1P2Monitor-v0.9.42 P1P2/S/018 [MON] 2024-06-29_23:19:44 Compiled Sep 27 2023 12:49:03 +control NEWP1P2LIB E-series P1P2/S/018 [MON] 2024-06-29_23:19:44 Reset cause: MCUSR=5 (brown-out-detected) (power-on-reset) P1P2/S/018 [MON] 2024-06-29_23:19:44 P1P2-ESP-interface ATmegaHwID v1.2 P1P2/S/018 [MON] 2024-06-29_23:19:44 Control_ID=0xF0 P1P2/S/018 [MON] 2024-06-29_23:19:44 CONTROL_ID_DEFAULT=0x0 P1P2/S/018 [MON] 2024-06-29_23:19:44 Counterrepeatingrequest=0 P1P2/S/018 [MON] 2024-06-29_23:19:44 F030DELAY=100 P1P2/S/018 [MON] 2024-06-29_23:19:44 F03XDELAY=30 P1P2/S/018 [MON] 2024-06-29_23:19:44 Verbosity=3 P1P2/S/018 [MON] 2024-06-29_23:19:44 CPU_SPEED=8000000 P1P2/S/018 [MON] 2024-06-29_23:19:44 SERIALSPEED=250000

Arnold-n commented 4 months ago

Hi @fuecy,

The line with Control_ID=0xF0 indicates that the EEPROM still has 'L1' mode actively stored, so it should try to restart auxiliary control mode after a reboot. Assuming the bridge receives data from P1/P2, it should report after ca 6 seconds report "* No auxiliary controller answering to address 0xF0 detected, control functionality will restart". Do you see that message, or do you seen any other message?

If you see no message at all, can you set output mode temporarily to show hex packet data (add 0x0010 to J-mask for output via telnet or 0x0001 for output via MQTT), and see if there is proper data being received, including any 00F030 message without 40F030 reply?

Arnold-n commented 4 months ago

For testing purposes, it can be useful to reset the ATmega manually with the A command (your telnet session will survive the restart of the ATmega as the ESP is not restarted).

fuecy commented 4 months ago

Hi Arnold The above output was after i enabled the auxiliary again. The controll id was 0x00. It happened to me twice, hence i made the ticket but now i am not able to reproduce. I have to do some longer testing as it happened when the wifi was down for some time. Normal power reboot seems to work fine.

Arnold-n commented 4 months ago

Hi @fuecy, It would not hurt to update to newer firmware, there were some issues in earlier versions in case of network issues.

If Control_ID is reset to 0x00 it is likely that the auxiliary control mode was switched off due to detection of multiple errors - a safety feature.

fuecy commented 4 months ago

I think you can close the issue. Is this safety feature documented somewhere?, maybe i missed it. Due to a lose wire in the RJ45 connector to the closes accesspoint and together with the fact that i push my configuration dynamicy to my accesspoint it resulted in unexpected behaviour of the wifi which resulted mainly my head pump to get into an error state. I think that would have triggered the safety feature and fall back on read-only mode. I dont think it was the wifi of the p1p2mqtt device that had issues with it.

Arnold-n commented 4 months ago

Thanks for your feedback. It is not really documented although it is now touched upon in P1P2Monitor command documentation that auxiliary control mode and counter request mode will be switched of in case of too many bus collissions (and, in fact, in case of other errors too).