Nope, no issues till now. Will let you know if i have the same issues
I have had to change the same expression in the refresh part.
Didn’t change it before.
Ahh yea, you have to change the color on 2 places in the piston
1 Like
I wish there were a way to get Hubitat Safety Monitor arming/disarming in WebCoRE. I guess I’ll have to write my own security monitor in WebCoRE.
You can change safety monitor from webCoRE using modes, shame we can’t see SM state from webCoRE though!
We have on our list to add the states. But, you can control HSM and respond to HSM events. See this post:
Assuming that WebCore can send/respond to Location Events.
1 Like
Specific ones yes... probably just needs reference to shm changed to hsm wherever applicable then.
A child device generated by hsm would be sweet btw… integration with other apps would be simple that way.
Integration with other apps is simple already. They can subscribe to location events, and send location events to HSM. That’s simpler than throwing another device out there.
@ajayjohnm I’ve got another pull request up in github to support hubitat’s button implementation along with support for location routine events ( I have a modified version of Other Hub pusher that sends routines to hubitat ) along with removing an unsupported call to request.getHeaders() in the dashboard.
4 Likes
@jp0550 @ajayjohnm just wanted to say thanks for your ongoing work on this… really appreciated.
7 Likes
Awesome work @jp0550! You are on a roll! 
I tried to do some preliminary testing but encountered some generic errors (UI and pistons were unaffected. However the error did popup on every page-load). Despite doing a hard reload, clearing the cache and even trying it in incognito mode, I couldn't get rid of this.
However, I am pretty certain that this is an issue with my setup itself and can be easily resolved. Hope to test around a bit more tomorrow and then update the opening post with yet another set of great fixes from you!
In the meanwhile, I exchanged some messages with Robin, who has spoken to the webCoRE maintainers
to get their buy-in on letting us merge our patches, directly on their GitHub. This is as long as the patches are non-destructive patches. This would help us in avoid the hassle of maintaining a separate branch at our end.
I did get some basics ready for making our existing webCoRE patches non-destructive.
Now to move on to actually updating all the patches.
1 Like
I want to check if a button is pushed.
How can i do this in webCoRE? Normaly you can evaluate if the "button" event is pushed but that option isnt there on hubitat:
I'll admit that I am not at the same level as some of you when it comes to writing code, so is adding this type of code a minor task? It seems like most people didn't want to touch WebCore because it would be an extensive re-write. (I just got the impression from various comments on the forum).
I believe that button pushes are one of the items not currently working yet.
1 Like
webCoRE is crazy complex but broken down into it's component parts it's possible to tweak for most mortals (Adrian is not a mortal btw).
A huge chunk of webCoRE runs in JS on the webCoRE servers, intention was to reduce the code base due to size limitations imposed by groovy.... this part of webCoRE is, in the most part, platform antagonistic.
"Non-destructive patches" relates to a proposal I made to @ajayjohnm in regards to making HE patches for WC work without breaking ST integration (i.e. the code detects which platform it is running on and behaves differently depending on what is detected). Such patches could be applied to the main webCoRE repository via pull requests and would be very much welcomed. It would save running two versions of the apps and all the sync issues that goes with it.
1 Like
Also, us knowing that webCoRE has a life after ST scraps groovy gives us (royal us lol) an incentive to continue development of new features such as find and replace, holiday variables and other new features we have in the pipeline.
2 Likes
This may be only for Minimotes (because that's the only button device I have), but this works for me:
A sample of the log produced:
The action selection looks like:
1 Like
I have found the way to do it!
Only thing is, you have to add the "button has changed", otherwise it wont subscribe to the buttons events!
@jp0550 Barring a few areas, I tested your latest commit and everything works like a charm! Thanks for all your hard work!
I like the option you have added to support local hosting of the webCoRE UI
I couldn't test routines though, as I do not have a version of Other Hub that support routine sync.
As for the button implementation, I did have trouble getting the held event to be recognized. However, it may be worth noting that I used a Xiaomi button (which uses a custom handler by @veeceeoh). I didn't dig much into investigating what was happening but I guess the issue may probably lie with way my button reports its events.
Regarding the non-destructive patches, I am currently working on making all your patches as well as the ones contributed by others, work in a manner that the same code could run on ST and HE.
For any future patches, kindly use the snippet mentioned in the below linked thread, to ensure that the patch only runs when on the HE platform.
