DLite

Woo-hoo! Everything is linked again. I didn't end up needing to re-pair with a new PIN.

I sent an email to Ecobee support. I haven't had good luck getting them to pay attention to Control4-related issues, but I figured it was worth a shot. Has anybody else made progress?

I tried to get a PIN this morning with no luck.

Were you able to get a PIN at all?

At some point today, my Ecobee network driver became unlinked to C4. When I click "Get PIN" -- either in composer or on a touchscreen -- there is no response. The LUA output shows, "Access denied | www.ecobee.com used Cloudflare to restrict access." I checked status.ecobee.com, and everything shows up as operational. Is anybody else experiencing this issue today? Thanks

Thanks a lot — very helpful!

I am getting upgraded from 2.10.3 to 3.1.1, and I have to pick a convenient day for this to occur. About how long should I expect my C4 system to be offline for this upgrade? My dealer has already gone through the process of replacing drivers that are obsolete in OS3, so I am assuming/hoping there won't be any additional time for that. My dealer characterizes my project as being on the larger side, although I'm not sure how best to quantify that here. When Composer launches, it shows that it is loading 625 drivers, if that helps. Thanks

Just a quick postscript on this: We installed the Cinegration driver, and it is working great -- much better than the older driver we were using. Thanks again for the advice. I did have some head-scratching moments in the beginning, but then I finally realized that shades were stopping whenever they received two identical commands in a row. I had a bunch of these command sequences in my code to mitigate missed RF commands -- e.g., "close shade" command plus 2 second delay plus another "close shade" command as a backup. No need for the backup commands anymore, since the Cinegration driver handles the repeated commands automatically. Once I adapted my code to that functionality, all was well.

The default zone closure timeout value is 30 seconds. In my testing, using a lower value results in zones reporting in C4 as incorrectly closed. I think that 30 is as low as you can go without causing problems.

You are correct about the zone closure issue. Just to clarify the behavior, if a single zone is open, its closure is tracked in real-time. If you have multiple zones open, and all are closed at (roughly) the same time, the closures will show up in real-time too. However, if you have multiple zones open, and some (but not all) are closed, then then it takes 30 seconds for these zones to show up as closed in C4. As far as I know, there is no way around this issue with the HSIM driver.

Create vacation is an API capability And just like that, I went from being satisfied with the new driver....to unsatisfied. Sometimes ignorance is bliss.

Weird. We have an all Unifi network, and have no problems with the quality of the video intercom on the T3 touch screens. Of course, we do not have any C4 video distribution over the network. Not sure if that is a key difference here or not.

Hi, I have a Vista 128BPT, and I was also using the old Houselogix Honeywell driver. I switched over to the HSIM module and driver, and all is well. I can confirm that the HSIM works great with the Vista 128BPT, and it is compatible with OS3. In fact, my security panel seems faster and more reliable in responding to the HSIM driver than to the old Houselogix Honeywell driver. As an aside, I was worried about whether there would be good support for the HSIM driver, and I'm happy to report that there was. Before the install, my dealer called Control4 to confirm that HSIM is compatible with OS3, and C4 confirmed that it is. In addition, when my dealer had a minor issue during the installation of the HSIM driver, Control4 support was very helpful, and the problem got solved quickly. I hope this helps.

Yeah, I agree that is annoying. On the plus side, this version seems a lot more reliable at sending successive commands to multiple Ecobee thermostats. That's not listed in their bug fixes, so maybe it is just a coincidence so far, but right now that is what is making me the happiest.

No, unfortunately it does not.

In the new v12 Ecobee Network driver, the change log reports, "HoldMode selector on 'Set Home Status' doesn't work." First off, it is awesome that they finally at least acknowledged this bug, which has been hanging around for a long time, and that they have attempted to address it. Does anybody know how the updated driver now handles the set home status command? In my very limited testing with the new driver, it seems that set home status commands only work when the code selects the "permanent" hold mode. For any other hold mode, issuing the C4 command doesn't seem to have any effect on the thermostats. Can anyone confirm this or else clarify how the set home status command works in this new version? If this is indeed how it is working now, it is definitely an improvement over the old version, even though they haven't fixed the bug completely. Before, the old driver would issue a command that would always default to "hold until next," which was a royal pain -- needed to keep reissuing the home status commands to prevent the thermostat's internal schedule from overriding the selection. Anyway, kudos to C4 for a useful update.

Right. This is exactly my question. After a bunch of trial and error, I finally noticed that my driver only worked when the “model” matches the pathname. However, Vince’s example driver earlier in the thread works perfectly, even though the model is “hottub” and the path is “experience-button-hottub.” The two do not exactly match, but that driver still works. How come? Sent from my iPhone using Tapatalk

Here is an example to clarify -- sorry for my poor explanation. Consider the XML excerpt below from goodbyetimer.c4z. (I've cut out extraneous lines in order to shorten the post.) <name>Scenario - Experience Button - Goodbye Timer</name> <model>goodbyetimer</model> <creator>Control4</creator> <display_icons> <Icon height="300" width="300">controller://driver/goodbyetimer/icons/device/default_300.png</Icon> <Icon height="90" width="90">controller://driver/goodbyetimer/icons/device/default_90.png</Icon> The XML file above installs properly and works fine. However, just changing the <model> line to anything other than goodbyetimer consistently results in failure. For example, the XML file below failed to install into the project when my dealer tried: <name>Scenario - Experience Button - Goodbye Timer</name> <model>goodbye</model> <creator>Control4</creator> <display_icons> <Icon height="300" width="300">controller://driver/goodbyetimer/icons/device/default_300.png</Icon> <Icon height="90" width="90">controller://driver/goodbyetimer/icons/device/default_90.png</Icon> Does this make sense?

Actually, just to be super clear, I am referring to the "model" not the "name." I understand that the name doesn't matter. Does the "model" matter? When I changed the "model," everything seemed to work, but maybe I am imagining this. Thanks for your help.

Huh. I guess I must have inadvertently fixed whatever error I had. Thanks for clarifying.

Hi @VINCELdUB: Thanks so much for posting this explanation. I have a lot of generic experience buttons in my project, and I've been able to create custom ones for my dealer to install. It vastly improves the UI! If you wouldn't mind though, I did want to ask you about one issue that has been puzzling me. At first, I followed all the instructions and was careful to match the name of the .c4z file with the path of the images in the .xml file. However, I kept getting an error. After beating my head on this for a few hours, I finally figured out that if I also matched the model name to the .c4z filename and the path names, it worked like a charm. E.g., one of my buttons was called goodbyetimer.c4z. When the model name was "goodbye," it kept failing. I changed the model name to "goodbyetimer," and all was well. I am happy I got it to work, but I'm still puzzled about how this is working. In the Hot Tub driver you posted as an example, the model name was "hottub," but the file name was "experience-button-hottub." I am confused about why that works. Would you mind explaining the syntax rules about the model name to me? It is obvious I'm missing something! Thanks very much for your help.

Yes, true. I could play around with that and see how it goes over with the kids. Maybe the coolness will help. Thanks!

Yes, quite true. Our family really likes the UI for the wakeup/goodnight button though, and an experience button wouldn't be quite as nicely done. I'd probably rather live without the announcement feature just to keep that interface. Anyway, the announcement feature isn't critical -- maybe I was just aiming for the gee-whiz factor.

Thanks. I pored over that system variables list with no luck -- was hoping for someone to tell me I just missed it!

I'd like the audio endpoints to read out the currently set wakeup time -- via the Chowmain Advanced Announcements driver. The goal is to add that to the "goodnight" sequences in each bedroom. E.g., hitting the "bedtime" button results in the announcement, "Your alarm is set for XX tomorrow." Any other ideas are most welcome. Thanks