IKEA Motion Lamp Hack Update

Back at it again, I decided to add a few more features before I deem this project complete and ready to be put into service. In case your are wondering, this is based on my previous work on the IKEA Motion LED Lamp Hack. This time around I just wanted to make a few hardware changes that will let me have full control of the light.

IKEA Motion Lamp Resistor Modification

USB HUB + WiFi Teardown

One day I come across an interesting product from Adafruit that I couldn't resist getting. It will make a nice addition to the Raspberry Pi Zero. It's a 3 port USB hub with inbuilt WiFi which takes the fourth port. Inspired by insideGadgets, here are some photos and part numbers.

USB WiFi Hub

Wish it was a bit more compact. I have a USB to OTG adapter in the USB plug.

USB WiFi Hub Inside

USB WiFi Hub PCB Top

Main Components

• USB HUB - Terminus FE 1.1s
• 3.3V Regulator - AMS1117
• WiFi - Realtek RTL8188ETV

USB Wifi Hub IC

USB Wifi Hub WiFI

USB WiFi Hub PCB Bottom

Interesting thing to note is the fourth USB port footprint, this PCB can support the WiFi module or fourth USB port. Overall it is a simple design that would be easy to embed in another project without the housing.

IKEA Motion Lamp Hack

Last year while visiting a friend for the Portland Mini Maker Fair I became the owner of an IKEA STÖTTA, a battery powered, motion activated, LED lamp. I knew it was ripe for hacking. After arriving home, it sat on my desk waiting to be disassembled to reveal its secrets. I figured the only way to get it off my desk was to get around to tearing it apart and seeing what I could do with it. Over the weekend I spent more time trying to decide which direction to take since there are plenty of features I could add. At least I can get something going now and add to it later. Who ever said a project had to be completed?

IKEA LED Light PCB Close Up

The lamp consists of a small PCB which contains the following main parts;

• HS8A005 (BISS0001 Motion Detection IC)
• PIR Sensor
• LED Driver (Inductor and IC, powered by battery VCC and outputs 3V)
• 3.3V Regulator
• Voltage Detector (Disables trigger on low battery)

IKEA Light PCB Labeled

Mooltipass

A year and a half ago I helped support the Mooltipass on Indiegogo. I originally heard about it on Hackaday.com, but what really captured my attention other than it being an offline password manager, is that it was going to be designed by the the community. Anyone could volunteer time to help with the project. Unfortunately I was unable to do so with the many other things I had going on. But at least I could support the project by backing it.

The Mooltipass is a USB encrypted (AES256) credential storage device that acts like an HID keyboard. It can be used with or without the Chrome app and the extension. The extension allows it to detect which site you are on and load that credential after an approval from the on board display, as well as manage the device settings and credential database. The goal of the Mooltipass is to minimize the possible attack vectors on your stored passwords. I use LastPass which has a larger attack surface and offers greater convenience, so for the time being, I am using both systems. Security for the Mooltipass is accomplished by being a physical device as well as having a removable smart card. Without the smart card and pin number, you cannot access the credentials even if you have the backed up binary blob. There is also a permanent lockout after three failed attempts of entering the pin. Which I find a bit short since with the touch buttons it is easy to mess up. I should also mention that the pin isn't limited to 0-9; it has used all of the possible hex values, 0-9, A-F. Pretty neat!

Since the Mooltipass is a physical device pretending to be a keyboard, it will work with sites in which the login form isn't detectable, such as a Flash based web app, which is another great feature. This is accomplished by using the onscreen display to send the credentials. An unintended use that I found is that is greatly reduces keystrokes for non web based logins which is helpful for people like myself who have tendentious.  I realized with the Mooltipass how many times a day I am entering in my credentials.

Living Room Node Upgrade

For over a year now the living room node and La Crosse Gateway has been sitting atop a plastic bin next to my patio slider in a mess of wires.  This is when you know you have too many projects lying around the house.  So this summer I decided to design a PCB with a nodeMCU that will replace both projects and mount atop of a power brick. I went with the nodeMCU since there is power nearby, ease of connecting directly to the MQTT broker, and I can broadcast more often without the power limitations of a battery. This project frees up two RFM12B boards so that they can be used for the other window and the front door.

Living room slider node and La Crosse gateway

PCB Battery Clip

Just a small update to the battery powered nodes. Until now I had used a piece of tape to hold the PCB to the battery pack. It was always a pain when changing the batteries or accidentally hitting the node and watching it fall apart. I also wanted to try my hand at Fusion 360, so this seemed like the perfect opportunity.

Fusion 360 sketch of PCB battery holder clip

I still have a lot to learn in using Fusion 360 but I got the job done, um sort of. I had issues extruding the width less than I had initially and I didn't want to start over. So canceling the print worked good enough at the size I wanted.

Fusion 360 model of PCB battery holder clip

It came out quite nice. I just need to learn Fusion 360 properly.

PCB battery holder in action

C.H.I.P. by Next Thing Co

After a year of waiting it has arrived: the $9 computer from Next Thing Co. When it launched on Kickstarter, there was no reason to skip backing this one to at least see what it was all about. Now that it has arrived I am quite happy that I did. For such a large project it would hardly be worth calling it late. My reward was due May 2016 and I received it June 2016. Very good compared to most crowd sourcing campaigns. I selected the C.H.I.P. plus battery reward, but before it shipped you could add accessories. I added the VGA adapter and an extra C.H.I.P. That way I can use it on my desk attached to my monitor since the DVI input is already in use. With the Raspberry Pi I have to connect it to the TV if I want to mess with it directly. At this price it's cheap enough to buy more than one that you can dedicate to a project and just fuggedaboutit.

$9 C.H.I.P. and accessories

nodeLED

As a hacker, I know all too well how much workbench space is vital. Alongside my three monitors, I have an extended desk that houses my soldering irons, compartment shelving, and countless projects, among other tools and devices. One constant that seems to get in my way is an old desk lamp. That’s where this project came to light, ha! I decided to design my own lamp using an analog RGBW LED strip. This board I designed will give you the tools to design your own WiFi controlled light source.

The boards' controller is run by the NodeMCU which is connected to an N-Channel MOSFET for each color of the RGBW LED strip. Trimpot for brightness and two user buttons (that can be setup to change modes, possibly) were also added. A 5v regulator was then added so the power can be shared with 9-12v input for the LED strip. The nodeMCU will be updated by wireless as well.

My idea is to have the nodeMCU be a web server for direct control via a web page. The site will have various configurations including color options, number of channels, animations (like fade effects) and a timer. I’d like to have it connect to MQTT server to integrate with larger servers such as openHAB.

You can follow the details of the project on Hackaday.io

https://hackaday.io/project/11521-nodeled

JeeNode to MQTT Gateway

It's been a few months since I have worked on openHAB but that is mostly due to focusing on FriedCircuits, Hackaday Prize and the Maker Faire. Not a dull moment around here! I finally sat down while watching some tube (or rather crystals) to start work on the JeeNode to MQTT gateway. Up to this point if you have read my other posts I have still relied on DomotiGA to get the JeeNode data into openHAB. This is because DomotiGA has support for JeeNodes. I noticed the sensor nodes weren't checking in again which usually is because DomotiGA is not running, this time I think it just needed a restart plus one node actually needs batteries. This prompted me to finally get around to writing the gateway. Once complete I won't need DomotiGA and the desktop UI so I can use Ubuntu server for my rebuild of openHAB.

After some research I was able to get receive the data over serial, split it and shift the bits into separate variables to publish over MQTT. Using the Paho MQTT python library it is trivial to connect and publish. I decided to map out it out as JeeNode/node#/name/value. Simple. I should mention this code is assuming the JeeNode is running the room node sketch or at least using the packet format. My remote nodes and receive node code is on Github if needed. Here is a graphical view of the tree for one node.

MQTT JeeNode Map

Switchmate

Last year my friend and I backed the Switchmate on Indiegogo.  At the time I didn't have much of a home automation setup - just two window nodes and the slider.  Not even any connected bulbs and I was still on DomoitaGA so I didn't have any of the fancy rules I now have in openHAB.  Over the course of the campaign, they had different deals so I ended up with three rewards.  I had actually forgotten about them, in part because since switching to openHAB and getting connected light bulbs, the need for these switches seemed diminished.  But one day I was pleasantly surprised to receive a shipping notice.  A few days later I received the package in the mail and boy was I surprised!  The quality and presentation was excellent - not what I expected at all.  Curious about them?  Read on!

Routing High Speed Signals and USB

Eventually in most hobbyists' path, one will end up working with high speed signals. These days so many microcontrollers support USB and even ones that don't can use software USB. Of course using a microcontroller is the answer to every engineering problem, right? Most of us just work with USB 2.0 connected directly to a microcontroller for uploading and serial communications. With advent of the USB Tester, I have learned more about USB than I ever thought I would. Recently I have dived into USB 3. Which compared to 2.0, is so much more sensitive to your PCB routing as I found through trial and error. I have seen many projects on the various blogs and for sale on the usual sites that don't follow or even try to route correctly. With USB 2.0 for the most part you can get away with it and it will still work. To help save you some time, I would like to share my findings that should help prevent PCB re-spins just due to USB not working. This is by no means an exhaustive guide to high speed routing as there are plenty of application notes across the web for that. I will list a few at the end of this post that I found helpful.

I am not by any means an expert on high speed signals, but I have learned enough to get the job done. In the end I was fortunate that my desktop PC had the first USB 3 controller made by Renasas which is much more sensitive than my laptop so I knew if it worked it would work for anyone. 

Diagram of USB Differential Pair (Wikipedia)

High speed signals use differential pairs instead of a single trace or a clock / data pair like I2C. By using a pair of traces you can cancel out noise. One is positive and the other negative. The idea is that electromagnetic interference would affect both signals and therefore would be canceled out since the receiving end looks at the difference of the two. Using a 2 channel oscilloscope you can connect to both signal and do a bit of math to see the resulting signal.

With USB 2.0 I was able to get away with branching (breaking out D+/D-). These are terms that you will come across with working with high speed signals. 

• Branching is when the traces are not direct from one point to another and have a split.
• Stubs is if the signal hits a via with a pin in it from the top layer instead of the bottom layer to from a straight path. 

USB 2.0 only uses 1 differential pair vs USB 3 which uses 2 for full duplex operation. If you are using the Type-C connector you have duplicates of each pair plus for reversibility and extra signals for detecting orientation and other signal types.

USB Type-C Pin Out (Credit someone on the internet)

Important things to consider while laying out your board. 

• Calculate trace width and spacing to maintain 90Ohm differential (Calculator) This will also depend on the PCB you will be using. In my case OSHPark lists the specs of their PCB.
• Maintain trace length of each pair. CAD tools have a differential pair routing tool along with meander to adjust traces for matching. A better way is to add a little length on the end of the short trace before connecting to your pad instead of having to meander which will affect the 90Ohm differential target. It can take a bit of time though to get it just right.
• Use as few vias as possible as they affect signal integrity.
• Route using 45degree angles instead of 90. I think this is to avoid reflections. 
• Avoid stubs by using a via before routing to a through hole part so you are on the bottom layer. 
• As much as possible, route above/below a continuous ground plane. On 2 layers boards this is pretty much impossible. With USB 3 it really should be a 4+ layer board. 
• Signals should be on the outer layers. 
• As always use the shortest path possible. (The Wozinack way ;))
• Another one that may be hard to do is don't cross signals above or below another signal. Ideally there should be a ground plane there anyway. 
• One way to avoid inverted pairs having to cross over each other is to mirror a part but then you have to deal with parts on both sides which may or may not be an issue for you. You should check with your assembly house if going that route. I have been able to reflow boards twice in this case. Surface tension usually keeps parts them from falling off. 
• Remember that higher speed signals travel along the skin of the copper so surface area is your friend and reduces impedance and attenuation on the signal. (More info)
• Type-C cable only has 1 pair of differential pairs for USB 2.0 on the A side of the connector. B is unconnected. So I believe that means you should tie A and B together or maybe there is a mux IC for USB 2.0.

USB 3 Differential Pairs Example

It seems a lot to take in for a hobbyist but after awhile it starts to make sense. PCBs are getting cheaper so if it doesn't work out you can keep trying different designs until it works. 

Here is my settings in Eagle CAD for a 2 layer board from OSHPark pictured above.

Eagle CAD Differential Trace Settings

Eagle CAD Length Settings

There is a minimum error in length but I always try to get it 100% matched.


Links I found during my research:
http://www.digikey.com/en/articles/techzone/2016/feb/usb-3-1-usb-type-c
https://www.fairchildsemi.com/application-notes/AN/AN-6103.pdf (PDF)
http://www.cablewholesale.com/cgi-bin/articlelink.cgi?article=SALES_ART_2015-03-30&key=653bc4866500468368db5e966ba1ea767ed58693&link=/support/technical_articles/introducing_10_gigabit_usb_31.php
http://www.edn.com/design/test-and-measurement/4438870/USB-3-1-testing-part-2--Type-C-cable-assemblies
http://www.cypress.com/file/151566/download
http://www.xmultiple.com/xwebsite-forum-USB-TypeC.htm (Good one with cable wiring)
https://en.wikipedia.org/wiki/USB_Type-C
https://www.element14.com/community/servlet/JiveServlet/previewBody/36206-102-2-218482/Introduction%20to%20USB%203.0%20Protocol.pdf (PDF)
https://www.synopsys.com/Company/Publications/DWTB/Pages/dwtb-convert-usb-design-type-c-2015q1.aspx
http://electronics.stackexchange.com/questions/125011/how-does-usb-type-c-handle-reverse-polarity
http://kevinzhengwork.blogspot.de/2014/09/usb-type-c-configuration-channel-cc-pin.html
http://www.mouser.com/publicrelations_techarticle_3cs_of_usb_2016final/
http://www.usb.org/developers/docs/hs_usb_pdg_r1_0.pdf (PDF)
http://electronics.stackexchange.com/questions/41851/how-critical-is-the-layout-of-usb-data-lines-how-does-my-layout-look
http://www.ti.com/lit/an/spraar7e/spraar7e.pdf (PDF)
http://www.belden.com/blog/broadcastav/understanding-skin-effect-and-frequency.cfm (Skin Effect)
http://www.appfruits.com/2015/03/building-your-own-custom-teensy/ (Links to calc)
http://www.multek.se/engelska/engineering/pcb-structures-2/differential-microstrip-impedance-calculator-2 (Calculator)

Quest for a Logic Analzyer

Since I started this adventure in hardware I have wanted to get an logic analyzer. I have an older but good oscilloscope that only goes so far when it comes to digital logic signals. I could go for the Saleae, but if I am going to do that I would rather sprint for the higher end model which is an easy $400+. In the mean time I was on a quest to find a low cost option. Upon my travels of the interwebs I found a few options. There's Dangerous Prototype's bus pirate (which I have) or their openbench logic. There are also the microcontroller options using, say, a Teensy or STM32. Then when I came across the BeagleLogic, it seemed like it fit what I had in mind. And actually, if I remember correctly, I saw it during the Hackaday Prize 2015. Funny how you end up somewhere on the Internet you've been before but have long forgotten.

The BeagleLogic is a logic analyzer based on the Beaglebone created by Kumar Abhishek, a semi-finalist of the Hackaday Prize Best Product 2015. What makes the BeagleLogic special is it uses the BeagleBone PRUs which are basically 200Mhz microcontrollers attached to the ARM CPU with shared memory. This is one thing that sets the BeagleBone apart from other SBCs. I have always been interested in the PRUs but they are a bit complicated and I've yet to have the time to investigate. I wish Ti would make an easy way to use them like Arduino did for microcontrollers. For me it's more of the lack of time to learn them when I have so much going on with other projects.


Features:

• 100MSPS
• 14 Channels (13,14 require you to disable eMMC)
• 320MB Capture Buffer
• 5V tolerant inputs
• Web Interface
• Capture interfaces from the BeagleBone itself
• Opensource 

At the moment, you have to make your own BeagleLogic. There isn't a place to order it. In addition, you need your own Beaglebone. Hardware wise, all it provides is the ability to probe up to 5V. since the BeagleBone ADCs only accept 1.8V signals. The BeagleLogic is fairly simple to make with the help of OSHPark. With a bit of drag soldering it would be easy to hand solder as well. I opted to order a stencil from OSHStencils and use my re-flow oven just to make it look nice and professional.

OSHPark Shared Project: (Just click order now)
https://oshpark.com/shared_projects/PKPgfF7q

Bill of Materials:
https://docs.google.com/spreadsheets/d/12azxrOXTphC75ShBOmVUEJG1oJav0N1jhAYYi9JiIA4

Notes:

• You don't need the EEPROM parts anymore but the footprints are on the PCB if needed.
• The transistor BSS138 was out of stock on Digikey so I ordered samples from Fairchild. 
• I did have some issues with the cape affecting the power on boot process. It's okay during a reset though. So you can't attach it till after you power up. 

Software is where the magic happens. There is a pre-made image for the BeagleBone with everything loaded and configured to use the BeagleLogic. It's a recent image based on Debian instead of the older Armstrong builds. The nice thing is that it doesn't flash the eMMC so you can leave your existing setup alone and just pop in the SD card when you need your logic analyzer. Which is another reason that makes it a good option. I can still use the BeagleBone hardware for other projects and not keep it collecting dust in between uses.

BeagleLogic is setup to be used in two ways. One is the web based interface. Just power it up and fire up your web browser. You can use the USB NIC which will put the BeagleBone at 192.168.7.2:4000 or plug in the on-board Ethernet or even use WiFi with a USB dongle. Plenty of options for connecting to it.

There aren't many options in the web interface but it's a great start to be expanded. In my case I couldn't get the "Dump Raw Data" option to work, unless it saves to the BeagleBone and it's not downloaded via the browser which is what I was expecting. If you have a I2C bus that only talks a few times a second, it can be challenging to find the data just by scrolling. There is software triggering but you can't use it via the web interface. You can by means of the command line, which is the second way to capture your data.

The command line tools are provided by the Sigrok software suite. The output file can be exported to the desktop app, PulseView to do protocol decoding.

First you have to capture from the command line and specify how you want to trigger, which channels and the sample rate / sample limit.

Example:
debian@beaglebone:~$ sigrok-cli -d beaglelogic -c samplerate=5m -o outputfile.sr -C P8_45,P8_46 --samples=10000 -t P8_45=e,P8_45=e

Using WinSCP on Windows you can copy the output file to your desktop and open it with PulseView. The PulseView binary for various operating systems are available.

From this point, select the protocol using the last icon on the toolbar. Finally just click the protocol tab to configure it. (This took a bit to figure out.) Select the pins that map to clock and data in this case.

If you need to, look at timing use the cursors tool.

The BeagleLogic is a great inexpensive logic analyzer especially if you have a BeagleBone laying around collecting dust as I did. (It was supposed to eventually be for a robot project but now I want to use the new BeagleBone Blue.) The BeagleLogic has a lot of potential to be a full feature tool. One big thing that is missing is the ability to connect to it directly form the host without having to copy a file each time. I haven't tried running PulseView directly on the BeagleBone then using VNC to connect. Even as is, it's a useful tool and a good place to start if you have never used a logic analyzer. Be sure to visit Kumar's blog http://theembeddedkitchen.net/ There is a lot of good info - especially on PRUs. I had actually came across it researching some STM32 SDIO stuff earlier this year.

Due to the nature of OSHPark, I have two extra fully assembled. If anyone is interested in them please send me an email. william at blog domain.

Here are some other links with more info on BeagleLogic and Sigrok.
https://github.com/abhishek-kakkar/BeagleLogic/wiki/Using-BeagleLogic:-Post-processing
https://github.com/abhishek-kakkar/BeagleLogic
http://beta.beaglelogic.net/use-beaglelogic/
https://sigrok.org/wiki/Supported_hardware
https://hackaday.io/project/4395-beaglelogic
http://hackaday.com/2015/02/19/turn-your-beagleboneblack-in-to-a-14-channel-100msps-logic-analyzer/


Correction: The BeagleLogic doesn't need the ADC's but the BeagleBone GPIO's are only 3.3V

openHAB Last Sensor Update

A few of the sensor nodes are battery powered so it is important to know if they have stopped transmitting. My previous system (which is still feeding openHAB) tracks last seen time stamp. In openHAB you have to set an item and a rule to handle that. This is one of the items at the bottom of this post that is required to remove my reliance on DomotiGa.

All this requires is one item to store the time stamp and a rule to update it whenever the sensor item receives a change. The only catch in my case is if the new value is the same as the current, it seems it is not triggered as an update. I am not sure if it is DomotiGa not sending or openHAB not triggering. So during the night I don't get as many updates. It's fine for now because when I setup a JeeNode to MQTT bridge, I can have that trigger the time stamp regardless if there is a sensor value change.

Items

 
DateTime        office_lastupdate       "Last Update [%1$tm.%1$td.%1$tY %1$tr]" 
 

You can use this site to help you format the datetime to suit your needs.
http://docs.oracle.com/javase/6/docs/api/java/util/Formatter.html


Rule

rule "Last Update Office"
when
        Item office_lightlevel received update or
        Item office_temp received update or
        Item window_office received update
then
        office_lastupdate.postUpdate(new DateTimeType())
end
 

Sitemap

 
 Text item=office_lastupdate valuecolor=[office_lastupdate>300="red",>240="purple",>120="orange",>0="green",<0 data-blogger-escaped-code="" data-blogger-escaped-red="">

Using the value color option you can quickly at a glance look at the time since update based on the color. Just adjust the values in seconds.


Reference
https://community.openhab.org/t/show-date-time-of-last-sensor-update/2114/9

openHAB Proximity Update

Just a quick update to the proximity tracking. The original post was just using Bluetooth which tends to not be completely reliable. So we need a backup such as WiFi. OpenHAB has a binding that can check for network devices. Between this and the device scan script for BT, we are set.

Just need to add an item for each device you want to track on the network. This can be used to see if a laptop is on or even check to make sure a sensor or something it alive.

Install the NetworkHealth binding - sudo apt-get install openhab-addon-binding-networkhealth

There isn't much in openhab.cfg to figure. I just setup the cache period to 60. Just restart openHAB if you make a change and load it to the new binding.

Items

 
Switch  wifi_Will               "Will Wifi"            (gNetwork)      {nh="Note5"}
Switch  wifi_Jenn               "Jenn Wifi"            (gNetwork)      {nh="Jenn-iPhone"}
 

The devices in the items config can be an IP address or host name. Using the hostname allows you to not have to set a static IP or reservation in DHCP. I already had reservations so these host names are set in the router. It looks like in iOS you can't change the host name but setting it in my router allowed me to control it. Android uses the device name you set in settings.

Sitemap

 
 Group item=gNetwork icon="present"
  

I put both devices in a group and just used that to add it to the sitemap. Then you can easily add more devices to track.

Then just update the occupied rule to take the other items into account.

Rule:

 
rule "Update Presence to home"
when
        Item wifi_Will changed from OFF to ON or
        Item wifi_Jenn changed from OFF to ON or
        Item device_WillPhone changed from OFF to ON or
        Item device_WillPhone changed from OFF to ON
then
        occupiedState.postUpdate(ON)
end


rule "Update Presence to away"
when
        Item wifi_Will changed from ON to OFF or
        Item wifi_Jenn changed from ON to OFF or
        Item device_WillPhone changed from ON to OFF or
        Item device_WillPhone changed from ON to OFF
then
        if(wifi_Will.state==OFF && wifi_Jenn.state==OFF && device_WillPhone.state==OFF && device_JennPhone.state==OFF){
                occupiedState.postUpdate(OFF)
        }
end

 

There is a bug in the rule though, the occuipedState isn't quite working. Everyone leaves and it's still on. So I will need to troubleshoot that a bit more. (Hmm... I noticed I am using postUpdate vs sendCommand...)

References:
https://github.com/openhab/openhab/wiki/Network-Health-Binding
https://github.com/openhab/openhab/wiki/Samples-Tricks#check-presence-by-detecting-wifi-phonestablets

openHAB and Fireplace Rules Part 5

Now that everything is humming along we can make some fancy rules. This includes creating a flexible timer and auto mode based on room temperature. I went through a lot of iterations but ended up with some nice rules that work well. I will post the current version here but any updates will be maintained on Github.

openHAB the Fireplace and Rules Part 4

If you haven't read part 1, part 2, and part 3. Start there and I will wait for you here. Welcome back! Now we get to do all of the fun stuff now that we have software control of the fireplace. We can have some real fun adding features. The original remote does have a set point and scheduling options but we never used that and of course you couldn't trigger remotely or based on other triggers. The features I had in mind are listed below.

• On/Off
• Keep original remote functionality
• Timer
• Temperature set point
• Remote turn on/auto when temp is under a certain value and we are coming home
• This would be instead of setting up scheduling

Part of this comes from that fact that the fireplace heats better than the wall heater we have at least for that part of the apartment, which we spend a lot of time in. The hardest part was getting openHAB control vs the physical remote to play nicely together. Finally the solution was to abstract the openHAB web input versus the remote. This uses four switch items.

 
Switch  tempFire_Switch "Fireplace Manual"        (gHeating)      {zwave="4:command=SWITCH_BINARY"}
Switch  tempFire_Web    "Fireplace"       (gHeating,gLeave)
Number  tempFire_ADC    "Fireplace ADC [%d]"      (gHeating)      {zwave="4:command=SENSOR_MULTILEVEL"}
Switch  tempFire_Remote "Fireplace Remote [%s]"   (gHeating)
 

The first one, tempFire_Switch is the one that controls the relay and therefore the fireplace directly. This one will not be in the sitemap and only controlled via rules. The tempFire_Web is the input from a user using openHAB and tempFire_Remote is the physical remote. The tempFire_ADC number item is the input from the ADC relay that lets us update the remote status without interfering with the actual fireplace.

openHAB the Fireplace and Wiring Part 3

Now that the relay works we can do the final wiring. Read part 1 and part 2 to see how we got here. It's been a rabbit hole for sure, but don't fret, we are on our way out!  Compared to everything else, the wiring is the easiest part. The fireplace uses a simple switch to control it as it is a millivolt system which generates its own power (from the heat of the pilot) to trigger the gas valve. Ripe for hacking. In the end for safety (and for long term vacancies), I decided to wire the local override switch as a hard disable. That way if we are gone for the weekend or during the Summer months, I can disable it. Just in case there is a network glitch or something the fireplace can't turn on even if the relay does. Turns out this is also useful during testing of the rules so the fireplace isn't turning on and off consistently.

Basically the connections are one side of the fireplace switch connection goes parallel with the side switch then to the relay negative. Then the positive of the relay is direct to the fireplace. Then the original receiver is wired to the relay ADC input.


Simple. I used some electrical tape just so I can easily remove it, this being an apartment and all. Now we can close oFf the fireplace and play with openHAB.

openHAB and our Fireplace Part 2 and OpenZWave

Finally, the MimoLite replay has arrived. Even though it was Amazon Prime, it look about five days to land in my eager hands. At least it was free shipping! In Part 1 we looked at a solution to control the fireplace via our openHAB network. Now the fun part of actually installing it. I set aside an evening after work for the installation. Of course when projects seem simple, they end up taking a lot longer.

MimoLite Relay

openHAB and Our Fireplace Part 1

When moving into our place nearly six years ago, my hacker eye noticed the gas fireplace and my attention was drawn to the fact that it has a remote that has manual/auto and scheduling. It's the first place I've lived in with a gas fireplace, so my first thought was the RF signal was prime for hacking. I never got around to trying anything and it is probably more difficult than the outdoor temperature sensor I did earlier this year. Recently, with the adventures in openHAB and with all of my Z-Wave research it dawned on me: I probably can just bypass the remote and interface directly. One simple test would answer my question. I took a jumper and followed the receivers two wires to the gas controller. Sure enough jumping them turns it on. The local manual switch and the remote receiver are in parallel. My question was then, where is the power coming from to detect the closed circuit? I measured about 500mV. I didn't know much about fireplaces/heaters before I started this adventure. A little research later...

OpenHAB and Proximity

A big part of being able to automate with rules is the ability to know who is home. Proximity is one of the items that needs to be transferred from DomotiGA to openHAB. There are two main ways of doing this. OpenHAB supports a Bluetooth binding which requires a bit of working to get setup. Not wanting to mess with that, I decided to just adapt my original shell script to openHAB as well as incorporating some changes from https://code.google.com/p/openhab-samples/wiki/Tricks#Use_cheap_bluetooth_dongles_on_remote_PCs_to_detect_your_phone/w. This example page also has some good rules on using not only phones but laptops and such on the network to track who is home.  You can have all kinds of fun with that!