DLite

Just checked, and the problem now seems to be resolved. Mine is linked again.

I have had a recurrence of this problem since last night -- account is unlinked, and I can't generate a PIN code. Anyone else?

Sure, some screenshots are linked to below. The C4 integration is really pretty awesome, but as you note, the multi-zone playback bug is unlikely to get fixed. https://www.dropbox.com/s/4tzf94kx5d95vfm/Screen Shot 2020-03-29 at 10.17.07 AM.png?dl=0 https://www.dropbox.com/s/ys3jm0cyy8c94rh/C4-Roon.Screen Shot 2020-03-29 at 10.16.38 AM.png?dl=0 https://www.dropbox.com/s/8y8tk3kx344urnx/C4-Roon.Screen Shot 2020-03-29 at 10.15.03 AM.png?dl=0

There is a C4 driver for Roon that works only if you have a nucleus. The problem is the driver has a bug that prevents multi-zone playback from functioning properly. Roon has been aware of the bug for over a year, and I have kind of lost hope that they will fix it. Apart from zone grouping, the integration is really good. However, the lack of reliable zone grouping is a huge flaw IMHO. On the plus side, I love the Roon app, and it is still my go-to interface for music. It works really well with Sonos and a variety of high-definition streamers. And the Roon app really enriches the listening experience.

Thanks very much for clarifying.

Cool! I didn't think my dealer had auto-update set up for that driver, but it seemed to update to v13 automatically.

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.