You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add reconnect logic for handling update failures in DbusService (#250)
* Add reconnect logic for AhoyDTU/OpenDTU after failed update attempts
* Add reconnect logic tests for DbusService to handle update failures
* Refactor DbusService tests to reset meter data and clean up comments
* Implement reconnect logic in DbusService to handle update failures and manage status codes
* Refactor ReconnectLogicTest to improve setup and add comprehensive tests for reconnect behavior and status code handling
* Enhance reconnect logic in DbusService and configuration files to improve error handling and retry mechanisms
* Add configuration options for retry logic in README and config.example
* Refactor status code handling in DbusService to use constants and improve update logic
* Add error handling modes and update logic in DbusService and tests
- Introduced ErrorMode configuration to switch between "retrycount" and "timeout" modes.
- Updated DbusService to handle error states based on the selected mode.
- Enhanced unit tests to cover new timeout behavior and ensure correct status code handling.
* Refactor DbusService update logic to ensure _refresh_data is called in normal operation and add unit tests for successful update scenarios
* Add error handling modes to README and config.example for improved error management
* Enhance error handling configuration in DbusService and tests
- Added error handling mode and related configuration options to config.example.
- Refactored DbusService to initialize and load error handling properties from configuration.
- Updated unit tests to verify correct reading of error handling configuration values.
* Refactor error handling logic in DbusService to fix the retry condition
* Refactor error handling configuration in DbusService to use constants and update several places accordingly to the code review
* minor changes
Copy file name to clipboardExpand all lines: README.md
+53-1Lines changed: 53 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,6 +15,7 @@
15
15
-[Default options](#default-options)
16
16
-[Inverter options](#inverter-options)
17
17
-[Template options](#template-options)
18
+
-[Error Handling Modes](#error-handling-modes)
18
19
-[Service names](#service-names)
19
20
-[Videos how to install](#videos-how-to-install)
20
21
-[Use Cases](#use-cases)
@@ -122,12 +123,15 @@ Within the project there is a file `/data/dbus-opendtu/config.ini`. Most importa
122
123
| useYieldDay | send YieldDay instead of YieldTotal. Set this to 1 to prevent VRM from adding the total value to the history on one day. E.g. if you don't start using the inverter at 0. |
123
124
| ESP8266PollingIntervall | For ESP8266 reduce polling intervall to reduce load, default 10000ms|
124
125
| Logging | Valid options for log level: CRITICAL, ERROR, WARNING, INFO, DEBUG, NOTSET, to keep logfile small use ERROR or CRITICAL |
125
-
MaxAgeTsLastSuccess | Maximum accepted age of ts_last_success in Ahoy status message. If ts_last_success is older than this number of seconds, values are not used. Set this to < 0 to disable this check. |
126
+
| MaxAgeTsLastSuccess | Maximum accepted age of ts_last_success in Ahoy status message. If ts_last_success is older than this number of seconds, values are not used. Set this to < 0 to disable this check. |
126
127
| DryRun | Set this to a value different to "0" to prevent values from being sent. Use this for debugging or experiments. |
127
128
| Host | IP or hostname of ahoy or OpenDTU API/web-interface |
128
129
| HTTPTimeout | Timeout when doing the HTTP request to the DTU or template. Default: 2.5 sec |
129
130
| Username | use if authentication required, leave empty if no authentication needed |
130
131
| Password | use if authentication required, leave empty if no authentication needed |
132
+
| MinRetriesUntilFail | Minimum number of consecutive update failures before entering error state (StatusCode=10, zero values). Default is 3. |
133
+
| RetryAfterSeconds | If AhoyDTU/OpenDTU is not reachable, try to reconnect after this many seconds. Default is 120. |
134
+
| ErrorMode | Error handling mode: `retrycount` (default, error after N failures) or `timeout` (error after a time period without success). See section below for details. |
131
135
132
136
*1: Please assure that the order is correct in the DTU, we can only extract the first one in a row.
133
137
@@ -182,6 +186,54 @@ This applies to each `TEMPLATE[X]` section. X is the number of Template starting
182
186
183
187
*4: Path in JSON: use keywords and array index numbers separated by `/`. Example (compare [tasmota_shelly_2pm.json](docs/tasmota_shelly_2pm.json)): `StatusSNS/ENERGY/Current/0` fetches dictionary (map) entry `StatusSNS` containting an entry `ENERGY` containing an entry `Current` containing an array where the first element (index 0) is taken.
184
188
189
+
---
190
+
191
+
#### Error Handling Modes
192
+
193
+
The error handling behavior of dbus-opendtu can be configured using the `ErrorMode` and `ErrorStateAfterSeconds` options in your configuration file. This allows you to choose between two flexible strategies for handling communication errors with your DTU (Data Transfer Unit):
194
+
195
+
##### 1. `retrycount` Mode (Default)
196
+
-**Behavior:**
197
+
- The system will attempt to update data from the DTU on every cycle.
198
+
- If a number of consecutive update attempts fail (as set by `MinRetriesUntilFail`), the system enters an error state:
199
+
- All DBus values are set to zero.
200
+
- The DBus `StatusCode` is set to 10 (error).
201
+
- After waiting for `RetryAfterSeconds`, the system will attempt to reconnect and recover.
202
+
-**Configuration:**
203
+
-`ErrorMode=retrycount`
204
+
-`MinRetriesUntilFail=3` (default)
205
+
-`RetryAfterSeconds=120` (default)
206
+
207
+
##### 2. `timeout` Mode
208
+
-**Behavior:**
209
+
- The system always attempts to reconnect and refresh data every `RetryAfterSeconds`.
210
+
- Zero values and error state are only set if the time since the last successful update exceeds `ErrorStateAfterSeconds`.
211
+
- This means the system will keep trying to reconnect, but will only show an error after a defined timeout period has passed without success.
212
+
-**Configuration:**
213
+
-`ErrorMode=timeout`
214
+
-`ErrorStateAfterSeconds=600` (for example, 10 minutes)
215
+
-`RetryAfterSeconds=120` (default)
216
+
217
+
##### Example Configuration
218
+
219
+
```
220
+
# Error handling mode: "retrycount" (default, as before) or "timeout" (after a time period)
221
+
ErrorMode=timeout
222
+
# For "timeout" mode:
223
+
ErrorStateAfterSeconds=600
224
+
# For both modes:
225
+
RetryAfterSeconds=120
226
+
MinRetriesUntilFail=3
227
+
```
228
+
229
+
##### Summary Table
230
+
| Mode | When are zero values set? | When is reconnect attempted? |
| retrycount | After N consecutive failures | After `RetryAfterSeconds`|
233
+
| timeout | After `ErrorStateAfterSeconds` timeout | Always, every `RetryAfterSeconds`|
234
+
235
+
Choose the mode that best fits your reliability and error reporting needs. For most users, the default `retrycount` mode is sufficient. Use `timeout` mode if you want to avoid error states for short outages and only show errors after a longer period without successful updates.
0 commit comments