Open krahabb opened 1 year ago
Thanks for the contribution. Generally it makes sense to handle the exceptions. I'm also fine if we do that as a 2st step.
In the long run I was however thinking of not logging some exceptions and instead creating error-type sensors e.g.
this way we could also trigger the exceptions only on the first occurence. and improve the logging as you mentioned in your other PR
Hello, Sorry to be that late but I didn't receive any notification since some time ago I've completely disabled them in github (they were too much!). I'll try to follow the development even if, at the moment, I'm pretty busy on my own integration. Thank you for following up! Davide
Hello, This is the second part of my proposal to reduce HA log cluttering.
This PR is rather 'intensive' on the code and I'll try to explain the rationale and the coding choices:
async_setup_entry
) has received a different approach (the logic was a bit remanaged) so to return more specific exceptions to HA core in order to let it manage the problem (by either signaling an auth error or in general telling the core to try reload the configuration entry at a later stage)'ViCareEntity'
) in order to use a single point of entry for theentity->update()
call and put the exception logic there. It was straightful enough since the exceptions blocks in all the implementations were the same. Then, the need to trap exceptions in other parts of the code suggested me a different approach based off context managers and that became the solution but the common super class was a nice idea (in my opinion - very personal declination). Now it still implements the single point of entry for the update() call in every entity even if rather simple but can provide other common behaviors (just theentity->device_info()
right now)