If we can have an inbuit debugger or tools that allow breakpoints and single step that would be really really useful.
3 Likes
First of all, I love the input coming here, a lot of things wished for exist in one form or another, some will take longer and others have suitable alternatives 
There are also things which may not be possible at least to begin with. I’m saying this without commenting on which ones, but do keep these things coming, we are very happy for the input
This is something we are experimenting with for the dev-environment, if/when this will be fully functional (or available) is currently unclear, but I wanted to comment on this since it’s a feature I myself very much want even for community development It is however a rather well-developed dev-environment even without this.
4 Likes
A decent Dashboard 
But fast, unlike HE current one. I so want to use HE dash, but just find it so much slower than my HA one.
7 Likes
Also similar to @TechMedX post, but for Zigbee, akin to what deCONZ has.
The ability to see the routing, and LQI 
7 Likes
More powerful radios and a set of external antenna accessories! 
1 Like
Hub or System design:
I’m don’t know how far along you are with hub or system design and development. However I’ll throw this out there.
-
MQTT should be native for broker and client within the system. Create extensibility options beyond just devices and creates a native capability to support multiple control processors without having to use third party integrations. For HE this was “Hubconnect” however it’s not a “new” thing that only HE does. This master-slave configuration is available on lots of “hubs” and on all professional systems. Most use their own methods to accomplish this however MQTT is open, extensible, fast and can be secured if desired.
-
Z-Wave/ZigBee radios. Although the hub or device “may” have an internal radio or set of them having the ability to support external/network attached radios is a necessity and is found with all professional systems. The ability to accomplish this is very easy with Linux/BSD/Unix based systems or it can be accomplished in ways such as the zigbee2mqtt or zwave2mqtt have been working towards of using MQTT as a transport rather than network serial devices. Arch/design of this is variable but the capability should be a required capability
-
hub/system integration API should be default. It took teeth pulling to get this functionality with HE but it was eventually provided in the form of MakerAPI. Although this worked it was not a complete integration.
-
Time. NTP should be default and if possible the HW should have a battery backed RTC.
-
Static IP configuration. All core devices on the network should have the option to manually configure the IP settings.
-
Documentation. User and Developer documentation needs to be robust and continuously updated. Hire a tech writer before that next developer it pays dividends at the mid-way point before it becomes a deficit and problem
-
Community. Don’t tell the community devs they aren’t the target audience for you platform when they are the one’s making it a better platform. Don’t have temper tantrums and stay professional. Do have a sense of humor though.
-
Don’t blame devices for system deficiencies in protocol stacks
[EDIT]
-
From the start provide a ‘The Home Remote’ template/starting point to make the ability to have end user customized. Actual real custom interfaces a reality. One thing that sets pro vs consumer systems apart besides reliability and functionality are the custom interface capabilities. If not ‘The Home Remote’ then your own however it’s easier, faster, more economical to not re-invent the wheel when not necessary
-
Really consider providing the system as a software only option (at a cost) for advanced users or integrators to deploy for development/testing and custom installations. Developers should be able to run VM’s for development and not be required to purchase half a dozen hubs!
[EDIT]
-
Local real full system/radio backups. Yes I know Z-Wave backup is not easy but it’s worth the time to do correctly.
-
If I read ‘perform a soft reset’ one more time I’m out
8 Likes
Here’s an idea that I’ve been thinking about for quite a while - Load Balancing/High Availability/N+1 Support:
I’m relatively new to home automation, but as I buy more devices and automate more things, I have this concern of a single point of failure with a ~$150 piece of hardware taking out the functionality of my ~$300k+ home, even if it is temporary. I know there are backups I can use to restore in the event of a hub failure, but I don’t want to “drop everything” if that should happen; I just want the system to go on with life so I can do the same…some use cases:
-
An environment where we could monitor the utilization of a hub and know when it is time to invest in a second to load-balance the work (and enough granularity to know WHAT needs to get moved WHERE to properly balance the CPU cycles, memory, Z-Wave/Zigbee traffic, etc.)
-
A failed hub in a multi-hub environment could use its backups to “recreate” the now-missing functionality on another, and balance out the workload if necessary. If my workload deems 2 hubs are beneficial, I could have 3 hubs actually spread out in the house, and if hub 2 goes down, then hubs 1 and 3 see this, figure out what hub 2 was doing, restore those things from the backups and redistribute to each other. In a perfect world, I’d get an alert along the lines of, “Hey, Hub 2 just failed, but we migrated everything over, and all functionality continues. Automations might be delayed for a few minutes as we remap functionality. You’ll want to go buy a replacement when you have time. Enjoy dinner with the family. -Your Oh-La Overlords :)”
I don’t know if any of this is even possible, but instead of having one beefy hub (that may be over-powered for some and under-powered for others), you’d have a “mesh of hubs” that support and heal themselves!
EDIT:
Possibly easier/just as useful, the idea of a “hot spare” - instead of Hubs 1 and 3 trying to recreate and remap the workload of now-failed Hub 2, Hub 1 would see that Hub 2 failed, and do an automated restore onto Hub 3 (which was just sitting idle, waiting for its moment to shine, LOL!) You’d get an alert, “Hey, Hub 2 failed, so I lit up Hub 3 to replace it. Give it a couple of minutes to settle in. Oh, and enjoy the sunset with the SO; I got this! -Your Oh-La Overlords”
6 Likes
Interesting ideas… the ‘sticky’ issue here are with the radios and how devices connect to them. Z-Wave and Zigbee both rely on a single master radio that they join. If that radio dies so does all communication with the devices connected to it. It is possible to mitigate this with multiple remote radios where if one fails only a portion of the Z-X mesh is non functional. However these types of setups tend to be more complex and require a lot more design than a typical consumer out of the box type device can/will provide.
Yet technically it is possible. Not simple. But possible. So… interesting.
2 Likes
THIS !
I am so sick of wasting hundreds of hours trying to track down issues on an inherently unstable platform and looking like an idiot in front of the wife.
As much as ST sucks the automation running solid for over a year, has failed only once, compared to many failures over the same period for -can I say it… well you know
5 Likes
- on/off button in the hub
- small battery/supercondenser to allow smooth shutdown and “last message” send
- device management: groups, alternate names, editable labels, editable replaced battery date
- presence feature for any device
- python interface (at least a REST wrapper)
*… I agree… no more reboot to let hub run correctly - resources monitor/resource saturation alarm
4 Likes
Here’s my take, it’s not an easy task … There’s always likely to remain a single point of failure even if it’s just the Z-Wave, Zigbee, Intranet / Internet interface and this will require manual intervention to remedy. The Z radio implementations indirectly impose this because of ID based restrictions. A controller/hub failure is often more easily recoverable via backups or a ‘fancy’ failover but are more widespread in impact. I continue to look at fall/failover setups and MQTT helps.
Choose your important key ‘island’ areas like lighting, security, Audio/Video, heating/cooling, key access, electric gates etc. and choose those well regarded solutions that can operate as a standalone system should your controller go down. Then your house remains functional at a ‘normal’ level.
Now use your HA system to overlay ‘smarts’ to that ‘island’ functionality like scenes, auto night lighting, modes, presence triggered heating, zone control , scheduling, rules, touchscreen control etc. Now should the controller be down the house still functions in a manageable way for others, especially important if you are away from home with the family potentially in darkness.
2 Likes
I 100% agree with this. Don’t try to make one device control everything. Instead, use best-of-breed subsystems for HVAC, Lighting, Security, Video Surveillance, etc… Tie them all together with something that can talk to everything!
This is why I recommend users go with a Smart Thermostat that has its own cloud connected ecosystem, like Ecobee. It can be integrated with many other systems. Ecobee works on its own, locally to control your home HVAC, while still offering remote control/configuration via the Ecobee cloud. Ecobee works with Amazon Alexa, Google Home, and APple HomeKit (locally!), as well as with Hubitat, SmartThings, and many others.
Note: Hopefully Nest will get back on this list once developers finish cracking the new API ‘nut’.
I recommend Lutron Caseta/RadioRA2 lighting systems for switches, dimmers, fan controllers, pico remotes, shades, etc… I also recommend Philips Hue for smart bulbs. Both of these systems have their own dedicated standalone controllers that integrate with tons of services, like Amazon Alexa, Google Home, Apple HomeKit, Hubitat, SmartThings, Node-RED, HomeAssistant, Logitech Harmony Hub, etc… Why limit yourself to direct paired Z-wave/Zigbee switches, dimmers, and bulbs when these complete lighting solutions offer so much more, and are considered the best in class solutions?
The great things about having these best in class subsystems, is that it frees you to try various home automation controllers from various vendors. Wanna try Hubitat, go for it. How about HomeAssisant? Sure, why not try it at the same time as Hubitat? No need to un-pair and re-pair any of your devices. Wanna try Oh-La Labs? Hopefully their upcoming product will support direct integration with numerous sub-systems as well.
Home Security systems - pick the best solution for your needs, that also can easily be integrated with other systems like those mentioned above. General Purpose home automation controllers have never been great at home security, and none have ever really claimed to be. Get something that runs locally and is supported well.
Home Audio/Video - the Logitech Harmony Hub is widely supported and is able to control a ton of devices. It also can work 100% on its own, or in addition to other systems like Amazon Alexa, Google Home, SmartThings, Hubitat, HomeAssistant, Node-RED, etc… I love that I can just pick up ONE physical remote control and know it will work, regardless of whether or not my home automation systems is up and running. But its great that I can trigger a lighting scene based on what Harmony Activity I have started or stopped.
So, my hope for the Oh-La Labs team is that they make sure their solution can easily integrate with all of these other best-in-class solutions.
10 Likes
… and if you can interface to these islands via MQTT as a common denominator that really empowers you to use whatever controller or controllers you wish.
The reverse is also often true - if any one of these controllers has a plugin for the island device (and also MQTT) then you can re-publish the device to MQTT making that device status & control available to all your controllers…
2 Likes
Since I have to be careful not to accidentally slip any details, I Will just quote Markus
Keep the input coming!
Oh, and you guys are so going to love what we have in store…
10 Likes
RRodman ‘Founder’ interesting… do we know you from somewhere familiar already, apologies if it hasn’t registered with me… I think I recognise the dog …
I’m dreaming already about my new controller…
I wish it was already
2 Likes
roflmao
1 Like
Making an assumption that custom code can be freely contributed for drivers and apps I have to ask a couple of somewhat contradictory questions.
Will all your Oh-La Labs drivers/apps be OpenSource ? I don’t mean the core code implementation.
I have previously written drivers for Schneider / Clipsal C-Bus. a lighting system and I released free code (obfuscated) but I couldn’t ever release on some platforms because I am under NDA not to disclose or allow reverse engineering the underlying protocols.
Will developers be able to contribute drivers in such a way that a ‘protected’ driver could be made available? Or even a hub licensed version?
Please understand this is not my desire to publish in a closed source way, nor am I looking for $$ income, it is simply the NDA restriction. My contributions are typically OpenSource and free (unless problems arise)
2 Likes
…
- Hub PoE enabled
- stackable LCD screen for simple GUI
- stackable mini UPS
…
2 Likes
I have similar questions in this regard as well. There’s the NDA issue with some drivers on platforms that are source distributed and there’s also the fact that Simplex Technology is a integration business so…well we like to make money to ya know stay in business
I will respond to this later this evening in detail. I have a few errands to run and there is a bit of a story there that needs to be told properly.
For now though you recognize my picture from my time on the HE forums…
2 Likes