New sensor domain expiry#14067
Conversation
OttoWinter
left a comment
There was a problem hiding this comment.
Nice 👍 I'm already looking forward to this integration.
| add_devices([DomainExpiry(sensor_name, server_name)], | ||
| True) | ||
|
|
||
| hass.bus.listen_once(EVENT_HOMEASSISTANT_START, run_setup) |
There was a problem hiding this comment.
There's no need to wait until Home Assistant start with this platform. Only cert_expiry needs it so that the frontend can show it's ask certificate.
Because the DNS server is running independent of Home Assistant, here we don't need to wait.
| """Fetch the domain information.""" | ||
| import whois | ||
| domain = whois.whois(self.server_name) | ||
| expiry = domain.expiration_date - datetime.today() |
There was a problem hiding this comment.
How does this handle non-UTC timezones? How does whois.whois return the expiration date? Your code is probably ok, just checking.
There was a problem hiding this comment.
expiration date from whois is in UTC
|
|
||
| SCAN_INTERVAL = timedelta(hours=24) | ||
|
|
||
| TIMEOUT = 10.0 |
|
|
||
| def setup_platform(hass, config, add_devices, discovery_info=None): | ||
| """Set up domain expiry sensor.""" | ||
| def run_setup(event): |
There was a problem hiding this comment.
Why are you delaying the setup?
| expiry = domain.expiration_date - datetime.today() | ||
| self._state = expiry.days | ||
| else: | ||
| _LOGGER.error("Cannot get expiry date for %s", self.server_name) |
There was a problem hiding this comment.
set self._state = None ?
There was a problem hiding this comment.
I didn't change it because expiration date will always be datetime. This check is for some domains that don't share this information and error will be triggered only for them
|
IMHO opinion, the |
|
Valid point, but the Certificate Expiry sensor (which probably served as a point of reference here) uses |
|
@fanaticDavid True, but that doesn't mean we should repeat past mistakes. In the end, it's not going to be that big of a deal with either choice, users will have to go to the home-assistant.io component page anyway for setting up the integration. I personally value the direct user experience through descriptive configuration keys more than consistency. (That doesn't mean consistency is not important, it is, but that it's not that high of a priority in this case) |
|
@OttoWinter I agree, we should not repeat past mistakes. I would change |
|
I mean one thing speaking against changing it for cert_expiry is that for that sensor it is actually a host. For example, you can use an IP address with the cert_expiry platform. The difference is that the cert_expiry platform actually does set up a connection to the specified host (+ port!) and checks the server for a valid certificate. The domain_expiry sensor on the other hand never connects to the actual target domain and just uses DNS queries, so it does not connect to a "host". |
|
I stand corrected! Now, back on topic... 😛 |
|
Thanks for the adjustment @masarliev! 👍 |
|
This is pretty much a duplicate of the already available |
|
Yes. It's same. As it seems I didn't know about whois sensor. Should we delete this sensor? |
|
Yes. Opening a PR for that now. |
Description:
Domain expiry sensor.
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.io#5242
Example entry for
configuration.yaml(if applicable):Checklist:
tox. Your PR cannot be merged unless tests passIf user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
REQUIREMENTSvariable (example).requirements_all.txtby runningscript/gen_requirements_all.py..coveragerc.