Jump to content
c4forums | The Control4 Community


c4Forums Member
  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

ajmccaus's Achievements

  1. Yes there are different ways to do this: using advanced lighting scenes and binding or programming the button press to trigger the scene using the preset % in the light driver settings screen programming a ramp to % for the button click event using the UnilogiQ driver, create a scene in the hue app with a preset brightness and program that to trigger on the button press event There's probably even more ways to skin that cat but there's 4. The best way I've found is to program the UnilogiQ driver on the button press event. That gives the smoothest result. Just be sure to add a command to update the levels of the C4 hue light driver right after that or the hue light won't show the proper level in C4. The ramp to % over x milliseconds works pretty well too. Good Hue performance seems to require custom programming for keypad events in my experience. If you just bind the switch to the light driver it doesn't work very well. Let me know if you want to go into more detail on your use case.
  2. After doing months of research, testing, and implementing my own DIY smart lighting system using Philips Hue and Apple's HomeKit, I decided to embark on my Control4 lighting journey this past September. This post is to summarize what I was aiming for, what I did, and the outcomes for the benefit of anyone that might want to do something similar. I'd also like to emphasize the limitations and issues with the current Control4 Free Philips Hue driver, those limitations being a significant impediment to reaching my goals with the system. I'm new to the forum and Control4 and have read through much of the content available on implementing Philips Hue lighting in C4. Many of the issues I see people dealing with are related to the issues I've found with the C4 Hue driver, and could be fixed with a better implementation of the Hue API in C4. Although I'm not a C4 dealer, I am a fairly technical user with software and hardware design experience. My C4 system covers a home theatre, lighting, and security (Overhead garage door control, locks and doorbell camera). This post will be focused on specifically the Philips Hue lighting integration with C4, so on to that. Requirements Overall I wanted a lighting system with: Automatic time of day brightness and warmth (color temperature) control, so that the lights are less bright in the morning and at night, and also warmer when less bright full color lighting in some rooms, e.g. bathrooms and bedrooms have dim red light by default when activated late at night so as not to disturb sleep, and some rooms have full color scenes for relaxing ambiance and dance party purposes Control via any app (C4, Hue, HomeKit, etc) and physical switches to replace my existing switches (i.e. no hue dimmer switches fixed to the wall next to my dumb switches with tape or some barrier preventing the power being cut to the bulbs) A great user experience consistent with normal light switches, as no one is interested in having to read a manual prior to using the lights in my home A way to turn off the power to the bulbs when necessary, from the physical light switch Consistent aesthetics for the switches around the house, especially with multi-gang switch banks Occupancy on, occupancy off, and vacancy mode in most rooms, with intuitive automatic switching between the different modes Compatible with my existing home as a retrofit As cost effective as possible while nailing the above key features I started building this system with HomeKit and Philips Hue and ended up with 1 Hue bridge, over 40 hue bulbs, 3 Hue motion sensors, and 5 Hue dimmer switches. The system worked reasonably well but I quickly ran into the limitations of HomeKit which prevented reaching my ultimate goal. Those limitations that C4 (at least on paper) addressed were: No way to backup the code, so if anything went wrong with the AppleTV HomeKit Hub I'd have to start from scratch again No physical switches available that satisfied my requirements for aesthetics and function Limited capability for implementing advanced programming and variables Limited product integration support (although this is completely addressed by setting up a HomeBridge server for HomeKit) Random glitches that are intolerable for mission critical applications like door locks and primary lighting Me being solely responsible and able to fix the system when broken Implementation After looking at options for physical switches I decided on using Control4 essential switches which have the following advantages over other options out there: Can be set as keypads to control the Hue lights while maintaining power to the bulbs, so that I can control the bulbs via control4 and other means (e.g. Hue app, HomeKit) Can be set up with consistent functionality for single, double, and triple tap on the bottom and top switches, along with other non-hue lighting circuits Can also control the load to the hue bulbs so I can turn off the power to them completely if I want or need to Can be tied into the control4 system seamlessly to control or be controlled by other control4 devices Are aesthetically pleasing especially compared to putting hue dimmer switches beside the load switches or covering the load switches in some way Are a good price for the functionality they give, about half the cost of the regular C4 switches. Mainly the difference (for the switches, not dimmers) is the essential switches don't have advanced control of the LED lights on the switch itself like the regular switches do For the circadian schedule I used a driver from Janus Technologies (Control4 Circadian Lighting (drivercentral.io)). I also installed ceiling motion sensors from Nyce which worked alongside my existing 3 Hue motion sensors. I recently learned about a Hue motion sensor driver from UnilogiQ (@Bogdy, Control4 drivers | UnilogIQ) and will update when I get that installed and configured. Outcomes and Issues: Since there's no way to save a draft here I'm going to post this and come back to complete later.
  3. I had a look at your driver documentation (great quality BTW). I definitely want to try this out in my project. Does your off command issue a Hue API PUT request to simply set {"on": false} for that room (group)? Does your driver GET all the HUE groups (rooms/zones) from the bridge and parse the JSON reply to get the groupID's for each room or zone that's set up in the Hue app? If your driver's off command is like the above I'd like to bind it to a keypad press to replace the C4 driver's 'off' action on the same keypad press. Would that be possible?
  4. Yes I am using the Janus circadian driver right now. I am planning to post separately on my lighting set up and will include more detail on that driver's functionality. In short it works well, but is somewhat hindered by the poor quality of the C4 Hue driver.
  5. I would pay for a good driver, and if there were functionality like circadian scheduling even better. I agree it would be great if C4 would just fix the driver. Since the driver is the better part of 9 years old however, it seems like they have little interest in doing that. What about an open source project for a C4 Hue driver? If the C4 one is free anyway then why not share the source code for the community to improve and maintain?
  6. What’s not true is what the quoted text says: that the hue bridge is not capable of direct scene calls via an API request. The Hue API does have that capability as I mentioned, and it works great. The issue is not the Hue bridge or the API but rather the C4 driver. It would be a great benefit for the whole C4 community to have a driver that works well. Customers would benefit from a great user experience with Hue, and dealers would avoid hours of wasted time and weeks of frustration only to end up with a subpar outcome for their customers.
  7. Two options: 1. Turn on polling in the bridge driver. Downside: have to wait at least 30s for updates and it can bog down your hue bridge with requests especially if you have a lot of hue lights. 2. What I did was turn off polling and tie hue updates to motion sensor events with a macro. That way the hue updates quite well as long as someone is in the house triggering motion sensors.
  8. I know this is a super old thread, but I spent a lot of time researching options and decided to go with both hue bulbs and C4 switches. I wanted: - circadian lighting that changed brightness and white temperature throughout the day, - the ability to control on and off and dimming from the switch, - retaining control from outside of C4 - the ability to control the power to the bulbs. with the C4 and Hue combo I got all this. The one fly in the ointment is the C4 hue driver ‘works’ but is very buggy and inconsistent. It needs to better implement the Hue API so that controlling lights with the C4 switches results in performance as good as a Hue dimmer switch or the app.
  9. Absolutely. I have it implemented with essential switches, some of which are 3-way with Aux keypads. I also have it set so that a double bottom tap turns off all the lights on the floor, and am planning to do a triple top tap turn on all the lights on the floor. Now if only I had a good hue driver that worked as smoothly as the hue app…
  10. Interesting but if you have C4 switches installed you can do much better. I have my C4 switches set up as keypads normally, that simply control on and off commands to the hue bulbs. In addition to the normal single tap function, I have it set up so that a double top click sets max brightness and a triple bottom click cuts power to the load.
  11. This sounds very interesting @Bogdy. I am interested to know more about how this actually works in Composer to save and set scenes. Can you post some screenshots and/or description? Would you consider expanding the Hue functionality in your driver to include more lighting control and that fixes the issues with the C4 hue driver in that regard?
  12. Not true. The Hue API does have a single command to set a scene with a group of bulbs. That’s how it works when using the hue app. You can also send a direct HTTP PUT request to the hub via Postman or a web browser to accomplish this. Have a read through the Hue API and try it out on your own web browser with the built in REST API interface of the Hue bridge: Get Started - Philips Hue Developer Program (meethue.com) This is another example of the need to update or just plain rewrite the C4 hue driver. One HTTP GET request gives a complete JSON database of all the scenes (and their sceneIDs) set up in the Hue hub that could be parsed and saved by the driver for later recall in Composer with perfect results just like from the Hue app. Simple as pie if the driver was improved to do this. It is tragic reading through all the Hue related posts here and seeing all the time spent figuring out subpar workarounds when it could all be avoided and result in a better user experience with a simple rewrite of the Hue driver. Even worse, there is no way to make the workaround code easily copied and pasted into Composer for other similar applications. Hence the need to update the driver software. I’m happy to work with C4 or anyone else who is interested in seeing a great implementation of Hue on C4.
  13. I have the same issue, among others with the hue driver. I am probably going to post on my issue in this forum but am investigating others Q&A’s first. The reason why the hue lights go on at 1% is twofold but is all to do with the broken way the C4 driver implements the hue API. Firstly, the C4 hue driver ramps down brightness to 1% before actually issuing the Hue API ‘off’ request, when an off command is given from C4. Then when a C4 on command is given, the Hue API ‘on’ command is sent to the hub followed by another Hue API command to ramp brightness to some higher level (preset or last used values depending on the C4 driver settings). Other Hue API commands are probably then sent for Color temperature, etc. All this causes the Hue bulb to first turn on to 1% for a brief moment before ramping to the desired brightness. Because C4 is sending so many commands to the bridge in rapid succession, the bridge queues the commands and there’s a delay… but in the worst case a command is dropped when the Hue bridge’s buffer is overflowed. Intermittently dropping the command to ramp to the desired brightness is why sometimes the bulb stays at 1%. All this can be solved very simply by correcting the C4 Hue driver’s implementation of the Hue API. On an off command from C4, just have the driver send an {“on”:false} request to the Hue Bridge, and that would solve the problem of going to 1% when the bulb is turned on from C4. BTW these problems are worse when using the groups driver since that’s more susceptible to buffer overflow from rapid successive API requests. There are other problems with the C4 Hue driver but hopefully this helps explain the reason and solution to the above issue. Adding a timer to issue the command again may ‘work’ but it’s a pretty crude hack and actually adds to the issue of C4 issuing too many Hue API requests too fast, when the same overall end result (with a far better user experience) can be accomplished with a single to a few Hue API commands with proper delays between them. The Hue API documentation recommends 1000 ms between light group requests and 100 ms between single bulb requests. https://developers.meethue.com/login/?redirect_to=https%3A%2F%2Fdevelopers.meethue.com%2Fdevelop%2Fhue-api%2F I’d like to work to fix this driver problem with C4 or anyone else on this forum that could help… it’s really annoying me that my expensive ‘pro’ control system doesn’t control my hue lights as elegantly and smoothly as even a $30 hue dimmer switch or a free app.
  • Create New...