Sunday, December 20, 2015

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.




Monday, December 14, 2015

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.

Monday, December 7, 2015

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


Sunday, December 6, 2015

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...

Wednesday, November 25, 2015

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...


Thursday, November 19, 2015

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.




Saturday, November 14, 2015

Nextion - Human Machine Interface

Another crowd sourced campaign completed! This one, from Indiegogo is called Nextion HMI, Human Machine Interface. This display offloads the UI elements, processing, and design away from your microcontroller. Nextion has an editor that you design your UI with drag n' drop elements. Then your microcontroller just interacts with the display over serial to retrieve button press and other events. I believe this is similar to 4D systems but affordable. Sweet!
Nextion in action. Image from Indiegogo.

Here are some of the specs for the 2.4in. For details check Indiegogo or their site http://imall.itead.cc/display/nextion.html.

  • 320 x 240 Resolution
  • RGB 65K true to life colors
  • TFT Screen with integrated 4-wire Resistive Touch Panel 
  • Easy 4 pin interface to any TTL Serial Host
  • 4M Flash memory for User Application Code and Data 
  • On board micro-SD card for firmware upgrade 
  • Visual Area:36.72mm(L)×48.96mm(W) 
  • Adjustable Brightness:0~180 nit, the interval of adjustment is 1% 
  • 5V90mA power consumption
Indiegogo was for 2.4in and 4.3in. Now they are releasing 5.0in, 7.0in and 2.8in. Anything over 2.8in comes in a higher resolution which is nice.

Sunday, November 8, 2015

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.



Saturday, October 24, 2015

Home Automation: Egg Minder

As I was looking for some Z-Wave stuff on Amazon, I saw an awesome deal on the Quirky Egg Minder. It was selling at a reduced price for only fifteen bucks - so total impulse buy! Also, my reasoning to buy just about any gadget is for future blogging. Makes sense, right? I ordered via Amazon Prime on a Friday and received on Sunday. Pretty, sweet! Upon opening the box, I was pleasantly surprised by the nice modern packaging. The Egg Minder is a WiFi cloud enabled device to manage your eggs. You know, the of farm-fresh variety. No more are the days of counting your eggs. Not only does it keep count, but it keeps track of freshness by indicating which eggs are the oldest to use first. This is indicated by a blue LED.



Wednesday, September 30, 2015

Blast from the Past: Tandy 1000TL/2

A little over two years ago I was finishing building the XTIDE Adapter with the Dangerous Prototypes free PCB. Using their Bus Pirate I was able to flash the CPULD, but you need a computer to flash the BIOS. Upon pulling my Tandy 1000TL/2 (my first computer were I learned the basis of everything I do today) out of the closet, I realized after trying a standard keyboard that it requires an XT keyboard. Drat! When my wife and I moved first moved to Monterey, I had gotten rid of a bunch of stuff. I couldn't remember if the Tandy keyboard was one of them. I know I got rid of the monitor(s) and dot matrix printer. Either way, I still haven't found it.

Once in a while I would think about this project and looked up ways to create an adapter from AT to XT. It's cheaper and it takes up less space then getting a $$$ XT clicky keyboard on eBay. More recently I had found some decently priced ones on eBay but never pulled the trigger. 

Then after our trip to the Portland Mini Maker Faire and staying/talking to my best friend, it sparked my motivation to finish this project. We had visited a computer recycling place in search of a keyboard. They thought they had one, but not all 5pin din keyboards from yesteryear are XT. So looking on eBay can be tough as well. The best bet are ones that obviously have a switch.




Sunday, August 9, 2015

VA Tester and our Giant Star

Once upon a time on a bright and sunny afternoon, I decided to interact with some photons from that big burst of energy we revolve around. I had ordered a 6V 3.5W solar panel from Amazon awhile back but I never got around to trying it. I also had an Adafruit Solar LiPo Charger that I hadn't used.  Part of this is research of using solar with home automation nodes that are near a window. Currently, I use AA batteries but I see them as wasteful since eventually you have to replace them. Of course you can get rechargeable AA batteries but they usually put out a tad less voltage, 1.2V vs 1.5V and still uses energy from an outlet to recharge. (Hmm...you could recharge them from solar?) This setup using off the shelf parts is a bit more pricey but in theory could last indefinitely on the same set of batteries. The Adafruit charger is where the magic happens. It takes care of load sharing with a 1S LiPo battery when there isn't enough Sun and it will charge when there is enough Sun. Ideally in the end, I would design a node that incorporates this circuit but it's really only needed for window nodes.  I could create two types of nodes - one for solar and one without, or an easy add-on board to solar enable a node, hmm...




Tuesday, July 21, 2015

The Proto Buildbar

This summer, we had the pleasure of attending a beautiful wedding near Dayton, Ohio. Since many of MobileWill's family members were also there, we decided to prolong our visit to about a week. One of the things we always like to do before visiting an area is to look up local eateries, coffee shops, museums, and such. A few places stuck out (which is always a plus, especially in the mid-west!), specifically the National Museum of the United States Air Force and a couple of new dining experiences. Yes, we've been dreaming about biscuits from Bob Evans. But we must admit, besides those things and just spending time with family, there wasn't much else to do. That is, until MobileWill's cousin recommended perhaps one of the coolest places in all of Ohio...

The Proto Buildbar.




Sunday, July 5, 2015

Arduino Zero Has Arrived!

The long awaited Arduino Zero has arrived! This is the version from CC not SRL. Looks like some retailers such as Adafruit has/had the SRL version already. Wonder if they will switch, perhaps since they began manufacturing for Arduino in the U.S.? Shipping via USPS with regular mail was painstakingly slow, especially since they are rolling out phase two of their plan. It arrived five days later than scheduled, but alas, that is my error for not choosing USPS priority mail. I could go on and on about their delivery times and dealings, but it would mean writing another post about it. 

Anyway, now that rant is out of the way, I can rant about the poor packaging. This is my first order directly from the Arduino U.S. store, so I had no prior expectations. What I received was a standard manilla padded envelope with the familiar Arduino box inside. Upon removing the small box, it had been noticeably smashed at least once. I immediately checked to see if the headers were damaged. Thankfully the Zero was fine. However, the lack of protected packaging could have easily made that a different story. The box they use isn't crushed-proof, I believe it is just their standard retail packaging. To top it off, the Zero inside has zero antistatic protection. None, whatsoever. I was in a bit of shock, especially since Arduino.cc is well known. It would cost them less than pennies to at least outfit the Zero with a antistatic bag. Actually, come to think of it, all of their products should be in antistatic bags, in my opinion. (If you've seen this from Dave Jones' EEVblog, then you know what I'm talking about!)

Not all is lost, though! Now down to the good stuff bout what was inside the small box: the Arduino Zero. It is the first Arduino with the Atmel Embedded Debugger (EDBG). Here is a video with a good overview of using the EDBG with the Zero. https://www.youtube.com/watch?v=Bjr6BBHXuDw.  This is like the Arduino Due in price and that it gives you a 32bit ARM microcontroller, however, not quite as large - it's much smaller like the UNO and it has the Atmel Embedded Debugger.

Arduino Zero and Packaging
Mine arrived as pictured. One thing to note is the JTAG headers for the Embedded Debugger/serial link is populated but the SWD interface for connecting another target board is not. If you need it you will need to get the smaller 1.27mm headers. Looks like there is an adapter kit on Amazon.

Differences vs other Arduino's

  • 32-bit core that allows operations on 4 byte wide data within a single CPU clock. (For more information see the int type page).
  • CPU Clock at 48MHz
  • 12 channels DMA controller that can relieve the CPU from doing memory intensive tasks
  • 32 bit Real Time Counter (RTC) with clock/calendar function.
  • 32 bit CRC generator
  • Two-channel Inter IC Sound (I2S) interface
  • Peripheral Touch Controller (PTC)

Summary

MicrocontrollerATSAMD21G18, 32-Bit ARM Cortex M0+
Operating Voltage3.3V
General purpose I/O Pins20, all of which can do digital I/O and all except for 2 and 7 can be used as PWM output
UART 1
Analog Input Pins6, 12-bit ADC channels
Analog Output Pins1, 10-bit DAC
External InterruptsAvailable on all pins except pin 4
DC Current per I/O Pin7 mA
Flash Memory256 KB
SRAM32 KB
EEPROMNone (part of the Flash memory may be used as a non-volatile storage with some limitations*)
Clock Speed48 MHz

*Copied from http://www.arduino.cc/en/Main/ArduinoBoardZero


These are some very nice features that I am looking forward to trying out. Before we get to playing, we have too see how much power this thing uses. The Arduino UNO can be setup to consume very little power. Let us find out what the extra processing power will cost us...

Tuesday, June 23, 2015

STM32 Nucleo and DFU USB Bootloading

Over the last few months I have been playing with the Nucleo development boards from STMicroelectronics. If you're unfamiliar with them, they are fast, mbed and Arduino (headers) compatible. This makes it easy like an Arduino to program and use. What sets them apart is that they are 32bit and have, depending on the model, tons of memory and flash. The Nucleo boards maintain the Arduino footprint but also have headers for the extra pins which gives this board plenty of GPIO for your projects.  In turn, you end up with multiple buses such as SPI, I2C, and UARTs for your consumption. They are priced very well and come in different flavors based on your needs. Each flavor is based on different ARM Cortex architectures such as M0, M3, and M4. One of the best features is real debugging via ST-Link/V2-1. The unfortunate thing due to the nature of mbed, you can only use the debugging features using a full desktop IDE such as Keil or some of the other free alternatives. But mbed allows you to export your code from the online IDE to the project format for those IDE's. So there's that.

Most of my projects spend very little time on the development board. Once they are working, I usually want to design a PCB for it. Therefore I prefer to use microcontrollers that support native USB programming, such as the popular ATMega32U4. With some AVR chips you can use the Arduino bootloader but most chips come with a DFU bootloader that can support flashing over serial and USB. In the case of STM32, it additionally supports CAN, I2C, and SPI bootloading. For some reason the Nucleo boards don't have the native USB connector onboard, but the needed pins are available for easy access. (The discovery boards do.)

Connecting USB Pins

To access these pins you can use a USB breakout or a USB Tester. Of course you could always cut open a USB cable, but seriously, why create a mess? If you have one of my USB, Testers it makes it much easier, plus all of the other features it provides. BUY ONE NOW!! Just kidding! The pins for D+ and D- are not labeled on the pin out of the Nucleo board out but if you look up the datasheet you can find them and match the pin names with the Nucleo pin out as shown below.

So far I have tested the L152 and F411 and both have been PA12, PA11 (D+, D-). Which is pin 6,7 from the top on the right most column of male headers.

STM32 Nucleo USB DFU Connections

Saturday, May 23, 2015

Maker Faire, Bay Area 2015

This year the Bay Area Maker Faire celebrated ten years. William and I could not believe it! We've attended BAMF (as we cheekily call it), for the past eight years. Wow! It feels like only yesterday that we were frantically searching for parking, trying to stand in line before the gates opened. Oh wait, that happens each year. Ha!



This year was just as eye opening as ever. It has grown in popularity for sure, but more so it has also grown into a lot more than just garage hacking. From the new 3D Printer tent, to the Start-up area, the BAMF has become a fair that now encompasses so much more and will surely continue to morph. We feel like we've grown along with it. After-all, some of William's first blog posts were about the Arduino Projects Pack from MAKE.




We've certainly come a long way since the early days of the Maker Faire. For us, BAMF has become more than just the faire itself. It's a real treat to meet-up with some folks from around the globe that we now consider friends. Over the past couple of years, there have been some post Maker Faire shindigs like the BAMF meet-n-drink hosted by the Hackaday crew and the BringAHack dinner hosted by Laen from OSHpark. Honestly, it's really these outings that we look forward to attending. A chance to mingle without the distraction of a crowd or the barrier of a booth? We could do that all night!

I tried to capture some images from those evenings this year, but bare with me as it was dark and you know, after a long day with one or two beers, hiccups are bound to happen. :)







Sunday, May 3, 2015

Jamrific

Over the last few weekends and then some, I have been playing with the Colorific RGB Bulb from Amazon. Inspired by this learn guide https://learn.adafruit.com/reverse-engineering-a-bluetooth-low-energy-light-bulb/explore-gatt I decided to make it reactive to audio. Finally! An excuse to buy the Teensy Audio shield!

Here are a few pictures and a short demo of it in action. You can find the code and my notes on the issues with it and where the project is at currently on:https://github.com/FriedCircuits/Jamrific

Teensy 3.1 with Audio Shield, TFT connect to RPi

Raspberry Pi 2 with BT 4.0 and UART connected to Teensy 3.1.

Colorific Bulb in action


Monday, April 13, 2015

Review: Hummingboard

I came across the Hummingboard while reading Engadget. This isn’t your run-of-the-mill Linux board, it’s jam-packed with features that other boards don’t have. The main feature that sets this board apart from the others is that the SOC is socketed and swappable. What a great idea! Need more power for your project or different board features? Just swap out the SOC module or board and now you can have an expanded set of features all while using the same platform.

Does this new board look strangely familiar for some reason?
This board shares the same footprint and IO layout as the Raspberry PI.


Sunday, February 22, 2015

Raspberry Pi 2 and Motorola Lapdock

Back in October of 2012, I had tested the Motorola Lapdock with the original 256MB Raspberry Pi. Recently I was able to get my hands on a Raspberry Pi 2 and decided to see if it worked any better. It pretty much works the same in that if the Lapdock doesn't detect it, it goes to sleep and it won't try again until it turns itself off. So the only way to get past the point in boot where the display signal is lost for a second, is to power the Pi up from another power source with the HDMI connected. You must wait for it to fully boot. Then disconnect the HDMI, wait for the Lapdock to turn off, and then plug it all back in and power it up. It's quite the sequence just to get it to work.

This time around I had a hard time with audio. Last time it was a struggle too, but at least it worked. I didn't spend a lot of time on it, but only the way I could get it to work was by loading the Python games app and selecting force headphones. Then you can use the web or anything else but this is using headphones instead of the built in audio. A lot has changed in software since the 256MB version so this needs more investigating.

Raspberry Pi 2 and Motorola Lapdock
This is unfortunate since the Raspberry Pi 2 and all of its power would make a great travel companion with the Lapdock. What really needs to be done is a way to fake an HDMI signal at all times in any case it would work much smoother. Maybe if the Lapdock can be hacked to always stay awake or a longer detection timeout. At this point it will be at the bottom of the project list.

Friday, February 13, 2015

HA: Living Room Node

Just wanted to do a quick post about the node running in the living room. It's similar to the other nodes except I am using a Tiny328 and a DHT11 temp/humidity sensor. Currently, this is the only node with humidity. It's presently being powered from a 5V USB wall adapter using a USB Tester to break out the power - same one that is running the La Crosse gateway!



Here is the github link that I am using for all nodes. I have adapted it to support each sensor that a node might have. It's based on the roomNode by JeeLabs. This sketch assumes the node has been configured already with the JeeLabs rf12demo sketch.

Owncloud

Last year I decided to give freeNAS another try despite the warnings of not having ECC memory and running in a VM. Long story short, it ran great for awhile. I had freeBSD jails setup for CrashPlan and Owncloud - it was heaven! It was all running smoothly until not having ECC memory caught up to me. I began to have checksum errors, so I had to dump the data. Much faster than restoring from backup.



Wednesday, February 4, 2015

HA: DomotiGa Web Interface

DomotiGa is an open source Linux app written in Gambas which I hadn't heard about until now. As part of any good home automation or any connected project is a way to control it remotely and easily, otherwise it's easier just to hit the light switch yourself, right? I am using a Ubuntu Virtual Machine running in VMWare ESXi. VMWare offers ESXi as a free version of there enterprise bare metal hypervisor. ESXi can run on most hardware but if you have trouble there are plenty of guides out there to get drivers working.

One of the easiest ways to get a remote interface is a website. It is much easier, universal and platform independent compared to using an app. There are two types of web interfaces available in DomotiGa. I tested both out to pick the best one for my application and decided that since each one serves a different purpose I would leave both active.



Simple Web Client

DomotiGa Simple Web Client

DomotiYii


From the above screenshots I am sure you can tell the difference between the two. The simple web client is well, simple, and it is great for quickly checking sensor data or controlling switches. But for advanced management, DomotiYii fits the bill. I keep the simple web client running in a browser window on my left monitor. It can auto refresh and the changes turn green momentarily.

This would be a good interface to easily setup a Raspberry Pi with a display on the wall as a status display. DomotiGa has a JSON RPC interface so it wouldn't be hard to grab the data and pipe it into your own front end. There is another system that makes easy to design a UI and interface it with DomotiGa, one is CF iViewer https://www.domotiga.nl/projects/domotiga/wiki/CF_iViewer

Monday, February 2, 2015

Kickstarter: ArduRF

Today I received a few packages but one of them contained the ArduRF from Kickstarter. This campaign was short and sweet. I received the reward thirty-three days after it ended. You can read about the details from their Kickstarter but it's an Atmega328p (Arduino Uno) with the RFM69 embedded. One has a USB A connector that can plug directly into your PC. This can act like a base station/receiver. This will replace my node connected to an FTDI cable to my Ubuntu VM. Using the JeeNode library in compatibility mode, the RFM69 should work with the RFM12B radios until I completely transition over. The other is similar to an Arduino Pro Mini but longer with the addition of a JST LiPo battery connector with the charging circuit and a mini USB for programming. These are great boards to add to your network or to get you started with low power RF. Plus they are very well priced. I look forward to diving in and posting more about these.

Check them out! You can find them on their site http://www.ezsbc.com/ or https://www.tindie.com/stores/ddebeer Happy tinkering!






Tuesday, January 20, 2015

La Crosse Weather Station Gateway

Its alive! Last Christmas (or was it the one before that?), I received a La Crosse wireless weather station from my mom who is obsessed with them. This one has just a small display that can gauge inside and outside temperature. What interested me is that it's a simple 433Mhz radio link. So sometime between then and a while ago, I got a 433Mhz receiver from Sparkfun with the intention of capturing the binary data from the outside sensor.

Stock photo from SFE - CC BY-NC-SA 3.0


Finally Some Home Automation

With all the busyness of FriedCircuits and with taking a late honeymoon to Europe, there hasn't been very much time left for other just-for-fun projects. It's taken a long time to scale up productivity after our trip. A few weeks ago I finally started to dive into getting some sort of a start on home automation, or domotica, as its called across the pond. Since the failure of the Smart Outelet I decided to start on a smaller piece of the home automation beast this time around. Having been following JeeNodes for awhile now, I wanted to make a custom version in which I actually had done last year and never posted about it. I did some testing with his setup and the HouseMon server running on a Rasberry Pi. I have been toying with the idea of writing my own from scratch but I don't have the time and why reinvent the wheel, right? On my daily travels of the web (Feedly) I have come across a lot of home automation projects, but one piece of software struck my interest and this is what got me back to exploring this space.



Thursday, January 8, 2015

Wizkers.io Is Live!

Happy New Year! Begin 2015 with Wizkers.io - an easy to use Open Source application that is great for makers and programmers alike. It was designed and is managed by Edouard Lafargue, a fellow maker who has greatly contributed to the USB Tester, which is supported by Wizkers.io. Now that's Open Source in action!

//We look forward to posting projects using Wizkers.io and the USB Tester!



Here is his press release:

"We are live! 
After about two years of work, I am very happy to announce the launch of Wizkers.io.
What is Wizkers? Wizkers is an Open Source application that gives a web interface to your instruments. And much more. 
What's in it for you ? Your measurement instruments often have great IO capabilities that are underutilized. Wizkers unlocks those. You are building a great project that generates a lot data, but you don't want to get locked into one particular Internet of Things provider, and don't want to spend inordinate amounts of time building a great user interface for it. Wizkers solves this. 
With Wizkers, you can visualize, log, download, and send instrument data to cloud services, all using one consistent interface. And if your instrument supports it, you can do full remote control too! 
Imagine your USB-connected power meter being able to do full-screen data graphs, data logging, and even real time uploads to IoT services. This is exactly what Wizkers lets you do. 
Wizkers is a pure HTML5/Javascript application which runs in Google Chrome, and is incredibly easy to setup: you can head over to the Chrome webstore (goo.gl/DgLqXH) and get up and running in a matter of seconds. 
Wizkers is not limited to running as a Chrome app. You can also install it on any embedded device - Beaglebone or other - to create a web interface for your measurement instruments, or even for your own DIY projects. And thanks to the Apache Cordova project, a native Android version is coming up too. 
Wizkers is still beta software. Expect a few bugs, but I feel that I have now reach a level of stability that makes it possible for a larger audience to start experimenting with it. Your feedback will be invaluable! 
So what instruments does Wizkers support out of the box today? At the time of release, we have support for the Medcom "Onyx" Geiger counter, the Fried Circuits USB current/voltage/power meter, Fluke 287/289 digital multimeters, and the Elecraft KX3 Amateur radio transceiver. And more instruments are on the way. 
Wizkers also supports IoT data services like helium.co for data input. 
Last, all the data recorded by Wizkers can be forwarded on to cloud services - talking to "dweet.io" is a no brainer - with a generic REST API output plugin, and more specialized services like Safecast.org. 
Wizkers is already being used daily by a team of beta testers whom I really want to thank for all their support, encouragement and great feedback! 
With this, I encourage you to head over to wizkers.io and discover what it can do for you!"