jfai

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

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.

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.

… or you could use a version of these programs

Regarding the scaling issues, this worked for me on Windows 10 + Java 8: 1. Find the Java web start executable: Right click on ISY Launcher shortcut More > Open file location In the explorer window right click on ISY Launcher Open file location javaws.exe in your JRE should be selected 2. Change DPI scaling behavior from Application to System: Right click on javaws.exe Properties > Compatibility > Change high DPI settings Check "Override high DPI scaling behavior. Scaling performed by:" Select "System" As far as I know, Java 9 should scale correctly without scaling performed by system.

They work as they should. Also, all sensors are powered by a central power supply with step-down converters at each sensor. No batteries here.

MultiSensor 6 https://aeotec.com/z-wave-sensor for short range. Zooz ZSE40 4-in-1 Sensor for longer range.

You're welcome.

Here are the programs for the "Ohana hallway": Ohana_hallway_lights_timed_on If ( // state: lights off or lights on timed $sOhana_hall_lights is 0 Or $sOhana_hall_lights is 1 ) And 'Ohana hallway / Ohana Hallway multi-sensor / Ohana hallway.Motion' is switched On And 'Ohana hallway / Ohana Hallway multi-sensor / Ohana hallway.multi-sensor' Luminance < '$Min_luminance_percent %' Then // state: lights on timed $sOhana_hall_lights = 1 // starts / restarts the lights on timer program Run Program 'Ohana_hallway_lights_on_timer' (If) Else - No Actions - (To add one, press 'Action') Enters the "lights on timed" state and (re-)starts the timer program. While motion is detected, the lights stay on for the programmed duration by restarting the timer program. This particular motion sensor is configured with a PIR period of 15 seconds. The sensor does not send "motion on" events repeatedly. A "no motion" event is sent only after no motion is detected for at least the configured PIR period. Ohana_hallway_lights_on_timer If // state: lights on timed $sOhana_hall_lights is 1 Then // state: lights on timed Set 'Ohana hallway / Ohana hallway lights' On // program ends if state is not "lights on timed". $Motion_ohana_hall_interval_count = $Motion_light_number_of_5s_intervals_on Repeat While $Motion_ohana_hall_interval_count > 0 Wait 5 seconds $Motion_ohana_hall_interval_count -= 1 // state: lights off Repeat While $sOhana_hall_lights is 1 Set 'Ohana hallway / Ohana hallway lights' Off $sOhana_hall_lights = 0 Else - No Actions - (To add one, press 'Action') Turns on the lights and keeps them on for some time. Then turns the lights off. The program stops if the state is no longer "lights on timed". Ohana_hallway_lights_force_on If // state: lights off OR lights on timed OR force off ( $sOhana_hall_lights is 0 Or $sOhana_hall_lights is 1 Or $sOhana_hall_lights is -1 ) And ( 'Ohana hallway / Ohana hallway lights' is switched On Or 'Ohana hallway / Dimmer at dining doorway' is switched On ) Then // state: force on // Stops WAIT of timer programs $sOhana_hall_lights = 2 Else - No Actions - (To add one, press 'Action') When one of the light switches is switched on, enters "force on" state. Switching the state stops any running timer programs. Ohana_hallway_lights_force_off If // state: lights on timed OR force on ( $sOhana_hall_lights is 1 Or $sOhana_hall_lights is 2 ) And ( 'Ohana hallway / Ohana hallway lights' is switched Off Or 'Ohana hallway / Dimmer at dining doorway' is switched Off ) Then // state: force off // Stops WAIT of timer programs $sOhana_hall_lights = -1 Run Program 'Ohana_hallway_lights_forced_off_timer' (If) Else - No Actions - (To add one, press 'Action') When one of the light switches is switched off, (re-)starts the "force off" timer program. Ohana_hallway_lights_forced_off_timer If // state: force off $sOhana_hall_lights is -1 Then // program ends if state is not "forced off" $Motion_ohana_hall_interval_count = $Motion_light_number_of_5s_intervals_off Repeat While $Motion_ohana_hall_interval_count > 0 Wait 5 seconds $Motion_ohana_hall_interval_count -= 1 // state: lights off Repeat 1 times $sOhana_hall_lights = 0 Else - No Actions - (To add one, press 'Action') Waits for some time before lights can be turned on by motion. The timer stops when the state changes to any state but "force off".

All my hallways have motion sensors and the lights are controlled such that: · Switch on the lights when motion is detected and the area is dark (variable "Min_luminance_percent"). · Switch off the lights when no more motion is detected and the lights were on long enough. The duration is variable “Motion_light_number_of_5s_intervals_on” times five seconds. · Force the lights on with the wall switches - motion is ignored. · Force the lights off with the wall switches and ignore motion for some duration. The duration is variable “Motion_light_number_of_5s_intervals_off” times five seconds. Note the state "force off" in the attached FA diagram. I think you're trying to implement a similar use case. Let me know if you're interested and I will post the ISY programs that implement this state machine diagram. You should be able to modify the programs to suit your needs.