Electric Imp - Making a WiFi Thermometer
Many of you are familiar with the announcement of the Electric Imp, which was not so long ago on Habré , moreover , first impressions of its use are beginning to appear . Since this device seemed to me promising and quite interesting, when I first went on sale the developer edition I ordered myself to play a bit and appreciate the possibilities.We collect
Electric Imp itself at the time of purchase cost $ 29.95 , but in order to start using it, you will have to purchase a fee, which was estimated at $ 19.95 (now the price has decreased to $ 12.95 ).
After the kit arrived, instead of the usual
The thermistor connection is very simple.
Thermistor connection diagram ( source )
')
In order to get rid of the wires, I connected the battery to 750mAh, while on the board itself you need to set the battery power supply with a jumper. It turned out very compact device.
For a visual display of the temperature, I took the Raspberry Pi and the 16x2 LCD indicator from some Chinese set that was lying around idle.
Wiring diagram LCD 16x2 indicator to Raspberry Pi ( source )
I had to suffer a bit because I came across some kind of intermediate revision of the raspberry and the code did not start on the fly. It turned out that the Raspberry Pi board changed the purpose of several legs, one of them was just needed to connect the LCD.
We program
The code for working with a thermistor is quite simple, everything works fine and the result can be seen in the glider on the electricimp website. Now you need to send the result to where I need, since the API has the ability to send HTTP requests, but there are some nuances. First of all, I tried to send the result within my local network, and received nothing. After debriefing, it turned out that the Imp request is not sent directly, but through its server. There are two exits, or to forward the port on the router inside the local network, or send to your external server, and the local server periodically tighten the latest readings from there. Port forwarding imposes certain restrictions on use, so I decided to raise a server with a simple API on App Engine, simultaneously making it draw graphics, which turned out to be very useful.
main.py
#!/usr/bin/env python import webapp2 import json import logging import utils import time import os import datetime from google.appengine.ext.webapp import template from google.appengine.ext import db class Sensor(db.Model): temperature = db.FloatProperty(required = True) battery = db.FloatProperty(required = True) added = db.DateTimeProperty(auto_now_add = True, indexed=True) class SensorRequestHandler(webapp2.RequestHandler): def post(self): data = json.loads(self.request.body) params = json.loads(data['value']) temp = params['temp'] battery = params['battery'] sensor = Sensor(temperature = temp, battery = battery) sensor.put() self.response.out.write('OK') def get(self): sensors_data = Sensor.all().order('added').fetch(None) temperature_data = [] battery_data = [] for item in sensors_data: temperature_data.append([int(time.mktime(item.added.timetuple()))*1000 ,round(item.temperature, 1)]) battery_data.append([int(time.mktime(item.added.timetuple()))*1000, round(item.battery, 2)]) path = os.path.join(os.path.dirname(__file__), 'templates/charts.html') self.response.out.write(template.render(path, { 'temperature_data' : utils.GqlEncoder().encode(temperature_data), 'battery_data' : utils.GqlEncoder().encode(battery_data) })) class LastRequestHandler(webapp2.RequestHandler): def get(self): ordered_list = db.GqlQuery('select * from Sensor order by added desc limit 1') last = ordered_list.get() self.response.headers['Content-Type'] = 'application/json' self.response.out.write(utils.GqlEncoder().encode(last)) class CleanRequestHandler(webapp2.RequestHandler): def get(self, bulk = 'old'): logging.debug("bulk: %s", bulk) try: while True: q = Sensor.all() if bulk != 'all': q.filter('added <', datetime.date.today() - datetime.timedelta(days=60)) assert q.count() db.delete(q.fetch(200)) time.sleep(0.5) except Exception, e: self.response.out.write(repr(e)+'\n') pass app = webapp2.WSGIApplication([ ('/sensor', SensorRequestHandler), ('/sensor/last', LastRequestHandler), ('/sensor/clean/?(all)?', CleanRequestHandler) ], debug=True) As a result, the result looks like this:
- Imp sends a temperature reading to an external server every 10 minutes
- Server saves this value
- Raspberry Pi every few minutes tightens the temperature readings and displays it on the LCD display.
In parallel with the temperature, I decided to collect battery voltage readings, but it turned out that the function from the API returns the voltage from the board itself (~ 3.25V).
Unfortunately, the current ability to execute an HTTP request is severely limited, so we had to pervert and pack the data into JSON, which in turn is packaged a second time into JSON already inside the HTTPRequest node.
class Termistor { pin_num = null; constructor(pin){ pin_num = pin hardware["pin" + pin_num].configure(ANALOG_IN); } function read(){ return hardware["pin" + pin_num].read(); } function getTemperature(){ local temp = math.log(((655350000/read()) - 10000)); temp = 1 / (0.001129148 + (0.000234125 + (0.0000000876741 * temp * temp ))* temp ); temp = temp - 273.15; return temp; } } local sensor = Termistor(9); local output = OutputPort("Temperature", "string"); imp.configure("Termistor 10K", [], [output]); function capture(){ imp.wakeup(600.0, capture); local temp = sensor.getTemperature(); local jsonOut = "{\"temp\":"+temp+", \"battery\":"+hardware.voltage()+"}"; output.set(jsonOut); server.show(format("%1.1fºC", temp)); } capture(); imp.sleep(2.0) server.sleepfor(600.0) Reap the rewards
The graphs are stably constructed, look like this:
Raspberry Pi derives temperature
For a more visual demonstration, I made a small video (I recommend watching it in 720p and full screen):
Energy saving
Imp can run in three modes.
Disabled powersave mode (default)
In this mode, the WiFi module is always on. This contributes to low mains power but leads to high current consumption of ~ 60-80mA for 3.3V
Enabled powersave mode
In this mode, the consumption drops to 5mA at times when there is no transmission over WiFi, but the delay before transmission increases accordingly and it can be more than 250ms.
Deep dream
In this mode, Imp is disconnected from the WiFi network, stops executing code, loses context (except for data in a special nv table) and switches to very low power consumption mode (~ 6 μA). Bring out of sleep can either a pre-cocked timer, or a wake-up pin. Starting and connecting to a WiFi network takes about 2s.
I have to admit that my experiences with powersave mode have failed. What with the enabled mode, that with the Imp turned off, I lonely lived for three days. In principle, you can come to the conclusion that for some reason this very powersave mode was always on for me because the average consumption was out
750/24 * 3 ~ 10 mA, which corresponds to the powersave enabled mode.
In deep sleep mode, the Imp temperature sensor has been working for a month already, and the voltage dropped from 4.2 to 3.68, that is, the LiPo battery for 750mAh should last for about a month and a half, which is good news.
Plans
Add an honest battery voltage meter (which is especially important for LiPo batteries), screw up the solar battery and, while there are no special plans, use it as a local temperature sensor in one of the enthusiastic weather projects. It is also possible to add a Geiger counter.
Conclusion
The device came out very interesting and promising, but at the moment the application is tightly bound to its own Electric Imp servers and the paucity of the API. If we assume that these defects will be corrected, then Imp is ideally suited for use in conjunction with various sensors in smart home systems.
useful links
1. Source code on github
1. Arduino + termistor
2. Electric Imp Wiki
3. Drive a 16x2 LCD with the Raspberry Pi
Source: https://habr.com/ru/post/164105/
All Articles