That's for them to decide.
Based on the # of people that will pay for Home Seer (yuck) licenses, I would say the data shows that there are a chunk of people that are willing to pay a premium for higher horsepower, local systems.
1 Like
This thread can go on and on with us giving our thoughts on what HE should do.
Bruce has already given an answer of where they presently stand and what their priorities are. Should they change I'm sure we will be the first to know.
I for one would be more than happy for them to continue to investigate the memory leak issue.
Wouldn't a 'turbo' hub still suffer with this problem if it ran the existing code? It would just take longer to crash.
I'm probably an average user with the number of devices and automations I'm running and I reboot twice a week and don't really have any issues. (I agree this is not really satisfactory, but it works for me).
I get the odd glitch here and there but generally all is good.
Just my tuppence worth.....
2 Likes
I would like to have the ability to do device firmware updates. I don't want to go out and purchase some other hub just to do that. For me, that would be worth a premium over the stock HE hubs.
6 Likes
I don’t believe that is true. There are polling settings for local LAN dashboards in advanced settings.
The two seconds is only used if the websocket connection fails, as in the green/red dot in the top right corner is red.
Originally it was always polling and then came the update with the websocket. That update is what revealed the websocket that well so love for our other applications now 
2 Likes
That’s good to know. 
Thanks!
2 Likes
It is easy to test too... Open the developer tools while on the dashboard and you can see that there is not regular polling when you are on the local lan
If they do ever decide to make a "pro" version.. there are more commodity based hardware oems that wouldn't require them to purchase in the crazy quantities that these China based factories require... I had an oem device manufactured before and the company would brand (silk screen) / build / flash firmware / and ship direct to the customer on an individual basis .. In theory that could help make the business model more palatable.. They could just add an appropriate markup to the oem's costs and then they wouldn't be out anything if they don't sell in large quantities..
Now.. that is based on a lot of assumptions on what is going on under the hood.. If the software is not easily portable between cpu architectures, this may not be a viable option..
I'd be happy with a z-wave routing tool and a better DB -- I don't know what they are using, maybe sqlite3 ? But it does seem to lock up fairly easy but the memory resource leak from what I gather is mostly related to the current dashboard code now.
Memory Resource leaks has always been the enemy of every OS out there.
I wifi option for the hub would be really nice !
H2.. a Java SQL DB
3 Likes
Don't focus on Memory.. it's a Resource Leak. Memory is ONE resource, not the only. Resources are often protected by semaphores. A fail in the semaphore can cause deadly embrace, but there are a ton of other ways that just give grief in new and exciting ways.
2 Likes
@JasonJoel I think it suits as a device controller for you, and i'd say that you certainly seem to be more in the market segment where custom solutions like Hass.io+NodeRed+MQTT sits, and with you're ability to run any hardware you like and your skill set I'd certainly say that it makes sense for you. I don't think Hubitat is a device targeted at that space (mostly), though I'd certainly admit that the HA market has some very odd target spaces with a lot of grey zones between.
I'm a system administrator at work and honestly couldn't be bothered to host stuff at home. I think when @bravenel says that he doesn't see a market for that, I don't think that means that the hardware will never incrementally improve, rather that the capacity to market something (at a higher price point) in Hubitat's current segment (given say the Smartthings price point for example) is not likely worth it or feasible (in their eyes). I can certainly see a C-7, C-9 or something down the track that has an extra 1gb of ram or maybe 16gb flash (which would likely make some of the heavier custom uses more feasible), but those features won't be the point of the device and likely will only be there because the cost differential between the mainboards has shrunk to non-existance.
If the underlying architecture isn't matured though, those extra resources won't provide much benefit to platform stability as even extra memory can be consumed by a resource leak for example, would just take fractionally longer.
-
UI Framework: Another additional suggestion for improvement would be the UI Framework in use by the hub. There are obviously a lot of quirks (that we've mostly got used to) that is prohibitive for new users in the Iris/Wink/Smartthings segment.
-
Drivers with Event Subscription Filter: Given the event subscription model for execution, unsure if it would be feasible or not for drivers to have options for users to switch off the events they're not interested in subscribing to at all. Especially with so many multi-sensor devices. I may not need temp events from my window contact sensor for example, so why not tell the driver to not add those events to the queue and therefore not require writing them to the database. Unsure if this would have any beneficial impact to performance, but just thought that if I don't care about an event, why not turn it off.
Of course, no doubt when there are new hub models with small increments in ram/cpu/flash there will be those that will continue to add more and more hubs. I swear some of you will end up with more Hubitat hubs then you do light switches. 
Cheers,
Glenn.
6 Likes
I'm thinking it's on the Z-radio mesh anyway and that's the resource that is 'at capacity'. By that I mean, for any given transaction, we'd like to think the Z-Radios are either trying to get a packet out, or receiving one.
I know that the half duplex nature means it's actually impossible, but I'm ignoring the gap between send and wait for reply. By having multiple hubs, I get to use that gap. Hub1 sends, then waits.. dead air.. and into that dead air, Hub 2 sends. They are different meshes, using the same "radio air."
Fair points. Turning off events was more a database stability idea though. I/O is always a bottleneck for every platform, so if you don't have to write an event to DB then that might help in that part of the equation.
Radio bottlenecks and limitations of the protocols are certainly another issue, and maybe radio improvements could be made as well. 
1 Like
Close.. I have 100+ devices on 2 Hubs. Yes, I have an idea to use another to split again. I'm really curious about improved response time. Not improving the BEST but reducing the max response.
I have reason to think I'm at the point of diminishing returns.. but I'd like to know that. 
Seems to me on a different thread the tipping point was 7!
1 Like
Then I have a ways to go.. perfect.. there are rooms in this house that don't yet have a Hub mounted on a wall, in a frame, with an overhead spot. 
(joking)
2 Likes
Haha. Describes me perfectly as well 
1 Like
Or an option to turn off ALL non-essential database writes, including events, logging, etc ..... there's probably a fair few users now that are using other logging and event systems via the maker api / mqtt / web socket / etc.
I read somewhere that the last 1000 events are kept for everything? That's a lot of database writes ..... just one Aeotec MS6 sensor for example would generate many thousands of writes .... now times by a few hundred devices and that's a lot of potential for database corruption, not to mention flash wear.
