I changed the device type to Generic Zigbee Bulb and it seems to work ok. However, I can't seem to share it with the ST hub via Hubconnect. (I'm moving devices over one at a time from ST to HE but still want them to be visible in ST so Alexa integration continues to work).
Is changing the device type the proper resolution? I don't think this is some obscure device (see link below); why wasn't it properly recognized? Tried to pair it twice with same results.
Try exposing it via HubConnect as a dimmer instead of a bulb. Since it's white-only, it's basically just a dimmer in a different form factor, and I think HubConnect looks for RGB- or CT-related capabilities for bulbs, which would explain why you won't see it there.
As for the the driver: if you're feeling extra nice, switch to the plain "Device" driver, the open up the "Logs" window. Hit the "Get Info" command/button, and copy and paste the entire fingerprint line here from the logs so staff can add it to the right driver. (I'd assume it's the one you chose, though I don't know if they've formally tested it as it's not on the "official" list; you may want to ensure all commands work as expected and all attributes/states get reported when changed.)
Tagging @mike.maxwell unless he's tested this bulb already and decided not to include it "officially" for some reason (I'm assuming you found it works as expected?).
Sorry, ran out of steam last night. Yes, it works correctly as a Generic Zigbee Bulb, and also as a Generic Zigbee Dimmer.
Since it's an "official" Samsung ST Device, I'd think there would be a bunch of them out there.
I sorted out the Hubconnect issue as well. but I'm confused on something.
In the Device Information section, there's a Device Name field whose initial value seems to be the name of the driver that was assigned to it at creation. There's also the Type field, which appears to be the actual driver that's used.
Changing the Type field has obvious effects on the device, whereas changing the Device Name doesn't. Hubconnect seems to use the Device Name field when deciding what remote driver is needed.
Is the Device Name field significant to HE or it is just an arbitrary string used for display purposes?
No, that's totally up to you. It's used to determine the display name of the device, which will use the device label if present, otherwise the device name (this is what you'll see in app inputs that ask you to choose devices, in the logs [eventually], and whatnot). Some people like to keep the device name as the driver or model and add a label (so they know what devices are what), while others don't care, but those are both user-editable as you please.
That's what I expected. Looks like HubConnect is using it (incorrectly) to determine what driver to use, rather than basing that on the driver specified by the Type attribute.
No, HubConnect is looking for devices based on the Capabilities specified in the driver (and that particular input in the app). I don't use it anymore and don't have the code around to check, but if you were looking for "bulbs," my guess is that it was looking for a color-related capability that a white-only bulb wouldn't have. I think I mentioned this before, but you'd want to look under "Dimmers" instead since the capabilities of a white-only bulb would more or less exactly match those of a dimmer, even if you wouldn't personally call it one.
Ok I tried to reproduce this to get the error log entry I saw earlier, and I was wrong.
The bulb shows up in two different categories in the HC UI, once under Bulb Devices and once under Dimmer Devices. Depending on which one I select (or I can choose both), that's apparently what HC uses to determine what driver is needed on the ST side.
In the ST log, it tried to create two ST devices for one HE device because I selected both instances in the HC UI.
I must have also edited the device's name at the same time I removed and re-added the bulb, and mistakenly thought it was the reason it worked the second time. The real reason is that I must have selected it from the dimmers category the second time.
Yeah, where you select it in the app determines what driver is needed on the "remote" side. You also can't select it more than once since it will try to create devices with the same device network ID (DNI), which neither Hubitat nor SmartThings allows, though removing one selection and choosing another (even if the device itself remains added--you just might need to manually change the driver) should be fine, if I remember. Anyway, glad you got it figured out!
Three times last week this bulb went AWOL. I don't think there's anything wrong with the bulb itself. The first two times I factory reset the bulb and paired it again. Thinking it may be some sort of interference, I reconfigured my wifi 2,4 channel as well as the HE zigbee channel to be at opposite ends of the spectrum (also checked neighboring wifi channel usage).
That didn't make any difference though. The third time the bulb stopped working, I tried rebooting the hub first, and I regained control of the bulb without having to reset/repair.
Then I changed the driver from Generic Zigbee Bulb to Dimmer, as that was how it was originally recognized by HE. No problems since.
Is it possible that there's a problem with the Generic Zigbee Bulb driver and this device? I'm willing to change the driver from dimmer back to bulb and capture whatever logs might be useful in case it starts failing again.
I don't know that the device fell off the network. I assumed as much the first two times when I reset/re-paired, but the third time I tried rebooting the hub and the problem cleared right away. If the device fell off the network, I assume that rebooting the bub would have no effect. Or would it?
Anything I should look for or try in an attempt to reproduce? Or just forget about it unless it happens again?
(I'd assume it's the one you chose, though I don't know if they've formally tested it as it's not on the "official" list; you may want to ensure all commands work as expected and all attributes/states get reported when changed.)
