I used to run locally on a Pi.
Decided to use the Pi for something else and changed to cloud.
This was some time ago though and I'm pretty sure I did see the version field after. Cannot guarentee it though.
@nh.schottfam 
You are right checking the privacy agreement brings this field into view.
Thanks.
I was able to update my pi and it now includes the "Dark Mode" icon in the upper right corner, but it does nothing when clicking on it.
I'm guessing there is an alternate universe where this update applies to ST as well? 
I get this in the staging site:
A newer SmartApp version (v0.3.111.20210130) is available.
This is an optional update; consider updating the webCoRE SmartApps in the SmartThings IDE
interesting, I'll have a look
The latest kit for webcore turns back on lifx device support in webcore.
The setup is the same as before:
- in webcore console (IDE) you have to enable lifx support
If you use HPM to install, do a repair install on webcore to force it to update.
I would try support again. There was a post today about a lot of emails where snagged and put into spam folders.
I have discovered a new issue that cropped up in the past few days. I don't think the issue is with the app but the recent change made to the dashboard.
I have included screen caps to show the problem but when testing my apps the variables that the app uses would update in near real time. That no longer happens. If I want to see any changes to the contents of a variable I must refresh (F5) to see them. This problem is also happening on the SmartThings side.
tagging @ipaterson
Excellent observation, please try the fix on staging.webcore.co (if you've used that before you will need to hard reload the page). The fix is on GitHub, file dashboard/js/modules/piston.module.js in case you run a local dashboard.
Tested on staging.webcore.co and it is working again. Thanks much.
adding a setLevel() device command in a webCoRE piston is not allowing the optional duration parameter.
the setLevel() device command should accept the 1st parameter as a numeric level from 0-100 and an optional 2nd parameter as a numeric duration. This is a hardware fade that is performed in the dimmer switch firmware (not the webCoRE software emulated "Fade level")
The underlying piston code seems to be able to accommodate multiple parameters but the UI only allows a single parameter with no provision to enter optional parameters.
I have attempted to modify the HE webCoRE Apps Code so it allows for the optional 2nd parameter. I edited line 3462 as follows (bold italic is the added code):
setLevel : [ n: "Set level...", i: 'signal', d: "Set level to {0}%{1}{2}", a: sLVL, p: [[n:"Level",t:sLVL], [n:"Duration",t:sINT,r:[0,8192],d:" with duration {v}"], [n:sONLYIFSWIS,t:sENUM,o:[sON,sOFF], d:sIFALREADY]], ],
that change now lets me add an optional 2nd parameter.
HOWEVER, the command does not execute. Nothing. I was hoping this was just a simple bug in the UI where the optional 2nd parameter was just overlooked or forgotten. But when I enter the 2nd parameter, the command does not execute. If I remove the 2nd parameter then setLevel(x) works again. So I guess there is something else in the piston code that I'm missing. That code looks like a fairly generic wrapper for the executePhysicalCommand() and accepts a "params" list variable. So I'm lost as to where it is choking on the 2nd parameter for the setLevel(x,y) device command.
Any ideas?
I'll work on a fix. It is a bit more complicated than what you tried.
There are also issues of backward compatibility and not breaking existing pistons.
Should have it later today.
Awesome and thanks! 
Note that I arbitrarily put a range of r:[0:8192]. You probably don't want to use that. I think it might vary with different dimmer brands so probably needs to be loosely bounded. Maybe just leave the range off (although it probably should be restricted to positive values only 
)
New Release posted today.
See note 1 for release updates info
Do note to clear your browser cache after updating.
- loading a small piston first makes the db update for the browser go quicker.
I appreciate you fixing this so quickly 
However, in my humble opinion, the fix has some bugs that need attention. 
In the webCoRE main code, it now accepts the optional "duration" parameter. That is good. But it doesn't display the value in the editor. This is mostly a cosmetic bug because the command does seem to work with the duration setting even though it doesn't show it in the editor.
Here is my suggestion to fix the code:
Line 3462 you have:
setLevel: [ n: "Set level...",i: 'signal',d: "Set level to {0}%{1}",a: sLVL,p: [[n:"Level",t:sLVL], [n:sONLYIFSWIS, t:sENUM,o:[sON,sOFF], d:sIFALREADY],[n:"Transition duration (seconds)", t:sINT]], ],
I suggest changing it to this:
setLevel: [ n: "Set level...",i: 'signal',d: "Set level to {0}%{2}{1}",a: sLVL,p:[n:"Level",t:sLVL], [n:sONLYIFSWIS, t:sENUM,o:[sON,sOFF], d:sIFALREADY],[n:"Transition duration (seconds)", t:sINT, d:" in {v} seconds"]], ],
That will make it display like this:
Also, in the webCoRE-Piston code, it appears that you re-used the global 'delay' variable to hold the local 'duration' value. I think this could be a problem for people who use the Piston Execution Delay option. I'm new to the webCoRE code, so I may be interpreting this wrong. But I believe the global 'delay' variable is used across multiple commands to specify a delay in milliseconds between command executions and you don't want to over-write it with the setLevel 'duration' value. The global 'delay' value is a Piston Execution Setting found here:
On lines 3417-3421 you have:
Long delay=psz>2 ? (Long)params[2]:0L
if(attr==sSTLVL && delay>0){ // setLevel takes seconds duration argument (optional)
List larg=[arg, delay.toInteger()]
executePhysicalCommand(rtD,device,attr,larg)
}else executePhysicalCommand(rtD,device,attr,arg, delay)
That causes the global piston execution 'delay' variable name to get replace with the setLevel variable params[2] (transition duration) and that will bypass any global piston execution delay that may already be set.
My suggestion is to create a local 'duration' variable name instead of using the global 'delay' name. Then you can pass in the optional duration value as well as the global delay value and also preserve the piston delay for non setLevel commands
Long duration=psz>2 ? (Long)params[2]:0L
if(attr==sSTLVL && duration>0){ // setLevel takes seconds duration argument (optional)
List larg=[arg, duration.toInteger()]
executePhysicalCommand(rtD,device,attr,larg, delay)
}else executePhysicalCommand(rtD,device,attr,arg, delay)
thx
your second change is incorrect, and I suggest you don't do that. I'll fix the first issue on display.
Both scenarios are already working.
I admit I only just recently started looking at the webCoRE code so its very possible I'm missing something in the bigger picture. However, I don't see what is incorrect with my short code suggestion above. Can you please help me understand why its incorrect?
BTW, I tested my suggestions before I posted and they are working for me. So I'd really like to understand where is incorrect and why you think I shouldn't do that.
I can see that you are re-using 'delay' as a local variable to hold the setLevel duration value when the variable name 'delay' is already being used throughout the code as a global variable to store the Piston Execution Delay value. Those are two different timings. Your code puts the setLevel duration value into the 'delay' variable and then passes that value (I believe incorrectly) as the Piston Execution Delay parameter in the "else executePhysicalCommand" line. So everything else that calls the do_setLevel routine is going to get a 0L value for Piston Execution Delay even if it should be something else. It also drops the Piston Execution Delay value from the 1st executePhysicalCommand with the sSTLVL attribute. My suggested change should fix those two things (as far as I can tell).
Does it work correctly? I'm not sure about that. The setLevel duration is working now and thats good. But it looks to me like your code fix is no longer honoring the previous Piston Execution Delay properly. Instead of just telling me mine is incorrect, can you please help me understand with a little more details? I am an experienced programmer but am new to the webCoRE code and I would like to understand it better.
@nh.schottfam
Wondering if you could add this really simple change to WC. 
As my HPM updates always fail due to sync problem I have to check the app code manually to make sure I'm up-to-date.
The WC engine text reads the wrong line of the code so it reports the wrong version.
I'm at 0211 on both so the first HE version is incorrect.
