KeviNH

Floodlights with a PIR in the same enclosure run the PIR on the same 120VAC as the lights, for example the really old school 3-hole box incandescent floods, wired like this: Becomes this:

My day job includes installing DPI and proxy hardware, including TLS MITM Proxies. With only DPI, the eavesdropper can only intercept usernames, passwords and URLs for unencrypted traffic (e.g. http); They need to add on a MITM proxy to see this level of detail for encrypted traffic (e.g. https or another TLS/SSL protocol). For personal and other small-scale use, self-signed (or better yet, private-CA) certificates can be just as secure as expensive certificates, when done right. Most mobile devices and computers allow you to import your private-CA or self-signed public key. Do this before you connect the first time, and self-signed is no worse off than any other certificate. Next, require client certificates for real protection against MITM proxies (Not all client apps support using a client certificate). The ISY994 supports client certificates. I doubt Mobilinc does, and I believe at least some parts of Tasker have experimental support for client certs. This approach actually works great for personal use, but is difficult to scale up to a service that you want to offer to many different users on many different computers, as each computer would require manually importing both keys before it can be used securely. When using the ISY portal, you have a whole different set of risks to consider, especially when looking at how to "make my tasker to portal connection more secure".

The ISY normally accepts only encrypted traffic on port 443, this mens the protocol is TLS (SSL, with https:// URLs), and the entire URL and any content is encrypted in transit (unless somebody in the middle is doing something nasty). This includes the username and password. While the "query string" may show the user and password, usually it is parsed by the app and sent obfuscated in a header. Either way, with TLS, the full URL is not exposed in transit, but may be readable by anybody who can see you screen or access the app's configuration settings (e.g. Apple, your employer, etc). While it's kind of a headache to do with ISY994, you could use the Free LetsEncrypt certificates instead of self-signed. Adding a certificate is low-risk, just don't set the "Verify" checkbox (see the security guide for details)

Once you've converted all your lights to LED, the system can just guess what rooms you're likely to enter in the near future, and if it turns on extra lights, no big deal, minimal electricity wasted.

I don't know if the Foscam R2 offers a URL that will fetch an image from the camera-- documentation is poor at best. Even with a URL that returns a snapshot, you can't just call snapshot.cgi from a Network Resource, as ISY994 doesn't support reading the binary response from the camera (a large .JPG file) in reply to a Network Resource nor can ISY994 email it to you -- there needs to be an always on computer/rPi/etc to handle reading in the picture and sending out the email. All that giant URL does is turn on the motion detection feature of the Foscam. You could use another giant URL to turn it off again.

Most solutions need a URL that will fetch an image from the camera. They also require a computer that is always on, be it an Ubuntu host, Blue Iris, rPi, etc. You could leave motion turned off on the Foscam, and then use a network resource like this to enable it when somebody is at the door: http://xxxxxx.xxx:00/cgi-bin/CGIProxy.fcgi?cmd=setMotionDetectConfig1&isEnable=1&linkage=14&snapInterval=2&triggerInterval=6&isMovAlarmEnable=1&isPirAlarmEnable=1&schedule0=281474976710655&schedule1=281474976710655&schedule2=281474976710655&schedule3=281474976710655&schedule4=281474976710655&schedule5=281474976710655&schedule6=281474976710655&x1=56y1=103&width1=10000&height1=10000&sensitivity1=0&valid1=1&x2=0&y2=0&width2=0&height2=0&sensitivity2=2&valid2=0&x3=0&y3=0&width3=0&height3=0&sensitivity3=3&valid3=0&x4=0y4=0&width4=0&height4=0&sensitivity4=3&valid4=0&usr=admin&pwd=***** The Foscam R2 is kind of buggy, it's an Amba S2L with some slightly modified commands not exactly supporting the standard Foscam APIs. In theory you could do /cgi-bin/CGIProxy.fcgi?cmd=setSMTPConfig&receiver=... to override the email desitnation temporarily to add your email address to the email destination (by putting a , in between) and then a few minutes later, remove the extra email address from the list of destinations. But I don't have a Foscam any more, so can't say for sure.

Try moving the actions into a separate program, like so: Well Pump Low - [ID 0059][Parent 0001] If 'Well Pump On-Off ZW 057 / ZW 057 Energy Meter' Status > 200.000 Watts And 'Well Pump On-Off ZW 057 / ZW 057 Energy Meter' Status < 900.000 Watts Then Send Notification to 'Robert' content 'Power' Set Elk Output 'Output 111' On Wait 30 seconds Run Program Cycle Well Pump Else Set Elk Output 'Output 111' Off Everything with a wait involved goes into the second program: Cycle Well Pump - [ID 005A][Parent 0001] If No Conditions Then Set 'Well Pump On-Off ZW 057' Off Wait 2 minutes Set 'Well Pump On-Off ZW 057' On $i.WellPumpCycleCount+=1 Send Notification to 'Robert' content 'Cycled well pump' Else - No Actions - (To add one, press 'Action') From the Wiki: The program's conditions are reevaluated each time a Wait or Repeat statement is encountered, and at the end of each iteration of a Repeat loop. So what's happening is that when each "wait" clause is encountered, the conditions (if any) are re-evaluated, and since the Wattage is zero when off, the condition is false and the execution stops. By using a separate program, there are no conditions to re-evaluate.

Nest can already predict when you're going to be at home, anticipatory lighting is the next step in the development of the Google home.

I have a program called "Phil Connors"; runs at sunrise every day. At sunrise Phil resets several variables and enables/disables all programs that are normally enabled or disabled, basically setting everything back to my defaults. That way any override I might have made during the previous day is undone at dawn. Personally, for the majority of my Insteon motion sensors, I have the MS as a controller for the scene. That ensures the floodlights come on immediately on motion, and works 100% of the time, has no dependency/delay on the ISY. To make this work reasonably with floodlights in a yard that is used for socializing, I put the yard lights on a dimmer and have a "disable yard motion" program which calls "Adjust Scene" to set the responder on level to 1%, sleep for 4 hours, then uses "adjust scene" again to reset the on level to 100%. I chose not to have Phil do the resetting of the on level every day at dawn only because I was being overly cautious of write cycles to the flash memory in the dimmer switch.

Some of the Smarthome kits still have that old text about not needing a power supply, Most of the kits do include a power supply.

Do you mean Network Resources? It might be possible, depending on your particular cell carrier -- some still offer a web gateway, or can be reached via a commercial web-to-SMS service (usually these charge a monthly fee). Most carriers offer a public SMS gateway where you send a plaintext email (e.g. via Notifications) to a specific email address, and it is forwarded as an SMS to the recipient. These generally have very strict anti-spam and rate-limiting, so sometimes if you send the same message multiple times, only the first one is delivered. E.g. for a Sprint user in New Hampshire with phone number 222-3333, you'd email to 6032223333@messaging.sprintpcs.com

I agree -- I'd hesitate to use "Repeat Every 1 second" unless I really needed that level of granularity. I track HVAC runtime with this technique, but only to the nearest whole minute.

Synchro-Linc is definitely the easy and cost-effective way, and has the advantage of not risking accidentally turning off a remote-controlled switch and forgetting to turn it back on. I would add the Synchro-Linc as a controller for a scene with a rarely used light, then you might notice the sump pump is acting erratically just from seeing the light.

Is there a thread showing how to use IFTTT with ISY994 without ISY Portal?

My goal is to convert over to using ESP32 for both control and status. I just need to get a few more low-current relays. I picked up a spare Open/Close sensor last time they were on sale at $20 (Amazon, free prime shipping). Instead of using the magnet, I wired a mercury tilt switch to the screw contacts, and attached the whole unit to an upper panel of the door. I set the angle of the tilt switch so the sensor is "closed" when the garage door is down, or at least mostly down. I like this solution better than using the reed switch and magnet because it still reads closed even if the door is open a couple of inches, as happens sometimes in winter when ice builds up in the opening.

I've been slowly moving to ZWave motion sensors anywhere I don't actually need the sensor to trigger an Insteon scene directly.

oberkc is correct -- one of the more important idiosyncrasies of ISY programming is condition re-evaluation, it takes a little getting used to the Wait behavior and the difference between state and integer variables. Based on the above behavior, this is how I wrote my "Notify Garage Door" program (I use the $GarageOpen state variable in other programs and other notifications): If Status 'Outside / System Devices / Garage Door IO Sensor' is On Then $GarageOpen = 1 Wait 7 minutes Send Notification to 'BenInsteon' content 'GarageDoor Open' Repeat 5 times Wait 30 minutes Send Notification to 'BenInsteon' content 'GarageDoor Still Open' Else $GarageOpen = 0 Send Notification to 'BenInsteon' content 'GarageDoor Closed' At the end of each Wait or Repeat, the program condition is re-checked, and if the garage door has closed in the meantime, execution of Then immediately stops short, and Else code (if any) runs. Lastly, if the program is in the middle of a Wait and a change causes the conditions re-evaluate to false, the Wait will end early and the Else code will run immediately. See above for why this re-evaluation happens with state variables, but not integer variables.

As mentioned above, double-check that GarageOpen is a state variable, otherwise Program 2 won't trigger. Instead of using a third program, why not put it into the "Else" for Program 1? Program 1 [Notification.GarageOpen.1] If Status 'Outside / System Devices / Garage Door IO Sensor' is On Then Wait 15 minutes $GarageOpen = 1 Else $GarageOpen = 0

It should survive exposure to salty water. These"reed switch" type flow sensors are very simple devices, there's a plastic-encapsulated captive magnet in the switch body; when water is flowing, it pushes the magnet in the direction of flow, bringing it into range to close the sealed reed switch. Sometimes it is returned by gravity, sometimes by a metal spring.

There are a few WiFi-enabled water softeners, but as far as I can tell, no WiFi or Z-Wave enabled control head to retrofit a standard water softener.

You're basically hitting a "race condition" in the ISY. While you expect the tests triggered by incoming "is switched off" event to be fully processed before the incoming "Status is off" event, there is no guarantee this will be the case, as the internal evaluation of "if" conditions is not perfectly atomic. You may be able to work around it by using multiple programs and/or variables.

If you have the Z-Wave module for your ISY994iZw, there are several threads discussing the various Z-Wave brands of locks. Without Z-Wave, your best option is the MorningLinc (MI) controller and locks

ISY994 can also add a custom "From" address for the notification. So, for example a different sender for "Lock" versus "Unlock", then many smartphones let you set a custom message notification sound if you add each of these From addresses as a contact. So I have a creaky door opening as my "Unlock" notification sound, and a door closing ("thud")as the "Lock" sound, so I don't even have to look at my phone to know which event just happened. I do something similar with my garage door alert.

Another good reason to add a "Beep", notification, or log to the first program, as shown above. With the original single program, conditions are re-evaluated (including at the end of each Wait). Program will stop early if the conditions are false, which is why statements after the wait sometimes do not execute. Go with the two program solution, so "Last trigger it should complete with any amounts of retriggering".

Yes, you're good. For testing out programs like this one, try making the sensor trigger a noise or notification, for example: Front Security Switch - [ID 0030][Parent 0001] If Control 'Front House Security-S' is switched On Then Run Program 'Front Security' (If path) Set Scene 'Dining Room' Beep The "Beep" line will cause any beep-enabled controller (e.g. a lightswitch) in the scene to emit a single chirp. I like to use a notification which writes a timestamped line to a logfile for this kind of execution tracking. The second program, below, is disabled (You'll need to right click on the program and select 'Disable') and has the time range as the conditions, so when 'If' is called by the first program, it will only run if the time condition is true. NOTE: Disable this program!!! Front Security - [ID 0031][Parent 0001] If From 12:00:00AM To Sunrise (same day) Then Set Scene 'Front House Lights' On Set Scene 'Dining Room' On Set Scene 'Foyer' On Wait 5 minutes Set Scene 'Dining Room' Off Wait 5 minutes Set Scene 'Foyer' Off Wait 5 minutes Set 'Front House Lights' Off Else - No Actions - With the above, anytime the motion sensor is triggered, you will get a beep, but only when it is triggered at night will it turn the lights on, then off.