Additional details on how things work:
webCoRE Operations
Your pistons execute locally and if the webCoRE servers/internet are down, pistons keep working (unless the piston is using one of the below mentioned webCoRE server functions).
- It is possible to run the webCoRE [dashboard] server locally (see below)
Your piston is stored in HE hub (inside the piston child application). When in the webCoRE dashboard and you want to edit a piston, the webCoRE dashboard requests the code from HE, and when you "save", it stores the code back into HE into the piston.
- This is why it is good in general for HE to take regular backups on your hub and store off your hub.
webCoRE dashboard (server) functions
webCoRE uses the cloud webCoRE servers for webCoRE dashboard operations (when you use the cloud instances of webCoRE dashboard such as dashboard.webcore.co or staging.webcore.co). The webCoRE cloud servers allow:
- get html, css, js files without running your own local webserver
- you create/edit/debug pistons (regardless of your location)
- share, import pistons with others
- cloud backup and restore of pistons
- provides some services such like email (outbound)
staging.webcore.co is the newest / beta of the wc servers (WC team puts updates there before they release them). You generally do not need to use this site unless instructed to, as it may have code that is not fully tested/released.
Piston Backups
-
When you backup your HE Hub, you do have a backup of all apps, pistons, and settings
-
Note there are two types of backups:
-
the HE hub backup (done from HE console -> Settings)
- it logically is a full, and it only allows a full restore
- when running automatically it is stored on your HE hub, or in the HE cloud if you signed up for the cloud service
- you can download a backup to your computer via HE console -> Settings -> Backup / Restore
- when you restore it roll the entire hub back to the backup point (restore everything back in time)
- it logically is a full, and it only allows a full restore
-
webCoRE piston backups (done from webCoRE IDE)
- webCoRE contains the ability to backup pistons locally (to the system you are running your browser on) from the webCoRE dashboard.
- this backup can be all your pistons (if using staging.webcore.co) and selected set of pistons
- it is stored as a file on your computer
- on restore you can restore selectively only the pistons you want from what is in the backup
-
Miscellaneous Details:
-
Notes on making http requests:
-
if you have an application that makes http requests to a webCoRE piston (or other HE applications running on your hub), there are limits on the response size that can be sent thru the HE cloud gateways.
- specifically HE platform limits responses to (128KB-header sizes) in size
- currently HE does not allow gzip responses
-
-
webCoRE will terminate a piston execution if it runs for more than 40 seconds for a single event - so in addition to the "being nice", this should terminate a runaway piston.
-
When the webcore dashboard is open at the main dashboard page (listing your pistons), it updates every 10 seconds with Hubitat. While not a lot of overhead, be aware that it is updating
- if you open the "Dashboard (beta)", there is much more overhead on Hubitat (while it is open)
-
Time Handling
-
HE platform handles time string parsing differently than ST. If you find time strings are not converting properly please report this (ideally private message, and logs and/or example piston).
-
When scheduling things that you want to run on "day changes" - for example midnight:
- keep in mind that schedules can run up to a second or two early, so if you want to ensure it runs at or after midnight, set the piston to run "Every day at 1 minute after midnight", to ensure it runs on the new day.
-
the design paradigm of having a single "nightly" piston run, and it calls other pistons is more friendly to the resources on Hubitat.
-
If you are in an area that has daylight savings time (DST), Be careful scheduling work to happen during the change periods of DST, as things may not run, or run twice depending on the DST change happening. - 00:01 - 00:58 or 03:01 and later may be better choices.
-
-
If you need a larger application, you can use multiple pistons, and have a main piston call the sub-pistons. Again, leave the wait = true on when performing "execute piston"
- do note:
-
to pass data to a piston, you can use arguments on the piston call, or global variables.
-
to get data returned from a piston execution, global variables are often the best choice.
-
note that a piston can subscribe to a global variable change. (globalvariable changes). This design paradigm can make it easy to not worry about the loading comments below.
- global variables are "loaded" when a piston starts, and saved when a piston exits, so if:
-
Piston A calls piston B, and B modifies a global variable, piston A will not see the change until the next time piston A executes.
-
Piston A modifies a variable and calls piston B, since A has not exited yet, the change to the global variable is likely not to be seen by B until B runs again after A has exited (and saved changes)
-
- global variables are "loaded" when a piston starts, and saved when a piston exits, so if:
-
- do note:
-
If you are using older zwave devices (and some zwave plus devices), these devices may not report physical switch state changes in a timely manner, so you may need to add a refresh in your pistons before checking state for conditions.
- For triggers or conditions, Zwave Poller should be enabled for these older devices. This is due to ST vs. HE differences in handling of older zwave devices. If you choose Zwave poller, you won't need the refresh commands in you pistons:
-
In many cases, replacing these older devices will be your best option to have HE function efficiently and have a well-operating mesh.
-
Device Status Not Updating on Manual Change - #4 by JasonJoelOld
Z-Wave Poller only supports Generic Z-Wave Dimmer and Generic Z-Wave Switch device handlers.
-
- For triggers or conditions, Zwave Poller should be enabled for these older devices. This is due to ST vs. HE differences in handling of older zwave devices. If you choose Zwave poller, you won't need the refresh commands in you pistons:
-
Version numbers
-
interoperability with the dashboard.webcore.co site requires compatible version numbers for dashboard server interactions. For server interactions webcore reports the webcore version number understood by the dashboard.
-
An HE version number is also in the code for webcore.groovy and webcore-piston.groovy. These are checked that they are the same, but they do not provide an update notification of newer version available (only the webcore version number is checked for the notification)
-
Running a Local webCoRE Server
It is possible to host the webCoRE web server files (html, js, css) locally (on your own computer in home, such as a raspberry PI).
This is an advanced/complex configuration, and when setup properly removes part of the webCoRE web server cloud dependencies - shifting the dependencies to your local deployment. This feature is only available on the HE port of webCoRE. Note that this is for webserving the IDE web pages, other webCoRE server functions (piston sharing, email, ifttt outbound, $nfl, store media still use the webCoRE servers)
-
Because your local copy is providing the web server server files, you need to ensure it is kept running, and you should run webCoRE or HE backups to ensure no service or data loss.
-
If you want remote access to the webCoRE dashboards, or have multiple locations and want to share pistons across them (when running a local webCoRE server) you have to enable access to the webCoRE server on your local network to the desired locations (VPN, remote desktop access, etc.)
-
It is not required to host the webCoRE webserver files locally and doing so is not likely to change performance for most folks. For information/discussion on running the webCoRE servers locally, see the threads:
-
Note you should use the files (html, css, js) from the latest repo for webCoRE in note 1 of this thread (not the older files in the older instructions links as the web server files have changed since those notes were written).
-
webCoRE can be hosted with superstatic (NPM package), and it has a superstatic config file as part of the repo if you clone the repo in note 1.
FuelStreams
The webCoRE dashboard can display / graph data. Fuelstreams is a groovy module to store data for piston fuelstream requests locally on the HE.
Older Release History
Previous updates History / Changes:
Previous Release Updated February 24, 2020
- more optimizations and performance improvements
- These are primarily reductions in code size, cpu, memory and db (storage) consumption
- bug fix for flash command
Previous Release Updated January 7, 2020
- Many more optimizations and performance improvements both for piston execution and dashboard operations.
- further reduction in accesses to state (HE db)
- reduced operating memory and operating piston size
- bug fixes
Previous Release Updated December 17th, 2019
- Improved logging
- changes for runtime changes
- 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'
- do note that just after reboot, the hub is 'busy', so you may want to limit / delay the actions you take
Previous Release Updated December 9th, 2019
- Improved logging
- additional optimizations
Previous Release Updated October 28th, 2019
- Bug fix for cast errors
- update to webcore Server code (for those running a local webCoRE server) for recent fix added
Previous Release Updated October 12th, 2019
-
Updated to work with latest webCoRE server updates to improve device loading, and support for more devices. This should alleviate most issues with having to open a small piston first.
- Note if you use the public webCoRE servers, you need to be running this latest software
- Note if you run a local webCoRE server, your local webCoRE server software MUST be updated to work with this new release
-
Optimizations, and fixes
- Further performance improvements
- HSM incidents / alerts reported via $incidents, $hsmTripped
- added $weather support for Darksky weather data (must be configured in webcore application)
- improved handling of webCoRE global and superGlobal variables
- version numbers updated to meet webCoRE servers.
Updated Release Updated August 30, 2019
- update for device optimizations
Updated Release Updated August 25, 2019
- few bug fixes for color settings
- more cleanups
Updated August 22, 2019
- Fix for HSM settings issues
- Few more optimizations
- import URLs are added to main modules to make easier updating
- updated version number to match recent webCoRE release in IDE
- Normal update procedures should be followed (see below)
Updated August 15, 2019
Significant updates to webCoRE on HE to reduce overhead and improve performance
As always, before upgrade, do take backups of your hub, and store the backup off the hub on your computer. (HE console -> Settings -> Backup and Restore)
It is good practice to reboot your hub prior to upgrading, and to let it settle its internal DB for a few mins, then install the new webCoRE version (HE console -> Settings -> Reboot Hub)
Install the main webCoRE.groovy application last when updating the groovy components (HE console -> Apps Code -> webCoRE Piston; webCoRE Storage then webCoRE (main app).
After upgrading recommendation:
- go into the HE console, Apps -> webCoRE and then scroll down to hit "done"
- wait about 1 minute for updates to occur as part of the upgrade
- open the webCoRE dashboard/IDE in a new browser window
- THIS SHOULD NOT BE REQUIRED WITH OCT 10 and later updates select a small piston so that db uploads to the IDE will not exceed HE limits. It is possible this small piston may need to be loaded twice (without editing the piston) for all the IDE uploads to complete. This may occur if you have a lot of global variables, variables, or devices. HE logs (HE Console -> Logs) will show if you need to load twice or not.
Improvements
- much improved performance due to many optimizations - These together can reduce overhead by up to 50%
- reduction of state usage (HE database)
- improved locking performance
- code optimizations to improve performance
- Added new trigger capability
- 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.
- if Device receives attributeValue or if Device gets attributeValue (for momentary devices like buttons)
- updated version numbers to match updated webCoRE release
Updated June 27, 2019
- webCoRE servers updated with HE changes - no longer need to use staging site.
- updated version numbers to match updated webCoRE release
Updated May 31st, 2019
- Updates for device capabilities and commands (auto-fill in IDE)
- fix for physical and programmatic device trigger filters
- Experimental support for $weather variable based on APIXU data
- this can be enabled by:
- installing the storage app
- entering your apiXU key in the webCoRE app (HE Console -> Apps -> webCoRE -> Settings)
- data format is apiXU data format (pistons need to be modified to this data layout)
- this can be enabled by:
Updated May 12th, 2019
- Fix for subscription publishing (if you think you hit this issue, pause/resume of the piston, or edit/save (both in webCoRE dashboard) will resolve.
- Ability to set default notification device used when you call sendPushNotification. This can be the HE mobile app, pushOver or twilio (or any other driver that supports deviceNotification.
Updated May 5th, 2019
- Ability to execute Rule Machine rules from webCoRE. To use this capability you need to use the webCoRE dashboard site staging.webcore.co when editing pistons that call RM.
- Improved DST processing
- improved sunrise/sunset events to avoid double executions
- cleanups and bug fixes
Updated April 20th, 2019
- Fix for time schedule subscriptions
Updated April 16th, 2019
- fix for improper hashing of location ID
- async http for email requests
- fix for subscriptions to be properly updated after save of piston code
- After installing this update, in the Hubitat console, "Apps" -> select each piston and hit done so the updates are applied.
- update of color code. Note webcore manages hue for colors as a range 0...360
- webcore automatically scales this to 0..100 range required by color devices that accept hue calls on HE.
Updated April 6th, 2019
- fix ifttt calls into webCoRE
- note if you are using the standard dashboard.webcore.co site for editing, it will return an incorrect URL when using ifttt. The site staging.webcore.co will show you the proper URL. This is not a runtime issue, but an IDE issue that is fixed on staging.webcore.co.
Update April 4th, 2019
- fix for access error on field.
Updated April 2, 2019
- Fixed an issue with editing new pistons.
Updated March 30, 2019
-
Key update is code changes to dramatically reduce state (storage) usage by webcore pistons
- side effect to be aware of once this new version is installed, you cannot easily go back to an earlier version of webcore on HE due to the state changes / reduction in the piston.
- piston backups, restores from webcore server work as normal (no changes).
-
Benefits:
- I have observed startup, and atomicState accesses to be much faster (likely due to having to load/store much less state during startup and piston end)
- Many operations run faster, especially ones that accessed atomicState and piston startup
-
How to install: (this is consistent with instructions below)
- Do restart, and backup your HE Hub (download the backup to store off your hub)
- Install webcore-piston.groovy, then webcore.groovy under "Apps Code"
- After installed and operating, you should take another backup of your hub and download the backup to store off your hub.
Updated March 23, 2019
- ifttt events are directed to specific pistons vs. all pistons
- This change requires you on installation to this March 23 version to pause pistons that subscribe to ifttt events, and then after the groovy code update is complete, unpause them so that the subscriptions are properly updated by the new code. This is done in the webCoRE dashboard, selecting each piston that subscribes to ifttt events / callbacks.
- time parsing fixes for iso 8601 strings
- this release has beta / experimental display of local fuel streams in the webcore dashboard. (currently requires staging.webcore.co as dashboard URL)
- small bug fixes
March 20th changes:
- Avoid duplicate commands to physical devices
- Additional time cleanups
March 16th changes:
- command cleanup and ensure webcore dashboard updates with command changes
- use this version to avoid issues with recent Hubitat platform changes
March 15th changes:
- Many time handling and DST changes based on bugs found in original webCoRE
March 14th changes:
-
Global Variables do not wake all pistons on change (only pistons subscribed to that variable)
- This change requires you on installation to this March 14 version to pause pistons that subscribe to global variables, and then unpause them so that the subscriptions are properly updated by the new code. This is done in the webCoRE dashboard, selecting each piston that subscribes to global variables.