jfai

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

@auger66 Somfy recommends that a RTS transmitter is no more than 25-35 feet away from the receivers, although most RTS transmitters claim longer range under ideal conditions, i.e., not in any real house. In practice, this means that you'll need a myLink in every large room, or at least for each zone of rooms where all motors linked to that myLink are within 25-35 feet. Additionally, myLink connects over 2.4 GHz Wi-Fi, therefore the quality of Wi-Fi connectivity needs to be considered at the myLink location. If you use network resources to send TCP commands to myLink, make sure that you only send one command concurrently to any of the myLinks in the system. myLink doesn't like overlapping requests. This is actually not trivial to achieve with a controller like ISY due to the nature of an event-based system. You may find yourself having several, independent ISY programs that send myLink commands and synchronizing those programs isn't really straightforward nor desirable. I have an installation with two myLinks and 20+ motors and reliability is very good, albeit not perfect. There is this one particular curtain motor which doesn't receive a request maybe 1 out of 50 times. The motor is on the same wall as the myLink, about 12 feet away, across a patio door. The motor is part of a myLink scene with other motors, and all the other motors are much further away. Such is the nature of RF. By the way, my ISY does not send TCP commands to myLink directly, instead I run a relay service (on the Polisy), as I have mentioned several times in this thread and others.

UDI Mobile, IFTTT, Alexa, MacroDroid - I've tried them all with various Android versions and 4 different phones and none of them is sufficiently reliable when it comes to geofencing. At one point I implemented a "3 out of 4" algorithm using 3 location apps and a Wi-Fi connectivity sensor. That worked, but the additional complexity wasn't warranted. Now I'm using MacroDroid geofencing and Wi-Fi connectivity together with the Occupancy 2 node server. Straightforward and reliable.

The alternatives to integrate ISY with RTS motors through myLink: ISY ---> TCP N.R. ---> myLink ---> RTS motor ISY ---> HTTP N.R. ---> myLink ---> RTS motor (requires an HTTP-to-TCP service - I haven't published mine) ISY ---> Polyglot myLink N.S. ---> myLink ---> RTS motor (requires a myLink node server - needs to be developed) The Tahoma hub would replace the myLink device(s). How the Tahoma hub connects to the ISY is not knowable, unless the Tahoma API is published by Somfy. I would expect that the Tahoma hub is more expensive than myLink because it has more capabilities as a home automation hub. Somfy Tahoma uses ZigBee and is targeted at larger installations for homes larger than 7000 sq.ft. or more than 10 rooms/zones with Somfy motors. I don't know if Tahoma can be used for RTS motors. One myLink can handle up to 16 RTS channels and you can join up to 10 myLinks for multi-zone control.

Somfy Tahoma is their attempt to get into home automation and you'll need to purchase their hub. Why would you want another hub in addition to the ISY? I can't imagine that their hub will be more cost-effective than the myLink. Historically, Somfy's APIs are closed to the general public. They only support higher- end automation partners. I've tried to contact them several times about the Synergy (myLink) API, with no results. I had to search long and wide to find authorative information about the Synergy API in the public domain.

Yup, that works - most of the time. myLink is connected to the network with Wi-Fi (2.4 GHz only). myLink RTS is radio-frequency. Depending on your Wi-Fi coverage, locations of the myLink devices, locations of the Somfy motors, the myLink commands will be missed by the motors, or some myLink device isn't reachable. You also need to make sure that no two ISY programs send commands to the myLink devices concurrently or even too close together. Coding the myLink device/scene id into the network resource is error-prone when you make changes to the myLink registrations. The service deals with device discovery, command retries, throttling, name mapping, logging of command results/errors, among other things.

I developed and am using at my home for a few months a server that accepts HTTP requests from the ISY (Network Resources). The server translates HTTP requests into the Somfy Synergy commands required to control Somfy myLink devices on the local network. myLink scenes and individual devices are controllable and addressable by id, name, or alias. Sample network resource definition to run a myLink scene with 4 shade motors and 2 curtain motors: POST /mylink/command HTTP/1.1 Host: 192.168.0.32:3300 Content-Type: application/json {"command":"scene","target":"GreatDay"} This was the first stage of developing a robust node server for Somfy myLink. The next stage would be to interface with Polyglot. There doesn't appear to be much demand for a Polyglot node server for myLink. A quick survey of Somfy motor references in the UDI forums for the last two years or so: Z-wave - 5 (3 undecided) myLink - 4 (2 undecided) ZRTSI - 3 URTSII - 2 Tahoma - 1 (1 undecided) Other - 3 (3 undecided) ------ Total - 18 (9 undecided) What's your budget for a Somfy myLink nodeserver?