Devices not responding - Epic-Systems Echo driver

[prabeau]

I am having a difficult time understanding the issue here as it pertains to my system. I have a Gen 2 echo and echo dot. Installed the driver when on 2.10 Upgraded to 3.1.1 with no issues.

Was I just lucky or am I missing something.

[dcovach]

3 minutes ago, prabeau said:

I am having a difficult time understanding the issue here as it pertains to my system. I have a Gen 2 echo and echo dot. Installed the driver when on 2.10 Upgraded to 3.1.1 with no issues.

Was I just lucky or am I missing something.

Who updated your system

[prabeau]

My dealer in Montreal

 

[AK1]

7 minutes ago, prabeau said:

I am having a difficult time understanding the issue here as it pertains to my system. I have a Gen 2 echo and echo dot. Installed the driver when on 2.10 Upgraded to 3.1.1 with no issues.

Was I just lucky or am I missing something.

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

[prabeau]

HC 800

[AK1]

Perhaps the problem 

Just now, prabeau said:

HC 800

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

[dcovach]

There is a facebook conversation on this problem and some C4 employees and others have commented on this.  Call it what you will, but bad mouthing is different than professional analysis.

Some of the comments sums it up.....

"Because it’s modifying a config file outside the C4 API requirements.  Also, it circumvents the privacy settings of Control4’s privacy wall that is negotiated between C4 and Amazon Alexa"

"I think this firmly qualifies as a dumpster fire driver... No driver should be making changes to the system, outside of what's exposed by the driverworks API. It wouldn't have broken had it not touched the NGINX configuration to begin with".

"That driver is a dumpster fire. Move away from it as soon as possible."

[AK1]

35 minutes ago, dcovach said:

There is a facebook conversation on this problem and some C4 employees and others have commented on this.  Call it what you will, but bad mouthing is different than professional analysis.

Some of the comments sums it up.....

"Because it’s modifying a config file outside the C4 API requirements.  Also, it circumvents the privacy settings of Control4’s privacy wall that is negotiated between C4 and Amazon Alexa"

"I think this firmly qualifies as a dumpster fire driver... No driver should be making changes to the system, outside of what's exposed by the driverworks API. It wouldn't have broken had it not touched the NGINX configuration to begin with".

"That driver is a dumpster fire. Move away from it as soon as possible."

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

[AK1]

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.

[jfh]

1 hour ago, dcovach said:

There is a facebook conversation on this problem and some C4 employees and others have commented on this.  Call it what you will, but bad mouthing is different than professional analysis.

Some of the comments sums it up.....

"Because it’s modifying a config file outside the C4 API requirements.  Also, it circumvents the privacy settings of Control4’s privacy wall that is negotiated between C4 and Amazon Alexa"

"I think this firmly qualifies as a dumpster fire driver... No driver should be making changes to the system, outside of what's exposed by the driverworks API. It wouldn't have broken had it not touched the NGINX configuration to begin with".

"That driver is a dumpster fire. Move away from it as soon as possible."

Two comments;

1) 1.8 works fine on EA-5 on 3.1.0 and I understand it will be fine on 3.1.1 as well

2) I’m not sure I’d call analysis that refers to a driver as a “dumpster fire” professional. There are certainly more ways to make the point in a professional way.  While as a programmer I agree it’s generally not advised to make system changes outside the API, you have to consider the benefits over the risks.  I certainly agree with the unspoken point that the driver modification of the config file should have been noted previously.  (However as long as ES is actively supporting the driver, I don’t see it as a big concern). 
 

If you are happy with C4s VS driver (which was released well after the ES one), it’s relative slowness and remarkable lack of flexibility, then by all means drop the ES driver.  My voice automation relies heavily on being able to use the SET command event  (ES supports; C4 does not) to support use of natural sounding phrase triggers from Alexa routines.  That and VS inability to differentiate device and room names makes using VS messy at best (and/or forcing you to use ridiculous device names).  And I don’t think VS supports UP/DOWN either.

[jfh]

10 minutes ago, AK1 said:

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.

C4 should spend their time fixing their driver so it matches the available functions of the ES driver, thereby making the ES driver unnecessary.

If I have to choose between losing superior voice control over a new OS release, the OS probably loses, assuming no other blockbuster function that requires consideration.

C4 has provided bare bones Alexa support, just enough so they can market it as a feature.  They should be improving it and expanding it as more and more people move toward voice commands are a primary automation interface.

[dcovach]

C4 should spend their time fixing their driver so it matches the available functions of the ES driver, thereby making the ES driver unnecessary.
If I have to choose between losing superior voice control over a new OS release, the OS probably loses, assuming no other blockbuster function that requires consideration.
C4 has provided bare bones Alexa support, just enough so they can market it as a feature.  They should be improving it and expanding it as more and more people move toward voice commands are a primary automation interface.

I still don't feel this warrants hacking a controller without warning.

Sent from my BBB100-1 using Tapatalk

[msgreenf]

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.

Look at some of the changes in os 3.1.1...

[jfh]

4 minutes ago, msgreenf said:

29 minutes ago, AK1 said:

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.

Look at some of the changes in os 3.1.1...

Don’t want to get too far off topic, but what was done in 3.1.1 (besides the default password/access stuff) that’s akin to this?

[dcovach]

Two comments;
1) 1.8 works fine on EA-5 on 3.1.0 and I understand it will be fine on 3.1.1 as well
2) I’m not sure I’d call analysis that refers to a driver as a “dumpster fire” professional. There are certainly more ways to make the point in a professional way.  While as a programmer I agree it’s generally not advised to make system changes outside the API, you have to consider the benefits over the risks.  I certainly agree with the unspoken point that the driver modification of the config file should have been noted previously.  (However as long as ES is actively supporting the driver, I don’t see it as a big concern). 
 
If you are happy with C4s VS driver (which was released well after the ES one), it’s relative slowness and remarkable lack of flexibility, then by all means drop the ES driver.  My voice automation relies heavily on being able to use the SET command event  (ES supports; C4 does not) to support use of natural sounding phrase triggers from Alexa routines.  That and VS inability to differentiate device and room names makes using VS messy at best (and/or forcing you to use ridiculous device names).  And I don’t think VS supports UP/DOWN either.

On the contrary, dumpster fire is easy enough to understand. It's easier to get lost in the details.

It's safe to say that drivers that require all the stars to align and broken rules are going to be low in demand soon.

Sent from my BBB100-1 using Tapatalk

[msgreenf]

Don’t want to get too far off topic, but what was done in 3.1.1 (besides the default password/access stuff) that’s akin to this?

C4soap continues to be depreciated

[zaphod]

What do you mean by VS driver?  Do you mean the core C4 Alexa functionality?

[dcovach]

Voice scene

Sent from my BBB100-1 using Tapatalk

[Gary Leeds UK]

We had this fix applied to our HC800 - Are you saying we need to delete the driver and next update will over ride his fix ?

[AK1]

9 minutes ago, Gary Leeds UK said:

We had this fix applied to our HC800 - Are you saying we need to delete the driver and next update will over ride his fix ?

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.

[RAV]

"Dumpster Fire" is a term coined by another developer for a driver that doesn't follow an official API. Their point being that sooner or later, it's going to have an issue, one side or the other will update and break the driver's control. The trouble is for dealers it's not always apparent if it's official API, snooped, or a hack, and the client just knows they paid for and it isn't working so it's the dealers fault. (Snooped referring to watching the communications by another app that's controlling it; as oppose to a hack which might mimic another device to fool a cloud server, ie pretending to be an iPad).

Control4 will always take the API road. Got to protect their brand, right thing to do.

Now, many dealers are also campaigning to always only use API drivers. For the good of the brand, industry and reliability for your customers.

But automation is still the wild west. What is the developer's responsibility to disclose, update, support? Is it a one time purchase with the expectation it will work and be supported through all updates? Is it a one time at this moment use at your own risk, it works today, and we can't control the future? 

I'd like to at least see a disclosure of: its from their official API, or there is no API and we reversed engineered it. And appropriate related pricing. If it's an API and you're going to support it, than that's worth much more than here use at your own risk works today.

And kudos to the brands that are paying developers for creating complimentary drivers.

[jfh]

1 hour ago, RAV said:

"Dumpster Fire" is a term coined by another developer for a driver that doesn't follow an official API. Their point being that sooner or later, it's going to have an issue, one side or the other will update and break the driver's control. The trouble is for dealers it's not always apparent if it's official API, snooped, or a hack, and the client just knows they paid for and it isn't working so it's the dealers fault. (Snooped referring to watching the communications by another app that's controlling it; as oppose to a hack which might mimic another device to fool a cloud server, ie pretending to be an iPad).

Control4 will always take the API road. Got to protect their brand, right thing to do.

Now, many dealers are also campaigning to always only use API drivers. For the good of the brand, industry and reliability for your customers.

But automation is still the wild west. What is the developer's responsibility to disclose, update, support? Is it a one time purchase with the expectation it will work and be supported through all updates? Is it a one time at this moment use at your own risk, it works today, and we can't control the future? 

I'd like to at least see a disclosure of: its from their official API, or there is no API and we reversed engineered it. And appropriate related pricing. If it's an API and you're going to support it, than that's worth much more than here use at your own risk works today.

And kudos to the brands that are paying developers for creating complimentary drivers.

Agree 100%.   I understand the issues dealers might face but don’t have a lot of sympathy for the lack of disclosure argument given how little information C4 itself discloses (at least to end users).

 

Your “Wild West” point is key though and pretty much applies to any third party driver (hello Extra Vegtables, HouseLogix and others).  As an end user (and certainly as a dealer) you have to weigh the risks of “how long will the driver work?” against “I really want this function”.  I’ve had C4 almost 7 years now and seen enough to know this conflict isn’t going away anytime soon.

If I couldn’t have the function provided by many of the Chowmain drivers and those from other 3rd parties, I’d have a C4 system that was little more than a glorified remote control.  C4 either needs to step up and take ownership or make it a lot easier for 3rd parties to provide function through open APIs.

 

 

[eggzlot]

22 minutes ago, jfh said:

Agree 100%.   I understand the issues dealers might face but don’t have a lot of sympathy for the lack of disclosure argument given how little information C4 itself discloses (at least to end users).

 

Your “Wild West” point is key though and pretty much applies to any third party driver (hello Extra Vegtables, HouseLogix and others).  As an end user (and certainly as a dealer) you have to weigh the risks of “how long will the driver work?” against “I really want this function”.  I’ve had C4 almost 7 years now and seen enough to know this conflict isn’t going away anytime soon.

If I couldn’t have the function provided by many of the Chowmain drivers and those from other 3rd parties, I’d have a C4 system that was little more than a glorified remote control.  C4 either needs to step up and take ownership or make it a lot easier for 3rd parties to provide function through open APIs.

 

 

While I certainly agree, there is a difference between a driver failing vs crippling a project.  I know I am using a reversed engineered driver for MyQ.  If and when it breaks, so be it but it will hopefully not take down my system where a dealer has to spend hours to restore everything.  I'll just have look at other options for control like soldering a remote to a relay, etc.  But my dealer told me it may happen, so he was up front, explained the pros and cons and I made a choice.  If my dealer said the MyQ app has a chance to take your system down in "dumpster fire" fashion I may have looked at alternatives.

I am dealing with issues now with Blue Iris, but I did last me almost 5 years, so I feel I got value and use out of the driver so if support went belly up that is ok, but it has not crippled my system.

[prabeau]

I had the driver forget name now....geofencing.... that locked up my system, so nothing new.

"followme"

 

[AK1]

I had the driver forget name now....geofencing.... that locked up my system, so nothing new.
 
 

This happens but when the consequences are severe and identified weeks ago, developer silence is not cool.


Sent from my iPhone using Tapatalk