I need some help converting a CoRE piston to webCoRE!
I have a virtual on/off switch that I use with a group of lights.
When I use my Amazon Echo to turn the virtual switch on, my CoRE piston turns all the lights on.
When I use my Amazon Echo to turn the virtual switch off, my CoRE piston turns all the lights off
My CoRE piston uses the following triggers:
if switch changes to on
if switch changes to off
I also control the same lights manually and there are many times when I tell my Amazon Echo to turn the virtual switch on when it’s already on and also off when it’s already off. Fortunately, CoRE still evaluates these commands as “switch changes to on” or “switch changes to off” (even though the switch didn’t technically change). So everything works exactly the way I need it to in CoRE.
Unfortunately in webCoRE, if the virtual switch is already on and I tell my Amazon Echo to turn it on, webCoRE doesn’t evaluate “switch changes to on” as true. Therefore, my actions aren’t triggered like they would be in CoRE. The same goes for telling my Amazon Echo to turn off the virtual switch when it’s already off.
Can webCoRE be updated so it functions the same way as CoRE with virtual on/off switches?
If not, can anyone help me figure out something that would work with a webCoRE piston so I don’t lose the functionality I currently have with my CoRE piston? I’ve thought about this for a while now and can’t come up with a solution that will work with webCoRE.
@cozdabuch heres a quick and dirty version to give you an idea of how it might go. the top half is the save and bottom half is the restore logic. you will need to include the trigger or condition when the save is executed vs the restore maybe on alarm state change. for this version, i only save and restore the switch state. since this is only an example i only added 2 switches, you will probably want to try with a longer list of devices.
there is probably a better way of doing this. if someone else has other ideas please share. thanks!
Communication using network physical addresses (aka MAC) only works when the two entities communicating are on the same local network. MAC addresses are not relayed to the next hop and cannot be routed/found over WAN. You’re safe, knowing your MAC address is pretty much the same as a hacker knowing the serial number of your old lawn mower. Useless
Chris and all - continuing with a conversation about Conditions versus Triggers in IF clauses… I had an odd thing happen and because of something you said earlier I was able to quickly figure it out. But I don’t fully understand why this happened. I’d appreciate it if you can explain further. Here’s the situation…
The question is related to the 3rd if block. If contact sensor IS open and switch is Off, then turn the switch on…
When I opened the contact sensor the switch was not turned on. And when I looked at the logs I saw that it didn’t even log anything to the console, which meant that webCoRE wasn’t triggered at all about the door opening.
When I looked at the piston, I noticed there was no small lighting bolt symbol in the “gutter”, which told me, I think, that webCoRE was not subscribed to or monitoring this If block.
To solve it, I simply changed the If contact sensor IS open, to If contact sensor CHANGES TO open. Then it worked fine.
But what I really find confusing, is that I had the same exact logic in the old CoRE which worked just fine. Except in that case the logic for this If block was the only thing in the piston, whereas in webCoRE I have this logic as a block among other code within the same piston, as you can see here. Not sure if that played a factor, and if so how.
Yeah, I noticed that the $nextScheduledTime system variable doesn’t populate for me. Like I mentioned before, I haven’t used this variable yet so I wasn’t sure what it returned (other than it’s a time variable) … it was just a shot in the dark, but apparently my aim was waaaay off
When you only have conditions in a piston, the piston will subscribe to the conditions. When you mix conditions and triggers in a piston, the piston will only subscribe to the triggers unless you manually force it to subscribe. CoRE and WebCoRE both operate this way (except I don’t think CoRE had a way to force a subscription). You mentioned that in CoRE the third If block was in it’s own piston…this is why it worked fine over there…no triggers, so piston subscribed to conditions. In WebCoRE, you mixed triggers (changes to and stays) with conditions (is), so the conditions did not subscribe. Since there was no subscription, the piston was not notified of a state change in that particular contact sensor, and did not execute.
I have a timer based piston that runs daily at a time which is specified in a global variable.
It worked until about a week ago when broke.
A look in the logs reveals:
║An error occurred while executing the event: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object '1970-01-01T16:30:00.000Z' with class 'java.lang.String' to class 'long'
Thanks Chris! Makes perfect sense. In fact you touched on this in an earlier reply to me, which is would enabled me to quickly hone in on the issue and resolve it last night.
Regarding this:
Do you know why webCoRE designed that way? Seems that at a minimum it should warn you in the IDE that the code block will not subscribe to any events and will never execute. The missing lighting bolt is a good indication, but for newbies this is easy to overlook.
Regarding this:
When forcing a subscription, does it matter which part of the two AND conditions (Contact IS open versus Switch is off) that you would apply the Always Subscribe subscription method too, or perhaps you have to apply it to both?
Also - is there any difference whatsoever in how the piston will behave under various conditions/situations, in this case, with using conditions only in this area of the piston with forced subscription and using IS, compared to using Contact “Changes To” open? Certainly it seems more intuitive to use Changes To and have it automatically subscribe, compared to having to use the force subscription option. But if there is any functional difference in how these will operate it’s good to know.
I think the most challenging part of mastering webCoRE programming is that it is so flexible that there are multiple ways to accomplish the same exact thing, which can make it confusing to know which is the best way and what subtle difference there may be between the various ways…
Speaking of which, another related question if you don’t mind… I’ve seen where people will use a ONLY WHEN restriction clause. Like If Switch Changes To On, then Only When Motion Is Inactive … That’s pretty intuitive, but I don’t understand why you wouldn’t just put the Only When condition as part of the IF with an AND instead. For instance in this case, instead of Only When, use If Switch Changes To On AND Motion is Inactive then…
Similarly, I don’t see what’s the best way to use the “when true / when false” options. Ideas?
Also I THINK I just realized something else, which should be noted as a caveat in the discussion. If you have mixed conditions and triggers in a piston in different If blocks, a Condition will still be evaluated if there is also a trigger on the same check elsewhere in the piston. So it seems.
For example if you have a door sensor that uses an IS clause in a piston that has mixed conditions and triggers and multiple If blocks, but the door sensor is used in a trigger elsewhere in the piston, then the Condition test will still be evaluated.
In other words, it seems that the subscriptions are device specific but cover the entire piston, not just each place where the device is referenced in the piston.
Are any of you guys keeping track of how long your lights or other such switches were on for?
I’d like to set up a piston that triggers on a switch changing to Off, and then use previousAge to capture how long the light was on for, and then upload that data to a spreadsheet along with the day’s date/time it turned off. The idea is to be able to produce a report that allows me to look at things such as how long the lights were on for each day/week/month, what the average time the lights are on for, etc. What’s a good way to do this? Or am I better off using a third party add-on like ActionTiles or something like that, if those will track that automatically? Perhaps this is what the upcoming Dashboards and Fuel are about?
