There is now a new revision of Moteino USB (R5). It has 27ohm resistors on the D+/D- lines and pulled up the RST line on the FT231XS chip which should help with any upload issues, see this forum post for more details.
Also the new FTDI Adapter (R2) fixes the same issue and also switches from FT232RL to FT231XS. The reason being the economics of using a chip that is not only cheaper while doing the same function, but also the one and only USB-serial converter I now use.
I assemble all these boards on a pick and place machine and having a reduced and more efficient BOM makes a big difference. The FT232RL came in a wide 24mm tape which occupied a separate 24mm feeder. Buying a full reel of those parts is an impossibility given the price, and partial reels require a leader to load into the feeder, an extra fee every time you buy anything less than a full reel. Plus, some of the leader tapes I buy from Digikey break off pretty easily and so it’s a pain to work with individual feeders and I’m trying to avoid leader tape whenever I can. The FT231XS come in tubes which makes it much easier to work with using the vibe feeder. The only downside is that I have to reload them more often (58 parts per tube).
I kept mentioning this in the forum from time to time and I’m happy to release the first batch of WeatherShields which is now available in the shop. These are highly accurate I2C temperature/humidity (Si7021) and atmospheric pressure (BMP180) sensors. Credit goes where it’s due – this was inspired by this forum post and its author mr. A, but it’s somewhat different than the one presented there. There is a sample sketch to read the data from this shield, schematics is at the end of this post.
The Si7021 has an active conversion consumption of 150uA and standby of 60nA, and BMP180 ranges between 3-12uA in active mode and 0.1uA in standby.
Very Fast sample times, far superior to sensors like DS18B20 which require a long ridiculous sample reading time of up to 1s. By comparison Si7021 requires about 4-10ms sample conversion time depending on reading resolution (8-14bit)
The shield can be stacked on/under a Moteino (not a MoteinoMEGA)
Small prototyping area where you can add a little circuit, connect it to the Moteino pins through thin hookup wire
The BMP180 sensor also gives temperature readings that are pretty good but it is primarily an atmospheric pressure sensor, and Si7021 has a magnitude better accuracy for temperature
Onboard P-mosfet driven VIN/battery monitor. This is a VIN-4.7k+10K-GND voltage divider that can be enabled by setting A3 to OUTPUT LOW and reading the VIN voltage on A7, then disabling it to save power by setting A3 to INPUT (HighZ which disconnects any battery drain through this circuit).
These are much different than popular hobby sensors like DS18B20 or DHT11/DHT22 which are in a different price range and much more limited, so they are not meant to be general purpose sensors. These boards come at a price and instead they are precision sensors for serious weather monitoring enthusiasts and offer a set of features which makes them very battery/remote monitoring friendly and along with Moteino they can make a very small battery operated node. There is a battery friendly sketch available.
Comparing readings between 2 units:
This is how they look fresh out the reflow conveyor:
I put together a quick video to show the progress of SwitchMote and a simple demonstration of how it works and how it can be used in home automation. My goal is to offer a smart wireless light switch controller that allows syncronization with other units independently (without the need of a gateway/coordinator) to create light scenes, and increase the usability of a regular light switch.
Here’s a peek at another project I’ve been working on lately, SwitchMote. It’s a compact shield for Moteino that has a mains switching power supply and a solid state relay to drive a mains load. I’ve designed this to work for lights. The idea is to replace a single regular light switch with this so that I could control lights from the home-automation controller, while allowing it to be operated manually as well. An LED indicates the status of the light/load (LED on when light off).
UPDATE: An updated version of this gateway install guide is published here. The rest of this post is kept here for legacy purposes, some links to source files might be obsolete or not work any longer, please see the linked guide above for the latest code and walkthrough.
GarageMote is a garage door controller shield that can be used to remotely control a garage door from anywhere on the web or from your smartphone.
GarageMote was created for several reasons. Mainly because as I’m adding more Moteino based home automation devices around my property, one of the nice things I wanted to be able to do is control the garage door remotely. It’s become so routine to close the garage door when I leave from home that sometimes when I’m already 5 or 10 minutes away I wonder if I actually closed it. And so I want to be able to check the door status and close it if it was left open by mistake, without having to drive back home. Or maybe it’s useful to be able to let someone in without giving them the garage code every time.
In the previous part of this post I described the conceptual high altitude picture of a secured, realtime home automation gateway. In this part I will go into more detail and show some of the issues I’ve faced and and solutions to address them.
First, the webserver had to be put behind a mandatory SSL connection. All incoming HTTP port 80 traffic would be permanently redirected to secure sockets layer port 443. That was pretty easy with a self signed SSL certificate and some webserver configuration. Then HTTP basic authentication was put in place so that users would first need to be authenticated before web access would be granted. Again, not too complicated, using a .htaccess file and some changes in the webserver config file. Custom authentication can also be implemented, but for the purpose of this tutorial basic auth is good enough.
Now to the harder part. I wanted the websocket server as a separate entity from the main webserver. Several reasons for that, but mainly because of scaling and I like to keep separation of concerns and have a modular design. That exposes several issues. Continue reading →
The title is actually incomplete but didn’t want to make it too long. What I’m about to describe is an initiative on how to put together an encrypted, authenticated, realtime, RaspberryPi powered home automation gateway. It will be a few separate posts that will go from concept to implementation, using a real world example of how to control something in the house. I’ll break it down and explain the big picture and each part that needs to be addressed. But first, a little more background and reasoning behind this effort.
Above you can see my temporary gateway setup. It’s very simple – I have a RaspberryPi powered through an ATXRaspi, and a Moteino which acts as the gateway to my wirelessly controlled house. It’s hard wired to my home router because the wireless adapters are simply junk, not reliable. Also hooked up to a monitor and keyboard.
I’ve seen tons of blogging and articles on how to make something blink, turn a servo or LED on, even do more real things like turn ON lights, change the thermostat or control some household appliance, from your smart phone. All cool and dandy. But almost everyone seems to completely skip security. The blog posts end when the LED or light turns on, and everyone seems to be super excited about the cool thing they just did. But I’m left there with a raised eyebrow wondering if those people know what they are doing. Security is of major concern to me because if I hook up my garage doors, lights and perhaps other appliances to the interwebs, I don’t want unauthorized access. Is that a nobrainer or am I paranoid? Continue reading →
Update: MoteinoLeo is now discontinued and no longer available for sale.
The difference between MoteinoLeo and the regular Moteino is pretty obvious – it’s got built in USB. It’s conceptually an Arduino Leonardo clone, with an RFM12B transceiver solderable on the bottom, with a few minor changes and some added features. It runs at 16Mhz, 3.3v, has an optional FLASH footprint for data logging (wireless programming on Leo is not yet achieved, perhaps in the future if a custom bootloader will permit). There’s also a 750mA PTC fuse to protect the USB against shorts or over current.
For a few weeks I kept tweaking and playing around with my new mailbox event notifier, based on Moteino. It all started as a joke, then when I saw it actually works, I decided to beef it up and do a writeup and a video: