Welcome back from your time off Eric! Hope it was restful!
I was trying to reverse engineer the ZHA quarks that are being used for the fans, and it seems like it is just copying all of the configuration from a VZM31SN rather than querying the device for the components it supports.
Is that intentional, or does the ZHA Quark need updating to support the new switch? I tried modifying a local copy of the quark, but I was struggling to confirm that it was actually changing anything.
Yes, the user experience is less than stellar in my opinion. The “dimmer” like behavior is made worse by the general ambiguity of the led bar. So far every person that has tried the switch, has expected to be able to cycle speeds by pressing the paddle up, not holding it.
That can be coded into an automation, but that truly seems like a hack to implement something that should exist in firmware. An automation will never be as responsive and trouble free as being implemented in the switch itself.
I’m not EricM (both Erics are very busy these days )
But I am one of the beta testers and I wrote the Hubitat device driver. The VZM35 Blue Fan Switch does NOT have power monitoring, but it DOES have internal temperature monitoring.
Yes, we just confirmed this yesterday and are trying to figure out what the course of action is. Manufacturer’s aren’t just supposed to change the bill of materials without letting us know.
What they told us is that they swapped out the LED’s with better ones (at first I thought this was just them saying it, but upon testing, it’s actually a much better LED when comparing certain colors against each other) and also they are much more efficient from a heat perspective.
That said, they still need to tell us when they do things like this as it leads to issues like this.
The net of it is that the latest batch of Red 2-1’s, Blue 2-1’s and Fan switches all have the same LED’s in it – the original couple of batches of Blue 2-1’s have the different LED’s in them that don’t match the new batch.
What the manufacturer has offered to do is figure out if a firmware change can be accomplished or look for ways to tweak the settings (via intensity or color values) to get them as close as possible.
Yeah, this is the most noticeable one. At first, when I was alerted to the color change, I saw the blue and went, “yeah, ok, that does look different, but I’m sure it can be solved via tweaking a few things”, but then I changed it to white and dang… I must say the new white looks awesome though.
Yeah, this was brought to my attention too and I confirmed with the manufacturer that they did not change the diffuser, but it is weird that at certain angles you can see the LED’s.
I agree with this enhancement, really good idea!
We hadn’t even considered this to be honest. All the fan controls I’ve ever played with have had the hold to change speeds, so it never crossed my mind to include something like this.
But, you guys definitely aren’t the only ones who’ve asked for this feature (unless you both are blowing up the ticket system under different aliases lol jk) and I think it would be a fairly simple firmware upgrade.
Let me see if we can add this to a future firmware release! I’ll put it in GitHub right now
Thanks for the suggestion!
Good suggestion to put them in the manual. I’ve been revamping the Knowledge Base and trying to make it more user friendly, so I’ll add this to the scene control section or something.
Just confirming, although @mamber is correct – no power/temp monitoring in the switch – just an internal temperature monitor that is there to prevent overheating.
–
All, if I missed something, let me know – I’m just getting caught up!
In summary, Home Assistant (ZHA) is erroring trying to query the switch for “active power reports”, but as there is no power monitoring in this switch it is causing the rest of the device capability discovery to fail.
2023-10-23 13:40:34.917 WARNING (MainThread) [homeassistant.components.zha.core.cluster_handlers] [0x239C:1:0xfc31]: 'async_initialize' stage failed: 'active_power_reports'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/zha/core/helpers.py", line 338, in wrapper
return await func(cluster_handler, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/zha/core/cluster_handlers/__init__.py", line 380, in async_initialize
await self._get_attributes(
File "/usr/src/homeassistant/homeassistant/components/zha/core/cluster_handlers/__init__.py", line 491, in _get_attributes
read, _ = await self.cluster.read_attributes(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/zigpy/zcl/__init__.py", line 501, in read_attributes
attrid = self.attributes_by_name[attribute].id
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'active_power_reports'
Is it as simple as updating the ZHA quirk, or will fixing the issue require a firmware upgrade?
I’m going to have to defer to @EricM_Inovelli on this one. Is anyone else facing this out of curiosity? Sorry, haven’t monitored the forums as well as I should’ve so I’m genuinely asking.
I believe it’s going to end up being an HA update and not something that can be overridden by changing the quirk, but there’s an issue open with the ZHA github.
Does HA check every device for active_power_report? The current quark copies all of the attribute list that is queried from the VZM31SN cluster and then removes a couple of attributes such as active_power_report. Is that the correct way of handling this device? I would have expected the quirk to query the VZM35SN directly for it’s capabilities.
Sorry, I don’t mean to drag this discussion too deep technically. Happy to move this discussion to a better forum to discuss this issue, I just want to know the right place to track the resolution to this.
In this case I believe it’s checking both the 2-1 and fan switches since they both use the same Inovelli cluster ID and the HA code just references that ID. Re the copy/remove, that was done by me after talking to one of the main ZHA devs who recommended it be done that way. If you go to the device page and manage it through that UI, you’ll see all the options work there, just having the issue with the frontend piece.
Got it… in that case, how do we expose the LED settings HA then? I assumed that the power error was causing the query to fail of the LED settings, but maybe I was down a rabbit trail. haha
Thanks all, I really appreciate all of the hard work!
Ya, I am tracking that I can change the settings directly via the cluster commands, but I was hoping to have the drag slider like we have on the VZM31-SN.