Closed phoinixgrr closed 6 months ago
Hey there @janiversen, mind taking a look at this issue as it has been labeled with an integration (modbus
) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
modbus documentation modbus source (message by IssueLinks)
The debug is fine, but you have cut away the interesting part in the beginning, we need to see the change from OK messages to faulty ones....
Please make a configuration only containing the faulty sensor and one good, make a debug log of that, and lets see the whole log.
The debug is fine, but you have cut away the interesting part in the beginning, we need to see the change from OK messages to faulty ones....
Thanks for the quick response @janiversen
I am currently performing a downgrade to to 2024.2.5 to confirm the assumption that the upgrade to 2024.3.0 is the cause of it.
core-ssh config]$ ha core update --version 2024.2.5
⣟ Processing...
Will update this accordingly with my findings. Also with the requested logs.
Confirmed. Downgrading to 2024.2.5
fixes the issue.
Log from the 2024.3.0
2024-03-07 14:48:05.750 DEBUG (SyncWorker_12) [pymodbus.logging] Connection to Modbus server established. Socket ('192.168.101.12', 56172)
2024-03-07 14:48:10.037 DEBUG (SyncWorker_8) [pymodbus.logging] Current transaction state - IDLE
2024-03-07 14:48:10.037 DEBUG (SyncWorker_8) [pymodbus.logging] Running transaction 1
2024-03-07 14:48:10.038 DEBUG (SyncWorker_8) [pymodbus.logging] SEND: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x1 0x0 0x0 0x0 0x1
2024-03-07 14:48:10.038 DEBUG (SyncWorker_8) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:48:10.042 DEBUG (SyncWorker_8) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:48:10.120 DEBUG (SyncWorker_8) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:48:10.121 DEBUG (SyncWorker_8) [pymodbus.logging] RECV: 0x0 0x1 0x0 0x0 0x0 0x4 0x1 0x1 0x1 0x0
2024-03-07 14:48:10.121 DEBUG (SyncWorker_8) [pymodbus.logging] Processing: 0x0 0x1 0x0 0x0 0x0 0x4 0x1 0x1 0x1 0x0
2024-03-07 14:48:10.121 DEBUG (SyncWorker_8) [pymodbus.logging] Factory Response[ReadCoilsResponse': 1]
2024-03-07 14:48:10.122 DEBUG (SyncWorker_8) [pymodbus.logging] Adding transaction 1
2024-03-07 14:48:10.122 DEBUG (SyncWorker_8) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:48:10.122 DEBUG (SyncWorker_8) [pymodbus.logging] Getting transaction 1
2024-03-07 14:48:10.122 DEBUG (SyncWorker_8) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:48:11.524 DEBUG (SyncWorker_3) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:48:11.524 DEBUG (SyncWorker_3) [pymodbus.logging] Running transaction 2
2024-03-07 14:48:11.524 DEBUG (SyncWorker_3) [pymodbus.logging] SEND: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x0 0x0 0x1
2024-03-07 14:48:11.525 DEBUG (SyncWorker_3) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:48:11.529 DEBUG (SyncWorker_3) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:48:11.621 DEBUG (SyncWorker_3) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:48:11.621 DEBUG (SyncWorker_3) [pymodbus.logging] RECV: 0x0 0x2 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:11.622 DEBUG (SyncWorker_3) [pymodbus.logging] Processing: 0x0 0x2 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:11.622 DEBUG (SyncWorker_3) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 14:48:11.622 DEBUG (SyncWorker_3) [pymodbus.logging] Adding transaction 2
2024-03-07 14:48:11.623 DEBUG (SyncWorker_3) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:48:11.623 DEBUG (SyncWorker_3) [pymodbus.logging] Getting transaction 2
2024-03-07 14:48:11.623 DEBUG (SyncWorker_3) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:48:33.562 DEBUG (SyncWorker_5) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:48:33.563 DEBUG (SyncWorker_5) [pymodbus.logging] Running transaction 3
2024-03-07 14:48:33.563 DEBUG (SyncWorker_5) [pymodbus.logging] SEND: 0x0 0x3 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x1 0x0 0x1
2024-03-07 14:48:33.563 DEBUG (SyncWorker_5) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:48:33.566 DEBUG (SyncWorker_5) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:48:33.677 DEBUG (SyncWorker_5) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:48:33.678 DEBUG (SyncWorker_5) [pymodbus.logging] RECV: 0x0 0x3 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:33.678 DEBUG (SyncWorker_5) [pymodbus.logging] Processing: 0x0 0x3 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:33.679 DEBUG (SyncWorker_5) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 14:48:33.679 DEBUG (SyncWorker_5) [pymodbus.logging] Adding transaction 3
2024-03-07 14:48:33.679 DEBUG (SyncWorker_5) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:48:33.679 DEBUG (SyncWorker_5) [pymodbus.logging] Getting transaction 3
2024-03-07 14:48:33.680 DEBUG (SyncWorker_5) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:48:35.881 DEBUG (SyncWorker_15) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:48:35.882 DEBUG (SyncWorker_15) [pymodbus.logging] Running transaction 4
2024-03-07 14:48:35.882 DEBUG (SyncWorker_15) [pymodbus.logging] SEND: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x3 0x0 0x1
2024-03-07 14:48:35.883 DEBUG (SyncWorker_15) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:48:35.886 DEBUG (SyncWorker_15) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:48:35.955 DEBUG (SyncWorker_15) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:48:35.956 DEBUG (SyncWorker_15) [pymodbus.logging] RECV: 0x0 0x4 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:35.956 DEBUG (SyncWorker_15) [pymodbus.logging] Processing: 0x0 0x4 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:35.956 DEBUG (SyncWorker_15) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 14:48:35.957 DEBUG (SyncWorker_15) [pymodbus.logging] Adding transaction 4
2024-03-07 14:48:35.957 DEBUG (SyncWorker_15) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:48:35.957 DEBUG (SyncWorker_15) [pymodbus.logging] Getting transaction 4
2024-03-07 14:48:35.958 DEBUG (SyncWorker_15) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:48:36.197 DEBUG (SyncWorker_1) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:48:36.197 DEBUG (SyncWorker_1) [pymodbus.logging] Running transaction 5
2024-03-07 14:48:36.198 DEBUG (SyncWorker_1) [pymodbus.logging] SEND: 0x0 0x5 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x4 0x0 0x1
2024-03-07 14:48:36.198 DEBUG (SyncWorker_1) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:48:36.202 DEBUG (SyncWorker_1) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:48:36.273 DEBUG (SyncWorker_1) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:48:36.273 DEBUG (SyncWorker_1) [pymodbus.logging] RECV: 0x0 0x5 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:36.273 DEBUG (SyncWorker_1) [pymodbus.logging] Processing: 0x0 0x5 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:36.274 DEBUG (SyncWorker_1) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 14:48:36.274 DEBUG (SyncWorker_1) [pymodbus.logging] Adding transaction 5
2024-03-07 14:48:36.274 DEBUG (SyncWorker_1) [pymodbus.logging] Frame check failed, ignoring!!
2024-03-07 14:48:36.274 DEBUG (SyncWorker_1) [pymodbus.logging] Getting transaction 5
2024-03-07 14:48:36.275 DEBUG (SyncWorker_1) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 14:48:36.479 DEBUG (SyncWorker_6) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 14:48:36.479 DEBUG (SyncWorker_6) [pymodbus.logging] Running transaction 6
2024-03-07 14:48:36.480 DEBUG (SyncWorker_6) [pymodbus.logging] SEND: 0x0 0x6 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x5 0x0 0x1
2024-03-07 14:48:36.480 DEBUG (SyncWorker_6) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 14:48:36.483 DEBUG (SyncWorker_6) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 14:48:36.552 DEBUG (SyncWorker_6) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 14:48:36.553 DEBUG (SyncWorker_6) [pymodbus.logging] RECV: 0x0 0x6 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:36.553 DEBUG (SyncWorker_6) [pymodbus.logging] Processing: 0x0 0x6 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 14:48:36.554 DEBUG (SyncWorker_6) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
Log from the downgraded "healthy" 2024.2.5 :
2024-03-07 15:09:47.171 DEBUG (SyncWorker_0) [pymodbus.logging] Connection to Modbus server established. Socket ('192.168.101.12', 45324)
2024-03-07 15:10:01.175 DEBUG (SyncWorker_15) [pymodbus.logging] Current transaction state - IDLE
2024-03-07 15:10:01.176 DEBUG (SyncWorker_15) [pymodbus.logging] Running transaction 1
2024-03-07 15:10:01.176 DEBUG (SyncWorker_15) [pymodbus.logging] SEND: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x1 0x0 0x0 0x0 0x1
2024-03-07 15:10:01.177 DEBUG (SyncWorker_15) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:01.196 DEBUG (SyncWorker_15) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:01.255 DEBUG (SyncWorker_15) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 15:10:01.255 DEBUG (SyncWorker_15) [pymodbus.logging] RECV: 0x0 0x1 0x0 0x0 0x0 0x4 0x1 0x1 0x1 0x0
2024-03-07 15:10:01.256 DEBUG (SyncWorker_15) [pymodbus.logging] Processing: 0x0 0x1 0x0 0x0 0x0 0x4 0x1 0x1 0x1 0x0
2024-03-07 15:10:01.256 DEBUG (SyncWorker_15) [pymodbus.logging] Factory Response[ReadCoilsResponse': 1]
2024-03-07 15:10:01.256 DEBUG (SyncWorker_15) [pymodbus.logging] Adding transaction 1
2024-03-07 15:10:01.257 DEBUG (SyncWorker_15) [pymodbus.logging] Getting transaction 1
2024-03-07 15:10:01.257 DEBUG (SyncWorker_15) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 15:10:03.247 DEBUG (SyncWorker_4) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 15:10:03.248 DEBUG (SyncWorker_4) [pymodbus.logging] Running transaction 2
2024-03-07 15:10:03.248 DEBUG (SyncWorker_4) [pymodbus.logging] SEND: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x0 0x0 0x1
2024-03-07 15:10:03.248 DEBUG (SyncWorker_4) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:03.249 DEBUG (SyncWorker_4) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:03.328 DEBUG (SyncWorker_4) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 15:10:03.329 DEBUG (SyncWorker_4) [pymodbus.logging] RECV: 0x0 0x2 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:03.329 DEBUG (SyncWorker_4) [pymodbus.logging] Processing: 0x0 0x2 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:03.330 DEBUG (SyncWorker_4) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 15:10:03.330 DEBUG (SyncWorker_4) [pymodbus.logging] Adding transaction 2
2024-03-07 15:10:03.330 DEBUG (SyncWorker_4) [pymodbus.logging] Getting transaction 2
2024-03-07 15:10:03.331 DEBUG (SyncWorker_4) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 15:10:03.886 DEBUG (SyncWorker_9) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 15:10:03.886 DEBUG (SyncWorker_9) [pymodbus.logging] Running transaction 3
2024-03-07 15:10:03.887 DEBUG (SyncWorker_9) [pymodbus.logging] SEND: 0x0 0x3 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x1 0x0 0x1
2024-03-07 15:10:03.887 DEBUG (SyncWorker_9) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:03.896 DEBUG (SyncWorker_9) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:03.960 DEBUG (SyncWorker_9) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 15:10:03.961 DEBUG (SyncWorker_9) [pymodbus.logging] RECV: 0x0 0x3 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:03.961 DEBUG (SyncWorker_9) [pymodbus.logging] Processing: 0x0 0x3 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:03.962 DEBUG (SyncWorker_9) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 15:10:03.962 DEBUG (SyncWorker_9) [pymodbus.logging] Adding transaction 3
2024-03-07 15:10:03.962 DEBUG (SyncWorker_9) [pymodbus.logging] Getting transaction 3
2024-03-07 15:10:03.963 DEBUG (SyncWorker_9) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 15:10:04.191 DEBUG (SyncWorker_10) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 15:10:04.191 DEBUG (SyncWorker_10) [pymodbus.logging] Running transaction 4
2024-03-07 15:10:04.192 DEBUG (SyncWorker_10) [pymodbus.logging] SEND: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x3 0x0 0x1
2024-03-07 15:10:04.192 DEBUG (SyncWorker_10) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:04.195 DEBUG (SyncWorker_10) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:04.271 DEBUG (SyncWorker_10) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 15:10:04.271 DEBUG (SyncWorker_10) [pymodbus.logging] RECV: 0x0 0x4 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:04.272 DEBUG (SyncWorker_10) [pymodbus.logging] Processing: 0x0 0x4 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:04.272 DEBUG (SyncWorker_10) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 15:10:04.272 DEBUG (SyncWorker_10) [pymodbus.logging] Adding transaction 4
2024-03-07 15:10:04.272 DEBUG (SyncWorker_10) [pymodbus.logging] Getting transaction 4
2024-03-07 15:10:04.273 DEBUG (SyncWorker_10) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 15:10:04.519 DEBUG (SyncWorker_12) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 15:10:04.520 DEBUG (SyncWorker_12) [pymodbus.logging] Running transaction 5
2024-03-07 15:10:04.520 DEBUG (SyncWorker_12) [pymodbus.logging] SEND: 0x0 0x5 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x4 0x0 0x1
2024-03-07 15:10:04.520 DEBUG (SyncWorker_12) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:04.521 DEBUG (SyncWorker_12) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:04.620 DEBUG (SyncWorker_12) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 15:10:04.620 DEBUG (SyncWorker_12) [pymodbus.logging] RECV: 0x0 0x5 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:04.621 DEBUG (SyncWorker_12) [pymodbus.logging] Processing: 0x0 0x5 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:04.621 DEBUG (SyncWorker_12) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 15:10:04.621 DEBUG (SyncWorker_12) [pymodbus.logging] Adding transaction 5
2024-03-07 15:10:04.622 DEBUG (SyncWorker_12) [pymodbus.logging] Getting transaction 5
2024-03-07 15:10:04.622 DEBUG (SyncWorker_12) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 15:10:04.891 DEBUG (SyncWorker_11) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 15:10:04.891 DEBUG (SyncWorker_11) [pymodbus.logging] Running transaction 6
2024-03-07 15:10:04.891 DEBUG (SyncWorker_11) [pymodbus.logging] SEND: 0x0 0x6 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x5 0x0 0x1
2024-03-07 15:10:04.892 DEBUG (SyncWorker_11) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:04.892 DEBUG (SyncWorker_11) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:04.968 DEBUG (SyncWorker_11) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
2024-03-07 15:10:04.969 DEBUG (SyncWorker_11) [pymodbus.logging] RECV: 0x0 0x6 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:04.969 DEBUG (SyncWorker_11) [pymodbus.logging] Processing: 0x0 0x6 0x0 0x0 0x0 0x4 0x1 0x2 0x1 0x0
2024-03-07 15:10:04.970 DEBUG (SyncWorker_11) [pymodbus.logging] Factory Response[ReadDiscreteInputsResponse': 2]
2024-03-07 15:10:04.971 DEBUG (SyncWorker_11) [pymodbus.logging] Adding transaction 6
2024-03-07 15:10:04.972 DEBUG (SyncWorker_11) [pymodbus.logging] Getting transaction 6
2024-03-07 15:10:04.972 DEBUG (SyncWorker_11) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"
2024-03-07 15:10:05.270 DEBUG (SyncWorker_14) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE
2024-03-07 15:10:05.271 DEBUG (SyncWorker_14) [pymodbus.logging] Running transaction 7
2024-03-07 15:10:05.271 DEBUG (SyncWorker_14) [pymodbus.logging] SEND: 0x0 0x7 0x0 0x0 0x0 0x6 0x1 0x2 0x0 0x6 0x0 0x1
2024-03-07 15:10:05.271 DEBUG (SyncWorker_14) [pymodbus.logging] New Transaction state "SENDING"
2024-03-07 15:10:05.283 DEBUG (SyncWorker_14) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"
2024-03-07 15:10:05.360 DEBUG (SyncWorker_14) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"
Not an expert on Modbus. I see the following difference
2024-03-07 14:48:33.679 DEBUG (SyncWorker_5) [pymodbus.logging] Frame check failed, ignoring!!
This message keeps repeating Let me know how can I further help
Thanks for the log, but now I am confused...you originally said you had 1 faulty sensor...and now it is multiple. Actually it looks as if the faulty sensor is now responding.
A short look on the log, it seems the message is ok, so no idea why frame check fails...I need to run this in our simulator, which will take a little while.
homeassistant reports only one sensor does not work (at least from GUI). The "lg_therma_outlet_temp" . Specifically it is reporting as unavailable. This happens with 2024.3.0
Reverting to 2024.2.5
the only sensor not working "lg_therma_outlet_temp"
starts working again.
Based on your configuration, I believe some sensors are ignored due to duplicate addresses:
climates:
- name: "lg_therma_climate_control"
address: 3
# ... #
sensors:
- name: "lg_therma_outlet_temp"
unique_id: "lg_therma_outlet_temp"
scan_interval: 10
address: 3
# ... #
I see the same thing on my instance with the following log messages:
Modbus pi01/Ecodan Zone 1 room temperature address pi0194_holding_4 is duplicate, second entry not loaded!
Correct .This sensor is also used in the climates:
section.
In the above picture, the same sensor is used and reported in the climate "19.1 degrees"
It is a common configuration, used for LG Therma . Example: https://rodmcbain.com/mastering-modbus-heat-pump-integration-with-home-assistant/
Not sure if the above example is problematic, and never bothered to validate it, since it worked fine, and it only stopped working when updating to 2024.3.0
@janiversen I also use both a climate and sensor entity monitoring the same address, since climate entities do not generate long-term statistics. Would it make sense to allow duplicate entities across different entity domains?
I can confirm. I also get this error:
2024-03-07 14:48:00.313 WARNING (MainThread) [homeassistant.components.modbus.validators] Modbus Heat Pump - LG Therma V/lg_therma_outlet_temp address Heat Pump - LG Therma V3_input_1 is duplicate, second entry not loaded!
The address is duplicate, but with different types (coil/input) so we do not remove the entry. But you really should correct that...a register in modbus cannot have 2 different types.
However I am still puzzled as to why you get frame_check failed, that is at a different level, and I will investigate.
No it would not make sense, or it would make the same sense not to have any checks at all. Defining the same address multiple times, means more polling of your device, different values in HA (because the 2 entities are not read simultaneously), the latter is the reason we added the check (there was an issue showing the statistics was wrong).
Now I see you get the duplicate error, you would have saved me some investigation had you told the whole story in the beginning.
Now I see you get the duplicate error, you would have saved me some investigation had you told the whole story in the beginning.
Apologies for being unable to review 50,000 lines of an unfamiliar log format without clarity on what I'm searching for.
wc -l home-assistant.log
58294 home-assistant.log
I hope that downgrading and confirming the issue with 2024.3.0 at least provided some assistance.
Seems to be related to the changes introduced here: https://github.com/home-assistant/core/pull/108906
Seems to be related to the changes introduced here: #108906
Oh wait - I was wondering why after yesterday's update I got the "is lower than 5 seconds, which may cause Home Assistant stability issues" on 4 of my sensors. Those sensors had scan_interval: 0
to be read in only once during startup of HA (e.g. device serial #, hardware revision etc - those NEVER change, so no need to poll them regularly). Changed it to 3600s, error gone.
Was '0' a misinterpretation / misconfiguration from my end (which is likely), or is this a faulty behaviour and related to those changes?
/tom
@Tom-Bom-badil that is another problem, and a real bug, please file a separate issue. "scan_interval: 0" is valid !
As for the issue at hand, duplicate addresses are causing multitude of problems, and a number of filed issues, that is the reason for the check.
That being said, the "frame_check failed" is still open, that is something that should not happen.
For those who want to use the same register for multiple entities, you need to add an automation that makes the duplication.
Changed my sensor using the same address as the thermostat to use a different address which supplies the same value. Solved for me.
As for the issue at hand, duplicate addresses are causing multitude of problems, and a number of filed issues, that is the reason for the check.
For those who want to use the same register for multiple entities, you need to add an automation that makes the duplication.
I'm not suggesting that this approach is incorrect.
However, it's crucial to recognize that this is a breaking change, which will have an impact on the majority of users utilizing LG Therma heatpumps (maybe other heatpumps also since most probably are utilizing also climates
configuration ) with modbus for homeassistant integration. Given that many users simply copy and paste existing configurations, this change must be approached with caution.
No it is not a breaking change, it detects a configuration that may lead to and probably will lead to problems.
But it is all history the release is out, with the release notes.
Wouldn't a sensor unexpectedly reporting as "unavailable" be regarded as a breaking change?
This is not reported in HA UI logs, nor any warning/message is appeared. The duplicate address, just becomes unavailable. You need to go through ssh console, search through several lines of logs, to identify the issue. (Not sure if also the logging level for modbus needs to be elevated for this to be reported)
it is reported in homeasssistant.log, as noted earlier in this issue! this log is available in the UI.
The discussion about "breaking change" does not seem productive, I made a choice when I made the pull request, the reviewer agreed with me and thus it got merged. If you see it differently then please review the pull request before they are merged, where they can be changed, instead of afterwards, where there are nothing to change.
The "frame check failed" is not an error as such, but a misplaced log statement in the underlying library.
So, if there is no alternate available adress to pull the information of the address that is also used on the climate control, how does one take that information to use it somewhere else in home assistant?
I am just investigating for a workaround here. Not a home assistant expert here, so I most probably maybe missing something.
If i get this correctly if modbus address is used in climate control, then it can be considered as good as dead. It cannot be used anywhere else.
use automation.
use automation.
@janiversen
Could you please offer an example of this? I'm finding it challenging to grasp how automations are useful here, given that automations in HA are typically designed to initiate actions in response to events. How does this apply in this situation?
This is not a support channel, issues are for reporting bugs, please use the user forums.
I have the same problem here. I am having hard time to understand why should I use automation to read same register defined under sensor and under climate entitis in modbus config. for something which should be very simple. My configuration in modbus is very simple (that's why I initially start using this) Also it is very clear how climate in modbus shoud access temp input register so I really don't understand what this change brings to anyone.
Well you might not understand it, possibly because you did not read the explanation given several times. It is needed in order to ensure consistency. Without it 2 entities, which refers to the same modbus register, would have different values, depending on the update frequency.
You have the entity available in HA, so no need to read it a second time !!!
Others have been complaining about the different values, and they are correct.
And please do not forget, open source is the place where doers decide what happens, so if you want changes get active and submit pull requests, instead of just complaining.
Thank you for your answer. My intentions are not to complain rather to understand if instruction for modbus are the same as before. Meaning, from now on, if we use climate definition in modbus where we must have defined input_type (with address and slave) we cannot use additional sensor to have that value as separate entity? Or wiseverse If I define sensor for (in this case) outlet temp how I can use that sensor in modbus climate definition? That's all what I am trying to understand, what this change brings in overall for modbus usage and instructions (limitation). I cannot find these things here. Thanks! I understand how community works. For now I will stay on previous HA version.
For now I will stay on previous HA version.
So you are opting for not receiving additional ha updates for ever?
I can understand your furstration @vuk1980 . I am at the same state. It's a breaking change —it used to function, but now it doesn't. The entire community using LG Heat Pumps with Modbus is impacted, and users are already feeling the effects.
Are you familiar with the automation mentioned here? My goal is simply to utilize Climate control and have the flexibility to use the same address elsewhere
It is fair you want to understand how to configure modbus, the instructions have not changed, it was never advised to have the same register being used in different entities, difference is that now it is being checked.
This channel "issues" is about reporting bugs, not providing support.
And I repeat if you use the climate control, the entity IS available in HA and can be used, without adding a second entity.
it was never advised to have the same register being used in different entities, difference is that now it is being checked.
It was never discouraged also. 🤷♂️
@vuk1980 There are some recommendations from the community here: https://community.home-assistant.io/t/modbus-issue-after-update-2024-3-cannot-access-same-input-register-twice/700893/4
So it seems that instead of "automation" a " template sensor." can be used to workaround it. Hope that helps
For anyone searching for a workaround:
This can replace the address used in the modbus climate control.
sensor:
- platform: template
sensors:
lg_therma_outlet_temp:
friendly_name: "Lg Therma V Outlet Temperature"
unit_of_measurement: "°C"
value_template: "{{ state_attr('climate.lg_therma_climate_control', 'current_temperature') }}"
Where climate.lg_therma_climate_control
the name of your climate control
Thank you @janiversen for your awesome work on the Modbus Integration 👍
I have the same problems here. I also use the same address in 2 different domains, but I cannot understand why is that a problem... And it is definitively a breaking change.
You cannot use the same address with 2 different entities, because the register in your device represent 1 entity.
You might consider it a breaking change, to me (being the maintainer) the old behavior was a real bug (that was reported in several issues) so we fixed it.
Any change is a breaking change for someone, because the behavior changes.
Any change is a breaking change for someone, because the behavior changes.
I totally understand the reasoning behind the change. That's definitively a good thing that this is fixed, but when behavior changes drastically, like in this case (due to a bugfix or not) - that's a breaking change. A breaking change is a modification in the API that will require API users (in this case me) to update the application/configuration to prevent disruptions. Better communication on breaking changes leads to swifter upgrades.
But nevertheless, thanks for the maintaing the modbus integration, it is awesome!
@janiversen , sorry to come back to this again, but why duplicated names are also not allowed? For other integrations this is not a problem...
modbus:
name: logo
type: tcp
host: x.x.x.x
port: yyy
binary_sensors:
- name: "Storage"
input_type: coil
address: 8203
scan_interval: 1
unique_id: logo.binary_sensor.q12
switches:
- name: "Storage"
write_type: coil
scan_interval: 1
address: 40
# V5.0
verify:
unique_id: logo.switch.storage
With the above config it logs a warning:
Modbus logo/Storage is duplicate, second entry not loaded!
That is a bug, which is solved in 2024.3.1
Great, thanks a lot!
Ändern Sie Slave von 1 auf 2 für die zweite Entität
That will not work unless you want to change device.
It works great.
Well changing slave means the request goes to another device, and that is normally not what you want.
And especially randomly changing slave:1 to slave:2 will typically not work, except for the case where you have 2 devices with address 1 and 2.
The problem
Using Modbus, to control my Lg Therma Heat pump. After the update to Core 2024.3. I Seem to be experiencing some issues with reading specifically the following sensor:
Here is the whole configuration
The entity
lg_therma_outlet_temp
is reported as Unavailable. No other changes introduced except upgrading toCore 2024.3.
What version of Home Assistant Core has the issue?
core-2024.3.0
What was the last working version of Home Assistant Core?
core-2024.2.5
What type of installation are you running?
Home Assistant OS
Integration causing the issue
modbus
Link to integration documentation on our website
https://www.home-assistant.io/integrations/modbus/
Diagnostics information
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response