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.

Can RFM12B talk to RFM69?

I was asked this question a lot of times. Didn’t have a clear answer because in my early attempts to make them talk to each other I didn’t have success. I didn’t spend a lot of time on that since my interest has leaned towards RFM69 transceivers since they are much nicer and feature-rich overall (nicer packet engine, hardware AES encryption, digital RSSI etc).

Forum user timw has forked my RFM12B and RFM69 libraries and modded them to make them compatible, see this forum post for details. Turns out these mods makes communication possible between RFM12B and RFM69 transceivers. This is great news!

I was able to load his version of the libraries in my Arduino/libraries folder (I had to move/remove my original libraries because of conflicts), and using the examples that come with the two libraries (Struct_receive example on the RFM69 side, and Struct_send on the RFM12B side) I was able to see data coming through the RFM69 end. Seems very stable too. The signal strength (RSSI) fluctuates a little more than if I had RFM69 radios on both ends but it’s great to actually see a signal strength for a RFM12B transmitter:

The caveat is that the encryption must be turned off on both ends with the current version of the libraries. That’s because RFM69 uses hardware AES encryption and RFM12B does not support hadware encryption but uses a software XXTEA algorithm instead. The two are not compatible. One workaround would be to port/duplicate the XXTEA encryption on the RFM69 side, probably a little slower but worth it if encryption is important.

So anyway this should help folks that are trying to salvage their RFM12B nodes and make use of them while moving towards RFM69 based nodes. For me personally I will likely just upgrade everything to RFM69 moving forward but still this is a great development. Thanks timw for sharing your work!

RaspberryPi home automation gateway – Hardware and Demo

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.

In this last part of the RaspberyPi home automation gateway series I will show an example of hardware implementation that talks to the RaspberryPi secured realtime home automation gateway, and share the firmware source code.

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.

Continue reading

RaspberryPi home automation gateway – Setup

In this third part of the RaspberyPi home automation gateway series I’d like to present the RaspberryPi software stack that will allow a secured realtime webserver-websocket gateway to your home automation project.

As a webserver I decided to try Nginx. I’ve previously used Apache which always felt a bit slugish and had a large disk and memory footprint. There are many bechmarks that contrast webservers performance, here’s a nice one that focuses on RaspberryPi, and it includes Nginx and Apache.

The stack will be a webserver (Nginx) and a websocket server (Socket.io). The websocket will be proxied through Nginx, and everything will be encrypted with SSL and authenticated with auth_basic. A bunch of other things need to be setup and configured to make these work nicely together. Continue reading

Temperature and RC-Calibration for RFM69

I added two new functions to the RFM69 library: readTemperature() and rcCalibration(). Thanks to John for contributing.

  • readTemperature() function reads the internal CMOS 8bit temperature value, it’s fairly useful for situations where temperature varies a lot and RC calibration would be needed.
    The Gateway example has been updated to reflect its usage.
  • rcCalibration() will trigger a calibration of the internal RC oscillator. This is automatically performed at power-up according to the Semtech SX1231 datasheet section 4.3.5. But it can be triggered with this new function, as John has mentioned in the forum that when temperature changes, the RC oscillator will be affected, and a dramatic temperature shift will result in a frequency shift as well, causing a link to possibly be broken (for instance when your receiver is inside your house at room temperature and the transmitter is outside in bitter cold winter).

With the combination of these two functions, you can now recalibrate the RC based on temperature change, and also report a rough ballpark of what the temperature is. If you need more accuracy, a separate temperature sensor like the DS18B20 should be used.

 

Update & RFM69 lib bug fixes

For those wondering what’s going on with the silence, I have been quite busy but I am continuing to work on improving Moteino and the libraries behind it. I hope to release news on what I’m up to in a few weeks.

The forums are now picking up activity and they are a good place to check out for various support questions that have already been answered and also to see what others are saying/sharing about Moteino.

I encourage you to keep an eye on the library source code on github for bug fixes. I am working to extend the RFM69 library and occasionally I find code that I can improve and even bug fixes. For instance right now I patched a fix for the setPowerLevel(byte level) function which was declared incorrectly as protected and also had a bug. This bug fix is especially important for those that have Moteinos with RFM69HW radios. Overall my feeling as I develop with the RFM69 library is that it’s becoming a more and more stable piece of code. I do rely partially on others to provide feedback and I appreciate those who can participate and submit suggestions.

Wireless programming Moteino R3

It works!

The last few weeks I have spent a lot of time tweaking the RFM69 library and trying to get the wireless programming to work. I believe the RFM69 library is now more stable and ready for some prime time and also the wireless programming is working nicely for Moteino R3. If you think about it, being able to reprogram a mote that is 200m away, or somewhere in a tree, underground, in your attic, or on the bottom of your pool, is a pretty cool thing.

I reorganized the Github repository a little, moved some files and now the classes for wireless programming are in their own repository to avoid conflicts with the SPIFlash lib:

https://github.com/LowPowerLab/WirelessProgramming

If you have a Moteino R3 (or R2) with the onboard FLASH chip, you are ready to try programming it wirelessly, go ahead, it’s pretty neat.

The examples for Moteino R2 and R3 are in the directories for their libraries: RFM12B and RFM69.

More great stuff is coming, I got a lot of ideas for Moteino R3, I am thinking of migrating my home wireless sensor network to R3 and implementing a lot more home automation on these.

RFM69 library and Moteino R3

This is the library that I’ve been working on for the new RFM69 modules from HopeRF. I consider this an initial beta release and it surely is a work in progress, it may contain bugs, but the provided Gateway and Node examples should work out of the box and illustrate basic usage. Please let me know if you find issues. The syntax is a little similar to that of the RFM12B library, but I went with some new conventions on naming and overall structure to improve readability and overall code quality.

This is a video introduction to Moteino R3:

This is a new product and the library needs more testing and performance tuning. The library currently is tuned for fixed 433/868/915 Mhz frequencies, and a 50khz bitrate, 50khz frequency deviation. I am hoping others will contribute and test the library to find the best combination of these settings and power level vs range vs frequency vs bitrate, etc.

Continue reading

Wireless programming update

The initial code commit for wireless programming was a little sluggish and the performance wasn’t very good. I had to add delays to make sure everything was synch-ed and the protocol was working. The result was a rather slow wireless upload of a new sketch, especially if it was a large sketch. But it worked…

Today I worked on improving the protocol and was able to cut down the over-the-air upload time by a factor of ~5. The gains are mostly from improved serial communication. This will still take about twice as long as normal sketch uploads by means of an FTDI adapter. For instance, a 9,8Kbyte sketch takes me about 11 seconds to upload directly to a Moteino using an FTDI cable; wirelessly programming that same sketch takes about 22 seconds. Not bad given how involved the whole handshaking protocol works. And much better than almost 1 minute with the old code. So I’m classifying this new release as a beta. More improvements or bug fixes might be added later, but it’s definitely a functional release. I’ve uploaded different sketches of around 10KB several times without a glitch.

The wireless sketches examples (gateway and node) and the python script are in their github repo. The SPIFlash library was also updated (the WirelessHEX part of it), so get latest before you try this.

As mentioned before, the target node of the wireless programming protocol will need to have an SPI Flash chip attached (if they don’t have one already), and also run the DualOptiboot bootloader for this to work. Moteinos come with this bootloader (all orders since the other Wireless Programming post and code was released). If you have all these components right, any Arduino clone with an RFM12B transceiver and an SPI Flash chip of at least 32Kbytes of memory will do the job.

Just for fun, here’s how the end of a wireless upload looks like, notice there were 617 packets sent all the way from the PC (through the python script) to the attached Moteino (gateway), wirelessly to the remote Moteino (target node):

Transmission_end

SPIFlash memory library for Arduino/Moteino

I posted the SPIFlash library I was talking about in previous posts. I have not found a convenient library for that purpose hence this library written by myself.

Get it at my Github repository: http://github.com/LowPowerLab/SPIFlash
Also added a basic usage example under the library.

The All-About-Moteino page describes how you can add a flash chip to your Moteino or even to your Arduino. To access this chip you will need a library such as this one to conveniently read or write bytes to the chip. I would recommend getting used to the chip itself by doing some reading in the datasheet of the chip you are using – there are some particularities as to how these chips work. The library attemps to abstract most of these things so you don’t have to worry about them. At the very least please read the comments in the code for now. Soon I will hopefully add more info and tutorials. Stay tuned for the complete solution code for wireless/in-field programming of Arduino/Moteino using this library. I am working to get all that code organized and posted on this blog.