[OBSOLETE] Osram LIGHTIFY GardenSpot Minis rgb - aap version

I wonder could you make a rule in CoRE to limit the level to below 75% ? @bamarayne said he measured 5.4 watts. So 75% would be like 4 watts. That times 3 sets stays under the 12.5 watts the supplied transformer is labeled to provide? (If my theory is right)
I would imagine 25% less at max wouldn’t be a huge difference visually.

Possibly just set it at 75% level for an evening and see what the temperature of the power supply feels like? See if it is cooler? See if it seems alot dimmer?

I’ll take some measurements this evening to make sure the power draw varies with the brightness.

Please remember eventhough LED has resistive nature, is non linear.

Then again, Ill probably work this weekend on the second outlet.

Just depends how it’s dimming it. Just thinking outloud. (Non engineer type) I don’t know if it’s using PWM or what?

Power will vary with the brightness. There are two main ways to dim the LED:

  1. voltage variation - which does not play well with the LED on the low end of voltage, since the LED - a diode - has a minimum voltage requirement to “open”, so lowering the voltage below 0.6-0.7V would just cause the LED to - well - turn off
  2. PWM (pulse width modulation) - voltage is constant, but it’s not applied to the LED 100% of the time - think of it as turning it on and off very fast, some hundred times a second. Vary the amount of time it stays on versus the amount of time it stays off and you get an apparent brightness change - the LED is always off or full brightness, but because you’re interleaving the on and off times so fast, the eye will perceive it as actually dimmed.

Both methods reduce power consumption with level. Since we’re talking DC, the ideal LED is 100% resistive. Half the voltage applied, you get a quarter of the power consumed. Apparent brightness will also be closer to 25%, not 50% (you halved the voltage). LPW (lumens per watt, aka efficiency) may also vary depending on voltage applied. The PWM has a somewhat linear power variance with % of time the LED is on, even though, again, perceived brightness won’t be linear - the controller itself compensates for that so that the scale 0-100 in level does not linearly follow the 0-100 in % of pulse width, but the apparent brightness.

Either way, I see two problems here:

  1. stressing the power supply beyond its rated power output - this will cause higher internal PSU temperature, leading to a much shorter life span. You can help it by adding a radiator and some radiator paste between the PSU case and the aluminum radiator. Or use a bigger PSU. UL listed and IP rated.

  2. stressing the LED controller - it most likely uses transistors to either vary voltage or pulse width on the LEDs, they are designed for a certain power as well, simply using a stronger PSU does not mean the controller will take the beating. Isn’t the controller overheating too?

You will also very likely see brightness variance between the first bulb and the last bulb in the 27 chain because of wire resistance eating up voltage. Also, 100% brightness at 9/18 lights may be “brighter” than 100% brightness at 27 lights - pointing to a shortage in input power or the controller’s capacity to handle enough power.

2 Likes

Thanks @ady624 for the explaination.

1 Like

Yep… what @ady624… thanks for bringing back the nightmares of electronics school!

My concern is about the pier supply transformer… Will the draw the transformer is pulling change as the output varies. Not all do. It depends on the diode limiting rectifier and how the circuitry is designed… odds are it will change… we’re not talking high end aircraft electronics here… But remember I’m trained in advanced weapins systems… so I always think redundancy and reliability.

No noticeable difference in terms of brightness when comparing 2 sets (18) vs 3 sets (27), but slightly darker when compared to 1 set (9) - around 3-5% (ballpark estimation).

No difference between the first (1) and the last (27) (at least I can spot)… I guess strong design and good quality of the equipment (wires and interconnections) minimize this effect.

No big effect on the controller or the transformer (they heat up as compared to another 1 set system I have installed). Both transformer and controller are located in a vent site (also helping with dissipation).

For the record… I know I’m stressing the system… I concur with @ady624 the stress should be in the controller (PWM), but I guess there should be some kind of compensation (either width or frequency) when connecting 27 leds.

I’m not recommending this, but telling that I have been using this configuration for 2/3 months…

Then again, I will install the second outlet (but mainly because my wife want different colours :grin:)

1 Like

The OSRAM gardenspots LED driver has no transformer. Transformers are inefficient and generate a lot of heat (and vibration) that is incompatible with the IP68 rating of that LED driver. It’s pretty much a hollow box with a PCB board in it and then filled with resin to make it IP68 compliant. Power draw of the controller will vary with output level, so dimming them would be bringing the power level back into the rated range. If one were to limit it to 75% brightness, I would do that in the DTH, inside the setLevel() command. Central point :wink:

Well that’s just stupid…

And yes… the power draw is 1/2 at 50% brightness

@Squares, @bamarayne, @ady624

Thanks, for indulging me and my curiosity.
That’s one of the best parts of this forum, all the smart and helpful people.

I now feel safer experimenting more. Now to learn how to modify the DTH or set up a rule with CoRe. I doubt mine would ever get turned all the way up. We like them dimmer.

Sorry to semi hijack the thread.

1 Like

If your goal is to have the same color / hue / level on multiple strands of gardenHues, an alternative is to use CoRE.

Save the attribute(s) of the “master” gardenHue to a variable(s) and then set the variable(s) to the attribute(s) of the “slave” gardenHues.

Thanks, I’ll use that to keep both sides synced. I’ll also set a limit using CoRe to keep level down below 50% to help prevent over driving the power supply and driver module. Since I’m going to try running 3 sets on each power supply, controller set.

I would modify the DTH to max out at whatever value you want, say 75%. This way you make sure it stays below that threshold even when using the ST app to adjust things or other apps. Just my 2 cents

I’d really like to see more pictures of what you guys are doing.

Yeah I agree, I should hard limit it to protect against those that have no idea what I’m doing. Unfortunately right now I am running the default DTH, I could not get this version to respond to control changes and have not had time to troubleshoot the issue yet. Then there is the issue of not knowing how to code or change the default code.

I will hopefully get to tinker with it this weekend. Get this DTH working, then find the set level code and try to edit in a limit.

Thanks again for your 2 cents. Always appreciate when others with more working knowledge than me help me learn.

To set a max temp on this DTH, you should modify two areas:

  1. The slider tile Change the “levelSliderControl” tile to include a range limitation. In the example below, I used a range of 1 to 75:

controlTile(“levelSliderControl”, “device.level”, “slider”, height: 1, width: 4, inactiveLabel: false, range:“(1…75)”) {
state “level”, action:“switch level.setLevel”
}

  1. The setLevel() function: Change the setLevel() function to adjust the level value to your desired maximum. This will prevent the level from going above 75 if called by something other than the DTH level slider (like through CoRE). Change the following line:

state.levelValue = (value==null) ? 100 : value

to (again I used a max of 75 in this example):

state.levelValue = (value==null) ? 75 : value

if (state.levelValue > 75) { state.levelValue = 75 }

Here is what the modified setLevel() function should look like in its entirety:

def setLevel(value) {
log.trace “setLevel($value)”
def tt = (this.device.currentValue(“transitionTime”) ) ?: 3.2
Integer duration = tt * 10
log.debug "duration = ${duration} / tt = ${tt} "

state.levelValue = (value==null) ? 75 : value

if (state.levelValue > 75) { state.levelValue = 75 }

def transitionTime = swapEndianHex(hexF(duration,4)) 
log.debug "transitionTime = ${transitionTime} "

def cmds = []
if (value == 0) {
    sendEvent(name: "switch", value: "off", isStateChange: true)
    cmds << "st cmd 0x${device.deviceNetworkId} ${endpointId} 6 0 {}"
    cmds << "delay 150"
} else if (device.latestValue("switch") == "off") {
    sendEvent(name: "switch", value: "on", isStateChange: true)
    cmds << "st cmd 0x${device.deviceNetworkId} ${endpointId} 6 1 {}"
    cmds << "delay 150"
}
sendEvent(name: "level", value: state.level, isStateChange: true)
def scaledLevel = zigbee.convertToHexString(Math.round(value * 0xfe / 100.0), 2)
cmds <<  "st cmd 0x${device.deviceNetworkId} ${endpointId} 8 4 {${scaledLevel} ${transitionTime}}"
//log.debug cmds
cmds

}

3 Likes

Thank you very much, I was just looking at this, what timing!! I was in the right neighborhood and just about to change some stuff. Now I don’t have to edit and test and edit. It’s right here for me to cut and paste.

VERY much appreciated.

No problem!

Here is the CoRE Piston I use to automate my lights (although defer to anything @ady624 says, obviously).

I’m going to have to go download the latest DTH. For some reason what I have on my computer isn’t matching the same format as what you’ve sent. I’ll get it figured out. Thanks again. BIG time saver!!!