New SwitchMotes available

I’ve released some new SwitchMote kits after some requests by different users of SwitchMote. All SwitchMotes are wireless AC actuators, some designed to replace conventional light switches for the purpose of automating household light switching. Specifically there is a new dual 10A relay SwitchMote (and PSU):

There is a new assembly guide for this specific variant posted here. Here are some photos if it assembled and compared to the original SwitchMote:

Also there is a new single 30A relay SwitchMote PSU for heavy AC loads. The PCB for this particular one has double copper thickness to support the loads (2oz copper). Note that the relay has parallel posts at the top for heavy duty connectors as an option.

The demonstration of this PSU has already been posted in a video a few days ago:

The demo in the video uses the TxRxBlinky sketch. All of these are available at the Low Power Lab webStore. The SwitchMote guide page has been updated to include these new variants and the SwitchMote sketch was updated to support the new dual relay SwitchMote 2x10A.

GarageMote WeatherShield Upgrade

Now that WeatherShield is available to take high accuracy temperature, humidity and pressure measurements, it’s time to spread it around the property and watch the trends. I’ve already posted an example of upgrading my mailbox notifier project to include the WeatherShield. In this post I want to show my GarageMote upgrade to add a WeatherShield (WS), this was another quick evening project for today.

The garage is an interesting place to measure that data since it sits in between the house and the bitter winter cold or torrid hot summer. Would have been nice to have this data when I insulated my garage doors to see how effective that was.

The new GarageMote R2 includes an extra row of pins that are linked to the Moteino top header, which can be used for any general purpose, add more stuff to your GarageMote. This is perfect since WS‘s relevant pins are all on that same side. I had a prototype WS that I chose to stack on top of the Moteino, so male headers get soldered below, but you could also flip it over and have it be side by side the Moteino with headers on top. I shield the bottom of the WS with electrical tape, and soldered a pair of long pin headers with the longer side on the bottom of the WS.

This allows stacking of the WS on top of the Moteino using the female header that I soldered to the empty side header on GarageMote, the extra length headers are clipped off the top of the WS. I then install it back onto the door opener as before. GarageMote is permanently powered so it can afford to leave the transceiver in RX mode which is also necessary to listen for commands from a browser or mobile device (OPEN, CLOSE etc). That means it can also listen for wireless programming tokens, in fact the GarageMote sketch was always programmed that way so if a firmware change is needed it wouldn’t need to be disconnected, but instead reprogrammed wirelessly. The new revision of the GarageMote sketch is updated to include the WS code for periodic reading/reporting of the sensors data (which is excluded by default, and can be enabled by uncommenting the #define WEATHERSHIELD directive).

The resulting data arriving on the gateway looks like this:

F:4397 H:41 P:29.42

where F is fahrenheit degrees in hundreds (divide by 100), H is humidity in % and P is atmospheric pressure in inHg. The data is reported every 5 minutes, enough to get a pretty good resolution in a place that doesn’t expect large sudden fluctuations. Graphing and logging will be added later when I enhance the Gateway stack. For now this just serves as a quick demo and example of how WeatherShield can be used. Enjoy!

Mailbox Notifier Upgrade #3

As I explained in my lipoly+freezing=failure post, I ran into a snag with the brand new Lithium Polymer battery operated MotionMote that serves as my mailbox notifier. It discharges quickly after being exposed to the cold for a while, it seems like below 30F it goes downhill and then falls off the cliff and dies around 24F (-4C). After a recharge the cycle repeats, every time dying a little faster which means cold damages them permanently. So being tired of this nonsense I wanted to give alkalines a try and also wanted to add a WeatherShield to the mailbox, if it’s out there why not report temperature, humidity and pressure as well in addition to telling me when the mail is delivered.

UPDATE: the LiPoly batteries are still working great above freezing and will provide a compact and longer lasting charge than a 3xAAA pack. In the spring time I switch to a LiPoly because it lasts longer and I can charge it directly from the onboard USB of the MotionMote PCB. In the winter I go back to alkalines because they survive in the deep freeze.

The first step was to solder the weather shield on top of the Moteino, only 7 pins are soldered after being raised a little: GND, VIN, 3.3, A7, A5, A4, A3. The bottom of the WeatherShield was insulated with a piece of electrical tape to avoid any shorts.

Then I added the new battery – a 3xAAA holder with older batteries. I needed 3x of them to get above 4V so there’s some head room for the voltage regulator on the Moteino and the PIR sensor which was modified to allow running into much lower voltages. I could have soldered the battery holder wires directly to the MotionMote PCB but I had some spare female JST connectors and I added that to make it easy to remove later if needed. I took the measurements to lasercut another box that will fit this.
With the help of previous box designs I was able to get the dimensions and hole alignments right the first try. The box blueprint is published here for those that might find it useful. Here’s everything after test fitting:

Velcro goes on the back and the Moteino antenna protrudes from a hole in the box through a short cut in the velcro. The wire antenna also goes out the mailbox through a tiny hole. The slots in the side allow air to go in for better humidity readings.
After some minimal coding, the mailbox notifier sketch is altered to do the WeatherShield readings. The new sketch is published in the same repo. The new mailbox is now smarter and it gives all the following readings:

LO:4h1m BAT:4.36v F:3475 H:37 P:29.32

where LO is last open elapsed time,  F is fahrenheit in hundreds (divide by 100), H is humidity in %, and P is atmospheric pressure in inHg. It’s also running happy after being buried in the last winter storm. In the morning when the sun hits the mailbox directly the temperature can rise 20-30 degrees above the real temperature, but otherwise throughout the day it’s pretty stable and comparable to WeatherUnderground, when it’s overcast it’s often within 1 degree of WU but I am aware there are multiple factors that can influence a temperature reading in such a location. Humidity and pressure readings are also very stable and rise very deterministically.

Making a custom RaspberryPi case

Bulk made enclosures are useful when you just want basic underwear on your Pi but what if you need to put something else in there and it won’t fit? I’ve built a Pi enclosure for my home automation gateway before but it was just 3 layers of acrylic to hold everything together, turned out nice. In this post I will show another example enclosure for a Pi gateway.

I am finishing up a separate project where I needed to put a Pi gateway in an elegant enclosure along with an ATXRaspi+power button, and a Moteino. This guide can be used as a guide to build a RaspberryPi+ATXRaspi+Moteino setup that can all live together in a nice box to serve as an internet gateway to your Moteino or other wireless Internet Of Things network.

I will show you how I made the case and the steps I took to avoid wasting material while adjusting the cutouts. I will include the corel and DXF files that I used to lasercut the case. I have a 60W laser cutter imported from china, and that makes for a very nice prototyping tool to cut and engrave the boxes, but they are becoming widely available at hacker spaces and workshops all around.

First let’s see what components go in the box: Continue reading

Schlage smart door lock hack/teardown

Well it’s not really a teardown, but I did take apart the unit to analyse the electronics, which is the reason I bought this in the first place. Reason #2 was to see if I can hack it to control it via Moteino. Watch the video at the end of the post to see the results.

As the title suggests it’s a smart door lock with a for coded entry and is based on “Iris” which in turn uses ZWave RF wireless technology (made by Zensys), a closed source patented protocol+hardware stack that is OEM-able to automation system makers who want an “off-the-shelf” wireless stack to integrate into their product.
Here are some unboxing photos:

The mechanical side sits on the outside and also contains the keypad. I was eager to open this part up and I was met with a MSP430 controller that drives the keypad along with some circuitry to drive a small DC motor which turns a very small spring which in turn engages a latch. It was very difficult to put it back together and there’s not much going on in there anyway. The brains of this unit is a Zwave SOC (system on chip) which is similar in looks to the RFM69 transceiver. It’s soldered on another host PCB which has two button pads for LOCK/UNLOCK action from the inside of the house, and a red-green LED for visual feedback. The ZWave unit is a MCU+transceiver SOC with similar specs to the Atmega328 and works in the 915mhz unlicensed band in the US.

There are a few interesting finds on this PCB:

  • Power is provided from the 4xAA 6V battery pack through a voltage regulator. The regulator is a MCP1702-3V linear regulator, the same type that Moteino uses (except Moteino is MCP1703-3.3V and accepts up to 16V max input). This is significant because this proves mass manufactured low power electronics can and do use low dropout linear regulators without a major hit on battery life. Some people are concerned about battery life and email me to ask why I didn’t design Moteino with a switching regulator instead. A lot of reasons that I won’t go into here (except to say a low dropout linear regulator will perform great if your firmware is low power enough). And after this teardown I feel even better about it.
  • There is a mosfet enabled resistor based voltage divider which is obviously a battery monitor. A very simple and cheap alternative to other dedicated battery monitoring chip solutions. The resistors are obviously 1% or better and the divided voltage goes into one of the analog pins of the ZWave SOC.
  • The Zwave front end is probably controlled by the MSP430 controller via a 2 wire (serial?) interface, I would guess a UART. The Zwave SOC has a “patented” protocol API which is how the host application configures and talks to it. That part was not something I spent too much time to investigate since I’m not interested in ZWave.
  • The logic on the ZWave SOC is active low. Meaning that to turn ON a LED the pin wired to it has to be driven LOW instead of HIGH.
  • The ZWave PCB was covered in a clear electrical insulator coating (which scraped away very easily) to shield it from humidity, but nothing else was. This is weird, I can’t imagine why they would weather proof the MCU/radio but not the power supply.

Here are the closeups of the main PCB:

In the following video I show more details about how the unit works, power consumption, where I tapped into the circuit to control it, and how it is controllable via a Moteino/Arduino microcontroller. There is very little space in the case to add any other electronics in there. But the Moteino would probably fit OK. This makes me feel pretty good about my Moteino design decisions – one paramount requirement was small size without sacrificing usability (by tightly spaced non-breadboardable headers or cutting back on exposed pins) – it had to fit in such small places as this door lock.

Motion-OLED-Mote kit released

I am pleased to announce the release of the Motion-OLED Mote Kit. It is now available in the webshop. This kit can serve as a wireless motion sensor, mailbox notifier, display monitor for your wireless network. It’s extremely convenient when you just want to see if there is motion somewhere in your house, or if you just want to check your snail mail, without the need of a gateway or anything else – just build a MotionMote and an OLEDMote, keep one where motion needs to be detected and watch the messages coming on the display on the other unit. The onboard buzzer and LED give additional options to indicate visual and audio alerts when an event happens.

The kit contains most of the following components, depending on whether you order a Motion or OLED version. For more details about the assembly, programming, and usage you can visit this dedicated page.

This kit will build either one of these two display or motion-sensor units:

Moteino Framework architecture decisions

My vision for Moteino was to create an affordable/open/ideal/easy hardware platform that would fuel a new generation of wireless internet-of-things, and I think it came out pretty decent. My Hackaday Prize entry even made it in the top 50 semifinalists (out of 800+). More devices are being added to the Moteino Framework and existing ones are being improved to make it fun for those makers who like to DIY and solder their internet-of-things from easy to assemble kits. The end users have maximum freedom as far as using/building stuff with Moteino. They can build absoltely everything from scratch, as some have done, but some prefer to just save time and buy building blocks. Hence I funded my way through this adventure by selling ready made Moteinos and kits in my webshop.

People have asked many times why the Moteino was designed the way it was, and why not use this and that and the other type of MCU, transceiver type, radio band, or wireless technology. The number one reason why Moteinos are what they are today is because in the end they need to be designed to manufacture, work well, be reliable, license free, easy and fun to use in a friendly board format, cheap to buy or make, achieve long open air range or excellent indoor obstacle penetration when used with transceivers, etc. Here is my reasoning behind all these decisions and the answers to some frequently asked questions. Continue reading

Moteino Framework submitted to The Hackaday Prize!

The Moteino Framework (of connected things) is submitted to The Hackaday Prize. If you want to support this entry you can give it a “skull” on the project entry page. Here is the stage-1 video presentation and overview:

If it gets past the first stage I will continue to add more details and refine the entry. Thanks for your support!

SwitchMote R2 coming soon

UPDATE: It is now released (release notes). Assembly & guide is here. Kit available at the shop.

You asked and I’ve listened.
SwitchMote R2 is coming soon as a 100% kit, and should address most safety concerns and shortcomings of R1. I gave up the previous non-isolated design because of different considerations. The switching regulator was not able to work reliably beyond 185V from a half wave rectified input. Then lots of people talked about isolation and supporting loads higher than the 100W on R1. Well I came up with a design that is only slightly bulkier, and is fully isolated (3kV) through a UL certified PSU that supplies 5V @ 400mA for the electronics, uses a very compact coil relay with up to 5A @ 250V load. The design is also much more balanced and I’m happy with the result, the back cover plate uses 4 mounting spacers+screws, allows programming through the FTDI female connector. You can solder your wires directly to the PCB if you are required or you can use the traditional screw terminal. And lots more to talk about but more details will be included in the assembly and usage guide. And yes it works at 240V, doing timed testing right now:

The non-isolation part was of concern because of liability and because I am not a huge company to back it up. To prove my point, look at the tear-down photos of this IRIS switch, it uses a non-isolated design, will you buy it? Continue reading

SwitchMote source code released!

The source code for SwitchMote is finally “done”. As always, consider this a beta release at best, you should always check the github repository for any updates. There are 2 parts to configuring and programming a SwitchMote.

SwitchMoteConfig sketch, which needs to be loaded and used once, after assembly and before SwitchMote installation. This sketch is meant to help setup the essential parameters of the Moteino in the SwitchMote such as frequency, node and network IDs, RFM69 type (W or HW), encryption key, description, and some other utilities that may be extended in the future. All these parameters are then stored to EEPROM and will not be dependent on hardcoded values in your sketch.
This is especially useful when you have some nodes with RFM69W Moteinos and some with RFM69HW. It’s hard to keep track of all the transceivers settings. Additional settings could be added, like power level, bitrate, etc. Keeping the configuration with each node is most efficient in applications like SwitchMote. Setup once and forget!

SwitchMote sketch is the permanent sketch that will get loaded on your SwitchMotes. Note that this sketch will read the EEPROM configuration that was setup with the SwitchMoteConfig sketch mentioned above. This sketch does several things.

  • keeps track of which buttons were pressed, and manages the modes of operation
  • any button can be in ON or OFF mode – reflected in GREEN or RED led status
  • listens for BTNx:y tokens, to put button x in mode y, x={0,1,2}, y={0,1}
  • listens for SSR:y tokens, to turn the SSR on or off and the associated button in that same state (reflected by the LEDs)
  • if the button associated with the relay (SSR) is pressed then the SSR is turned ON or OFF depending on the mode that button transitions to
  • if a button is held pressed for at least 3 seconds (configurable) it enters SYNC mode, explained below
  • if a button has SYNC data it will notify the remote SwitchMotes to virtually “press a button”, and transition that button to the mode specified in the SYNC data
  • if any button is held pressed for at least 6 seconds (configurable) it erases the internal SYNC data in EEPROM. This could be modified such that only the SYNC data associated with the pressed button is erased, not the entire SYNC data
  • notifies the gateway, if any present, that a button was pressed

Note that SwitchMotes loaded with this sketch will work independently and with each other without the need for a network gateway or coordinator. A gateway is by default notified but the feature can be removed if not desired.

Also note that a SwitchMote can work without a relay, in which case only the neutral wire N and a hot wire to either one of S1/S2 is needed. In this case the SwitchMote can just act as a controller for other SwitchMotes or be customized to send other commands to other Moteinos. For instance you could open/close your garage (with GarageMote). The sky is the limit of what you can do.

Further details of the SYNC feature and how to use it are documented on the SYNC mode section of the SwitchMote page. Please refer to that page for any updates and latest information on SwitchMote.

Happy switching & sync-ing!

P.S. This code was released for RFM69 transceivers only because of huge growing interest in these line of transceivers and diminishing interest in RFM12B. You are welcome to port this to a RFM12B implementation as long as you keep within the boundaries of the CC-BY-NC-SA license.