Patched webCoRE for Hubitat (2018/09/09)

If i was able to get the backup code, then I might be able to try it. But since I can't access the dashboard to get the backup code, it's a nonstarter.

But no, your pistons are not stored in any way on the server, either your RPi or the WebCoRE cloud servers.

How can you recover them from the backup code if they are not stored on the server,

I believe it is backed up to the cloud server (in ST webCoRE). That's why you're able to restore the green snapshot piston code from someone else's piston. But if i delete the piston, it's gone so there's nothing to restore from.

The restore code also works when you aren't using the cloud endpoint; you can restore a deleted piston from its backup bin code. Obviously, your own piston and not someone else's.

Can you login to the cloud version and select the hub the HE hub? I am assuming that you also had Webcore setup for ST. If so, you might be able to access the HE hub webcore as well. Just throwing this out there. Not sure if it will help.

Then where is it restoring from? And how long are they stored there? I would think this couldn't be kept forever....you'd run out of room eventually. I mean, think of the number of pistons people have written in WebCoRE....it has to be in millions by now.

I assume (but don't quote me) for a local installation the backup bin is on the RPi; that would tend to follow with the ST cloud based stuff being shareable among users. But I confess to not really understanding how it is set up; I just tried it and verified that a deleted piston can be restored on my local setup from its backup code.

Tryed installing on a raspi.. I'm getting problem loading dashboard when use custom endpoints

Okay, now I've gotten back into WebCore but for some reason i have two copies of the Pistons app and I get this error when I go in.

WARNING: Results may be unreliable because the parent app's version (v0.3.10a.20190223) is newer than the child app's version (v0.3.108.20180906). Please consider updating both apps to the same version.

Hi @nh.schottfam,

Will presence also be supported on this?
I've re-installed, yet my Locations in the cloud version aren't being saved, yet the device is being created on HE.

Thx
Roy

Are you using custom endpoints for WebCoRE and a local server or the cloud server?

Updated March 11, 2019

New version

  • Reduces thread usage by pistons significantly
  • Added new functions from latest webcore
  • has HE version number in addition to webcore version

Feb Release:

  • Should be much faster, especially if Parallel execution is turned (left) off for your piston
  • use Async http calls for http commands
  • should fix HSM command issue reported

Note:

  • the piston bin (backup code) is located in state and settings variables for a piston (you can see these in Hubitat dashboard by "Apps" -> select settings gear next to the application /piston.

Here is an updated webcore forked from the original in this thread.

It has quite a few changes, primarily to add pauses into long running pistons so as to not hang the hub.

This version is a bit faster in that a lot of parent/child calls have been removed, and several bugs fixed.

I also removed code for lifx, a lot of comments (that caused problems compiling/saving on hubitat).

While a noble goal to keep the source the same as ST, this is impractical because of sheer code size, and the inherent higher horsepower ST has running in the cloud (Pistons don't compete with each other as much as they do on hubitat).

Pistons that run a long time will automatically "be nice" and release the cpu so other things can run / operate.

As mentioned in other notes, it is a good idea to control your use of:

  • global variables - limit subscriptions (if you use multiple, see if you can subscribe to less variables for a trigger)

  • How many events a piston receives

  • avoid enabling parallel execution in a piston, - this should not be needed as hubitat has much less available CPU than a cloud. (and this is a big hog of hub resources)

  • I suggest you not enable log piston executions in the WebCoRE app as this adds a bit of overhead on the hub and database (this is a webcore setting; not a piston/code setting).

  • Control use of logging, both in code in your piston, and in the dashboard when enabling logging on pistons. It is a good idea to leave it on "none" once you are done debugging to reduce load on the hub and the database. (I have thought about auto turning it down, but that may be a bridge too far for some)

Notes:

  • It is a good idea to reboot your hub before installing, and let it settle the db for a few mins.

  • The storage app is not used on Hubitat, so you can just not bother installing it.

  • You only need fuel stream installed if you enable local fuel streams.

6 Likes

With Presence, you need two installs. I have local end points for webCoRE with pistons, and the presence install you keep via the cloud. I've installed the original version from jp0550 and Presence is working fine. But not with the new version.

If I save a location in the new version, its not being saved.

I have to say I am really excited about all the work being done with this. Thank you so much for all the time and effort!!!

Thinking about adding this back in to my dev hub to see what's up.

1 Like

Can I just install this new version over the old one?

yes, it should be fine.

Good luck with that.
I'll be interested to see how you get on.
I just updated to the latest version , enabled 6 very basic pistons and my hub slowed down.
Just doesn't work for me.

It did not work for me either early on - hub crashes, super slow responding etc so I moved everything to RM (and added another hub etc) and things have been very stable. I am still watching this with interest though. I really like the design interface.

Since I would be putting this on a dev/controller hub the idea/hope is it would not affect my other device hubs except in the case of hub links which I purposefully keep to a minimum.

My view is this...until it's able to handle everything like it did on ST, I'm not going to use it for anything except those functions that I can't get with other functions of HE. By developing a few custom build drivers and a couple apps, I'm down to 1 webcore piston that responds to webcalls containing data.
I've gone through all the trouble of moving everything off webCoRE....no sense it putting it all back at this point unless I absolutely have to or it becomes much faster than the other parts of HE.

Yeah but since it's non-native I don't really have the expectation it will ever be faster than RM. It's just what I was used to with ST but to your point I now have a lot invested in RM/Apps/Drivers etc so am not likely to do a full change over anytime soon.