LED Bar, Smart Bulbs, etc

I think I remember seeing someone say they were using the mirror me hubitat app (sorry, don’t have a link, think you can find it on hubitat community), and having the bulb mirror to the led child. This would dim the brightness of the led strip to the bulb brightness, but would not do the partially lit you see with the non smart bulb mode.

I have not seen such a child device available to the Hubitat drivers. Am I missing something in my setup? Was this part of an old driver release that was removed? The only LED child device I see pertains to the color and not the level.

I really hope that I am completely wrong or have overlooked something obvious. This would be a really nice implementation! @EricM_Inovelli can you clarify?

You have to be running the latest version of the drivers (not the built in ones) and then enable the option ‘Create LED Color child device’

I would recommend hubitat package manager for keeping your drivers up to date if you don’t use that already.

I’ve been running the GitHub drivers since day 1 with the Inovelli dimmers. This does not work. I can create the child devices no problem. But they do not respond to level changes at all (they only respond to color).

@zavex Is there a modified driver that you’re using that achieves this?

1 Like

I accomplish what you’re after in a number of rooms using the switch bindings app in Hubitat. I tried Mirror, but ran into issues when I was controlling things from Alexa. Mirror just never seemed to perform as I expected it to.

My implementation is that I have the Inovelli Reds installed load-less, and they’re bound to Ilumin bulbs in their respective rooms. One room has multiple bulbs in a group with a virtual RGB bulb … the group keeps the colors of the bulbs synchronized, and the virtual device is exposed to Alexa so that all the bulbs change color at the same time, while also being bound to the switch in the room to reflect brightness and control on/off/dim. The only catch (also applies to mirror) is that the bulbs react to dim changes after releasing the switch. I don’t think there’s a need to use the child device unless you wanted to include it in the group to reflect the color settings of the bulbs.

Not sure this will solve your issue with different bulb types, but its something to try.

1 Like

I just use the latest driver as found in hubitat package manager.

The child level only works when the switch is on (doesn’t impact the off version). It also only has 10 dim levels, so dim levels are rounded by the driver. I don’t actually use mirror, but use a custom app I threw together to keep them in sync. It is really rough, but ensures dimmer is never set to less then 10, resulting in it turning completely off.

It is possible that @kitt001’s solution would be better for you. I am still refining how I setup things.

1 Like

I am trying to play with your app but I am having a little trouble choosing the Notification Child. Can you please provide some guidance?

So here is an example of one of my red dimmers:

image

And some of its relevant configs:
image

image

For smart bulb mode, you need to have updated to the latest firmware
image

And then this is my config for it in the my app:

Are you able to get it to work with similar settings?

Thanks so much for the additional information! I tried to get this working on a couple of my LZW31-SN dimmers (running firmware 1.47 and unsecured) but I didn’t have any luck in Hubitat 2.2.3.142.

For each of them, I made sure that smart bulb mode was enabled and I created the LED color child device using the option in the Inovelli driver (current version per the Hubitat Package Manager). I then setup the app by pointing to the Hue bulb and the LED child device, respectively.

I really wanted to tie the LED level to a hueBridgeGroup device, from the built-in Hue Bridge Integration. But when that didn’t work I also tried using various individual hueBridgeBulbRGBW bulb devices as the triggers.

Here’s logs from one of my rests below with Porch Light - Left which is a hueBridgeBulbRGBW and Front Porch Switch (LED Color) which is the LED on an LZW31-SN.

2020-08-31 02:03:13.444 pm [debug] Updated with settings: [smartBulb:Front Porch Light - Left, notificationChild:Front Porch Switch (LED Color)]

App 709 is the custom LED sync app. “Group Front Porch” is one of the hueBridgeGroups I’d ultimately like to use and it contains the bulb I used for testing. “Front Porch Switch” (local relay disabled, smart bulb mode enabled, INFO logging enabled, DEBUG logging disabled) is both the switch I used to trigger the smart bulb events and the one where I want the LED to change. When I test below with simple on/off button presses, you can see that childSetLevel() appears to be called with good arguments but nothing is changing on the switch.

app:709 2020-08-31 02:06:56.204 pm debug Event Properties (bulbOn): name: switch,value: on,archivable: true,descriptionText: Front Porch Light - Left was turned on,displayed: true,source: DEVICE,isStateChange: true,translatable: false,
dev:1222 2020-08-31 02:06:56.260 pm info Front Porch Switch: componentSetLevel(Front Porch Switch (LED Color), null)
dev:1222 2020-08-31 02:06:56.263 pm info Front Porch Switch: childSetLevel(08-ep103, 100)
dev:1222 2020-08-31 02:06:56.266 pm info Front Porch Switch: Setting parameter 14 with a size of 1 bytes to 10
dev:1222 2020-08-31 02:06:56.269 pm info Front Porch Switch: Retreiving value of parameter 14
dev:1222 2020-08-31 02:06:57.705 pm info Front Porch Switch: parameter '14' with a byte size of '1' is set to '5'
dev:1222 2020-08-31 02:07:01.210 pm info Front Porch Switch: Button 1 was held
dev:4 2020-08-31 02:07:01.557 pm info Group Front Porch was turned off
dev:22 2020-08-31 02:07:01.585 pm info Front Porch Light - Right was turned off
dev:21 2020-08-31 02:07:01.609 pm info Front Porch Light - Left was turned off
app:709 2020-08-31 02:07:01.650 pm debug Event Properties (bulbOff): name: switch,value: off,archivable: true,descriptionText: Front Porch Light - Left was turned off,displayed: true,source: DEVICE,isStateChange: true,translatable: false,
dev:1222 2020-08-31 02:07:01.703 pm info Front Porch Switch: componentSetLevel(Front Porch Switch (LED Color), null)
dev:1222 2020-08-31 02:07:01.707 pm info Front Porch Switch: childSetLevel(08-ep103, 10)
dev:1222 2020-08-31 02:07:01.710 pm info Front Porch Switch: Setting parameter 14 with a size of 1 bytes to 1
dev:1222 2020-08-31 02:07:01.713 pm info Front Porch Switch: Retreiving value of parameter 14
dev:1222 2020-08-31 02:07:03.217 pm info Front Porch Switch: parameter '14' with a byte size of '1' is set to '5'

A few things to double check.

  1. The switch needs to be in the on state.
  2. You should be able to change the level state directly from the child app. If this doesn’t work, no app will
  3. Did you update both target 0 and target 1 on the device when doing the firmware update?

I recall seeing that when you upgrade firmware, all the preferences may not be properly initialized. One thing you could try would be to exclude and then re-include the switch. I believe this will do a factory reset and initialize everything properly. you could also try manually flipping the preference values, saving and then flipping them back - in particular the smart bulb one. I am not totally sure which ones to do though.

Thanks for the suggestions, the exclude/include worked, and was required. I could not get the child device to obey any commands by directly interacting with it, until I included it again.

Now your app works for me for bulbOn and bulbOff events. It’s not working for level changes, which log an error from the app:

dev:21  2020-08-31 03:41:31.411 pm info  Front Porch Light - Left level was set to 10%
app:709 2020-08-31 03:41:31.482 pm debug Event Properties (levelChanged): name: level,value: 10,unit: %,archivable: true,descriptionText: Front Porch Light - Left level was set to 10%,displayed: true,source: DEVICE,isStateChange: true,translatable: false,
app:709 2020-08-31 03:41:31.494 pm error java.lang.ClassCastException: null (levelChanged)

It’s reasonably quick when I use the switch to trigger the Hubitat Button Manager event to get sent to the Hue bridge to change the smart bulbs. It’s quite slow (1-2 minutes in testing so far) to catch up to bulb changes from outside hubitat (Hue or Google->Hue). I guess there’s not a whole lot to be done on that front. The main use case where I’m worried about reasonable speed is the person using the physical switch on the wall getting prompt feedback, and that works acceptably (seconds but not milliseconds).

Parameter 14 is the level when the switch is “On”. As @zavex said, if the switch is “Off”, the level is controlled by Parameter 15 (and SetLevel does not work with that as yet). I was attempting to do level/color for a black series dimmer and it did not work when the switch was off (color would work, level would not). There is some hope though (per the response below):

Keeping :crossed_fingers:t4: that this will happen

I pushed a change that will hopefully fixed this if you want to update.

As far as speed, I think there are a few sources of delay going on here.

  1. There is a 750ms delay on the button press, so that multi tap etc can be recognized. You can turn this off with the latest firmware, but then you loose the multi tap scenes.
  2. Communication with Hue - not sure if the change event happens before or after request/response to hue.
  3. Any delay in sending request to switch, and applying the level to the LED strip.

I am not sure how long 2 and 3 are. I haven’t really messed with hue very much but an idea to test if you can improve that portion would be to create a virtual dimmer and have the dimmer control that directly, and then the bulb be matched to its level (maybe using Switch Binding above?). Also have the LED child be synced to the virtual dimmer. It might help, or it might just slow down how fast your hue bulbs react. It also adds more complication adding additional failure points.

Perfect. Works great now! Works with the Hue Group as well.

I suspect almost all of the lag is hub to hub communication. I am not sure if CoCoHue is any faster but if so I might give it a shot.

Next thing to figure out is how to have a copy of your app per room.

I set the Bridge polling interval in the app to 10 seconds and yep, that’s the delay. I had it set to one minute. I guess I’ll keep it at 10s unless something feels like it is getting murdered.

You can create as many copies as you want, by simply adding a new app each time. The downside is they will all have the same name and you can’t tell them apart. I intend to eventually convert them into a parent/child type of app, where you can rename each child - but it hasn’t been a high enough priority for me to dedicate the time.

I did the parent/child work. And here is your first pull request!

Awesome! Thank you! I went ahead and merged it.

I see you are much better at providing meaningful documentation to users than I am.

1 Like

Haha, well I followed your guidance.

But it looks like I am worse than you at placing files into the right directory. I must have not put the new one in the apps/ dir (it’s in the parent, sorry).

Looks like it is in the right place to me :wink:

Where I am from, that is just as much the code reviewer’s fault as the editor’s.

1 Like