jfai

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

yes(disconnect from panel) and yes (one sensor at a time)

Measure the resistance between the bare sensor wire ends with the sensor open and closed. That will tell you if any resistors are present at the sensor and the configuration (single or double EOL).

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?

I don't use these node servers - I was writing to help you understand how Polyglot fits with the portal and the ISY. You may want to check the sub-forums dedicated to each of the node servers.

Polyglot is a "container" for node servers. It has an administration user interface, separate from the ISY administration user interface. Node servers are adapters - implemented as executables - that speak device API on one side and speak ISY API on the other side. There are two Polyglot implementations: one runs in the "cloud" - hence named Polyglot Cloud, PGC - and it connects to your ISY via the ISY Portal. The other implementation runs locally on a device separate from your ISY, like Polisy, or a Raspberry Pi. The local Polyglot connects to your ISY via your local network. The two Polyglot implementations are separate and use slightly different APIs. Once you install a node server to one of the Polyglot environments, and add it to a slot in your ISY, the nodes implemented by the node server show up in the ISY administration console, just like the other nodes representing Insteon, X10, Z-Wave/ZigBee devices, and all of them can be used in ISY programs.

Generally speaking, for maximum interest and addressing the most use cases, the U/I needs to be designed using a "mobile first" approach. It needs to be usable on a small (phone) screen, yet scale well on larger screens, with an reactive layout. The majority of users (90+ %) will expect an "app" for their mobile devices, rather than a desktop/laptop application. On mobile platforms, the majority of users (90+ %) won't care if the app is native or HTML5 - they don't know the difference and don't care.

The 30 s is enforced for sensor value changes. If someone triggers the motion sensor/camera, there is no delay, unless the last state change of that sensor was less than 30 s ago. Most sensors have a debounce period built in, either in the control electronics or the firmware. The debounce period varies depending on sensor purpose from several milliseconds to 10s of seconds, e.g., motion sensors. Amazon's delay is at the higher end of the range, but it's still workable for most smart home applications.

Most likely you will face two issues for retrofitting cellular blinds/roller shades. The brackets for Somfy RTS motors could be different from the existing brackets. They may not only be mechanically incompatible, but also may require different widths of the tube/fabric. This definitely is an issue for inside mounting. You may be able to use adapters for the existing brackets, but the adapters will require extra room. The tube diameter needs to be correct for the desired RTS motor. As long as the tubes of your blinds/shades have the correct diameter for the Somfy motor, you will be able to retrofit. Even if the tube diameter is wrong, you could swap out the tube and reuse the existing fabric - tedious but doable. I've done it for a couple of roller shades - no experience with cellular blinds. Besides the motor with its included crown, you will also need the idler part. If you have a choice, stay away from cordless motors. They are much more noisy (comparing Sonesse ST30 and Sonesse 30 Wirefree) and if you have a bunch of them, taking care of the battery recharging can become cumbersome, especially if you don't have an outlet close to the motor. The longest charging cable is about 10 ft. For each wired RTS motor, you'll need to provide 24 VDC power through a 2-conductor wire (>= 18 gauge). You can either run the wire to a central power supply or have a 'wall wart' in an outlet at each window. Before you start ordering, make sure you understand the retrofit path.

+1

See this post

The ISY has system values for “day of month”, “month”, “year” and so on, but these system values cannot be used in program conditions directly: the values need to be stored in program variables first. Then these variables can be used for programs and folders in conditions for partial dates, e.g., “if day-month is 16-12 then …”, which is supposed to run the program’s then block yearly on December 16th. A program runs daily at midnight which sets these integer variables to the numbers of today’s date: · Date_day_of_month · Date_month · Date_year Before the integer variables are set, the program sets the state variable “$sDate_valid” to 0, which indicates invalid date variable values during the date change. Once the date variables are all set, the state variable is set to 1, which indicates that the date variables are valid. Program and folder conditions can be constructed by combining the state variable “$sDate_valid” with the date variables. Program: Set day month year [Run At Startup] If Time is 12:00:00AM Then $sDate_valid = 0 $Date_day_of_month = [Current Day of Month] $Date_month = [Current Month (Jan=1, Feb=2, etc.)] $Date_year = [Current Year ] $Date_day_of_month Init To $Date_day_of_month $Date_month Init To $Date_month $Date_year Init To $Date_year Wait 1 second $sDate_valid = 1 Else - No Actions - (To add one, press 'Action') At midnight every day, sets the variables for the date. Indicates that a date change was completed and that the date variable values are again valid. Also sets the variable init values, so that the correct date values are restored in case of a reboot. Example: Folder Conditions for 'Christmas time' If $sDate_valid is 1 And ( ( $Date_month is 11 And $Date_day_of_month >= 21 ) Or $Date_month is 12 Or ( $Date_month is 1 And $Date_day_of_month <= 15 ) ) Then Allow the programs in this folder to run. Allows the programs in this folder to run from November 21 through January 15 every year. Happy holidays!

You could adapt these programs: Motion sensor, lights, timers

You could adapt these programs:

Had to make the same decision a while back and went with Somfy MyLink. The other options require additional hardware for connecting to a controller like the ISY. The MyLink device works standalone: you can set up simple scenes and schedules without ISY integration. I'm adding more and more Somfy motors in my house and am working on a nodeserver for MyLink as well.

@Michel Kohanim What's the power consumption of the two Polisy systems? What are the operating temperature requirements?

Exposing your alarm system to the Internet in any way is equivalent to mounting an alarm keypad at the outside of your house - in a dark corner that is accessible from the street and which you cannot surveil. Would you be comfortable with that? IMHO, the risks outweigh any convenience gains.

Example: Away status If $sAway is 1 Then Wait 1 second Set 'Away scenes / Away Status' On Resource 'Send away mode change to Stringify' Resource 'Away mode status' Set Elk Speak Word 'Away' Set Elk Speak Word 'Mode' Else Wait 1 second Set 'Away scenes / Away Status' Off Resource 'Send away mode change to Stringify' Resource 'Away mode status' Set Elk Speak Word 'Home' Set Elk Speak Word 'Mode' Reflects the value of managed state variable "State_Away". This is a separate program from "Away mode on" and "Away mode off", so that the variable value is indicated at the keypad even if the variable value is changed without operating the keypad button, e.g., using this client. The scene "Away status" contains the keypad button used to turn the away mode on/off.