Tim Wilson

If only we'd thought to ask sooner. *sigh*

I had the same issue on one of my Nest thermostats where I didn't have a common wire. (The builder only used a four-conductor wire to one of my thermostats for some reason.) It ran for a while just like Larry's son's experience and then started exhibiting the exact behavior the OP describes. It might be worth checking the voltage reported on the Nest to make sure it's within spec. Mine was too low which suggested that the battery couldn't supply enough voltage without the common wire. I ended up running a new wire to the location which took care of the problem.

I'd take a look at the Polyglot solution mentioned above first as long as you're willing to use a RaspberryPi or similar device and you're willing to run the 5.0.x Alpha branch of the ISY firmware.

That makes sense. Thanks for the clarification, Michel.

Yes, that's more like what I expected it to be.

Thanks for the reply. So you're saying that the ISY evaluates the "if" portion of that program continually during the specified time interval? That wouldn't change the observed behavior I cited, but it is a big difference from what I thought was happening. I could have sworn I'd read somewhere that those only get evaluated at the beginning and end. (But I'll take your word for it as someone who should probably know.)

I still don't think this is working quite right. Let me check my understanding of how the following program triggers. I may be misunderstanding something fundamental. Tim arrives home - [ID 0006][Parent 0008] If From Sunset + 15 minutes To Sunrise (next day) And 'Neighborhood / Tim iPhone' Occupied is True Then Run Program 'Outside lights on arrival' (Then Path) Else - No Actions - (To add one, press 'Action') My understanding is that the "if" part of this program will be evaluated when one of the following events occurs: The ISY's time is Sunset + 15 minutes The ISY's time is Sunrise (next day) My iPhone enters the geofence I've defined as my "neighborhood" Obviously, the "and" requires that the time constraint and occupancy both evaluate as true to trigger the "then" clause. I should not be surprised, then, when the outside lights turn on at Sunset+15 if I'm sitting in my living room at the time. That's not what I attended with this program though. I only want the outside lights to turn on as I approach my house in my car after dark. I don't need the outside lights on if I'm already in the house. So I'm back to the idea that I may need to set a state variable when the occupancy state changes. My program would change to look for that state variable between sunset+15 and sunrise, say $sTimArrivedHome = 1, turn on the lights, set $sTimArrivedHome = 0, wait 10 minutes, and turn the light off. Does that make sense?

Thanks for all the feedback everyone. I'm still experimenting a bit with the placement of the sensor tags to optimize the performance.

It looks like Amazon stocks both 32% and 70% RH calibration kits for $7.95 each. The question is which to get. I'm thinking that 32% is probably closer to the average over an entire year..

The purpose of this tutorial is to demonstrate how to automate a bathroom exhaust fan based on the humidity in the bathroom compared to a reference sensor in a different room. This solution uses the following devices: two wireless sensor tags (13-bit temperature and humidity) ethernet tag manager (required for the wireless sensor tags) Insteon 2477S SwitchLinc On/Off Insteon 2477D SwitchLinc Dimmer Background I've been using a simple timer to control the exhaust fan in my master bathroom. It started getting flaky, and I would often come home from work and find that the fan had been running all day. I decided that it was time to up my home automation game and go with a more sophisticated solution. I replaced the old exhaust fan timer with a 2477S SwitchLinc. Having the ISY control the 2477S is easy, but I wanted it to monitor the humidity in the bathroom and run the exhaust fan as needed. The humidity varies widely where I live so I can't simply measure the humidity in the room. I need to have two sensors so I can compare the humidity readings and determine when the difference between them exceeds a given threshold. Step 1: Humidity monitoring Among the cheapest and most capable humidity sensors I could find were the CAO Wireless Sensor Tags (see Wireless Sensors sub-forum). The 13-bit temperature/motion/humidity sensors can be purchased for $29 each or in a five-pack for $139. The sensors require an ethernet tag manager that receives the sensor data and publishes it to a web site for monitoring and tracking. The ethernet tag manager can also update variables on the ISY using the ISY's REST interface. I placed one of the sensors in the master bathroom near the shower about six feet high on the wall. The other one is in the master bedroom on the far side of the room from the bathroom. You can see from the graph below that it's not difficult to tell when someone is showering. (You can view the graphs on the WirelessTag app or the MyTagList.com web site.) Humidity measurements (Click for full-size view.) The wireless tags can trigger lots of different kinds of events through the use of Kumo Apps which are Javascript applications that have easy access to the sensor values. (See examples at the link.) I created a Kumo App that updates three state variables on my ISY: sMasterBath.humidity, sMasterBedroom.humidity, and sMasterSuite.humidityDelta. Here's the Kumo App: var tags = <#tags_[13]_N#>; var isy_ip=<%ISY IP Address%>; var isy_user = <%ISY username%>; var isy_password=<%ISY password%>; var isy_RESTcall = "http://"+isy_user+":"+isy_password+"@"+isy_ip+"/rest/vars/set/2/"; var isy_variable_humi_delta = 3; // "3" corresponds to the ISY state variable // Initialize a couple variables to use later to trigger recording the humidity difference var master_bath_humi = 0; var master_bedroom_humi = 0; tags.forEach( function (tag) { tag.updated = function () { var cur_name = tag.name var valid_device = true switch(cur_name) { case "Master Bath": var isy_variable_temp = 4 // This and following map to ISY state variables var isy_variable_humi = 1 master_bath_humi = tag.moisture // save this for later break; case "Master Bedroom": var isy_variable_temp = 5 var isy_variable_humi = 2 master_bedroom_humi = tag.moisture // save this for later break; default: var valid_device = false } if(valid_device==true){ // Capture sensor data from the "Master Bath" and "Master Bedroom" sensors. var tag_temp = Math.round((tag.temperature * 1.8 + 32)*10)/10; // Convert to F and round to 0.1 KumoApp.Log("Temp for "+cur_name+" ("+isy_variable_temp+") updated to "+tag_temp); KumoApp.httpCall(isy_RESTcall+isy_variable_temp+"/"+tag_temp, "GET"); var tag_moisture = Math.round(tag.moisture); KumoApp.Log("Humidity for "+cur_name+" ("+isy_variable_humi+") updated to "+tag_moisture); KumoApp.httpCall(isy_RESTcall+isy_variable_humi+"/"+tag_moisture, "GET"); // Calculate the humidity delta if both sensors have checked in. if (master_bath_humi > 0 && master_bedroom_humi > 0) { var master_suite_humi_delta = Math.round((master_bath_humi - master_bedroom_humi)*10)/10; KumoApp.Log("Humidity difference in Master Suite ("+isy_variable_humi_delta+") updated to "+master_suite_humi_delta); KumoApp.httpCall(isy_RESTcall+isy_variable_humi_delta+"/"+master_suite_humi_delta, "GET"); }; } else { KumoApp.Log("Data from non-configured device: "+cur_name); } }; } ); The variables at the top in the angle brackets correspond to parameters that are prompted when the Kumo App is launched. Each sensor tag is checked in turn and the temperature and humidity data are logged to the ISY via its REST interface. Once both sensors have logged their humidity data, the Kumo App calculates the humidity difference and logs it to ISY variable #3. Step 2: Controlling the exhaust fan Once the humidity data is stored in variables in the ISY, the final step is writing two programs: one to turn the fan on and another to turn it off. I decided that for the purpose of triggering the exhaust fan, I would check the status of the light in the bathroom (the 2477D dimmer) on the assumption that I don't want the exhaust fan to start up unless someone is actually in the bathroom showering. Since we always have the light on when someone is in the bathroom, that makes it easy to avoid the situation where the exhaust fan might turn on when no one is home or in the middle of the night. Here's the code: Turn ON Master Bath Exhaust - [ID 0019][Parent 0001] If '2nd Floor - Master Bath / Master Bath Lights' Status is not Off And $sMasterSuite.humidityDelta >= 3 Then Set '2nd Floor - Master Bath / Master Bath Exhaust Fan' On Else - No Actions - (To add one, press 'Action') You can see from this code that I decided to set the humidity threshold to 3%, that is, the fan will only turn on if the difference between the humidity in the bathroom and bedroom is at least 3%. This is easily tweaked over a period of a few days until the fan turns on at the right time. Similarly, on the assumption that the master bathroom light won't be on when no one is present, the code to turn off the exhaust fan runs when the bathroom light is off and the humidity difference drops below 3%. Turn OFF Master Bath Exhaust - [ID 001A][Parent 0001] If '2nd Floor - Master Bath / Master Bath Lights' Status is Off And $sMasterSuite.humidityDelta < 3 Then Set '2nd Floor - Master Bath / Master Bath Exhaust Fan' Off Else - No Actions - (To add one, press 'Action') The sensors and programs are working great so far. Feel free to post with questions below.

The lights came on when I got home tonight. Now the problem is that they click off after 10 minutes and then go right back on again. I think I need to set a variable somewhere to manage that unless someone has a more elegant solution. In my previous solution that was using Locative only, the state variables that Locative triggered worked perfectly. Now the line that refers to the neighborhood being occupied is always true when I'm home.

I have the Schlage Connect. Search the forums here for "BE469" to find more info.

Good catch. I'm guessing that could be messing up the trigger.

I just switched to using the ISY portal node server for occupancy monitoring, and I'm having trouble replicating what used to work for me when I was using simple Locative calls to set ISY state variables. Here's the program I have right now. Essentially I want the outside lights to come on (it's a single Insteon 2477S device, not a scene) if it's dark outside, if the lights aren't already on, and I arrive in my neighborhood geofence. Arrive home - [ID 0005][Parent 0008] If From Sunset + 15 minutes To Sunrise (same day) And 'Outside / Outside Lights' Status is Off And 'Neighborhood / iPhone' Occupied is True Then Run Program 'Outside lights on arrival' (Then Path) Else - No Actions - (To add one, press 'Action') The "Outside lights on arrival" program is disabled and looks like this: Outside lights on arrival - [ID 0007][Parent 0008][Not Enabled] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set 'Outside / Outside Lights' On Wait 10 minutes Set 'Outside / Outside Lights' Off Else - No Actions - (To add one, press 'Action') I'm still trying to wrap my head around the event-drive programming paradigm of the ISY. I'd appreciate any pointers.

Part 6: Creating the ISY program to trigger notification and logging We've finally arrived to the final section. Now it's time to create a short program to trigger the Pushover notification and Airtable record creation when the deadbolt is locked or unlocked. Fortunately, the final step is the easiest one. Go to the "Programs" menu and click "New Program" at the bottom of the screen. Enter the following: Notification program If '1st Floor - Living Room / Front Door Lock' is switched Alarm Unlocked by Keypad Or '1st Floor - Living Room / Front Door Lock' is switched Alarm Locked by Keypad Then Resource 'Zapier -- Front door keypad activity' Resource 'Pushover -- Front door keypad activity' Else - No Actions - (To add one, press 'Action') Your program will use the corresponding name of your deadbolt. Mine is called "Front Door Lock", and I have it in a folder called "1st Floor - Living Room". Simply add both notifications to the "Then" portion of the program and you're all set. The notifications will also correspond to the names you gave yours. Good luck.

Part 5: Creating network resources in the ISY Now that we've got the HTTP hooks set up with Pushover and Zapier, we can create the "Network Resources" on the ISY to trigger them. Network resources have many options, but for this project we’re using an HTTP POST request. You’ll find the Network Resources in the ISY menu shown below. Network resources menu Let’s set up the resource for the Pushover notification first. First, you’ll need to go back to your Pushover account and retrieve the API token, user key, and HTTP path that were created when you set up your ISY application. In the screenshot below, you can see the options required in the Network Resource. Pay attention to each one because the settings have to be just right to trigger the notification. Pushover request The HTTP POST request consist of “Headers” and the “Body” which is the request’s payload. The headers are the metadata. They describe the contents of the request. The “Body” section in the lower left is where you will craft your notification. The data is formatted into one line in the body of the request, and it doesn’t all show in the screenshot. Here’s the entire thing. token=TOKEN&user=KEY&title=Front+door+access&message=${sys.node.ZW005_1.ST}+at+${sys.time}+by+user+#${sys.node.ZW005_1.USRNUM} I removed my token and user key. Replace the text in all caps with the values from your Pushover account. Notice how the string is composed of a series of name and value pairs separated by an & character. Besides the token and user key that are used to authenticate me to the Pushover service, I’ve added two other fields: title (optional) and message. The title variable contains the text “Front+door+access” where the + characters are replaced by spaces. You’re not allowed to have literal spaces in HTTP requests of this type. Using the optional title variable create a nice title for the push notification in a bold font. Pushover notification in iPhone The contents of the message variable are generated dynamically by substituting the values of the three ISY variables below: ${sys.node.ZW005_1.ST} is the current status (“ST”) of the lock. ${sys.time} is the current system time. ${sys.node.ZW005_1.USRNUM} is the user number (“USERNUM”) corresponding to the keycode used to lock or unlock the deadbolt. Your lock variables will probably be different than mine because they correspond to the ID of the specific Z-Wave device in your ISY. Go ahead and save your Network Resource and click “Save” on the main Network Resource screen too. Your notification should be ready to use. Now we’ll configure the network resource for the Zapier webhook. As before, pay careful attention to the options listed in my screenshot. (I obscured the path to my Zapier webhook.) Zapier request One difference in this case is that the Content-Type header has been set to “application/json”. Javascript Object Notation (JSON) is a convenient (and highly legible) way to express variables and their contents. It’s a common format in the world of web applications. Like before, in the body of the request, everything is on one line. Here’s the JSON data expanded so you can see it better. { "timestamp": "${sys.date} ${sys.time24} -05:00", "st": "${sys.node.ZW005_1.ST}", "user_num": "${sys.node.ZW005_1.USRNUM}" } With this JSON example, you have a name/value pair with quotes around each separated by a colon with each pair separated by commas. It looks a bit like CSS notation if you’ve done some web development. The “st” and “user_num” values should look familiar from the Pushover example. The “timestamp” is a bit different. I want to log the time that the deadbolt was locked or unlocked by the user, and I want to include the date this time. (The date hardly seems necessary for an push notification since you check and then dismiss it.) Make sure you use the same variable names that you set up when you created your Zapier web hook. The contents of the “timestamp” variable is a simple combination of the system date and time plus a timezone offset (-05:00) that helps Airtable determine the local time. Use whatever offset from GMT that makes sense for where you live. Save your network resource, and you should be ready to log to Airtable.

Fortunately, the deadbolt itself functions just fine without an Internet connection. If I have a network hiccup, and someone's access doesn't get logged, I can live with that.

Photon OS looks really cool. We are a big VMware shop at work, but I hadn't seen that before. If Apple would ever updated their Mac Mini, I'd probably buy one in a heartbeat for a nice, compact home server. I feel your pain about the cloud services. I usually take a wait and see attitude with them, and I don't tend to put anything mission critical on a service I'm getting for free. With Airtable, for example, I can export anything of my databases any time I want, so I feel OK about using it. And I don't hesitate to move to a paid tier for a service that I use a lot and want to support.

Step 4: Setting up a Zapier webhook Zapier is a competing service to IFTTT. I find it more user-friendly and possessing richer integrations than IFTTT with some of the tools I use most often. Each combination of a trigger and action is called a “zap.” The free plan allows only simple trigger-action combinations, but the paid plans offer multi-step zaps that can support more complex workflows. For this project, the trigger is an HTTP POST sent by a network resource on my ISY, and the action is a connection to Airtable that creates a new record in my database with the data in the POST request. They steps to creating a new zap are shown below. Overview of Zap steps The first step is to create a trigger using the “Webhooks” app. This is similar to the “Maker Webhooks” service that IFTTT provides. Once you create a webhook for your zap, you’ll get a URL that you will enter in your ISY’s network resource. Webhook URL Once the webhook is created, you can send a test request, and Zapier will confirm that it was received. Webhook test With the webhook set, now you can choose the appropriate action app. We’re using Airtable for this project. Selecting an action app Through Zapier, you can use HTTP to create a new record, update an existing record, or search for a record. We want to create a new record in the database for each lock/unlock event. Select “Creater Record” Then you connect to your Airtable account. If you’ve used the Airtable channel previously, this step will already be set to go. Connect to Airtable Once you’re connected to Airtable, you need to choose the database where the new records will live. In my case, that table is called “Home Access.” This is the stage where you map the variables in the HTTP POST to the fields in your Airtable database. Zapier will pull in all the relevants fields from the table. You just need to click on the ones you want to populate and associate the POST variable. Map to your database fields That should do it. If you have a tool like Insomnia or Paw, you can test whether the connection works and a record gets created before you even create the network resource on your ISY.

I haven't tried the ISY's built-in web server yet. That's a cool idea. I could push that kind of stuff to my Raspberry PI too.

Part 3: Creating an Airtable database I like to describe Airtable as the database took that Google should have created and included in their G Suite. It's user friendly and powerful enough to use for production-level projects. Their implementation of table relationships is especially well done. If you've done any database development you know how solving many-to-many relationships requires lots of extra tables. Airtable take care of the many-to-many relationships in the background gracefully. The free version of Airtable is quite robust, and I don't expect to run into any of its limits anytime soon. For this project, I created a database (called a "Base" in Airtable's parlance) called "Home Access." When you create a new database, you can use one of their templates as a starting point, upload a CSV file, or start from scratch. I started from scratch and created four tables: Access Log, User Codes, Status Codes, and Alarm Codes. (I'm not using the Alarm Codes table at this point.) Creating multiple tables allows me to do lookups with the data I get from the ISY and create fields that make more sense. Here's what the database looks like with all of the fields in the Access Logs table visible and some sample data. Airtable access log From left to right: "Timestamp" is the primary key and based on a formula that converts the "Datetime" field to the proper timezone. "Datetime" comes from the ISY via Zapier. "Status Code" is the lock status as reported by the ISY. "Action" is the verb associated with the action that was performed on the lock. I felt this made more sense than using the status code directly. "Lock User" is the user number associated with the keypad combination used to lock or unlock the deadbolt. This also comes from the ISY. "Person" is the name associated with the user number. This value is a lookup from the "User Codes" table. The entries in the "Status Code" and "Lock User" fields are blue which indicates that those data are linked to corresponding tables. The field to the right of each of those are looked up through the linked fields. Under normal cirmcumstances, I keep those linked fields hidden, and the table looks like this: Airtable abbreviated access log The "User Codes" table is a simple mapping of user numbers to names. User table Likewise, the "Status Codes" table maps the ISY lock status code to the action that was done on the lock. Access code table Note: this was not meant to be an Airtable tutorial. There is a lot of great help documentation on their web site. For a quick intro, their "12-Minute Airtable Guide" is a good place to start. For this project, I like the idea that I can create a permanent record of uses of the front door lock. We have a cleaning service that comes to the house every couple weeks, and they use their own keycde to access the house. The Airtable database allows me to go back in time and see when they came and went. (It also works for noting when your children get home at night.)

Part 2: Setting up Pushover Pushover is a free service (with limits) that allow for native push notifications to iOS, Android, or desktops. While it's possible to do notifications via text, native push notifications usually arrive faster and can be more succinct with additional formatting options. It's possible to generate push notifications by sending email to a custom email address, but we'll be using an HTTP POST to generate the notification directly. After creating a free Pushover account, you'll need to add the devices you'd like to receive notifications in the "Your Devices" section. Pushover automatically creates a "User Key" associated with your account. Pushover user key The next step is to create an "application" within the Pushover system. Pushover home screen Creating a new Pushover application Once you have created your "ISY" application, you'll get an API key to use with your ISY network resource in the HTTP POST request. Pushover application API token Take note of your "User Key" and the "API Token." You'll need those later to create your push notification from the ISY.

Thanks for the question, Gary. I'd love to see your solution. As for me, I like the native notification functionality that Pushover provides. Text messages work too, but I prefer the notifications. Airtable makes it possible to create a long-running record of lock/unlock events, and I already use it for lots of other database functions such as tracking my vehicle maintenance, managing my youth archery team, and tracking various aspects of a non-profit I run. Airtable's API might be possible to access directly from the ISY, but Zapier provides a handy abstraction for doing simple things like adding records.

Part 1: Introduction The purpose of this series of posts is to explain in detail how to configure notifications and logging via network resources on an ISY whenever the keypad is used to lock or unlock a Schlage Z-Wave deadbolt. Resources required Schlage BE469 Z-Wave deadbolt. I have the new Schlage Connect model, but I believe any BE469 lock will work. An account at Zapier.com (free). It's possible to do the same thing with IFTTT, but I find the interface and functionality more intuitive with Zapier. An account at Pushover.net (free). Pushover provides push notifications to iOS, Android, and desktop systems. An account at Airtable.com (free). Airtable is an intuitive, online relational database system. It has a rich API, sharing features, and integrates well with Zapier and IFTTT. ISY network module. The notification and logging in this how-to use HTTP POST requests to trigger Zapier and Pushover. Prerequisites In addition to the items in the section above, you need to have the Schlage lock added as a device to your ISY. If configured properly, the ISY will show the status of the deadbolt (e.g., Locked or Unlocked) as well as the user number associated with the keycode that was last used to lock or unlock the deadbolt. You will need a database created in Airtable ready to receive the information from the lock and unlock events. A detailed Airtable tutorial is beyond the scope of this how-to, but the basic setup will be described in that section. Finally, your ISY must be able to access the Internet in order to send the HTTP requests to Zapier and Pushover. How-To Sections Part 2: Setting up Pushover to send notifications from the ISY Part 3: Creating an Airtable database Part 4: Setting up a Zapier webhook Part 5: Creating network resources in the ISY Part 6: Creating the ISY program to trigger notification and logging

For the record, I got this figured out last night with the help of the ISY Portal IFTTT Integration wiki page which I hadn't found in my initial searching. I'll write it up and post it in the How-To forum because I think it could be useful to others.