it worked thanks ady624
1 Like
You are most welcome. @HLlalo did you have to enable Expert mode, or did you update to v0.1.126 and worked without Expert mode?
Thank you
I updated to latest only.
Perfect, thank you 
I went through and created a bunch of new pistons and edited old pistons yesterday. I seemed to hit the bug in a variety of spots. Iâd create a basic piston with one IF condition (button changes to pushed) and when I finished creating the task (turn off a light switch), instead of taking me to the list of actions it would take me to a blank action page. If I hit the back arrow then the actions would show up and I could go back into the THEN page and theyâd all be there.
Is it still doing that in latest version? V0.1.126+?
The tale of two pistons. Iâve got one piston that monitors whether my safe or my office door is opened or closed and sends me a push notification with the device name and itâs status. â${currentEventDevice} is {$currentEventValue}.â
I have another piston that changes modes throughout the day (morning, afternoon, evening, night). It is set to send a push notification also (âChanging mode to {$currentEventValue}.â) This may not be the right variable, but I donât know because the push notification prints it out exactly like I typed it and doesnât use the variable value.
Thoughts?
Tried it once and it worked fine. I hadnât published the new code when I typed it up.
$currentEventValue is correct. Typo in the piston? It will output the variable name if the variable does not exist⊠what is the dashboard showing for that piston? Also, make sure you use {$name} and not ${name}. $ is inside the accolades.
Wait a minute. The event is time, so the value is in no way the mode you set. Add a send notification to each of the location mode changes and type the mode name manually. The event value represents the value received by CoRE in the event - and thatâs a time event you are dealing with. No value thereâŠ
Two stage question about the wait timer in CoRE and the timer display in the CoRE Dashboard and its relation to actual events.
Using the attached image I have a Basic piston that triggers a switch that turns on every 5 minutes, waits 3 minutes and turns it off again.
First Observation:
The piston starts and turns on a switch. Next event happens 3 minutes later with the switch turning off. In between that time the trigger countdown timer on the CoRE Dashboard has counted down to the 3 minute mark (as it should) but once the switch turns off, the original trigger timer gets reset back to a 5 minute countdown. So instead of the switch turning on every 5 minutes it is turning on every 8 minutes.
Question: Is this by design? I would think it would turn the switch on every 5 minutes and off at 3 minutes and then back on 2 minutes later.
Second observation
Lately I have been seeing on the CoRE dashboard past due times of 30, 40, 50, upwards to a minute.
It doesnât seem to be a reflection of actual delayed timed events because the IDE log shows no unusual delays.
Based on actual observed times the timer on the CoRE Dashboard is derived from some other calculation.
Is the timer being displayed an accurate representation of what it really happening?
The countdown timer is only updated every now and then, not continuously synced to ST. It is normal for it to go into past due times because it assumes nothing happened between updates.
The 8 minute total is not normal. Will look into it. Thank you
2 Likes
You may have done this already so I apologize if I missed it, but can you explain how, for a contact sensor, an If condition of âis openâ is different from an If condition of âchanges to openâ? I get the part that one is a state and the other is an event, but operationally behind the scenes, how does CoREâs operation differ between the two? Is having to continually check state more resource intensive than just listening for an event? Does one respond quicker than the other?
Ok. Iâll do that. Though, shouldnât {$currentEventValue} still output null?
I donât know the nitty gritty of it all, but here is what I learned from experience. I have a keychain remote with 4 buttons. I had set up a piston with âis pushedâ and âis heldâ and it would never run unless I ran the simulation while the button was held, which never caught the pushed events. I recently changed this to âchanges to pushedâ and âchanges to heldâ. Now, the piston runs immediately as I want it to.
What I suspect is that the pistons donât run constantly, so when set to âis openâ you have to wait for the piston to run and check the status. When you set it to âchanges to openâ it is triggering the piston to run because the status changed.
I think my Piston that died was because of the IFTTT maker connection. When I upgraded to the latest version, everything needed to be reentered, including the IFTTT connection.
Looking at fixing the Dashboard not loading and captured some logs, Whatâs the cannot get property âlâ on the CoRE lines referring too?
Seem to be a lot of description errors as well.
Edit: Looks like all these errors are related to pistons talking to my Minimotes. I deleted one piston and all the other errors left are related to the other minimote piston. They are just Basic ELSE IF pistons.
dde50e5b-9d94-421d-9380-62dcf132852e 09:09:32: error java.lang.NullPointerException: Cannot get property âlâ on null object
fae9b487-60c4-443c-a227-a47d24e28deb 09:09:31: error java.lang.NullPointerException: Cannot get property âdescriptionâ on null object
168b0f19-0e08-4d87-857c-3cf83dff60d7 09:09:28: error java.lang.NullPointerException: Cannot get property âdescriptionâ on null object
c81a2c91-3cb4-4fa7-97e1-cbb14632ec4f 09:09:21: error java.lang.NullPointerException: Cannot get property âdescriptionâ on null object
9a2e1c9d-dbf6-45ea-a50f-f880c640d80a 09:09:20: error java.lang.NullPointerException: Cannot get property âdescriptionâ on null object
dde50e5b-9d94-421d-9380-62dcf132852e 09:09:16: error java.lang.NullPointerException: Cannot get property âlâ on null object
fae9b487-60c4-443c-a227-a47d24e28deb 09:09:15: error java.lang.NullPointerException: Cannot get property âdescriptionâ on null object
168b0f19-0e08-4d87-857c-3cf83dff60d7 09:09:12: error java.lang.NullPointerException: Cannot get property âdescriptionâ on null object
d229cc83-ba87-4f4e-ae94-43e65b8f02e0 09:09:00: debug getChildDevices(false), children=2
28d0c5de-9474-48e1-8e12-14e6cb946da6 09:09:08: trace poll()
2fa2b439-ed26-4c1d-8e26-f9ac8f583c55 09:09:08: trace poll()
c81a2c91-3cb4-4fa7-97e1-cbb14632ec4f 09:09:05: error java.lang.NullPointerException: Cannot get property âdescriptionâ on null object
9a2e1c9d-dbf6-45ea-a50f-f880c640d80a 09:09:03: error java.lang.NullPointerException: Cannot get property âdescriptionâ on null objec
OK I was reluctant to migrate all my rules from RM as it was working damn well since the previous meltdown but I have to say after this latest I gave up and migrated to CoRe.
WHAT AN APP. for those of you that worked so hard on the development I cannot say thank you enough. this is just what ST needed to make it viable as a true HA platform.
Again thanks to all of you that gave your time to help those of us that lack your knowledge.
One question. RMs license let him kill it. Is this one truly open source so if our current developers leave someone is allowed to pick up the pieces and drive on?
1 Like
Makes sense. I guess it would help if I explain what Iâm trying to do.
I have a door with a contact sensor attached and a GE light switch in the same room. The end result is that when the door is first opened, I want an immediate push notification and for the light in the room to turn on. Then I want a push notification reminder every 2 minutes that the door is still open, then I want an immediate push notification as soon as the door is closed.
I currently have this set up and working correctly using a combination of SHM (for the immediate open and close notification), Smart Lighting (to turn the light on), and CoRE (for the 2 minute reminders). Iâd really like to be able to combine everything into a single CoRE piston. I was thinking something like the following:
Else if piston
If contact sensor changes to open
Then using switch turn on, using location send push notification âdoor just openedâ.
Else if contact sensor changes to closed
Then using location send push notification âdoor just closedâ.
Else if contact sensor is open then using location send notification âdoor is still openâ, follow up with piston (self) after 2 minutes
Conceptually it makes sense to me, but depending on how the piston fires and which conditions are evaluated when, it may or may not work. Thatâs why Iâm wondering about some of the behind the scenes details.