github danieldotnl/ha-multiscrape v9.1.0
v9.1.0 🔁 Reliable retries and triggers

pre-release5 hours ago

👋 A quick note

I run The Smart Home Newsletter — a weekly curated digest for smart home enthusiasts.

Each issue highlights the most relevant and interesting smart home articles, news, and projects from the past week.

Since you're here, you're clearly into home automation — so you might genuinely enjoy the newsletter.

👉 Subscribe at smarthomenewsletter.com


🔁 What's new in v9.1.0

This release is all about manually triggered scraping (scan_interval: 0). Retries now actually work, you can control how many there are, and the trigger service and refresh button no longer silently drop requests.

🚀 New: configurable max_retries

When scan_interval is 0, a failed run is retried automatically, 30 seconds apart. You can now set how many times with the new max_retries option (default: 3):

multiscrape:
  - resource: http://192.168.1.50/status
    scan_interval: 0
    max_retries: 0 # let an automation decide when to try again
    sensor:
      - ...

Set max_retries: 0 to turn the automatic retries off. This is useful when something outside Multiscrape already coordinates the runs, such as an automation polling a device that only accepts one connection at a time. Without it, a retry could collide with the external loop's request. max_retries is ignored when scan_interval isn't 0. See Retries in the README. (#610, closes #609)

🐛 Bug fixes

  • Retries crashed instead of retrying. With scan_interval: 0, every retry attempt raised an AttributeError, which hid the original error and meant no retry ever happened. Retries are now scheduled correctly. (#610)
  • Reloading left the old scrapers running. After multiscrape.reload, the previous coordinators and HTTP sessions were never shut down. A retry scheduled before the reload could still fire on the orphaned coordinator with the old config and session. Also, each reload leaked another set of sessions. Reloading now shuts down and closes everything it replaces. (#619, closes #617)
  • The trigger service and refresh button could be silently ignored. If you triggered a scrape while one was already running, the request could be dropped without any log message, even though the service call reported success. Now a trigger waits for the running scrape to finish and then runs its own. (#620, closes #618)

Thanks to @Alessandro9042 for the retry fix and the new option!

📚 Documentation

  • Fix the split configuration example and document PUT requests (#616). Thanks @dajiaohuang!

⬆️ Dependencies & Tooling


Full Changelog: v9.0.4...v9.1.0

Don't miss a new ha-multiscrape release

NewReleases is sending notifications on new releases.