Which bulb did you get? Just wondering if the product specs for it says that it is Zigbee 3.0 compliant.
Classic Colour Globe (B22) x 1
GU10 Colour Globe x 1
GU10 Globe x 1
Quad Switch x 1
All packaging says Zigbee 3.0 compliant
Confusingly, I got this reply after I asked why ZB3.0 marked devices don’t work with hubs and got this reply…
So should that mean they should be backward compatible and should connect?
I will try the GU10 bulbs this weekend and see if I have any luck with them being discovered.
So a dummies question here...how can I tell if a device that has joined is my bulb, or one of my other zigbee devices that I hadn't joined?
Bear with me here - and be kind 
Yesterday when this device was found, hubitat informed me that it was a Xiomi zigbee device. I didn't think that was correct as non of my xiomi devices were in pairing mode. I tried setting a generic zigbee bulb driver, but after selecting configure, not information in the relevant section was populated. I tried resetting the bulb (on/off 3 times) several times and it wasn't playing nice. Tried again just now, and found it as a previously joined device. If I haven't put anything else in pairing mode, how certain can I be that this is actually the ikuu bulb?
Suggestions on what to do. Happy to test.
https://docs.hubitat.com/index.php?title=Device_Detail
Get to this page and post the screenshot
The device fingerprint should be the key thing that uniquely identifies the bulb
Wasn't exactly what I was hoping for... odd that it hasn't reported its fingerprint, but maybe we need to dig a bit deeper.
This is what I'd do...
Install this custom driver
https://raw.githubusercontent.com/markus-li/Hubitat/development/drivers/expanded/zigbee-generic-device-toolbox-expanded.groovy
Then change the driver for the device to that custom driver "Zigbee - Generic Device Toolbox"
Next enable debugs and open the Logs window on another tab so you can switch between them.
Next press the Get Info button on the Device Config page and then post back the results from the Log screen that corresponds with that Get Info button being pressed
I get this result from one of my devices in the log...
dev:2192021-05-07 11:41:55.941 am infoCOPY AND PASTE THIS ROW TO THE DEVELOPER: fingerprint model:"LXN56-1S27LX1.2", manufacturer:"3A Smart Home DE", profileId:"0104", endpointId:"01", inClusters:"0000,0003,0004,0005,0006,0008,1000", outClusters:"1000", application:"00"
dev:2192021-05-07 11:41:55.935 am traceApplication: 00
dev:2192021-05-07 11:41:55.931 am traceModel: LXN56-1S27LX1.2
dev:2192021-05-07 11:41:55.926 am traceManufacturer: 3A Smart Home DE
dev:2192021-05-07 11:41:55.903 am debugGetting info for Zigbee device...
dev:10982021-05-07 12:15:04.936 pm infoINCOMPLETE - DO NOT SUBMIT THIS - TRY AGAIN: fingerprint model:"null", manufacturer:"null", profileId:"A1E0", endpointId:"F2", inClusters:"", outClusters:"0021", application:"52"
dev:10982021-05-07 12:15:04.934 pm traceApplication: 52
dev:10982021-05-07 12:15:04.929 pm traceModel: null
dev:10982021-05-07 12:15:04.926 pm traceManufacturer: null
dev:10982021-05-07 12:15:04.922 pm warnManufacturer name is missing for the fingerprint. Try again.
dev:10982021-05-07 12:15:04.918 pm debugGetting info for Zigbee device...
dev:10982021-05-07 12:15:04.898 pm debugd=[nwkAddrOfInterest:C640, endpointId:F2, profileId:A1E0, applicationDevice:0061, applicationVersion:00, inClusters:, outClusters:0021], ll=10, icn=0, ocn=1
dev:10982021-05-07 12:15:04.869 pm traceSimple Descriptor Information Received - description:catchall: 0000 8004 00 00 0040 00 C640 00 00 0000 00 00 5D0040C60AF2E0A161000000012100 | parseMap:[raw:catchall: 0000 8004 00 00 0040 00 C640 00 00 0000 00 00 5D0040C60AF2E0A161000000012100, profileId:0000, clusterId:8004, clusterInt:32772, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:C640, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[5D, 00, 40, C6, 0A, F2, E0, A1, 61, 00, 00, 00, 01, 21, 00]]
dev:10982021-05-07 12:15:04.833 pm infoUnhandled Event IGNORE THIS - description:catchall: A1E0 0000 F2 01 0040 00 C640 00 00 0000 01 01 040086 | msgMap:[raw:catchall: A1E0 0000 F2 01 0040 00 C640 00 00 0000 01 01 040086, profileId:A1E0, clusterId:0000, clusterInt:0, sourceEndpoint:F2, destinationEndpoint:01, options:0040, messageType:00, dni:C640, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:01, data:[04, 00, 86]]
dev:10982021-05-07 12:15:04.785 pm infoINCOMPLETE - DO NOT SUBMIT THIS - TRY AGAIN: fingerprint model:"null", manufacturer:"null", profileId:"0104", endpointId:"F2", inClusters:"null", outClusters:"null", application:"52"
dev:10982021-05-07 12:15:04.778 pm debugsendZigbeeCommands(cmd=[he raw C640 0 0 0x0004 {00 40C6 F2} {0x0000}])
dev:10982021-05-07 12:15:04.776 pm warnOne or multiple pieces of data needed for the fingerprint is missing, requesting it from the device. If it is a sleepy device you may have to wake it up and run this command again. Run this command again to get the new fingerprint.
dev:10982021-05-07 12:15:04.773 pm traceApplication: 52
dev:10982021-05-07 12:15:04.771 pm traceModel: null
dev:10982021-05-07 12:15:04.763 pm traceManufacturer: null
dev:10982021-05-07 12:15:04.759 pm debugsendZigbeeCommands(cmd=[he raw 0xC640 1 0xF2 0x0000 {10 00 00 04 00}, delay 2000])
dev:10982021-05-07 12:15:04.753 pm warnManufacturer name is missing for the fingerprint, requesting it from the device. If it is a sleepy device you may have to wake it up and run this command again. Run this command again to get the new fingerprint.
dev:10982021-05-07 12:15:04.749 pm debugGetting info for Zigbee device...
dev:10982021-05-07 12:14:57.548 pm traceApplication ID Received
--- Live Log Started, waiting for events ---
I'm not an expert on all things Zigbee, but it looks as though the device is not reporting everything it should correctly - so it will require someone with skills in writing drivers and/or access to the device to nut it out. We may never get it working if we can't uncover what specifically the device needs to function - something that only Mercator may only know.
I'll go back to Mercator and ask if they can support me if I buy one to build a driver for it - obviously if they're unwilling to help, then it could be impossible, but maybe a more experienced HE developer might chime in with some other options.
I've sent off an email to their Product Manager (Felicity) and hopefully she'll be able to assist with more details and/or advice. If I can, I'll write the drivers for the devices, but will depend on what they come back with.
1 Like
@saxnix can you try the same test (logging the get info results) against another device and any chance you can jerry-rig the 4-gang switch to see what it does too ??
1 Like
Thanks for your input and follow up. I won't touch the switch at this stage, but I will also try one of the GU10 bulbs and see how I go with that. With running the test on another device, do you mean an ikuu device - or any device?
Another Ikuu device.
The product mgr was specific about saying "if the device is ZB3.0 compatible then it will work with other hubs"... so perhaps they have a range of ZB products that they know are not ZB3.0 compatible, and who knows, maybe the bulb you tried was incorrectly marketed as being ZB3.0 when it isn't... they probably have different chipsets, firmware and boards... so wouldn't be too surprising to have inconsistencies in the way their Ikuu products work
OK, so I just installed the GU10 bulb, started discovery on the hub and turned the light switch on. It pulsed a couple of times then stopped and at the same time appeared in the Found Devices section. Like the other bulb, the hub thinks it is a Xiaomi/Aqara Motion Sensor.
Saved it, changed the driver to the toolbox, turned on logging, selected Get Info, here are the logs;
dev:10992021-05-07 01:41:48.081 pm infoUnhandled Event IGNORE THIS - description:catchall: A1E0 0000 F2 01 0040 00 BD1C 00 00 0000 01 01 040086 | msgMap:[raw:catchall: A1E0 0000 F2 01 0040 00 BD1C 00 00 0000 01 01 040086, profileId:A1E0, clusterId:0000, clusterInt:0, sourceEndpoint:F2, destinationEndpoint:01, options:0040, messageType:00, dni:BD1C, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:01, data:[04, 00, 86]]
dev:10992021-05-07 01:41:48.003 pm infoINCOMPLETE - DO NOT SUBMIT THIS - TRY AGAIN: fingerprint model:"null", manufacturer:"null", profileId:"A1E0", endpointId:"F2", inClusters:"", outClusters:"0021", application:"52"
dev:10992021-05-07 01:41:48.000 pm traceApplication: 52
dev:10992021-05-07 01:41:47.998 pm traceModel: null
dev:10992021-05-07 01:41:47.996 pm traceManufacturer: null
dev:10992021-05-07 01:41:47.993 pm warnManufacturer name is missing for the fingerprint, requesting it from the device. If it is a sleepy device you may have to wake it up and run this command again. Run this command again to get the new fingerprint.
dev:10992021-05-07 01:41:47.991 pm debugGetting info for Zigbee device...
Device Info & Details
OK, so I deleted the Xiaomi driver, removed the device, and repaired it.
Saved it as Generic Zigbee Bulb, and it seems to be working.
I'll try the original bulb again and report back
Yep, the original bulb is working with;
Generic Zigbee Bulb driver. Basic on off, set level.
Advanced Zigbee RGBW Bulb driver - seems to have full functionality.
Generic Zigbee RGBW Light driver - seems to have full functionality.
Checked the GU10 Colour Globe and it too is working now.
OK, I feel like now I can book a sparky for next week to try out the quad light switch
1 Like
So now that I have completely filled this thread with incorrect infomation, should I go back through and delete all the no-relevant posts, and just add a post stating that if you have the Oh-La Labs Xiaomi/Aquara Motion Sensor driver installed, that you may need to remove it before adding this brand?
2 Likes
