Smart home vs an automated home

Introduction

In this article I'll touch on the Internet Of Things (IOT) and what it is. I will talk about, and show similarities and differences between a smart home versus an automated home. I will talk about different home automation software packages and different ways to gear your IOT devices towards making your home more of a smart home.

Internet Of Things

You may have heard the terms IOT or IOE before and said, what the heck is that. IOT stands for the Internet Of Things. Similarily, IOE stands for the Internet Of Everything. IOT and IOE, in it's broadest sense is the process of making the things that we use every day, in some way shape or form, connected to the internet. These things have various sensors and control functions. Being connected to the internet allows outside access to to the data and control that those sensors and controls provide. IOT is a way of simplifying the world around you. IDC, a market intelligence research firm, says that there are around 13 billion connected devices in use worldwide already. Business Insider (BI) Intelligence projects 34 billion devices will be connected by 2020.

Home automation projects

One aspect of IOT that is becoming more common is home automation. Home automation is nothing new though. My start into home automation began many years ago with X10. I found it nice to be able to control devices remotely. With their software called ActiveHome, I could also automate things with motion sensors and timers using a computer. After using it for a bit, I found that there were things that I wanted to do that my X10 hardware could not. Since then I have tried a number of different software packages, most of which fit in the realm of home automation platforms. Some of these have included MisterHouse, Domoticz and most recently my VeraPlus controller. I have another blog post talking about my home automation setup. https://dan.bemowski.info/2017/06/11/my-home-automation-setup/

One project I was a part of that geared itself toward being more of a smart home system than an automated home system. That project was called Open Source Automation, or OSA. The features that drew me toward the system were it's ability to integrate a number of different types of hardware into one system. Another thing that drew me toward it was it's focus towards being a smart home controller. When I was on the project, the smart home features were in their infancy, but moving forward.

Smart home vs automated home

So what is the difference between an automated house and a smart house. The ability for you to turn devices on and off from your phone, and scheduling lights and other devices to turn on and off on different schedules, simply means that you have an automated home. You may ask then, how is that different from a smart home. A smart home adds other layers on to the automated home system giving it a new level of functionality.

The broadest aspect of a smart home is gathering lots of data. Smart homes are made of many data gathering tools and sensors. Gather more data and you can make more intelligent decisions based on that data. Another thing we'll throw into the mix is objects. These objects have many properties. The properties of these objects, combined with data that your system has collected can now make smart decisions. Now your system is gearing up to be a smart house.

One of the biggest pieces of data in all of this, and the most difficult to manage, is occupancy sensing. A basic level of occupancy sensing is to put motion sensors in a room that will turn lights on and off. However, the use of a motion sensor will only tell your system that one or more people occupy an area. Now what if you could tell how many people were in that area. To take that a step further, what if you could tell exactly who was in a particular area. Now you can make smart decisions based on that added data.

People objects

Previously we mentioned objects and their corresponding properties. So lets say we defined a person as one of those objects. We'll define two "person" objects using myself (Dan) and my wife (Karen) as examples. So let's say Dan likes the temperature in a room to be 70° and he likes a lot of light in a room. Two properties for Dan would then be "temp = 70°" and "lightLevel = 100%". Now Karen likes the temperature in a room to be 67° and have the lights a little dimmer, so her two properties would be "temp = 67°" and "lightLevel = 70%". Let's combine this with motion sensing with person recognition. You can now define your rule on your main controller to say:

If ( motion_sensed ) {
if (furnace_mode == off ) {
set furnace = on; //Turn the furnace on if someone is in the area
}
set furnace_temp = temp; //Set the temperature to the users desired temp
set lights = lightLevel ; //Set the lights to the users desired light level
}
}

So with that, if I walk into the room and the furnace is off, it will set the temperature to 70° and turn the lights on to 100%. If my wife walks in under the same scenario, The furnace will set itself to 67° and the lights will dim to 70%.

As you can see, the more data you can gather, the smarter, more informed decisions your automation controller can make based on that data. Using this approach can save energy and improve the quality of life for the occupants. You should now be able to tell the difference between a smart house and an automated house.

Conclusion

So to sum it up, an automated house gives you control of devices from an external source such as a smart phone and limited action from other sensors such as motion sensors. A smart house makes it's decisions using multiple factors and sensors. Check out the ongoing discussion on this topic on the MySensors website https://forum.mysensors.org/topic/7814/a-smart-home-vs-an-automated-home/ .

Related Images:

October 1, 2017October 26, 2017

Temperature-humidity sensor

Description

This post will outline how I built some temperature-humidity sensors for my home automation setup to use in a couple rooms in my house. I'll explain some of the options I tried before coming to my final design. I will also give you links to where you can purchase the parts and to download the 3D printer files for the enclosure.

Introduction

This originally started from an idea I had for my home automation setup to put a temperature and humidity sensor in my main bathroom. The main reason for this was to help a small problem with occasional small mold spots on my ceiling. This was most likely due to humidity in the bathroom. When someone would take a shower, they would turn on the vent fan before showering, and then off shortly after. The problem is that when the vent fan is shut off, there still may be excess humidity in the room that could eventually cause the mold.

The idea was that I could have a controller on the vent fan for the bathroom that would turn on when the humidity reached a certain level, and then would also turn off when below another level. The two levels would factor in some hysteresis to the equation to prevent the fan from continually starting and stopping when the humidity is near a certain level. By doing this, the humidity in the room would be dropped to a safe level before shutting off, thus preventing the mold problem.

The temperature-humidity sensor design ideas

So I needed to figure out everything I would need for the project. My primary home automation setup revolves around MySensors nodes. Those nodes talk to my Vera Plus automation controller. I decided to make the temperature and humidity sensor a MySensors node. The exhaust fan control, which I have yet to do, will be controlled by a converted Sonoff module. For this article i'll focus on the Temperature and humidity sensor.

Below is a list of the things I needed to create the sensor. The basic list was simple

A circuit board for the project.
A micro-controller to control the sensor.
A temperature and humidity sensor.
Some kind of power source.
An enclosure to mount the sensor to the wall.

On to building the prototype

For the circuit board, I had a number of the MySensors Easy/Newbie circuit boards, so I thought that would be a good choice. For that board I needed an Arduino Pro Mini, and an nRf24L01+ radio.

Now I needed to choose a temperature-humidity sensor. I had both some DHT11 and some DHT22 sensors. The DHT22 is a higher resolution sensor, so I originally decided to try that one. Through some testing with the DHT22 sensor I found that the power consumption was too high. I did some looking and found the HDC1080 sensor. This sensor connects to the I2C bus and uses very low power. It's low power consumption made it ideal for use on a battery operated node. By removing the regulator and power LED from the Pro Mini I was able to run this sensor for a week with no significant power drain on a set of 2 - AA batteries.

The last piece of the puzzle was an enclosure. The enclosure had to be vented since I was measuring temperature and humidity. It also needed to be able to hold a battery or set of batteries. I figured that I should find the battery box first, and then design the sensor enclosure around that and the PCB. I settled on this one.

The enclosure design

I have dealt with temperature sensor enclosures before, so I had some ideas on what the enclosure should look like. I turned to OpenSCAD and came up with a basic design. The box was vented, it had mounting tabs for the PCB and a place to hold the battery box. I decided to make it easy to remove from the wall if needed and made the wall plate with two tabs that the cover could lock on to.

Since the creation of the first prototype wall box, I have done a couple revisions to the design. This is what the final design looks like.
Version 3 of the wall box is highly configurable and can be adapted to other configurations if needed. All versions of the wall box can be found on my thingiverse page https://www.thingiverse.com/thing:2186286

Related Images:

September 16, 2017November 8, 2017

RS485 communication techniques

Introduction

RS485 is a physical layer communication standard typically used in automation systems as a way for sensors and other devices to communicate to a central automation computer. It is also used in computer system peripherals for data communication between devices. A couple examples of this are the Small Computer Systems Interface, or SCSI-2 and SCSI-3 interfaces for hard disk drives. Different systems use different protocols as their defined standards outlining the "language" they will use to communicate to each other. In this short article I will discuss data communication using an RS485 serial bus and the best practices for an error free signal.

What is RS485?

RS485 has sometimes been referred to as a protocol, which it is not. It is simply a communications interface wiring standard. Unlike RS232 serial which is used for point to point serial communications, RS485 is a standard used for multi-point serial communications. RS485 communication is typically done at half duplex using two wires handling both transmit and receive. Full duplex operation can be achieved using 4 wires depending on signal and speed needs. Below is a diagram of an RS485 serial bus showing the master node and slave nodes.

As can be seen in the diagram, there is the two data lines, or differential pair, where the master and slaves connect, and at the end of the differential pair is a series of termination resistors. Because the wires are a differential pair, the termination resistors are used to prevent reflections of the signal from back-feeding on to the line and causing collisions. An RS485 network should only have termination resistors at the beginning and end of the transmission line.

The communication

Data transmitted on an RS485 bus can be heard by all nodes connected to that bus. Because of this, a protocol is used to determine how that communication is managed. The protocol must define a system for how data is transmitted, how a node knows that the data is meant for that node and how that node responds to the data it receives. There have been a number of different protocol standards used in RS485 communication, with one of the most notable standards being the Modbus protocol.

RS485 interface types

There are many different types of RS485 interfaces on the market. One is a USB type interface as seen on the left. This type will allow you to use a laptop or desktop PC as a master device, or a slave node on the network. Another type such as the interfaces shown below are typically used to connect to a micro-controller such as an Arduino or a PICAXE, or small credit card size computers like the Raspberry PI or Beaglebone Black. Interfaces such as the ones below typically come with the termination resistors integrated on to the board and may need to be removed if being used as slave nodes in the network.

RS485 bus setup

In an RS485 topology, the network is designed as one single line with multiple drops, or slave nodes. As mentioned previously, termination resistors are put in place at both ends of the line to prevent signal reflection. When termination resistors are not used, signal reflection can distort the signal on the line to the point of causing data loss or corruption. These reflections are more noticeable on longer runs because the length of the pulse is long enough for the full pulse to make it to the far receiving end. Once it reaches the end, it is then reflected back causing ghost signals that can differ in phase by the time it has ended. On shorter cable runs, the the delay of the reflected signal is short enough that the distortion may not affect things because the phase difference will be negligible.

Termination resistors should not be used at the slave nodes as this will cause unwanted signal attenuation. With too much attenuation the signal may get lost completely. Therefore, on node adapters where termination resistors are in place by default, such as the ones pictured above, you may need to remove them if they are not acting as the end node.

Conclusion

RS485 can be a good way of connecting automation devices where wired connection between devices is critical in preventing drops in signal. Following these simple rules for connecting the bus, the signal transmission between devices should be quite reliable.

Related Images:

August 27, 2017November 8, 2017

Unseen door sensors

NOTE: This is a post copied from my old website. This content was posted back in 2012, but the idea is still a good relevant one.

I did some testing with a theory for a hidden door sensor. I had a pile of magnetic reed switches and got to thinking. Neodymium rare earth magnets are the strongest magnets you can get. I had one that I pulled from an old hard drive that was very strong. I connected my continuity tester to the switch and set it on top of my desk which is made of 3/4 inch press board. I held the magnet under the desk top and was able to activate the reed switch with the magnet even 1/2 inch or more away from the bottom of the desk top. This told me that it should be able to activate the switch through the frame of a door. The distance from the hinged side of the door to where the magnet and reed switch are mounted will determine the sensitivity of the switch action. The switch would be most sensitive at the furthest point from the hinged side. Below is a diagram of the concept.

Related Images:

August 12, 2017September 24, 2017

The setup of my 1-Wire network

Introduction

DISCLAIMER: This post was copied from my old web page and is a bit old. Some information contained within this post may be out of date.
In my home automation setup, I wanted to be able to monitor temperature in various places around my house as well as outdoors. I wanted a solution that was relatively cheap and easy to use. My brother some time back had mentioned to me about something called 1-Wire. He had used it up at his cabin to monitor temperature and electric usage through current sensing. I did a bit of searching and found that it fit both of my needs, cheap and easy to set up. So I figured I would document my setup here.

The 1-wire interface

The first thing I needed to run this was some type of 1-Wire computer interface. After looking at options, I came across the DS9097U adapter on Ebay. Unlike other 1-Wire adapters that had an RJ11 jack for connecting the sensors, this model had 2 - 3.5 mm headphone style jacks on it. It did come with an adapter to connect the RJ11 style sensors if needed. It looked like that adapter would fit the bill perfectly. I ended up purchasing one for around $20.00 US from a china distributor on Ebay.

The sensors

The next thing I was going to need was some of the 1-Wire temperature sensors. My brother had mentioned that he got all of his equipment from a company called Hobby Boards. I checked their website and I could buy the bare temperature sensors for about $4.50, but they wanted $10.00 for shipping. I decided to check Ebay. I figured that if I could get the adapter cheap, I should be able to get the sensors cheap too. I ended up finding another chinese distributor that sold the sensors in packs of 5 for around $7.00 shipped. A pack of 5 of them from Hobby Boards would have been about $40.00 shipped, so I went for the Ebay deal (who wouldn't at that price), so I bought a pack of 5 just to try things out.

The build

Now that I had all the parts, I needed to figure out how to wire things up. Looking at the data sheet, I saw that there were 2 ways to wire these devices. The first was using parasite power. This is basically powering the device from power it grabs from the 1-wire network.

The other way was to use an external 5 volt power source.

So, if I was to use the external power source, how would I accomplish this. I once again turned to Hobby Boards who had a how to section that outlined a wiring specification that used cat5 wire, and supplied a regulated 5 volts along with an unregulated 12-24 volts on the wire for use down the line for other devices. The color scheme shown here is using the ISO T568A standard. Most cat5 cables that you buy these days use the ISO T568B specification which is what I am using. The only noticeable difference is that the orange and green wire pairs are reversed putting the color order at, white orange, orange, white green, etc...

I figured using a documented wiring spec would be more reliable, mainly because it has been tested and used by others. Not to mention if I wanted to add other devices from Hobby Boards, I can do it without having to re-wire things.

Now that I had a wiring specification planned out, I had to figure out the temperature sensor nodes. Using the information from the DS18B20 data sheet, I devised a simple circuit that allowed me the option of using parasite power or external power. Using a jumper on a 3 position header I was able to quickly switch between the 2 if needed. In the schematic shown to the left, placing the header jumper across pins 2 and 3 will run the sensor on parasite power. Conversely, by placing the jumper on pins 1 and 2, I could run it on the 5 volt external power.

Since the majority of the nodes were going to be in the house on walls, I wanted something that wasn't going to look unsightly on the wall. I ended up finding someone that was throwing out some old vented covered wall boxes. I then put together a couple of these circuits on some perfboard. I even made an etched board that although it turned out good took too much time. The perfboard versions were much easier to do in the small quantity that I needed, and they worked just as well. To the right is one of my perfboard sensors mounted on the wall plate ready to be installed. I connected each one individually and used the software that came with the 1-Wire adapter to get the built in hardware address of each sensor and labeled each one.

The installation

Now that I had a few of these built, it was time to install them around my house. To start, I installed one in the master bedroom, orne in the spare bedroom and one outside on the outer edge of my deck. I wired these up with the cat5 wire just stripped and screwed to the terminal block using the blue pair and the solid orange wire. Though this works, my issue with it right now is that none of the connections pass the other wire pair signals down the line, like the 12-24 volt power. For now, this is not an issue, but I do have a plan for fixing it which I still need to implement. The idea is to use an RJ45 splitter adapter similar to the one shown to the left. By crimping modular plugs to the ends of each cable coming to the temp sensors and plugging them into the 2 jacks on the adapter, this will pass all signal and power lines through. I can then clip the wire that comes off of the adapter and use it to connect to the temp sensor or whatever other sensor I try to install.

The only other hurdle to attack in this project is to get things set up in my automation software. This was insanely easy. I installed the 1-Wire plugin for OSA and after plugging the sensors into the adapter, OSA sent a 1-wire search ROM signal which automatically detects any sensors attached to the 1-Wire bus. OSA then automatically added these as objects to the system. All I needed to do then is to add them to my floorplan view and make use of them in the system.

I started with the outdoor sensor. Looking at my RCS thermostat a while back, I noticed that it had an option for displaying the outdoor temperature on the wall display keypad. Since I wrote the OSA plugin for it, I simply added an option for taking the temperature value from any other OSA object and sending it to the thermostat. Now if I want to know the temperature outside, I just look at my thermostat.

I wanted to do more than just use these to display the temperature on a wall display. My next thing to tackle was to use the value from my master bedroom sensor to aid in controlling a booster fan that I have attached to my furnace. The booster fan was originally set up to come on any time the furnace or central air turned on. I thought that this was a waste of energy, so I set up a script to say if it is between 9:00 PM and 1:00 AM, and the temperature in the room is below 68° in the room when the furnace kicks in, then turn on the booster fan. This is so that the room is warmed up a bit when we go to bed. I will do something similar for the summer months and using the air conditioner. Now I have some real world energy saving with the system. Though not much, i'd suspect, it is something.

I have recently installed two of these in my bar/man cave area in my basement. The room is very long with a fireplace at one end. My plan is to monitor both temp sensors and when the one closest to the fireplace shows a temp that is 3 or more degrees higher than the one on the other end of the room, it would turn on a fan to circulate the air in the room. The fan would then stay on until the temperature normalized throughout the basement.

One more thing that I plan on doing which I have not yet set up is to put a system in place for humidity control in my bathroom. The idea is to install a 1-Wire temperature and humidity sensor in the bathroom. I will then install a controller on my vent fan that I can turn on when the humidity gets too high. The fan would then stay on long enough for the humidity to get to a safe level. The idea behind this is to control mold and mildew buildup in the bathroom.

Conclusion

There are many other uses for 1-Wire in a home automation setup. Implemented correctly, many of these can save you time money and cleanup costs. I have not even scratched the surface of things I can do with this, and I plan to do a lot more over time.

Related Images:

August 12, 2017November 4, 2017

Fix an oozing or leaking heat block

Fixing an oozing or leaking heat block

Oozing heat block If you have done 3D printing, you may have experienced the oozing or leaking heat block problem. This is where you have filament oozing from the heat block on either the top side by the throat tube, the bottom side by the nozzle or both. This plastic will start to melt and drip down on your prints, and over time will burn on to your heat block leaving a big mess. In this section I will discuss why this happens and how you can fix it.

Why does this happen?

Incorrect block assembly You are probably wondering how this happened in the first place. The main reason is that the heat block assembly became loose at some point. This may be from movement and vibration when printing, or maybe you had to work on the assembly at some point to clean it or something else. In the illustration on the right you see that there is a gap between the throat tube and nozzle inside the heat block. This gap is what allows the heated filament to ooze out. The heated plastic will be forced through the threads of the throat tube and possibly the nozzle and start pooling up at the top and bottom of the block. If left long enough, the plastic will run down the side of the heat block and drip onto your nice print.

Now you are wondering, how can there be a gap there? You say to yourself, I tightened the nozzle in when I re-assembled it, there can't be a gap. There is something you need to understand about metal. When it is heated, it expands. When a metal ring is heated, that expansion will be outwards. If the throat tube and nozzle are not tightened together enough, the expansion of the block can cause this gap.

How can I fix this?

So now you are wondering, is this something I can fix, or do I need to buy a new heat block assembly. There is a good chance you can fix this. The main thing is to tighten things when the block is heated and the metal is expanded during reassembly. This will reduce the chance of that gap forming the next time it is heated.

Heat block parts Since your heat block was leaking, you should first disassemble it and clean it. Clean parts reduce the chance of leaking in the future. Remove your heat block assembly from the extruder carriage and set your printer to preheat. preheating for ABS is probably the best as it will get your heat block to around 240 C (464 F) making things easier to clean. With pliers holding the heat block, use a wrench or another set of pliers to remove the nozzle. Once that is removed, your throat tube should come out easily. Be VERY careful as the parts are extremely hot. Use a wire brush to clean away any plastic from the throat tube, heat block and nozzle. You may need to re-heat the parts to clean them good. Once cleaned, you can begin to put it all back together.

Correct heat block assembly These first steps are easier to do when the parts are cool and you can use your hands to fit them together. The proper way to assemble the heat block is to first thread the nozzle into the heat block, and once it is in all the way, back it off 2 turns. Next, thread the throat tube in until you feel it hit the end of the nozzle threads. DO NOT use pliers on the throat tube. With the throat tube in all the way, grab the heat block with a pair of pliers and use a wrench to tighten the nozzle in place. Once that is all together, heat up the heat block to temperature while holding it with the pliers. This can be done with the heater on the printer, or the burner on your stove. Don't use a torch or it may get too hot. Once heated, tighten the nozzle a bit more. This will ensure that the gap between the throat tube and the nozzle will be closed not letting the filament ooze out. In the illustration above, you will notice that after assembly, the nozzle is still not tight against the heat block. This will allow you to tighten it again if you need to. One more thing to note. Do not put a nut on the throat tube and tighten it to the heat block. This can cause more issues.

Now you can re-assemble the extruder assembly. Correct nut assembly Use the nut on the throat tube to tighten the extruder assembly to the carriage to prevent the heat block assembly from spinning when printing. Incorrect nut assembly Be careful not to over-tighten the nut as you can easily break the throat tube.

Related Images:

August 12, 2017September 24, 2017

Adding HVAC overlays to MisterHouse

Introduction

DISCLAIMER: This is an old topic that I migrated from my old website due to the traffic it used to get. I no longer use MisterHouse for my automation, so I will not be able to answer any questions regarding this topic. Some of this information may be out of date, but may still work.

indoor temperatures graph

For some time now I have been using the MisterHouse automation software with my Raspberry Pi as my main automation software. One of the features that I use is the weather data from the internet_weather.pl common code module. I also have an RCS-TR40 RS485 thermostat and 7 one-wire temperature sensors throughout the house that I use with this setup also. The weather module has a graphing feature that allows me to graph the indoor temperatures from my one-wire sensors. A sample of this is shown to the right. Though this was a nice feature, there was somehting missing. I wanted a visual representation of my HVAC operation overlayed on the graph. I saw a perfect example of what I was looking for on Marc Merlin's blog site marc.merlins.org/perso/homeha/2009-12.html. About 1/4 of the way down the page you will see the 2 graphs. Marc uses cacti with RRD to get his results, but I was using a module in MisterHouse that did not have this functionality. This post shows the steps I took to modify the code in the weather module to be able to do this.

The Code Modification for HVAC Overlays

Before performing any of the steps described here, it is always a good idea to make backups of the files that you are modifying in the event that you need to revert back. With that said, let's proceed.

The main file that you will need to modify is the weather_rrd_update_graphs file located in the MisterHouse/bin folder of your installation. When I made the modifications to my setup, I had to start a new RRD database file because of the way that I modified the file. I am going to show you how to do this in a way that SHOULD NOT affect your current RRD database.

The first step is to locate the section of code that defines the default color codes for the graphs. In my file, this started at line 44. Depending on the number of HVAC zones and whether you want to show heating, cooling or both for these zones, this will determine the number of tempspares that you will want to sacrifice for this. In my setup I only have single zone heating and cooling, so I would only need to hijack $tempspare9 and $tempspare10. The default color codes used for 9 and 10 are "66FFFF" and "0000CC" respectively. These will need to be changed. I used "FF6F7D88" (9) for the heating color, and "6F87FF88" (10) for the cooling color. One thing you will notice that is different with these 2 values is that they are longer than the original values with the added "88" at the end of each. This is very important as the last 2 hex values are the transparency values. This is what allows the HVAC color bars to be overlayed over thetemperature line graphs and still have them visible.

The next part is a bit tricky. You will need to remove the tempspare RRD DEFinitions for whatever $tempspares you are using for this. In my setup I would remove tempspare9 and tempspare 10 DEFs. For each tempspare, you will need to remove 6 lines of code.

1	."\"DEF:mintempspare9=$RRD:tempspare9:MIN\","
2	.($weather_uom_temp eq 'C' ? "\"CDEF:fmintempspare9=mintempspare9,32,-,5,9,/,*\"," : "\"CDEF:fmintempspare9=mintempspare9\",")
3	."\"DEF:maxtempspare9=$RRD:tempspare9:MAX\","
4	.($weather_uom_temp eq 'C' ? "\"CDEF:fmaxtempspare9=maxtempspare9,32,-,5,9,/,*\"," : "\"CDEF:fmaxtempspare9=maxtempspare9\",")
5	."\"DEF:tempspare9=$RRD:tempspare9:AVERAGE\","
6	.($weather_uom_temp eq 'C' ? "\"CDEF:ftempspare9=tempspare9,32,-,5,9,/,*\"," : "\"CDEF:ftempspare9=tempspare9\",")

Now, where you deleted these lines of code, you will add 2 lines for each tempspare you are replacing.

1	."\"DEF:tempspare9=$RRD:tempspare9:AVERAGE\","
2	."\"CDEF:ftempspare9=tempspare9,1,EQ,INF,UNKN,IF\","

Next, you will need to change the LINE2 definitions for your tempspares to AREA plots. Find the following lines:
. ($sensor_names{tempspare9} ? "\"LINE2:... :'')

Remove the "LINE2" and "GPRINT" lines from each and replace with this:

"\"AREA:ftempspare9#${colortempspare9}:" . sprintf("%-${max}s",$sensor_names{tempspare9}) . "\","

For the last code modification, you need to edit the weather_rrd_update.pl file in "misterhouse/code/common/". Look for this block of code:

if($config_parms{weather_uom_temp} eq 'C') {
grep { $_=convert_c2f($_) unless $_ eq 'U' } ($rrd_TempOutdoor, $rrd_TempIndoor,
$rrd_TempSpare1, $rrd_TempSpare2, $rrd_TempSpare3, $rrd_TempSpare4,
$rrd_TempSpare5, $rrd_TempSpare6, $rrd_TempSpare7, $rrd_TempSpare8,
$rrd_TempSpare9, $rrd_TempSpare10, $rrd_DewOutdoor, $rrd_DewIndoor,
$rrd_DewSpare1, $rrd_DewSpare2, $rrd_DewSpare3, $rrd_TempOutdoorApparent);
}

You will need to remove all references to TempSpareXX that you are converting. If not done, this could prevent the HVAC bars from showing up if you have your user configuration "weather_uom_temp" set to "C"elsius.

HVAC overlays user code additions

Now you need to define things in your user code. This will vary for each setup as thermostats and/or ways of identifying that the furnace or AC is on are done differently in each setup. This is basically how I have it set up in my user code:

# Define the weather hash's initial starting HVAC values
if ($Startup or $Reload) {
$Weather{TempSpare9} = int(0);
$Weather{TempSpare10} = int(0);
}

#### Now, if your furnace is on tempspare 9, the code will be something like this: ####
if ($RCS_current_state eq 'heat') {
# Tell the weather hash that the furnace is on
$Weather{TempSpare9} = int(1);
} else {
# Tell the weather hash that the furnace is off
$Weather{TempSpare9} = int(0);
}

Last, you can tweak your setup in your mh.private.ini file adding your own sensor names for each tempspare that you set up. You can also tweak the colors of your displayed bars from here the same as your other sensors. Remember though, if you change color values in your mh.private.ini file, you NEED to add the transparency value to each color. I found 88 to be a good transparency value for me, but your situation may differ.

Below is a sample output of my setup with the furnace overlays in place.

Related Images:

July 4, 2017February 17, 2019

Using a Sonoff with ESPEasy and a Vera home controller

Description

This post is to describe how I used Sonoff modules with my Vera Plus automation controller. I'll explain the configuration and setup of the Sonoff, as well as the modifications needed to an existing plugin to make the whole setup work.

Details

Sonoff modules are cheap Wi-fi controllable relay modules that are based off of the ESP8266 chip. Here I will describe how to control these with a vera home controller. The procedures described here should work for nearly any ESP8266 based relay module and are not exclusive to the Sonoff modules.

The basic outline of the procedures are as follows:

Flash new firmware to the Sonoff or other ESP8266
Set up and configuration
Testing the device
Installing the necessary plugin on your Vera
The configuration settings
Adding local control using the button
Updating your Vera device based on the local button press

DISCLAIMER: I take NO responsibility for issues or problems that may arise from using the procedures outlined here. I am merely giving the information on what worked for me on the devices that I have. The procedures may be different for other ESP8266 modules. Please consult documentation on the modules that you have for more information. It should also be noted that this will wipe out the existing firmware on the device and it will no longer be able to be used as originally sold.

Flashing firmware to the Sonoff or other ESP8266

The first step in this process is to make sure we have the correct firmware loaded on your device. The firmware that we will be using for this project is the ESPEasy firmware which is an open source firmware for ESP8266 modules. There are a few ways to flash the firmware to the device, but the procedures I will outline here for flashing this firmware to the device involve the use of the Arduino IDE. One thing you will need to do the programming is an FTDI USB to serial adapter. These can be purchased on ebay cheap. Lets get started.

The first thing you will need, if you don't have it already, is the Arduino IDE which can be downloaded from this link: https://www.arduino.cc/en/Guide/HomePage. Follow the installation procedures outlined on that page to complete the install.

Once you have the IDE installed, you will need to add the ability for it to flash the ESP8266 modules. To do this, got to File > Preferences, and just up from the bottom of the Window you will see a text box labeled "Additional Boards Manager URLS". In the box, paste this URL "http://arduino.esp8266.com/stable/package_esp8266com_index.json". You should now see some new entries in the list of available modules. The one we are concerned about for this post is the "Generic ESP8266 Module". Select that and the com port that you have your FTDI adapter attached to.

Next you will need to connect the FTDI adapter to the Sonoff module or other ESP8266 device. For the purposes of this post, I will only outline the connection to the Sonoff. It is easies to solder a header connector on to the Sonoff on the center row of holes as shown below. If you plan on flashing a lot of modules, you may want to make yourself an adapter cable to connect the FTDI adapter to the Sonoff. The cable should be wired like the diagram below.

Next you will need the firmware to flash. This can be downloaded from the SourceForge websit using this link: https://sourceforge.net/projects/espeasy/. In order to flash the firmware, you will need to put the Sonoff into programming mode. To do this, unplug the USB cable to the FTDI adapter, hold down the reset button (labeled GPIO0 in the image above) on the Sonoff module, then plug the USB cable in again. Now click the upload button in the Arduino IDE. The firmware should flash to the device. If for some reason it does not, chances are that you didn't get it into programming mode. Repeat the steps above and try again.

Set up and configuration

After flashing the firmware to the device, you need to do the initial configuration to get it to connect to your WiFi router. When a device with ESPEasy firmware starts for the first time, it will present itself as an access point. For the initial configuration you will need a tablet, smart phone, laptop or other wireless capable device. On your chosen device, go to your configuration screen for setting up WiFi. In your list of available access points to connect to, you should see one called ESP_0. When you try to connect to it, it will ask for a password. The default password is configesp. After connecting to the device, go to a web browser and navigate to 192.168.4.1. This should bring you to the new device wifi setup page. This is where you will set the device up to connect to your access point. Select your access point from the list, and if your wifi is encrypted and requires a password, type that in and click connect. You should then see a page showing a countdown. At this point the controller is attempting to connect to your access point. If successful, your laptop, tablet or phone should automatically switch back to connecting to your regular wireless access point and navigate you to the IP address that the device picked up from your router's DHCP server.

You are now ready to perform the device specific configuration to define how you will connect to the device to your Vera. For my setup, I picked a range of IP addesses that I would use for my Sonoff devices. I made a list of my Sonoff devices and assigned them each an IP address. I left room in the pool of IP addresses I chose to have more room if I decided to add more of these to my setup. You can judge this based on your configuration.

Now, in the menu at the top, click on "Config". This will take you to the main device configuration page to define how you will connect to the device. Here we will start by selecting a protocol to use. I am not sure of the specifics for each protocol, but for my setup I chose the ThingSpeak protocol. You can ignore the Controller IP and Controller Port for now. Next we will set up the IP address for the device from the list that we made earlier. You will set this at the bottom of the page under "Optional Settings". All of these settings should be set as appropriate for your home network setup, but here is how I set mine up. Type the IP address in the box labeled ESP IP. Next you will need the IP address of your wireless access point which in most cases can be typed in for the ESP GW and ESP DNS settings. And last would be setting your subnet mask in ESP Subnet, which again in most cases can be left at the default of 255.255.255.0.

The last thing that you need to configure is how the device will operate. Since the ESPEasy firmware can be used on amy number of different ESP8266 devices, the firmware is highly configurable for many different types of devices. For the HTTP Switch plugin that we will be setting up with Vera, we are only concerned about configuring a relay for now.

In the top menu, click on Devices. On initial setup, the devices page should look like this. Some things you will want to know prior to setting up the relay. The standard Sonoffs have the relay connected to GPIO 12. If you are configuring this for some other type of ESP8266 device you will need to consult any available documentation to find out which GPIO port the relay is configured on. Start by clicking the Edit button for device number 1. On the next page you will be given an option to select a device. For this select "Switch Input" since we will be controlling a relay. Once selected, you will be given a list of configuration options. The options we are concerned with for now are 1st GPIO, Pull Up, Switch Type, Switch Button Type, Send Boot State and Send Data. For the 1st GPIO, select GPIO-12 for the Sonoff relay. If you are using another ESP8266 device, select the GPIO that your relay is connected to. For the Switch Type, simply select "Switch" as this is a relay controller. Last is selecting the Switch Button Type which will be "Normal Switch". You should also make sure to check the box next to Pull Up since we will be using the ESP8266 internal pull up resistors. For my setup I have also checked the boxes for Send Boot State and Send Data. All other settings for now can be left at their defaults. Now click on Submit to save the new device configuration.

Now we will reboot the Sonoff by clicking Tools in the top menu and selecting Reboot. This will cause any changes to be loaded. If you made changes to the IP address on the Config page, you will most likely need to type the new IP address into your browser's address bar to access the newly configured device.

Testing the device

Prior to doing anything on the Vera side of things we will want to make sure that all of the work we did configuring the device is going to work. The ESPEasy firmware uses GET based control commands that can be typed into your browsers address bar. For testing we are going to use the command for turning on and off the device. You will want to have something connected to your Sonoff or other 8266 device to be able to see if the commands work. For me, I connected a small night light for this. The command format that you will use is this:
http://{your device IP addess}/control?cmd=GPIO,{GPIO pin},{1 or 0}
In the command above, replace {GPIO pin} with the GPIO pin of the relay, in our case 12, and replace {1 or 0} depending if you want to turn on (1) or off (0) the device. When sent a command like this:
http://{your device IP addess}/control?cmd=GPIO,12,1
The device should give a JSON response that looks like this:

{
"log": "GPIO 12 Set to 1",
"plugin": 1,
"pin": 12,
"mode": "output",
"state": 1
}

If you can successfully turn on and off your Sonoff, you are ready to move on to configuring your device(s) in Vera.

Installing the necessary plugin on your Vera

In my setup I am using a Vera Plus controller running UI7. This plugin should work on any Vera controller though running UI7. I cannot verify, nor do I make any claims, that this will work on devices running UI5, though it may, so test it at your own risk.

The plugin that I modified to make all of this work is called "HTTP Switch (WiFi Switch)". You must install this prior to uploading the modified files listed in the next section.

Next, there are 3 files that you should upload to your Vera; D_HttpSwitch1.json, D_HttpSwitch1.xml and L_HttpSwitch1.lua. A .zip file containing these 3 files can be downloded by clicking on this link. Once downloded, extract the files from the archive to a temporary folder on your computer. In your web browser, navigate to your Vera controller and in the left menu, click on Apps > Develop apps > Luup files. Drag and drop the 3 files into the Upload box or click the Upload button and select them. Once the files are uploaded, rebot you Vera controller by clicking on Settings > Net & Wi-fi and clicking on Reboot at the top. Once the Vera has rebooted, you should be ready to configure your first device.

The configuration settings

After installing the HTTP Switch plugin, it should have created one device for you. Navigate to Apps > My apps and click on the Details button for the HTTP Switch plugin. The newly created device should be listed under "This plugin has created the following devices:", click on the device. To configure the device, click on Advanced and navigate to the Variables tab. Your settings should look similar to this:

The first steps in configuring the device is knowing the devices IP address and the GPIO pin that you set up earlier. When setting the IP address or GPIO pin number in settings, you MUST check the box underneath that says "switch to input type text". If this is not done, it will not work. Set these two values and once set, reload the luup engine. Once the luup engine reloads, return to the advanced tab for the device. For the LinkStatus, you should see "Online!" and for PingStatus you should see "UP". If you see something like "Set IP!" for the LinkStatus, it is possible that you didn't check the box for "switch to input type text". Double check your IP address setting and fix as necessary. If the IP address is set, you may want to try restarting you Vera by clicking on Settings > Net & Wi-fi > Reboot. Once you see the status of the device as "online!", you should be able to control your device. If by chance you cannot, double check to see that you have the correct GPIO pin value set.

Adding local control using the button

So I had a request to explain how to use the ESP Easy rules scripting to make use of the local button and the LED on the Sonoff. This will also allow control via a 433MHz remote or other controller if you are using a Sonoff RF device since the 433MHz receiver is connected to GPIO 0 which is the same GPIO port as the local switch. Because of this, a 433MHz trigger is the equivalent to pushing the local button. In this example, we will use the button to locally toggle the Sonoff module on or off. Also, when the device is turned on or off, we will use the LED on the module to indicate the on/off state of the device. Lets get started.

By default, the ESP Easy firmware has rules scripting disabled, so in order to use scripting, we need to enable it. In the top menu, click on Tools and then click on the Advanced button. Near the bottom, just above the Experimental Settings section, check the box next to "Rules:". This will give you a new selection in your top menu called "Rules".

Before creating our Rules script, we need to create an additional device to be able to use the button. Click on your Devices link in the top menu. You should already have a device listed under Task 1 for your relay. We will now add the onboard switch to Task 2. Click on the Edit button for Task 2. Chang the device settings to match the image to the left. The two values from this screen that we will be using in the script are "Name", and "Value Name 1". We will also use these same two values from the relay device that we created earlier.

Now lets write a simple script. When you click on the Rules link, you will simply see a blamk box. This is the script window where your script will be placed. First I will give you the rules script code, and then I will explain how it works. Here is the script:

on Relay#Switch do
    if [Relay#Switch]=0
        gpio,13,1
    else
        gpio,13,0
    endif
endon

on Button#Switch do
    if [Relay#Switch]=0
        gpio,13,1
        gpio,12,1
    else
        gpio,13,0
        gpio,12,0
    endif
endon

So, there are two sections to the script, the first starts with "on Relay#Switch do", and the second starts with "on Button#Switch do". In both sections you will notice the "Relay#Switch" and "Button#Switch". These are the values from the devices that I mentioned earlier would be used in the script, and as can be seen, they are written in the format {Device Name}#{Device Value Name 1}.

The first part of the script deals with incoming HTTP requests and handles any change in the relay state with "on Relay#Switch do". Next, "if [Relay#Switch]=0" checks the status of the relay to see if it is "0", and if it is, turn the LED on which is on GPIO 13. I am speculating that the check of the relay state happens before the relay is turned on or off, so when checking "if [Relay#Switch]=0" is true, we are about to turn it on, and vice versa.

The second part of the script deals with the button press using "on Button#Switch do". It again checks the state of the relay, but here we need to perform two actions; first turn the LED on (or off), and then turn the relay on (or off). Seems simple enough.

One thing that I noticed in my testing of the script is that the response time was a bit slow. When I would press the button, the device would come on, and then 5 to 7 seconds later the LED would come on. I also had to wait a few seconds after turning it on/off before I could turn it off/on again. When sending an HTTP request, the LED would come on at the exact second that the device turned on. Maybe you will have different luck with yours.
EDIT: Thanks to Patrick (from the comments below) it was said that if you edit any devices that you have in your devices list and uncheck the "Send Data" box, this will fix that issue. I tested this on my units and the response time is very fast now. Thank you Patrick.

I have only given you the basics of what the ESP Easy firmware can do. With rules, you can perform actions such as sending HTTP or MQTT requests back to your controller and much more. If you want to perform more complex actions with your rules, check out the rules tutorial on the Let's Control It website: https://www.letscontrolit.com/wiki/index.php/Tutorial_Rules

Updating your Vera device based on the local button press

So, now you have your Vera controlling your Sonoff devices. You even have local control of those devices from the button on the Sonoff itself. But you may notice that when you control your device locally with the button, the status of your device does not change on the Vera controller. How can we fix this? Luckily, the Vera controllers, at least for UI7, have the ability to receive LUUP action requests through HTTP requests on port 3480. A typical HTTP request for a light switch looks like this:
http://{your-vera-ip}:3480/data_request?id=action&output_format=json&DeviceNum=122&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=X

So let's analyze what is going on here. First, we are making a data request, and based on id=action, we are telling Vera that we want to perform some kind of action. Next, we are going to tell what the output format of the response to that action should be. In this case, it will be a JSON response based on output_format=json. The two most common formats are JSON and XML. Since we are not going to be doing anything with the response in this example, we'll just leave it set to json. The next thing is important. It is the device number. In the example we have DeviceNum=122. The device number will be the device number of the Sonoff as it is defined on your Vera controller. There are a few ways to find your device number. One way is to look up your device from your "Devices" list, clicking the icon next to your device and then clicking on "Advanced". The device number will show at the top of the page:
Vera device number
The next part is defining the service ID for the device which is serviceId=urn:upnp-org:serviceId:SwitchPower1. Since the Sonoff is a switch type device, this is what we'll use. The next part defines the action we want to take, action=SetTarget, which is setting a value for a target device. And last we'll set the value for that device with newTargetValue=X, where X is a boolean on (1) or off (0) value.

WHEW, you made it through that part, and hopefully you have some understanding of what is going on with the HTTP request. Now we need to translate this to an ESP Easy's rules engine command. Let's look back at the rules engine script that we created earlier. Since our goal here is to relay back to Vera when the button is pressed, the specific part in the script that we want to look at is the "on Button#Switch do" section of the script. In this part of the script we want to make two HTTP calls. The ESP Easy rules script command that we will use is "SendToHTTP". To use this command we need to break apart our HTTP request that we defined above into parts. The parts will be separated by commas in this format without spaces between the commas:
SendToHTTP {Your Vera IP} , {Port #} , {Your HTTP call}
So using this format, our request above would translate to:
SendToHTTP {your-vera-ip},3480,/data_request?id=action&output_format=json&DeviceNum={your-device-number}&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=X
Replace the parts in green with your values. Here is the full script for my device.
on Relay#Switch do
if [Relay#Switch]=0
gpio,13,1
else
gpio,13,0
endif
endon

on Button#Switch do
if [Relay#Switch]=0
   gpio,13,1
   gpio,12,1
   SendToHTTP 192.168.1.123,3480,/data_request?id=action&output_format=json&DeviceNum=122&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1
else
   gpio,13,0
   gpio,12,0
   SendToHTTP 192.168.1.123,3480,/data_request?id=action&output_format=json&DeviceNum=122&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=0
endif
endon
Immediately after we tell GPIO 12 (the Sonoff relay) to turn on or off, we send the appropriate call back to the Vera controller to update the device status. That's all there is to it.

Conclusion

I hope that this tutorial was helpful. If you have problems or find errors, leave a comment and I will try to help.

Happy automating.

Related Images:

June 29, 2017September 24, 2017

My personal weather station

Description

For a while now I have wanted to add a personal weather station to my home automation system. The idea was to use the data collected for things like controlling when my lawn sprinklers run. I also plan on using temperature and humididty data to determine things like heating and cooling (HVAC) operations. In this post I will log the ongoing details of my modular personal weather station project. With the help of my new Anet A8 3D printer that I purchased earlier this year, I was able to use it to build all of the parts needed for the project. The project was started a while ago, but I didn't have a place at the time to post my progress, so here it is.

Details

So far I am working on 4 parts to the weather station. Wind speed anemometer, wind direction vane, rainfall gauge and a temperature and humidity sensor. All sensors need to communicate to my home automation system over my MySensors network. I am hoping that I can control all data collection with a single arduino pro mini built on a MySensors Easy/Newbie PCB created by Sundberg84 from the MySensors forum. In this post I will outline each modular section of the project. All of the 3D printed parts for this have been designed in OpenSCAD and will eventually be posted on my thingiverse page. This post is a work in progress. Check back to see more information.

The anemometer and wind direction vane

The first part of the project that I started with was a combination of two sensors. An anemometer for measuring wind speed and a wind vane for determining wind direction. weather station wind sensor This is the first prototype design of the 3D printed parts. Some minor changes have been made since this design. The first was to invert the center mount sections so the screws screwed in from the bottom. This put the wind direction vane on the piece with the square mounting peg and the anemometer was moved to the other piece. The reason for this was to keep rain from collecting in the small screw recesses and potentially getting inside the case. The next change which I am in the process of printing as I write this, is a new piece with a round mounting peg instead of a square one. This was done because of a later decision to mount everything using schedule 40 PVC electrical conduit. weather station wind speed sensor rotor

The anemometer is mounted with a ball bearing that is press fit into the cap. The shaft, a 1/4 x 20 bolt with a small rotor that has a magnet mounted in one end and that will pass by a magnetic reed switch. The arduino will use the counted pulses from the reed switch to determine the wind speed. The anemometer cup design was borrowed from a project on thingiverse, but I can't seem to find the original that I used. The cups, arms and main shaft attachment are all separate printed parts that I have glued together. This made for an easier build on my 3D printer.

Related Images:

June 11, 2017September 24, 2017

My start into open source hardware

So I decided to get my feet wet on creating my first commercially manufactured circuit boards to release as open source hardware. For one of my automation projects Prototype switch board I had built some custom in-wall automation scene controllers based on MySensors. The controller consisted of 3 boards; the power supply board, the computer board (Arduino Pro Mini) and the switch board (first prototype seen on the left). 30x70 proto board All three of the circuit boards were built on standard 30mm x 70mm prototyping circuit boards like these. My first fully assembled version of the controller can be seen below. Though the design seemed to work good, they were a bit of a pain to put together. Prototype scene controller Building one controller on prototyping boards and wiring it all up took 4 hours or more. After building 3 of them and seeing how they worked, I wanted more, but I didn't want to spend all the time making them. So, it was time to get my feet wet on PCB manufacturing.

The design

So I figured that if I was going to be making a number of these, I wanted the design to be flexible. I wanted to be able to do more with it than just a scene controller. Having the 3 separate boards made it modular. I figured I would design it so that I could build more than just switch boards for the face of the CPU board.

The main board

Scene controller main board For the design of the main board I broke out all digital and analog IO lines from the pro mini except for A6 and A7. I also have ground, raw 5 volt power plus the 3.3 volt regulated power from the pro mini available on 2 single inline header connectors. A4 and A5 on J3 also provide I²C capabilities to the front board. With all of these, the only limit to what can go on the front board is what you can fit in the small space..

The keypad board

Keypad board PCB design The design of the keypad board may look a bit crowded, but it was designed that way to make it flexible. Many different keypad designs can be made from this one board. I had gotten the idea for this type of design from a video I had seen by a guy in Australia named Jonathan Oxer. He had designed light switches for his house and designed a single universal circuit board that allowed him to use that one board for building different switch configurations. You can find the video here http://www.superhouse.tv/arduino-light-switches/ . His other videos on home automation are well worth watching. Check out his website here. The keypads can be made with or without indicator LEDs.
4 button keypad 2 button keypad Standard paddle keypad The buttons can have any text embossed on them, or they can just be left blank. Here are just 3 examples of the many different wall switch designs that can be made using this board. No need to have separate boards printed when you want to put together a new switch. Just grab a board, print the switch layout on your favorite 3D printer and screw it together. Done!

The power supply

There is nothing fancy with the power supply board. It is based on the standard HLK-PM01 power supply module that will take a wide input voltage (90 ~ 264V AC) and convert it down to the 5 volts needed to power the controller. The output is filtered with a 0.1uf ceramic capacitor as well as a 10uf electrolytic to help stabilize the voltage supplied to the controller. On the AC input side, a standard 0.75A glass fuse as well as a 73°C (163°F) thermal fuse is used for maximum protection since this will be used in wall. You can never be too careful.

Conclusion

In the future, I will design other sensor boards to be used with this controller. This is an open source design, so feel free to take the gerbers and design your own sensors for it. I hope you like the design. Let me know your thoughts.