I want to be able to remove and re-include devices (the same or new ones) and have them REPLACE devices I had before without needing to redo all my rules. Z-Wave switches aren’t like the ones in grandpa’s house that work for 100 years–they tend to go wonky, unfortunately.
While hand-holding through gui rule building tools can be helpful, I want to be able to more directly ‘script’ them, export them, tweak them, import them (maybe to clone rules, make changes in a text editor, etc.
If a rule is busted, it would be helpful to know what/where it is busted–not just have entire lines say “busted” or have the rule entirely corrupted.
In addition to debugging logging for rules, it would be very helpful to be able to access detailed information on the Z-wave, zibee, etc. networks and traffic to pinpoint problems.
I love the fact with webCoRE that I can save my (or other users’) rules and import them. Saves a heap of time and frustration for someone who is a novice user and doesn’t have a great understanding of programming. I really don’t like the usability of the Hubitat Rule Machine, but I am not a programmer, more of a hobbyist.
As mentioned by @Cjkeenan then something more like Node-RED or other GUI rule building systems but with the ability to import/export/share and directly edit the code if desired.
Considering it’s inevitable that someone will develop a Node-RED integration it makes sense to have that as the program engine? Or a native integration from the beginning for that GUI programming with all of the bells and whistles in place. Immediately makes the platform hugely operational.
While technically Node-RED supports sharing, I will say where it falls is in the configuration nodes. IIRC, whenever you share a flow, it also shares as part of that the configuration nodes used not necessarily with a copy of the original user, but with a template of it. So, if something like Node-RED were to be created I would take care with the “sharing” use case and maybe whenever an import happens, maybe a dialog comes up saying these configuration files need attention so that they do not go unnoticed.
I agree, the wheel should only be reinvented if there are clear and present issues with the current design.
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.
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.
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.
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. )
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.
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.
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
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
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.
, having to botch around it is a pain in the arse.
