I have a whole house lighting setup and the moment that has 32 channels of dimming covering around 90 GU10 rececessed lights.
Has anyone attempted any ‘smart bulb’ solution at this scale, and are there any recommendations / warnings / etc. Ideally would like a mix of white and color and need the ability to group bulbs, create scenes, dim up/down, etc. Finally, they need to be ‘affordable’.
Some of my current dimming units are getting old, and the controllers are obsolete, so I’m thinking about upgrading, and going to to smart bulb would free up a whole wall in my garage where al the dimmers and wiring runs are today.
Let’s put this straight.
First, we’re in a OH context here, so you don’t want any proprietary central solution like Loxone or similar, right?
Second, you have centralized all wiring, right?
Third, you can probably rather easily change to low voltage LED lighting using say a GU5.3 base on your lights, correct ?
Here’s some advice:
First, redesign all of your lighting. That is, consider deploying LED strips instead of spotlights, and re-think if you still want all lights and lamps to stay where and the way they currently are. Change from 230/110VAC to 12/24VDC where possible, but keep track of electrical figures.
Second, find a nice-looking tradeoff with a couple of color lights and keep the majority of spotlights as white ones. You don’t want to and don’t need to color everything.
Third, DON’T go for smart bulbs but stick with simple (cheap, too) ones and put OH-controlled actuators into your wiring cabinet instead. Way cheaper and more future-proof, too.
For RGB(W) lighting, you need 3(4) cables per set of spotlights.
See if you can group those spotlights that you want to have color for into groups of three(four). Deploy RGB(W) spotlights
and attach all of them to the existing three wires running to your garage, each now representing a unicolor channel.
I’m using ZWave Fibaro components that I can recommend. There’s a 4-channel LED controller available for 50€, i.e. about the price of a single smart bulb.
It can power 4 unicolor 12/24VDC LED channels or even halogen lights, or one RGBW LED strip or set of spotlights. Control would completely take place in OH, so you can use the Web UI or app or program your scenes and activate them based on time of day, on triggers like movement detection or ‘classic’ button presses, or via separate remote. Many many options here. The LED controller also has 4 0-10V inputs where you could attach a color input device (these are available on *bay or *mazon for 30-40€).
Thanks for the response Markus. I probably dont have the budget to re-design the light fittings this time around, but the advice on using OH controlled actuators is something I’ll look into, as well as maybe trying to put some RGB(W) strips into some of the locations. Need to plan a bit more !
There’s also a 230/110VAC dimmer actuator available if you want to stick with that voltage (but it only has 1 channel).
And quite often you can get snap-in replacement fittings to replace or adapter to move from GU10 to a low voltage fitting like G4 or GU5.3.
Though my advice isn’t worth much here. I have a grand total of three lamps controlled (have no need for more at this time).
However, I have comment on the logic/programming/rules side of things.
You will want to get very comfortable with Groups and [State Machines(A State Machine Primer with HABlladin, the openHAB Genie). A state machine is just a fancy way to think about and code a bunch of “if this then that” rules to control your house.
Think about your lighting as state transitions. You can put everything into a table if it is easier for you. For example:
State/Event Group 1 Group 2 Group 3
-------------------------------------------------------------------------
Morning 25% / blue OFF 100% - Warm White
Day + Someone Home OFF OFF 50% - Warm White
Day + No one Home OFF OFF OFF
...
Once you have your “scenes” configured it is a simple matter of setting up a rule that triggers when ever the events on the left occur, calculates which State your house is in, and then issues the proper commands to the members of the Groups.
Note that you can have as many Groups as you need and a Light can be a member of multiple Groups. However, if a Light is a member of multiple Groups you need to be careful of your states and figuring out which one takes precedence.
I also found it handy to use a Time of Day state machine to drive stuff that needs to change based on the time of day.
rule "Lighting scene change"
when
Item TimeOfDay changed or
Item Weather_Cloudy changed
then
switch TimeOfDay {
case "MORNING": {
gMorningLightsON.members.filter[l|l.state != ON].forEach[l| l.sendCommand(ON)]
gMorningLightsOFF.members.filter[l|l.state != OFF].forEach[l| l.sendCommand(OFF)]
}
case "DAY": {
gDayLightsON.members.filter[l|l.state != ON].forEach[l | l.sendCommand(ON)]
gDayLightsOFF.members.filter[l|l.state != OFF].forEach[l | l.sendCommand(OFF)]
if(Weather_Cloudy.state == ON) gWeatherLightsON.members.filter[l|l.state != ON].forEach[l|l.sendCommand(ON)]
else gWeatherLightsON.members.filter[l.state != OFF].forEach[l | l.sendCommand(OFF)]
}
case ...
}
end
Obviously there is a lot that can be done to simplify the above even further with a lambda or Associated Items but I think this illustrates the main thrust of a State Machine of this type. For illustrative purposes my actual rule looks like:
val logName = "lights"
rule "Set lights based on Time of Day"
when
Item vTimeOfDay changed or
Item Weather_Cloudy changed
then
val offGroupName = "gLights_OFF_"+vTimeOfDay.state.toString
val onGroupName = "gLights_ON_"+vTimeOfDay.state.toString
logInfo(logName, "Turning off lights in " + offGroupName)
val GroupItem offItems = gLights_OFF.members.filter[g|g.name == offGroupName].head as GroupItem
offItems.members.filter[l|l.state != OFF].forEach[l | l.sendCommand(OFF)
]
logInfo(logName, "Turning on lights for " + onGroupName)
val GroupItem onItems = gLights_ON.members.filter[g|g.name == onGroupName].head as GroupItem
onItems.members.filter[l|l.state != ON].forEach[l | l.sendCommand(ON)
]
if(vTimeOfDay.state == "DAY"){
if(Weather_Cloudy.state == ON) gLights_Weather_ON.members.filter[l | l.state != ON].forEach[l | l.sendCommand(ON)]
else gLights_Weather_ON.members.filter[l|l.state != OFF].forEach[l| l.sendCommand(OFF)]
}
end
Sorry, I discovered this post and I’m now asking why the lines seems against each other (one send ON the other OFF withing the same logic trigger
Is this an example or a special syntax for the case structure? If so where can I find the reference?
Thank you
Look at the Group names. One is called gMorningLightsON and it goes through and turns ON all of it’s members that are not already ON. The second is called gMorningLightsOFF and it goes through and turns OFF all of it’s members that are are not already OFF.
At a time period change, there are always two Groups. One Group has as it’s members all those lights that should be ON for that time period. The other has as it’s members all those lights that should be OFF for that time period.
It would be an error to have one light be a member of both Groups.
