The quad switch does not dim. There is a 1-gang dimmer switch available in the range. I haven’t seen any Zigbee or Zwave dimmer yet that is 2-gang or bigger. But then again, I haven’t looked too hard either.
1 Like
For heat / safety reasons I don't think you will find any approved dimmers in Australia, smart or otherwise that are not single gang only.
2 Likes
I just installed two of the fan/light switch on the wall. Let me know how you go with a driver and if you want me to test anything. I don't have the skills to write a driver myself.
Almost completed... hopefully tomorrow I'll have something up on GitHub
1 Like
Ikuu SMFL20W-ZB Floodlight
- endpointId: 01
- application: 52
- softwareBuild:
- inClusters: 0000,0003,0004,0005,0006,1000,0008,0300
- outClusters: 0019,000A
- model: TS0501B
- manufacturer: _TZ3000_juq7i1fr
Driver: Generic Zigbee Bulb also working for this
Driver for the Fan/light switch is completed. Make sure you hit Configure to install the needed child devices.
4 Likes
You sir, are a good man.
Works a charm.
Thanks! 
nice work!
As an update, the Zigbee Double GPO 'works' with the Generic Zigbee Multipoint driver, but seems to chew a lot of processing time so I think its going to need its own driver...
yeah we now have a good range of ZB products. FINALLY!!
Now we just have to get the drivers/compatibility sorted.
work in progress...i hope to have an update for the community shortly on that front.
2 Likes
hi all,
i met with mercator recently, and had a very frank, open and productive conversation regarding their product line.
i'll put together a post shortly detailing the key points, but for now, those who are generously helping out with driver development, please be aware (particularly @gslender and @richard1 who put their hands up early) that i am coordinating with @mike.maxwell to test and include a built-in driver for the entire range of Ikuu ZB3.0 devices.
i think this will save a lot of time for everyone, and we will have a full range of consistent, supported drivers to support the AUS HE community moving forward.
5 Likes
I don’t mean this as criticism, but I’ve not found the built in drivers to be always 100% helpful for all situations and the closed source approach means we can’t adjust or modify the behaviour to suit differing needs. So I’ll probably continue to build drivers for the devices I’m using and make them available. I don’t believe closed source works when you’re relying on third parties to jointly agree with your objectives and goals. But totally happy to be proven wrong.
4 Likes
That does sound pretty useful, at least for many of the items. The standard drivers work pretty much perfectly for the 70mm and 92mm RGBW downlights as well as the motion sensors and so on, so adding the signatures of their devices should solve the problem there.
In fact the only device that has not functioned correctly so far has been the GPO that I got first, which I am still working slowly (not had much time) on getting power metering to work with both switches and correct child devices.
I do agree with @gslender that the closed source drivers are frustrating. Much of the difficulty we have with writing drivers could be completely avoided if we had access to a decent library with documentation or a rich code library from the OOB drivers.
I will be taking delivery of in-wall dimmers, fan controller, Zigbee bulbs, LED strip and push-button mechanisms over the next week or so (once Lighting Superstore ships at least).
all good - of course if you want to make your own drivers, happy days.
if any community driver provides a benefit over the built-in ones - and they're stable - i would (and do) absolutely use them.
that said, there's a lot of products in the lineup that you/richard and other capable generous guys may not bother writing drivers for, that others (including myself) will want to use, then this fills that gap.
plus, there are non-tech / beginner users that don't want/need anything other than to use stuff out of the box without having to worry about custom drivers and scary stuff like that. this helps them.
and of course there's support - if things go awry, its always good to know theres more robust support from HE for the built-in drivers.
last point i'd agree with you on - as well as @richard1 - is that i would absolutely prefer the built-in drivers to be open. but seeing as thats not my call - and writing drivers is too difficult/time consuming for me - i'm working to get the best outcome for me (and everyone) so thought this was a good idea...
1 Like
actually on the topic of the GPO, have you looked at your Zigbee logs? since adding it to my mesh it just non-stop messages like crazy, even when i change to the "Device" device driver, and clear all configs/states/child devices etc.
on the surface it "worked" in terms of outlet on/off (with the exception of power metering), but this thing is spamming my mesh big-time. do you see the same thing?
It is debatable about whether the community gets reduced/better support when source is closed or open... so I can't agree that OOB drivers = better support
I'm going to reach out to the PM from Mercator/Ikuu and let them know my vote would be the that they simply disclose some further technical details around the ZB protocol that each device supports, and let the market self-regulate. If the HE team build awesome/complete drivers then great, if not then the community can fill that gap. It also means that other markets (like SmartThings, HA etc ) can now benefit and build on that knowledge too. What's wrong with that approach??
hi there..bit confused here...that IS what i'm looking to achieve.
i am coordinating/enabling the bit before the comma.
to be clear, i'm not suggesting you and others shouldn't continue to build your driver(s), or indeed that i wouldn't use them if it makes sense to.
i would encourage that, actually. its a large part of what attracts me to this platform and this community 
1 Like
Hmm, I thought that it was just because I had not configured reporting correctly. With debug and trace logging on, I see 1-2 messages per second from the device.
raw: A5E3010B040A0805210000, dni: A5E3, endpoint: 01, cluster: 0B04, size: 0A, attrId: 0508, encoding: 21, command: 0A, value: 0000
Is this the sort of thing that you are seeing? I have mine on my newer C7 hub while I do some planning for migration from the old C4 so I am not seeing any major problems.
In your conversations with Mercator, had you any luck getting technical documentation out of them?
@gslender & @sanewton72 - yeehaa !
Guys, this is definitely a "Best of both worlds" approach.
- Factory, Hubitat drivers (Locked down + factory supported)
AND - Community Drivers (Open/Editable + community supported)
in terms of technical documentation, they are wanting to keep their IP close to their chest in that regard, but have basically said that during development they were very careful to maintain full ZB3.0 compliance. So conversations around compatibility and interoperability basically boiled down to: its compliant, it should pair with no issues, and from that point on its platform-specific but the device will support all the specified mandatory services/message types.
in terms of what I'm seeing, i'm on a C5, yea i'm probably getting around 2 per second, like so:
IkuuDGPOUSB2021-06-21 16:07:56.837 profileId:0x104, clusterId:0xb04, sourceEndpoint:1, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-67
IkuuDGPOUSB2021-06-21 16:07:56.326 profileId:0x104, clusterId:0xb04, sourceEndpoint:1, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-67
as mentioned, to try to confirm if the driver is causing this behaviour, i tried a number of different drivers - even the "Device" one, but the messages just keep hammering in. Maybe this product needs some initialisation message of some kind, and it just does a Zigbee Kath&Kim (LookAtMeLookAtMeLookAtMe) until it gets it?
