You tell us that we don't really need any further insight into the box, then a few posts later tells us that the issue with webcore slowing the box down over boots is that the App is still running and starting up in its broken state.
Well, how are we supposed to know that when we have no insight at all into what's happening on the box? No cpu utilization, no memory utilization, no process control?
Hell if that's indeed the case then throw us a bone and give us a switch to disable an App without having to uninstall it. That would go 90% of the way towards mitigating my issues with WebCoRE until a suitable replacement is available.
The bottom line for me is that while you guys may have decided that nobody really needs a migration path from WebCoRE/SmartThings to hubitat, I do! If I have to start over from scratch, there's no particular reason to choose hubitat/Rule Machine over the several competing platforms.
This thread is veering dangerously close to the old trope of developers telling us dumb users that we don't really need what we say we need and to just do it the way you tell us to. That right there is a strategy that never fails to gain acceptance.
I think its unclear how well either supports the zigbee devices I have.
HomeSeer hard to get excited about vb.net scripting. Xtend or whatever OpenHAB calls it looks interesting.
Home Assistant uses yaml. Meh. I've done a lot of yaml "scripting" in Ansible (also driven by yaml) and while you can eventually get the logic to flow like you want, it can get a bit tortured. You're all like, "My kingdom for a case statement!".
What zigbee devices do you have? I have a HomeSeer Linux box that also has Deconz installed with a conbee usb stick for zigbee. Its just ok but very buggy currently. . So I use the Hubitat box for Zigbee currently and use HomeSeer for Z-wave cause it just works.
Ehhh I didn't have any luck adding the Iris Motion Sensor and Iris Contact sensor to Deconz yet. One guy modified the code and got it work but I don't want to modify it every time there is an update.
The vb.net scripting is an option. You can actually use any native scripting the platform supports. I have stuff in vb, shell, python and I pass things around between node-red and HomeSeer and even Hubitat thanks to Maker API
I didn't say what was wrong with webCore. I offered a possible explanation. The answer lies in the code. You have the code, you installed the code, that's all you need to figure it out. There is nothing in the OS that is going to tell you anything about what is wrong with that code. Everything is right there for you to examine.
Examine the code. Put debugging code in it. Figure it out. Quit complaining about the consequences of your choices.
Add Pause code to the source code, like we did to Rule Machine, Motion Lighting, Simple Lighting, etc.
You are free to make any choice you want. We never decided to put webCore on your hub, you did.
No, its veering over the line of someone refusing to take responsibility for installing code that you know nothing about and expecting the vendor to bail you out, when the vendor has made it abundantly clear that this is not within the scope of our responsibility.
In my case, the runaways / hangs have nothing to do with webcore. There are today folks reporting coding mistakes (section() without {}, and there are many others I have run into.
To be clear, the core idea of HE is good. That's why we are here. But developer mistakes should not be so "catastrophic". Yes they are recoverable, but honest mistakes should not be punished so much.
I understand this is new. This feedback is meant to encourage improvements. I do think some rate limiter would clue folks into a problem and stop the problem, then they could investigate vs. spending a lot of time rebooting / recovering and then still trying to find the mistake.
None of these coding mistakes crash the hub. They either throw compile time errors or run-time errors. Excuse me for pointing out that there has been a great deal of code implemented for this platform without crashing of hubs, runaway code, need for reboots, etc.
Are your development efforts having these results? If so, please share with us the code that's causing this problem. Let's deal with real facts, not projections and suppositions.
I appreciate yourself, Mike and others are great coders...
Some of us are still working on it...
In my case of hangs, all were mistakes in code, either in porting something, or writing new. All so far has been mistakes. Just really painful mistakes...
It is hard to know what is the problem when the system locks up and you can't get into the web interface. I take your word they were not crashes, but the net effect is similar.
That's a given, isn't it. Seriously, why don't you share the code that results in a hung hub. Point out the cause, give some guidance to others.
It should probably be made much more clear that we didn't bring this hub to market for the purpose of being a development platform. Hubitat Elevation is a home automation system. Some people prefer or need to use code they develop. We aren't going to devote our resources to making it a better development platform. It is clearly an adequate development platform, or it wouldn't have the variety of built-in apps and drivers that it has, nor the large variety of user developed apps, integrations and drivers. Just look around, there is a lot of evidence that it works for that purpose.
Complaints about it's shortcomings as a development environment are not of much use. Take a poll, find out how many people here want better development support and how many want better home automation support. Irrespective of the desires of a few, our vision is very clear on this -- we are in the home automation business.
thanks to Maker API
Propping it up and then beat it some more, kicking it and asking "are you dead? You're not answering!!" Kick
