What do your binding and reporting screens look like?
Edit: I noticed the video might be confusing but if you pay attention to my taps on the screen it might make more sense. What I was trying to show is that controlling one endpoint didn’t ever change the other endpoint.
I watched your video a few times and I actually think mine would behave the same way, since the light affects the fan and not the other way around. Turning on/off doesn’t seem to either.
Steps to replicate would be more like:
I agree with @alexrmay91 - what you did wouldn’t cause the issue to show. If the steps he just put down don’t show what we’re talking about, try going into the exposes screen for the device in z2m and hitting the refresh button for light brightness to trigger an attribute read.
The issue is caused by the function below having no logic to filter out endpoint 1. Both endpoint 1 and endpoint 2 are interpreted by this function as fan speed changes.
fan_mode: {
cluster: 'genLevelCtrl',
type: ['attributeReport', 'readResponse'],
convert: (model, msg, publish, options, meta) => {
if (msg.data.hasOwnProperty('currentLevel')) {
const mode = intToFanMode(msg.data['currentLevel'] || 1);
return {
fan_mode: mode,
};
}
return msg.data;
},
} satisfies Fz.Converter,
Woah - your bind page looks super different from mine (I haven’t changed these). Mine looks like this (on 3 different modules, 2 different Z2M installs):
@rohan I showed the bind page for my dimmer switch (2in1) since that is where I set up the bind between my dimmer and canopy module.
If I go to the page for my canopy module, it looks identical to your screenshot except I have LevelCtrl ticked in the top entry. I’ve never changes settings here.
Ah - my mistake, I misread it.
Does the problem go away if you unbind the 2-1 to the canopy module?
Edit: I forgot to turn on show screen taps, but I only ever change brightness and off/on. Seems like turning off and on only affects the fan speed because it ramps the transition.
FWIW, I see the same thing. The code snippet @philh30 posted seems like a smoking gun to me too…
Was trying to show that it doesn’t matter which endpoint I control, the other is totally independent. Seconds 18 - 25ish I turn the light off and the fan stays on. The very end I do the same. That is just a partial video showing a much larger test and it is not doing that in my install. In general I have done a bunch of work with z2m and those devices and would likely have noticed that issue.
I think the problem is that EP2 shouldn’t be configured to report on the level cluster. It should only report on the fan cluster. This is why it doesn’t need an ep distinction when parsing those reports because they should only be coming from ep1. It is weird that yours is reporting and I’ve never had any of mine do that. What does it say on your “Reporting” tab? I suppose the code could be changed to ignore levelcontrol reports from ep2 which would likely fix the issue but strange that it is popping up now.
Edit: I still need to figure out why the interview process is different in my install vs yours but try to unbind the LevelCtrl cluster on EP1. You essentially select only LevelCtrl and then click Unbind exactly like the image below:
I followed your instructions at the end and that seems to have fixed it! Quick testing seems like it’s behaving completely normally. Thank you. Let me know if there’s anything else I can share from my system, I’m happy to help.
Level reports from EP2 aren’t a problem - the code interprets them only as fan speed. The problem is level reports from EP1.
Z2M creates the binding on LevelCtrl when a remote is bound to EP1 or when EP1 is added to a group. If I unbind the LevelCtrl cluster, the brightness level is no longer reported to the controller when I adjust it with the bound remote. This does stop the problem that was originally reported - changing light brightness through HA no longer causes the fan speed to be reported incorrectly - but at the cost of having the remote no longer work as it should.
You are correct, I mixed the two endpoints up. I believe the changes here will fix the issue when EP1 LevelCtrl is bound to the coordinator:
It shouldn’t break anything on the VZM35 I believe. I will push it to the Z2M dev channel when I get some time (after letting it settle for a bit to make sure it doesn’t cause any problems). If anyone wants to test it you can enter your docker container, run the following command, then restart their docker container from the command line (not via the Add-on gui because that will overwrite the file).
*My docker container is named zigbee2mqtt, but yours may be different
docker exec -it zigbee2mqtt sh
wget https://pastebin.com/raw/N3H9ypEj -O /app/node_modules/zigbee-herdsman-converters/devices/inovelli.js
exit
docker restart zigbee2mqtt
And now we’ve figured out why I (and others) couldn’t reproduce this. I don’t have anything bound to the light endpoint only the fan endpoint.
Nice detective work!
Hi All,
I’m using my VZM36 via Zigbee2Mqtt, and Openhab.
Have an issue with Fan speed after updating Z2M.
Turning on the fan is fine, as was setting different speeds.
However since the upgrade to Z2M (no other upgrades/changes), sending {"fan_mode": off} no longer turns the fan off as it used to.
I see from the docs inside Z2M that fan_mode only accepts low, smart, medium, high, on
It seems reasonable that off would be an option here as well.
Thoughts?
thanks
/m
Thanks for the very clear and detailed instructions on setting up the canopy zigbee binding @Eric_Inovelli was very helpful and essentially has me up and running on my Hubitat C-7.
The one odd issue I’m running into is everything functions as expected except for the config button cycle function when it comes to turning off the fan. when it gets to “off” nothing seems to happen other than the whole LED bar showing essentially no light to indicate that’s the cycle stage that I’m at.
are there any scenarios or gotcha’s i’m missing? the cycle for speeds per tap seems to be working as expected. I think i saw earlier in the thread about controlling the fan canopy module from somewhere other than the light switch can throw it out of sync? I’d understand not seeing the right LED indication vs speed, but I’d still expect the fan to actually turn off at some stage of the cycling process…
next step is to see if i can get this combo working properly in Smartthings…though i imagine i’ll need to pair my 2-1 switch to HA first and execute and firmware update before bringing it over there…last will be Home Assistant.
I can’t help with the off issue.
What I have found with the “sync” issue is that if you set the fan speed at the canopy, such as via Habitat, when you use the config button it starts the cycle all over again.
Example: if you set the fan to medium via Hubitat, when you press the config button it’s starts at low, then medium, then high, then off.
Thanks @EricM_Inovelli.
Something else crossed my mind.
Let’s say, as part of a home assistant template, I want to dynamically identify the light entity associated with the device (the canopy module). Is there any attribute/property I can use to filter down to the actual light entity?
Here is an example, this will give me all the light entities:
{% set canopy_device = 'canopy_module_device_id' %}
{{ device_entities(canopy_device | string) | select('in', states.light | map(attribute='entity_id') | list ) | list }}
The output:
[
"light.canopy_module_master_bedroom_light",
"light.canopy_module_master_bedroom_light_2"
]
The goal was to improve the filter so I can get “the” light entity back.
Not a big deal. I’m think the answer is no but… I figure I should ask around anyway 
Here is the PR I am working on for the vzm36 endpoint issue. Should be merged with the dev branch soon. (I need to fix some indentation errors).
@CodeMaster I am not too familiar with how you could dynamically filter the light endpoints with a template. Would filtering by the entity name (to exclude _2 for example) be consistent enough? To be honest, I always just disable that extra entity.
@alexrmay91 @philh30 The dev branch of Z2M has the fix that we talked about earlier in the thread. Hope you have been able to test it and make sure you didn’t notice any problems (since it will go into production next week I think.
@EricM_Inovelli Should I undo the steps you shared in this post when I test it? If I understand correctly, the change to Z2M makes unbinding level control unnecessary.
I may not have the time to switch over to the dev branch for testing it. But I will for sure give it a go once they production update goes live! Will update you with my results.