jfai

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.

I don't know how UDI is implementing the next generation U/I but I'm willing to bet that it won't be pure HTML/CSS. My money is on some kind of JavaScript framework, and most of those obfuscate & "minify" the JavaScript files as part of packaging. Good luck trying to hack those...

Do you know what security protocol HA uses on the port that you opened to the world? If not, I would use a VPN instead, e.g., OpenVPN. At least you know that tons of people are using the same VPN implementation and that most security flaws have been found and fixed.

Maybe most people don't want to provide information and incentives to total strangers or would-be burglars? I'd rather have them break into the house with the Youtube channel than into mine. ?

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...

There is no need for port forwarding to the ISY, nor a DDNS service. The UDI Portal and the ISY have a bi-directional connection (websocket). There's no need to install any applications on the device(s). All modern consumer computing devices including all mobiles in the last 5+ years come with a web browser already installed. All you need is a UDI Portal subscription. Then browse to UDI Portal, then Go to my ISY > Elk > Arm Away (or whatever) .

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...

It appears that just using the "Elk" URL of the ISY's in-built webserver is much easier: UDI Portal > Go to my ISY > Elk > Arm Away (or whatever) No expenses (besides the UDI Portal subscription), no configuration, it just works.

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.