This post provides the full details, including code and part numbers. We'll work our way from the bottom-up, starting with the contactors. ("Contactors" are what the cool guys at the electrical parts shop call high voltage relays).
But first, here are some pics of the overall implementation. Not shown is the router and Raspi (located on the main floor, connected to the Arduino below via USB).
Here are close-ups of the Arduino (underneath the) Relay Shield (left) and the transformer (right).
The low voltage power that opens/closes the contactors is controlled by the Arduino w/ Relay Shield. Each of the 4 relays on the shield has 3 contacts - common, normally open (NO), and normally closed (NC). Using standard thermostat wire - I think it's 18 gauge, I sent one wire from each of the relays on the Shield to the low voltage contact on the corresponding contactor, the other to a 24VAC transformer (which is powered by a 240VAC main). I then used the same wire type to connect the transformer to a contact on each of the relays on the Relay Shield. Note that I used the NO (normally open) contacts on the relay shield - so by default the contactor is open (contact not made).
Here is a primitive schematic showing all wiring.
All custom code for this project can be found here. All other code resides on the Raspberry Pi, consisting of Python and various supporting Python libraries (as referenced in the fullauto2.py and parsecal.py code).
Here is the code that runs on the Arduino. The Arduino uses its own programming language, based on C/C++, that is developed in the Arduino IDE. You develop and test the code in the IDE, then compile/upload the code to the Arduino.
The Arduino code starts listening on the serial port, then runs a continuous loop. If it receives an "M" character, it tells one of the relays to close; completing the circuit, closing the contactor, sending power to the mail floor heaters. If it receives an "m" character, it opens the relay - turning the heat off. It similarly uses different characters for the 2 other circuits. The code is also listening for a "U" character. This is a keep-alive signal from the Raspi (device on the other end of the USB connection). This is a fail-safe - in case the Arduino receives an ON signal and then loses the serial connection before receiving an OFF signal. If the Arduino doesn't receive a "U" for an hour, it opens all relays, turning off all heat.
Most of the logic lives in the Python code on the Raspi. The Raspi code establishes a serial connection with the Arduino, then runs a loop that has a 2 minute wait between each iteration. The loop 1) gets my Google Calendar iCAL (ics) file, 2) parses the file, looking for the specific 3 cottage heat events, 3) writes the circuit label and start/stop times for each event (circuit) to a local file, 4) loads the times from the file as items in a dictionary, 5) gets current local time, and 6) depending on whether current time is between event start/stop times, sends the appropriate character to the Arduino. Oh, it also sends the keep-alive "U".
Note that the Arduino will reset each time serial communications are established. This is built into the Arduino and can't be configured. Care was taken to establish serial communications once at the top of the Python code, then merely testing within the loop so that connectivity is only re-established in the event that it is lost. The intent here is to avoid turning the heat off/on every 2 minutes, as would be the case if communications were established routinely within the loop.
Note too that the main Python code does a call-out to another bit of Python code that parses the calendar file. This is because the iCal parsing library wouldn't execute properly from within the main code for some unknown reason. (And there is ZERO documentation for the iCal Python library).
Finally, the intermediary file that is created by the code allows me to turn circuits on/off while at the cottage in the event that the 3G network is unavailable. I such a situation I SSH to the Raspi while at the cottage. I plan to improve upon this with an Arduino with an LCD/button shield that will allow be to simply over-ride heat control at the press of a button. Details to follow.
I created a Google Calendar specifically for the 3 cottage heat events. I created the events with the same names that my code will parse for. I then published the calendar in iCal format, allowing the public to view. Each time I'm planning my next cottage visit, I'll change the start/end times/dates of each of the events accordingly. My use cases are such that I want each circuit to be controlled independently.
The Arduino and Raspi are powered by a UPS, mainly because cottage power is flakier than city power. In the future I plan to use the USB interface on the UPS to monitor and report on power status via the Raspi.
As mentioned in the previous post, I connect to the Internet using a 3G wireless router (MoFi), that receives a USB modem (in my case a Rogers Rocket Stick). I use a tab plan for the stick that is about $5 per month for 10MB - plenty for automation purposes. For now, I'm paying an additional $5 for a public IP address (which I'll cancel once things have settled in). I access the console on the Raspi over SSH from Windows using Putty, and authenticate using a key and passcode. (There are many articles on the Web on how to set this up). I also run a dynamic DNS client on Raspi (apt-get DDNS I think), as I had trouble getting the router to do this properly.
Clearly, I'm not a developer. I know that there is much room for the code to be made more maintainable, robust, and elegant. But hey, it works.
That said, please do suggest improvements that you feel may be worthwhile implementing. Thanks. I'll be cleaning up the code over time; adding comments and improving overall quality and reliability.
Oh, BTW, I've received a number of parts that I ordered from the Open Energy Monitor project. This will let me remotely confirm that current is actually running to the heaters (with actual energy consumption details, nicely charted). I'll be able to report on temperature as well. In fact, the monitoring/reporting solution will be running on an independent Raspi/Arduino. And why not - the stuff''s cheap. I'll post the details of this side of this project once it's functional. Leave a comment if you're looking for more on this in advance of the implementation.
Mike
2 comments:
This is a great idea! Automation saves us all of the trouble in adjusting household stuff. This way, people can focus more on important things, and that the adjustments are on the exact time and parameters needed. There'll be no more guessing on what to do, once this setup's done. Thanks for sharing!
Kellie Taylor @ Aim Dynamics
Post a Comment