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

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

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

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

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!

OpenHAB and Zigbee Philips Hue

Now that openHAB and Z-Wave are working, it's time to get Zigbee setup so I can use the cheaper light bulbs. As of this post, the GE and Cree Zigbee bulbs are $15 at your local Home Depot or on Amazon in comparison to $30 for the Z-Wave ones. I have tested the Cree bulbs and they have a nice even glow compared to GE. The GE bulbs look cool since they have a clear dome but deathly to look at when on.

My co-worker originally bought the bulbs but realized replacing the wall switches was the way to go, so now I have them, ;).  Since I didn't go the Wink route, I had to figure out the best way to get Zigbee support. Zigbee seems a bit harder as I couldn't find a nice USB solution like Z-Wave. There are some USB solutions like the Ti Zigbee development board which is supported by openHAB2, which isn't ready for prime time.

After many hours researching I decided on the Philips Hue Hub. It's not the best solution as far as flexibility but it works with openHAB without root, using the native REST API and works locally without a cloud service. You can join it to the cloud if you want for remote access, but openHAB takes are of that for me and doesn't rely on someone else's server but my own. Plus it supports scenes and the new version of the hardware is Apple Homekit certified (if you are into that). It seems that the new hardware version just came out so it was a bit hard to find but of all places, Best Buy had it in stock. Most places sell it with a kit with a few RGB bulbs vs standalone.  I didn't want to spend that much and honestly, using the cheaper Cree bulbs is a great start. Eventually, I would like to try the color bulbs. Maybe Philips can send me some to review...

openHAB and Z-Wave

Now that openHAB is chugging along nicely, I would like to be able to start controlling devices using off the shelf parts. There seems to be two standards widely used Z-Wave and Zigbee. So far it appears light bulbs are mostly Zigbee and switches/thermostats/door locks are Z-Wave. You can get Z-Wave light bulbs but as of this post, they cost twice as much. Zigbee is what the Xbee is based on and it isn't as standardized across manufacturers like Z-Wave. To be as flexible as possible in the end, I want to have both radios available to openHAB.

One way to do this is via a rooted Wink Hub. My co-worker really likes the Wink Hub as it has worked out well for him, but he is solely using it and not integrating it. If I had gone with this solution, it would of cost me less but in the end it wouldn't have been as flexible - depending on their device database, require polling, and requiring another app and point of failure. Also unless you root it you are using their cloud service, plus its hard to root after its been updated. The nice thing is it has all the radios: Z-Wave, Zigbee, and Bluetooth. What would be cool is to root it and take control of everything directly (found openWink). Of course there are other controllers like SmartThings by Samsung that has an API and the ability to add unsupported devices. The last one I came across was the VeraLite. These are all more expensive than the Wink.

openHAB and Colorific

After my initial adventures in exploring openHAB, I wanted something I can control. The only thing around at the time was my Colorific RGB bulb I was playing around with in the Jamrific project. Even though openHAB doesn't support this bulb directly, I can still make it work since it is so flexible. One of the available bindings is the EXEC which can call a system command or shell script. Perfect!

Adventures in openHAB

When I was originally researching open source home automation servers, I had looked at openHAB but then dismissed it due to the iPhone looking interface and lack of admin UI. At that time I settled on DomotiGA, as you may have noticed in my previous blog posts. The problem with DomotiGA is the difficulty in adding custom devices without having to edit/compile the source code which is in Gamba3. For now I have just lived with it since it has a nice desktop UI to use and supports JeeNodes. Some other issues is the lack of an official built-in web interface and mobile apps, ease of remote access, plus, it's Linux only, which isn't that big of an issue but it can be limiting for some (to clarify, there are two web interface add-ons). Don't get me wrong DomotiGA is great, but better if you use mostly off the shelf devices.

Now onto openHAB! OpenHAB or Open Home Automation Bus, is a Java based framework to develop your own automation system. Being that it is Java, it will run anywhere Java does which is pretty much anywhere. I am using a Virtual Machine but you could run it on a Raspberry Pi. This time I decided to give it a real try since I have devices to play with now. The easiest and fastest way to get going is to use the MQTT data from DomotiGA and feed it to openHAB. This pulls the data from my sensor nodes around the house. At least this will get you a proof of concept and a chance to get familiar with openHAB.  Unlike DomotiGA, openHAB uses all configuration files. There is a version two in the works that provides a web interface but it is still in beta. I won't get too much into it here, since there are plenty of resources but here is the basic layout. You will see it is very flexible. It's great that I can bring together a mix of my own nodes/hardware along with off the shelf devices. If you are not into editing configuration files, you can download the Eclipse based OpenHAB Designer, which I haven't tried yet.