MakerAPI commands for RGB bulbs somehow causing wrong color?

🛎️ Get Help
1

I've got Homebridge commanding through MakerAPI pretty seamlessly. The one oddity is color control, where "set bulb to RED" ends up setting some other odd color. Color temperature based commands also don't seem to work properly. This is consistently broken across Sengled, Sylvania, Philips, and some other RGB bulbs (I have a wide variety, all Zwave or Zigbee).

Now here's the weird part: the color command is properly logged by MakerAPI, properly set in the Hubitat system, but the bulb itself gets set to the wrong value. If I open my Hubitat native mobile app, I can see the device supposedly has the correct color in it's logs. This leads me to believe it's Hubitat at fault in some very strange way.

Here's the workflow:
Siri via iPhone -> Homebridge -> MakerAPI -> Hubitat -> Zigbeebulb

Let's pretend I try to set an RGBCCT bulb to RED (where it's currently in colortemp mode set to 3000K): "Hey Siri, set KIDDOS to RED"

Siri gets it right, hands this through Homebridge, and I can see in my logs
[app:247](http://192.168.1.92/logs#)2024-01-18 09:33:48.801[debug](http://192.168.1.92/logs#)device event: {"name":"colorName","value":"Red","displayName":"KiddosOverhead","deviceId":"436","descriptionText":"KiddosOverhead colorName is Red","unit":null,"type":null,"data":null}

I can see in the device properly received "red" (which in this case is a group, however, this is true for individuals as well):

Screenshot 2024-01-18 at 9.42.36 AM
Screenshot 2024-01-18 at 9.42.36 AM2088×1338 221 KB

... but the bulb itself got set to some weird shade of blue in this case... wtf?

To put the final cap on this oddity, if I simply push the "setColor" button as-is, the bulb then transitions properly to the intended RED color. This seemingly proves that core Hubitat understood the command as-intended, put the right values into the right variables internally, but just randomly chose to ship the wrong command out the Zigbee radio.

Anyone know what's going on here? I don't even know where to look next.

2

:sigh:

3

This is an event, not a command (though it normally would follow from a "successful" command). What you'd need to do is see the actual command HomeBridge is sending, which would probably be setColor(), and it should be sending a parameter consisting of a Map with hue, saturation, and level values (representing the HSV/HSB color).

I don't use HomeBridge on Hubitat anymore but imagine some degree of logging either there or in the MakerAPI instance might expose this. That would give you an idea of whether the command is really being sent correctly, since if it isn't, that's one reason the device detail page may work while Siri doesn't.

4

Thank you for the reply. Any tips on how to get to the deeper/appropriate level of logs from MakerAPI (or anywhere else in Hubitat)? What I shared here is all I could find from the /logs tab and, for the record, MakerAPI already has enable logging for debugging set.

5

If that's all Maker API is spitting out, you'd need another approach.

Here's one option: add a "virtual" RGBW bulb that you can make log the commands it sends. I wrote a driver for this a while back:

This, of course, won't let you test with the "real" device, but this will at least let you see exactly what is getting sent from HomeBridge to Maker API and help narrow down a device versus app or other problem.

1 Like