Wish List For Automation Hub

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.

The hint is in the thread title - “wish list”

5 Likes

Support for Bluetooth LE devices like SwitchBot products. AFAIK they have the only device “on the market”, very hard to find right now, that supports retrofitting curtain RODS to be smart. Supposedly they have SmartThings support by using their hub but nothing made it’s way over to Hubitat.