They definitely are accessible somehow and I even reached out to @bravenel for guidance. Nothing so far. I’m also skimming the CoRe code for clues as well.
Not at all! I went back and did a search myself and these are the instances I found…
- Dashboard App: Line 109.
- Piston App: Line 812 and line 1137 (1138 has the command too, but it is commented out).
It would also be worth noting that I am using the latest 3.x version of webCoRE.
Appreciate your patience; but on line 109, which is runIn(30,stop) how would the toInteger() advice apply? I assumed that line could be left alone; same for line 812 of Piston.
Line 1137 in Pison I had changed to runIn(toInteger(t), timeHandler, [data: next]) ; these changes in addition to the ones ogiewon documented. And it mostly works, unless time triggers are involved. If I create a piston to do something at 11:00 pm, I get ‘An error has occurred while subscribing’ in Hubitat log, and this in the WebCoRe log:
| +1ms | ╔Starting piston… (v0.2.102.20180116) |
|---|---|
| +468ms | ║╔Subscribing to devices… |
| +514ms | ║║Subscribing to Aeon Labs Doorbell H1… |
| +518ms | ║╚Finished subscribing (51ms) |
| +531ms | ║Comparison (time) 83160033 happens_daily_at (time) 82860000 = false (1ms) |
| +537ms | ║Cancelling statement #2’s schedules… |
| +543ms | ║Requesting time schedule wake up at Tue, Feb 27 2018 @ 11:01:00 PM EST |
| +562ms | ║Setting up scheduled job for Tue, Feb 27 2018 @ 11:01:00 PM EST (in 86099.936s) |
| +569ms | ║An error has occurred while subscribing: groovy.lang.MissingMethodException: No signature of method: app1519704323087212899030.toInteger() is applicable for argument types: (java.math.BigDecimal) values: [86099.936] |
| +576ms | ╚Piston successfully started (576ms) |
Running same version as you; is anything similar logged in WebCoRe for your time triggered pistons?
I am not quite able to understand what must be going wrong 
I just ran a test piston and it worked fine for me...
Logs
2/26/2018, 10:37:59 PM +407ms
+1ms ╔Received event [Home].time = 1519706280000 with a delay of -593ms
+496ms ║RunTime Analysis CS > 20ms > PS > 19ms > PE > 457ms > CE
+510ms ║Runtime (36921 bytes) successfully initialized in 19ms (v0.3.000.20180224) (509ms)
+510ms ║╔Execution stage started
+531ms ║║Comparison (time) 81479930 happens_daily_at (time) 81480000 = true (1ms)
+533ms ║║Time restriction check passed
+534ms ║║Cancelling condition #3's schedules...
+534ms ║║Condition #3 evaluated true (13ms)
+535ms ║║Cancelling statement #3's schedules...
+537ms ║║Requesting time schedule wake up at Tue, Feb 27 2018 @ 10:38:00 PM CST
+538ms ║║Cancelling condition #2's schedules...
+538ms ║║Condition group #2 evaluated true (state changed) (17ms)
+539ms ║║Cancelling statement #4's schedules...
+994ms ║║Executed physical command [null].on() (22ms)
+994ms ║║Executed [Switch 8].on (22ms)
+1008ms ║╚Execution stage complete. (497ms)
+1009ms ║Setting up scheduled job for Tue, Feb 27 2018 @ 10:38:00 PM CST (in 86399.585s)
+1053ms ╚Event processed successfully (1052ms)
Piston
Ah well. I tried duplicating your piston exactly and just got the same error. My next step will be to delete everything and try reinstalling. Thanks for your help!
Use “t.toInteger()” instead, maybe?
2 Likes
YES! Thanks for taking the time to give a clue to someone who literally doesn’t know what they are doing. And for your clear instructions that enabled me to even attempt to get this going.
As you indicated, the runIn() statement that needs to be changed is:
runIn(t, timeHandler, [data: next]) in Piston.
What eliminated the WebCoRe logged error was changing it to:
runIn(t.toInteger(), timeHandler, [data: next])
Now a simple time trigger works as expected. Thanks much!
1 Like
Glad to hear it and for the feedback. I have edited my post above to include this change as well.
Thank you so much for figuring this out. I have three webCore pistons which I can’t work out in RM. If you guys are up for more challenges, I have these two problems:
- In my first piston, the emulated fader doesn’t work. My guess is there may be some challenges with the hardware abstraction layer? I’m using Caseta dimmers in my piston.
- The second piston has a challenge in running the expression {$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit}. I get the three dots and then the (evaluating) and then blank.
Thoughts?
While time triggers now appear to work, has anyone been able to use a Wait action successfully?
With an action of ‘Wait 4 seconds’ , WebCoRE logs the following:
An error occurred while executing the event: groovy.lang.MissingMethodException: No signature of method: java.lang.String.call() is applicable for argument types: (java.lang.Long) values: [4000] Possible solutions: wait(long), wait(), any(), wait(long, int), any(groovy.lang.Closure), each(groovy.lang.Closure)
Appears to stem from line 1655 in WebCore Piston code. @mike.maxwell , any thoughts on this one?
Is there a GitHub repository with this modified webcore hanging around?
2 Likes
Tony,
Looks like that line you referenced is call a function called pause(). What is interesting is the definition of that function , as shown below, does NOT support passing any arguments into it, which is probably why the error is being thrown. So, I am not sure why that would have ever worked.
Map pause() {
Now I am the first to admit that I am not much of a Groovy programmer, so maybe I am missing something obvious here?
Interesting. That line appears in the code as ’ pause(delay)’ and also has that same usage in line 2155 of the WebCore code.
Going by the WebCoRE log message that gets generated immediately before it is used (in WebCoRE Piston) with an action of ‘Wait 4 seconds’, it appears that delay in my failing testcase evaluates to 4000 (4000ms). If I comment out that line (in WebCoRE Piston), no errors are thrown, but no delay happens either, so it seems to be the culprit. I’ve used ‘Wait’ actions with the ST version, and they certainly work in that environment.
From looking at the code near line 607 where pause() appears after the Map keyword I see the msg string “Piston successfully stopped” so I assume (and I am definitely out on a limb here) that the pause function may also serve to ‘Pause’ the entire piston… and I’ve seen some odd behavior with that feature as well (as in, it doesn’t seem to pause the piston at all). Fixing that may fix both issues.
Line 1644 gives us a clue:
if (rtData.logging > 1) trace "Waiting for ${delay}ms", rtData
All the pause(delay) call should do is wait delay milliseconds.
Looking at the pause() function, in addition to stopping a Piston, it's set up to return the runtime data Map rtdata. This doesn't match the call from line 1645 at all.
This is because the pause(delay) function must be elsewhere. I assume in another executable.
Any idea what the ’ Map pause()’ section does around line 606? Then there’s the asycnttp_v1 includes that need to be commented out; possibly something missing from there. Would be nice if this was fixable; the functionality is severly limited without the ability to do waits.
All, I have successfully found a workaround to the pause() issue found by @Tony earlier. In both the webCoRE and webCoRE Piston apps, you must replace all 'pause(argument)' calls with 'pauseExecution(argument)' calls instead. Only change the pause calls that have an argument passed to them, and of course keep using the original argument!
Note: DO NOT change the 'piston.pause()' call in the main webCoRE app. It is the one call that uses the 'map pause() {...}' function defined in the Piston app.
I have forked Adrian's webCoRE GitHub repository at (removed link - see update below) so I could have one place to share our collective fixes to make webCoRE run more reliably on Hubitat. If you have other fixes, please share them here so all are aware of them. You can also issue a pull request to my GitHub repository so we can keep the four apps up to date in a common location. Thanks for that idea, @justin.bennett.
UPDATE: Please use the community supported version of webCoRE for Hubitat found in the following thread. This version is much more up to date than the version I had been maintaining early on.
5 Likes
Every time you do something incredible out here or on the ST forums, I try my best to resist from responding with 'Dan's the man!'. Couldn’t help it this time 
In all seriousness, am really glad you took this initiative. Thanks for keeping webCoRE alive even on Hubitat!
1 Like
Well done! Now (peeling the next layer of the onion) all we are missing is the ability to use button devices. Still this is major progress. Thanks!
1 Like
@ajayjohnm - I think I have fixed this one too by changing out the asynchttp_v1.put() call for just a normal synchronous httpPut() call. This was not just a simply change of the function call. I had to hack away at it to make it work, so it looks a little different. But at least it seems to return "OK" as the response!
I just updated the webCoRE Dashboard app in my github repo with this change as well.
2 Likes
I suspect the asyncHTTP is more relevant for web traffic because it allows for out-of-order packets, maybe? Local processing shouldn’t have that issue.
Also this:
- Automatic smart request retries optimized for spotty mobile connections
