Number one thing for me would be a stable platform from the beginning.
It doesn’t matter how user friendly or feature rich a platform is if it doesn’t work all the time.
12 Likes
Oh one other thing I have for the wishlist and idk if it is possible or if it would break device integrations into other platforms like Alexa, but on the WiFi side, being able to broadcast a VLAN out of the Hub so that all WiFi devices have their own space away from the normal user on the router, kinda like what the Zigbee and Z-Wave radios do, but just a different protocol.
3 Likes
Just to clarify that I’m reading this correctly. You want the new platform to support VLAN’s at the network stack? If so it’s a good idea. I’m going to take a long-shot guess that the hub will be Linux or FreeBSD based so having VLAN support would be possible. However there are complexities that come along with that and I would suggest tucking it away into an “Advanced Configuration” section.
3 Likes
Oh yeah and:
Def needs to have integrations (e.g., like Ring, Hue, etc.).
And, Community Apps/drivers.
But, a huge thing would also be to add the ability to send email and text messages. 
(Email would require the ability to securely authenticate and do session encryption to the server, so I could use my email address, etc.) Maybe if it had enough horse power to run a gateway like Exim, Sendmail, etc. )
2 Likes
I am no network engineer, so I will not pretend to know the complexities, but all I was saying was to mimic the network setups of Zigbee or Z-Wave, dedicated radios on a dedicated network for a specific purpose. Now if that is accomplished via a VLAN or by some other means I cannot say and if that is a bad idea, I am all ears but having to put more and more devices on the same network as everyone else seems like a bad idea and why I transitioned relatively rapidly from Alexa (non-zigbee) as a hub to HE.
This is the only excerpt we have about the HW of the device I think, I love the note about it not being a RPi 4 after I think it was @aaiyar that noticed the stark similarities in the spec.
Our expert engineers and architects have designed the platform from the ground up to ensure there are none of the inefficiencies and bottlenecks (including I/O) currently experienced with other platforms. Featuring a quad core CPU with proper multi threading and neural processing (Not on a RPi4), 1Gb Ethernet, 4GB RAM. Z-Wave and (Ooh the) Zigbee are a shoe-in with onboard Wi-Fi for automated device pairings and will also include other advanced wireless technologies. (We have some really cool things coming.)
I would exercise caution with this sort of thing as feature creep is a devious devil and it has sunk many projects, just look at the history of kickstarter. Not saying this would do that, but that seems like a niche use case for what seems like a decent amount of work.
2 Likes
Thought you guys might like to see the latest info markus has let slip… might help shape your wishes 
6 Likes
Have support for HubConnect. I think it would help the uptake of a new hub if it can be added on to the existing HE hub one might have. It would then not be a big undertaking to try it out and you can easily dip your toes in without breaking what you already have working and also not ending up with two separate HA systems.
6 Likes
Potentially could go one further, a transition tool between the two platforms, bi-directionally if possible would be great.
4 Likes
A transition tool would be good as well. But you would potentially want to stay on your other hub for some time as the integrations you need may not exist on the new hub for some time, so an integration like HubConnect would be great
5 Likes
A working ZigBee 3.0 RGBW driver would be nice 
, having to botch around it is a pain in the arse.
2 Likes
Basic network control would be an initial request from me
i.e the ability to manually input ip address/dns servers/NTP servers etc.
OR… at the very least the ability for these to be controlled via a DHCP server properly
Just respecting DHCP inputs would be great
Andy
9 Likes
not sure what it takes, or if it’s possible, but having some cool z-wave mapping/testing tools like the ones Z-wave toolbox has would be great
5 Likes
In your internal event system architecture it would be most useful to know where events originated from (which app, device, user) not just that they’ve arrived.
3 Likes
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