I'm running into an issue where when I use this integration to turn off my pi-hole (which works great), and if I manually in Pi-Hole resume blocking, this virtual driver never picks up that it's back on.
In scheduled jobs I do see "updateBlockingResumeTime" scheduled for every minute, however it never updates the actually status. Manually "polling" fixes it.
I have polling set to every 5minutes, but it doesn't seem like it's being kicked off in these cases.
Any idea?
Edit: hmmm, updating the poll timing and turning on debug and hitting save I'm getting this error. Wondering if that is part of the problem @walksonair ?
Thanks for bring this up! I’ve been seeing some issues pop up on my end as well and suspect it’s related to what you’re showing.
I’m attending PyData Seattle through the weekend and will work on this early next week…
1 Like
I’ve just pushed an update that fixes the missing-state issue when Pi-hole blocking is resumed outside of Hubitat.
The driver now cleans up an obsolete unsubscribe call, keeps the minute-by-minute countdown accurate, and clears/reschedules the timer the moment Pi-hole reports blocking is back on, so manual webpage changes show up without mashing “Poll.”
I also dropped my own polling interval down to 1 minute so the virtual switch stays aligned with the Pi-hole UI whenever I toggle blocking there; longer intervals still work, but real-time alignment depends on how frequently Hubitat polls.
I’ll keep exploring whether Pi-hole exposes any event-style hooks in v6 that could reduce the need for polling altogether.
Thanks again for the patience and for flagging the problem! @SoundersDude reports matched some odd behavior I had been meaning to dig into, and the extra urgency kept this from sitting on my to-do list any longer. I appreciate the community eyes on this project and the great feedback!
2 Likes
