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:
AlertMe pairing support.
Ability to use hub completely offline.
USB-C or classic barrel jack power input.
Proper old-fashioned IEEE 802.3af PoE (not PoE+).
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).
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)?
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…)
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.
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:
What problem are you having?
Based on the response do logging of anything that historically has caused that type of issue
Make logs easy to share in the form
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.
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.
Pretty sure no promises were made or even hinted about regarding what the new hub might offer in terms of these ideas.
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.
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.
