Overview
webCoRE provides a rich common programming environment and code sharing across different home automation platforms. webCoRE provides an integrated IDE, debug and trace environment 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 that can be imported, as well as get questions answered.
-
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 15ms (which is a dramatic improvement vs. operations on SmartThings which is commonly > 150ms for the identical piston)
Current 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 driver 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
Previous Releases
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 [BETA] Hubitat Package Manager
-
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 / 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 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 site for editing,
-
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 files in HE.
-
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.
- This can affect you if you are running backups from the webCoRE dashboard using webCoRE cloud servers, as large lists of pistons could be requested to be uploaded for backup. Doing full hub backups from HE console, or backing up pistons one at a time from the webCoRE dashboard are the workarounds.
-
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)
-
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.
-
Features in this code :
-
This version is less overhead on HE platforms:
-
state (storage) reduction for webcore pistons
-
many parent/child calls have been removed
-
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
-
-
-
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.
-
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
-
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
-
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
-
-
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.
-
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
-
-
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).
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
-
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.