// This is the script to give summary on the main page.
Think IPM

Tuesday, June 20, 2017

PSA: Check out your smoke detectors (once every 10 years)

I have owned my house for just about a year now and I have been automating and ‘smartening’ it up like crazy.  My home automation platform of choice is Home Assistant.  If you haven’t checked it out, it’s an Open source platform that runs on a raspberry pi and becomes the glue or in VMware terms, the abstract layer between all the various hardware.   Yes.  I have a software defined house.

So last month, I got to thinking about my smoke detectors.  I have quite a few of them in the house and honestly didn’t know much about them.  I knew 2 of them were connected to my alarm system and the rest were hardwired into power.  There was also an interconnect wire between them all so that if one goes off, they all go off.  I learned this when one of them went into a low battery state and triggered them all to go off. at night. on a week day.

In addition to the ‘dumb’ status they held, I also learned after some googling that ALL smoke and carbon monoxide detectors go bad after 10 years.  They have a chemical pad in them that ‘smells’ the smoke or CO and then triggers the alert.  This chemical has a 10 year effective lifespan.  My current detectors were 14 years old (they have a manufacturer date stamped on them) and basically didn’t do ANYTHING except eat batteries and then chirp for more.  The house could be on fire and they wouldn’t respond unless a battery happened to fall out of them.

Image result for nest protect

Of course, they needed to be replaced and I went with the Nest Protects.  They are not the cheapest guys on the block but I think they are the smartest and were the easiest to integrate into my existing smart home.  By code, I needed 9 of them for the house.  1 in each room, 1 in all bedroom hallways and 1 in the kitchen.  The ones I purchased are hardwired into power and use a wireless interconnect to spread the word of danger.  You can read up on all the cool nest features elsewhere so I wanted to just share the couple of small additions I made to my set up.

Home Assistant already had a Nest component so once I set them up on the network and added them to my Nest account, all the various protect sensors just showed up in the interface.   My Nest package can be found in my Github repo here.

Out of the box, if the Nest Protects sense an emergency condition, they will of course alert you but additionally, they will

  • turn off your HVAC (assuming controlled by a Nest Thermostat)
  • turn on your sprinkler system (if controlled by a Rachio system)

Thanks to Home Assistant, mine will also trigger my emergency script.  The script sequence will

  • switch all outside lights to red to indicate an emergency
  • flash all lights in the house 4 times to grab everyone’s attention (although the piercing siren from the detectors should do that as well)
  • turn on all interior lights to 100% brightness in the house.
  • switch my front LED strips to a white flashing strobe
  • open both garage doors if we are home. (via Garadget) [Not implemented yet]

It’s been about a month with the Protects and no false alarms so I’m pretty happy with that.  The guide light feature is a welcome bonus as well.

Click Here to Continue Reading >>

Friday, June 16, 2017

Building my Home alarm system (Hardware Phase)

Image result for burglar 

I have a house.  It has prewired windows and doors that I want to use for my own purposes.  I DON’T have an alarm company.  I refuse to pay some monthly fee for monitoring.  I just don’t feel as though I have gotten the value that I expected in the past from the security companies.  Basically I’ll just pay myself and become my own 24/7/365 monitoring solution. Winking smile


So after a ton of Googl-fu and trying to decide what type of system I should use to replace ADT with, I settled in on using the awesome ESP8266 chips in the NodeMCU form factor.   These tiny (and cheap) little devices could be wired up to all my existing wired doors and windows and then programmed to interface with my Home Assistant home automation platform.  They are about 10 bucks and have built in Wi-Fi and a good amount of support out there on the internet for DIY projects.  They really are awesome once you start working with them.

Here is the part list for my project : 

Let’s take a look at where I started :

imageIt was your standard alarm box.  All wires from the windows and doors fed back through to the walls to this 1980’s circuit board.   They were all simple reed switches (red and black) with magnets at the windows and doors.  When the window/door is closed, a magnet keeps the reed switch closed and the circuit is complete.  When the window/door opened, the magnet is moved away, switch is opened and the circuit is broken.  Easy for 1980’s tech to understand, easy for me to understand and easy for me to get the ESPs to understand.

First thing first, rip out all the wires from the motherboard(carefully). Smile 

Hopefully they are all labeled.  Mine were not so I basically just peeled them off in pairs and used a multimeter to test them.  Set it to tone and then walk around opening and closing windows until the tone goes away. (side note: I found 6 windows that had broken reed switches that were permanently closed through a process of elimination).  Once you identify all of your windows and doors, LABEL them!

ScreenClipAfter I had most of the physical wires labeled, I started with the NodeMCUs.  There are a ton of great resources around to explain how to program the NodeMCUs so I’ll let you find your own way through that but will give you the high level points :

I had 22 windows/doors but bundled a few together for a total of 17 zones.  I purchased 3 NodeMCUs from amazon and figured I would could do 7 zones on each one of them.

I used ESPEASY software to flash and configure the NodeMCUs.  You can see what GPIO pins I used in the diagram to the right.  Green were good, but the red Xs gave me issues.  This may have to do with my novice understanding of the whole ESP8266 architecture and microelectronics in general.

I used MQTT to talk back to my Home Assistant.  If you don’t know about MQTT, it is a machine to machine messaging protocol.  Super lightweight and perfect for these types of communications.

The way ESPEASY works in my set up is that every time a reed sensor is tripped (circuit broken), it will update MQTT.  Home Assistant is configured to watch those MQTT topics and act accordingly when it detects a change. (window opening or closing).  Based on that information, HA will do things.

ESPEASY uses a very nice web interface to do all of the configuration.  It was pretty easy to use once the flashing was completed.



Once the NodeMCUs were flashed and configured, I started wiring them up. 

image image

image image

Since I don’t like soldering (I’m not good at it), I decided to go with breadboards and wire jumper connections.  It made it super easy to connect everything in.  Plus if one of my ESPs goes bad, I can just pop it out and replace with a new one.  The wiring was pretty easy.   All the grounds (black) would be bundled together and then put to a GND on the NodeMCU, and each of the reds would go to a GPIO pin on the boards.

With everything wired up and tested, I removed the old motherboard and carefully put everything back into my alarm case.




The end result in Home Assistant was this:


It’s not the prettiest interface (I’m working on fixing that anyway) but it is WAAY more flexible than anything else I could have gotten.  I have 17 zones that I can now use for input for various things in my Smart Home.

The Home Assistant code for all of this is located here :

One of the first automations I put in place was to turn off the HVAC systems if any of the openings were open for more than 5 minutes.  Then make a short announcement and wait to turn the HVAC back on when the window/door was closed.   I love it!

  - alias: 'Turn off HVAC in window/door is opened'
      - platform: state
          - binary_sensor.MCU1_GPIO4
          - binary_sensor.MCU1_GPIO5
          - binary_sensor.MCU1_GPIO10
          - binary_sensor.MCU1_GPIO12
          - binary_sensor.MCU1_GPIO13
          - binary_sensor.MCU1_GPIO14
          - binary_sensor.MCU2_GPIO4
          - binary_sensor.MCU2_GPIO5
          - binary_sensor.MCU2_GPIO9
          - binary_sensor.MCU2_GPIO10
          - binary_sensor.MCU2_GPIO12
          - binary_sensor.MCU2_GPIO13
          - binary_sensor.MCU2_GPIO14
          - binary_sensor.MCU3_GPIO4
          - binary_sensor.MCU3_GPIO5
          - binary_sensor.MCU3_GPIO10
          - binary_sensor.MCU3_GPIO14
        state: 'on'
        from: 'off'
          minutes: 5
      - service: climate.set_operation_mode
          entity_id: climate.downstairs
          operation_mode: 'off'
      - service: script.speech_engine
          value1: "The {{ trigger.to_state.attributes.friendly_name }} has been opened for about 5 minutes.  I will shut down the Air Conditioner so you can enjoy the fresh air."
          call_outside_weather: 1
          call_inside_weather: 1


The home assistant code is all based on YAML and is pretty easy to learn and write for.  At some point in the future, I’ll have to do a quick write up on the main Home Assistant system running on my raspberry Pi.

So that’s about it; I ripped out my old alarm system, replaced it with 3 ESP8266 NodeMCU chips, stuffed it back into the old case, integrated it with Home Assistant and then started writing automations using my new sensors.

I built all of this a while ago and I have been running with it without issue.  In fact, it works incredibly well. 

Since then, I have also added in a light sensor to know if someone opens the panel case.



There is a ton of potential with this system and I plan to keep building it out but for now, this should get you started.  I feel like this post might have been all over the place so if there are any BIG items I may have missed or glossed over, feel free to hit me up on twitter.

Click Here to Continue Reading >>

Tuesday, June 13, 2017

Those are some BIG log files you have there buddy!

Sometimes a well run, stable production environment that runs and runs and runs is hiding some hidden dangers from you.  My client was recently doing some housekeeping on their shared storage and came across some larger than normal Virtual Machine log files.


By default, these log files normally will get rotated out when a VM is powered off/on or vMotion’d.  For machines that do neither and just run happily in production, you could have instances where the log files could grow much more than you expect.  By default, VMware will keep 6 rotations of log files but each log file is enabled for unlimited growth (or until the LUN is consumed!).   For machines that have lots of login/logoff activities (think Terminal services / Citrix machines), you might want to consider reviewing the current logging options.


As a refresher, here is the KB article to brush up on your logging options.  Image result for lumberjack


You can safely delete the older vmware-x.log files without issue but sometimes will run into issues deleting the current active log file.  The VM will need to be powered off or vMotion’d to access that log file.   It’s also worth mentioning that you should take a moment or two to investigate the contents to make sure the log spew is normal and you aren’t missing something that should/could be addressed.

For machines that are generating large log files with benign messaging, you might want to consider turning off logging for those VMs.

To turn logging to off, enter logging=false in the virtual machines .vmx file

Happy Logging!


Click Here to Continue Reading >>

Thursday, June 8, 2017

Home Protection from Power outages (Sort of) with the BGE70.

So June is the official start of Hurricane season down here in Florida.   This is basically when it rains every day like clockwork from 4pm to 5:30.  Unfortunately with the rain usually comes heavy lightning and more recently (in my new neighborhood), power outages.  They last just a few seconds but due to my heavy investment in IOT and home automation, create absolute havoc for my house.  Basically when there was a power blip in the house, all the smart lights would immediately turn on to full brightness when the power was restored and all devices would start rebooting.  Since the Cable Modem takes the longest to reboot, most of the hubs would be back up before it and complain about not having internet access and end up in some weird state where they would need one more reboot.  My quick solution for the time being is a $35 buck UPS (APC Back-UPS Connect UPS Battery Backup).  Pretty standard stuff I guess but I found this niche one that is specifically created for home networking gear.  It doesn’t support three prong devices and is created to specifically protect your cable modem and other internet infrastructure that typically has two prongs.  Apparently this allows a smaller battery and much longer runtimes off it in contrast to it’s traditional three prong siblings.

Click the Picture for the link to the device.

For me and my situation, I decided to just connect the Cable Modem, a Network switch and my Home Assistant Raspberry Pi to it.   This will keep the internet connection alive in the house (assuming upstream cable company equipment isn’t affected) and my home automation software running.   Everything else (hubs, switches, lights, controllers) can reboot and come back on their own.  Since the Home Automation server is also protected, I should be able to write some logic on it to detect when these power events happen and adjust the house accordingly. 
(Middle of the night == Turn all the lights back off; Evening with us home == Turn off MOST of them)

Eventually I will get around to writing about my home automation software (powered by Home Assistant) but for now, if you want to know more about it, check out my Github repo and associated descriptions within it.

P.S. The other great thing about this UPS is it only beeps ONCE when the power goes off.  It doesn’t continually whine about being on battery power like other Battery Backup devices I have owned in the past.


- Carlo

Click Here to Continue Reading >>

Wednesday, June 7, 2017

Upgrading your Data Domain OS

Today I ran into a replication issue between 2 Data Domain that showed up as VERY slow transfer rates between sites.  After working with EMC support, it was advised that I should upgrade the OS versions of the boxes to

The process was time consuming but pretty straight forward.

1) Upgrade Destination DD first.

2) Make sure your boxes are no longer doing anything.  I disabled the replication pairs and paused any backup jobs or cleaning tasks.

3) Upload the new RPM to the box via the GUI.

4) Run the upgrade via the command line.

5) Repeat on Source DD server.



You can upload the RPM via the GUI but do the upgrade via Command line.


During the upgrade, the Box will reboot and the Putty connection will become unavailable for about 15 minutes.   Once your PING returns, you can log back into the DD Box via Putty and run
system upgrade status – Verify that the Box shows Completed.

Current Upgrade Status: DD OS upgrade In Progress
      Node 0: phase 4/4 (Finalize 100%)

Current Upgrade Status: DD OS upgrade Succeeded

uname  - Verify the Current OS has been upgraded.


- Easy Peasy.


Be sure to  remove the RPMs via the GUI after successfully updating the Data Domains to reclaim the space.  -Thanks for the tip Eric!

Click Here to Continue Reading >>