New Construction Wiring for Phillips Hue

[TundraSonic]

15 hours ago, Cyknight said:

-Tunable whites are good, but consider HOW OFTEN you actually CHANGE them at all - in most cases tunable white is used to set a preferred level, then it always gets turned on to that level, excepting likely bedrooms.

We use tunable white daily and it changes throughout the day. Our kitchen for instance is about 6500 in the morning, 2800 in the evening and about 1800 late night IIRC. We'd not want to go back to not being able to do this. Similar for our living room, bedrooms and offices. Our gym and all showers use RGB.

A major advantage to Hue/LIFX is that the lamps use industry standard bases and can be easily changed. This when they burn out or when technology advances. For us we're looking for improvements in TM30 (and warm-dim) and Flicker. I don't want to be locked in to the poor light quality that's available today. Ketra, Hue, LIFX, Juno and all the rest still have a very long way to go on improvement.  I also don't like the cost of replacing a Ketra, Juno or similar proprietary integrated fixture/engine when they burn out. Industry standard lamp bases are a very good thing.

[LollerAgent]

2 minutes ago, TundraSonic said:

We use tunable white daily and it changes throughout the day. Our kitchen for instance is about 6500 in the morning, 2800 in the evening and about 1800 late night IIRC. We'd not want to go back to not being able to do this. Similar for our living room, bedrooms and offices. Our gym and all showers use RGB.

Same here - via the Advanced DMX Driver from Domaudeo.  Curious what you are using to power the circadian schedule?

[Cyknight]

On 6/28/2022 at 7:55 AM, TundraSonic said:

We'd not want to go back to not being able to do this.

Then you're in my experience the exception, but regardless, you still SET it to go to the same level every time at the same time. This is easily (and much cheaper) done using a simple controller (even an IR one if need be) for a whole bank of low voltage lights at once, which can be on a single switch for on/off).

On 6/28/2022 at 7:55 AM, TundraSonic said:

. Industry standard lamp bases are a very good thing.

Meh. It should have focused on industry standard FIXTURE control, not bulb control.

Smart BULB is a band-aid solution for existing lighting fixture - and has a place as such for sure.

[Cyknight]

On 6/28/2022 at 7:42 AM, TundraSonic said:

Eliminates accidentally turning something on/off and allows for easier on/off sequences such as is needed for LIFX.

You'd be hard pressed to accidentally engage the current bar - and if LIFX needs so many on/off sequences, they should fix the cause....

[Matt Lowe]

On 6/8/2022 at 9:13 AM, AHSquirrel said:

The Biggest Issue with Philips hue as one mf my colleagues found out is that when you have a power cut all the lights come back turned on at full brightness. Brief power cuts of 3-4 seconds are fairly common in the UK especially at night.

This power on behavior can now be changed in the app. I dont if that works for all bulbs.

[fleon]

Well, not to disagree with Cyknight, but I have three whole home hue projects.  Two of them are quite large - one has about 150 lights, the other has about 300.  Programmed correctly, I have about 200 lights that all come on simultaneously with zero issues.  The motion sensors are instant.  The color works correctly.  The voice control for brightness and color works.  

Hate to say it, but I get more "popcorn" on effect with the C4 zigbee light than I do with the Hue lights.  And although I haven't done a DMX install in quite a few years, hue has been rock solid and way cheaper.   Not to mention so much more flexible and easy to setup.

So I'll have to disagree with you on this one.

 

[TundraSonic]

@fleon, have you had any problems with multiple Hue bridges within a single C4 project? 

Also, have you found a good solution for Zigbee repeaters that support the light protocol?

[TundraSonic]

On 6/29/2022 at 2:17 PM, Cyknight said:

You'd be hard pressed to accidentally engage the current bar - and if LIFX needs so many on/off sequences, they should fix the cause....

The on/off sequence is for resetting the lamp or doing a hard ON or hard OFF. The other option that I can think of would be a button on the side of the lamp but that could be a PITA to access for a GU10 inside a fixture in a 12' ceiling.  

[therockhr]

https://www.thedigitalmediazone.com/2022/06/23/leviton-intros-most-exciting-diy-smart-home-scene-controller-switch/
 

Relates to earlier convos. A keypad/switch that can be used with smart bulb. Not exactly what some are wanting as it looks like the bottom button is only tied to the load. 

[fleon]

1 hour ago, TundraSonic said:

@fleon, have you had any problems with multiple Hue bridges within a single C4 project? 

Also, have you found a good solution for Zigbee repeaters that support the light protocol?

I have not.  I haven't even had to change the default zigbee channel.   As far as programming, yes - 3.3 improved things a lot, but prior to that, I had to sometimes have a delay in activating lights when a scene was complicated.    I got around all of that by using (and I still use) the unilogiq hue driver.

I haven't needed a repeater.  Since the hue hubs are so cheap (you can literally get them free during a sale of the starter packs for hue lights) I just put a new hue hub near the lights.    

[TundraSonic]

Thanks. One problem is not having Ethernet in a few places where a bridge is needed. Worst case I can steal a Comtrend PLA from something else (I've 6 of them operating) but I hate to do that and as good as they are they're not quite as reliable as a hard Ethernet or WiFi.  Maybe if I get time one day I'll turn on the internal WiFi in a Hue Bridge to see how that works.

Is the UnilogIC the 'Hue Motion Sensor' driver? Do you prefer it over the Phillips driver or just what you have? 

[fleon]

Yeah, that should be the same one.  The Unilogiq driver (when I got it at least) had the motion sensor driver and the gateway driver bundled.  The driver allows you to access the list of scenes on the hue hub and activate the scene instead of just a group.   It's also very, very fast.

There's wifi in a hue bridge?  I didn't know that.  You could also  get a wifi to ethernet adapter.  A bunch of people make them.  Haven't used one in years however.  I bit the bullet a couple of years ago and ran some wires around my house then just patched it back up.    

[Andrew luecke]

On 6/11/2022 at 4:41 AM, TundraSonic said:

The Chowmain driver, at least the old one, uses only the cloud API so every command/ack has to go through the LIFX cloud. This is slow and, due to apparent lack of positive ack's, quite error prone. 

If they've redone the driver to talk directly to the lamps and added ack's so that they can insure that you get the result that you expect then it should be much better. Unfortunately I have to wait on our integrator to install it.

 

On 6/11/2022 at 5:41 AM, LollerAgent said:

The Berto LIFX driver makes use of the local API. 

.

 

G'day, 

As per popular demand, we've actually now completely rewritten our LIFX Driver, and our 3rd Generation driver with Local control via the UDP protocol is now available to installers for BETA testing (they can contact me directly for a copy). 

Work on the update actually began a long time ago (some people during beta testing of our V2 / OS 3.3 drivers may have noticed the UDP traffic). However, generally, we don't make announcements until it's ready to ship, which is why it wasn't mentioned sooner (we also didn't want people to be forced to wait for the full rewrite to use the OS 3.3 colorwheel).

The 3rd Gen drivers include all the benefits of V2 / V1 (including ColorWheel, which we implemented a few months ago), and also include a few more commands and improvements (with some major backend improvements, and more inbound). They also use the same licencing as our existing LIFX driver (the upgrade is free for existing useres), however, installers will need to replace your master driver with the new V3 agent, and the original cloud-based V1/V2 lights with the new V3 lights (fortunately, our Auto-Setup makes it easy).

 

There were a number of technical reasons for using the cloud API in the original drivers (the cloud API is a lot easier to work with, and both API's have their own issues).

 

So all these problems should now be eliminated in V3.  
 

 

[TundraSonic]

That's great news @Andrew luecke!  Three questions;

1) When my integrator updates us to this new driver, will I have to redo existing scenes and programming?

2)Do you now have positive ack's to insure that lamps respond (and do you do retries?) or is this still a best effort maybe it will maybe it won't?

3) When we add a new LIFX lamp will this driver pick it up? Can I as a homeowner tell the driver about the new lamp? Or will I have to call our integrator every time we buy a new/replacement lamp?

Thanks,

[msgreenf]

1) yes

3) yes - that is part of the agent

[TundraSonic]

On 7/3/2022 at 2:09 PM, fleon said:

There's wifi in a hue bridge?     

Yeah, but it's disabled so you have to go in and manually enable it. This and not allowing the bridge to be powered by POE are two of the stranger bits about them. The lack of POE perhaps the most baffling.

[TundraSonic]

1 minute ago, msgreenf said:

1) yes

3) yes - that is part of the agent

Thanks.

1) That's a gonna be a lot of programming.   So, once the new driver is installed will all references to the old levels in scenes and programming disappear? Or will I still be able to see them?  IOW, do I need to go in and document every reference to a LIFX lamp before upgrading?

3) Very good news!

[msgreenf]

1) depends on how your dealer does the update. All references to existing devices are removed from all programming and ALS when the old devices are deleted 

[TundraSonic]

8 hours ago, msgreenf said:

1) depends on how your dealer does the update. All references to existing devices are removed from all programming and ALS when the old devices are deleted 

Is there a good way and a bad way?

[msgreenf]

49 minutes ago, TundraSonic said:

Is there a good way and a bad way?

There is no great way to do this. They all kinda suck. I like to keep old drivers. Rename them **old. Then add new and then change programming 

[TundraSonic]

Thanks. I'm assuming that leaves the old references in place so you can just replicate it in the scenes or programming?

[msgreenf]

6 minutes ago, TundraSonic said:

Thanks. I'm assuming that leaves the old references in place so you can just replicate it in the scenes or programming?

Yup! 

[Andrew luecke]

10 hours ago, TundraSonic said:

That's great news @Andrew luecke!  Three questions;

1) When my integrator updates us to this new driver, will I have to redo existing scenes and programming?

2)Do you now have positive ack's to insure that lamps respond (and do you do retries?) or is this still a best effort maybe it will maybe it won't?

3) When we add a new LIFX lamp will this driver pick it up? Can I as a homeowner tell the driver about the new lamp? Or will I have to call our integrator every time we buy a new/replacement lamp?

Thanks,

1. Yes.. The driver protocols and handling are significantly different. I considered reusing the existing drivers, but the reality is, I believe long term maintenance will suffer, and it makes it a lot more prone to bugs. Overall, the complete rewrite was more work, but better for everyone. Also, our UDP driver already has more capabilities (like a command for infrared, and reboot command)

2. The issues with the cloud driver weren't really ACK related (the flag in the Master driver can trigger that on and off as required). The problem more was simply the whole protocol at time operated unpredictably it seems. Some of it was due to the way the light reports back. The UDP has support for the same silly issue (but we keep that flag off)

ACK handling and resending is not implemented in the first beta, but will likely be fully added in the near future because I need it for some of my optimisations I'll be adding (the way I've designed the connections is with the expectation I'll be adding it soon).

That being said, as an example, if I ping a lifx light (I'm using a UAP-AC-LR), its very doable to sustain an almost perfect connection to the light on many networks. So if commands aren't being sent properly, it would be worthwhile checking the network.  Also, we're using Unicast in this case, so you shouldn't be affected by network Multicast / broadcast restrictions 

Ping statistics for 192.168.1.224:
    Packets: Sent = 324, Received = 324, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 72ms, Average = 7ms
Control-C

3. The Agent has built in Auto-Detection, and Auto-setup of C4 drivers. But due to limitations in Composer HE, not sure if there are any restrictions on whether endusers can perform these actions.  

 

Hope that helps, 

Andy

[TundraSonic]

Great. Thanks Andrew. Great info. Looking forward to the new driver.

On #2. We have a quite robust network (7 AP's that have been fairly well tuned) but even so some lamps have spotty signals. I don't think this can be avoided in most homes or businesses.

[Andrew luecke]

22 hours ago, TundraSonic said:

Great. Thanks Andrew. Great info. Looking forward to the new driver.

On #2. We have a quite robust network (7 AP's that have been fairly well tuned) but even so some lamps have spotty signals. I don't think this can be avoided in most homes or businesses.

Just letting you know, this made it into our latest beta (installers can now retry the command a few times before giving up), as well as a lot of new enhancements. The code also allowed us to add some additional optimisations