Replies: 2 comments 1 reply
-
|
From my perspective, the log is primarily a debugging tool. I already have a problem that most bug reports do not provide a sufficiently detailed log (with debug logging enabled, covering a sufficiently long time period, and without being inappropriately filtered), making diagnosis of issues tricky. If anything, I am likely to increase the volume of logging. Taking the two specific examples that you list... The first is the issue of disconnected devices. The problem is that this plugin was written with the expectation that appliances being disconnected was an abnormal condition, that would typically be short-lived, e.g. due to a loss of internet connectivity. This is the case with my own appliances - they are always connected, even when switched off. Hence, this plugin expects to be able to connect to the appliances to read their capabilities when Homebridge is started. If an appliance is disconnected at start-up then the plugin initialisation is stalled until the appliance is subsequently connected. Until that happens the plugin will not finish advertising appropriate services to HomeKit (or indeed remove any that are no longer relevant), and some functionality will not be operational. Since this limbo state can be confusing, I think a periodic warning message in the log is entirely appropriate. Once the appliance connects and initialisation completes these messages are not generated again unless Homebridge is restarted, which should be a rare event. Obviously, it would have been better if the plugin had been designed to expect appliances to be disconnected and to handle that more gracefully. However, I am not going to rewrite the plugin for something that would only be a minor benefit, only affects the initial start-up, and doesn't apply to my own usage. There are far more serious start-up issues that should be tackled... The second issue you raise is the program remaining time. For this I have a general logging strategy of all Home Connect API requests/events being logged at Debug log level (which you have disabled) and any interaction with HomeKit (especially anything that bridges between HomeKit and Home Connect) being logged at Info level. In this case the Home Connect API is reporting events for changes to the remaining program duration, and that is then being used to update HomeKit's Hence, I will not be removing either of those log messages. The configuration for this plugin is already quite complicated, and is still missing many functional configuration options that other people have requested. The only configuration options that I might add relating to logging will be to increase the log output to make diagnosing problems easier. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your explanation! |
Beta Was this translation helpful? Give feedback.
-
|
+1 — I found this helpful too, thanks @thoukydides |
Beta Was this translation helpful? Give feedback.
-
Hi,
I like the plugin very much. It provides many features. In my case I am mainly interested in getting the door states, power on/off and program finished events. Most of the time my appliances (except the dish washer) are powered off. Hence, there is no communication. However, the plugin tries to get the data anyway resulting in many log messages (see following log snippet). I like the idea to add an additional logging setting to suppress log messages from disconnected appliances or (if possible) to fine tune the output per event/appliance. It's interesting to see the remaining time from dish washer but it's filling my log with 1 message per minute.
What do you think?
Best regards
Beta Was this translation helpful? Give feedback.
All reactions