Next up on staging is improved support for certain system variables.
$currentEventDevice when used inside an on events from block will act like the specific devices selected in that block. When $currentEventDevice is selected the attribute and command lists will include the attributes and commands relevant to the monitored devices. Previously included only the global built-in attributes and commands.
$currentEventValue when used inside an on events from block will act like the attribute(s) selected in that block. So inside an on events from My Light's switch if you have a condition based on $currentEventValue the Value dropdown will show off and on and a numeric attribute would show range conditions like "greater than."
$device is a special variable inside for each device loops and now it will behave like the devices being looped.
This is live on https://staging.webcore.co, just be sure to do a hard refresh if your browser doesn't pick up the new code. If you encounter any issues please look up how to view your browser's developer console and share any red errors that appear there.
Worth noting this is a frontend dashboard change only, it has no effect on how the pistons run just makes it easier to work with those variables.
Sunset offset doesn't appear to work for me. My shades went down at sunset instead of 30 minutes past sunset tonight. I rebooted and created a test piston with a sunset offset in the future and it scheduled it for tomorrow.
Just updated to the latest piston code. Don't know what caused this as it's not at sunset app:122024-03-04 17:04:16.658errorjava.util.ConcurrentModificationException: null on line 1533 (method finishRecovery)
If I use Update it errors out, but if I do a Repair it finishes without any errors.
My hubs use webCoRE exclusively and my practice is to Disable all pistons in webCoRE settings beforehand removing as much load from my hub as possible. It might work for you, might not
Can't speak for anyone else, but it doesn't matter if I use update or repair. They both fail (times out) on webCoRE Piston. For the past several months, I have had to do all updates/repairs for Piston manually.
Same with me . Has any progress been made in fixing Hubtiat + HPM + webCoRE Updates? Does anyone have any insights or updates on when this will be addressed?
It's my understanding (which could be totally wrong) is that HPM fails on webCoRE Piston updates, installs and repairs because of the huge amount of code causing the operation to time out. This is due to a Hubitat platform timeout setting that isn't easily adjusted and may take a lot of effort by the Hubitat team to correct.
In the meantime, although I'd love to have this fixed because using HPM is obviously more convenient, it's not a huge deal to manually accomplish the updates and fixes while the permenant fix is investigated and eventually completed. Of course, this is just my opinion
Also, you can install the built in version and gradually copy your pistons across from the HPM installed version to the built in version.
The only downside is WC updates are dependant on an HE update and for me, that's OK.
Just another option.
The only problem with that is the people, me for one, have had many bugs found, quickly fixed and tested by the us and the team.
My pistons/Web UI have been fixed but if I go to the buitt-in version it lags behind so they remain broken until HE catches up.
Using staging.webcore.co helps keep some of the fixes.
Yep, everyone's use case is different.
Personally I've never had any issues that needed a 'quick' fix and using built in saves me from having to do any interaction with the app, apart from fine tuning the pistons that are working superbly but I just cannot help myself.
. Has any progress been made in fixing 
