My current Digitrax/TrainController controlled N scale Altamont and Blue Ridge Railway (A&BR1) occupies a 21 x 12 train room.
Currently I am planning a new, larger layout, the A&BR2, and my "Starting Over" blog details my thinking and planning. For anyone who might be interested, here are several entries dealing with lighting and specifically with Phillips HUE lights taken from my blog "Starting Over", which appears on the Altamont and Blue Ridge website (www.altamontandblueridge.com). On the A&BR1, I currently use a Lutron system of dimmable florescent tubes. I know that when I say "florescent", there are those who will wince, but really, you have to see this particular installation. It looks great!
More about the Phillips HUE lighting system
12/13/2015
The more I think about the new WIFI controlled HUE LED bulbs from Phillips, the more convinced I become that this is the way to go. The ability to slowly change brightness AND color is indeed intriguing. I have spent some time researching the possibilities for controlling this system from the Windows desktop, aiming at applications that can be called from Traincntroller operations windows. Although the software I need doesn't appear to be currently available off-the-shelf, there is a C# compatible API for developers called Q42.HueApi that will run within the Microsoft Visual Studio environment. This API will enable me to write my own custom software to control HUE lights. I have downloaded Q42.HueApi and installed it within a new C# Visual Studio Project. Although I have yet to find a comprehensive code resource, I have nonetheless found enough code samples online to write code that will find the hub on my WIFI network, register as a "client," and address a designated single bulb (or a select array of bulbs or all bulbs) to turn on, dim, change color, and/or blink. I have not attempted to apply timing parameters of these functions, but that is the next step. Granted, this new program is not finding the HUE hub because I have not purchased the system yet, so whether or not this code actually works is still very much in question. Nonetheless, it does run and compile without error, and that is a very good sign. Bolstered by this success, I ordered a starter kit today (3 bulbs and a hub that will run up to 50 bulbs).
Beyond getting my code to work and fashioning workable sunrise, sunset and thunder storm sequences, there are still other questions to be answered. What is the system delay time for changes in brightness and color change? What will be the best spacing and positioning for these bulbs? Is the light saturation more directional or diffuse? What kind of shadows will they produce? How much heat do they produce? What are the unforeseen problems? Can I get by with 50 or less on the new layout? If so, it will greatly simplify the programming. If not, then I'll have to divide each move into small increments and address both hubs before I go to the next move. Otherwise, the hubs will respond sequentially. Long sequences of very small moves will create the illusion of a simultaneous response, but this will entail a lot more code, and long system delays could make this approach unworkable altogether. To be sure, these incremental movements can be handled neatly using nested "for" loops, but that kind of thing can get messy if one is not careful.
Preliminary Testing of Phillips HUE System
12/18/2015
My HUE Starter Kit from Phillips arrived a few days ago. It was a snap to get it running using various freeware apps. I put an app on my cell phone and a different app on my PC. Both allow for easy, grouping of bulbs, creation of stored "lighting scenes", and easy manipulation of brightness, color, and intensity right down to the individual bulb level. Impressive!
The LEDs, of course, run very cool so heat is not a problem. The max brightness is about what I expected (600 to 800 lumens depending on the color and saturation) about the same as a 65 watt incandescent flood. It appears that to light a layout from an overhead lighting soffit, I will need to space these bulbs no more than three feet apart in order to get the kind of bright, full daylight I want. With the 3 foot spacing, I do get some unwanted shadows. An object on the layout below, midway between two lights will cast a faint shadow both left and right, and (if it is not directly below the center line of the light array) a dark shadow in the middle. Therefore a two foot spacing would be better, but this starts getting really expensive! Even then, the light diffusion and overall light quality is not as good a the T8 dimmable fluorescents I am currently using.
My conclusion is that I should stick with the current T8 dimmable florescent system, with the florescent fixtures mounted in the corner of the soffit away from the backdrop wall and angled down on the layout and slightly back toward the backdrop and install fixtures for hue bulbs at six foot intervals in the soffit next to the backdrop wall and angled slightly toward the aisle edge of the bench work. This would avoid any shadows on the backdrop, give me the quantity and quality of the daylight fluorescents, as well as add the color changing capability of the HUE lights for effects. Using this approach cuts way back of the cost of the HUE bulbs required, and allows the fluorescents to "fill" any shadows cast by the more directional HUE bulbs (except, of course when the fluorescents are very low or off - in which case - like at sunset - the shadows would be desirable.
With this approach I will need no more than 20 HUE bulbs for the entire A&BR2 (about $1200). Is the extra $1200 for the HUE bulbs wroth it? For sure!
Phillips HUE Program Up and Running
12/19/2015
Well, yesterday afternoon, after some fumbling around, all of the stars finally aligned, and I got all the right references added, and all the right addresses and codes and usernames in all the right lines of the Q42.HueApi code, and Voila! the lights came on both literally and figuratively. In the end, it only took seven lines of code to connect to the HUE bridge and issue a command to my three new Phillips HUE light bulbs.
From there on out, it was a snap. I set up a little application to test all the Q42 commands for brightness, color, saturation, on/off, etc., and I plan to use this to fool around with bulb groupings later. I then created a stunning sunset application that can be called from TC. As the main florescent room lights go down, my new application slowly fades up the HUE lights while slowing changing their color to a deep red/orange, then when the room lights are completely faded out and everything is aglow in red, the red/orange HUE lights slowly fade away and morph to a soft and very dim blue/violet starlight. It's awesome!
There are a few issues. 1) I have not been able to use the new bulbs on ABR1 layout in tandem with the florescent room lights because the HUE bulbs have a very limited range. In the train room, my phone gets wifi from my router just fine, but the HUE bulbs don't, so I'll need some kind of router repeater. The published range of these bulbs is 30 meters from the router, but if there are any walls etc. they don't come close to that. 2) When commanded to go to a brightness of "0", the HUE bulbs, get pretty low but do not go all the way off. This is a problem with most dimmer systems for CFL and LEDs, but given the ability to change colors, changing the color of a "0" brightness bulb to a a soft blue/violet, gives a lovely very dim nighttime effect that is actually more dramatic than complete darkness. I could, of course, program the system to simply fade to "0" and then turn the lights off, but the transition from "0" to off is a little jarring. I say "a little" because when the HUE lights are commanded to turn off, they do not just turn off, they actually execute a nice ~ one second fade. 3) The way this system handles color, is pretty messy. One can program color changes using RGB based commands which are six digit strings incorporating 3 pairs of two digit hexadecimal numbers. UGH this is cumbersome in "for" loops! Or one can use a somewhat baffling x,y coordinate system. Either way, fades across large portions of the color spectrum are tricky, because not all of the RGB or xy colors are producible by the HUE bulbs, and if you enter coordinates that the bulb can't produce, it will simply ignore the command. This is going to take some more study and some getting used to. 4) The configuration of "bridge locator" routines in Q42.HueApi is still something of a mystery to me. I was able to get things running by using a crude software tool provided by Phillips to register with the bridge and then get the randomly assigned username back from the bridge. I then typed this username and my IP address into to my code to connect to the bridge. Since this will be a single user device, I really don't see this as a problem going forward. 5) There might be timing issues with some future routines. Phillips recommends that commands be at least 500 ms apart and 1 second apart for commands to groups of lights. This does not present a problem for the kind of slow fade ins and outs I require. I just use a loop to move from a maximum brightness of 255 to a minimum brightness of 0, decreasing the brightness in increments of 5 or 10 with a 1 second delay after each. So a fade lasts either 51 or 25.5 seconds - smooth as glass. To produce a faster fade, I would have to make the delays less, which could cause problems, or make the increments larger, which might make them visible and kind of jittery looking.
In all, the HUE system and the Q42 API together are nothing short of wonderful - very flexible and powerful (although not totally transparent) systems that are every bit of what I expected and more! The error trapping in the Q42.HueApi is excellent, and it usually not only defines errors, but suggests a fix.
Pete Caldwell
www.altamontandblueridge.com
Currently I am planning a new, larger layout, the A&BR2, and my "Starting Over" blog details my thinking and planning. For anyone who might be interested, here are several entries dealing with lighting and specifically with Phillips HUE lights taken from my blog "Starting Over", which appears on the Altamont and Blue Ridge website (www.altamontandblueridge.com). On the A&BR1, I currently use a Lutron system of dimmable florescent tubes. I know that when I say "florescent", there are those who will wince, but really, you have to see this particular installation. It looks great!
More about the Phillips HUE lighting system
12/13/2015
The more I think about the new WIFI controlled HUE LED bulbs from Phillips, the more convinced I become that this is the way to go. The ability to slowly change brightness AND color is indeed intriguing. I have spent some time researching the possibilities for controlling this system from the Windows desktop, aiming at applications that can be called from Traincntroller operations windows. Although the software I need doesn't appear to be currently available off-the-shelf, there is a C# compatible API for developers called Q42.HueApi that will run within the Microsoft Visual Studio environment. This API will enable me to write my own custom software to control HUE lights. I have downloaded Q42.HueApi and installed it within a new C# Visual Studio Project. Although I have yet to find a comprehensive code resource, I have nonetheless found enough code samples online to write code that will find the hub on my WIFI network, register as a "client," and address a designated single bulb (or a select array of bulbs or all bulbs) to turn on, dim, change color, and/or blink. I have not attempted to apply timing parameters of these functions, but that is the next step. Granted, this new program is not finding the HUE hub because I have not purchased the system yet, so whether or not this code actually works is still very much in question. Nonetheless, it does run and compile without error, and that is a very good sign. Bolstered by this success, I ordered a starter kit today (3 bulbs and a hub that will run up to 50 bulbs).
Beyond getting my code to work and fashioning workable sunrise, sunset and thunder storm sequences, there are still other questions to be answered. What is the system delay time for changes in brightness and color change? What will be the best spacing and positioning for these bulbs? Is the light saturation more directional or diffuse? What kind of shadows will they produce? How much heat do they produce? What are the unforeseen problems? Can I get by with 50 or less on the new layout? If so, it will greatly simplify the programming. If not, then I'll have to divide each move into small increments and address both hubs before I go to the next move. Otherwise, the hubs will respond sequentially. Long sequences of very small moves will create the illusion of a simultaneous response, but this will entail a lot more code, and long system delays could make this approach unworkable altogether. To be sure, these incremental movements can be handled neatly using nested "for" loops, but that kind of thing can get messy if one is not careful.
Preliminary Testing of Phillips HUE System
12/18/2015
My HUE Starter Kit from Phillips arrived a few days ago. It was a snap to get it running using various freeware apps. I put an app on my cell phone and a different app on my PC. Both allow for easy, grouping of bulbs, creation of stored "lighting scenes", and easy manipulation of brightness, color, and intensity right down to the individual bulb level. Impressive!
The LEDs, of course, run very cool so heat is not a problem. The max brightness is about what I expected (600 to 800 lumens depending on the color and saturation) about the same as a 65 watt incandescent flood. It appears that to light a layout from an overhead lighting soffit, I will need to space these bulbs no more than three feet apart in order to get the kind of bright, full daylight I want. With the 3 foot spacing, I do get some unwanted shadows. An object on the layout below, midway between two lights will cast a faint shadow both left and right, and (if it is not directly below the center line of the light array) a dark shadow in the middle. Therefore a two foot spacing would be better, but this starts getting really expensive! Even then, the light diffusion and overall light quality is not as good a the T8 dimmable fluorescents I am currently using.
My conclusion is that I should stick with the current T8 dimmable florescent system, with the florescent fixtures mounted in the corner of the soffit away from the backdrop wall and angled down on the layout and slightly back toward the backdrop and install fixtures for hue bulbs at six foot intervals in the soffit next to the backdrop wall and angled slightly toward the aisle edge of the bench work. This would avoid any shadows on the backdrop, give me the quantity and quality of the daylight fluorescents, as well as add the color changing capability of the HUE lights for effects. Using this approach cuts way back of the cost of the HUE bulbs required, and allows the fluorescents to "fill" any shadows cast by the more directional HUE bulbs (except, of course when the fluorescents are very low or off - in which case - like at sunset - the shadows would be desirable.
With this approach I will need no more than 20 HUE bulbs for the entire A&BR2 (about $1200). Is the extra $1200 for the HUE bulbs wroth it? For sure!
Phillips HUE Program Up and Running
12/19/2015
Well, yesterday afternoon, after some fumbling around, all of the stars finally aligned, and I got all the right references added, and all the right addresses and codes and usernames in all the right lines of the Q42.HueApi code, and Voila! the lights came on both literally and figuratively. In the end, it only took seven lines of code to connect to the HUE bridge and issue a command to my three new Phillips HUE light bulbs.
From there on out, it was a snap. I set up a little application to test all the Q42 commands for brightness, color, saturation, on/off, etc., and I plan to use this to fool around with bulb groupings later. I then created a stunning sunset application that can be called from TC. As the main florescent room lights go down, my new application slowly fades up the HUE lights while slowing changing their color to a deep red/orange, then when the room lights are completely faded out and everything is aglow in red, the red/orange HUE lights slowly fade away and morph to a soft and very dim blue/violet starlight. It's awesome!
There are a few issues. 1) I have not been able to use the new bulbs on ABR1 layout in tandem with the florescent room lights because the HUE bulbs have a very limited range. In the train room, my phone gets wifi from my router just fine, but the HUE bulbs don't, so I'll need some kind of router repeater. The published range of these bulbs is 30 meters from the router, but if there are any walls etc. they don't come close to that. 2) When commanded to go to a brightness of "0", the HUE bulbs, get pretty low but do not go all the way off. This is a problem with most dimmer systems for CFL and LEDs, but given the ability to change colors, changing the color of a "0" brightness bulb to a a soft blue/violet, gives a lovely very dim nighttime effect that is actually more dramatic than complete darkness. I could, of course, program the system to simply fade to "0" and then turn the lights off, but the transition from "0" to off is a little jarring. I say "a little" because when the HUE lights are commanded to turn off, they do not just turn off, they actually execute a nice ~ one second fade. 3) The way this system handles color, is pretty messy. One can program color changes using RGB based commands which are six digit strings incorporating 3 pairs of two digit hexadecimal numbers. UGH this is cumbersome in "for" loops! Or one can use a somewhat baffling x,y coordinate system. Either way, fades across large portions of the color spectrum are tricky, because not all of the RGB or xy colors are producible by the HUE bulbs, and if you enter coordinates that the bulb can't produce, it will simply ignore the command. This is going to take some more study and some getting used to. 4) The configuration of "bridge locator" routines in Q42.HueApi is still something of a mystery to me. I was able to get things running by using a crude software tool provided by Phillips to register with the bridge and then get the randomly assigned username back from the bridge. I then typed this username and my IP address into to my code to connect to the bridge. Since this will be a single user device, I really don't see this as a problem going forward. 5) There might be timing issues with some future routines. Phillips recommends that commands be at least 500 ms apart and 1 second apart for commands to groups of lights. This does not present a problem for the kind of slow fade ins and outs I require. I just use a loop to move from a maximum brightness of 255 to a minimum brightness of 0, decreasing the brightness in increments of 5 or 10 with a 1 second delay after each. So a fade lasts either 51 or 25.5 seconds - smooth as glass. To produce a faster fade, I would have to make the delays less, which could cause problems, or make the increments larger, which might make them visible and kind of jittery looking.
In all, the HUE system and the Q42 API together are nothing short of wonderful - very flexible and powerful (although not totally transparent) systems that are every bit of what I expected and more! The error trapping in the Q42.HueApi is excellent, and it usually not only defines errors, but suggests a fix.
Pete Caldwell
www.altamontandblueridge.com
