No custom converters. It’s just reporting of level - control works as expected and on/off reporting works. Some steps to replicate:
I use the canopy module with HomeAssistant and ZHA, and haven’t seen any odd behavior, but I feel it’s worth noting: the canopy module, at least with ZHA, shows up as three devices: the fan, the light, and a second light that controls the fan and which does in fact behave as you just described (since it is just a different way of controlling the fan). The logic I have heard for this is that it allows you to bind the fan control to a dimmer device that knows nothing of fan devices.
At least with ZHA, the only way I found to determine which light actually controlled the light was to try it. But of course if it is actually controlling the light, but the (reported?) fan state is also changing, then nothing I said is likely to be relevant 
Anyone know – can I safely use the module with a fan that does not have a light? I’m guessing I can just cap off the light wire, but sometimes electronics aren’t happy when you leave something disconnected so I thought I should double-check.
I think that’s fine. Just cap the light lead, as you suggested.
Can confirm, I run 2 this way with no problems.
Thanks for the reproduction steps. I went through them and in all steps 2/3/4, there was no change in fan speed displayed when adjusting the light brightness.
@EricM_Inovelli any thoughts?
Interesting, I haven’t noticed this. I’ll try to do some testing tomorrow.
@rohan Have you checked whether you’re running a custom converter? I don’t see how that’s possible otherwise. The code I linked above has nothing to prevent brightness reports from impacting the reported fan speed.
@EricM_Inovelli A separate topic, but I raised an issue here regarding how the minimum and maximum parameters are set up in the converter. The documentation of the Blue parameters is self-contradictory, showing in the table that minimum and maximum go up to 254 and 255 respectively, while the detailed description further down the page says 253 and 254. The converter uses the latter ranges, which is a problem since the default maximum that ships on the device is 255.
Nope, not running a custom converter since the production release. I was one of the beta testers for this module and did have a custom converter running until the official release. I double checked that I have no custom converters set up currently.
Here’s what I’m seeing. The actual fan ran at medium and stayed that way the entire time.
Here are the software versions I’m using. But, this behavior has been unchanged for a few months since I received the module. I have one other in my house that behaves the same.
Home Assistant: 2024.5.5
Z2M: 1.38.0-1
Canopy Module: 1.01
Do you see the same things if you control the module from Zigbee2mqtt’s web interface?
Yes. If I go to the canopy module in Z2M and change the light brightness there, the fan will change between high medium and low on that same page.
@EricM_Inovelli Another issue - parameters that are read from the device aren’t being separated by endpoint into the _1 and _2 postfixes. See logs below, where querying smartBulbMode from endpoint 2 fails to update smartBulbMode_2.
[2024-06-07 13:24:45] debug: z2m: Received Zigbee message from 'Patio Fan Right', type 'readResponse', cluster 'manuSpecificInovelli', data '{"smartBulbMode":0}' from endpoint 2 with groupID 0
[2024-06-07 13:24:45] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Patio Fan Right', payload '{"autoTimerOff_1":null,"autoTimerOff_2":null,"breezeMode":null,"brightness":254,"defaultLevelRemote_1":null,"defaultLevelRemote_2":null,"dimmingSpeedDownRemote_1":null,"dimmingSpeedDownRemote_2":null,"dimmingSpeedUpRemote":25,"dimmingSpeedUpRemote_1":null,"dimmingSpeedUpRemote_2":null,"fan_mode":"medium","fan_state":"ON","higherOutputInNonNeutral_1":null,"last_seen":"2024-06-07T13:24:45-04:00","ledColorWhenOn_1":null,"ledIntensityWhenOn_1":null,"linkquality":87,"maximumLevel":254,"maximumLevel_1":null,"maximumLevel_2":null,"minimumLevel":1,"minimumLevel_1":null,"minimumLevel_2":null,"outputMode_1":null,"outputMode_2":null,"quickStartLevel_1":null,"quickStartTime_1":null,"quickStartTime_2":null,"rampRateOffToOnRemote":127,"rampRateOffToOnRemote_1":null,"rampRateOffToOnRemote_2":null,"rampRateOnToOffRemote":127,"rampRateOnToOffRemote_1":null,"rampRateOnToOffRemote_2":null,"smartBulbMode":0,"smartBulbMode_1":null,"smartBulbMode_2":null,"state":"OFF","stateAfterPowerRestored_1":null,"stateAfterPowerRestored_2":null,"update":{"installed_version":67174657,"latest_version":67174657,"state":"idle"},"update_available":null}'
I got my first of 5 installed today.
Running Home Assistant and ZHA.
The user experience on ZHA looks a little odd to me, it shows as 3 devices:
The fan and two lights (see 1, 2 and 3 in the screenshot)…
Devices 1 and 3 are controlling the fan and always in sync.
1 appears to be the proper user interface and 3 a “dimmer” equivalent.
1 will automatically set the fan to the level equivalent of the percentage selected in 3 and vice versa.
2 controls the light and works as expected.
The above, combined with the fact that all configuration parameters are duplicate makes me believe something is wrong.
I already removed, factory reset and added it back but it is always the same.
This behavior is exactly as designed. The “dual” controls for the fan are precisely as you figured it: a “normal” fan interface, and a “dimmer” equivalent.
My recollection is that this was done so you could, if desired, bind the “dimmer” fan control to a device that doesn’t have a “fan” endpoint, such as a standard dimmer switch, thereby allowing you to control the fan using any device with a dimmer endpoint, rather than requiring a specific “fan” control device.
I’d have to double-check, but I believe the “duplicated” configuration parameters are so you can set light and fan parameters separately.
This makes sense but do we have two chips? Because it shows two firmware parameters and yesterday, after the installation, Home Assistant suggested I had two canopy modules to update. I got really confused at the time 
so I updated one of them.
This is a bit messy but… what can we do.
Regarding the “dimmer” equivalent for the fan, I’m guessing it showing all light parameters because it sees it as a light but not all of them are relevant or will work with the fan, correct? In my case it may be better to just disable this entity so it disappear from the UI and avoid future confusion.
The parameters listed are a mix of for the light or fan endpoint and all should be valid, but it can be hard to tell from the UI which applies to which endpoint. It’s probably easiest to go into the Manage Zigbee Device options and use the Inovelli Light (endpoint 1) and Fan (endpoint 2) clusters to set the settings.
Both entities are technically the ‘light’ in HA, and in fact it was originally just 2 lights in HA. The Fan cluster on the device in ZHA is how you get the fan entity too and it’s just matched up to that light.
Yeah, that is the easiest solution if you don’t need the dimmer endpoint in HA then you can disable it. As stated above it is there from a firmware perspective to be able to bind it to devices that only support the level cluster. ZHA creates the entity because it sees that cluster in the firmware for that endpoint.
There is a github issue open for that in Z2M. I haven’t had time to look into it, but if anyone wants to work on it and make a PR I will give it my blessing 
Edit: Here is this Inovelli VZM36 reads attributes into incorrect property names · Issue #22459 · Koenkk/zigbee2mqtt (github.com)
@alexrmay91 I am still confused on what you are seeing because I know I have messed a ton with that device in Z2M / HA and didn’t notice that. I added a new one to one of my Z2M installs and it didn’t replicate.
Did you see the video in this post?
I can’t think of anything special about my setup that could possibly be causing it… I’m just running public release versions of everything, nothing custom or beta to my knowledge. The modules are bound to blue dimmers?
