day_energy and total_energy reports 0

I use your software for a few months and it runs stable.
Unfortunatelly it reports unexpected 0s in the morning and the evening e.g. for day_enery and total_energy.
Both zeros are illogical for the total_energy, as the total_energy is a steadily increasing value that should not be 0 except at the very beginning.
The situation is similar with day_energy. Zero values are only expected in the morning after the time reset. In the evening, after the values have risen steadily throughout the day, a 0 value is illogical and unexpected.
I prefer to send no values rather than a series of zeros.
In addition, the 0 for day_energy in the evening breaks the calculation of my self-used solar energy as provided by Home Assistant.
What do you think about this behaviour?
Expected behavior
Continuous line that is interrupted overnight because the inverter and logger are offline overnight.
The line does not go down to 0 either in the morning or in the evening.
Screenshots

Hardware (please complete the following information):

Inverter model: Deye SUN300G3 EU 230

Software (please complete the following information):

Logger firmware version: 1.57
deye-inverter-mqtt version: 2024.06.2

Logs
Logger is online for the first time this day:
2024-07-20 03:28:00,909 - DeyeDaemon - DEBUG - Invoking action
2024-07-20 03:28:00,910 - DeyeInverterState - INFO - Reading start
2024-07-20 03:28:00,910 - DeyeInverterState - INFO - Reading registers [metrics group: {'micro'}, range: 003c-0074]
2024-07-20 03:28:00,939 - DeyeTcpConnector - INFO - Re-connected to socket on IP <IP_ADDRESS>
2024-07-20 03:28:00,939 - DeyeTcpConnector - DEBUG - Request frame: a517001045000029acebf60200000000000000000000000000000103003c003945d4b615
2024-07-20 03:28:01,114 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a585001015000129acebf60201c07a2f012d0000000000000001037200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078ab9415
2024-07-20 03:28:01,116 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings_micro', 'settings'}, range: 0028-0028]
2024-07-20 03:28:01,120 - DeyeTcpConnector - DEBUG - Request frame: a517001045000029acebf602000000000000000000000000000001030028000104025715
2024-07-20 03:28:01,175 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a515001015000229acebf60201c07a2f012d000000000000000103020064b9af5e15
2024-07-20 03:28:01,177 - DeyeInverterState - DEBUG - Production today: 0.0
2024-07-20 03:28:01,177 - DeyeInverterState - DEBUG - Production Total: 0.0
2024-07-20 03:28:01,178 - DeyeInverterState - DEBUG - Phase1 Voltage: 0.0
2024-07-20 03:28:01,179 - DeyeInverterState - DEBUG - Phase1 Current: 0.0
2024-07-20 03:28:01,180 - DeyeInverterState - DEBUG - Phase1 Power: 0.0
2024-07-20 03:28:01,181 - DeyeInverterState - DEBUG - AC Freq: 0.0
2024-07-20 03:28:01,181 - DeyeInverterState - DEBUG - Uptime: 0.0
2024-07-20 03:28:01,181 - DeyeInverterState - DEBUG - PV1 Voltage: 0.0
2024-07-20 03:28:01,182 - DeyeInverterState - DEBUG - PV1 Current: 0.0
2024-07-20 03:28:01,182 - DeyeInverterState - DEBUG - PV1 Power: 0.0
2024-07-20 03:28:01,183 - DeyeInverterState - DEBUG - PV1 Production today: 0.0
2024-07-20 03:28:01,183 - DeyeInverterState - DEBUG - PV1 Total: 0.0
2024-07-20 03:28:01,183 - DeyeInverterState - DEBUG - PV2 Voltage: 0.0
2024-07-20 03:28:01,184 - DeyeInverterState - DEBUG - PV2 Current: 0.0
2024-07-20 03:28:01,184 - DeyeInverterState - DEBUG - PV2 Power: 0.0
2024-07-20 03:28:01,185 - DeyeInverterState - DEBUG - PV2 Production today: 0.0
2024-07-20 03:28:01,185 - DeyeInverterState - DEBUG - PV2 Total: 0.0
2024-07-20 03:28:01,185 - DeyeInverterState - DEBUG - PV3 Voltage: 0.0
2024-07-20 03:28:01,186 - DeyeInverterState - DEBUG - PV3 Current: 0.0
2024-07-20 03:28:01,186 - DeyeInverterState - DEBUG - PV3 Power: 0.0
2024-07-20 03:28:01,186 - DeyeInverterState - DEBUG - PV3 Production today: 0.0
2024-07-20 03:28:01,187 - DeyeInverterState - DEBUG - PV3 Total: 0.0
2024-07-20 03:28:01,187 - DeyeInverterState - DEBUG - PV4 Voltage: 0.0
2024-07-20 03:28:01,187 - DeyeInverterState - DEBUG - PV4 Current: 0.0
2024-07-20 03:28:01,188 - DeyeInverterState - DEBUG - PV4 Power: 0.0
2024-07-20 03:28:01,188 - DeyeInverterState - DEBUG - PV4 Production today: 0.0
2024-07-20 03:28:01,189 - DeyeInverterState - DEBUG - PV4 Total: 0.0
2024-07-20 03:28:01,189 - DeyeInverterState - DEBUG - DC Total Power: 0.0
2024-07-20 03:28:01,190 - DeyeInverterState - DEBUG - Operating Power: 0.0
2024-07-20 03:28:01,190 - DeyeInverterState - DEBUG - AC Active Power: 0.0
2024-07-20 03:28:01,190 - DeyeInverterState - DEBUG - Radiator temperature: -10.0
2024-07-20 03:28:01,191 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/logger_status', value: 'online'
2024-07-20 03:28:01,192 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m17636), 'b'deyemqtt/logger_status'', ... (6 bytes)
2024-07-20 03:28:01,195 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 17636)
2024-07-20 03:28:01,197 - DeyeMqttClient - INFO - Logger is online
2024-07-20 03:28:01,197 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/day_energy', value: '0.0'
2024-07-20 03:28:01,198 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m17637), 'b'deyemqtt/day_energy'', ... (3 bytes)
2024-07-20 03:28:01,199 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 17637)
2024-07-20 03:28:01,201 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/total_energy', value: '0.0'
2024-07-20 03:28:01,201 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m17638), 'b'deyemqtt/total_energy'', ... (3 bytes)
2024-07-20 03:28:01,203 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 17638)

First zero value in the morning:
2024-07-20 03:33:00,910 - DeyeDaemon - DEBUG - Invoking action
2024-07-20 03:33:00,911 - DeyeInverterState - INFO - Reading start
2024-07-20 03:33:00,911 - DeyeInverterState - INFO - Reading registers [metrics group: {'micro'}, range: 003c-0074]
2024-07-20 03:33:00,917 - DeyeTcpConnector - DEBUG - Request frame: a517001045000029acebf60200000000000000000000000000000103003c003945d4b615
2024-07-20 03:33:01,097 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a585001015000929acebf602019f7b2f010c0100000000000001037200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078ab5c15
2024-07-20 03:33:01,098 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings_micro', 'settings'}, range: 0028-0028]
2024-07-20 03:33:01,101 - DeyeTcpConnector - DEBUG - Request frame: a517001045000029acebf602000000000000000000000000000001030028000104025715
2024-07-20 03:33:01,158 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a515001015000a29acebf602019f7b2f010c010000000000000103020064b9af2615
2024-07-20 03:33:01,159 - DeyeInverterState - DEBUG - Production today: 0.0
2024-07-20 03:33:01,160 - DeyeInverterState - DEBUG - Production Total: 0.0
2024-07-20 03:33:01,160 - DeyeInverterState - DEBUG - Phase1 Voltage: 0.0
2024-07-20 03:33:01,161 - DeyeInverterState - DEBUG - Phase1 Current: 0.0
2024-07-20 03:33:01,161 - DeyeInverterState - DEBUG - Phase1 Power: 0.0
2024-07-20 03:33:01,162 - DeyeInverterState - DEBUG - AC Freq: 0.0
2024-07-20 03:33:01,163 - DeyeInverterState - DEBUG - Uptime: 0.0
2024-07-20 03:33:01,164 - DeyeInverterState - DEBUG - PV1 Voltage: 0.0
2024-07-20 03:33:01,164 - DeyeInverterState - DEBUG - PV1 Current: 0.0
2024-07-20 03:33:01,164 - DeyeInverterState - DEBUG - PV1 Power: 0.0
2024-07-20 03:33:01,165 - DeyeInverterState - DEBUG - PV1 Production today: 0.0
2024-07-20 03:33:01,165 - DeyeInverterState - DEBUG - PV1 Total: 0.0
2024-07-20 03:33:01,165 - DeyeInverterState - DEBUG - PV2 Voltage: 0.0
2024-07-20 03:33:01,166 - DeyeInverterState - DEBUG - PV2 Current: 0.0
2024-07-20 03:33:01,166 - DeyeInverterState - DEBUG - PV2 Power: 0.0
2024-07-20 03:33:01,166 - DeyeInverterState - DEBUG - PV2 Production today: 0.0
2024-07-20 03:33:01,167 - DeyeInverterState - DEBUG - PV2 Total: 0.0
2024-07-20 03:33:01,167 - DeyeInverterState - DEBUG - PV3 Voltage: 0.0
2024-07-20 03:33:01,167 - DeyeInverterState - DEBUG - PV3 Current: 0.0
2024-07-20 03:33:01,168 - DeyeInverterState - DEBUG - PV3 Power: 0.0
2024-07-20 03:33:01,168 - DeyeInverterState - DEBUG - PV3 Production today: 0.0
2024-07-20 03:33:01,168 - DeyeInverterState - DEBUG - PV3 Total: 0.0
2024-07-20 03:33:01,169 - DeyeInverterState - DEBUG - PV4 Voltage: 0.0
2024-07-20 03:33:01,169 - DeyeInverterState - DEBUG - PV4 Current: 0.0
2024-07-20 03:33:01,169 - DeyeInverterState - DEBUG - PV4 Power: 0.0
2024-07-20 03:33:01,170 - DeyeInverterState - DEBUG - PV4 Production today: 0.0
2024-07-20 03:33:01,170 - DeyeInverterState - DEBUG - PV4 Total: 0.0
2024-07-20 03:33:01,170 - DeyeInverterState - DEBUG - DC Total Power: 0.0
2024-07-20 03:33:01,171 - DeyeInverterState - DEBUG - Operating Power: 0.0
2024-07-20 03:33:01,171 - DeyeInverterState - DEBUG - AC Active Power: 0.0
2024-07-20 03:33:01,171 - DeyeInverterState - DEBUG - Radiator temperature: -10.0
2024-07-20 03:33:01,172 - DeyeInverterState - DEBUG - Active power regulation: 100.0
2024-07-20 03:33:01,172 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/logger_status', value: 'online'
2024-07-20 03:33:01,172 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m17886), 'b'deyemqtt/logger_status'', ... (6 bytes)
2024-07-20 03:33:01,174 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 17886)
2024-07-20 03:33:01,177 - DeyeMqttClient - INFO - Logger is online
2024-07-20 03:33:01,178 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/day_energy', value: '0.0'
2024-07-20 03:33:01,178 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m17887), 'b'deyemqtt/day_energy'', ... (3 bytes)
2024-07-20 03:33:01,180 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 17887)
2024-07-20 03:33:01,182 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/total_energy', value: '0.0'
2024-07-20 03:33:01,182 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m17888), 'b'deyemqtt/total_energy'', ... (3 bytes)
2024-07-20 03:33:01,184 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 17888)

First non-zero value in the morning:
2024-07-20 03:34:00,911 - DeyeDaemon - DEBUG - Invoking action
2024-07-20 03:34:00,911 - DeyeInverterState - INFO - Reading start
2024-07-20 03:34:00,912 - DeyeInverterState - INFO - Reading registers [metrics group: {'micro'}, range: 003c-0074]
2024-07-20 03:34:00,915 - DeyeTcpConnector - DEBUG - Request frame: a517001045000029acebf60200000000000000000000000000000103003c003945d4b615
2024-07-20 03:34:01,273 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a585001015000b29acebf60201db7b2f014801000000000000010372001300000000105700000013000000000000105700000000000009600000000000000000000013880000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000000000000000000001320000000000000000000000000000e0723415
2024-07-20 03:34:01,275 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings_micro', 'settings'}, range: 0028-0028]
2024-07-20 03:34:01,279 - DeyeTcpConnector - DEBUG - Request frame: a517001045000029acebf602000000000000000000000000000001030028000104025715
2024-07-20 03:34:01,587 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a515001015000c29acebf60201db7b2f0148010000000000000103020064b9afa015
2024-07-20 03:34:01,588 - DeyeInverterState - DEBUG - Production today: 1.9
2024-07-20 03:34:01,589 - DeyeInverterState - DEBUG - Production Total: 418.3
2024-07-20 03:34:01,589 - DeyeInverterState - DEBUG - Phase1 Voltage: 240.0
2024-07-20 03:34:01,590 - DeyeInverterState - DEBUG - Phase1 Current: 0.0
2024-07-20 03:34:01,590 - DeyeInverterState - DEBUG - Phase1 Power: 0.0
2024-07-20 03:34:01,590 - DeyeInverterState - DEBUG - AC Freq: 50.0
2024-07-20 03:34:01,591 - DeyeInverterState - DEBUG - Uptime: 0.0
2024-07-20 03:34:01,591 - DeyeInverterState - DEBUG - PV1 Voltage: 30.6
2024-07-20 03:34:01,591 - DeyeInverterState - DEBUG - PV1 Current: 0.0
2024-07-20 03:34:01,592 - DeyeInverterState - DEBUG - PV1 Power: 0.0
2024-07-20 03:34:01,593 - DeyeInverterState - DEBUG - PV1 Production today: 1.9
2024-07-20 03:34:01,593 - DeyeInverterState - DEBUG - PV1 Total: 418.3
2024-07-20 03:34:01,594 - DeyeInverterState - DEBUG - PV2 Voltage: 0.0
2024-07-20 03:34:01,594 - DeyeInverterState - DEBUG - PV2 Current: 0.0
2024-07-20 03:34:01,595 - DeyeInverterState - DEBUG - PV2 Power: 0.0
2024-07-20 03:34:01,596 - DeyeInverterState - DEBUG - PV2 Production today: 0.0
2024-07-20 03:34:01,597 - DeyeInverterState - DEBUG - PV2 Total: 0.0
2024-07-20 03:34:01,597 - DeyeInverterState - DEBUG - PV3 Voltage: 0.0
2024-07-20 03:34:01,598 - DeyeInverterState - DEBUG - PV3 Current: 0.0
2024-07-20 03:34:01,598 - DeyeInverterState - DEBUG - PV3 Power: 0.0
2024-07-20 03:34:01,599 - DeyeInverterState - DEBUG - PV3 Production today: 0.0
2024-07-20 03:34:01,600 - DeyeInverterState - DEBUG - PV3 Total: 0.0
2024-07-20 03:34:01,600 - DeyeInverterState - DEBUG - PV4 Voltage: 0.0
2024-07-20 03:34:01,601 - DeyeInverterState - DEBUG - PV4 Current: 0.0
2024-07-20 03:34:01,601 - DeyeInverterState - DEBUG - PV4 Power: 0.0
2024-07-20 03:34:01,601 - DeyeInverterState - DEBUG - PV4 Production today: 0.0
2024-07-20 03:34:01,602 - DeyeInverterState - DEBUG - PV4 Total: 0.0
2024-07-20 03:34:01,602 - DeyeInverterState - DEBUG - DC Total Power: 0.0
2024-07-20 03:34:01,603 - DeyeInverterState - DEBUG - Operating Power: 0.0
2024-07-20 03:34:01,603 - DeyeInverterState - DEBUG - AC Active Power: 0.0
2024-07-20 03:34:01,604 - DeyeInverterState - DEBUG - Radiator temperature: -10.0
2024-07-20 03:34:01,604 - DeyeInverterState - DEBUG - Active power regulation: 100.0
2024-07-20 03:34:01,605 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/logger_status', value: 'online'
2024-07-20 03:34:01,605 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m17936), 'b'deyemqtt/logger_status'', ... (6 bytes)
2024-07-20 03:34:01,608 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 17936)
2024-07-20 03:34:01,609 - DeyeMqttClient - INFO - Logger is online
2024-07-20 03:34:01,609 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/day_energy', value: '1.9'
2024-07-20 03:34:01,610 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m17937), 'b'deyemqtt/day_energy'', ... (3 bytes)
2024-07-20 03:34:01,612 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 17937)
2024-07-20 03:34:01,613 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/total_energy', value: '418.3'
2024-07-20 03:34:01,614 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m17938), 'b'deyemqtt/total_energy'', ... (5 bytes)
2024-07-20 03:34:01,617 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 17938)

Last non-zero value in the evening:
2024-07-20 18:48:01,108 - DeyeDaemon - DEBUG - Invoking action
2024-07-20 18:48:01,109 - DeyeInverterState - INFO - Reading start
2024-07-20 18:48:01,109 - DeyeInverterState - INFO - Reading registers [metrics group: {'micro'}, range: 003c-0074]
2024-07-20 18:48:01,186 - DeyeTcpConnector - DEBUG - Request frame: a517001045000029acebf60200000000000000000000000000000103003c003945d4b615
2024-07-20 18:48:01,363 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a585001015001029acebf60201c34e3001c00100000000000001037200110000000010680000001100000000000010680000000000000938000000000000000000001388000000000000000000000000000a0000000000000fd200000000000000000000000000000000000000000000000000040000000000000000000000b500000000000000000000000000006e210d15
2024-07-20 18:48:01,365 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings_micro', 'settings'}, range: 0028-0028]
2024-07-20 18:48:01,369 - DeyeTcpConnector - DEBUG - Request frame: a517001045000029acebf602000000000000000000000000000001030028000104025715
2024-07-20 18:48:01,423 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a515001015001129acebf60201c34e3001c0010000000000000103020064b9afd915
2024-07-20 18:48:01,424 - DeyeInverterState - DEBUG - Production today: 1.7
2024-07-20 18:48:01,424 - DeyeInverterState - DEBUG - Production Total: 420.0
2024-07-20 18:48:01,425 - DeyeInverterState - DEBUG - Phase1 Voltage: 236.0
2024-07-20 18:48:01,425 - DeyeInverterState - DEBUG - Phase1 Current: 0.0
2024-07-20 18:48:01,426 - DeyeInverterState - DEBUG - Phase1 Power: 0.0
2024-07-20 18:48:01,426 - DeyeInverterState - DEBUG - AC Freq: 50.0
2024-07-20 18:48:01,426 - DeyeInverterState - DEBUG - Uptime: 0.0
2024-07-20 18:48:01,427 - DeyeInverterState - DEBUG - PV1 Voltage: 18.1
2024-07-20 18:48:01,427 - DeyeInverterState - DEBUG - PV1 Current: 0.0
2024-07-20 18:48:01,428 - DeyeInverterState - DEBUG - PV1 Power: 0.0
2024-07-20 18:48:01,428 - DeyeInverterState - DEBUG - PV1 Production today: 1.7
2024-07-20 18:48:01,429 - DeyeInverterState - DEBUG - PV1 Total: 420.0
2024-07-20 18:48:01,429 - DeyeInverterState - DEBUG - PV2 Voltage: 0.0
2024-07-20 18:48:01,430 - DeyeInverterState - DEBUG - PV2 Current: 0.0
2024-07-20 18:48:01,430 - DeyeInverterState - DEBUG - PV2 Power: 0.0
2024-07-20 18:48:01,431 - DeyeInverterState - DEBUG - PV2 Production today: 0.0
2024-07-20 18:48:01,432 - DeyeInverterState - DEBUG - PV2 Total: 0.0
2024-07-20 18:48:01,433 - DeyeInverterState - DEBUG - PV3 Voltage: 0.0
2024-07-20 18:48:01,433 - DeyeInverterState - DEBUG - PV3 Current: 0.0
2024-07-20 18:48:01,433 - DeyeInverterState - DEBUG - PV3 Power: 0.0
2024-07-20 18:48:01,434 - DeyeInverterState - DEBUG - PV3 Production today: 0.0
2024-07-20 18:48:01,435 - DeyeInverterState - DEBUG - PV3 Total: 0.0
2024-07-20 18:48:01,435 - DeyeInverterState - DEBUG - PV4 Voltage: 0.0
2024-07-20 18:48:01,436 - DeyeInverterState - DEBUG - PV4 Current: 0.0
2024-07-20 18:48:01,436 - DeyeInverterState - DEBUG - PV4 Power: 0.0
2024-07-20 18:48:01,437 - DeyeInverterState - DEBUG - PV4 Production today: 0.0
2024-07-20 18:48:01,437 - DeyeInverterState - DEBUG - PV4 Total: 0.0
2024-07-20 18:48:01,438 - DeyeInverterState - DEBUG - DC Total Power: 0.0
2024-07-20 18:48:01,438 - DeyeInverterState - DEBUG - Operating Power: 0.0
2024-07-20 18:48:01,439 - DeyeInverterState - DEBUG - AC Active Power: 1.0
2024-07-20 18:48:01,439 - DeyeInverterState - DEBUG - Radiator temperature: 30.5
2024-07-20 18:48:01,440 - DeyeInverterState - DEBUG - Active power regulation: 100.0
2024-07-20 18:48:01,440 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/logger_status', value: 'online'
2024-07-20 18:48:01,441 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m63071), 'b'deyemqtt/logger_status'', ... (6 bytes)
2024-07-20 18:48:01,443 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 63071)
2024-07-20 18:48:01,446 - DeyeMqttClient - INFO - Logger is online
2024-07-20 18:48:01,446 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/day_energy', value: '1.7'
2024-07-20 18:48:01,447 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m63072), 'b'deyemqtt/day_energy'', ... (3 bytes)
2024-07-20 18:48:01,449 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 63072)
2024-07-20 18:48:01,450 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/total_energy', value: '420.0'
2024-07-20 18:48:01,451 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m63073), 'b'deyemqtt/total_energy'', ... (5 bytes)
2024-07-20 18:48:01,453 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 63073)

First zero value in the evening:
2024-07-20 18:50:01,109 - DeyeDaemon - DEBUG - Invoking action
2024-07-20 18:50:01,109 - DeyeInverterState - INFO - Reading start
2024-07-20 18:50:01,110 - DeyeInverterState - INFO - Reading registers [metrics group: {'micro'}, range: 003c-0074]
2024-07-20 18:50:01,118 - DeyeTcpConnector - INFO - Re-connected to socket on IP <IP_ADDRESS>
2024-07-20 18:50:01,119 - DeyeTcpConnector - DEBUG - Request frame: a517001045000029acebf60200000000000000000000000000000103003c003945d4b615
2024-07-20 18:50:01,300 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a585001015000129acebf602019c4e3001310000000000000001037200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078ab4915
2024-07-20 18:50:01,302 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings_micro', 'settings'}, range: 0028-0028]
2024-07-20 18:50:01,311 - DeyeTcpConnector - DEBUG - Request frame: a517001045000029acebf602000000000000000000000000000001030028000104025715
2024-07-20 18:50:01,523 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a515001015000229acebf602019c4e300131000000000000000103020064b9af1315
2024-07-20 18:50:01,524 - DeyeInverterState - DEBUG - Production today: 0.0
2024-07-20 18:50:01,525 - DeyeInverterState - DEBUG - Production Total: 0.0
2024-07-20 18:50:01,525 - DeyeInverterState - DEBUG - Phase1 Voltage: 0.0
2024-07-20 18:50:01,525 - DeyeInverterState - DEBUG - Phase1 Current: 0.0
2024-07-20 18:50:01,526 - DeyeInverterState - DEBUG - Phase1 Power: 0.0
2024-07-20 18:50:01,527 - DeyeInverterState - DEBUG - AC Freq: 0.0
2024-07-20 18:50:01,527 - DeyeInverterState - DEBUG - Uptime: 0.0
2024-07-20 18:50:01,527 - DeyeInverterState - DEBUG - PV1 Voltage: 0.0
2024-07-20 18:50:01,528 - DeyeInverterState - DEBUG - PV1 Current: 0.0
2024-07-20 18:50:01,528 - DeyeInverterState - DEBUG - PV1 Power: 0.0
2024-07-20 18:50:01,528 - DeyeInverterState - DEBUG - PV1 Production today: 0.0
2024-07-20 18:50:01,529 - DeyeInverterState - DEBUG - PV1 Total: 0.0
2024-07-20 18:50:01,529 - DeyeInverterState - DEBUG - PV2 Voltage: 0.0
2024-07-20 18:50:01,529 - DeyeInverterState - DEBUG - PV2 Current: 0.0
2024-07-20 18:50:01,530 - DeyeInverterState - DEBUG - PV2 Power: 0.0
2024-07-20 18:50:01,530 - DeyeInverterState - DEBUG - PV2 Production today: 0.0
2024-07-20 18:50:01,530 - DeyeInverterState - DEBUG - PV2 Total: 0.0
2024-07-20 18:50:01,531 - DeyeInverterState - DEBUG - PV3 Voltage: 0.0
2024-07-20 18:50:01,531 - DeyeInverterState - DEBUG - PV3 Current: 0.0
2024-07-20 18:50:01,531 - DeyeInverterState - DEBUG - PV3 Power: 0.0
2024-07-20 18:50:01,532 - DeyeInverterState - DEBUG - PV3 Production today: 0.0
2024-07-20 18:50:01,532 - DeyeInverterState - DEBUG - PV3 Total: 0.0
2024-07-20 18:50:01,532 - DeyeInverterState - DEBUG - PV4 Voltage: 0.0
2024-07-20 18:50:01,533 - DeyeInverterState - DEBUG - PV4 Current: 0.0
2024-07-20 18:50:01,533 - DeyeInverterState - DEBUG - PV4 Power: 0.0
2024-07-20 18:50:01,533 - DeyeInverterState - DEBUG - PV4 Production today: 0.0
2024-07-20 18:50:01,533 - DeyeInverterState - DEBUG - PV4 Total: 0.0
2024-07-20 18:50:01,534 - DeyeInverterState - DEBUG - DC Total Power: 0.0
2024-07-20 18:50:01,534 - DeyeInverterState - DEBUG - Operating Power: 0.0
2024-07-20 18:50:01,534 - DeyeInverterState - DEBUG - AC Active Power: 0.0
2024-07-20 18:50:01,535 - DeyeInverterState - DEBUG - Radiator temperature: -10.0
2024-07-20 18:50:01,535 - DeyeInverterState - DEBUG - Active power regulation: 100.0
2024-07-20 18:50:01,536 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/logger_status', value: 'online'
2024-07-20 18:50:01,536 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m63124), 'b'deyemqtt/logger_status'', ... (6 bytes)
2024-07-20 18:50:01,538 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 63124)
2024-07-20 18:50:01,541 - DeyeMqttClient - INFO - Logger is online
2024-07-20 18:50:01,541 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/day_energy', value: '0.0'
2024-07-20 18:50:01,542 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m63125), 'b'deyemqtt/day_energy'', ... (3 bytes)
2024-07-20 18:50:01,544 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 63125)
2024-07-20 18:50:01,547 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deyemqtt/total_energy', value: '0.0'
2024-07-20 18:50:01,549 - paho.mqtt.client - DEBUG - Sending PUBLISH (d0, q1, r0, m63126), 'b'deyemqtt/total_energy'', ... (3 bytes)
2024-07-20 18:50:01,551 - paho.mqtt.client - DEBUG - Received PUBACK (Mid: 63126)

@CarstenGrohmann hi! This software only publishes the values read from the inverter. Your inverter returns zeros, and that is what is published.
Let's look at this response frame:
a585001015000929acebf602019f7b2f010c0100000000000001037200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078ab5c15

It contains this ModbusRTU frame inside:
01037200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078ab

Even without decoding, it is obvious that it contains zeros only. It's worth noting that the CRC is valid, which indicates, that the communication is working correctly.

My converter has no connection to the internet and DEYE_FEATURE_SET_TIME is set to true.
I'll update the firmware to the newest 2.32 releae and check, if this solves this issue.

I'm sorry for what is essentially a +1, but I'm noticing the same behavior.
At some point during the day day_energy suddenly becomes 0 and then returns to the previous (correct) measurement during the next poll.
Maybe this can be handled so that it simply sends nothing instead of 0 in cases where 0 doesn't make any sense?

Maybe this can be handled so that it simply sends nothing instead of 0 in cases where 0 doesn't make any sense?

The question is how to define "where 0 doesn't make any sense"?
Options:
Ignore Modbus response frames having zeros only

Pros: Easy to implement
Cons: Prone to false positives (zeroed frame may be valid in some situations)

Publish measurement having value equal zero only when zero is read two times in a row or more.

Pros: More fine grained control over the reported values.
Cons: Risk of losing legitimate zero measurement.

What do you think? Or maybe you have other proposal?
This feature would have to be put behind a feature flag, and be disabled by default.

I had trouble with the newest firmware and rolled back to MW3_16U_5406_1.63. The firmware 1.63 reports the same zero frames as reported above.
Therefore, I would prefer the first option as it prevents data from being pushed like in the "Logger is online for the first time this day" and "First zero value in the evening" sections.
@nifoc: In such a case, are all your values 0 or only day_energy?

Short update as I tested a small hack to filter 0 frames based on our discussion.
I added this temporary workaround to my docker container:
diff --git a/src/deye_modbus.py b/src/deye_modbus.py
index 1178712..13666d4 100644
--- a/src/deye_modbus.py
+++ b/src/deye_modbus.py
@@ -47,6 +47,9 @@ class DeyeModbus:
         modbus_crc.reverse()

         modbus_resp_frame = self.connector.send_request(modbus_frame + modbus_crc)
+        if "0" * 80 in modbus_resp_frame.hex():
+            self.__log.debug("Ignore empty frame: %s", modbus_resp_frame.hex())
+            return {}
         if modbus_resp_frame is None:
             return {}
         return self.__parse_modbus_read_holding_registers_response(modbus_resp_frame, first_reg, last_reg)

2024-08-31 04:45:50,980 - DeyeModbus - DEBUG - Ignore empty frame:<PHONE_NUMBER>000000001292000000000000000000001292000000000000094200000000000000000000138800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000012a00000000000000000000000000001517
2024-08-31 04:46:51,252 - DeyeModbus - DEBUG - Ignore empty frame:<PHONE_NUMBER>000000001292000000000000000000001292000000000000094200000000000000000000138800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000012a00000000000000000000000000001517

and in combination with a Utility Meter:
utility_meter:
  energy:
    name: "Production today (daily reset)"
    source: sensor.deye_inverter_mqtt_production_today
    cycle: daily

Home Assistent generates diagrams without any outliers in the morning or in the afternoon:

As there is no consensus about the best strategy here, my proposal is to implement them one-by-one, as needed, so the end-user can choose the one that suits him best. Yours will be added first @CarstenGrohmann

Let me note that I am experiencing similar sporadic "spikes" readings from Deye SUN12k SG04LP3 in my fork, where I observe regular +ok=... response with valid CRC. I do not use block reads but single parameter and the reads are not zero but usually close to. I thought that some delay (1 second) between AT+INVDATA=... send and +ok=... recv would solve the problem of getting correct value(s) to the logger. So, there is some bug in the firmware that deyecloud.com is resolving somewhat better that us with AT+ protocol and I am looking for a root cause of such behaviour.

@CarstenGrohmann
Hi can you add the HA sensor settings of this sensor?

sensor.deye_inverter_mqtt_production_today

I have trouble with my daily sensor values which my small inverter  see https://github.com/kbialek/deye-inverter-mqtt/issues/197

I have no special/manual settings for the sensor.deye_inverter_mqtt_production_today sensor as I use my plugin Deye MQTT HA Plugin to announce the MQTT values to HA. In addition,  I use several UtilityMeter sensor is used to reset most values at midnight.

Hi Carsten
I saw that you use a Utility Meter for the daily sensor.
But i guess that doesn't solve my issue that my inverter sends it's last known value (before it got offline) for day_energy or your production_today via mqtt when it goes back online,
He resets to 0 when the time is set, but sadly he first sends sensor data via mqqt before that.
I just installed your plugin, but that wouldn't change the issue as it only changes the mqtt topics and auto creates the mqtt sensors (which i have done manually before). Nevertheless a plugin to automatically create the sensors is a great benefit.
But as i said an additional utility meter wouldn't change a thing if the sensor which is used has wrong values.
But I will see this tomorrow when the inverter comes back online.
The sensor has wrong values from 0:00 - 7:20 which would be then used for the utility meter as well.
(image of my day_energy sensor)

Btw do you plan to enable the active_power_regulation via mqtt as well?
Btw2 why are you using state_class:total and not total_increasing for your total / daily sensors?

@Bhoft My microinverters behave in the same way. I will think how to solve this in a systemic way.

@kbialek
good that i am not the only one 👍
I just checked your code and if you aggregrate over multiple inverters you are already checking if now isn't the last aggregation date.
https://github.com/kbialek/deye-inverter-mqtt/blob/8a56a28eee905bff2e3b5e0cf9d54b80db76df88/src/deye_multi_inverter_data_aggregator.py#L43-L46
Maybe something like this would also work for single inverter usage?

But as i said an additional utility meter wouldn't change a thing if the sensor which is used has wrong values.

The utility meter cannot change the values of the origin sensor. The utility meter creates a new sensor with changed values and you can use the new sensor instead of the original sensor.

From my perspective the utility meter is a feasible workaround.

Btw do you plan to enable the active_power_regulation via mqtt as well?

Yes, I'll do after I added support for another set of topics.

With 3 Utility meters (battery and production) I have been able to correctly restart the sensors at midnight for the Energy card.
Further, I needed to add several sensor templates to correctly recompute for Sunsynk-Power-Flow-Card

Deye Inverter MQTT Essential Power (computed)
Deye Inverter MQTT Internal CT total power (computed)
Deye Inverter MQTT Inverter Power (computed)
Deye Inverter MQTT Non Essential Power (computed)
Deye Inverter MQTT Tesla (computed)
Solar power (computed)
SolarEdge Meter1 Power actual (inverted)

where some missing sensors (e.g. frequency) are taken from another inverter (Solaredge).
Btw, I would love to see R/W registers such as peak shaving (191), limit_control (142), (off) grid state, battery limits,  ... to be implemented for automated (timed)  control of the inverter such as https://github.com/klatremis/esphome-for-deye is!

hi!
I'm currently testing this beta image ghcr.io/kbialek/deye-inverter-mqtt:2024.09.1-beta-2
It contains these PRs

https://github.com/kbialek/deye-inverter-mqtt/pull/198
https://github.com/kbialek/deye-inverter-mqtt/pull/199

I encourage you to give it try
@CarstenGrohmann You will need to add DEYE_DATA_FILTERS=ignore_zeroed_frames to the config to activate this functionality

I'm currently testing this beta image ghcr.io/kbialek/deye-inverter-mqtt:2024.09.1-beta-2 It contains these PRs

I have installed the beta version yesterday and have an error in the log (multiple times)
2024-09-13 05:59:04,549 - DeyeDaemon - ERROR - Unexpected error during runner execution
Traceback (most recent call last):
  File "/opt/deye_inverter_mqtt/deye_daemon.py", line 53, in __invoke_action
    self.__action()
  File "/opt/deye_inverter_mqtt/deye_inverter_state.py", line 60, in read_from_logger
    processor.process(events)
  File "/opt/deye_inverter_mqtt/plugins/deye_plugin_ha_discovery.py", line 237, in process
    self.publish_sensor_information(topic, event.observation)
  File "/opt/deye_inverter_mqtt/plugins/deye_plugin_ha_discovery.py", line 167, in publish_sensor_information
    "unit_of_measurement": observation.sensor.unit,
AttributeError: 'DailyResetSensor' object has no attribute 'unit'

Besides that the day energy value is now 0 when the inverter comes online.
2024-09-13 05:14:04,299 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/day_energy', value: '0.0'

same for the PV1 values
2024-09-13 05:14:04,323 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/dc/pv1/day_energy', value: '0.0'

The AttributeError exception is raised from my code. It looks like the unit attribute is missing from DailyResetSensor even if the class is derived from Sensor class.
2024-09-13 11:08:31,622 - DeyeDaemon - ERROR - Unexpected error during runner execution
Traceback (most recent call last):
  File "/opt/deye_inverter_mqtt/deye_daemon.py", line 53, in __invoke_action
    self.__action()
  File "/opt/deye_inverter_mqtt/deye_inverter_state.py", line 60, in read_from_logger
    processor.process(events)
  File "/opt/deye_inverter_mqtt/plugins/deye_plugin_ha_discovery.py", line 320, in process
    self.publish_sensor_information(topic, event.observation)
  File "/opt/deye_inverter_mqtt/plugins/deye_plugin_ha_discovery.py", line 242, in publish_sensor_information
    "unit_of_measurement": observation.sensor.unit,
AttributeError: 'DailyResetSensor' object has no attribute 'unit'

@kbialek: What do you think about this issue?

A new beta image 2024.09.1-beta-3 is there

I fixed the error reported by @CarstenGrohmann I was actually expecting some errors to appear. The first implementation was quite dirty.
I've added a log message DeyeDaemon - INFO - Active data filters: ignore_zeroed_frames

I've updated my docker image and published a development branch with new metric and total_increasing state class for day_energy in https://github.com/CarstenGrohmann/deye-mqtt-ha-plugin/tree/more_inverters.
Today it was raining. I'll monitor all changes during the days next week with more sun.
Thank you for this fast update.

A new beta image 2024.09.1-beta-3 is there

I have installed that beta and have these results:

carstens addon is working again (the old version haven't tested the new version yet)
there is an issue with the "total" values

Issue with total values:
These are the Log lines when my micro inverter came online  today the total values are 0 for the first 3 MQTT publishes.
2024-09-14 05:13:50,598 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/total_energy', value: '0.0'
2024-09-14 05:14:48,080 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/total_energy', value: '0.0'
2024-09-14 05:16:48,082 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/total_energy', value: '0.0'
2024-09-14 05:17:48,160 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/total_energy', value: '201.3'

Same for other total values like PV1 Total energy
2024-09-14 05:13:50,647 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/dc/pv1/total_energy', value: '0.0'
2024-09-14 05:14:48,105 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/dc/pv1/total_energy', value: '0.0'
2024-09-14 05:16:48,103 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/dc/pv1/total_energy', value: '0.0'
2024-09-14 05:17:48,202 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/dc/pv1/total_energy', value: '44.4'

Which results in a wrong value

which was btw already the case in the first beta. I just didn't saw it but can see it in the statistics

Issue with total values:
These are the Log lines when my micro inverter came online today the total values are 0 for the first 3 MQTT publishes.
2024-09-14 05:13:50,598 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/total_energy', value: '0.0'
2024-09-14 05:14:48,080 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/total_energy', value: '0.0'
2024-09-14 05:16:48,082 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/total_energy', value: '0.0'
2024-09-14 05:17:48,160 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/total_energy', value: '201.3'

Same for other total values like PV1 Total energy
2024-09-14 05:13:50,647 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/dc/pv1/total_energy', value: '0.0'
2024-09-14 05:14:48,105 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/dc/pv1/total_energy', value: '0.0'
2024-09-14 05:16:48,103 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/dc/pv1/total_energy', value: '0.0'
2024-09-14 05:17:48,202 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/dc/pv1/total_energy', value: '44.4'

@Bhoft I do not think that this behavior is caused by the changes I added in the beta image. I belive that what you see is caused by zeroed frames returned by the logger "just" right after it has powered on in the morning. You may try to add DEYE_DATA_FILTERS=ignore_zeroed_frames config variable to mitigate this.

@Bhoft I do not think that this behavior is caused by the changes I added in the beta image. I belive that what you see is caused by zeroed frames returned by the logger "just" right after it has powered on in the morning. You may try to add DEYE_DATA_FILTERS=ignore_zeroed_frames config variable to mitigate this.

You are right i just extended the history in my statistics and it also occur way before the beta.  I just didn`t saw this because the default range on the history was only the last 2 days and i didn't checked before that time range.

I have added the ignore_zeroed_frames  filter yesterday but still got the Zero value publishes for total values this morning
relevant log entries
2024-09-14 13:22:33,170 - DeyeDaemon - INFO - Active data filters: ignore_zeroed_frames
2024-09-15 05:10:45,896 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/dc/pv1/total_energy', value: '0.0'
2024-09-15 05:11:45,738 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/dc/pv1/total_energy', value: '0.0'
2024-09-15 05:12:45,747 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/dc/pv1/total_energy', value: '0.0'
2024-09-15 05:14:45,734 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/dc/pv1/total_energy', value: '45.4'

and register values at that times
2024-09-15 05:10:45,447 - DeyeInverterState - INFO - Reading registers [metrics group: {'micro'}, range: 003c-0074]
2024-09-15 05:10:45,455 - DeyeTcpConnector - INFO - Re-connected to socket on IP <IP_ADDRESS>
2024-09-15 05:10:45,456 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e50200000000000000000000000000000103003c003945d4ca15
2024-09-15 05:10:45,632 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a5850010150003067c63e50201c6e6b52e2f00000090853038010372000000000000000000000000000000000000000000000000000008ca0000000000000000000000000000000000000000000000000000000000000000000008ff08f3138400000000000000000000000002920002001d000000000000000000000000000000000000000000000000000000004e27be15
2024-09-15 05:10:45,632 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings_micro', 'settings'}, range: 0028-0028]
2024-09-15 05:10:45,637 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e502000000000000000000000000000001030028000104026b15
2024-09-15 05:10:45,821 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a5150010150004067c63e50201c6e6b52e30000000908530380103020064b9af1915

2024-09-15 05:11:45,447 - DeyeInverterState - INFO - Reading registers [metrics group: {'micro'}, range: 003c-0074]
2024-09-15 05:11:45,452 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e50200000000000000000000000000000103003c003945d4ca15
2024-09-15 05:11:45,637 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a585001015000d067c63e5020102e7b52e6b0000008f853038010372000000000000000000000000000000000000000000000000000008d400000000000000000000000000000000000000000000000000000000000000000000090108f5138100000000000000000000000002920002001d00000000000000000000000000000000000000000000000000000000de883d15
2024-09-15 05:11:45,637 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings_micro', 'settings'}, range: 0028-0028]
2024-09-15 05:11:45,643 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e502000000000000000000000000000001030028000104026b15
2024-09-15 05:11:45,707 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a515001015000e067c63e5020102e7b52e6c0000008f8530380103020064b9af9b15

2024-09-15 05:12:45,447 - DeyeInverterState - INFO - Reading registers [metrics group: {'micro'}, range: 003c-0074]
2024-09-15 05:12:45,453 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e50200000000000000000000000000000103003c003945d4ca15
2024-09-15 05:12:45,635 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a585001015000f067c63e502013ee7b52ea70000008f853038010372000000000000000000000000000000000000000000000000000008ca00000000000000000000000000000000000000000000000000000000000000000000090308f7138600000000000000000000000002920002001d00000000000000000000000000000000000000000000000000000000d8f41c15
2024-09-15 05:12:45,635 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings_micro', 'settings'}, range: 0028-0028]
2024-09-15 05:12:45,639 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e502000000000000000000000000000001030028000104026b15
2024-09-15 05:12:45,695 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a5150010150010067c63e502013ee7b52ea80000008f8530380103020064b9af1515

2024-09-15 05:13:45,447 - DeyeInverterState - INFO - Reading registers [metrics group: {'micro'}, range: 003c-0074]
2024-09-15 05:13:45,452 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e50200000000000000000000000000000103003c003945d4ca15
2024-09-15 05:13:45,635 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a5850010150012067c63e5020179e7b52ee30000008f853038010372000000000000000000000000000000000000000000000000000008ca00000000000000000000000000000000000000000000000000000000000000000000090108f5138200000000000000000000000002920002001d000000000000000000000000000000000000000000000000000000008a045015
2024-09-15 05:13:45,635 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings_micro', 'settings'}, range: 0028-0028]
2024-09-15 05:13:45,640 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e502000000000000000000000000000001030028000104026b15
2024-09-15 05:13:46,007 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a5150010150013067c63e502017ae7b52ee40000008f8530380103020064b9af9015

2024-09-15 05:14:45,448 - DeyeInverterState - INFO - Reading registers [metrics group: {'micro'}, range: 003c-0074]
2024-09-15 05:14:45,452 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e50200000000000000000000000000000103003c003945d4ca15
2024-09-15 05:14:45,631 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a5850010150014067c63e50201b5e7b52e1f0100008f85303801037200000000000008020000000000000000000001c6000001ac000008ca025c0000000001dc0000138800000000000000000000000000000000000000000000090308f7138400000000000000000000000002920002001d000000000000000000000000013f0000013e0000013f0000013f000035915c15
2024-09-15 05:14:45,631 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings_micro', 'settings'}, range: 0028-0028]
2024-09-15 05:14:45,637 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e502000000000000000000000000000001030028000104026b15
2024-09-15 05:14:45,700 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a5150010150015067c63e50201b6e7b52e200100008f8530380103020064b9af0b15

"Ignoring zeroed frame" wasn't found in the log files, so i guess the skipping doesn't work in my case?
What i found strange is that i don't see it today in the popup statistics (where it was visible yesterday)

but in the detailed statistics

but i guess it has something to do with the resolution of the timeline or some usage of function like mean.
I just mentioning this because it seems you can't rely on the display of the statistics in the popup.

@CarstenGrohmann @Bhoft  I've built a new beta image 2024.09.1-beta-4

I decided to remove https://github.com/kbialek/deye-inverter-mqtt/pull/198 - it's based on a heuristic which does not  work reliably.
Added https://github.com/kbialek/deye-inverter-mqtt/pull/200 - values will be published only when total energy sensor value is higher than zero
I kept https://github.com/kbialek/deye-inverter-mqtt/pull/199

I've updated the docker image to beta-4. The last version beta-3 runs without any anormalities:
2024-09-16 16:20:38,398 - DeyeModbus - DEBUG - Ignoring zeroed frame:<PHONE_NUMBER>0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078ab
2024-09-16 16:24:39,445 - DeyeModbus - DEBUG - Ignoring zeroed frame:<PHONE_NUMBER>0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078ab

@CarstenGrohmann Maybe I should explain it a bit more. Modbus responses shared by @Bhoft contain mostly zeros, but not only zeros, thus zeroed frames ignoring does not work for him. This convinced me that ignoring zeroed frames is only an unreliable weak heuristic. That's why I decided to replace it with "data readiness check". The service will publish the values to MQTT only when "data readiness check" is successful.
Now what "data readiness check" actually is? It simply checks if "Production Total" value is greater than zero. This check should work for all inverters I belive.
I'm testing beta-4 now. I see that probably I did there something wrong. I will come back to you.

Hi i have tested the beta-4 now for two days and can say that the Data readiness check seems to work.
I have no publishes for the deye/total_energy in the mornings with Zero.
e.g. first connect this morning and its publishes
2024-09-18 05:16:21,099 - DeyeTcpConnector - INFO - Re-connected to socket on IP <IP_ADDRESS>
2024-09-18 05:16:21,099 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e50200000000000000000000000000000103003c003945d4ca15
2024-09-18 05:16:21,311 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a5850010150005067c63e50201fbddb72e360100002a843238010372000d00000000084a0000000200020003000201d7000001b9000008de02700000000001eb0000138800000000000000000000000000000000000000000000091409081380000000000000000000000000028f0002001d001000000000000000000000012d0000012e0000012d0000012e00005768d115
2024-09-18 05:16:21,311 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings_micro', 'settings'}, range: 0028-0028]
2024-09-18 05:16:21,321 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e502000000000000000000000000000001030028000104026b15
2024-09-18 05:16:21,382 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a5150010150006067c63e50201fbddb72e360100002a8432380103020064b9afeb15

2024-09-18 05:16:21,386 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-18 05:16:21.382964:212.20000000000002]
2024-09-18 05:16:21,386 - DeyeInverterState - DEBUG - Data readiness check result: True
2024-09-18 05:16:21,387 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/logger_status', value: 'online'
2024-09-18 05:16:21,392 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/day_energy', value: '1.3'
2024-09-18 05:16:21,398 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/total_energy', value: '212.2'

So everthing is fine 👍
The only strange thing is that the debug message of the readiness check is always true, so even when offline
2024-09-18 05:14:27,235 - DeyeTcpConnector - DEBUG - Could not open socket on IP <IP_ADDRESS>: [Errno 113] Host is unreachable
2024-09-18 05:14:27,236 - DeyeInverterState - DEBUG - Data readiness observations: []
2024-09-18 05:14:27,236 - DeyeInverterState - DEBUG - Data readiness check result: True
2024-09-18 05:14:27,236 - DeyeInverterState - DEBUG - No observation events received (offline)

I couldn't find a single line in my logs with Data readiness check result: False or Data readiness observations: [total_energy@timestamp:0]
What i also find a bit strange is I find many entries in the log with<PHONE_NUMBER>002.
...
Data readiness observations: [total_energy@2024-09-17 14:50:21.082968:212.0]
Data readiness observations: [total_energy@2024-09-17 14:51:21.089482:212.0]
Data readiness observations: [total_energy@2024-09-17 14:52:21.079735:212.10000000000002]
Data readiness observations: [total_energy@2024-09-17 14:53:21.086853:212.10000000000002]
....100 of times
Data readiness observations: [total_energy@2024-09-18 05:49:21.348573:212.20000000000002]
Data readiness observations: [total_energy@2024-09-18 05:50:21.348877:212.20000000000002]
Data readiness observations: [total_energy@2024-09-18 05:51:21.350037:212.3]
Data readiness observations: [total_energy@2024-09-18 05:52:21.354751:212.3]
Data readiness observations: [total_energy@2024-09-18 05:53:21.351361:212.3]

...
Data readiness observations: [total_energy@2024-09-18 07:23:21.379221:212.5]
Data readiness observations: [total_energy@2024-09-18 07:24:21.377085:212.5]
Data readiness observations: [total_energy@2024-09-18 07:25:21.687514:212.60000000000002]
Data readiness observations: [total_energy@2024-09-18 07:53:21.396904:212.70000000000002]
.. also multiple times
Data readiness observations: [total_energy@2024-09-18 07:54:21.431255:212.70000000000002]
Data readiness observations: [total_energy@2024-09-18 07:55:21.384730:212.8]
Data readiness observations: [total_energy@2024-09-18 07:56:21.436309:212.8]

The<PHONE_NUMBER>002 seems a bit strange in my opinion.
There are multiple entries and its always ends with<PHONE_NUMBER>002.
For me it looks like something isn't read correctly from the registers?
Reading before where no<PHONE_NUMBER>002 is added
2024-09-18 07:24:21,122 - DeyeInverterState - INFO - Reading registers [metrics group: {'micro'}, range: 003c-0074]
2024-09-18 07:24:21,127 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e50200000000000000000000000000000103003c003945d4ca15
2024-09-18 07:24:21,305 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a5850010150027067c63e502017bfbb72eab020000aa843238010372000200000000084d0000000000000000000101d8000001b9000008e802700000000e01ed000013880000000000000000000000000cc20000000000000dac091e090f1382000000000000000000000000028f0002001d00000000000000000000000001b4000a01c900080164000801ac00351ccb6a15
2024-09-18 07:24:21,305 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings_micro', 'settings'}, range: 0028-0028]
2024-09-18 07:24:21,313 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e502000000000000000000000000000001030028000104026b15
2024-09-18 07:24:21,376 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a5150010150028067c63e502017bfbb72eab020000aa8432380103020064b9afa115
2024-09-18 07:24:21,377 - DeyeInverterState - DEBUG - Production today: 0.2
2024-09-18 07:24:21,377 - DeyeInverterState - DEBUG - Production Total: 212.5
2024-09-18 07:24:21,377 - DeyeInverterState - DEBUG - Phase1 Voltage: 228.0
2024-09-18 07:24:21,377 - DeyeInverterState - DEBUG - Phase1 Current: 1.4
2024-09-18 07:24:21,377 - DeyeInverterState - DEBUG - Phase1 Power: 319.2
2024-09-18 07:24:21,377 - DeyeInverterState - DEBUG - AC Freq: 50.0
2024-09-18 07:24:21,377 - DeyeInverterState - DEBUG - Uptime: 0.0
2024-09-18 07:24:21,377 - DeyeInverterState - DEBUG - PV1 Voltage: 43.6
2024-09-18 07:24:21,377 - DeyeInverterState - DEBUG - PV1 Current: 1.0
2024-09-18 07:24:21,377 - DeyeInverterState - DEBUG - PV1 Power: 43.6
2024-09-18 07:24:21,378 - DeyeInverterState - DEBUG - PV1 Production today: 0.0
2024-09-18 07:24:21,378 - DeyeInverterState - DEBUG - PV1 Total: 47.2
2024-09-18 07:24:21,378 - DeyeInverterState - DEBUG - PV2 Voltage: 45.7
2024-09-18 07:24:21,378 - DeyeInverterState - DEBUG - PV2 Current: 0.8
2024-09-18 07:24:21,378 - DeyeInverterState - DEBUG - PV2 Power: 36.6
2024-09-18 07:24:21,378 - DeyeInverterState - DEBUG - PV2 Production today: 0.0
2024-09-18 07:24:21,378 - DeyeInverterState - DEBUG - PV2 Total: 44.1
2024-09-18 07:24:21,378 - DeyeInverterState - DEBUG - PV3 Voltage: 35.6
2024-09-18 07:24:21,378 - DeyeInverterState - DEBUG - PV3 Current: 0.8
2024-09-18 07:24:21,378 - DeyeInverterState - DEBUG - PV3 Power: 28.5
2024-09-18 07:24:21,378 - DeyeInverterState - DEBUG - PV3 Production today: 0.0
2024-09-18 07:24:21,379 - DeyeInverterState - DEBUG - PV3 Total: 62.4
2024-09-18 07:24:21,379 - DeyeInverterState - DEBUG - PV4 Voltage: 42.8
2024-09-18 07:24:21,379 - DeyeInverterState - DEBUG - PV4 Current: 5.3
2024-09-18 07:24:21,379 - DeyeInverterState - DEBUG - PV4 Power: 226.8
2024-09-18 07:24:21,379 - DeyeInverterState - DEBUG - PV4 Production today: 0.1
2024-09-18 07:24:21,379 - DeyeInverterState - DEBUG - PV4 Total: 49.3
2024-09-18 07:24:21,379 - DeyeInverterState - DEBUG - DC Total Power: 335.5
2024-09-18 07:24:21,379 - DeyeInverterState - DEBUG - Operating Power: 0.0
2024-09-18 07:24:21,379 - DeyeInverterState - DEBUG - AC Active Power: 326.6
2024-09-18 07:24:21,379 - DeyeInverterState - DEBUG - Radiator temperature: 25.0
2024-09-18 07:24:21,379 - DeyeInverterState - DEBUG - Active power regulation: 100.0
2024-09-18 07:24:21,380 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-18 07:24:21.377085:212.5]
2024-09-18 07:24:21,380 - DeyeInverterState - DEBUG - Data readiness check result: True

next reading with<PHONE_NUMBER>002
024-09-18 07:25:21,123 - DeyeInverterState - INFO - Reading start
2024-09-18 07:25:21,123 - DeyeInverterState - INFO - Reading registers [metrics group: {'micro'}, range: 003c-0074]
2024-09-18 07:25:21,132 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e50200000000000000000000000000000103003c003945d4ca15
2024-09-18 07:25:21,317 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a5850010150029067c63e50201b7fbb72ee7020000aa843238010372000300000000084e0000000000000000000101d8000001b9000008e802700000000f01ed000013880000000000000000000000000d640000000000000d70091e090d1381000000000000000000000000028f0002001d00000000000000000000000001aa000b01cf00090164000801ae003772320a15
2024-09-18 07:25:21,318 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings_micro', 'settings'}, range: 0028-0028]
2024-09-18 07:25:21,329 - DeyeTcpConnector - DEBUG - Request frame: a5170010450000067c63e502000000000000000000000000000001030028000104026b15
2024-09-18 07:25:21,687 - DeyeTcpConnector - DEBUG - Received response frame in 1. attempt: a515001015002a067c63e50201b7fbb72ee7020000aa8432380103020064b9af1b15
2024-09-18 07:25:21,687 - DeyeInverterState - DEBUG - Production today: 0.3
2024-09-18 07:25:21,687 - DeyeInverterState - DEBUG - Production Total: 212.6
2024-09-18 07:25:21,687 - DeyeInverterState - DEBUG - Phase1 Voltage: 228.0
2024-09-18 07:25:21,687 - DeyeInverterState - DEBUG - Phase1 Current: 1.5
2024-09-18 07:25:21,687 - DeyeInverterState - DEBUG - Phase1 Power: 342.0
2024-09-18 07:25:21,688 - DeyeInverterState - DEBUG - AC Freq: 50.0
2024-09-18 07:25:21,688 - DeyeInverterState - DEBUG - Uptime: 0.0
2024-09-18 07:25:21,688 - DeyeInverterState - DEBUG - PV1 Voltage: 42.6
2024-09-18 07:25:21,688 - DeyeInverterState - DEBUG - PV1 Current: 1.1
2024-09-18 07:25:21,688 - DeyeInverterState - DEBUG - PV1 Power: 46.9
2024-09-18 07:25:21,688 - DeyeInverterState - DEBUG - PV1 Production today: 0.0
2024-09-18 07:25:21,688 - DeyeInverterState - DEBUG - PV1 Total: 47.2
2024-09-18 07:25:21,688 - DeyeInverterState - DEBUG - PV2 Voltage: 46.3
2024-09-18 07:25:21,688 - DeyeInverterState - DEBUG - PV2 Current: 0.9
2024-09-18 07:25:21,688 - DeyeInverterState - DEBUG - PV2 Power: 41.7
2024-09-18 07:25:21,688 - DeyeInverterState - DEBUG - PV2 Production today: 0.0
2024-09-18 07:25:21,689 - DeyeInverterState - DEBUG - PV2 Total: 44.1
2024-09-18 07:25:21,689 - DeyeInverterState - DEBUG - PV3 Voltage: 35.6
2024-09-18 07:25:21,689 - DeyeInverterState - DEBUG - PV3 Current: 0.8
2024-09-18 07:25:21,689 - DeyeInverterState - DEBUG - PV3 Power: 28.5
2024-09-18 07:25:21,689 - DeyeInverterState - DEBUG - PV3 Production today: 0.0
2024-09-18 07:25:21,689 - DeyeInverterState - DEBUG - PV3 Total: 62.4
2024-09-18 07:25:21,689 - DeyeInverterState - DEBUG - PV4 Voltage: 43.0
2024-09-18 07:25:21,689 - DeyeInverterState - DEBUG - PV4 Current: 5.5
2024-09-18 07:25:21,689 - DeyeInverterState - DEBUG - PV4 Power: 236.5
2024-09-18 07:25:21,690 - DeyeInverterState - DEBUG - PV4 Production today: 0.1
2024-09-18 07:25:21,690 - DeyeInverterState - DEBUG - PV4 Total: 49.3
2024-09-18 07:25:21,690 - DeyeInverterState - DEBUG - DC Total Power: 353.5
2024-09-18 07:25:21,690 - DeyeInverterState - DEBUG - Operating Power: 0.0
2024-09-18 07:25:21,690 - DeyeInverterState - DEBUG - AC Active Power: 342.8
2024-09-18 07:25:21,690 - DeyeInverterState - DEBUG - Radiator temperature: 24.4
2024-09-18 07:25:21,690 - DeyeInverterState - DEBUG - Active power regulation: 100.0
2024-09-18 07:25:21,691 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-18 07:25:21.687514:212.60000000000002]
2024-09-18 07:25:21,691 - DeyeInverterState - DEBUG - Data readiness check result: True

It's still published as 212.6
2024-09-18 07:25:21,700 - DeyeMqttClient - DEBUG - Publishing message. topic: 'deye/total_energy', value: '212.6'

@Bhoft

I couldn't find a single line in my logs with Data readiness check result: False

Interesting. Please watch it for few more days.

The<PHONE_NUMBER>002 seems a bit strange in my opinion.
There are multiple entries and its always ends with<PHONE_NUMBER>002.
For me it looks like something isn't read correctly from the registers?

This is how floating point number encoding manifests. It's not an issue. You can ignore it.

@kbialek

I couldn't find a single line in my logs with Data readiness check result: False

Interesting. Please watch it for few more days.

Checked again this morning and there were 4 readiness checks with false and 0.0.
2024-09-19 05:11:27,652 - DeyeInverterState - DEBUG - Data readiness observations: []
2024-09-19 05:11:27,652 - DeyeInverterState - DEBUG - Data readiness check result: True
2024-09-19 05:12:21,749 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-19 05:12:21.746710:0.0]
2024-09-19 05:12:21,780 - DeyeInverterState - DEBUG - Data readiness check result: False
2024-09-19 05:13:21,750 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-19 05:13:21.746222:0.0]
2024-09-19 05:13:21,750 - DeyeInverterState - DEBUG - Data readiness check result: False
2024-09-19 05:14:21,752 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-19 05:14:21.749380:0.0]
2024-09-19 05:14:21,752 - DeyeInverterState - DEBUG - Data readiness check result: False
2024-09-19 05:15:22,554 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-19 05:15:22.549701:0.0]
2024-09-19 05:15:22,554 - DeyeInverterState - DEBUG - Data readiness check result: False
2024-09-19 05:16:21,771 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-19 05:16:21.763551:216.9]
2024-09-19 05:16:21,771 - DeyeInverterState - DEBUG - Data readiness check result: True

I checked again older logs and the check with false did occur on the 17th as well (also 4 times).
2024-09-17 05:19:13,757 - DeyeInverterState - DEBUG - Data readiness check result: True
2024-09-17 05:20:13,650 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-17 05:20:13.647024:0.0]
2024-09-17 05:20:13,650 - DeyeInverterState - DEBUG - Data readiness check result: False
2024-09-17 05:21:13,661 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-17 05:21:13.658232:0.0]
2024-09-17 05:21:13,661 - DeyeInverterState - DEBUG - Data readiness check result: False
2024-09-17 05:22:13,626 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-17 05:22:13.623930:0.0]
2024-09-17 05:22:13,626 - DeyeInverterState - DEBUG - Data readiness check result: False
2024-09-17 05:23:13,733 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-17 05:23:13.729732:0.0]
2024-09-17 05:23:13,733 - DeyeInverterState - DEBUG - Data readiness check result: False
2024-09-17 05:24:13,631 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-17 05:24:13.628597:210.9]
2024-09-17 05:24:13,631 - DeyeInverterState - DEBUG - Data readiness check result: True

I have no idea why this didn't occure yesterday on the 18th.
The only thing i see that the first true total energy reading has these<PHONE_NUMBER>002
2024-09-18 05:15:27,268 - DeyeInverterState - DEBUG - Data readiness observations: []
2024-09-18 05:15:27,269 - DeyeInverterState - DEBUG - Data readiness check result: True
2024-09-18 05:16:21,386 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2024-09-18 05:16:21.382964:212.20000000000002]
2024-09-18 05:16:21,386 - DeyeInverterState - DEBUG - Data readiness check result: True

Checked again this morning and there were 4 readiness checks with false and 0.0.

Thanks for the feedback @Bhoft This means that the solution works as expected.

I have no idea why this didn't occure yesterday on the 18th.

I suppose, that it's caused by a timing issue in the inverter's firmware. Probably the memory locations that are read over Modbus are being initialized after some delay. Now, it depends when we query the values. We do that either before or after the initialization. If we do before, then we get zeros. If we do after then we get the expected values.
Having said that, I'm getting confident that the new version can be released. What about you @CarstenGrohmann . Did you have a chance to test beta-4?

I activated beta-4 a few hours after you released it. I see the same true and false behavior as reported by @Bhoft.
My Docker logs do not contain any errors.
I am doing fine with the current changes. My data in HA looks good.
Please feel free to publish the changes.
BTW: Did you have a chance to read my comment in https://github.com/kbialek/deye-inverter-mqtt/pull/200#pullrequestreview-2310667825?


staticcheck reports issues

running staticheck on code is producing following violations:
staticcheck ./...
commons/oci/database.go:178:3: this value of ok is never used (SA4006)
commons/oci/database.go:503:6: func getConflictRetryPolicy is unused (U1000)
commons/oci/provider.go:80:15: error strings should not be capitalized (ST1005)
commons/oci/provider.go:80:15: error strings should not end with punctuation or a newline (ST1005)
commons/sharding/exec.go:55:181: error should be returned as the last argument (ST1008)
commons/sharding/gsm.go:432:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/provstatus.go:90:6: should omit comparison to bool constant, can be simplified to instance.Spec.IsExternalSvc (S1002)
commons/sharding/provstatus.go:138:6: should omit comparison to bool constant, can be simplified to instance.Spec.IsExternalSvc (S1002)
commons/sharding/provstatus.go:196:6: should omit comparison to bool constant, can be simplified to instance.Spec.IsExternalSvc (S1002)
commons/sharding/provstatus.go:254:3: unnecessary guard around call to delete (S1033)
commons/sharding/provstatus.go:279:3: unnecessary guard around call to delete (S1033)
commons/sharding/provstatus.go:304:3: unnecessary guard around call to delete (S1033)
commons/sharding/provstatus.go:338:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/provstatus.go:358:10: error strings should not be capitalized (ST1005)
commons/sharding/provstatus.go:380:3: unnecessary guard around call to delete (S1033)
commons/sharding/scommon.go:221:6: should omit comparison to bool constant, can be simplified to masterFlag (S1002)
commons/sharding/scommon.go:315:27: should omit comparison to bool constant, can be simplified to instance.Spec.IsDebug (S1002)
commons/sharding/scommon.go:489:2: this value of labelSelector is never used (SA4006)
commons/sharding/scommon.go:497:11: error strings should not be capitalized (ST1005)
commons/sharding/scommon.go:615:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/scommon.go:734:9: empty branch (SA9003)
commons/sharding/scommon.go:747:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/scommon.go:789:6: func labelsForShardingDatabaseKind is unused (U1000)
commons/sharding/scommon.go:800:6: func removeAlpha is unused (U1000)
commons/sharding/scommon.go:839:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/scommon.go:845:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/scommon.go:851:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/scommon.go:863:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/scommon.go:899:6: func getGsmShardValidateCmd is unused (U1000)
commons/sharding/scommon.go:900:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/scommon.go:906:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/scommon.go:911:6: func getGsmAddShardGroupCmd is unused (U1000)
commons/sharding/scommon.go:912:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/scommon.go:918:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/scommon.go:924:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/scommon.go:961:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/scommon.go:1013:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/scommon.go:1166:4: error should be returned as the last argument (ST1008)
commons/sharding/shard.go:108:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/shard.go:358:2: this value of service is never used (SA4006)
commons/sharding/shard.go:405:2: should merge variable declaration with assignment on next line (S1021)
commons/sharding/shard.go:421:2: should merge variable declaration with assignment on next line (S1021)
controllers/database/shardingdatabase_controller.go:155:2: this value of idx is never used (SA4006)
controllers/database/shardingdatabase_controller.go:173:6: should omit comparison to bool constant, can be simplified to isShardTopologyDeleteTrue (S1002)
controllers/database/shardingdatabase_controller.go:285:6: should omit comparison to bool constant, can be simplified to !OraShardSpex.IsDelete (S1002)
controllers/database/shardingdatabase_controller.go:305:7: should omit comparison to bool constant, can be simplified to !OraShardSpex.IsDelete (S1002)
controllers/database/shardingdatabase_controller.go:379:6: should omit comparison to bool constant, can be simplified to !OraShardSpex.IsDelete (S1002)
controllers/database/shardingdatabase_controller.go:463:9: should omit comparison to bool constant, can be simplified to oshInst.deltopology (S1002)
controllers/database/shardingdatabase_controller.go:501:72: should omit comparison to bool constant, can be simplified to !r.osh[idx].onsProviderFlag (S1002)
controllers/database/shardingdatabase_controller.go:545:4: error should be returned as the last argument (ST1008)
controllers/database/shardingdatabase_controller.go:567:10: error strings should not be capitalized (ST1005)
controllers/database/shardingdatabase_controller.go:606:2: this value of sfSetFound is never used (SA4006)
controllers/database/shardingdatabase_controller.go:607:2: this value of svcFound is never used (SA4006)
controllers/database/shardingdatabase_controller.go:877:11: error strings should not be capitalized (ST1005)
controllers/database/shardingdatabase_controller.go:881:11: error strings should not be capitalized (ST1005)
controllers/database/shardingdatabase_controller.go:885:11: error strings should not be capitalized (ST1005)
controllers/database/shardingdatabase_controller.go:987:9: empty branch (SA9003)
controllers/database/shardingdatabase_controller.go:990:5: should omit comparison to bool constant, can be simplified to updateFlag (S1002)
controllers/database/shardingdatabase_controller.go:1028:7: should omit comparison to bool constant, can be simplified to !availableFlag (S1002)
controllers/database/shardingdatabase_controller.go:1036:5: should omit comparison to bool constant, can be simplified to availableFlag (S1002)
controllers/database/shardingdatabase_controller.go:1047:2: this value of gsmSfSet is never used (SA4006)
controllers/database/shardingdatabase_controller.go:1051:2: this value of podList is never used (SA4006)
controllers/database/shardingdatabase_controller.go:1075:28: error strings should not be capitalized (ST1005)
controllers/database/shardingdatabase_controller.go:1101:7: should omit comparison to bool constant, can be simplified to !availlableFlag (S1002)
controllers/database/shardingdatabase_controller.go:1109:5: should omit comparison to bool constant, can be simplified to availlableFlag (S1002)
controllers/database/shardingdatabase_controller.go:1113:35: error strings should not be capitalized (ST1005)
controllers/database/shardingdatabase_controller.go:1121:2: this value of catalogSfSet is never used (SA4006)
controllers/database/shardingdatabase_controller.go:1123:2: this value of podList is never used (SA4006)
controllers/database/shardingdatabase_controller.go:1146:36: error strings should not be capitalized (ST1005)
controllers/database/shardingdatabase_controller.go:1166:2: this value of shardSfSet is never used (SA4006)
controllers/database/shardingdatabase_controller.go:1208:2: this value of gsmPod is never used (SA4006)
controllers/database/shardingdatabase_controller.go:1225:2: this value of shardSfSet is never used (SA4006)
controllers/database/shardingdatabase_controller.go:1234:7: should omit comparison to bool constant, can be simplified to !OraShardSpex.IsDelete (S1002)
controllers/database/shardingdatabase_controller.go:1272:5: should omit comparison to bool constant, can be simplified to eventMsgFlag (S1002)
controllers/database/shardingdatabase_controller.go:1299:5: should omit comparison to bool constant, can be simplified to eventMsgFlag (S1002)
controllers/database/shardingdatabase_controller.go:1325:5: should omit comparison to bool constant, can be simplified to eventMsgFlag (S1002)
controllers/database/shardingdatabase_controller.go:1355:5: should omit comparison to bool constant, can be simplified to eventMsgFlag (S1002)
controllers/database/shardingdatabase_controller.go:1366:2: this value of shardSfSet is never used (SA4006)
controllers/database/shardingdatabase_controller.go:1386:7: should omit comparison to bool constant, can be simplified to !OraShardSpex.IsDelete (S1002)
controllers/database/shardingdatabase_controller.go:1387:8: should omit comparison to bool constant, can be simplified to !setLifeCycleFlag (S1002)
controllers/database/shardingdatabase_controller.go:1428:6: should omit comparison to bool constant, can be simplified to deployFlag (S1002)
controllers/database/shardingdatabase_controller.go:1433:5: should omit comparison to bool constant, can be simplified to errStr (S1002)
controllers/database/shardingdatabase_controller.go:1435:10: error strings should not be capitalized (ST1005)
controllers/database/shardingdatabase_controller.go:1435:10: error strings should not end with punctuation or a newline (ST1005)
controllers/database/shardingdatabase_controller.go:1481:2: this value of shardSfSet is never used (SA4006)
controllers/database/shardingdatabase_controller.go:1482:2: this value of shardPod is never used (SA4006)
controllers/database/shardingdatabase_controller.go:1484:2: this value of gsmPod is never used (SA4006)
controllers/database/shardingdatabase_controller.go:1495:7: should omit comparison to bool constant, can be simplified to OraShardSpex.IsDelete (S1002)
controllers/database/shardingdatabase_controller.go:1496:8: should omit comparison to bool constant, can be simplified to !setLifeCycleFlag (S1002)
controllers/database/shardingdatabase_controller.go:1597:2: this value of svcFound is never used (SA4006)
main.go:122:2: this value of i is never used (SA4006)
test/e2e/autonomousdatabase_controller_bind_test.go:64:8: const bindingHardLinkTestFileName is unused (U1000)
test/e2e/autonomousdatabase_controller_create_test.go:63:3: const changeStateTimeout is unused (U1000)
test/e2e/autonomousdatabase_controller_create_test.go:64:3: const changeStateInterval is unused (U1000)
test/e2e/behavior/shared_behaviors.go:48:2: should not use dot imports (ST1001)
test/e2e/behavior/shared_behaviors.go:49:2: should not use dot imports (ST1001)
test/e2e/util/oci_config_util.go:137:2: ineffective assignment to field configUtil.provider (SA4005)
test/e2e/util/oci_config_util.go:196:54: should omit nil check; len() for nil slices is defined as zero (S1009)
test/e2e/util/oci_vault_request.go:52:6: func waitForVaultStatePolicy is unused (U1000)

@psaini79 @harayuanwang Please look into above static check issues

Fixed in drop 2 that just released


Parameterless constructor error with EventHandler

Hi there,
I'm getting the following error on startup when trying to use Event Handlers: Cannot dynamically create an instance of type. Reason: No parameterless constructor defined.

My project is a brand new project where I copied the DTO, Handler, Request and Endpoint classes as per the documentation just to try it out, as I have a use case in a real project where this seems like it would suit my needs perfectly (need to respond quickly with OK to a request, then fire and forget a task that may take 4-8 seconds). https://fast-endpoints.com/docs/event-bus#_1-define-an-event-model-dto
using System;

namespace FastEndpointsEventHandlerDemo.Features.Order
{
    public class OrderCreationHandler : IEventHandler<OrderCreatedEvent>
    {
        private readonly ILogger _logger;

        public OrderCreationHandler(ILogger<OrderCreationHandler> logger)
        {
            _logger = logger;
        }

        public Task HandleAsync(OrderCreatedEvent eventModel, CancellationToken ct)
        {
            _logger.LogInformation($"order created event received:[{eventModel.OrderID}]");
            return Task.CompletedTask;
        }
    }
}

If I add a parameterless constructor as per the error, then I can't use constructor dependency injection.
I'm using the lastest version <IP_ADDRESS>-beta. Was there a change that hasn't been documented yet?
Also, the search box on the documentation isn't working (never produces any results)

oops... looks like i forgot to delete an unneeded line from the old code.
fixed in v5.3.1
thanks for reporting!


Why the MoE layer forces the input hidden dimenstion the same as the output hidden dimension?

I notice a problem when I read the tutorial of MoE. As the figure shows, it says the input dimension must be equal to the output dimension. This absolutely imports complexity for many DNNs, and I don't understand why this is necessary. In my view, the output dimension is supposed to be easily set at will?

@ykim362 -- I know its a very old issue but do you mind explaining this here?

I think this is because the initial implementation is based on the NLP applications following GShard and Switch. We have a certain tensor dimension assumption - batch, sequence length at the beginning of input tensors.

Hi,
I have fixed this issue in this PR https://github.com/microsoft/DeepSpeed/pull/2530/files.


When using copilot the autocomplete is bugged

I have nvim with github copilot,
When I open a styles file the tab key prints: copilot#Accept("")

I've solved this removing the line:
call s:map_key("", "hyperstyle-tab")
and adding a line to remap UltiSnipsExpandTrigger: let g:UltiSnipsExpandTrigger=""


Allow reset when the process is running

The reset button seem to behave strangely when trying to reset when there is a running process

All the steps besides the third one got reset.
I think this is because of the can_reset functions, that are implemented only for some steps.
I think we should just delete them. We want to allow reset while the process is running so that the user can submit a new workflow.

The above scenario also seems to indicate some bug in WizzardApp implementation, since it should not allow the reset at all when one of the steps cannot be reset.


Adds linter rules for license and import. Fixes linting (#319)

Signed-off-by: Ashwin Pc<EMAIL_ADDRESS>Signed-off-by: Ashwin Pc<EMAIL_ADDRESS>(cherry picked from commit 317f15665b900737565eff8c8b0b8534f47ddac1)
Description
[Describe what this change achieves]
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

This is a backport PR originated from https://github.com/opensearch-project/opensearch-dashboards-functional-test/pull/319


nftables various heira data variables not found

Hi Tom,
Just been testing the latest version of your CIS module.  Found a few issues around resolution of some nftable variables from the heira tables.  I'm sending you a pull request which should explain it best.

Currently my vms using nftables work as expected with no issues.


Formal verification of interrupt detection

@CharlyCst You can already review & merge if you want. I still need to make sure that the detected interrupt is the same. Currently I only check if they detects equivalently but I don't check the returned type

@CharlyCst I rebased the commit and introduced a new function in Virt-sail which allows us to model check the entire virtualisation of the interrupts at once :)


Show error messages in contributed commands somewhere discoverable

Extension:
import * as vscode from 'vscode';

export function activate(context: vscode.ExtensionContext) {
	context.subscriptions.push(vscode.commands.registerCommand('sd.helloWorld', () => {
		throw Error('Super helpful debugging information');
	}));
}

Run command, note that the super helpful debugging info gets discarded:

If you dig a bit you can find the error logged in the Extension Host output channel, but that is pretty undiscoverable.
This came up a couple times at the VS Code extension hackathon and students did not know how to see what was actually failing. I think we could go a few ways on this:

Include the error message in the notification
Include in notification a directive to enable "stop on caught exceptions". (This isn't ideal because running an extension with this enabled will trigger a bunch of unrelated stops)
log the error to console and put a button in the notification that opens developer tools.
put a button in the notification to open the extension host output channel

I assume this is happening when a command is triggered via the command palette...
Generally, we don't have special error handling for commands from extensions vs commands from the core and I that's a good choice. Instead, each caller of a command should handle errors in the best fitting ways

@bpasero would you accept PR for this? Speaking with first-time extension authors at the hackathon this was a large point of confusion.


#46 Output field description below the field (we don't support the po…

…sition option yet)

If you need to publish a new version to npm, we have to increment package version to 0.1.4 as it is in the develop branch.


Added resolution scaling sandcasle example

Fixes #8102
This sandcastle example lets you set a custom resolution scale or use the device pixel resolution.

Thanks for the pull request @IanLilleyT!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

fixed latest problem

Thanks @IanLilleyT


make generate images function work with parallel in CIFAR files

What does this PR do?

Remove unused FLAG variables in cifar experiments.
Make generate_images function work with parallel

Fixes #82 and partially 73
Before submitting

[x] Did you make sure title is self-explanatory and the description concisely explains the PR?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you list all the breaking changes introduced by this pull request?
[x] Did you test your PR locally with pytest command?
[x] Did you run pre-commit hooks with pre-commit run -a command?

Did you have fun?
Make sure you had fun coding 🙃

-- DO NOT MERGE --
After two tests, the above fix does not seem to perform as well as the main branch. I got an FID of 4.9 for the two tests while it should be 3.6. For now, I consider the parallel training not fixed.


Tag release

Hi @zpao ,
Is it possible to tag a release ?

We haven't had any "releases" and there isn't a version number in the repo. Happy to do it and make up a version number but can't do it without knowing the goal (presumably it's for composer, which might only read the version from tags?)

You are absolutly right.
Actually people have to whitelist this library in their root composer.json due to dev minimum stability.

Cool, tagged v1.0.0. https://github.com/reactjs/react-php-v8js/tree/v1.0.0

Thanks !


Update CUPs Documentation to use cupsctl

Use cupsctl  to make cupsd config changes, and lpstat -W completed -o in a cronjob to ensure configured pruning without purging active jobs.

Hey @rabbitt, thanks for contributing to the privacy guides.
Using cupsctl is way cleaner than using heredoc… great contribution. I see changes are essentially written to /etc/cups/cupsd.conf without requiring sudo. 🙌
I believe launch daemon step  is required to make sure cupsd.conf is not overwritten during macOS updates… what do you think?

Hey @rabbitt, thanks for contributing to the privacy guides.

My pleasure!

I believe launch daemon step  is required to make sure cupsd.conf is not overwritten during macOS updates… what do you think?

Sure, understanding your specific use case, I think that makes sense for you. For me, I prefer to manually reconfigure after an OS update because having a launchd service reconfigure things without my awareness, or possible consent, always makes me nervous, and is somewhat akin to "spooky action at a distance" in that I might not always expect or always want the change. Again, in your use case, it probably makes sense :-)


maybe explain more clearly the VSCode setting..

sorry, could be because English is not my native language, but as I first understand it, I thought I just have to set the path to the zls.exe file in the VSCode ZLS setting, but every thing I tried give the error :
"Couldn't start client Zig Language Server Client".
until I realize that it's not the path that is needed, but the command to launch zls......
maybe  the text about VSCode setting could be made clearer about that, for the next newcomers.
thanks.

Hey @ffred! I totally agree with your analysis! I thought that the current description (Path to \zls` executable.) was clear enough, but now that I read it over, it does seem to imply the *directory* of the zls` executable. I'll change this soon and update the version available on the store!

I changed the description to Path to zls executable. Example: C:/zls/zig-cache/bin/zls.exe., which should clarify things. Thanks for your issue! :)


Add support for nested python containers and mixed dtypes

Fixes #457, #407, and #358 (and potentially more that I don't want to bother to find).  I've now spent roughly 20 hours working on this over 3 different attempts, so I'll need to take a short break before addressing any review comments (though it's quite possible that due to the amount of churn any review will take a long time)!

Oops, it just occurred to me that we'll need a helper to decode objects created with previous version of the extension! I'll make that real quick.


Folder structure broken in v2.0.2

Currently running v2.02 and the folder structure is now broken. Some workspaces are in their folders but others are just in the root. I have all are saved in their site/client folder inside the ~/sites folder that I have this extension pointed to. If I install v1.7.1 it works as expected and how it has been.

Can you please attach some screen shots, also what settings do you have for condense file tree. Also can you show the folder structure how it appears on the file system

Ok so this appears to be an issue with the Condense File Tree option. Unchecking that makes them appear like they do in v1.7.1.

I'm not sure what issues it could be apart from maybe you didn't have it on before.
In tests I saw the same structure with 1.7.1 and 2.0.0.
I have noticed some issues with condese and certain tree structures and explorer compact setting which I shall address in the next patch release.
Did you always have Condense File Tree enabled before?

Closed as seems fixed


SDK: fix navigation bugs in deployed docs

See this comment
Todo

[ ] Investigate and fix the problem

It does work, but some links in the Readme and/or when navigating from one page to another inside the deployed docs, you end up getting redirected to the dApp due to the router fallback guards

@andrevmatos I updated the issue title and description.

@andrevmatos Could you pinpoint atleast one link which gets redirected wrongly ?

In the docs homepage, Architecture > Vertical, there's a Raiden link, which should lead to the Raiden class documentation, but redirects to the dApp.

@andrevmatos @taleldayekh The abi and deployment now dont exist, what do we want those bullet points to be replaced with ?

abi and deployment are data directories and don't contain any logic.

abi is the output of the TypeChain contracts interfaces used for type safety.
deployment contains information about the deployed Raiden contracts for the Ethereum test networks.


feat(aws-cdk): add support for HTTPS_PROXY

Also fix usage of CredentialProviderChain in the SDK creation.
Fixes #645.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.

please release this fix....


Select Filter template not working. TypeError: Cannot read property 'value' of undefined

  {
    value: 0,
    label: "Best Seller"
  },
  {
    value: 1,
    label: "Evergreen"
  },
  {
    value: 2,
    label: "Old Category-No recent demand"
  },
  {
    value: 3,
    label: "New Category"
  }
];

[...,    dataField: "seg",
    text: "Segment",
    sort: true,
    formatter: cell =>
      selectOptionsArr.filter(opt => opt.value === cell)[0].value || "",
    filter: selectFilter({
      options: selectOptionsArr
    })
  }
];

Not enough information to reproduce it. So close it. Please open another issue and follow the instruction to create an clear issue description. thanks


@metamask/jazzicon

✘ [ERROR] Could not resolve "@metamask/jazzicon"
node_modules/react-metamask-avatar/dist/esm/index.js:1:34:
  1 │ import e from"react";import a from"@metamask/jazzicon";import r from"@emotion/styled";const s={},t=e=>{const{address:r,size:t}=e;if(!r||42!==r.length)return"";const i=`${t}...
    ╵                                   ~~~~~~~~~~~~~~~~~~~~

You can mark the path "@metamask/jazzicon" as external to exclude it from the bundle, which will
remove this error and leave the unresolved path in the bundle.
✘ [ERROR] Could not resolve "@emotion/styled"
node_modules/react-metamask-avatar/dist/esm/index.js:1:68:
  1 │ import e from"react";import a from"@metamask/jazzicon";import r from"@emotion/styled";const s={},t=e=>{const{address:r,size:t}=e;if(!r||42!==r.length)return"";const i=`${t}...
    ╵                                                                     ~~~~~~~~~~~~~~~~~

You can mark the path "@emotion/styled" as external to exclude it from the bundle, which will
remove this error and leave the unresolved path in the bundle.
/home/saksham/Work/sperax/chaquen_frontend/node_modules/esbuild/lib/main.js:1651
let error = new Error(text);
^
Error: Build failed with 2 errors:
node_modules/react-metamask-avatar/dist/esm/index.js:1:34: ERROR: Could not resolve "@metamask/jazzicon"
node_modules/react-metamask-avatar/dist/esm/index.js:1:68: ERROR: Could not resolve "@emotion/styled"
at failureErrorWithLog (/home/saksham/Work/sperax/chaquen_frontend/node_modules/esbuild/lib/main.js:1651:15)
at /home/saksham/Work/sperax/chaquen_frontend/node_modules/esbuild/lib/main.js:1059:25
at /home/saksham/Work/sperax/chaquen_frontend/node_modules/esbuild/lib/main.js:1527:9
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
errors: [Getter/Setter],
warnings: [Getter/Setter]
}
Node.js v20.9.0
Desktop (please complete the following information):

Device: acer nitro
OS: ubuntu
Browser -brave
Version [e.g. 22]

Hey @sakshamjaiswal1 thanks for the comments.
I do think that the libraries you mentioned are peer dependencies. This means that you as integrator need to provide them.
This keeps the bundle size low of this package and allows you as integrator to specify what version of emotion/styled you want to use.
🙏🙏🙏
Let me know if this doesnt work for you.


Properly support recursive types

Porting tests over from the official Avro python package (see #18), I noticed that recursive types aren't properly supported (for very simple use cases the schema parsing doesn't crash, but I am not even sure encoding would actually work).
Let's support recursive types for real.
There are already some tests to uncomment which cover the issue; they can be found grepping for the issue number.

It seems that there is already a pull request open: #53


[Doc Improvement][Use external OAuth providers][3437956] #9912

Acrolinx Scorecards
We currently enforce a minimum score of 80.
Click the scorecard links for each article to review the Acrolinx feedback on grammar, spelling, punctuation, writing style, and terminology:

Article
Score
Issues
Scorecard
Processed

msteams-platform/tabs/how-to/authentication/auth-oauth-provider.md
90
6
link
:white_check_mark:

More info about Acrolinx
Use the Acrolinx extension, or sidebar, in Visual Studio Code to check spelling, grammar, style, tone, clarity, and key terminology when you're creating or updating content. For more information, see Use the Visual Studio Code extension to run Acrolinx locally.

Acrolinx Scorecards
We currently enforce a minimum score of 80.
Click the scorecard links for each article to review the Acrolinx feedback on grammar, spelling, punctuation, writing style, and terminology:

Article
Score
Issues
Scorecard
Processed

msteams-platform/tabs/how-to/authentication/auth-oauth-provider.md
90
17
link
:white_check_mark:

More info about Acrolinx
Use the Acrolinx extension, or sidebar, in Visual Studio Code to check spelling, grammar, style, tone, clarity, and key terminology when you're creating or updating content. For more information, see Use the Visual Studio Code extension to run Acrolinx locally.


Can gymnasticon appear in Peloton's app as a cadence sensor?

Gymasticon is now working for me, via an RPi, for Zwift. Are any of its output modes capable of appearing as a cadence sensor to the Peloton app? (I'm not seeing it appear when Peloton App searches.)

Happy to hear it! I just pushed up #39 which adds the feature you described. To try it out, clone the repo:
git checkout -t origin/csc-server
npm install
npm run build
npm link
gymnasticon

Wow, thanks! I should be able to test it tomorrow.

Is there something you need to do to enable this? I updated to the latest version and did the Garmin permission trick. So ANT+ is working (which is great), but I don't see a BT CSC advertisement anywhere. I didn't see anything in the --help but thought maybe I'm missing something. I guess the concept is that (conceivably) in the latest update the rpi is outputting 1 CPS advertisement, 1 CSC advertisement, and an ANT+ cycling power/cadence message?

Added in #39 and will be in the next release.


[BUG] iPhoneOS17 not make build for ios

i make pull request and solve it any user can use it by :
html_editor_enhanced:
git:
url: https://github.com/osamamohammed98/html-editor-enhanced.git
ref: 877096c

now i make build


dotnet build, test outside the dockerfile

To improve workflow time

ng build should also be outside the dockerfile

finally, I changed my mind on this. It is useful to run the dockerfile every time even if there is some Github integration that is not available, such as automatically adding comments to PR.


Improvement: refine CLI commands, options, and communication with server

Unflatten commands and simplify communication between CLI and server.
Example:
Usage: mina-indexer [OPTIONS] <COMMAND>

Commands:
  server
  accounts
  blocks
  chain
  checkpoints
  ledger
  staking-ledger
  snark
  summary
  transactions
  help

Builds on top of improvements in #648.

Closed via #681.


Add available_request function

Summary
Add a new method to get status from usersock daemon.
Impact
ALT1250/GS2200
Testing
Spresense with LTE/Wifi

@SPRESENSE please fix the errors

@SPRESENSE
Does this PR depend on https://github.com/apache/nuttx/pull/9647?
If so, please add a comment to both the commit messages and the summary.

@SPRESENSE
I think you need to fix the sim:usrsocktest as well.
nsh> usrsocktest
Starting unit-tests...
Testing group "char_dev" =>
	Group "char_dev": [OK]
Testing group "no_daemon" =>
	Group "no_daemon": [OK]
Testing group "basic_daemon" =>
	[TEST ASSERT FAILED!]
		In function "open_close":
		line 113: Assertion `(bool)((sd >= 0)) == (bool)(true)' failed.
			got value: 0
			should be: 1
_assert: Current Version: NuttX  11.0.0 8f91e6d52a Jun 30 2023 16:41:42 sim
_assert: Assertion failed : at file: usrsocktest_basic_daemon.c:527 task: usrsocktest 0x55ba4122eaa0


Unsubscribe all project email preferences when user unsets project_email_communication

Linked to https://github.com/zooniverse/Panoptes-Front-End/issues/4220#issuecomment-361304385 and https://github.com/zooniverse/Panoptes-Front-End/pull/4229
When a user sets project_email_communication to false it should unsubscribe all their user project preferences.
Review checklist

[ ] First, the most important one: is this PR small enough that you can actually review it? Feel free to just reject a branch if the changes are hard to review due to the length of the diff.
[ ] If there are any migrations, will they the previous version of the app work correctly after they've been run (e.g. the don't remove columns still known about by ActiveRecord).
[ ] If anything changed with regards to the public API, are those changes also documented in the apiary.apib file?
[ ] Are all the changes covered by tests? Think about any possible edge cases that might be left untested.

I realise I've misunderstood what this PR is supposed to do. @camallen mind refreshing my senile mind please?

Setting the project_email_communication field on a user to false will unsubscribe all their project prefs via the API since this was introduced.
I can't remember our exact conversation in meat space but from memory we decided to add a button to  unsubscribe from all (new api end point?) and allow folks to manage the individual prefs via normal form controls as well. Should we jump on call with grant to hash this out again?

Sounds good to me!


Why header not support html format instead of support only text?

As the topic is written

Please support this issue, thank you :)

+1

+1