DLite

Sorry, I should have clarified everything. First, "HOLD_MODE" is one of the driver variables. Program off a trigger where HOLD_Mode equals "Permanent." Next, in programming, go to the thermostat you want to control and choose Set Hold Mode to Off. That will clear any existing holds and put the thermostat back on its regular schedule. In theory, there is a device specific command in the driver that allows you to choose whether the Hold Mode is set to permanent, until next, for 2 hours, etc. However, this device specific command has never worked for me, on any version of this driver. And, changing the default hold behavior on the thermostat has never fixed that problem; I have tried every permutation without success. (As an aside, if you ever manage to get this device-specific command to work properly, please let me know!)

As far as I know, this is an issue with the driver. You can't specify the type of hold behavior, and it seems to default to permanent holds, no matter what you set on the thermostat. There is a workaround we use that might help you. The driver has a text string variable that reads in the type of hold mode active. What we do is activate a timer when the "Hold Mode" variable equals "permanent." When the timer expires, we clear the hold on the thermostat. The assumption here is that we will never manually set a permanent hold -- if that works for you too, then you might try this solution.

Yes, it does connect via cell service. They install a small cellular device wired to the generator, and that is what communicates with their cloud service. In my experience, the push notifications from the Mobile Link app are instant and reliable. Email notifications are reliably sent, but they generally take a few minutes to arrive.

We have a Generac generator with their mobile link cloud service. Mobile Link informs you when you lose power, when the generator kicks in, when your utility power comes back online, and the maintenance status of the generator. That is useful when you are away from home. Unfortunately, the cloud service itself doesn't link to any other service like IFTTT. Even the email alerts come after a few minutes of delay and are not that useful to program off.

@bdo21 has a cool solution that you should consider. That said, if voice control is critical to your family, you might also want to give Sonos a serious look. We are probably a high-maintenance family, but I am certain I would get objections if we lost the ability to see track info on C4 touch screens. Even the 0.5 second delay might be a bridge too far in our house. Alexa voice control over Sonos works seamlessly. And, while the drawbacks of Sonos for C4 are well-documented on this forum, I will say that many of those drawbacks have been eliminated or mitigated with the latest release of Roon's C4 driver. The Sonos + Roon Nucleus combination now features good -- albeit not 100% error-free -- C4 integration. With a Roon Nucleus installed and linked to your Sonos speakers, you can select and play tracks from Qobuz, Tidal, or your music library on Sonos from C4 touch screens. As a bonus, Roon's stand-alone app is also a pleasure to use.

Didn't Control4 just come out with their own receptacle outlets? Has anybody had experience with them yet? https://www.control4.com/docs/product/receptacle-outlet-switch/data-sheet/english/latest/receptacle-outlet-switch-data-sheet-rev-a.pdf

As I understand it, this behavior is by design. C4 doesn't expect you to have two different sources playing in the same room at the same time. One way to achieve what you want would be to have your dealer create two "rooms" -- e.g., "Living Room Watch" and "Living Room Listen." If you did that, you could have Sonos playing in the "Living Room Listen" at the same time that the TV plays in "Living Room Watch." For convenience, you might also write a bit of code that automatically mutes the TV whenever the Sonos starts playing and automatically unmutes it if the Sonos stops playing while the TV is powered on.

Yes, that's exactly right -- this was the new driver from a month ago. I think I may have figured out the mistake with the new driver. Previously, the old driver was set to keypad address 13. We configured the new driver the same way, and at first glance, it appeared to stick at 13 after the "set" command. However, the driver actually reverted back to the default of 18, because the new version only supports addresses from 17 to 23. I've now asked our alarm company to create a new reservation between 17 and 23 for the new driver to use, and we'll soon see if that fixes the problem. (My hunch is that 18 was already reserved for the TotalConnect module, which would explain why the driver sort of works, but with weirdness.)

Yes, please let me know how that goes. It's always good to understand other integration options.

As Mitch alluded to, the 4232 has this limitation, but HSIM is compatible with TotalConnect. It worked perfectly fine for a long time using the old version of the HSIM driver software. Since the last C4 OS update, the old driver became less stable in the sense that it would lose communication with the HSIM every few weeks. And, to be clear, the new HSIM driver and TotalConnect both coexist peacefully until an arm/disarm cycle takes place.

After a lot of futzing around, I can finally replicate the issue. 1. Baseline: Driver updates sensor status normally. 2. Arm the security system. 3. Disarm the security system. 4. After Arm/Disarm cycle, the driver stops updating sensor status, although it continues to properly update panel arm state and to properly arm the panel itself. 5. If I go into Honeywell TotalConnect and click on the "sensors" tab to refresh sensor status in TotalConnect, this mysteriously resolves the issue and the C4 driver begins to update sensors again. As noted above, I also use the Honeywell TotalConnect remote access feature as well as C4 remote access. HSIM is supposed to be compatible with TotalConnect, and it worked fine with the old driver. Is anybody else out there using a Honeywell Panel, TotalConnect, and the new driver successfully? Hope I'm not alone with this weird behavior.... Thanks

On Friday, my Honeywell Security Panel HSIM driver was updated to v114. It worked fine for 2 days, but as of last night, the zone status stopped updating on C4. The panel status (disarmed not ready, disarmed ready, and armed) still updates, and I am still able to arm the system programmatically and via the C4 Touchscreen. So far, I've restored a backup from when the zones were updating. I've rebooted the HSIM from the driver. I've rebooted the EA-5 Director. I've power cycled the EA-1 that the HSIM is connected to. No luck with any of these steps. Anyone have any ideas about what might be going on, or what I could do? Thanks very much.

And...right on cue, I had to do a PIN reset this morning.

Does anyone know how to get programmatic keypad presses working with the latest version of the HSIM Honeywell Security Panel Driver? I have an HSIM connecting C4 to my Honeywell Vista 128BPT panel. I had been using an older version of the HSIM-Honeywell driver to control it. However, recently, I started having intermittent loss of connectivity between C4 and the HSIM module. In assessing the issue, my dealer noted that my old driver was marked by Composer as "obsolete" and in need of replacing. He updated me to the newest version (v114), which solved the connectivity problem. It works well in all respects, except I can no longer get the "keypad press" function to work in programming. (Interestingly, the "manual" keypad presses work fine from my T3 touch screens, but just not in programming.) I use keypad presses to enter commands for bypassing zones automatically -- e.g., in case a sensor goes bad. This code worked fine under the older version, but the keypad press commands don't seem to do anything under the new driver. Does anyone have experience or advice regarding keypad presses, or how to bypass zones programmatically? Thanks a lot. EDIT. Whenever we issue a Honeywell keypad press command, the LUA output reads: ExecuteCommand(Honeywell Keypad Press) ExecuteCommand: Unhandled command = Honeywell Keypad Press Any chance someone can explain what that terminology means?

Awesome! Thanks a lot. Looks like that would also be easy to plug into a C4 outlet too.

Same here (knocking on wood).

I'm working on integrating a patio heater into C4. My electrician says I need a 30A powered relay in order to run the heater. My Control4 dealer has not previously connected a relay of that power level and is uncertain whether it can be successfully and safely connected to a relay output on an EA-5 or an I/O Extender. Does anyone out there have experience controlling pumps, heaters, motors, etc, with a relay of this size connected to a C4 device? Thanks a lot.

Hi, We are remodeling our backyard, and I'm looking for an integrator that can advise on how to integrate a patio heater into our C4 system. Please PM me if interested. Thanks a lot.

Yes, I have it working well with 3.0 using the HSIM hardware and driver. The only limitation to be aware of is the short delay in reporting zone closures if you have multiple zones open -- see earlier in this thread.

Has anyone ever integrated a Bromic Patio Heater into C4? See, for instance, their electric models. Thanks

Hi, We'd like to install Zigbee lock on two outdoor gates. We have Yale C4 Zigbee locks throughout our house, but I assume these can't be used outdoors. Does anybody have any recommendations or suggestions? Thanks

Very interesting. Would you mind sharing which brands have this feature? And, is it controlled by the zone board or the furnace itself? Thanks a lot.

I have used Honeywell RedLink in the past, with Carrier equipment. In my case, it supported only a limited number of discrete speeds -- I think it supported 3 speed levels -- but not the continuously variable speeds that a Carrier communicating thermostat would support. The same is true for the Honeywell zoning board, which supports (I think) 3 speed levels. However, I've never used Amana, so I'm not sure if Honeywell is uniquely capable of getting true continuously variable speeds from it. And, I agree it would be great if these manufacturer thermostats would integrate more closely with Control4, but I think the obstacle is very often on the manufacturer side, not the Control4 side. I think C4 and its driver developers do as much as they can with the APIs that are made available, but I'll defer to the experts on whether new and better drivers could be written with the current APIs.

We have a similar situation -- 2 furnaces/hvac units with 7 zones total. IMHO, Control4 integration is tightest with Ecobee's or Control4 thermostats, and much less tight with manufacturer-specific thermostats. And, as I understand it, you won't get the most out of a manufacturer-specific zoning system unless you use the manufacturer's thermostats. On the other hand, manufacturer-specific systems give you more HVAC features. So, it's a trade-off without a perfect solution. We ended up using a Honeywell zoning board, which is manufacturer-agnostic, with 7 Ecobee's, but that has its own drawbacks. E.g., we don't get true continuously variable speed performance out of our system. But, if you find a perfect solution, please do let me know! I hope this helps.

@Gary Leeds UK, Does 3.2 break announcements for other Sonos equipment, apart from the Move? We have announcements working on all our Sonos Amps, Connect:Amps, and Play:5's right now -- would hate to lose that.