Patched webCoRE for Hubitat (2018/09/09)

Yay. I'm not sure I did much apart from help you to 'poke and hope'.
Glad you got it working though.
Have fun.

1 Like

:grin::+1: Great!! Only took me three times :joy:

1 Like

Best way too learn in my opinion! But you do need at least a small stick to to start poking :joy:

1 Like

So it's one of the other in reference to the dashboard, if you have you pi set up as the server you can't use ? Have you guys set up a VPN to be able to remote in and edit if you have too?

Not as yet, but you can. But then I have VNC on my VM image to connect if needed.

I've pushed an update to github for the following changes:

  • Update code to latest from ady624 (removal of contact support)
  • Hubitat Saftey Monitor support for dashboard and pistons
  • Added $currentEventDescription and $previousEventDescription variables
  • Added firmware version display support to dashboard if >=

The $hsmStatus variable has also changed from showing a display status to the raw value, so if any previous pistons used that be sure to update them.

Note there is also support for another event: "Hubitat Safety Monitor Event" that is disabled by default. It will listen to apps sending events (using hsmSetArm) to Hubitat Saftety Monitor but not done through HSM or buttons/switches configured to do so.

For instance if you cancel an alert by using sendEvent(name: "hsmSetArm", value: "cancelAlerts") it will pick it up in a piston, but not if you hit the Cancel Alerts button using a device configured in HSM or through the app page.

If that's something your interested in you can uncomment line 3120 in webCore.groovy and it will show up as a new virtual device just note the limitations above.

@bravenel maybe in the future HSM can send these events to let other apps know when things like cancelled alerts happen within HSM

//alarmSystemEvent: [ n: 'Hubitat Safety Monitor event',t: 'enum', o: getAlarmSystemStatusActions(), m: true],

If you are running a local instance don't forget to run these commands:

cd webCoRE/
git pull

Also, if you haven't switched from @ajayjohnm's repo to mine, run these before doing the above:

Here is an example piston for the HSM:


That was my believe as well. As i have over 20 pistons, really don't want to chance it and would like to be pretty certain it won't break my pistons. @jp0550 - some guidance on this matter?

Just wanted to find out - I have a second Rpi and have installed webCore there. Will there be any problems if i just change on the HE portal the custom webcore instance url to the new Rpi IP address? Will it disrupt anything?

No disruptions at all. The webcore UI is just a front end for editing pistons.

1 Like

This will be in the next release (1.1.3).

1 Like

Idpaterson pushed another update today for some UI changes. I've merged the changes into my repo. Feel free to update if you want to get rid of the UI out of date message or want the latest.


Changed the IP and all is working smoothly. Thanks for verifying that!

1 Like

Has anyone run into an issue with particularly large or complex pistons? I have a piston that runs fine on SmartThings but moving it to Hubitat results in errors and warnings in the log when I attempt to edit it.

2018-08-08 13:54:18.383:errorjava.lang.NullPointerException: Cannot set property 'timing' on null object on line 1114 (api_intf_dashboard_piston_get)

2018-08-08 13:54:18.373:warnTrimming 139KB response to smaller size

Pushed a fix up for you. If you already had the latest, you just need to update webcore.groovy.

@jp0550 how does push notifications work ? I use pushbullit or notifications dont work ?

NM saw the answer above

Just realised this but for some weird reason when using a Philips Hue bulb and using webcore to set a colour, the default level will always jump to 50%.


Set level - 10%
Wait - 5 sec
Set colour - Red

It goes to 10% and after 5 secs, it changes colour and the brightness will be 50%.

Is anybody having this issue?

Yes, I'm definitely having issues with the level changing when I set a color. I've never tested to see that it was 50%, but my intention was to set it very low (around 1-5%) and then change the color, and I figured this out when I noticed that the bulb was much brighter than I expected when I did it in that order (level, then color). I worked around the problem by setting the color first and then changing the level. Not sure if this ever happened on ST, but I know in general different bulbs might behave differently so it's not too surprising to have to play around with the order of actions to get everything the way you want it with lights in webCoRE.

Does this happen when you change the color for it in the driver page for the bulb or only in webcore?

Tried directly on the driver page and no issues over there - I think.....setColor - Red, Hue-0.

I also tried this and the level stayed at 50%.

Set colour - Red
Set level - 5%

It wouldn’t go down to the 5% level. Played around with all the different arrangements as suggested by @bertabcd1234 with not much success. Only fade to level worked.

That is odd--I have what sounds like the exact same thing working for me:

If you're controlling a lot of lights at once, the Hue bridge is rate-limited and if webCoRE/Hubitat sends a bunch of individual commands, I'd almost think that might be the problem except you say fade works, which I'd assume would run into the same issue. I've also seen some third-party bulbs paired to Hue not respond as fast as Hue bulbs (IKEA Trådfri, in particular), which might cause problems with commands in rapid succession (even with my Hue Dimmer paired directly to Hue I have to wait a second or two between switching scenes for them to catch up or they'll not match what I configured).

I tried that exactly that with no luck. I am however connecting the Hue Bulbs directly to HE - not using the Hue Bridge.

Download the Hubitat app