Question regarding the service categories

[livinhack]

How could we meaningfully integrate devices that support both a “native” and an alternative method for connecting to Home Assistant into the service/device selection?

Example: Shelly

Should it be categorized as
xyz (Native)
xyz (MQTT)

under Shelly

Or should there be a separate category called MQTT for everything that doesn't connect via Z2M but supports MQTT?

[spacerunner5]

That would be awesome and overdue. I have the same shelly problem: Native, MQTT using commands, MQTT using RPC - 3 Variants, 3 blueprints.

Next issue will come for sure: Devices supporting multiple connection types, like zigbee and matter. Multiple complete definitions for z2m, ZHA, matter, tasmota etc.

In my option, it's a general limitation in the current switch definition implementation. Everything is in one blueprint file. Maybe it could be split: A definition for the hardware (switch) and the associated connector(s)? This would be a fundamental, breaking change. But maybe worth it for the future of the project.

In practice, users than would

1.) select the switch they have

2.) select the connection type

which would make it easier for users and maintaining the switch definitions / blueprints itself.

[livinhack]

A small concept based on your idea.

Image editing only, no code!

[spacerunner5]

sehr cool 😃! Die Switch / Button ist auch super (ist jetzt noch nicht so, oder?), allerdings: z..B. bei den Shellys kannst du pro Input (bsp i4 - 4 Kanäle) einstellen, ob Schalter oder Taster :-) Die Änderung wäre aber schon riesig. Man müsste überlegen, wie man das so umsetzen kann, daß bisherige Nutzer ihre HA Config / Schalter nicht verlieren. Backward compatible also. Ich hoffe wirklich, Du bleibst mit dem Elan am Switchmanager dran. Für mich eines der besten Tools, leider in der bisherigen Implementierung mit noch so einigen Schwächen. Tausend Dank & ein schönes Wochenende! Viele Grüße, Stefan Von meinem iPhone gesendet Am 20.03.2026 um 16:34 schrieb L. Ries ***@***.***>:  A small concept based on your idea. Image editing only, no code! Konzeptgrafiken.gif (view on web)<https://github.com/user-attachments/assets/ba8daa83-1dfc-42a9-bafe-ccccd727b54b> — Reply to this email directly, view it on GitHub<#15?email_source=notifications&email_token=AEUG5D4V7RXQDS5QBK4KCHD4RVQC5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRSGI4DCNZRUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16228171>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEUG5DYNVEMLVZVNDTNB45T4RVQC5AVCNFSM6AAAAACWVGV27OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMRSHAYTOMI>. You are receiving this because you commented.Message ID: ***@***.***>

[macpit]

Hey @livinhack and @spacerunner5 👋

Thanks for the great discussion and the concept mockup — really well thought out!

The idea of separating hardware definitions from connectors is architecturally clean and would definitely reduce blueprint duplication, especially for devices like Shelly that support multiple connection methods.

That said, implementing this would be a fundamental, breaking change to the entire blueprint format and data model — essentially a v4.0 rewrite. Given that the project currently focuses on stability and expanding blueprint coverage, this is not something we plan to tackle in the near future.

But never say never — lets see what the future brings. We will keep this discussion open as a reference if we ever revisit the architecture. 🙂

[livinhack]

No, I just tested it. Only a single file (blueprint-selector.ts) needs to be modified before the build to achieve the look shown in the following images.

[livinhack]

I’ve come across so many switches by now that seem to appear multiple times under different names.

Take Xiaomi switches, for instance: they could easily be consolidated if you simply removed the model number from the names of the duplicates. Furthermore, the model number for the Xiaomi "Double Key" is identical to that of the Aqara D1 Wireless Switch (Double Button)—which makes sense, given that Aqara is a Xiaomi brand—yet the image for the corresponding Aqara switch doesn't match. A cleanup is urgently needed here, as these are surely not the only instances (things look very similar in the Tuya range, too...).

Edit:
Zignito 4 Gang is a 1to1 Copy of Tuya.
I think it would make sense to have a commit-policy "check whether a device is a white-label Tuya device", so as not to unnecessarily bloat the list.