KeviNH

I'd still try adding the wait statements, see if the false alarms go away.

I'd recommend rewriting your program slightly, and also making a custom notification that reports the heating mode of each thermostat. For example, for my ZWave thermostat I put this text in the notification: "Upstairs thermostat mode is ${sys.node.ZW003_1.CLIHCS}". Do this for each thermostat, and you'll know which one is triggering your program. I would write the program like this: Wait 1 minute Send notification "Mode is not heat...." (including current modes) Wait 1 minute Set mode to heat.... Send notification "I reset the mode to heat...." (including current modes) Set mode heat thermostat1 .... The waits are important, especially for the first notification -- because the notification is delivered by a separate task, if you call send notify and then immediately change the value of one of the items that is a variable in the notification, it's a race condition and sometimes your notification text will have the new value that was just set, not the old value as of the time the program was triggered. Waiting even a few seconds avoids this. The second wait ensures that the actions following the Wait will not be performed if the Conditions ('If') change. So if the problem clears itself up, you will not get the "I reset the mode to heat..." message.

I think the easiest approach would be IFTTT and the "Do" button app. There's also an easy workaround on Android, works with most apps -- you log into Google Play under the account that bought the App, download it, then log out. Or better yet, make a new Gmail account named "WetCoastWillieFamily" and just use that account when buying apps.

That's a cool one, I didn't know IFTT could directly receive SMS. I see that it requires registering the sending phone number, and only allows one phone number per IFTTT account, so that could be difficult for OP's household use requirement. Still, a cool feature in IFTTT!

Reading SMS messaging might be tricky. Why not use IFTTT and the "DO" button? IFTTT/DO apps are free, and integrate with the Portal to control your ISY from anywhere. I wrote a daemon that can run on rPi and enables control from Twitter direct messages,-- you tell it which twitter accounts to trust to send commands. With a little programming it could restrict commands to specific users only. My daemon runs in the local network (e.g. on rPi or maybe MacOS). To make usage easier, the twitter messages can be sent under IFTTT control (e.g. from a "Do" button). Because it runs on a rPi in your network and makes REST calls directly to the ISY, no requirement for Portal or network module or exposing your ISY password. I rewrote the daemon ingest direct messages with "User Streams", so it can react immediately to a command, maybe someday I'll port it from Perl to Python.

There are advantages to defining a separate program with no conditions, and calling it using "RunThen" from another program. For one, a program with "Wait" statements inside results in the "If" conditions being re-evaluated after every wait ends; if the "If" statement is false when re-evaluated, the program terminates early. This is one of the little idiosyncrasies of ISY programming that takes a while to learn and get used to working around. As a programmer, it helps to think of the ISY as sort of a big state machine.

Makes sense to me. I'm slowly transitioning my wireless motion sensors over to Z-Wave, but have a few triggerlincs for contact closure, guess I'll need to find an Everspring SM103?

I'd love to see UDI partner with a PWS vendor! Would be great if ISY994 could provide plug-and-play integration with a home weather monitor. Could still use HAM for forecast, but override the "current conditions" values automatically with whatever sensors you have at home. So if I have a rain gauge, temperature, and humidity sensor, I get those local values from my PWS and use the HAM values for everything else.

You can use Z-wave "parameters" to set an offset for the sensors in the multi-sensor 6.

That's what i'm waiting for to even consider making the jump to V5. Considering that my ISY does things like keep pets fed, I generally don't run beta code. If you just want them to end up full-on or full-off, why get fancy? Almost Sunset If Time Is Sunset - 30 minutes Then Run Program 'Fade Up Exterior' (Then Path) Fade Up Exterior If (NO CONDITION) Then Set 'ZwaveExteriorDimmer' 1% Repeat 50 times Set 'ZwaveExteriorDimmer' Brighten Wait 36 seconds, The above is primitive, works in 4.x.x , and compatible with just about any dimmer, Insteon or Zwave, as long as "Brighten" just steps up 1 level. Many of these Z-Wave dimmers have built-in fade-up and fade-down functionality, you just need to set the appropriate parameters. I think the slowest supported fade would be P7=99 and P8=255, taking about 5 minutes to execute.

Wiring up a new thermostat is pretty easy on most systems, just need to go slow and label everything. This is key -- take a picture of the wiring going into the thermostat. The color of the wiring insulation can vary, and isn't the key point. If you look carefully at your thermostat, a newer one will have molded or printed labels where each wire is connected, something like "C", "R", "Y1", "G", "W2". I take a labelmaker and label each wire, while it is still attached, with the corresponding letter code for the terminal it is connected to. Then you just need to connect to the same-labeled terminals on the new thermostat.

If you want to learn rPi and maintain a little Linux box, then there is certainly more flexibility with the Pi solution than with a dedicated MP3 board, see my post above about text-to-speech.

So you're saying the thermostat is controlled by the ISY994, but is on the first floor,doesn't know you need heat on the second floor, because there is no thermostat upstairs? You want a way to detect that the upstairs is too cold? The cheapest solution would be to dig out an old mercury switch wall mount thermostat (free!) and connect it to an insteon open close sensor. Better yet, if you have Z-Wave module, get a multisensor (one that's known to work well with ISY). I use two different models of Aeotec, powered off USB adapters. Seems many people use the Insteon 2441ZTH as a remote sensor for their Insteon thermostats, usually with a 2441TH?

Not sure if "undo" is achievable. I think I get what you want to accomplish, I have a "Goodnight" button myself. What you maybe could do is have 2 programs involved. The "Goodnight" button would run a program "SetGoodnight" that XORs a variable "S.GoodNight_Requested" and plays some beeps at every keypad that has the button. Then a separate program with conditions of "Time is 45 seconds after Last Run of SetGoodNight. And S.GoodNight_Requested == 1" does the actual work. So if you press the Goodnight button accidentally, just press the same button again within 45 seconds, and the upcoming lighting change is cancelled.

Doesn't look like it. What I would do is add "And Program 'Lights On in Evening' is False" to the conditions for my "Turn off Garage Lights When Door Closes" program; this way the program doesn't run if the other program is currently true. I also have programs that exist just to provide a 'true' or 'false' statement for whether another program has run recently, like this: Garage Door Opened Recently If From Last Run Time for 'Garage Door Opened' To Last Run Time for 'Garage Door Opened' + 1 hour (same day) Then Wait 1 hour and 1 second This makes it easy to add And Program 'Garage Door Opened Recently' is False" as a condition for other programs, and I edit just one program to change the definition of "Recently" everywhere it is used (maybe I want to make it 30 minutes instead of an hour). I'm not sure if the wait does anything.

I suggest ignoring the "command line" link you included, it just makes things more confusing adds an extraneous layer of indirection. Instead, use curl to directly make REST calls to the ISY. Yes, you would write rules in Sighthound (Basic or Pro). I would make one rule for each camera, action would look like: curl.exe -ns http://10.3.3.3/rest/vars/set/2/9/1 Where 10.3.3.3 is your ISY's IP, and 9 is the number corresponding to the state variable for that camera. On the ISY994, I would make a state variable for each camera, e.g. $S.Cam1_SawPerson and $S.Cam2_SawPerson and then make an ISY program like this, one for each variable: Camera 1 If $S.Cam1_SawPerson > 0 Then Send Notification to 'WebPage' content 'WebPage Eventlog append Automated Event' Wait 1 minute $S.Cam1_SawPerson = 0 Comment: Camera 1 saw a person, so we log this and then clear the variable 1 minute later. Repeat the above for Camera2, Camera3, etc. Now you can write a program that has as a condition "$S.Cam1.SawPerson > 0 And $S.Cam2.SawPerson > 0". This program would only be true if both cameras saw a person within a minute of one another: Both cameras 1 and 2 If $S.Cam1_SawPerson > 0 And $S.Cam2_SawPerson > 0 Then Set 'KitchenLights' On Comment: Camera 1 & Camera 2 both saw a person, so turn on the light Basically, you are using the SightHound to increment state variables, and let the ISY deal with the AND logic and resetting the variables back to zero. This works better than directly calling programs, as you could, for example, have the second program only turn on the light if the time is after sunset.

I'm not sure Amazon Echo is the best tool for this job. If you want a ready-made text to speech solution, maybe look at Sonos? That said, if you have a Unix-like computer up and running (MacOS, rPi, Ubuntu, etc), I wrote a Unix listener script which can be triggered by a network resource to say anything or play an MP3. It does not use a cloud service, instead locally generates speech with the free open source "espeak" text-to-speech package. On rPi you would run sudo apt-get install espeak

For ISY994 integration, I went with the Z-Wave enabled Honeywell YTH8320ZW1007/U, For local control the UI is almost identical to the older Honeywell touch screen thermostats, and remote control via ISY994iZ is very easy and has been reliable.

There's a lot that can go wrong with external notifications. Using the Network Module, I wrote a set of LOCAL notifications and webserver files to act as a an on-box log of program execution, I put a notification at the top of certain programs that does Send Notification to 'WebPage' content 'WebPage Eventlog append', this appends a message to the end of a file on the ISY itself. First, under Configuration->Networking->Web Server, I created a folder on the ISY named "EVENTS" Then I made a custom notification with a subject of "@webpage:@append:events/log${var.1.9}.html" where the body is wrapped in HTML <DIV><PRE> tags, and contains the text I want to see in my "log". The ${var.1.9} variable is a variable named Day_of_week, each night at midnight I have a program which updates this variable, and then calls a different notification which creates a new file with an HTML header (<BODY><TITLE>, etc), overwriting the old content from a week ago. Because these are local notifications, they have been very reliable, and give me 6 days of lookback. I also have another notification that wraps <strong><font color="red"> around certain events, so they really stand out in the logs. If you want further info, I can try to post screenshots. Only works with the Network Module enabled (or Portal).

I would use SMS notifications (or if you don't mind the extra delay, regular email). This is easy to set up, and notification is useful for other purposes as well. If you use email, you could register a new gmail account to send the notifications to and from, and add this as an email account on your phone. Configure the ISY at the second home with a notification. Create a program that sends the notification for events at night where a door is opened or motion is detected. Make a contact for the ISY on your phone, with a custom message alert tone. Add this contact to "Favorites", so the message alert should play even when "Do Not Disturb" is set. I get a little fancier, my notification program condition includes a counter variable, so after a few notifications are sent, the low-risk motion detection stops sending (there's another program that resets the count to zero at dawn). This way I'm not woken up constantly by one bad sensor.

Yes, way back -- I stopped even trying to automated with X-10 back around 2005. Too many failed modules, devices switching on by themselves or not receiving signals, etc. I know quite a few people who got so frustrated from dealing with X-10 issues that they gave up on home automation, aren't willing to try the new products, just fed up with the whole thing.

I regret my original purchase of X-10 home automation equipment. Talk about unreliable, lack of polished apps, and hardware failure rates

Some sort of inherent tiered access rights would be great. If you really need a mechanism to permit just certain calls to the ISY, there are open source "web proxy" tools (e.g. Privoxy or Squid) which could be used as a filtering "forward proxy". Not for the faint of heart, and requires a machine that is always on to "proxy" the requests, apply a filter restricting what calls are allowed.

Cool, definitely looking forward to seeing this feature in a future 5.0 beta.

Technically it is possible to create a separate mechanism to receive the email, parse it, and then make a call to the ISY, that is a lot of indirection, and is likely to be unreliable and slow. Expect minutes between disarming the alarm and the variable being updated. It looks like Qolsys can be configured to turn a Z-Wave light on/off when the alarm is armed/disarmed. You could then have the ISY react to the device being turned on; if your ISY has Z-Wave you could make it a secondary controller, or maybe use a Synchrolinc? The most common WiFi SD cards do not support sending files TO the card, but this appears to be possible with Toshiba FlairAir. That said, it is likely the IQpanel caches the list of files from the card and may not display new files immediately when you upload. Would be interesting to try!