Nah, Chuck's not old -- just me.
1 Like
Then there are those (with company backing) that are watching and waiting for a mechanism like an "App Store" to distribute code because some integrations can't be source distributed due to licenses and internal keys necessary for the API access. I have had this discussion with Hubitat staff before.
1 Like
@bravenel - sorry - this is properly interesting to me, and I'm at risk of exposing my lack of understanding, but the hub failures I see have all the smell of resource exhaustion - if we're java based, then it's probably heap exhaustion. Are you telling me that you guys don't even find things like being able to monitor heap free, or used memory for the process, etc, isn't relevant when you're trying to troubleshoot problems? If it was our guys java code, the first thing they'd be doing would be to grab all the performance metrics they could, and knowing them, they'd probably build a quick rig to kick the hell out of certain processes and see if the leaks came from there.
From my personal position, I've written a few drivers (and I definately fit into the 'build it to suit my requirements, and release it because why wouldn't somebody benefit from it' camp. It's ENTIRELY possible that I'm doing something daft - it's not like groovy is a language I'd ever had cause to play with before. So it's entirely possible that I'm crashing people's hubs, by extension. I'm not a complete git, though, so if I had any useful instrumentation that I could use to work out if my code is leaking resources, then I'd use it, and do my best to isolate the problem. As it stands, though, I've no way of knowing even IF I'm a bad actor, let alone how.
If, genuinely, though, there's no way of knowing this, bar some nebulous 'know more and be better' sort of capability, then I'd say that THAT is the core limitation we're talking about.
Anyway... I'm rather with @JasonJoelOld on this - these are the limitations - they're not ideal - but we're still here, and we're still using it all. I guess my only spin on it is if there ARE opportunities for us to do things less wrong by being pointed in the right direction, then we'd do them less wrong, and maybe we'd all win a bit.
-- Jules
6 Likes
I'm pretty much at a loss for this: We've implemented dozens of major apps and hundreds of drivers and NEVER have encountered these problems of "hub failures". I can't possibly begin to make suggestions about what might be the cause of this. You and others seem to think that IF ONLY we had better diagnostic tools for developers, that these problems would magically go away. I don't buy that for a minute. At the risk of sounding arrogant, what is needed is writing good code that the author is diligent about testing and understanding completely. Those who do that do not need additional diagnostic tools.
This isn't a platform built for developers, or designed to solve their problems, nor do we see it going in that direction. This is a home automation platform that happens to allow people to write their own code, at their own risk. Given that we are dependent ourselves on the platform stability and the same tools available to users to implement the apps and drivers made available on Hubitat Elevation, we are pretty sensitive to its foibles. It is for these reasons that the pleas for better development tools fall on deaf ears -- we don't need more tools ourselves, so why should you? Granted, if this were intended to be a development platform we might have a different attitude. But it's not.
It may not be obvious, but the existence of community created apps and drivers is not a huge selling point causing droves of people to purchase our product who wouldn't otherwise. The vast majority of our customers are not developers, have no interest in developing anything, are not purchasing because of Cobra's apps, or because of someone's custom driver that exposes something the built-in driver does not. Some will argue that we're being short sighted by not putting more investment into supporting developers with things they want that go beyond what we know to be needed to do good development work. But they are not sitting where we are faced with the marketing challenge of expanding the appeal of home automation to people who could care less about any of this, and just want something easy to set up. Consequently, our efforts are focused on that challenge, not on the desires of developers.
I'm sorry if this is a disappointment to you.
9 Likes
Here I completely disagree with you!
I bet there isn't many users that doesn't not have at least a custom driver or app. That only uses built in apps or drivers.
Obviously I only have the barometer of this forum.
I believe people are going with HE for two reasons local processing AND the integration capability for their sensors either with Stock or Community apps.
Remove the community code capability and see how many is your user traction.
This is just my opinion so take it as that. Just my 2 cents.
Out of curiosity do you even have hard metrics in how many devices use HE and what brand are used?
Those people are not writing code, those people do not know how to write code, those people do not know how to debug code. If you want to talk about developers there are very few people who know how to develop on this platform. There are 2 different discussions going on in this thread and people seem to be confusing "support" with available. Yes writing your own code is available and we will not remove that feature, what we are talking about is sending an email to support and asking them to fix your broken code and your broken hub because of custom code that you put on it. That is what we mean by not supported.
No Chuck....
This is what you guys simply don't get it....
What people are asking, for the developers, are better debugging tools, sample examples of code that run flawless..
They are not asking for you guys to debug the code or fix it.
They want means to understand why their code is breaking and why, what is breaking and how.
If they can't see how their code is affecting the system how can they even start pinpoint the problem? They are running blind.
They are asking for an opportunity to fix it themselves and not call support...
So quite the opposite of your guys interpretation.
Don't forget as you guys built the system you have a view that community developers don't have, you know what processes run and how they run.. you can even use the same tools but you simply have advanced knowledge that they don't have or is shared with them.
I had one last week. I wrote in and was told that three apps on my hub (InfluxDB Logger, Other Hub Event Pusher, and Alexa TTS Manager) were known to "lock hubs at times".
Has anyone tried to figure out why these apps are known bad actors?
You simply don't know what you are talking about.
C'mon, seriously?!
You simply don't get it...
2 Likes
Yeah, I hear this all the time.. I want code that is written for me and then I want to do little tweaks. I'm sorry that does not make you a developer. I hope I'm not insulting anyone, but if you don't know what you are doing, adding more information into the mix is not going to help you it is only going to confuse you. Do you know what to do with a heap dump? can you ananlyze thread dumps? Do you know how to profile Java applications? If so, please PM me and we'll get you a contract for employment.
Really?! You are using you personal assumption of what you consider a a developer tweaked by your own interpretation of what a developer should be.
I also think you should edit the last bit as I want to believe this is not your view.
But it reads that you are assuming that when you share Knowledge with others you are confusing people what is really calling people dumb. What is quite arrogant in my opinion.
How do you know the developers here don't?
On a side note: if you struggle with Senior Java developers and don't mind that they work remotely from anywhere in the world I might have a few contacts in Oracle.
Comic relief for the morning.... 
Afternoon here 
I'm going to have to assume there is different ways of interpreting what I said. I have to admit most of the time when I read your comments they come across as arrogant and I've been told I'm misinterpreting you. ie "This is what you guys simply don't get it...." Until you've actually done this you have no idea how misleading all that information can be. If you read way back up in this thread you'll see that I have had to use experts in the past for this sort of thing. It is not something that can easily be interpreted and is very often misunderstood. I have never worked with a developer skilled in profiling, that has always been something that was contracted out, they are a very rare bird.
Thats why I put that out there.. if they do they can contact me.
InfluxDB and Other Hub Event Pusher are both simply pushing out a lot of data (especially on high device hubs). For someone with say, 10 devices, I doubt their hubs ever lock up due to this. But, on my hub, where I'm starting to push 150+ devices (and will be well over 200 in the next couple of weeks), I can see the traffic going nuts just using my external monitoring scripts. I know for a fact that I can load the InfluxDB app and lock up/slow down my hub easily because of how much I'm asking a single board computer to do. Want to see what your hub is doing traffic wise? Simply monitor the websockets and see how much traffic is being pushed out. It'll give you a good perspective of what the hub is doing.
As for AlexaTTS, I've never seen it lock up a hub. I've seen it fail on cookie grabbing, but, it's never locked up my hub.
Think about it like this. These are single board computers with limited resources handling hundreds of threads, timers, event stacks, objects, logging, etc. Then, we throw something that pushes the internals even harder and relies on external resources and wonder why the hub gets slow or locks up?
1 Like
And quite expensive... I know lol.
This should not come as a surprise to anyone who came from SmartThings. They have repeatedly mentioned this in their community. I recall Alex or some other staff at one point stated that the active members of their forum represent less than 1% of their entire market.
There is no reason to think Hubitat market metrics are all that much different.
Pure speculation. No disrespect intended but you don't even remotely come close to having the necessary data to draw that conclusion.
SmartThings staffers have also mentioned that only a fraction of their user base ever install an app or driver. Again, no reason to believe those metrics are all that much different here.
Bruce has stated that they use the same dev environment that we do. I have no reason to discount what he says. Not that I disagree with you either. What tools would you like to see and how do you believe they will help?
I agree with the premise of writing good code to start with. I "grew up" writing C for programs running on 286's. I learned the value of clean, streamlined code, the need for code optimization, and compiler optimization tricks. We don't have to deal with any of these things now. That's both good and bad, as it makes it very easy to write crap code.
But seriously, and no disrespect intended to anyone by this.. When people are asking how to write an app that works in both Hubitat and SmartThings, that by the very definition, is not considered "good code" since it's already been bloated with logic to perform platform checks and is further bloated by code that will never execute.
Point is, I can see both sides argument, and in my opinion both are valid. However, I must agree with the Hubitat team on this one.
7 Likes
