It is pretty easy - use "pushed" and "held" properties for press up and down accordingly. See5j8oz piston for an example
Thanks, I'll try this. I think the fact that I can't see "button" in the logic is what has mentally got me stuck.
Hi All,
I recently updated to the latest verion of webcore. Not sure if it is coinsidence, but I am now unable to backup my pistons. Webcore responds with an error saying to make sure my security tokens are not expired. I have tried both Reset Access Token & Clear All Security Tokens both without success. I have even logged out to Re-Register my browser.
When I check the logs, I am receiving multiple Backup Too Big responses.
Anyone experience this or have any ideas I can try to troubleshoot?
Thanks
Seeing the logs would be good (private message may be appropriate).
HE has a restriction on max data that can be sent in a message.
Having HE backups does backup all your pistons.
I also noticed an issue with trying to backup more than 48 pistons. The backup would run until it hit the “40 of 48” and then it would abort. Once I deleted several old and paused pistons that I wasn’t actively using, I was able to succesfully backup all of the pistons without an error.
Do note:
Specifically the section on Piston Backups
I've been dealing with this for awhile. It isn't the number of pistons but the total size of those pistons combined. It's not really a bug per se but a limitation set on the HE platform. You just have to make your piston backups in smaller groups..
Interesting- thanks for the info.
I have a silly question.
Why would somebody use webcore which requires the Internet to run automation when they can use rule machine which is local?
webcore does not require internet to run. (see notes 1 and 2 of this thread).
I view webcore has much better development, debug, performance and tracing tools.
It makes it easy to share automations across hubs or between users.
It has a richer programming environment.
It makes it easier for ST users to come over to HE, which can only benefit HE.
11 Likes
100% agree with all the nh.schottfam points. Webcore was also easier to understand for me considering my developer background when it looks like Rule Engine was designed in a way people without dev experience could use it.
All of this. And (at least for my use) webCoRE performs faster and better than Rule Machine. Since I converted all my rules to WebCoRE pistons, I can now get five days of good performance from my hub between reboots. Using Rule Machine, my hub required rebooting every couple of days.
How much faster ?
How fast is a typical motion lighting piston?
It is hard to judge rule or motion lighting as they don't provide performance data. The nearest approximation is to turn on logging for them (which inherently will slow them down more)....
webCoRE provides performance data without having to enable logging (which of course you can), and it shows where the time is spent for each statement.
Here is a snippet, this can be enabled for any piston in the webcore dashboard for the piston by enabling trace.
small pistons on my system (I have 100s of pistons due to testing), run typically under 10ms
I just did a test. This looks damn awesome.
However, the hub processor power is still a factor on turning a light on. Since the hub actually processes the request that webcore tells it to do. Of course
300-400ms lighting. This is pretty good. However this doesn’t include the kind of conditions I do. Which typically include 3-5 conditions and sometimes much more. Plus multiple rules/events doing all this.
My solution (Homeseer) is still much faster. Why, because it’s a dedicated Xeon server. It gives me that instant lighting I’m looking for.
Webcore still looks awesome.
the first time webCoRE runs a piston (or first time after a reboot), it is slower as things have to get initialized. Subsequent runs will be very fast and do a lot to avoid accessing state on HE which is slow (as is logging).
webCoRE can log for the IDE without having to use the HE logging system. This logging does use state in HE which is does slow things down. HE actually has a fair amount of compute, it is its storage /state that is slow. clearly not a xeon with ssd....
Like anything on HE, webCoRE calls the device handlers, so their performance does matter. webCoRE will show you how they respond so you can understand where time is spent. calling device handlers less is a good thing. I find many with logging off are faster than with logging on.
Take these results with the appropriate grain of salt as they reflect my use case-- as they say, your mileage may vary:
Several months ago (using a less optimized version of WebCoRE than the current one) I ran several trials on my C3 hub comparing the time taken for a trivial RM4 rule vs. WebCoRE piston to toggle a virtual switch, triggering that VS manually from the UI device page. In the absence of rule logging I looked at the device 'Event' page on/off times of the VS and used that as the basis for comparison. Of course the times are affected by what else is running on the hub-- I did comparisons with all other automations enabled and disabled; still that doesn't account for other scheduled processes the OS is running at a given point in time. But aside from a couple of outliers, the trivial WebCoRE piston consistently outperformed the equivalent RM4 rule. Enabling other apps on the hub and repeating the trials showed similar results.
Performing trials with a physical (Zigbee) switch rather than virtual switch showed no winner, not surprising since the time taken to activate a radio controlled switch by either RM4 or WC is the dominant factor in the comparison. Adding a little more complexity to the virtual switch scenario (with a rule/piston testing a day of week condition and then using that to trigger another rule/piston) showed that in no case did RM4 perform as well as WebCoRE.
These are the times I recorded. Not a rigorous benchmark, but enough to convince me that I wasn't wrong in my perception that WebCoRE isn't hurting my hub's performance.
6 Likes
Your hub still requires rebooting.
Do you still have rule machine installed?
Better yet have you considered doing everything in webcore and not using any other app? I would be curious if your hub still requires reboots ?
I still have RM installed; as I migrated from rules to WC pistons I disabled the migrated rule (using the disable checkbox). I pretty much implemented each rule as a corresponding piston so I could easily back out if things didn't go well. It also made performance comparisons (and uptime-before-required-reboot comparisons) easier. l'm running now (and have been for roughly 6 weeks) with all rules disabled.
So I'm running roughly 133 fairly uncomplicated pistons, and a few dozen Simple Lighting and Button Controller apps (ST handles my Echo integration and ActionTiles dashboards via HubConnect) along with the indispensable Hub Watchdog app from @bptworld. Everything runs consistently well, with very good performance... until it eventually doesn't. The hub still requires periodic rebooting. I monitor virtual switch delays and have a piston automatically reboot the hub during off hours based on median and max delay thresholds of the monitored virtual switch. Otherwise I'll start to see sporadic timed automation failures, seemingly random errors pop up in the log, and device delays.
My current RM-free setup will run consistently for 5 days before delay thresholds in the piston force a reboot; I set the thresholds low enough so that the hub gets rebooted before performance degradation becomes noticeable . With RM automations enabled, I get only 36 to 60 hours of good performance before things start heading south. I've repeated the RM/WebCoRE swap enough times with the same results to feel confident that it is not just a fluke, however my results maybe unique to my installation.
I have toyed with the idea of going total WebCoRE just to see how performance would be affected, but I haven't been spending as much time at the keyboard lately. If Fall comes around and there is no progress on the slowdown issues, I may still give it a go.
I use very little to no stock apps, but run webCoRE for pretty much most things. I almost never have to reboot. If I do, it’s normally due to devices themselves rather than apps. That said, I do have two hubs. One running devices, the other running apps via HubConnect (also includes an ST hub for less priority devices/cloud etc).
