Thanks for this! I couldn't figure out why it wouldn't work!
Send Device Notification didn't work for me but Speak does!
Hey all, I am coming back to this topic after giving up on webCoRe for a while. HAs it stopped causing slowness within HE?
In a word, no. 
But it doesn't usually totally lock up the hub like it did before some change was addressed a while back. I'm slowly moving all my pistons to rules and apps, and with only two pistons left my hub is pretty stable--just might take a few minutes after boot. I also go into each piston child app and click "Done," which helps them run faster the first (or every?) time, though that's unrelated to the other issues and is just an ST-vs-HE difference.
The long answer is that it probably depends on how many pistons you have, how complex they are, and how lucky you happen to be.
Yeah I'm afraid the glow is coming off of WebCoRE for me. It has the logic to do the kinds of things I want to do, unlike RE, but it's simply not reliable.
I've about had enough of slow response, or worse WebCore Just dropping some events on the floor. If I leave the house ONE MORE TIME only to find that ONE random light didn't shut off I'm going to tear all this sh*t out and go back to bare bulb in every room with a string to turn it on. I don't particularly think this is an issue with WebCoRE on HE, its an issue with WebCoRE. It's simply not performant enough and requires too many tricks and work arounds to do the sorts of behaviours that are baseline to entry.
The latest port of webCoRE on HE is much more performant, and HE friendly.
See:
2 Likes
I'm curious if anybody is having any succes with webCoRE these days. I finally jumped ship and am running all of my automations out of an appdaemon/home assistant docker-compose setup, talking to hubitat via mqtt.
This has worked remarkably well over the last few months and has the added benefit of being real code, in real source control, written with a real text editor. I could re-create the whole thing on any box that runs docker in 15 minutes. It's faster than webcore too, though I'm guessing it could be faster still minus the mqtt stuff, but it's solid and reliable.
Haven't had any problems since I migrated from ST last November/December for two of my locations. WebCoRE has been solid for my automations ... I occasionally look at the status page, but that's about it.
I haven't updated to the latest WeCoRE-Habitat version, but I'm not in a hurry since everythng is working as expected.
1 Like
Working great here for me too, although I have two HE hubs and physical devices are on the hub without webCoRE. No idea if that helps or not, but I guess it doesnt hurt 
2 Likes
Anyone have a working example of an incoming external endpoint using the '$args' variable? I have not been able to set it using a URL Encode or parse it when using a JSON in a POST request. I used this several times on the ST webCoRE solution, so understand how it worked there.
When I was playing with recently, you'll have to explicitly put $args.variablename, $args by itself didn't work for me.
Thanks. Yes, that worked. In ST you could capture the $args value for inspection. Looks like that didn't port over.
https://cloud.hubitat.com/api/bd7...466&text=works
when you are in the webcore ide on your piston, do you see $args as a system variable?
Are you referring to this?
yes, if you run something that passes args, and leave the IDE window open, it should fill in with the $args
staging* shows this:
dashboard* just gives me [:]
Receiver piston:
Sender:
https://cloud.hubitat.com/api/c44c7e/apps/3/execute/f4742f:?text=MyData&access_token=2cb-bfca-8f4
Hmm, I see it in the system variable but it didn't log it...
8/30/2020, 11:36:47 AM +474ms
+18ms ║Args:
+28ms ║Args.text: MyData
It looks right to me
I see text:MyData as part of the map
Also may want to remove your keys if you did not otherwise obfuscate them
First line should have logged this though?: [referer:null, text:MyData, remoteAddr:[184.101.238.181, 70.132.62.153]]
