Not sure if you’re still wondering about this, but I commented those out because my heating system is one mode only (no A/C), but Control4 doesn’t seem to be able to report that to this component/doesn’t really know that at all, so I wanted to hide the extra temperature setting that doesn’t do anything in my system.
Theoretically I think if you commented those out it might work in a dual mode system.
I have mine working in dual/auto mode, but it’s view only right now - calls to update the set target and mode don’t work yet. Once I get those working I’ll add it to the GitHub repo. I’ve been distracted by overhauling my home lab and installing switches… It’s next on my list.
@coolTNT GitHub incoming, but I re-wrote a large portion of the thermostat today.
Here’s what I was able to get working:
Support for temperature ranges
Support for changing the low/high set points.
Support for changing the HVAC mode (complicated and requires another C4 driver, explanation incoming)
After researching for hours, I stumbled on the itfrosty’s original Home Assistant post, and noted that he called out that setting HVAC state wasn’t working. I had the thought of using the Web Event Driver (link below) to call in to Control4 a different way, but looking at his most recent commit on the Home Assistant component, he had already done this in a hard coded fashion for his setup. So I took that code, and retrofit it in to mine. There are some changes to the properties to support this. My configuration now looks like this:
You can see the base URL is now just the IP of the C4 controller. The two web ports are optional parameters, with defaults of 9000 and 8080 respectively. I can’t see the average person changing these - but in my adventures in LUA today I did figure out how to change the ports on Control4, just seemed like it would make sense for these to be configurable.
To manage the Web Event commands, some programming had to be done on the C4 side:
I’ve just taken a look at your GitHub, and I’m liking what I’m seeing. Thank you very much for the effort you’ve put in!
Two main concerns before I pull this into my repository:
What if the user doesn’t/cannot install the Web Event driver? I wouldn’t want to break existing setups with a code update, especially for those who don’t have easy access to Composer Pro to install a new driver. Do you know if the custom component breaks if that driver isn’t installed?
I see you’ve changed the temperature variables to read in Fahrenheit. It would be nice to be able to set the temperature unit through a Home Assistant config flag. USE_FAHRENHEIT=true?
This is minor, but for systems that only support one mode (heating/cooling only), the TARGET_TEMP_HIGH becomes useless, but will still show in Home Assistant. I’ve tried in the past to change the SUPPORT_FLAGS and related logic to adapt depending on a config variable, but haven’t been able to figure it out. If there could be a config variable called SINGLE_MODE_SYSTEM=true that switched the logic back to the old “one temperature only” that would be really cool
@coolTNT I can code around those I think… Will need you to test since my C4 setup is different. Give me a few days to work through the logic and I’ll post an update. Python is still a tad rusty
Ok, so I think I can address all of the requests with the latest commit to my branch of this, with one possible exception (but it still works on my setup).
I’ve added a try/except block around the web event call, so if the web event driver doesn’t exist it will simply do nothing except add a warning to the logs. There’s no other fix for this at the moment due to the broken call from the web 2 way driver.
I coded this, then realized it was actually pointless. As long as the component is consistently referencing the correct variable ID and unit variable ID’s against Control4, it doesn’t matter. Even if the component is retrieving the Fahrenheit values, if HA is configured to use Celsius they will be converted. The trick is just making sure that all of the calls in to Control4 are for the correct/consistent units and results. I backed out this change once I discovered this. It appears my C4 Controller always has both the Fahrenheit and Celsius values populated. While the component is only pulling Fahrenheit, HA displays the configured system units. Let me know if this isn’t the case on yours and I can put the switch back in.
Super excited about this one. I have this working great. I got the component to dynamically change the support flags based on HVAC mode. So if you are in HEAT mode, it will only reference the LOW set point, if you are in cool mode it will only recognize the HIGH set point, and if you are in AUTO it will switch to dual support mode and use both the low and high set points - making the GUI in HA more closely reflect to what we see in Control4. The Lovelace card does glitch a little when the support mode changes on the fly, but it comes back if you navigate out and back, or the temp targets change. This should make this component work regardless if the heating or cooling needs.
Added bonus, I discovered, by mistake that removing the “yield from” call in the async_setup_platform method it removed the None type error others have reported on HA start. TBH no idea what this call did, but it works without it and no errors.
Here’s my latest:
Future improvements I’d like to put in:
A list of parameters for supported modes: All, Heat, Cool - which would change the supported HVAC modes from the HA config, removing useless buttons from the UI for people with setups like yours, or setups where only cooling is needed.
Figuring out a wait to deal with Hold Modes - these don’t directly map from the intents of holds in C4 vs. Presets in HA. Also, much like the HVAC Mode the 2-way-web driver can’t change them. Alternatively I might just get rid of my schedule in C4 and switch to using schedules and automatons from HA to handle all of this.
Next up, I’ll publish an alternative version of the light component that will hopefully work for both dimmers and switches (I can only test with switches).
Added the below for the lights - just to note, they always worked, they would just throw a ton of errors and lag in updating because of the missing brightness values. I added a boolean switch_only flag that is false by default, so you should be able to drop this in and not change any config in HA and it should just work as it did before.
I also removed the yield from call in this one, which removed the None Type error at startup.
It used to pull the unit of measurement from Control4 for some reason, but didn’t use that unit to change the variable IDs used to actually get the temperature. This caused unit mismatches on my setup, so I just removed that. The climate component now always runs in Fahrenheit, and Home Assistant will handle unit conversion correctly.
Excellent, glad it’s working for you! Not sure why I didn’t get the unit mismatches when I was testing over the weekend. When I first installed them I do remember seeing that as well, which is why i went digging for the Fahrenheit values in the first place, but I can confirm with your changes it works on my setup as well.
Only thing you might want to do is update the read me with the new parameters for climate and light (and a note about the web event driver).
Unfortunately I can’t offer much input on the alarm and media player components. While I still use C4 as a universal remote on my main TV, it’s a very limited setup and I’m pretty sure the next time I refresh it C4 won’t be in the mix since there are so many other more easily manipulated options out there now.
Wish I knew more about the HA development process and how we could look to get this as a included component in the platform.
Works great, but I can’t see the Brightness value on my dimmers - C4-APD120 and C4-KD120. Any insight as to why and/or how to troubleshoot? I checked the web2way driver and both properties are exposed as usual.
Hey, Ryan! Noob here. I have tried to follow your instructions above to get my Nest Thermostats (working with C4) integrated into my Home Assistant with no joy. Would you mind helping me out?
Hey Sam, unfortunately the integration that we’ve built here was designed for the Control4 thermostat. Not the Nest products. That being said, if you have working Nest -> Control4 integration, you might be able to manipulate the Nest thermostat via the 2-way-web driver like we’ve done here. You’ll need to look at the itsfrosty two way web driver mentioned in the beginning of the post, and try to find the proxyID for the Nest device(s). Once you have that you should be able to use the web driver to query for the available variables, and test which ones can be manipulated directly.
Not sure I can directly help with this as I don’t have a Nest thermostat, but I can give pointers on how to extract data from the web driver if you have it installed on your C4 system and working.
Hey @rellerton I haven’t actually moved to 0.110 yet, because of incompatibility with some Lovelace elements I’m using. If you want to look into it that would be awesome!
@coolTNT or anyone else using this with 0.110+ - here’s the changes needed to remove the deprecation warning for Light and ClimateDevice. Literally just replaces Light with LightEntity and ClimateDevice with ClimateEntity. Double check the versions before you merge this though, looks like I’m several commits behind you on the other parts of this integration I’m not using:
As a side note, I’m starting a new Python Control4 library that actually uses the same API as the official Control4 app, which I’m hoping will have the code quality and reliability to become an official HA integration someday! If you want to check it out: https://github.com/lawtancool/pyControl4
Unfortunately there’s no README yet, but there are auto-generated docs based on the comments I’ve made in the code.