Looking at the code, it appears you did not accept the privacy agreement.
You might want to do that. I'll look at that code more, but even if you use local servers, webcore can want the external servers for some services (email, backup, etc).
If you don't that is fine, but I will likely look over that code and if something needs to be fixed, it may cause more side-effects.
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 would love to give it a try, but my hub won't turn on for over a week - and support hasn't replied to my email. When I finally get it finished, I would love to give it a try.
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:
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.
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.
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.
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.
Download the Hubitat app
