That’s exactly how mine works, one thing I would change is to add a delay to the close OR as well.
So door opens, 10 second delay before virtual contact opens, that’s what sets off SHM. You get a 10 second delay for the rest of the piston to disable the alarm basically, if the code entered was not valid or the door is just opened, the virtual contact opening after 10 seconds will trigger the alarm.
The only thing disarming the alarm is if a valid code is entered.
SHM does this already. When it arms after we all leave, I get a message if one of my contact sensors is still open.
I am not using SHM for security. I am still using SmartAlarm for the delays. I did try to set up a custom monitoring rule under SHM but Under the Custom ‘New Monitoring Rule’ portion of SHM I only see an option to get notified if a ‘sensor opens’ but not an option to get notified if a sensor is already open when the mode changes.
Thanks - I will try that out. I never played around at all with the Matching Device List option but it appears more straightforward than using variables.
SHM has it baked in, no option. It’s like a “real” alarm and sends an ST app notification if a checked sensor is not in the state it thinks it should be as it arms.
As long as SHM is configured with your sensors and SmartAlarm is arming/disarming, I’d think SHM would still send the notification.
Yes, the non/matching device store to variable makes it easier.
@Snakedog116, what switches are you using to manually turn on the lights? Like Michael mentioned, you need switches that support Physical/Programmatic ability … e.g., the GE switches.
I also do like the idea of having a certain percent of dim that is excluded from the motion trigger like @tatonvn mentioned. If you are ok with it always being on at say 99%, make that a condition, if light is less than 99% and motion, turn on, then for the off portion, if light is less than 99% turn off after 5 minutes. You have to turn it on at 99 or 100% with app or voice, but that would work if the switch is a dimmer and doesn’t support physical.
The problem i have is the colours in core dont seem to be accurate when working with my OSRAM bulbs. So i cant find one that’s a simple daytime orange (none led look) light mode.
When i set to to day gold and then set the level to 100% it drops to 50% and ive no idea why
Has anyone else had a problem with pistons not changing the mode? I have a piston that should put my house in home when im home and away when im out. I have checked the true/false status and they are triggering correctly. however, the mode does not change.
Any ideas or suggestions?
Could you explain what does not work if you do not set the restriction?
Hi @ady624 , are you able give your 2 cents on my issue here?
In short, I can select a pre-defined-color from CoRE, but trying to use the HSL values from the CoRE code for those same colors does not work for me. Why the difference?
I’m using Osram with “ZLL RGBW Bulb”-DH, if that makes a difference.
CoRE expects real HSL, where H is the hue in 0-360 degrees, S is saturation in 0-100 percent, L is the level in 0-100 percent. Are you providing the hue in percent by any chance?
SmartThings uses level as part of the color - when setting a color, you’re inherently setting HUE, SATURATION, and LEVEL. That may explain why your level changes unexpectedly. Changing the level manually after that will change the color. Higher level means brighter color, lower level means darker colors.
Yes, what I’m trying to do is make my light turn on and off when I walk by it. But the issue is that sometimes if we are sitting watching TV we aren’t moving much and the so the light will turn on for us, but then turn itself off a couple minutes later. Then I’m sitting there as my wife gets annoyed and I’m waving my arms around so that the motion sensor picks me up and the lights turn back on.
So what I’d like is to be able to have a program that says: If the lights aren’t already on, and motions starts, then turn the light on, dim it, and if there sill isn’t motion, then turn the light off.
But, if the light is already on, then leave it on.
So if I put the restriction in the ‘If’ area of the piston then as soon as the light turns on the piston is now false and will turn off even if I’m moving around.
In the ‘then’ area I’m able to put a restriction without it affecting the true-false state of the piston. So if the motion doesn’t stop the lights won’t turn off. But if the lights were already on to begin with then the ‘then’ part of the piston won’t execute.
Perhaps the issue is with the ‘wait until piston state change’. Is there a way to do ‘wait until no motion’ in the ‘then’ section of a piston? I don’t see it.
I believe so yes, I copies the HSL values from your CoRE code from the color “Light Sky Blue” with the values
h: 203, s: 92, l: 75.
Those should work right?
I’m going to play around with this tonight. I’m thinking that two if/then statements might be the way to go:
As long as you don’t manually turn the light on to 99% a manual setting would then not be affected by motion or a stoppage of motion.
To do this I would use a an or-if piston right?
Latching is my recommendation. #1 is the IF then #2 is the But If. You’ll want two groups in the IF, one like you mention and one that’s just “on motion” and that’s it, so Piston state change can occur once the light is on, for when the sensor resets after 15-30 seconds, minute, whatever you use.
I have just been through this will Michael helping along the way. Check out my piston that also is turning on a light with motion. I was having the same issue with it turning off when no motion detected but we were still in the area.
