webCoRE for Hubitat Updates

community_app
#1

Updated March 20, 2019

New Version (March 20th) changes:

  • Avoid duplicate commands to physical devices
  • Additional time cleanups

New Version (March 16th) changes:

  • command cleanup and ensure webcore dashboard updates with command changes
  • use this version to avoid issues with recent Hubitat platform changes

New Version (March 15th) changes:

  • Many time handling and DST changes based on bugs found in original webCoRE

New version (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.

Overview

Here is an updated webCoRE forked from the original in this thread: Patched webCoRE for Hubitat (2018/09/09)

  • This provides a common programing environment and code sharing across different platforms.

Features :

  • This version is less overhead in that a lot of

    • parent/child calls have been removed

    • global variables as triggers only wakeup pistons subscribed

    • reduced watchdog activity

    • reduce sending of location events (causes Hub db activity)

    • Should have less resource usage on Hubitat, especially if Parallel execution is turned (left) off for your pistons.

    • uses Async http calls for http commands

  • Pistons that run a long time will automatically "be nice" and release the cpu so other things can run / operate. Adds pause() for long running pistons to avoid CPU hangs of Hubitat. It will terminate long running pistons after 240 seconds.

  • Reduces thread usage by pistons significantly

    • 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

  • Bug fixes

Note:

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

webCoRE Differences / Restrictions:

  • Removed code for lifx, and a lot of source comments (that caused problems compiling/saving on Hubitat)

    • For lifx support you can use Hubitat lifx devices in webCoRE as you would any other device.

  • Hubitat does not support $weather or $twcweather, so you would need to use a weather device for Hubitat with webCoRE

  • sendPushNotification does not work, so use pushOver or some other notification driver on HE

  • HE limits SMS messages to 10 per day, or you can subscribe to a separate service and use an appropriate device handler.

  • While a noble goal to keep the source 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 has running in the cloud (Pistons don't compete with each other as much as they do on Hubitat).

    • 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 do want to keep the source / apis common on the webcore servers so that interoperability and piston sharing can work between platforms.

  • webCoRE on HE uses the 'us' region webcore servers. (I have not found a way to auto detect region on HE (if anyone knows let me know via Private message))

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

  • 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)

    • This causes webCoRE to use atomicState more which is very slow in Hubitat

  • 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))

  • 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.

  • Global variables - limit subscriptions (if you use multiple, see if you can subscribe to less variables as triggers)

    • This is a place where less is better - minimize total number of variables, and minimize changes and use as triggers.

  • I suggest to 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 app setting; not a piston/code dashboard setting).

  • 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.

Installation Notes:

  • It is a good idea to reboot your hub before installing or upgrading, and let it settle its internal db for a few minutes.

    • it is also a good idea to take regular backups and store them off the hub

  • A minimum install is webcore.groovy and webcore-piston.groovy. In the Hubitat dashboard under "Apps" select "Add User App" and the "webCoRE"

    • 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.

    • You only need the dashboard app installed if you use the Dashboard (beta) tab in the webCoRE dashboard

      • 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.

Hygiene after an upgrade

  • going into the Hubitat Dashboard and selecting: "Apps" -> "webCoRE" -> "Settings" -> "Cleanup and rebuild data cache" is a good thing to do.

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.

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 wrote this and got it working, and keep it working

Source code Link:

Links:

Community Apps
Patched webCoRE for Hubitat (2018/09/09)
#2

Additional data

  • Currently webCoRE will terminate a piston if it runs for more than 240 seconds - 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)

  • 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"

  • 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:

#3

Updated March 20th See original note for fixes.

#4

I get this warning and even though I cleared the cache and restarted the browser it won't go away.

A newer UI version (v0.3.10a.20190223) is available, please hard reload this web page to get the newest version.

#5

I think for some reason it’s looking at the ST value?

#6

on HE make sure you have updated both webcore.groovy and webcore-piston.groovy.

If you have done this correctly, you can then go into Apps -> Webcore and hit done

The webcore dashboard checks the webcore version number. The code (webcore.groovy and webcore-piston.groovy) check the HE version number (that they match) - this would show up in the HE dashboard under "Logs" if there is a problem.

#7

Not working.... I must be doing something wrong.