They are! The devs have already traced down 1 of 2 resource leaks, and i am fairly certain i read of several other fixes coming as well in the next update. Browse some other topics for more details on those issues and their fix status.
3 Likes
Let me fix that for you....
The devs have already traced down 1 of
2at least 1 resource leaks
ah well i believe it was mike who yesterday said you were looking into a second one. Kinda hard to keep up when all the info gets spread through 1000 threads lol
It was Bruce..., And he stated:
Which means they have found and verified one... So there was "at least one"... which is more accurate that a specific number "2", as they are testing another... because they suspect they are narrowing down another.... But, because they are hard to find, there is no assurance that there are not any others...
Don't get me wrong... I applaud their efforts to find these leaks and bugs... But with the number of posts (1000 is probably an exaggeration) with slowdowns, and support telling the user that there are errors in the logs (logs that are not available to users developing apps and drivers)... I suspect that there could possibly be more (just speculation based on the number of different error being reported)...
As far as the hidden errors are concerned... The logs are only available to Hubitat... If I, or any other code developer, write code, we can only find and eliminate bugs that generate errors in the logs that we are able to access... I did have a segment of code that (I assume) had a hidden error... It manifest itself as the function terminating unexpectedly with absolutely no indication of an error... After days of trying to figure out the problem, the code was deleted and started over from scratch... The fact is that Hubitat support will tell the user that there is an error, blame it on "user code" and do absolutely noting else... They don't send a PM to the app developer to say they are seeing a problem that MAY be caused by the developers code and provide details and log extracts... It remains a lurking issue until the user posts in the forum and the app developer happens upon it..., and can do absolutely nothing because there is not enough info...
Hubitat takes the stance (and rightly so) that user developed code is not supported by Hubitat. However, when there are issues that Hubitat is hiding from developers, then the responsibility is on them.
Sorry for the segue... but someone needed to say it in public....
2 Likes
FALSE.
I know, I've gotten those messages.
5 Likes
I have found several threads (that I can remember) that referenced these hidden error in code that I developed/was involved in, and have never received ANY contact from Hubitat.
I agree.
Also how do you support it.
As a user, you get an issue and send a ticket into HE.
What machine are you running the software on. Windows 95 (I know I'm just making a point). Are HE supposed to write a software package for all eventualities? Totally impractical.
We've already had one person on the forum demanding that HE release their code so he/she can modify it.
You have to search the internet and I bet you can find a hacked version of just about anything.
Just because it's licensed doesn't mean people won't do it. They will.
If I was running HE I would carry on as they are and protect their revenue stream.
Just my twopence worth.
Now, what automation can I fiddle with today.
3 Likes
This reflects a misunderstanding about "hidden" errors. We are not "hiding" anything. There are internal logs that have no value to users or developers (this you will have to take my word for). I can tell you, as probably the most prolific developer for Hubitat, the I can count on one hand how many times the "hidden" logs have been of help in finding a bug in the code I work on. We put in place mechanisms to report bugs that originate in apps and drivers into the Logs that the user or developer sees. This covers over 99% of all errors an app can throw. Within the remaining 1% are some bugs that don't show in the internal logs either, mystery failures if you will. These are tough to figure out for a new developer, and one must be very suspicious of whatever new code was added when this happens, which is very rare. Also within the 1% are errors that do leave some trace in the internal logs. Given the exercise that we've done to show app and driver errors in Logs, in almost every case what is in the internal logs is not very helpful if at all. I run into this once in a blue moon, and again, figuring out the problem entails typical coding sleuth work, introducing log.debug into the code, and isolating the point of failure pretty much by hand.
So if support says there are errors in the internal logs, that does not mean that there is useful information that we are withholding. More likely, there is some error that is in and of itself inscrutable. If the error was associated with an identifiable line of code, it would be in Logs. Otherwise, the developer still has the means at hand to debug their own code.
Please understand that we haven't focused our efforts on creating a development environment. We put our efforts into creating a home automation platform upon which development is possible. User development of apps and drivers is not, nor is it likely to become, a primary focus for the product. But, having that ability is certainly a powerful addition to the platform. It's not perfect by any means. But observe that every app and driver for Hubitat Elevation was developed in this environment, and as I said above, this development does not use or rely on "hidden" logs.
12 Likes
This is, at least for me, where the main value is... But also a potential detriment if used improperly... That’s why I bought a development hub, so I can test my code without affecting my production hub...
Properly written groovy code is crazy fast on this platform..
And serious kudos to HE because the development environment is more advanced (although less documented) than ST.. I’m not talking IDE, I’m talking about the classes, data types, etc, the real guts...
I just wish I could see enough of the innards to be able to help document.. But I totally understand the need to keep tight sandboxing...
4 Likes
1 more rant and then I’ll get off my soap box...
I think it’s ludicrous to expect HE to support every device and code running on their platform.. HE makes the hub and this wonderful software platform.. They don’t make these devices.. I only expect HE to support the hub hardware and the underlying software platform (the bits we don’t have access to) .. Everything else is for me to fix, and we are provided the logging utilities to identify and fix our issues.. So far I have been able to identify and fix every issue and slow down I have had, and it hasn’t been platform related..
5 Likes
I hope I didn't offend anyone with my rants above.. This is how I feel and in no way represents HE's official views, as I in no way represent HE..
4 Likes
The problem with a "check in" scenario is it makes you somewhat cloud dependent again.
1 Like
Me too when one of my drivers was causing a loop I had missed.
@bobbyD sent me a pm so I was aware of it (I fixed it in 5mins)
Andy
3 Likes
Wonder if this exhibits itself exactly the same across all installed platforms or if perhaps unique usage
& "leak creep" speed might help isolate it.
Might there be some optional system health & module usage data collection put into an interim release that could allow the community to help you guys narrow down the suspect part of the system?
He says nievely. 
so here is what I see.. I understand the CPU is not a constraint due to the serial connections of the devices, but not everything on my hub is limited by serial connection. Wifi devices I think are faster (I could be wrong) Perhaps Web connections are slowed by the CPU.
What about memory, I know there are a whole bunch of people here that have issues with slow downs once a week or day. Hell I have to reboot mine every day, cause there seems to be an app or two that are slowing my roll every day. Perhaps more memory will help that, perhaps they need to clean up the code when handling the other code. IDK, I'm not a programmer.
but I will tell you this, I have been a little dissapointed on the web interface, it seems a bit slugish from time to time. Could be me.
Forget the pro edition, I think they need to just clean it up a little, and in time I am sure it will.
Let me also say this, I would like a cleaner more "pretty" interface, and that WOULD need more memory and CPU I bet.
and Last, since I know Im ranting a bit, why do some users use two hubs to offload one for the other. this would save us if there was a pro version.
This almost always has to do with radio load (separate Zigbee networks, for example), or development vs production (risk management). Neither of those would benefit from a "performance" edition hub.
It is certainly possible to drown a hub with http requests. But if you are designing a system yourself why would you do that? Why would you design it that way? This is a home automation hub, not a universal home processor to do everything you can dream up.
A cleaner and prettier UI would not need more memory or CPU, just lots of engineering effort. On our list to do, but not near term.
4 Likes
I'm mostly spitballing here, but perhaps that's what a "performance edition" could be, instead? Bumping up the specs just enough (with an equivalent price-point) so that common things like HomeBridge, mqtt server, or other related daemons could be installed without folks having to set up and manage a separate environment.
Give people enough rope to have an all-in-one device, but keep that part community-supported.
1 Like
I think this is the most "bell ringing" statement I've read in many weeks...
The dream we each, typically individually, occasionally family wide, have for Home automation is ours to implement. If you want 500 devices on a Single Hub, you probably CAN do it, but it probably means an intense effort to squeeze out every nuance of the Platform. (I'm assuming a 'modern' mix of devices.. 500 Door sensors wouldn't require much effort. 
)
For me, I picked the multiple hub path because MY criteria demands quick, predictable response. I didn't like having variability in a specific light coming on. I focused MY design to meet that very personal requirement.
I have 100+ "Real" devices and certainly that many virtual devices.. and 20+ items in the Unused Box that I can't find a use for. If I HAD to scale to 500 devices, I'd use this same design. just "wider" via more hubs. I doubt I'd even explore putting 200 devices on a Hub, I'd go straight to Two. But again, I emphasize, that's ME, what I have and would choose. And if that design failed ME, I'd have to invent another 
It's One System with various parts. They are in no way "separate" - they are joined. I consider each hub to be one module of the whole. I don't have a working system if my Lutron SmartBridge PRO fails. We already know that Lutron is unwilling to license their radio product for internal integration. I do not see how that externalization of the Radio is different from a 2nd Hubitat Hub for ZWave or Zigbee. Or a Hue Hub for Bulbs... or.. or.. (etc.) I am completely satisfied with the modular approach because any failure affects only one slice of my total system.
1 Like
So what is the most real devices z-wave zigbee managed to get working smoothly on ONE hub??
I really don't think a 'high water mark' number is what you're looking for...
500 door sensors wouldn't be a problem I predict. They are almost dead quiet their entire (battery) life.
I would hesitate to put 2 HEM (power reporting) devices on a Hub. They are able to be very chatty.
Thus my '100+ devices' with quite a few multi sensors sending temps and RH and Lux and UV reports all day/night might be equivalent to 260 Door Sensors 
