erste Version am 11.12.2016
letzte Änderung am 01.01.2017

Temperatur- und Helligkeits-Logger - Seite 3

Schaltplan

Eigentlich lohnt es ja kaum, dafür einen Schaltplan zu erstellen. Für die ESP8266-Anbindung und die LDR-Beschaltung habe ich schon Schaltpläne, der Anschluss vom DS18B20 und dem RTC/EEPROM-Modul besteht primär aus simplen Leitungen.
Wahrscheinlich macht es aber durchaus Sinn, noch eine Lebenszeichen-LED einzubauen. Die hat sich bei der Rollladen-Steuerung schließlich sehr bewährt. Ebenfalls bewährt hat sich die Messung der eigenen Batterie-Spannung. Also kommt die auch wieder rein.
Und vielleicht noch ein Taster, mit dem ein sofortiger Sync eingeleitet werden könnte. Würden nach so einem Sonder-Sync alle Stunden-Blöcke im EEPROM auf ungültig gesetzt werden, könnte ein Wechsel von Standort- und/oder Sensor-Anzahl jederzeit durchgeführt werden, ohne den regulären Sync abpassen zu müssen und ohne beim nächsten regulären Sync vielleicht Daten mit falsch zugeordnetem Standort in die Datenbank zu bekommen.
Einen Standort-Wechsel-Wunsch könnte dem ATmega-Programm beispielsweise dadurch mitgeteilt werden, dass der Taster beim Power-On oder Reset gedrückt gehalten wird. Das ATmega-Programm könnte dem Python-Programm dann beim nächsten regulären Sync als erstes mitteilen, dass ein neuer Standort-Satz anzulegen ist. Auf die Weise könnte der beim Datenbank-Design angedachte nachträgliche Update des Fremdschlüssels zum Standort anhand des Datums eingespart werden. Die neuen Standort-Sätze würden automatisch angelegt und mit den neuen Messwert-Sätzen verknüpft werden. Lediglich der Name des Standortes wäre noch manuell einzutragen. Und man müsste vor einem Standort-Wechsel daran denken, erst mal den Sonder-Sync-Taster zu drücken, kurz den Sync abzuwarten und dann den Sonder-Sync-Taster zusammen mit dem Reset-Taster zu drücken. Das ist aber sicher einfacher, als jedes mal nach so einer Standort-Wechsel-Aktion die Datenbank umpatchen zu müssen.
Mit diesen ganzen Erweiterungen lohnt es nun schon, einen Schaltplan zu erstellen:

Der J1 wird wohl eine 5-polige DIN-Buchse werden, über die ein externes Sensor-Paar mit der Schaltung verbunden werden kann.
Etwas trickig könnte es bei einem Outdoor-fähigen Sensor-Paar werden. Als Strippe kommt eigentlich nur Flachbandkabel in Frage, weil sich das am ehesten zwischen Fenster und Fensterrahmen durchführen ließe. Bei Flachbandkabel wird es allerdings schwierig werden, die Sensor-Einheit mittels Schrumpfschlauch wasserdicht zu ummanteln. Vielleicht lässt sich das ja mit Heißkleber abdichten.

Aber wahrscheinlich sollte ich das sowieso nicht mit einem Schrumpfschlauch-Gehäuse machen. Bei einem Temperatur-Sensor stört es nicht, wenn der am Ende des Kabels baumelt und beides vom Wind bewegt wird. Bei einem LDR will man aber wohl lieber eine fixierte Position haben, damit der LDR immer in die selbe, definierte Richtung guckt.
Eine Abzweigdose wäre vielleicht ein möglicher Einbauort. Die gibts aber nur in Feuchtraum - nicht in wasserdicht :-(
Da braucht es dann wohl wieder den Heißkleber....
Ein der benötigten Größe etwas näher kommendes Gehäuse ist das hier. Davon habe ich ein 5er-Pack bestellt und auch schon eine Sensor-Einheit eingebaut. Es passt, jedoch war der Bau übles Gefriemel. Ein oder zwei Nummern größer hätte auch nicht geschadet....

Was an der Schaltung noch etwas stört, sind die LDRs mit ihren 10KΩ Widerständen, durch die konstant Strom fließt.
Bei maximaler Helligkeit (bzw. niederohmigem LDR) fließen dadurch konstant 5V / 10KΩ = 0.5mA.
Sind zwei LDRs verbaut, fließt bereits 1mA für nix....
Akkus mit 1900mAh wären rein rechnerisch nach 1900mAh / 24h/d=79 mAd bzw. 79 Tagen leergelutscht.
Für den DS18B20 wird der typische "Standby Current" mit 750nA angegeben. Dafür brauchts dann eher keine Abschaltbarkeit - aber für den oder die LDRs könnte ich noch einen weiteren MOSFET spendieren. Den bereits vorhandenen MOSFET dafür zu nutzen, macht wohl keinen Sinn. Schließlich soll die Spannung über den LDRs mehrmals pro Minute abgefragt werden, die 3.3V und der ESP8266 werden hingegen nur einmal alle 12 oder 24 Stunden kurz benötigt.
Noch zu testen wäre, wie sich so ein LDR verhält, wenn er erst unmittelbar vor einer Messung Strom bekommt. BTW: beim externen Sensor-Paar braucht es dann eine Strippe mehr.
Statt das Gate eines MOSFETs über einen digital-Pin anzusteuern, sollten die 5V des digital-Pins auch alleine reichen, um einen LDR "unter Strom" zu nehmen.

erster Tag auf Lochraster

Gestern habe ich die Schaltung auf Lochraster aufgebaut....

....und bereits die ersten 24 Stunden Daten von einem Sensor-Paar in der Datenbank.
Die sqlite-Datei ist 83KB groß. Damit ergäbe ein volles Jahr ca. 30MB. Das ist mir entschieden zu groß.
Dementsprechend habe ich etwas in der SQLite-Doku gestöbert und schließlich entschieden, Datum + Uhrzeit als Unix-Time in einem einzelnen Integer-Feld abzulegen.
Auf Python-Seite funktioniert die Hin- und Rück-Konvertierung in ein lesbares Format folgendermaßen:

dede@i5:~> python
Python 2.7.12 (default, Jul 01 2016, 15:36:53) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> d=datetime.datetime(2016, 12, 31, 10, 55, 10)
>>> int(d.strftime("%s"))
1483178110
>>> datetime.datetime.fromtimestamp(1483178110)
datetime.datetime(2016, 12, 31, 10, 55, 10)
>>> d.strftime("%Y.%m.%d %H:%M:%S")
'2016.12.31 10:55:10'

Auf SQL-Seite bietet sich ein View an:

CREATE VIEW Tescht AS SELECT datetime(date, 'unixepoch', 'localtime') FROM tabelle

Liefert den Wert 1483178110 in folgendem Format:

2016-12-31 10:55:10

Der Umbau war dank meiner Datenbank-Klasse komplett schmerzfrei.
Aber leider hat sich die Größe der sqlite-Datei nur geringfügig geändert. Nämlich auf 63KB.
Mit Chance reserviert sich sqlite3 immer größere Bereiche im Stück ... und die Dateigröße wächst nicht linear mit jedem Insert-Statement.
Obwohl....exportiere ich die Tabelle Dump als CSV, hat diese Datei auch schon eine Größe von 35KB.
Im EEPROM auf ATmega328-Seite reichen 5KB. Aber da wird Datum und Zeit ja auch nur einmal pro Stunde gepackt abgelegt und die Nutzdaten sind ebenfalls binär gepackt. Dann ist der Größenunterschied sozusagen das Tribut an die Einhaltung der ersten Normalform und die Menschen-Lesbare Speicherung der Daten. Wat solls....

Anbei der derzeitige Stand von ATmega328-Firmware und vom Python-SocketServer.

Die Fortsetzung folgt demnächst.