Then how do we explain why the lights go off with a Routine but not with a Piston? Kinda suspect
Rick
Then how do we explain why the lights go off with a Routine but not with a Piston? Kinda suspect
Rick
Nope, Iâm not gonna try and explain anything⌠But if the bug was there first, it canât possible be what came after.
First off, thanks to @ady624 for creating CoRE. Before discovering CoRE, I was continually frustrated with the limitations of scheduling routines in Smartthings.
As I understand it, CoRE runs in the cloud and will not execute pistons when the hub is offline. Not a complaint, just an observation. So, my question is, if I have a piston set up to run at a certain time and the hub happens to be offline, does the piston execute once the hub comes back online even though the time has passed?
I have an OR-IF piston set up to run my âGood Morningâ routine at 6:15 AM during the week and at 7:15 AM during the weekend. Not very exciting, but it gets the job done. I have had rare occurrences when the piston doesnât fire and I can only attribute it to the possibility of the hub being offline. So, what happens when the hub comes back online?
Thanks for the help.
Ray
Ray, youâre welcome
The piston actually executes in the cloud regardless of the hub being on or off - the problem with the hub being off is most things wonât work - device changes wonât be reported (hence the piston not running) and commands to devices wonât work either. Time and presence should still trigger the piston, but donât expect the device related commands to work - they wonât and I donât think they will be âdelayedâ and execute whenever the hub comes back online.
Anyone else experience problems with time interval sunset - sunrise?
If I create a very simple pistion (motion active -> turn on light bulp) with time interval restriction with sunset - sunrise, It works at evening, but int the morning it wonât work.
Even if I try to add a big offset to the sunrise (say +600 minutes) it wont work.
Sunrise here at my location (Denmark) is 07:07 PM CEST (from Local Variables).
If I just exchange the sunrise with a custom time, then it works.
It has worked before. Not sure if this is a ST or CoRE thing though.
I think Iâve been having this problem. Time restriction ends at sunset even though I tell it sunset plus 60. I think the offsets donât work, but want to get good debug captured.
Okay, so same thing happend this morning. I think I narrowed it down a bit:
I tried to set a custom time that would be just less than 60 minutes from the actual time:

And as you can see here, I got a time mismatch:

Then I tried to the set the custom time so that it would be just above 60 minutes from the actual time:
And that worked:
The local variables shows the right time though, so I am not sure what is going on.
Also there seems to be something wrong with the offset. If there is no offset at all (also no offset at sunset) then it seems to work. Maybe the offset at sunset subtracts/adds to the time at the sunrise part, I am not sure.
EDIT: Yes, that is exactly what is happening. If I remove the offset at sunset, then the end time is working.
If I create an offset of 120 minutes in the start time, then the end time is 120 minutes wrong as well.
EDIT#2: When I change the end time to âSunriseâ no matter what I enter in offset (-600 or +600) gives me Time mismatch.
So there is definitely something wrong.
if you choose anythibg other than custom time the offset field will reappear. Is that set to 60 by any chance? Custom time is not supposed to have an offset, but I have a feeling it still respects it. Bug.
Hey all,
So yesterday I left the house, my leaving Piston fired as expected, had to return home to put the chicken food out and found some of the lights had been turned off and others were still on. All of the lights showed on in the ST App (Things) This tells me a couple things
@ady624, Adrian, ST support is saying itâs a CoRE issue so far, not sure I entirely buy it but donât know what else to try
Rick
How many devices did you have per action in your piston?
Iâve seen that having too many causes failures so Iâve broken mine up into multiple groups of devices.
See the bottom two sections in this piston.
Rick, are you able to manually control the bulbs? On and off? I had two bulbs that recently dropped out. Also, since youâre saying that the ST app is showing the wrong state (not updating the state), I would disable the command optimizations in the piston - by default, a piston wonât ask a bulb to turn off if ST thinks itâs already off. And since ST thinks wrong⌠both about the bulb state and CoREâs faultâŚ

Well, the bulbs came pre-paired with the Hue Hub - so in order to remove them from the Hue Hub, I bought a Lutron remote control from Home Depot It allowed me to remove the lights from the Hue Hub and it would allow me to remove them from ST if I had too. So I can freely move them to any hub I want with just a few clicks (go next to the bulb, hold the top button until the bulb flashes and the remote stops flashing some seconds later - this connects the remote to the bulb, then go next to the bulb again - 4in or closer - and press the UP and the OFF (bottom) buttons and hold until the bulb flashes and resets - at this point you can move the bulb to any hub you like)
That was a confirmed bug, where the from offset also applied to the to time. Update to latest please.
v0.3.156.20160926 - RC - Fixed a bug that was bleeding the time from offset into the time to for piston restrictions
Pistons, where are they stored?
Today (and sometimes earlier) parts of the information in a piston is not showing up.
The last day some of the pistons stopped working as intended at temperature changes measured in a sensor.
Entering a piston from Dashboard sometimes does not show any information at times.
So the startup question is, is all pistons store on Samsung servers, or locally.
Second question, is there more systems out there having strange issues the last day?
@ady624 I noticed that youâve recently added support for usedCode for Locks from the data field. This will be useful for users if they want to take action based on which user unlocked the code. While the stock DH only reports usedCode for keypad based unlocked entries the Enhanced Universal Z-Wave Lock DH also reports the usedCode for lock events (where a keypad is used). So I think that this functionality would be would be useful for those using the Enhanced DH.
However one of the serious shortcomings of the stock DH is that it doesnât capture or report non keypad based events, with a slew of new technologies locks are now sending events for RFID and other technologies also. The Enhanced Z-Wave Lock DH does capture these events also and report them under an extension of the data field in a variable called type. If you added support (conditional because it would depends on the underlying DH, Enhanced or Stock) users can use this information to make decisions based on the type of event. The type field contains values to indicate the source of the event, e.g. manual, keypad, remote, rfid and auto (and may expand in future to encapsulate newer technologies).
For example locks have keypad, remote, auto and rfid types of lock/unlock events. User codes can be entered via RFID or Keypad to unlock and lock. This extension allows them to take actions based on a RFID user vs a keypad user or maybe an auto vs remote vs manual event.
Hey Jason,
8 total lights all in one action/group. What is too many from your experience?
Thanks, Rick
Adrian,
Yes, all lights work through the ST App w/o issue. I did have a couple lights several weeks ago that became orphaned, re-connected them and all has been well since. Also note, all lights shut off each night with a Good Night routine and have never failed (that I recall) and we have been using this routine since Dec.
I will try the command optimizations as you suggested
Thanks, Rick
Adrian,
Command Optimization was disabled already in that Piston, so I enabled it, what can it hurt I was thinking
More to followâŚ
Rick
HI,
is there a way of copying pistons?
I wan to transfer a few over to my parents setup.
Thanks.
No way to copy pistons yet. Sorry.