Overview
webCoRE provides a rich common programming environment and code sharing across different home automation platforms. webCoRE provides an Integrated Development Environment (IDE), including debug, trace, and performance analysis for developing, testing, monitoring and optimizing your automations. It also has the ability to create dashboards that can be accessed from different locations. webCoRE is one of the few apps that provides both execution and performance information on your automations.
There is a webCoRE community that has many example pistons (automations you write with webCoRE) that can be imported, as well as get questions answered. Tips are also available on using webCoRE and HE efficiently.
-
webCoRE on HE makes it much easier to move your existing automations to HE from SmartThings, and run all your pistons locally on the HE hub.
-
This is the latest port of webCoRE onto the HE platform and has many optimizations for HE.
-
Simple pistons normally execute on HE in less than 10ms (which is a dramatic improvement vs. operations on SmartThings which is commonly > 150ms for the identical piston)
-
webCoRE is integrated with homebridge V2 and Echo Speaks, both of these apps can execute pistons or trigger on piston execution
Current Release Update September 17, 2022
- Fix for un-implemented fuel stream command
- fix for queued commands and tracking trigger operation
- adjust http command handling for 401 responses
- added followRedirects to deal with multiple redirects resulting from a single http request
- added ignoreSSLIssues for internal https requests
- if you have 'full' debug enabled on main webCoRE application, there is now a report of global variables in use (variable with piston list)
- HE console -> apps -> webCoRE -> Settings -> Dump global variables in use
- this is updated as pistons run, so paused pistons will not add to the in-use report
- allow list of numbers to sort, min, max, avg, median, least, most, sum, variance, stdev, count, size
- Many more optimizations
Previous Release Update July 30, 2022
- release of experimental graphing in webcore
- Ability to subscribe to a pistonResume event within a piston that notifies it was resumed.
- if using staging.webcore.co you can now backup all your pistons in single operation from IDE
- bug fixes
- removed time offsetting webcore did on time comparisons (was 2 seconds)
- fixed some time as string parsing and comparison issues reported by folks
- fix for restrictions (only when in your piston) were not properly restricting operation is some cases
- fix for empty $args when executing a piston with arguments
Previous Release Update April 20, 2022
- Improvements to scheduling time event triggers that have time restrictions
- Improvements to Capture attributes and Restore attributes to handle more attribute types and ordering requirements
- added new trigger gets any
- This trigger allows a match on any momentary event value for a device:attribute
Previous Release Update April 2, 2022
Bug fixes:
- HE global set not working properly
- If location events were enabled for piston execution, some notifications generated device not found error
Previous Release Update March 30, 2022
Please note this version only runs with 2.3.1.130 or later of HE firmware (this is the current released version as of today)
Key changes:
- a lot of optimizations and improved Groovy compilation (these are what requires the latest HE version)
- more dashboard improvements from @ipaterson (currently on staging.webcore.co or if you install local dashboards)
- improvements in refresh and updates
- improved logging for pistons when in 'FULL' logging, that timer schedules and cancels have more data on what is being scheduled / cancelled and where in the piston restarts are occurring.
- improvements in else if statement processing that Task Cancelation Policy should correctly be matched to the else if (the bug was it was tied to the if)
- improvements in condition optimizations to deal with condition true/false statements properly when determining optimizations.
- added new file commands for HE hub files (thx to @thebearmay ) for assistance.
- adds commands
-
Write to file
- will create the file if it does not exist
-
Read from file
- file data is put into a system variable $file
-
Append to file
- will create the file if it does not exist
-
Write to file
- adds a new function exists(filename) which returns true/false if a file exists
- files are text files. You can use webCoRE json commands/functions to use other data types
- files are managed in HE console -> Settings -> File Manager
- adds commands
Previous Release Update February 10, 2022
- couple bug fixes for NP and variable access (not very common issue but has hit a few folks)
- updates for $currentEventDevice
- updates for handling sleep wakeups that original reason piston fired is still accurate.
Previous Release Update February 3, 2022
- Significant reduction in network bandwidth usage for dashboard and IDE
- Improvements in IDE 'db' loads by separating 'db' update from piston load
- New warnings in IDE for improper trigger usage/coding
- UI updates to choose is/are correctly (html, css, js updated)
- dashboard.webcore.co has rolled out dark mode theme
- flash/fade and other possibly long running commands have been significantly optimized
- these commands can cancel via normal tcp rules
- Many thanks to @ipaterson for UI improvements and db load.
More Previous Releases
Previous Release Update December 16, 2021
- latest optimizations and cleanups (quite a few)
- there is also a fix if you run local webCoRE CSS/HTML server so you want to update the changed files if you have this deployment
Previous Release Update October 19, 2021
- latest optimizations
- adds support for hub variables using @@variable format
webCoRE for Hubitat Updates - #1075 by nh.schottfam
Previous Release Update August 25, 2021
- updates to latest HE capabilities and device api updates.
- Many JVM optimizations resulting if further performance improvements (simple piston now runs in < 10ms)
Previous release Feb 20
- adds ability to query via http endpoint global variables - see webCoRE for Hubitat Updates - #904 by nh.schottfam
Previous Release Update February 9, 2021
- further optimizations
- Updates for http requests that return binary data
- Updates to 'stays unchanged' operation to cancel properly
- updates for setLevel command on switch to support command calls with duration for transition
- corrections for running multiple webCoRE instances
- added lifx support from original webCoRE
Previous Release Update January 23, 2021
- Further JVM optimzations
- Fixes for IDE displays of various 'stays' triggers
- correction of trace information for webCoRE IDE
- updates of wording for 'stays' triggers to describe behavior better
- updates for $sunrise, $sunset based on new HE apis
- correction of incorrect types used for time parsing
- use of new HE APIs for trace, exceptions (if running 2.2.4 or later HE firmware)
- updates to webCoRE IDE (on staging.webcore.co, or if you run local) for dark mode theme selection
Previous Release Update December 8, 2020
- added $longitude, $latitude, $zipCode and $tzId based on current hub settings.
- system variables are now sorted in IDE display
- for users running local web server for webCoRE, the html / css has been updated (use the repo listed in this note)
- Updates for homebridge V2 can execute webCoRE pistons.
- There is a new driver for users of $weather, that provides an event when $weather is updated - so pistons using $weather can be event driven, to run after an update occurs to $weather variable. The piston will need to decide what changed for values, the 'updated' event provides notification that webCoRE updated $weather. If you use HPM, you have to use 'modify' to select to add this device handler. Example: webCoRE for Hubitat Updates - #774 by nh.schottfam
Previous Release Update November 20, 2020
- added system variables for $tzName and $tzOffset
- updated time parsing for 'HH:mm:ss' formats
- added timeouts of 20 seconds for all http requests
- some adjustments for 3 axis devices (I don't have one to test with, and I don't see a virtual device on HE for 3 axis)
- subscription adjustments improving trigger vs. condition checking
- further optimizations for JVM
- improvements for integration with homebridge-v2
Previous Release October 16, 2020
- Update to handle HE changes on http requests and decode64
- Time handling improvements.
- Can convert epoch time in seconds to time or datetime format without additional math
- support for devices that have a setVariable command
- fix for $device initialization
- further optimizations for JVM and locking
Previous Release September 16, 2020
- Fix for HSM alert events, display in webcore console, and clearing
- corrections for local html web server deployments
- do note if deploying local html web server, use the files from the HE repository / branch, not older files from other repos.
- added option in webCoRE main app to clear all piston's logs, traces, stats, and caches if debugging logging is enabled for main webCoRE app
- further cache and JVM optimizations
Previous Release July 26, 2020
Further JVM optimizations
- further heap reductions
- locking improvements
Fixes for time handling
Fixes for device 'mixups' (this was done July 15)
Previous Release Update July 5, 2020
Further optimizations to help improve JVM performance on HE.
- Primarily reduction in heap variables and further code optimizations
- change to support decode64 for binary data returned on an http call due to HE api changes
- Added further time parsing based on common webCoRE issue(s)
- periods in meridians
- Unix time in seconds (vs ms).
- updated to support much larger pistons > 20 chunks
Previous Release Update June 9, 2020
- Fix for recent HE firmware changes in regard to received web event headers causing web calls to not trigger to piston
- various performance updates, and further state reduction
Previous Release Updated May 25, 2020
- Bug fix for parameter mapping for executePiston and http requests
- further performance optimizations
- further state space and access reduction
- webCoRE is available in Hubitat Package Manager
Previous Release Updated April 4, 2020
- Adds use of async http for ifttt access
- expanded use of attribute value subscriptions (device GETS, device RECEIVES triggers)
- optimizations to reduce code size and execution
- latest fixes for webCoRE on ST
- Ability to reset your webCoRE access token (will affect all external URL access to require new URL)
Installation and Updating
-
It is a good idea to reboot your hub before installing or upgrading, and let it settle its internal db for a few minutes. (HE console -> Settings -> "Reboot Hub")
- it is also a good idea to take regular HE Hub backups and store them off the hub How to backup your hub - Hubitat Documentation
-
webCoRE is available in Hubitat Package Manager [RELEASE] Hubitat Package Manager -- HubitatCommunity
-
Manual install: A minimum install is 2 source files: (instructions: How to Install Custom Apps - Hubitat Documentation)
-
webcore.groovy import URL:
https://raw.githubusercontent.com/imnotbob/webCoRE/hubitat-patches/smartapps/ady624/webcore.src/webcore.groovy -
webcore-piston.groovy import URL: https://raw.githubusercontent.com/imnotbob/webCoRE/hubitat-patches/smartapps/ady624/webcore-piston.src/webcore-piston.groovy
-
Optional Apps:
-
if you use $weather functionality - webcore-storage.groovy import URL: https://raw.githubusercontent.com/imnotbob/webCoRE/hubitat-patches/smartapps/ady624/webcore-storage.src/webcore-storage.groovy
-
You only need fuel stream app installed if you use graphing / enable local fuel streams. Import URL: https://raw.githubusercontent.com/imnotbob/webCoRE/hubitat-patches/smartapps/ady624/webcore-fuel-stream.src/webcore-fuel-stream.groovy
-
-
The sources are initially installed in the Hubitat console "Apps Code" -> "+New App"
- repeat this step for each source file to be installed
-
-
Then in the Hubitat console under "Apps" select "+Add User App" and then "webCoRE"
- After installed, the webCoRE App ("Apps" -> webCoRE) provides the registration code for the webCoRE dashboard (below).
-
Now you can go to the webCoRE Dashboard and start importing or creating pistons:
- using the standard dashboard.webcore.co or staging.webcore.co site to launch the IDE for creation and editing pistons,
-
Source code Link (note branch is hubitat-patches):
Notes on Updating:
-
it is good practice to UPDATE the webcore-piston.groovy code first, then the webcore.groovy last when installing new webCoRE version in HE.
- Using HPM, it will notify you of an update, or you can force update via 'hpm repair' on webCoRE
-
Hygiene after an upgrade: going into the Hubitat Console and selecting: "Apps" -> "webCoRE" -> "Settings" -> "Cleanup and rebuild data cache" is a good thing to do.
-
HE has a limitation on the amount of data that can be returned on a http call from a server (128KB - headers) to its cloud endpoints.
-
if you are running local webCoRE dashboards (this is an uncommon optional deployment described in note 2 of this thread), I would suggest updating webcore-piston.groovy and webcore.groovy and, ensure everything is ok with any code updates there, before updating your local dashboard.
- this will allow you to more easily check things out in a new release.
Details on the webCoRE port to HE
-
Here's a link to a thread that has links to the original github webCoRE code that was forked for use with Hubitat. It was this version of code that I started working with to optimize for Hubitat. Patched webCoRE for Hubitat (2018/09/09). This is quite old now...
-
While a noble goal to keep the source code (groovy) in the hub the same as ST, this is impractical because of sheer code size, numerous platform differences architecturally, and the inherent higher horsepower ST requires running in the cloud.
-
Fixes found during the HE optimizations have been provided back to the ST webCoRE team to resolve bugs.
- separate hub code makes QA and release management easier, both on developers and users (users on one platform don't get changes destined for another platform).
-
we keep the source / apis common for the webCoRE servers so that interoperability and piston sharing can work between platforms.
-
The HE code has :
-
Less overhead on HE platforms:
-
state (storage) reduction for webcore pistons
-
many parent/child calls have been removed
-
reduced watchdog activity
-
reduce sending of location events (causes Hub db activity)
-
Should have less resource usage and execute statements much faster on Hubitat, especially if Parallel execution is turned (left) off for your pistons.
-
New Features
-
Added new trigger capabilities
-
if Device receives attributeValue or if Device gets attributeValue (for momentary devices like buttons)
- receives / gets triggers have the piston only subscribe to attributeValue (vs all state changes) of the attribute. (ie switch.on (only on events of switch) vs. switch (all switch state changes). This is also interesting for buttons (gets 1) to only receive button pushes for button 1.
-
global variables as triggers only wakeup pistons subscribed to that variable
-
ifttt events only wakeup pistons subscribed to that event
-
Adds ability to have a piston trigger from a HE system restart event
-
this is not typically needed for proper piston operation, but can be helpful if you want a piston to check modes or other state that may not be correct (changes happened while hub was down).
-
this is done 'if System Start event occurs'
- so select a virtual device System Start, and the trigger verb 'event occurs'
- note that just after reboot, the hub is 'busy', so you may want to limit / delay the actions you take
-
-
-
uses Async http calls for http commands (http, email, ifttt)
-
Pistons that run a long time will automatically "be nice" and release/share the cpu so other things can run / operate. Adds pauseExecution() for long running pistons to avoid 'hangs' of Hubitat hub due to compute bound applications. webCoRE will terminate long running pistons after 40 seconds runtime for a single event.
-
Reduced thread usage by pistons significantly by quickly queuing activities that can be delayed
- Note Hubitat can run 4 threads at a time (cores) and has about 20 threads available for event processing.
-
Added new functions from latest webCoRE master
-
Has an HE version number in addition to webCoRE version number to understand what is deployed.
-
Ability run rules from Rules Machine.
-
Bug fixes for time handling, sunrise, sunset, daylight savings time.
Note:
- The piston bin (backup code) is located in state and settings variables for each piston (you can see these in Hubitat console by "Apps" -> select settings gear next to the application /piston.)
-
The backup code is also available in the webCoRE dashboard when you select the piston
-
it is good practice to enable automatic piston backups
-
webCoRE Differences / Restrictions (vs webCoRE on SmartThings platform):
-
Buttons operate differently in HE than ST, so when importing pistons from ST, these portions will need to be adjusted to the HE button devices and attributes.
-
Hubitat's button implementation
- This is a simple edit to use holdablebutton, pushablebutton as the attribute vs. button after import.
-
Some users have found they needed to recreate the if statement for a button if ST import brought in a device subIndex.
-
-
HE port has removed a lot of source comments (that caused problems compiling/saving on Hubitat)
-
Smart Home Monitor (SHM) does not exist in HE, but it does have Hubitat Safety Monitor. This is supported by webCoRE. Hubitat Safety Monitor API - #3 by bravenel
-
Hubitat does not support $twcweather, so you would need to use a weather device for Hubitat with webCoRE or the experimental $weather support (below)
- here is an example piston Hourly Weather Forecast Tiles - Example Pistons - webCoRE Community Forum
-
There is experimental support $weather variable access in webCoRE based on openWeatherMap (free), darkSky data (free but going away due to Apple purchase) or apiXU (payment required apiXU.com).
-
This requires installation of the webcore-storage.groovy app (HE Console -> Apps Code)
-
Enter your openWeatherMap, darkSky, or apiXU key in the webCoRE app (HE Console -> Apps -> webCoRE -> Settings). $weather should be populated for your pistons.
-
This link has information on viewing $weather data: webCoRE for Hubitat Updates - #3 by nh.schottfam
-
There is a new driver for users of $weather, that provides an event when $weather is updated - so pistons using $weather can be event driven to run after an update occurs to $weather variable. The piston will need to decide what changed for values, the 'updated' event provides notification that webcore updated $weather. If you use HPM to install, you have to use 'modify' to select to add this device handler. Example: webCoRE for Hubitat Updates - #774 by nh.schottfam
-
-
sendPushNotification command does work, it requires:
- HE mobile app, pushOver, twilio or some other notification driver on HE to be installed & configured on HE and this driver set for notifications in webCoRE (in the HE Console, Apps -> webCoRE -> Settings).
-
HE has removed SMS support (Previously it limited SMS messages to 10 per day). You can subscribe to a separate service and use an appropriate device handler.
-
if your phone provider allows email -> SMS message, you can use webCoRE's email capability to send txt messages.
-
another choice is: Sendmail - Send email and text notifications, (notification device) no local server needed
-
-
webCoRE on HE uses the 'us' (USA) region webcore servers (when using dashboard.webcore.co). I have not found a way to auto detect region on HE, and HE currently only has USA servers. (if anyone knows differently/more let me know via private message)
As mentioned in other notes, it is a good idea to:
-
Avoid enabling parallel execution in piston settings (under options when editing 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)
- This causes webCoRE to use atomicState much more (which is slow in Hubitat)
-
Control use of logging, both in code in your piston, and in the webCoRE dashboard when enabling logging on pistons. It is a good idea to leave it on "none" or minimal once you are done debugging a piston to reduce load on the hub and the database.
-
with the state size reductions in webCoRE, the logging setting is likely the largest consumer of state (db space)
-
This link has some performance information related to logging: webCoRE for Hubitat Updates - #333 by nh.schottfam
-
-
Piston Design paradigms part 1: if a lot of things need to happen near the same time:
- If you need a bunch of Pistons to run at the same time (say nightly or to run off the same trigger), you have a couple of design choices:
-
you can have a each piston with its own timer/trigger "At midnight..." (MORE OVERHEAD, as it causes a lot of threads to be consumed at the same time in Hubitat)
-
you can have one Piston called nightly work (or event work), and it calls each of the other Pistons that need to be run (BETTER in that less threads will be consumed (assuming you leave wait option set to true))
-
- If you need a bunch of Pistons to run at the same time (say nightly or to run off the same trigger), you have a couple of design choices:
-
Piston Design paradigms part 2: In many pistons, you may be subscribing to more device attributes or states than you intend. If a piston is dealing with motion (and controlling a switch), it may not need to be subscribed to the switch (but commonly you may see it is).
-
Look for the "lighting bolt" in your piston code (in webcore dashboard/IDE) and ensure you need all the subscriptions that you see. These cause the piston to wake up (and consumes a Hubitat thread) for each wakeup.
-
Key is to choose your comparisons correctly (trigger vs. condition) in your pistons - if the piston has a trigger, then conditions are not subscribed to.
-
-
Piston design paradigm part 3: In many pistons, you may read / compare the same device attribute repeatedly. In most cases the attribute will not change during a single event execution. If this is the case, you can at the start of the piston access/ store once the attribute value to a variable, and use the variable throughout execution. Device attribute access is slower than variable access.
-
avoid enabling log piston executions in the webCoRE app as this adds a bit of overhead on the hub and database (this is a webCoRE app setting; not a piston/code dashboard setting).
- If you have applications that want to trigger based on a piston execution, this does need to be enabled. Examples include Echo Speaks and Homebridge V2 (if you need this feature).
Installation Notes:
-
You only need the dashboard app installed if you use the Dashboard (beta) tab in the webCoRE dashboard. Import URL: https://raw.githubusercontent.com/imnotbob/webCoRE/hubitat-patches/smartapps/ady624/webcore-dashboard.src/webcore-dashboard.groovy
- Note this adds more overhead on your hub when you go to "Dashboard (beta)" screen in the webCoRE dashboard as it subscribes to many device attributes / events.
-
The storage app is only used for $weather support on Hubitat, so you only need to install it if using $weather variables.
Reporting issues:
-
Apologies in advance if you have problems
-
See instructions for what data to provide
-
A private message (here in this discourse forum) is many times best, and if you have a sample piston that shows the issue and/or logs, this makes things much easier to diagnose/fix.
If you need general webCoRE assistance on coding, examples, etc, the webCoRE community forum is a good place to visit, find programs you might reuse, have discussions with experts, etc.
Credits
- Credits to all those who before me who wrote this, got it working, and keep it working
Links:
Adrian presenting on webCoRE:
Note Adrian is the original author of webCoRE, and not directly involved in the port to HE.
