Zigbee supporting Esp32 module with Arduino

I still don't understand. The "zigbee rgbw bulb" code example has setColor function but it is not called in the code (not triggered any ways)
If this code is a working code, how does the setColor get triggered.

On Arduino side , currently only RGB based color setting is available. So to get the light to the correct color, Hubitat has to send a zigbee command with R,G,B parameters.
Is this available in the "zigbee rgbw bulb" code ?
if not, how can I add it ?

The ZigBee standard for color control (cluster 0x0300) only allows for HSV

then Arduino is not using that cluster.

anybody who could help about occupancy sensor question above ?
AND/OR
the possibility of 2 Endpoints in 1 zigbee device ?

The setColor code is triggered when someone goes to the device's page and uses the setColor command shown there, or when some other app or Hubitat function (such as a dashboard option allowing you to set a color, or a Rule) calls it. Here is a portion of what a ZigBee RGBW Bulb looks like on the device page:
SetColor

Besides the setColor (the new UI makes it look like Set Color) you can also see the setColorTemperature, on, off, refresh, and configure commands. Those have to have code for them in the driver, because the driver has capabilities that require them ("Color Temperature", "Switch", "Refresh", and "Configuration" respectively). If you add a capability to a driver you need to have code to support the command(s) a capability requires, otherwise it will get an error if someone selects one. If you write your own drivers, you can add additional commands. But capabilities are built-in things that other Hubitat systems can recognize. Since this has "Switch" everything knows that it can act as a switch. If I wrote a driver with on/off commands, it would have them on the page... but other features would not know about them without the "Switch" capability.

EDIT:
Looking at the portion of Arduino code I found above that references RGB LEDs, that same code also has portions for multiple methods (including HSV). In the end, it IS telling the LED strip RGB (I assume using whatever code is imported from the led_strip.h file) because pretty much all LED strip hardware runs using RGB. But that is not associated with the ZigBee portion of it. It looks to me like this portion is just for the LED strips (as it would do nothing on it's own), and other code is what is converting it for when it uses the ZigBee portion.

1 Like

Can you make a screenshot of the fingerpeints as reported in Hubitat when the device is paired for a first time? You will need to delete it from HE and pair once again. The detailed endpoints report is available only at that time - click on the 'device info' (or similarly named) hyperlink before you assign the new device a name and save it.

1 Like

it is now being detected as "Tuya Multi Sensor 4 In 1"
and logs:>

2025-02-09 12:10:26.045debugTuya Multi Sensor 4 In 1 zigbee default command response cluster: Power Configuration (0x0001) cluster command: 0x00 status: FAILURE (0xC3)
dev:14722025-02-09 12:10:25.933debugTuya Multi Sensor 4 In 1 parse (Espressif, 1.3.5 2023/05/28 10:34 PM) descMap = [raw:catchall: 0104 0001 0A 01 0040 00 72DA 00 00 0000 0B 01 00C3, profileId:0104, clusterId:0001, clusterInt:1, sourceEndpoint:0A, destinationEndpoint:01, options:0040, messageType:00, dni:72DA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[00, C3]]
dev:14722025-02-09 12:10:25.749debugTuya Multi Sensor 4 In 1 zigbee default command response cluster: Power Configuration (0x0001) cluster command: 0x00 status: FAILURE (0xC3)
dev:14722025-02-09 12:10:25.721debugTuya Multi Sensor 4 In 1 parse (Espressif, 1.3.5 2023/05/28 10:34 PM) descMap = [raw:catchall: 0104 0001 0A 01 0040 00 72DA 00 00 0000 0B 01 00C3, profileId:0104, clusterId:0001, clusterInt:1, sourceEndpoint:0A, destinationEndpoint:01, options:0040, messageType:00, dni:72DA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[00, C3]]
dev:14722025-02-09 12:10:25.525infoTuya Multi Sensor 4 In 1 reported Power source unknown (00)
dev:14722025-02-09 12:10:25.522debugTuya Multi Sensor 4 In 1 parse (Espressif, 1.3.5 2023/05/28 10:34 PM) descMap = [raw:72DA0A00000A07003000, dni:72DA, endpoint:0A, cluster:0000, size:0A, attrId:0007, encoding:30, command:01, value:00, clusterInt:0, attrInt:7]
dev:14722025-02-09 12:10:25.451debugTuya Multi Sensor 4 In 1 sendZigbeeCommands (cmd=[he raw 0x72DA 1 0x0A 0x0000 {10 00 00 07 00}, delay 200, he raw 0x72DA 1 0x0A 0x0001 {10 00 00 20 00}, delay 200, he raw 0x72DA 1 0x0A 0x0001 {10 00 00 21 00}, delay 200])
dev:14722025-02-09 12:10:25.442infoTuya Multi Sensor 4 In 1 refresh()...
dev:14722025-02-09 12:10:24.407infoTuya Multi Sensor 4 In 1 Initialization finished
version=1.3.5 (Timestamp: 2023/05/28 10:34 PM)
dev:14722025-02-09 12:10:24.405infoTuya Multi Sensor 4 In 1 manufacturer = Espressif
dev:14722025-02-09 12:10:22.811infoTuya Multi Sensor 4 In 1 Received bind response, data=[61, 00] (Sequence Number:61, Status: Success)
dev:14722025-02-09 12:10:22.807debugTuya Multi Sensor 4 In 1 parse (Espressif, 1.3.5 2023/05/28 10:34 PM) descMap = [raw:catchall: 0000 8021 00 00 0040 00 72DA 00 00 0000 00 00 6100, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:72DA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[61, 00]]
dev:14722025-02-09 12:10:22.510infoTuya Multi Sensor 4 In 1 Received bind response, data=[60, 00] (Sequence Number:60, Status: Success)
dev:14722025-02-09 12:10:22.506debugTuya Multi Sensor 4 In 1 parse (Espressif, 1.3.5 2023/05/28 10:34 PM) descMap = [raw:catchall: 0000 8021 00 00 0040 00 72DA 00 00 0000 00 00 6000, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:72DA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[60, 00]]
dev:14722025-02-09 12:10:22.471infoTuya Multi Sensor 4 In 1 Received bind response, data=[5F, 00] (Sequence Number:5F, Status: Success)
dev:14722025-02-09 12:10:22.454debugTuya Multi Sensor 4 In 1 parse (Espressif, 1.3.5 2023/05/28 10:34 PM) descMap = [raw:catchall: 0000 8021 00 00 0040 00 72DA 00 00 0000 00 00 5F00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:72DA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[5F, 00]]
dev:14722025-02-09 12:10:22.444infoTuya Multi Sensor 4 In 1 preferencies updates are sent to the device...
dev:14722025-02-09 12:10:22.440debugTuya Multi Sensor 4 In 1 sendZigbeeCommands (cmd=)
dev:14722025-02-09 12:10:22.439debugTuya Multi Sensor 4 In 1 sending the changed AdvancedOptions
dev:14722025-02-09 12:10:22.435debugTuya Multi Sensor 4 In 1 forcedProfile is not set
dev:14722025-02-09 12:10:22.433infoTuya Multi Sensor 4 In 1 Debug logging is will be turned off after 24 hours
dev:14722025-02-09 12:10:22.392infoTuya Multi Sensor 4 In 1 Debug logging is true; Description text logging is true
dev:14722025-02-09 12:10:22.390infoTuya Multi Sensor 4 In 1 Updating null (Tuya Multi Sensor 4 In 1) model ZigbeeOccupancyPIRSensor manufacturer Espressif deviceProfile=null
dev:14722025-02-09 12:10:22.380infoTuya Multi Sensor 4 In 1 updated()...
dev:14722025-02-09 12:10:22.305infoTuya Multi Sensor 4 In 1 Received bind response, data=[5E, 00] (Sequence Number:5E, Status: Success)
dev:14722025-02-09 12:10:22.301debugTuya Multi Sensor 4 In 1 parse (Espressif, 1.3.5 2023/05/28 10:34 PM) descMap = [raw:catchall: 0000 8021 00 00 0040 00 72DA 00 00 0000 00 00 5E00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:72DA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[5E, 00]]
dev:14722025-02-09 12:10:22.252infoTuya Multi Sensor 4 In 1 Received bind response, data=[5D, 00] (Sequence Number:5D, Status: Success)
dev:14722025-02-09 12:10:22.247debugTuya Multi Sensor 4 In 1 parse (Espressif, 1.3.5 2023/05/28 10:34 PM) descMap = [raw:catchall: 0000 8021 00 00 0040 00 72DA 00 00 0000 00 00 5D00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:72DA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[5D, 00]]
dev:14722025-02-09 12:10:22.057infoTuya Multi Sensor 4 In 1 Received bind response, data=[5A, 00] (Sequence Number:5A, Status: Success)
dev:14722025-02-09 12:10:22.048debugTuya Multi Sensor 4 In 1 parse (Espressif, 1.3.5 2023/05/28 10:34 PM) descMap = [raw:catchall: 0000 8021 00 00 0040 00 72DA 00 00 0000 00 00 5A00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:72DA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[5A, 00]]
dev:14722025-02-09 12:10:21.986debugTuya Multi Sensor 4 In 1 write attribute response is FAILURE
dev:14722025-02-09 12:10:21.982debugTuya Multi Sensor 4 In 1 parse (Espressif, 1.3.5 2023/05/28 10:34 PM) descMap = [raw:catchall: 0104 0000 0A 01 0040 00 72DA 00 00 0000 04 01 86DEFF, profileId:0104, clusterId:0000, clusterInt:0, sourceEndpoint:0A, destinationEndpoint:01, options:0040, messageType:00, dni:72DA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:04, direction:01, data:[86, DE, FF]]
dev:14722025-02-09 12:10:21.707infoTuya Multi Sensor 4 In 1 received device manufacturer Espressif
dev:14722025-02-09 12:10:21.702debugTuya Multi Sensor 4 In 1 parse (Espressif, 1.3.5 2023/05/28 10:34 PM) descMap = [raw:72DA0A00007604004209457370726573736966000000200801008605000042185A69676265654F63637570616E637950495253656E736F720700003000FEFF86, dni:72DA, endpoint:0A, cluster:0000, size:76, attrId:0004, encoding:42, command:01, value:Espressif, clusterInt:0, attrInt:4, additionalAttrs:[[value:08, encoding:20, attrId:0000, consumedBytes:4, attrInt:0], [status:86, attrId:0001, attrInt:1], [value:ZigbeeOccupancyPIRSensor, encoding:42, attrId:0005, consumedBytes:27, attrInt:5]]]
dev:14722025-02-09 12:10:21.647debugTuya Multi Sensor 4 In 1 write attribute response is FAILURE
dev:14722025-02-09 12:10:21.642debugTuya Multi Sensor 4 In 1 parse (Espressif, 1.3.5 2023/05/28 10:34 PM) descMap = [raw:catchall: 0104 0000 0A 01 0040 00 72DA 00 00 0000 04 01 86DEFF, profileId:0104, clusterId:0000, clusterInt:0, sourceEndpoint:0A, destinationEndpoint:01, options:0040, messageType:00, dni:72DA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:04, direction:01, data:[86, DE, FF]]
dev:14722025-02-09 12:10:21.574debugTuya Multi Sensor 4 In 1 sendZigbeeCommands (cmd=[he raw 0x72DA 1 0x0A 0x0000 {10 00 00 04 00 00 00 01 00 05 00 07 00 FE FF}, delay 200, he wattr 0x72DA 0x0A 0x0000 0xFFDE 0x20 {13} {}, delay 200, delay 200, zdo bind 0x72DA 0x02 0x01 0x0402 {404CCAFFFE430090} {}, delay 200, zdo bind 0x72DA 0x02 0x01 0x0405 {404CCAFFFE430090} {}, delay 200, zdo bind 0x72DA 0x03 0x01 0x0400 {404CCAFFFE430090} {}])
dev:14722025-02-09 12:10:21.517infoTuya Multi Sensor 4 In 1 configure()..
dev:14722025-02-09 12:10:21.509infoTuya Multi Sensor 4 In 1 received device manufacturer Espressif
dev:14722025-02-09 12:10:21.503debugTuya Multi Sensor 4 In 1 parse (Espressif, 1.3.5 2023/05/28 10:34 PM) descMap = [raw:72DA0A00007604004209457370726573736966000000200801008605000042185A69676265654F63637570616E637950495253656E736F720700003000FEFF86, dni:72DA, endpoint:0A, cluster:0000, size:76, attrId:0004, encoding:42, command:01, value:Espressif, clusterInt:0, attrInt:4, additionalAttrs:[[value:08, encoding:20, attrId:0000, consumedBytes:4, attrInt:0], [status:86, attrId:0001, attrInt:1], [value:ZigbeeOccupancyPIRSensor, encoding:42, attrId:0005, consumedBytes:27, attrInt:5]]]
dev:14722025-02-09 12:10:21.483infoTuya Multi Sensor 4 In 1 is present
dev:14722025-02-09 12:10:20.874infoTuya Multi Sensor 4 In 1 Initialize( fullInit = true )...
dev:14722025-02-09 12:10:20.867infoTuya Multi Sensor 4 In 1 installed()...

@snell

I am really confused.
I don't understand what I should do to make Hubitat send zigbee color change command to the Arduino device so that the device gets RGB values to process.
I assume , zigbee color cluster has different modes and for the RGB we should use a different command to make the remote device (Zigbee ED) understand that the parameters received are R,G,B and then process accordingly.
On the Arduino sketch there is the following statement:
zbColorLight.onLightChange(setRGBLight);
and it goes to this function:

void setRGBLight(bool state, uint8_t red, uint8_t green, uint8_t blue, uint8_t level) {
  if (!state) {
    rgbLedWrite(led, 0, 0, 0);
    return;
  }
  float brightness = (float)level / 255;
  rgbLedWrite(led, red * brightness, green * brightness, blue * brightness);
}

But if I send the setColor command from Hubitat's drivers they are not triggering that portion of the Arduino sketch. Probablty because the sent command (from Hubitat) is using HSL cluster and not RGB.
How can I make the driver use RGB cluster ?

You cannot. The RGBW drive is built-in and working the way the ZigBee standard says it should. The only option (I see) is to change the Arduino-code side to correctly accept the ZigBee color cluster and then convert it itself to the RGB the LEDs use. It looks like that code is there, the Arduino code has conversion routines for it based on the sample posted that I was referring to.

But something is "broken" in it somewhere. If it is correctly receiving the ZigBee command and recognizing the color cluster data, it SHOULD have been programmed to convert that to the values it needs for the rest of the process. It does not sound like that portion is working correctly.

Are you using their most recent .ino examples? I was just looking over this one here:

But it also includes the Zigbee.h which is really just a catch-all for a TON of other includes... one of which is the #include "ep/ZigbeeColorDimmableLight.h"... Throughout these it has multiple mentions of converting color data. I tried digging around in it, but there is a lot of layering of includes/code and not much in the way of comments.

I am not sure that this is correct. ZigBee standard has multiple ways of setting color. Hubitat is using HSL. In fact it could also use RGB but there is no driver that uses RGB at the moment. If we could get in touch with a Hubitat developer they could help about this.

On the other side, Arduino Zigbee development is not mature yet. I am in communication with a developer from Espressif and he already made some changes that helped me a lot to make esp32-c6 work with Hubitat.
About color, he told me that he had just wrote the Endpoint routines for HSL and that RGB is in his todo. Eventually he will develop RGB endpoint and I'll be able to use. But while waiting for him, I am just looking for a quick & dirty way on Hubitat side.

converting from HSL to RGB or the other way is not a big problem. We can do it at any side. The problem here is that Hubitat and Arduino is using different color models. And one is not accepted on the other side.

it is not broken. Just it is programmed with a different cluster and HSL command sent by Hubitat is not being received by an Arduino endpoint which is programmed to catch RGB command.

@kkossev
Unfortunately I could not get the screenshot that you asked for. The device is being recognized as "Tuya Multi Sensor 4 In " as I posted above and it does not provide the details you asked for. Is there a way to force it ?

ZigBee color cluster indicates it works in XY values. It optionally allows for hue and saturation based on RBG & W. It does not natively support RGB. Per the specification I dug up, the color cluster section starts on page 324.

The code espressif has in their examples does appear to use that XY method. The main sketch refers to RGB. But below that, in the included ZigBee code is where it handles converting it to how the ZigBee standard requires. That is where I think there must be a flaw somewhere, because you say it is not working properly. The Hubitat driver is sending the ZigBee color control data (it works on numerous other devices). Something on the receiving (ESP32C6) side is not processing it properly to send to the RGB LEDs... otherwise they should work, correct?

1 Like

well, prior to checking the specification, I was thinking that HSL and RGB are supported in parallel. And that Arduino/Espressif side decided to support RGB primarily.
AND that support of HSL is not required as RGB is already there.
Because in fact defining a color in RGB is easier for a programmer/developer.
And seeing "only HSL" support on Hubitat is a disappointment for me.

Arduino sketch on an ESP32-C6 works fine on Home Assistant with a Zigbee dongle.
That means HA is supporting RGB setting of color.

But as you note , the specification primarily supports HSL. That's really interesting.
I'll ask this to the Espressif developer.

1 Like

If you want to play with low-level Zigbee functions, you can take a look at [DEV] Knockturn Alley.

This is the first thing I use when I start writing a driver for a new device. I find the generated report very helpful for learning what capabilities are exposed by the device.

RGB works much better for me personally also... I have been using computers for a long time... and I have always worked in RGB for color. So the first time I was doing something with ZigBee color control I was like "huh?!". Now, that project failed MISERABLY but it was not Hubitat's fault (the company's product I was writing a driver for... well, let's just say they had "inaccuracies" in their spec and brochures that were only determined after much back and forth). But even so, I had all the conversion stuff in and just figuring it out was aggravating.

Since then, I have a lot of Arduino-based WS2812 projects (or SK6812) and they are all RGB of course (or they are other products that also use RGB methods). Even the ones I linked to Hubitat. But I use custom commands to accept RGB in Hubitat and I do not use the ColorControl capability (basically because I am lazy and do not want to do the conversions). The downside, no color picker. MAYBE I will get around to doing it someday... but none of my users have complained and it is just the way I think as well.

I don't understand the use of WS2812 if there is no color control. ?

@kkossev
did you see this ?

I can use WS2812 because I wrote my own driver. So I have commands I added that say things like:
Set All = has 3 fields to enter R, G, and B values from 0 to 255
or
Set Pixel = has 4 fields, 1 for which pixel to set, then the three fields for RGB

If I was doing a WS2812 controlling ZigBee project... I would use the Color Control. Then when the Arduino gets it from the ZigBee communication, I would convert it to RGB. If I was REALLY advanced I would look at using some of the manufacturer specific/custom cluster or such to be able to pass individual pixel colors or RGB commands directly. Not a lot of value having WS2812-based LEDs if you do not control them individually or have some sort of effects related to that.