Hubitat Elevation

#148

I have converted a few of my Motion Lighting and RM rules BACK into pistons because there is very little predicting what those apps will do. I’ve found that as long as you keep an eye on your pistons and don’t let them get out of control, there really is no negative impact on your hub. I think the people who were having problems early on actually had poorly designed pistons that were surviving in ST because of the cloud nature of them. But their poor little hub just couldn’t do it on it’s own. So far everything is going perfectly.

#149

I’m going slow converting mine back and so far they are running really well and fast.

#150

I have converted all my pistons to RM Rules.
I have only paused them though so it’s easy for me to jump back and forth between the the 2 systems.

#151

Yeah, webcore looks like it works on hubitat… until you spend about 150 hours trying to get it dialed in, only to realize it will NEVER work reliably. F8CK ME.

By what freaky magic does this process run?How can it get itself poisoned in such a way that you can’t effing clear it up or restart it? Even restarting the hubitat doesn’t fix a broken webcore. Your only option is to restore from a backup?

#152

The only time i have a issue with WC on HE is when I have to many devices selected (ones i don’t need pistons for) or if i have a dodgy piston that i’ve removed the device from or just have it set up wrong and haven’t cleaned up the app. once this is done you shouldn’t have a issue :slight_smile:

#153

I’m convinced one of the big problems is Global Variables. If you have a global variable as a trigger in a piston, if ANY global variable changes, that piston is re-evaluated to see if it is affected by the change. Which makes sense. Now, I never really had any slow-downs or lockups with HE and webCoRE but I went through and eliminated all the Global Variables that I could and I’m convinced the hub is running smoother. I can see in the logs I don’t have all these pistons running for absolutely no good reason. Maybe in the ST cloud this didn’t matter but when everything is being processed by your own hub, there’s no one to “borrow” resources from for a couple minutes.

#154

Yeah I was getting pretty frustrated last night as my hubitat performance kept degrading. It’s not just wecore that degrades either, its the entire hub. This seems to be triggered by webcore somehow, but it breaks everything in very subtle ways. The whole hub gets slower, the UI for both webcore and hubitat gets slow. Automations get slow and hubitat starts dropping events and devices start missing commands.

This broken-ness seems durable across restarts too, so it’s not ephemeral data that’s being corrupted. In the end I gave up and restored the hub from a backup. The UI got 5x faster, and all my automations started working quickly again. In fact webcore automations seem just as fast as rule machine ones when everything is working properly.

I agree that @globals are some element of the problem, but I think that adding/removing devices from the webcore app causes some kind of corruption. Everytime I add a new device everything gets slower. It looks to me like I can add a new device however, then restore the hubitat database, and my new device is still present AND my hub is fast again. I haven’t tested this too extensively though.

#156

I’m nearly 100% certain that adding/removing devices to webcore corrupts something. As soon as I change any devices at all I see a lot of:

Sorry an error occurred while retrieving the piston data.

#157

I’ve had no problems adding/removing devices from webCoRE. Remember the dashboard is just the editor. That being said, you should not remove a device that is part of a piston. Before removing a device, you should remove it from all automations it might be included in. There’s no predicting what will happen if you don’t. That’s just a standard recommendation.

#158

I can’t say what’s happening exactly because hubitat is literally a black box, and I did this all late at night and didn’t take extensive notes, but sometimes when I add/remove a device from the webcore app the whole hubitat hub gets slower. I’m not talking about adding/removing devices from a piston in the webcore editor, but sharing devices with webcore via the Settings in the App on Hubitat. When I do this I see a ton of those “Sorry an error occurred while retrieving the piston data” messages shorty afterwards when trying to load my pistons in the editor. The last time I removed a device I got a ton of those errors, but clearing the data cache and doing a rebuild seems to have restored performance. This hasn’t always been the case.

It’s important to note that when things go to sh*t, performance of the WHOLE hub seems to slow, not just of webcore. Piston loading between the gui and the hub is slower too, but so is the hubitat UI and actual event processing. This slowness is durable across reboots. The only way I was able to fix it was by restoring from a backup.

I haven’t tested this extensively, but it seemed that even after restoring hubitat from a backup, devices I’d added since that backup were still there. That sort of makes sense if the devices are in fact paired with the stick. I had to re-share those to webcore and that seemed to work ok, that is I didn’t see any further corruption at that point.

One last data point. I’m running hubitat 2.0, and when I was seeing the worst performance it appears (judging by the names that hubitat gives backups) that I was running the 2.0 version of the DB as well. The backup that I restored from was from 1.1.7.120, however. So now it seems (again judging by the names that hubitat gives backups), that I’m running the 2.0 gui with a 1.1.7 database and my performance has been restored to acceptable levels.

Did the 1.1.7.120 rollback do that? Hard to say, but I like it and I’m not messing with it.

I really wish I knew what “DB” meant in the hubitat context. Does anybody know what product they’re using under the hood?

#159

Yeah I’ve about had enough of hubitat.

The reality of migration from ST to it is you’re worse off not better off. The thing has broken in some new way every single day for a month. It seems like whatever bug I’m running into is probably fairly trivial because things largely work… until they don’t.

If this is a webcore bug, somehow its able to corrupt the entire hubitat system, which makes me wonder about an architecture that’s unable to isolate applications. Yeah Rule Machine, but I have absolutely zero interest in Rule Machine. What good is an app that is “stable” but can’t do the things I want to do?

I am absolutely SICK TO DEATH of blindly of clicking on stuff and hoping for the best. I’m just incredibly disappointed and ready to give up and find another architecture that I can actually work on. I’m going to start looking at OpenHAB or homeseer.

#160

I must admit I love webCoRE and had everything running on it.
I started to get issues and was advised to try using the native HE apps or custom apps.
I find RM not as straight forward as WC but once I started to use it I found that I could put 85% of my pistons on it because they were relatively simple.
The remaining 15% took some thinking about but I finally managed to get everything off of WC. It could be that you have some pretty complex pistons that cannot go on RM, I don’t know, but first it might be worth migrating across your simpler stuff and see if it helps.
Just a thought from a big, big, BIG WC fan.

#161

Post has gone in twice for some reason.

#162

What’s galling is that WebCoRE is 95% there, but we in the community don’t have the tools to fix what appears to be a remaining fatal bug.

#163

I’m considering moving to Hubitat. Mainly because I finally have a functioning PC in the house again lol

But I’ve now got so many of my automations running on Webcore that I’m somewhat attached to it. And seeing the issues in this thread and other areas has me a bit leery.

It all kinda shows why the original Smartthings team sold out to Samsung. I’d hate to make a move of this magnitude, only to find myself either hung out to dry or bound yet again to a large company with crappy customer service. Then again, at some point in the next many months or so Samsung will force us all into the new smartthings, at which point it’s clear that many of my most useful automations (such as presence unlocking my smart lock) will be destroyed anyway.

Tough decisions ahead.

#164

Well, I’m already in that hung out to dry position so I suppose I’m going to go ahead and try to patch WebCoRE on hubitat myself, just enough to be able to disable pistons on reboot. This ought to enable a bit faster recovery when things do go south.

@Ryan780 I’ve been watching the logs and see what you mean about globals…

#165

They are bad news! Ever since I got rid of all of them, running like a top. I’ve been telling anyone who’ll listen, if you get rid of globals, you will eliminate your lock up.
There already is a setting to disable all pistons in settings btw.
And the reason people are having trouble at boot is because a whole mess of global variables are being updated. And every time one is, every piston is evaluated. Do the math on that one. It HELLA HUGE! But unfortunately, it doesn’t seem like anyone was listening, before you. :grin:

#166

That disable all setting isn’t the same… it looks like they’re all still processing events, just no actions. I want to pause all pistons on startup.

#167

Ok, so I’m not yet in Hubitat. But I want to understand this firmly as part of my decision process in whether to make the move.

I have a global variable called “ALL WINDOWS”. I use it to report on whether any windows are open.
But I don’t use the variable as the trigger. My piston says “if garage and front door have both been opened within the past minute, then it looks like you might be leaving the house - so I’m checking to see which windows are open. Here they are:” and it proceeds to tell me which ones remain open.

So hypothetically, including a new window in that variable should affect nothing. Because WC has no reason to check/update it unless the piston is executing.

What am I missing?

#168

Why would you have that as a global variable in the first place? If it’s not used by another piston, there’s no reason it shouldn’t be a local variable to that piston.
But yes, if you aren’t using a global variable as a condition or a restriction or a trigger, then no, you wouldn’t run into this problem.
However, typically global variable are used to carry info from one piston to another so that some other action can be taken.
However, let’s say that you had some other global variable defined as a trigger for a different piston. If you change this variable, that other piston would be reevaluated when you set this variable. Every time you set this variable. Trust me, I’ve seen the logs. I had 35 piston executions when it should have been one. But don’t take my word for it.
But I do advise you to read all the posts on webCoRE on the Hubitat forum.