I’m using z2m and the VZM30 is showing as a light not a switch which means I can’t reassign this to its correct usage within Home Assistant. Does anyone know a workaround?
This is expected behavior since it can control dimmable bulbs. You can make a template switch if you need it to be represented as a simple switch.
I’d argue that is not is primary purpose so probably not the best default. I shouldn’t have to make a template switch to use it for its primary purpose. If I want to dim lights I’d use the many VZM31’s I’ve purchased.
1 Like
In your original post, you asked for a workaround. The template switch is that workaround.
Since the switch needs to support dimming bound devices (like smart bulbs or dumb bulbs connected to other dimmers), it has to show up as a dimmable device on the hub.
Zigbee devices cannot easily change their capabilities displayed to the hub (on most hubs). Zigbee2mqtt is an exception since it has a reconfigure functionality but most hubs do not.
By default, the switch will operate the same (be on) at any brightness above 0, so it should not actually be an issue controlling it from the hub.
It also appears the only way to actually work this in a meaningful way is to create a template switch, which calls the light service such that its a switch. Then create a Switch as X helper to convert it to the actual intention given.
Mind you the purpose of these switches is to do things such as exhaust fans and high loads such as my bathroom heaters, so now I’ve got a mess of a workaround, I strongly disagree this is a good behavior and so far, my effort hasn’t turned into a simple solution. It’s simply not working as intended.
I’m currently attempting to use this for the template switches template:
{{ is_state('light.basement_bathroom_exhaust_fan', 'on') }}
Then using the actions to turn on / off the light service, but this just made the switch and the actual light states non-operational sadly.
Seems like fiddling with all of the states of this did eventually trigger this to work, maybe because one was in the on state, and not correctly synced in Home Assistant it didn’t like it?
I still argue this is not a great choice. I shouldn’t have to do the following to have a reasonable experience:
- Create a template switch, which requires the usage of templating which is not user friendly.
- Create a switch as a x helper to actually convert it to the proper type
This now means when I look at my device I have 3 options for using it, not the best.
This is an example template I just put together:
You can mark the entities that you don’t want for the device “hidden” so that they disappear from the list on the device page.
Thanks for pointing out to hide it, I was not thinking about that.
Oddly now it just suddenly stopped working and I’m getting a weird dictionary error, but I can’t quite fathom why. My other switch is working. Maybe this is somehow related to the multiple steps now?
So that error appears to come and go for me and I’m not quite sure why but it’s happening on both switches. One works then suddenly stops, seems to go back and for so far.
Ah! So if you mark the light as hidden in Home Assistant these workarounds break. So you’ll just always have a light and a switch and if you have a valid translation (such as a fan) for Switch as a then you just get that one since it marks the intermediate as hidden but the original light you cannot mark as hidden or this breaks.
Which of course then breaks actions on areas since I can no longer just turn on the lights in that area and actually only get lights. Now I turn on the lights and all my things, neither of which is good for my scenario especially given voice assistant since it simply won’t know to ignore these.
I don’t think I could say this is a viable workaround and presenting as a light to home assistant is problematic when the user chooses to not use it as a light switch (which I’d argue is the expected behavior, I think presenting a VZ31 as a light switch is logical).
Did you mark it as hidden or as disabled? I’ve not had the behavior you described when it was hidden, only disabled. I am lagging a few versions behind on Home Assistant though (2025.4) so maybe the behavior changed at some point.
Marking this as “Visible” to the off value breaks this for me while still leaving this as “Enabled”. I did double check this!
FYI I am running 2025.7.2.
I have been digging into this and understand the frustration. @rohan has done a good job describing what is going on. We actually had a similar problem with the fan switch when it came out. It presented as a light device because it had the dimming cluster to be able to bind with other devices. We actually were able to get around that by adding the fan cluster in addition to the dimmer cluster. This created two devices though (a fan and a light), but the user could disable the light entity and it didn’t cause any further issues. This situation is a little different, because the device already has the on/off cluster but it is seeing the level cluster and assuming it is a dimmable device.
I don’t see an easy way around that this time from a firmware perspective. I looked into creating a blueprint or a simpler way to automate the template process, and I don’t think a blueprint can create an entity or device so it has be done via the configutation.yml file or through a few steps in the GUI. Unless someone else can point me in a different direction.
I think the best I can do right now is create a help article that can walk users through it. The strange thing is that it stops working when you mark the device as non-visible. I need to do some more testing on that, but it seems like the template should still be able to see the initial device.
I think template entity creation via blueprints is available now: Template - Home Assistant
Let me look at it once I upgrade Home Assistant in a few days.
This seems like a bug somewhere, especially since it works on my older version.
1 Like
This configuration seems to work (using a white dimmer to create a switch). It’s very similar in approach to the YAML template that was originally posted by @jvm33 (I think) a while ago but using the template generator. I’ve used variants of that original template on most of the dimmers configured for On/Off operation that I have installed.
The dimmer itself is marked as “hidden” (“Visible” is unchecked).
Note that in the “Actions on turn on” and and “Actions on turn off” you must add the entity associated with the dimmer not the device,
One comment on the blueprint switch template GUI discussed above is that it does not appear to add an availability_template for the entity.
This has the result that if the dimmer/fan/canopy/on off switch goes unavailable the template switch created from it still shows as available.
With a template switch created in YAML it’s possible to add an availability_template setting so unavailability of the underlying device will bubble up to the template switch and hence also to Apple Home (if the switch is pushed to Home via the Homekit Bridge).
@andrewk’s comments about using the entity and not the device made the difference for me. Seems that was the part that was missing to make this whole solution work, even though it’s a bit of a pain to have to work-around this. I still wish this product was just a “switch” instead of a “light” when it appears in Home Assistant.
It also appears that in 2025.8 there is also the availability_template setting in the UI as well, though I haven’t configured it yet but I’m about to go do that now.
Would it be easier for you if the switch showed up in Home Assistant with an extra on/off switch entity by default and you could just disable the light entity? There may be a way to do that in the Z2M converter.
That would be easier I think. Now that I finally got my workaround working it would behave the same but for additional new switches it would be vastly easier to just turn off the light (or switch depending on what kind of use case I suppose).