AK1

I agree with all of the above. The issue remans is Ari should have disclosed this issue on the Epic web site or via email to his licensees given the known severity of the outcome and the amount of time wasted to get back to an "unhacked" controller state. It makes no sense to expect a Dealer doing what should be a business-as-usual upgrade to visit this forum, dealer forums or the dealer KB .

I consider it "bricked" if any form of Composer Pro access is broken by the driver and the only course of recovery (without an unsupported OS hack) is to factory restore and reload project. Not to mention the impact, time and cost of doing so.

i think the key point is the severity of the "bug" in terms of bricking your controller coupled with a total lack of disclosure on the developer's web site. Even better would have been a proactive email to his clients alerting them of this possibility with an OS upgrade to OS 3.1.1. I would be way less concerned about about a bug in the normal course of business. But this bug is worthy of an immediate recall notice, to use an automobile industry analogy.

This happens but when the consequences are severe and identified weeks ago, developer silence is not cool. Sent from my iPhone using Tapatalk

It's impossible to say, Gary. But the point is the driver is playing outside of the sandbox so who knows what future updates will break it.

The Epic "fix" seems akin to the jailbreaking of iPhones a few years ago and Apple judiciously fixed the various exploits. I would expect Control4 to do something similar when a driver developer departs from documented API so that the driver may stop working after a future controller OS upgrade.

Yes, the "fix" posted by Epic yesterday clearly illustrates this.

Perhaps the problem Perhaps the problem only affects EA series controllers. Epic will need to provide information

What model of controller/ So far reports have I have seen apply to EA-5.

The 1.8 driver works on systems up to 2.10.6 with, as you say, Gen 1 Echo. 2 The Epic 2.0 driver also works up to 3.1.0 with latest Echo, but requires a tedious delete and reinstall of driver and recreation of programming some of our clients have 50 or more scenes to recreate. That's at least how I understand it.

Great, thank you for sharing, I am sure this community will find it useful. I wonder why you didn't post this here (your last post was Jan 13) or on your website.

You could have easily taken the 5 minutes of effort to upgrade your website given the severe consequences of your bug. It is completely unreasonable to expect a dealer to consult the Control4 dealer web site prior to upgrading a third party driver. The upgrade info should be on your website. This is nothing to do with bad mouthing or childish behaviour and everything about calling out a failure to document an issue promptly that has severe downside,

I am sure this Forum would love to know how to recover from a "fatal" Epic Systems driver failure after an upgrade to OS 3.1.1 rather than a controller factory reset. Please do share.

Here is an excellent example of how to handle a driver error received yesterday. Well done @Cinegration " Hello, Cinegration Development pushed an update to our Vantage InFusion driver to enable additional features for this driver. Unfortunately, there was a bug in the deployment of the update, rendering the driver ineffective. For this driver to continue to work, the driver must be updated manually for each project that has it installed. Our records indicate that you purchased this driver and have it installed in the following project(s): XXXX *NOTE: Only the project(s) listed above were affected. Any other projects with the Vantage InFusion driver installed will remain on version 1007. To manually update the driver: 1. Download attached Zip file 2. Copy the contents of the Zip file to My Documents/Control4/drivers 3. Login to the project (remotely or locally) 4. Right click on the Cinegration InFusion Driver ("main InFusion driver) 5. Click 'Update Driver' If you are using the light, keypad, or thermostat driver (additional InFusion drivers) as well, you will then need to update each type of driver that is installed in the project. *Only one driver of each type needs to be updated* (For example, if you have 10 light drivers and 2 thermostat drivers, you only need to update 1 light and 1 thermostat driver). Once both the main InFusion driver and the additional InFusion drivers are updated, the driver will function normally. All programming should remain unaffected. We sincerely apologize for this inconvenience. We would like to offer you a coupon code, valid for one of our Agent drivers of your choice - a $50 value! Coupon Code: XXXX Again, we apologize for any issues you experienced due to this driver update. Thank you for being a valued customer of Cinegration Development. The Cinegration Development Team

It is your fault you were lackadaisical in not documenting a severe bug.

Then DOCUMENT your driver issues on your web site - this is not just some "bug". The repercussions are calamitous for affected clients.

Why would I ? My confidence in Epic Systems is now non-existent given the 1.8 to 2.0 driver upgrade issues, this thread and the inexcusable lack of an alert on your web site.

I am beyond unimpressed with Epic Systems and this driver. This is how my day has gone so far: 1) Client on 3.1.0 some driver updates and OS upgrade to OS 3.1.1. One of the "updates" was to be a total reinstall of the Epic driver. The update process from 1.8 is beyond convoluted. Was not looking forward to recreating / copy pasting over 100+ trigger events. But i get it, sometimes (quite rarely) this happens in Control4 world when drivers have a total makeover. 2) Went to Epic website to check for latest driver. 3) Upgraded OS to 3.1.1. - wait, can't access EA-5 remotely - cannot connect to Director. 4) Waste an hour problem-solving, uninstall Composer / reinstall. Go to Dealer KB - found this, SERIOUSLY A MONTH OLD. "a month ago" I reached out to a member of C4Forums who was having the same issue and had to contact C4. This was what he had to say: "You have to do a factory reset on the device, then restore versions until you get to 3.1.0 and stop there. Apparently, 3.1.1 doesn't get along with the Epic Systems Echo driver, and try as we might, we weren't able to remove it to make 3.1.1 happy again." 5) Over to this forum to read this thread. 6) Factory reset EA-5, it goes back to 2.9.0 7) Download and installer Composer 2.9.0 Apply Certificate patches for controller and Composer. 8) Create new project, add and register controller. 9) Upgrade controller to OS 3.1.0 10) Sent a broadcast email to client base: "URGENT - If you are using Epic Systems Alexa driver and upgrade to OS 3.1.1 your controller may be locked and will require factory reset. We are recommending all our clients remove their Epic Driver unless staying on OS 2.10.6 or lower" Stuff like this simply should just NOT happen. Thankfully we largely have understanding clients. Who is going to pay for this 2 to 3 hours of wasted time today? If there was a warning on Epic web site, then caveat emptor. This thread goes back at least 2 weeks and the dealer portal entry "a month ago". That is plenty of tine for Epic to address / document this issue. Where is the warning on the Epic Systems web site? That would have alerted me at step 2) to stop. We spent a lot of time and clients money to upgrade from 1.8 to 2.0 Epic driver. But this is too much. We will be removing this driver from all clients. @chopedogg88 I will email you a refund request for this particular project.

Good point - this happened to us on one occasion recently

I would check for correct driver version. Then I would factory reset the lock, delete driver, reinstall driver and ID it into project again. Does it appear to ID successfully? When it comes to locks, you would be surprised how sometimes they don't ID even though there is ostensibly a good Zigbee mesh. Normal checklistL Zigbee channel, Wifi channel / interference, Zigbee antenna extender. On rare occasions we have to create a separate mesh in the given room.

Araknis

Definitely do not use Unifi switches - the only products wee have found that don't cause Control4 headaches are APs and the Cloud Key for management purposes.

I find Unifi admin unnecessarily complicated, Pakedge pretty basic and Araknis "just right"

We regularly install the WAPs and Cloud Key without a single issue. Everything else causes issues.

Right here.... DO NOT USE any of the following devices with your Control4 system. Every device on this list is known to cause issues and will not be supported. If you have no other option please work with Pakedge for a solution using our recommended networking gear. Use Bridge Mode (IP Passthrough) Setup for Common ISP modem/routers for help setting your current ISP provided device to bridge-mode if needed. Control4 does not recommend or support the use of ISP provided routers / WiFi. Article Body Make Model Device Type Known issues 2Wire 3801HGV Modem/Router Devices fall offline and/or will not identify Actiontec Any Devices fall offline and/or will not identify Arris NVG599 Modem/Router Devices fall offline and/or will not identify Actiontec Any Modem/Router Devices fall offline and/or will not identify Alcatel Lucent I-240W-R lack support for UPnP and/or STP and/or SMB/CIFS Alcatel Lucent I-240W-T lack support for UPnP and/or STP and/or SMB/CIFS Arcor Easy Box a300 lack support for UPnP and/or STP and/or SMB/CIFS Belkin F5D Series lack support for UPnP and/or STP and/or SMB/CIFS Belkin F7D Series lack support for UPnP and/or STP and/or SMB/CIFS Belkin F9K1103 lack support for UPnP and/or STP and/or SMB/CIFS Belkin N750DB Anywhere Access Issues Belkin N600DB Anywhere Access Issues BT Homehub (All Versions) Anywhere Access Issues / Devices fall offline and/or will not identify Dlink WBR-2310 Dlink 655 Does not work with dual transport devices (ie. tuner, amp, switch) Eero Any Mesh Building Router Devices fall offline and/or will not identify Engenius ESR-9850 Anywhere Access Issues Engenius ESR-9752 Anywhere Access Issues Google GFRG100 Devices don't show up or fall offline Google GFRG110 Devices don't show up or fall offline Google Onehub Mesh Building Router Devices don't show up or fall offline Linksys WRT54G (all models) Router Linksys BEFSR41 Multicasting incorrectly set by default - intermittent lock ups Linksys BEFSX41 Lock ups requiring reboot constantly Linksys ALL WRT Models Luxul All Wi-Fi devices Intercom Issues using Luxul Wi-Fi Micronet Sp648 lack support for UPnP and/or STP and/or SMB/CIFS Motorola NVG589 Devices fall offline and/or will not identify Netgear DGN2000 lack support for UPnP and/or STP and/or SMB/CIFS Netgear FS526T lack support for UPnP and/or STP and/or SMB/CIFS Netgear FVS336G lack support for UPnP and/or STP and/or SMB/CIFS Netgear GS108v1 lack support for UPnP and/or STP and/or SMB/CIFS Netgear GS108v2 Netgear N150 (WPN824N) Devices don't show up or fall offline Netgear N300 (WNR2000) Devices don't show up or fall offline Netgear WGT624 Netgear Orbi Mesh Building Router Devices fall offline and or will not identify Pace 5031NV Modem/Router Devices fall offline or will not identify Pace 5268AC Modem/Router Devices fall offline and/or will not identify Planet FGSW-1828 Ubiquiti Any Router/Switch/AP Does not support multicasting. Only supports IGMP which causes issues such as Control4 devices that fall offline due to UDP keep-alive being blocked through multicast routing. These issues manifest most commonly in large systems with dual transport devices ie. Matrix switches, Amplifiers, and Centralized Lighting.