In the morning, when I first get up, I walk past a motion sensor. A moment later a lamp with a color-changing bulb illuminates, glowing a specific color to indicate the temperature range that will include today’s forecast high temperature. With just one glance I know whether or not I should take a jacket before I step outside.

It’s been a long time since I last spent any significant amount of time focused on home automation but I recently made up for lost time by eliminating the last of my Insteon gear. All of the home automation gear is now Z-Wave compatible. But why stop there and not take the opportunity to add new enhancements?

In general, I’m uninterested in bulbs that can be directly controlled themselves, such as Z-Wave or wifi enabled light bulbs. They certainly have their applications but I don’t find them very practical for normal use. They still require that a light switch is left in the ON position in order to function. This breaks down very quickly when guests come to visit. For example, even with a remotely controlled lamp on an appliance or dimming module I often discover that instead of using the provided remotes our guests have simply turned the guest room lamp off using the traditional lamp switch. It’s just a normal, reasonable action.

My reason for purchasing a Z-Wave controlled, color-changing LED bulb certainly wasn’t a typical one. In this case I purchased one to use with my home automation system as a supplemental notification method, though for this particular project it is actually the only notification method used.

Why? Because I think it’s fun but I also thought it was actually, at least to some degree,  practical. As a visual indicator it gives me a hint as to whether or not I should check the weather forecast. Despite the various home automation projects I’ve worked on I have yet to purchase new thermostats to bring our HVAC system under home automation control. This means that if there will be a drastic weather change on any given day then it’s best if I adjust the thermostat before I leave for work.

Yes, I do have a weather app on my phone and I use it frequently. But there’s something interesting about having such a minimal interaction with a piece of technology that is informative and it did not require that I initiate the action each morning.

Did this project work? Yes.

The new Zipato RGBW LED Z-Wave bulb is the primary module for this particular project but it is also used for a variety of other notifications as well. I’m running Indigo 6 (OS X 10.10) along with an Aeon Labs Z-Stick.

The following animated GIF demonstrates the color changes, in order, which correspond to specific temperature ranges:

• blue: below 50 °F
• light blue: 50 °F – 59 °F
• purplish: 60 °F – 69 °F
• yellow: 70 °F – 79 °F
• orange: 80 °F – 89 °F
• red: 90 °F and above

To accomplish this I used data retrieved from the NOAA Weather Plus plugin for Indigo, developed by Nathan Sheldon. Indigo includes a built-in weather plugin but it didn’t provide the daily high temperature forcast data that is available in the Plus plugin.

Overall, setting this up in Indigo, with the method I have used, resulted in the use of four schedules, seven triggers, two variables, and two devices. I realize that I could do this more elegantly using a Python script but because I’m not yet familiar with that language I used the tools available in the Indigo UI.

Here’s a break-down of the steps in Indigo that I used:

1. At 12:01 AM a variable named isAwake is set to false in a schedule that resets several other variables
2. At 12:01 AM, in the same schedule, the value of WeatherHighTemp is set to 9999
3. Around 5 :00 AM another schedule runs that uses the NOAA Weather Plus plugin to download the forecast and copy the value of the forecast high temp into the variable named WeatherHighTemp
4. Any change to WeatherHighTemp kicks off seven very similar triggers, only one of which will have a condition that matches on the value of WeatherHighTemp
5. The trigger that has a matching condition sets the color of the LED bulb, but the bulb is not actually turned on yet
6. At 6:20 AM another scheduled task runs that re-enables the schedule named Morning Notifications
7. Morning Notifications starts running, checking for these specific conditions once a minute: isAwake variable must be false, current time must be between 6:30 AM and 9:00 AM, and a specific motion sensor must be ON
8. If the Morning Notifications schedule conditions are all true then it will do the following: set value of isAwake to true, set LED brightness to 50% (this turns the bulb on), turn the LED bulb off after a 30 minute delay and then also disable this schedule after a 35 minute delay

Why do I need the isAwake variable and why do I change it’s value?

This is a process that I only want to have run once per day, in the morning. The isAwake variable serves two purposes. First, it is used to determine when to execute the action. Second, it is one of two ways the scheduled actions are prevented from executing more than once. When the action executes then the value of isAwake is set to true, preventing the schedule’s conditions from being met. The next morning, at 12:01 AM, the value is reset to false.

The Morning Notifications schedule itself is set to meet several conditions, which it evaluates over and over again until they are met. In this case I have the schedule running once every minute. However, having it continuously evaluate these conditions over and over, throughout the day, when it will only need to run once, is a bit of a waste of resources so when the conditions are met the schedule is set to disable itself.

This is where the 6:20 AM schedule comes into to play. It does only one thing and that is to re-enable the Morning Notifications schedule prior to the point at which the time-based condition can be met (6:30 AM). I could do this at the 12:01 AM reset but, again, I’m trying to avoid unnecessary processing. I could even do this at 6:29 AM; the ten minute buffer isn’t necessary.

This may be a bit confusing if you’re not familiar with Indigo. Schedules can be set to run several different ways. The difference between these two schedules is that the Morning Notifications schedule runs on an interval (every one minute) when active while the other schedule that re-enables it runs only once at a specific time. If Morning Notifications did not disable itself when all conditions are met then it would continue to run all day, once per minute.

I think Indigo is an excellent automation package and it provides a lot of functionality but I found there is at least one specific case where one will have difficulty with certain types of logic by not using the scripting capabilities (and I think it’s awesome that they included this capability). That’s not to imply that a lot can’t be done only using the provided UI options.

IF ELSE

This is apparent in how I handled the setting of the LED colors. I am actually running seven different conditional tests concurrently. Each trigger is testing a condition, regardless of whether or not another trigger matches on it or fails. In this case it works because there is only one possible match.

The ability to use if-then-else statements would also eliminate the need for the additional schedule to re-enable the Morning Notifications schedule at 6:20 AM. Instead I would simply execute the Morning Notifications schedule at 6:30 AM and if the condition didn’t match I would have it run again, perhaps on an interval, until the conditions were true or the time was greater than 9:00 AM. Then I would just re-enable the schedule in the 12:01 AM reset, instead of using a separate schedule for only that one task. Instead of checking every minute it would simply do nothing until the next time that it becomes 6:30 AM.

Why did I set the WeatherHighTemp value to 9999 at 12:01 AM?

The triggers that determine the color to use are all triggered by changes to the variable. But what if, by chance, the high temperature for one day is the same for the next day? In that case, if the high temperature was 78 degrees one day and then 78 degrees the next, the triggers would not run.

In some cases this may be perfectly fine. However, this is not the only way that I’m using the LED bulb. I have additional notifications each day that will turn it on and off, typically flashing a green or a white color. As a result, the last written color setting is not always that of the corresponding high temperature from the previous day. It just works out that this notification is the first one of the day.

To avoid this problem I set the value to something very high. In the unfortunate event that this value turned out to be a true value it’s very unlikely that I would have to worry about the possibility of the value being the same two days in a row. In this case I think this is an assumption that we can live with…or, well, I guess in this case it would not be something that we could live with…

I setup a seventh trigger that will match only on the value of 9999 and display a specific color, which will serve as an indication of an error. An error event might be possible if the plugin fails to retrieve the forecasted high temperature. This also required that the 90 and above trigger has an added conditional statement preventing a match if the value is exactly 9999. All seven of these triggers have a conditional statement requiring that the variable change must occur after 12:15 AM to prevent the WeatherHighTemp change to 9999 at 12:01 AM from triggering them prematurely.