feat: allow multiple OTA override index locations

[Pulpyyyy]

zigbee_ota_override_index_location` now accepts a list of locations in addition to a single one. When a list is given, each source (local path or URL) is fetched/read and merged into a single index, so several independent OTA index sources (e.g. community/DIY firmware) can be used at once. Earlier entries take precedence; a source that fails to load is skipped with a warning, and if all fail the override index is ignored.

Ref #10032

[Nerivec]

This doesn't work on multiple fronts:

• bypassing checks & balances in ZH
• fetching on start instead of on-demand

It also introduce a high potential for conflicts (a lot of OTA indexes will be for same devices, but from different sources). Not sure this is something we want (custom indexes are dangerous due to often tricky matching, combining multiple adds to the fire), especially now with the extensive OTA API/frontend support for custom files/indexes.

[Pulpyyyy]

Thanks for the quick review : and you're right on both technical points. Fetching at startup, and doing the index handling in z2m instead of in zigbee-herdsman, is not the best approach. I'd like to fix it rather than drop the idea, because the underlying need isn't covered by the existing options.

The use case is about decentralized DIY firmware. I will maintain two independent custom-firmware projects, each distributed through its own OTA index:

• Pulpyyyy/zigcreate-ota → its own index.json
• Pulpyyyy/zigvindriktning-ota → its own index.json

They are separate repositories, released and updated on their own schedule. A z2m user who owns devices from both projects can today only set zigbee_ota_override_index_location to a single location, so only one of the two device families ever receives OTA updates.

This generalizes. The override index is exactly what lets people publish their own custom firmware : and the more who do, the more there is no single party whose job is to merge those indexes. Maintaining one combined index is trivial when you're the only author; with two independent authors one has to vendor the other's releases; with N authors it isn't feasible. And the existing alternatives don't close this gap:

The central zigbee-OTA repo requires submission/approval and a registered manufacturer code : not every DIY build qualifies (these use a custom manufacturerCode, 20630).
The frontend/API custom-file support, as I understand it, lets a user add individual files or a single index manually; it doesn't let them subscribe to several independently-updated remote indexes (happy to be corrected if it does).
So the specific gap is: follow multiple independent, self-updating index sources, without a coordinator. That's what multiple override locations solve. This was also proposed in #10032 ("the ability to specify one or more OTA-index files and OTA-servers"), so it isn't a one-off request.

So let's imagine it moves entirely into zigbee-herdsman, on-demand:

• setOtaConfiguration accepts string | string[] and just stores the normalized list : no fetching.
• In getOtaIndex, iterate the list and load each via the existing getOtaIndexInternal (so the same checks and parseOtaImage handling apply), then concat with the main index : exactly as it works today for a single override, just in a loop.
• This keeps everything inside ZH (no bypass), fetches on-demand (always fresh), and is purely additive/opt-in: a single string behaves exactly as today, zero change for existing users. The diff is small and reuses existing functions.

The conflict concern stil remains, fair point as multiple sources do make accidental overlap easier. But a single index can already contain conflicting entries today (json doesn't limits entries quantity nor ids) so multiple sources don't introduce a new matching class; they just make federation convenient. The list-based version can actually make this more transparent than today: precedence is the explicit list order, and I can log a warning when two sources declare the same manufacturerCode + imageType, which currently passes silently.

Before I write it: would you be open in principle to zigbee-herdsman accepting a list of override index locations, loaded on-demand in getOtaIndex, with explicit precedence and a duplicate warning? If yes, I'll close this PR and open it against zigbee-herdsman.

[andrei-lazarov]

I believe zigbee-OTA accepts custom / diy firmware. We have images from slacky, pvvx