Wish List For Automation Hub

A number of people in this forum were in that other forum so will know exactly what I’m talking about. These things have been debated over and over again there until the demands were met. And in the end they still weren’t that happy. For some reason people just want an app and security guys had to have HTTPS. It really got heated.

Eventually similar users will end up here and they will demand it as well. Just trying to get ahead of it … lol

1 Like

Security is an important thing and deserves attention from the very beginning of the design phase (as it’s SO much more expensive to “do right” after then).

A lot of people hear some words and think they are magical–but the design ‘behind the covers’ is what really counts.

You can bring up an “HTTPS” connection–but, done wrong, it might not be so effective.

The same goes for authentication and other security measures. You can develop “window dressing” approaches, that look difficult-to-break and secure. BUT, they might have serious flaws that can be bypassed as easily as subbing out a URL path.

Additionally, if there are built in “back doors” that allow the support organization wide-open access to your device, these can be a mess. At best, they can create a risk for exposure if the “trick” for getting in manages to become discovered. And, they can allow access to things you’d never want. And, it’s nearly impossible to ever know whether or not this is the case.

Even if the “mother ship” can’t connect directly to a gizmo on their own, chances are the gizmo is reaching out to the mother ship for updates, etc. And, that process can be leveraged to install things, update code, and gain access.

Plus, all those paths can be abused by malicious actors.

Thus–the extreme importance of solid, secure design from the get-go. Transparency and open-source try to aid in helping ensure good security. It’s a lot harder to hide poor/insecure code if the world can see it. And, when it can, others can jump in to help lock things down. But, alas, that’s not always a viable business model.

Note: I’m NOT in ANY WAY trying to smear any particular product with these comments. These are just GENERAL comments that apply to application development and security for any type of internet-connected device.

3 Likes

Yes, local access and HTTPS are tricky given the semi-requirement of third-party verification through certificates. Though you could have a hub issue its own self-signed cert (with the right metadata) which is saved to the browser.

I haven’t seen this mentioned yet, I’ve probably just missed it, but complete offline setup and use is definitely something I’d like to see. A device that you take from the box, never connect to the internet and is fully functional with optional firmware upgrades available as downloadable files.

I’m going to make a list, more things are coming to mind:

  1. AlertMe pairing support.
  2. Ability to use hub completely offline.
  3. USB-C or classic barrel jack power input.
  4. Proper old-fashioned IEEE 802.3af PoE (not PoE+).
  5. If it has wifi, make sure it’s both 2.4 and 5 GHz with each radio able to be powered down completely to reduce interference (obviously most important at 2.4 GHz for this application).
4 Likes

Please do tell how. I’d like to be able to use conditional notifications. Can you maybe provide an example of how to set-up/use (suggest in a new thread to avoid distracting this one)?

Thanks.

1 Like

Let me set one up again - I have been going over my flows recently and haven’t got back around to this one yet!!

New thread sounds good!

3 Likes

Just posted new thread!

Keep this one for the Wish List!!

4 Likes

More support for products on the EU market

Such as?

All Shelly devices, support for Revo radio’s that use the UNDOK app, AVM Fritz!box and the connected products, A zigbee thermostat that fits in an EU box and works together (repeater) with Xiaomi devices , more focus on Google integration, Devolo and more driver support from the company itself instead of counting on the goodwill of community members who can stop giving support any moment (ex. Yamaha, Broadlink…)

How about a path for community integrations and apps to be integrated into the hub?

There’s only good will development when there’s personal need or interest and that’s mostly found within the open source or inexpensive systems. Vendors don’t supply drivers for their products to the automation/control system platforms. Good vendors do provide an API but that’s it. The big platforms either develop the drivers in house or they hire out the work to dev shops.

Community development is how small systems grow and it’s a risk each user takes when they get the development done for free.

Now if you’re paying for a driver then there is an expectation of support and some longevity to the driver. Which is then dependent on the TOS of the driver, the cost and support model.

4 Likes

It would not be a problem for me to pay for a driver, I contribute in the past for drivers or apps that makes my live easier (if the developer likes to work on this concept), why not?. It could be a business model for a company to pay the developers cost…

I have been watching a recent thread in the HE forum where people are trying to help someone troubleshoot a problem they are having. It made me realize that with all of the complexity that is possible with the heterogeneous environments we build, this a real challenge.

It would be nice if there could be a troubleshooting wizard tied to logging. I am thinking it would work something like this:

  1. What problem are you having?
  2. Based on the response do logging of anything that historically has caused that type of issue
  3. Make logs easy to share in the form
  4. Once certain issues have been eliminated allow the wizard to switch logging to focus on what is needed to differentiate between remaining possible cause and repeat to narrow down

The trick will be to start to build a stables of the type of loggin and the length of logs needed to find intermittent problems.

Facetious alternative, never allow device, drivers, meshes, rules engines, etc do anything othan what the user wants.

3 Likes

I like this idea. Something like a submittable form that takes all the desired input from the user and creates a standardized output that could serve as a “ticket” for the community or staff.

1 Like

Secure email sending: TLS, SSL supported. No need for a full-fledged email server.

Secure remote access to the full hub as well as dashboards.

My curiosity is leading me to how all these can be built in a hub that seems to be coming out soon

2 Likes

The time frame of “soon” I think is relative. However my largest hope is that this is not a “hub” only solution.

1 Like

Communication protocol abstraction layer is where it’s at for me.

Very true - I imagine the initial feature set has long been set in stone.

3 Likes

Pretty sure no promises were made or even hinted about regarding what the new hub might offer in terms of these ideas. :slight_smile:

However, one can hope that they are listening–and using the ideas to shape the development and future plans. It’s a bit late to think they would completely rework their plans to incorporate any of these thoughts–but it’s possible they might do a bit of shuffling if the feedback is strong enough and the effort wouldn’t jeopardize their timing.