Ii just checked my logs and saw some errors, but both the fan and light seem to be responding to commands. BAF put out a new firmware version since I worked with @mavrrick58 on the driver. Not sure if there were any Matter changes/updates. If these fans stay hooked up to my Unifi APs I will probably see if @mavrrick58 is interested in fixing the issues in the coming weeks.
I removed it. Re-added the device to have a fresh start. It installs with the govee matter driver. Changed it to the provided driver. Did an initialize, then a refresh.
dev:2032025-12-12 10:25:17.649 AMdebugdescMap:[endpoint:01, cluster:0006, attrId:0000, value:00, clusterInt:6, attrInt:0]
dev:2032025-12-12 10:25:17.647 AMdebugdescMap:read attr - endpoint: 01, cluster: 0006, attrId: 0000, value: 08
dev:2032025-12-12 10:25:17.641 AMdebugskipped:[endpoint:01, cluster:0003, attrId:0001, value:00, clusterInt:3, attrInt:1]
dev:2032025-12-12 10:25:17.639 AMdebugdescMap:[endpoint:01, cluster:0003, attrId:0001, value:00, clusterInt:3, attrInt:1]
dev:2032025-12-12 10:25:17.637 AMdebugdescMap:read attr - endpoint: 01, cluster: 0003, attrId: 0001, value: 0400
dev:2032025-12-12 10:25:17.631 AMdebugskipped:[endpoint:01, cluster:0003, attrId:0000, value:00, clusterInt:3, attrInt:0]
dev:2032025-12-12 10:25:17.629 AMdebugdescMap:[endpoint:01, cluster:0003, attrId:0000, value:00, clusterInt:3, attrInt:0]
dev:2032025-12-12 10:25:17.627 AMdebugdescMap:read attr - endpoint: 01, cluster: 0003, attrId: 0000, value: 0400
dev:2032025-12-12 10:25:17.217 AMdebugrefresh()
dev:2032025-12-12 10:23:49.047 AMerrorjava.lang.NullPointerException: Cannot invoke method forEach() on null object on line 747 (method initialize)
dev:2032025-12-12 10:23:48.334 AMerrorjava.lang.NullPointerException: Cannot get property 'state' on null object on line 86 (method parse)
dev:2032025-12-12 10:23:48.304 AMdebugdescMap:[endpoint:00, cluster:001D, attrId:0003, value:[01, 02], clusterInt:29, attrInt:3]
dev:2032025-12-12 10:23:48.286 AMdebugdescMap:read attr - endpoint: 00, cluster: 001D, attrId: 0003, value: 160401040218
dev:2032025-12-12 10:23:47.999 AMinfoinitialize...
In case images make it easier to read
I swear I seen endpoint 02 earlier in some of the logs (probably when I was using the "Matter Fan Driver"), but that may have been what it was trying to write to, not what it was capable of?
Use the HE built-in “Device” driver and click on the “Get Info” button. You should see all of the endpoints in the live logs.
it has a ct white light and a reversible dc fan
New BAF firmware out as of December 10, 3.3.7. No mention of any Matter changes. But some AP and connection improvements.
the remote has 6 speeds, but like the light I believe can be programmed anywhere between 0 and 100 through matter. It also has a "breeze" setting. I have 2 more of these that add an additional ct light to it that shines against the ceiling.
I see the error from the first batch of screen shots. I have fixed that on the repo. Honestly that single stream driver was in a way ignored once we started building on the extra features with the multi endpoint component drivers. It was mostly used to figure it out.
Your last screenshot does indicated there are two endpoints and that it is the second one that performs the fan functions based on the clusters listed.
Could probably just take the multiendpoint driver and adjust the endpoint assignment so the fan control and CT Light Control is on the correct endpoint.
So with the above info I made some quick changes to the BAF driver and posted it here
Matter_By_Mavrrick/Altitude Fan Matter at main · Mavrrick/Matter_By_Mavrrick
Basically I modified the fingerprint to install for your devices, updated the endpoint assigned to the Fan and Light device, removed the stuff around the temp and occupance sensor the BAF fan has. Download all there drivers and reinstall your device and let me know how it goes. Hopefully this just works.
We probably should break this out to it's own thread now that we have a driver specifically for these Altitude fans.
I'll try it and let you know.
I had posted here as well. It may be more suited.
@mavrrick58 I'm playing around with Claude and reviewing some drivers. Claude says that data types are not to Matter spec. But the drivers work OK with current data type. Is it correct and if so should it be changed even if the current type works?
BTW, I think the vast majority of my issues have been/are BAF/UniFi interaction issues. This fan just doesn't do WiFi/Matter well with Unifi. It's gotten better in the last few months with both UniFi and BAF firmware updates, but still not all that great.
What the Matter Spec Says:
According to Matter 1.3 spec, Fan Control Cluster (0x0202):
- 0x0002 (PercentSetting): uint8 nullable → Data type 0x05
- 0x0000 (FanMode): enum8 → Data type 0x20
- 0x000A (WindSetting): enum8 → Data type 0x20
- 0x000B (AirflowDirection): enum8 → Data type 0x20
What the Driver Uses:
- Everything uses 0x04 (which in Matter is typically
uint8)
Keep in mind there may be a layer of Hubitat code inbetween the driver and what gets sent to the device. It has been a good while since i have looked at it, but i do believe what i was providing worked.
My guess is Cloud doesn't understand the use of the Hubitat Matter specific methods and maybe that is causing some of the confusion.
Nope, as I said it seems to be working. I've just been noodling around with Claude to see what it has to say about various items in different drivers.
Taking a quick look at the driver i think you are referencing when the method
attributeWriteRequests is used. That is a hubitat method that builds the list of attributes to send to the device.
Here is a thread i kind of brought up this point already. In that thread you see the supported data types that we were provied to use for Hubitat. 0x20 is not present in that list.
Sorry for the goose chase. 0x04 is the correct type. Claude seems to have hallucinated about the data type spec.
More info incase ou are interested since you are looking it up.
I just went to the Matter Standards site and downloaded the Matter 1.5 Spec Docs. I figured i would review what is current in the spec so i made sure i was accurate.
Generally speaking a lot of those commands are built and sent with that attributeWriteRequest command it has few parts to it. So the formating is not completely clear. To review the fan options i reviewed the Attributes for the cluster. They are shown below
The fact that some of them are labeled as variations of enum/bitmap values is a little missleading. When you review the docs, the enum values do have a set value for them. For instance the Windsetting is what is used for the woosh option with the BAF. Here are the Enum values as explained in the doc.
The attribute needs the bit value passed to execute the setting. So when the attribute is submited. Looks like the BAF fan uses 2 so i would need to research how we came up with that, but.
So all that said 0x04 is right because of the type of data being passed as you found. That said i also see why Claude could of gotten confused. It is all over the docs that the values are enumerated or bitmaps or something else and not just a unassined integer 8 value. It just another good example why it is always good to double check these AI tools.
Looks like the info is deep in the specs. Need to look at the Core Spec TLV encoding. In 1.3 appendix A.7. Control Octet Encoding and it's in binary. Claude did help me find that.
Look at the "Matter Application Cluster Specification" document. It seems to have all of the details for what cluster is what and what Attributes they have, along with their potential values. That is the document i pulled the above information from.