Any reason why the advanced X ZigBee drivers can't respond to devices changes?

My understanding is ZigBee is a bi directional protocol? So when a ON is sent to the device the device turns on and responds saying I'm on? I assume this is the same for level, colour ect.

So if the above is correct how come the advanced driver do not support it?

I am curious what you are seeing in your logs. I tested with a Sengled RGBW using the Advanced Zigbee RGBW Bulb driver and it appears commands and confirmations are working. Then again, I may be misinterpreting what I see. The logs are for On, Off, Some shade of red, CT of 4000, and Off.

Yes you would see this, because the command came from Hubitat. I'm talking when the command comes from a ZigBee group or outside of Hubitat. That's harder to show but it doesn't get updated.

1 Like

Ahh, okay. Sorry.

The answer ?

1 Like

Zigbee group messaging command responses do not get sent back to the driver, that's just the way it works.
Our zigbee group messages are followed by a read attribute request for each attribute that was changed, these responses are sent back to all of our drivers for a given device.

The advanced drivers work differently than the other ones, the advanced drivers respond to the command response acknowledgment rather than changes to the cluster attributes that are usually configured with reporting configurations, this cuts down on traffic.
They do however process read attribute responses like those sent via group messaging.

How do you send a Zigbee message to a Zigbee device thats joined to Hubitat, from outside of Hubitat...

1 Like

Find and bind, its possible on ZigBee 3.0 devices. Its like touch link but still joined to a network. Both devices are joined then on a lamp for example (Innr) once you join it to the hub, you trigger direct learn mode on a scene plate (in this example RGBgenie controller ZB-3009/10) and it will bind the two. So then you have direct control from the plate but also hub control. The disadvantage is the lamp state is lost although you can use the state of the child device for the scene plate as the state.

you need to use the generic drivers for this configuration.

I have a feeling there is issue with that aswell, I'll check it out next time I'm at my inlaws.

Sorry @mike.maxwell , only just got back to their place. I have changed it to generic, hit configuration and there is no difference. If I hit refresh it will work but other than that it doesn't push a updated to the hub?

what device is this?

It's a innr ZigBee 3.0 RGBW lamp "bulb"

Just to be clear we are doing things outside of HE.

so you were expecting the device to report back to the hub when its touch linked to another device?
I'm not sure this is going to work.

We didn't know if it would, you just suggested to try the generic.

I was hoping the device pushed the changes? Or is the coms only one way and when you send a event from the driver you follow it with a refresh?

That's what devices normally do when joined and bound to the hub.

So you think I would have to make it join as the general driver? Configure won't do it?

The device isnt reporting to the hub when its touch linked nothing we can do about it

1 Like

No, it's joined to the hub and joined directly to the device. Both devices are joined to the hub then on the scene plate you have from sunricher you then quickly put it in find and bind mode, as long as you do that within a few mins of joining the lamp to the hub it will bind.

So it reports to the hub and controlled from the hub, it just reacts instantaneous from the colour wheel of the scene plate and scenes.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.