So, I assume this is normal? Things seem to be working okay but just want to make sure that they stay stable. Thank you for your help.
Thank you for confirming!
@nh.schottfam I have come across a problem with a change made in webCoRE sometime in the past
Changed was made on v0.3.113.20210203 v0.3.113.20210209_HE
A change from "stays unchanged" to "changes and stays unchanged" has caused one of my pistons to fail. The piston in question hasn't been altered and was known to be working before.
The logic of "changes and stays unchanged" seems conflicting and there doesn't seem to be a way to make my piston work again.
I suggest you invert the order of the statements - ie make sure the stays unchanged always is executed first in the if xxx AND yyy
You code is setup currently that it would not always run over the stays unchanged
You have options to have the 'if' not do command optimizations.
In general
- stays unchanged is a trigger
- you seem to have two triggers in an if statement, which is generally a bad idea as both triggers 'never fire' at the same time.
Do you really want a trigger and a condition?
- ie mode changes away from is your trigger
- and do you want 'did not change' (condition looking backwards in time), vs 'stays unchanged' (trigger looking forward in time)
The other option is mode is the condition and stays is the trigger. However you likely need mode to be a trigger, but as a separate 'if' statement just to fire the piston (but to not AND triggers together)
See:
Yes both a trigger and a condition, at least I think I do. 
I have changed the piston to only trigger when coming out of night and changed the order as you suggested.
The way it was working before is when the hub came out of night mode a countdown timer started ticking down (on contact switch "stays unchanged" and if the person didn't open the cabinet (for medication) within the countdown a message was sent reminding them they haven't taken their meds. The way it is now the countdown timer never sets so the piston fails to do what it used to do before. I think having "changed and stays unchanged" is conflicting. If it changed then it can't be unchanged. Oh well
@nh.schottfam Color me silly but I followed the link you provided and in that link it states;
"there is a trigger ‘stays unchanged’ which is forward looking in time (IE IT MAY SET A FUTURE TIMER)"
Where is the 'stays unchanged' ? I have attached a screen shot and I can find no such thing. Am I missing something?
EDIT:
If I delete the new With block the Trace starts working again! Something in the block is harming the piston execution. Hmmm
I see there was an update on July 7. I applied the update and checked the date headers for the newer version but WC seems to be failing in some aspects.
- Trace runs but no longer highlights the trace path. If I do a Test it does but if an event comes in it does nothing.
- I added a new block to a piston and the lines don't execute.
After alarm.sendemail I added the block above but nada.
What am I missing, HE logs have a WC of:
app:122021-07-08 13:23:38.129 errorjava.lang.NullPointerException: Cannot get property ':3791c34e185f6da2a8285c7c90af4637:' on null object on line 2713 (pCallupdateRunTimeData)
app:122021-07-08 13:23:38.124 errorjava.lang.NullPointerException: Cannot get property ':c0a7627195000110ac4a0d40a89351c5:' on null object on line 2713 (pCallupdateRunTimeData)
@nh.schottfam
I suggest you reboot and see if that resolves it.
otherwise need to see full piston and full logs. This can be a private message
What version of HE firmware are you running?
I'm having issues with boolean restrictions. In the image below, I'm trying to change the value from "false" to "true", but it's stuck as "false" even after I check "true". (Saving at that point saves the "false" value).
I'm running the latest version (updated this morning). I'm running a local webCoRE server; I updated and restarted that as well.
So this is just in the UI that a value will not save?
ie what are the steps that you use to reproduce this? Does it happen if you create a new test piston?
That is strange as nothing changed in latest release for the UI...
If you can Private message me the piston, I would like to look at it more closely.
- I would also like to know the version of HE firmware
Also have you tried 'is not' as the comparison and test against false?
- this is strange.
So this is just in the UI that a value will not save?
Yes. I can't choose "true".
what are the steps that you use to reproduce this?
Seems to reproduce 100% when using a boolean device attribute. (Those aren't common. This one is the only one in my entire system. Usually developers represent booleans as on/off switch values instead.)
Does it happen if you create a new test piston?
Yes.
If you can Private message me the piston, I would like to look at it more closely.
On its way.
Also have you tried 'is not' as the comparison and test against false?
That's my workaround.
Since the last update (a few days ago), I'm having an issue with a piston that is controlling multiple lights. Before the update, I could control multiple lights (devices) with one statement. Now it seems that only one device in the line of devices are getting the command. If I break it up into multiple commands, then everything works properly. Below is an example of what DOES work now. Before I had both the Front Door Lamp an Foyer Lamp on one line (I added the asyc before breaking them into 2 different commands to test if that had any affect- it did not).
For everyone else
- this issue was a device handler not using proper attribute types (according to HE docs). A pull request was sent to the device handler in question to fix to one of the supported attribute types as per the HE developer documentation.
This response applies to my issues with using the Chromecast app?
Not sure about that. If you can get me a small reproducer piston I can look at?
If I can see the issue, I can fix it.
Ok, removed and tested all the statements and it seems I create some sort of conflict by setting the state of a virtual switch after its event is received.
The "set switch off" causes the Trace to fail or not run; rename "With Alarm" to another switch or remove the statement and all traces fine.
Is there a way to do a "Set switch" without creating an event maybe?
This virtual switch it pressed on the Dashboard. If the alarm is ready the piston does some arming code but if it's not ready then I just want to send out a msg and turn the virtual switch on the dashboard "off".
The code has always worked fine it's just the Trace that fails.
There is, if you click on the line where you set the switch, there is a tool icon at the bottom of the dialog., The subscription method default is automatic change it to do not subscribe.
After looking at your code again I realized that probably won't work. Your trigger event is the Alarm switch so whenever it changes the piston will trigger.
Perhaps changing the task cancellation policy for the IF(the one where you look at the global) statement to never cancel task may do what you want. Select IF and then the tool icon.
Yes, I looked for that but it's catch 22.
Maybe there will be a fix in WC ot alleviate this situation.
Try using two IFs for AlarmReady instead of using an else.
