jfai

The 'Overnight' program runs Else each time the motion sensor turns off (time doesn't matter). I suspect that's not what you intended. If the lights should turn off when the motion sensor turns off, you need to have a separate program.

Marvelous! Scenes don't work right. "On" or "Fast on" just turn every device on. Maybe I don't get the UX. See closed issue.

Correct. Correct: an integer variable as the sole condition will not trigger evaluation of the condition. However, another program could use Run(If), and there may be a reason to split the programs. An integer variable OR'ed with other conditions is not uncommon, e.g., checking some kind of configurable threshold. Therefore: it depends on what you're trying to do. There are many ways to slay a dragon. ?

Checking the last run time for ">" instead of "=" isn't much better. You'll get an email at 6 am every day. And then maybe once or twice throughout the day, but at seemingly random times. I doubt that's the intent of the program. Assumptions: The program was run the first time "manually" once after 6 am (otherwise it won't run until 6 pm the same day, and then it won't send the email). Let's say the program ran at 10 am. No email will be sent because the "time > last run + 1 hour" is false. The temperature updates happen at 15-minute intervals starting on the hour and the temperature changes each time (unlikely, but it's the worst case scenario). At 10:15, "time > last run + 1 hour" (= 11:00) is false. No email. At 10:30, "time > last run + 1 hour" (= 11:15) is false. No email. etc: the "time > last run + 1 hour" condition will only be true if the temperature doesn't change for at least 60 minutes, which may or may not happen. At 18:00, the time-of-day condition is false. No email.

What are you disagreeing with? Do you have another explanation why the email isn't sent?

Unless the temperature changes at exactly 1 hour after the last time the program ran, the condition won't be true. In other words, this program's condition is almost never true, except at 6 am each day. The temperature update occurs at most every 15 minutes. Therefore, the program condition is evaluated at most 48 + 2 times a day. The temperature may not change every 15 minutes, so the actual number of condition evaluation is most likely less than 50.

@gspitaleDo you already have the blinds and motors installed? The motors dictate the remote control options - unless you want to replace the control module plugged into the motor ($$$). So, if you want direct Z-wave control of the motor, you do not need the ZRTSI, but your motors need to have a Z-Wave control module. If you have RTS motors, you have the option of ZRTSI, URTSII, or myLink, but not direct Z-Wave. Unless I misunderstand your requirement, this can be done with all remote control options. A channel is a set of motors. Motors can be in any number of channels. Additionally, myLink has the concept of scenes. A myLink scene is a set of motor-position combinations. With myLink you can also define schedules for your scenes - no ISY programming required. I used that for a while until my shade/curtains automation "requirements" grew beyond just time-of-day conditions.

All your devices connected to the ISY and the ISY itself are controllers / microprocessors of some kind. I was writing about the ISY, since it's behavior in your use case was the topic of the thread. UDI could change the programming model of the ISY to what you want - which isn't necessarily what other people want - with breaking changes for all existing programs that use sensors. I doubt that'll happen anytime soon. You have many options at this point, including but not limited to: Use more than one program for your use case - see above. Write / Find a Polyglot Nodeserver that interfaces with your temperature sensors just the way you like. Maybe other people would like your Nodeserver and use it too. Use a different HA controller - with different quirks due to its unique programming model. Rinse and repeat ?

1. Every controller is implementing a defined programming model. The ISY evaluates the IF condition every time it hits a WAIT. That has always been that way since conception. 2. Sensors have many use cases, not just checking thresholds. For example, sometimes you'll want to know the rate of change, or just simply calculate a moving average for later graphing. 3. You could move the threshold logic of your program into the sensor. Many of the temperature sensors out there allow programming of the minimum/maximum reporting range, as well as hysteresis behavior.

How would you define "status" vs. "control" for a multi-valued sensor? It doesn't support the concept of "DON" and "DOFF", it just reports a measured value.

Put the temperature into an integer variable and reference the variable in the notification. P.S. Temperature sensors (and other sensors, like luminance) have always worked this way in the V5 firmware. Not sure about V4 - didn't have any sensors until a few years ago...

See earlier post about similar use case.

Depends what you use as trigger for the routine. If its the motion sensor through the portal, then you don't even need a program. Otherwise it depends on the program and how the sensor influences the program.

Alexa debounces sensor values over the course of 30 seconds. In other words, once Alexa sees the first sensor value change, it ignores all changes to the same sensor until 30 seconds have elapsed. "Sensor" here is anything that can be used as a trigger in an Alexa routine. For example, let's say you have two routines for your mailbox. The sensor is an Elk zone dry contact that is closed when the mailbox door is closed. When mailbox sensor opens, say "Mailbox opened" When mailbox sensor closes, say "Mailbox closed" Mail carrier opens the mailbox, drops the mail, and closes the mailbox after 15 seconds. You'll hear Alexa announcing "Mailbox opened", and after 30 seconds you'll hear "Mailbox closed". Mail carrier opens the mailbox, drops the mail, and closes the mailbox after 45 seconds. You'll hear Alexa announcing "Mailbox opened", and after 45 seconds you'll hear "Mailbox closed". Mail carrier opens the mailbox, drops the mail, and closes the mailbox after 10 seconds. Then the carrier opens the mailbox again after 5 seconds for 10 seconds. You'll hear Alexa announcing "Mailbox opened", and after 30 seconds you'll hear "Mailbox closed". The second set of opening and closing is not triggering the routines.

The Z-Wave Somfy interface is limited. As mentioned, "stop" and "My" commands are not supported. That was one reason I decided to use the Somfy myLink devices with RTS motors instead - see previous posts in this thread.

It's a large, heavy door. You need to worry about liability for personal injury. Whatever you do, your son needs to have direct line of sight of the garage door while operating it and that's hard to enforce with just geofencing. I think, you'll find that it's going to be a compromise kind of solution...

How about giving him a keychain remote for the GDO? Of course, if he loses his keychain, you have to worry about more than just your garage door...

The WAIT statement semantics are documented. The implementation is solid. If you want to program the ISY, it's best to understand how ISY statements and programs work, otherwise the outcome may surprise you. Wiki away to your heart's content...

The program works as is. The Armed with Exit Timer interrupts the Wait statement and the program condition is reevaluated, which in turn causes the Else branch to run, i.e., the program ends. The second Armed Fully event triggers the program, and the Then branch executes. After 3 seconds, the notification is sent.

I don't use the URTSII. If you can operate the shades by pressing buttons on the URTSII, then the issue is between the nodeserver and the URTSII, e.g. bit rate, number of error correction bits, pin out, cable termination,, etc.

All Somfy motors are available with RS485.

… and don't forget at least 18/4 to every window and patio door for possible motorized window treatments. Even better, add a home run of Cat5e in case you don't like RF-controlled motors. For runs to windows that are longer than about 80-100 feet, use 16/4. Additionally, think about possible locations of motion sensors and run 20/4 to each of these. Battery-powered devices need to be avoided... Don't forget a run of Cat5e to the mailbox, the doorbell/intercom locations, the irrigation controller, the garage opener, whole house filter, solar system and house battery inverter/controller. If you have large open living spaces (e.g. "Great room"), think about seating arrangements and put a couple in-floor outlets there.

What do you mean by "at best run sequentially"? Maybe your optimized state machine would work. You'd have to test. As I wrote, by and large I don't find optimizations worthwhile. One more advice: I would not add the dimmer control commands to the state transition programs and rather use the state variable as trigger in separate programs (separation of concerns).

The ISY programming language is geared towards event-driven state machines. Here's a state diagram for your use case (UML): It's straightforward to implement this state machine with the ISY. The state ids are values of an ISY state variable (sTapState). The state transitions are implemented by ISY programs. ISY pseudo code: Program "First tap" if $sTapState is 0 and iolinc.sensor is on then $sTapState = 1 Program "Idle after one tap" if $sTapState = 1 then wait 2s $sTapState = 0 Program "Second tap" if $sTapState = 1 and iolinc.sensor is on then $sTapState = 2 Program "Idle after two taps" if $sTapState = 2 then wait 1s $sTapState = 0 You can use sTapState as condition in other programs, e.g., to set the on level of the dimmer. These programs can probably be "optimized" by using special features of the ISY language (e.g. conditions based on the time elapsed since the last time a program ran, program condition, enabling/disabling programs), but I usually don't bother with optimizations. When the ISY restarts, variables are set to their "init values", which by default is 0, which is the state id of the start state. WAIT statements have special semantics: they cause reevaluation of the program condition and depending on the result may stop program execution - refer to the Wiki.

Variable name Purpose cCoat_closet_fan_off_temperature Temperature at or below which the fan turns off [⁰F]. Set to 92.0 Invariant: cCoat_closet_fan_off_temperature < cCoat_closet_fan_on_temperature cCoat_closet_fan_on_temperature Temperature at or above which the fan turns on [⁰F]. Set to 93.0 Invariant: cCoat_closet_fan_off_temperature < cCoat_closet_fan_on_temperature Coat closet fan on when hot If 'Foyer / Coat closet multi-sensor' Temperature > '$cCoat_closet_fan_on_temperature Fahrenheit' Then $sCoat_closet_fan = 1 Else - No Actions - (To add one, press 'Action') Sets the state variable to the "fan on" state if the temperature is above the upper limit. Coat closet fan off when cool If 'Foyer / Coat closet multi-sensor' Temperature < '$cCoat_closet_fan_off_temperature Fahrenheit' Then $sCoat_closet_fan = 0 Else - No Actions - (To add one, press 'Action') Sets the state variable to the "fan off" state if the temperature is below the lower limit. Coat closet fan on/off If $sCoat_closet_fan is 0 Then Wait 10 seconds Set 'Foyer / Coat closet vent fan' Off Else Wait 10 seconds Set 'Foyer / Coat closet vent fan' On Turns the fan in the coat closet on or off depending on the value of the state variable. The delays make sure that the fan runs at least a certain amount of time (debouncing).