Ich weiß zwar nicht mehr genau, wo ich ihn ausgegraben habe, er passt aber sehr gut als Reset-Taster auf dem AVR-NET-IO:
Auf diesem arbeitet jetzt Fastboot von Peter Dannegger, da mir die Flasherei per ISP zu blöd geworden ist.
Die Entwicklung läuft momentan schleppend, ich hänge etwas mit der Übertragung per JSON. Kleine Dateien gehen, geht’s über die MTU hinaus, kommt Mist an. Ich weiß mittlerweile zwar, woran es liegt, suche aber noch an einer vernünftigen Lösung.
War ein langer Weg, aber endlich gibt mein AVR die (nicht ganz) aktuellen Messdaten im JSON-Format aus:
Jetzt muss ich „nur noch“ die Daten auch richtig aktuell bereitstellen und die JSON-Ausgabe für die historischen Werte anpassen.
Wäre sehr angenehm, wenn ich das Teil heute noch in den Keller hängen kann (was ich aber leider bezweifel).
Ich bin gerade dabei, die erfassten Daten der Stromzähler und Heizung auf dem AVR-Webserver fürs Web aufzubereiten.
Natürlich soll es hier platzsparend zugehen, weshalb ich mich beim Datenformat für Json entschieden hab‘. Jetzt müssen die Daten nur noch in mundgerechte Stücke umgewandelt werden. Zuerst dachte ich daran, wie in der Originalfirmware von Ulrich Radig ein Template zu verwenden, in das die Variablen eingesetzt werden. Wenn ich aber daran denke, dass ich über (momentan) 4 Stunden im 15-Minuten-Takt die Daten sammle, würden das verdammt viele Variablen.
Speicherplatz- und Zeitverschwendung.
Deshalb soll in den einzelnen Programmodulen ein einfacher Json-stringifyer entstehen. Mal sehen, wie gut oder schlecht das über die Bühne geht 😉
Neben meinem Touchlight (dessen LED-Leisten ich heute probeweise mal ans Bett geschraubt hab), beschäftige ich mich auch ein bisschen mit meinem AVR-NET-IO, den ich vor ein paar Monaten mal bei Pollin bestellt hab‘.
Mit der Software von Ulrich Radig ist das Teil einiges leistungsfähiger als mit dem Original, allerdings noch nicht genau das, was ich will. Natürlich muss irgendeine Sensorik ran, Zabex hat eine recht nette und sinnvolle Anwendung für das Teil gefunden, so etwas ähnliches möchte ich auch machen.
Um für den Anfang mal ein bisschen Peripherie an das Teil zu bekommen, habe ich mich entschlossen I²C darin (wenigstens ein bisschen) zu implementieren. Herhalten musste (wie kann’s auch anders sein) ein DS75.
Da die negativen Temperaturen immer etwas ärger verursachten, wollte ich diese auch mal richtig zum laufen bekommen.
Um das Ganze authentisch zumachen, mussten dann natürlich negative Temperaturen her 😉
Bei der momentanen Hitze nicht allzu leicht – die Gefriertruhe steht im Keller und da ist kein Netzwerkanschluss.
Andauernd Eiswürfel oder Kälteakkus nach oben tragen ist auch keine Option.
Nachdem ich mir beim Auffüllen vom Feuerzeug regelmäßig die Pfoten vereist hab‘, muss das Gas doch eine mögliche Option sein. Mit einfachem Ansprühen kommt man schon in die zweistelligen Minusgrade, legt man den Sensor in einen kleinen Becher und sprüht ihn mit dem Zeug an, hält er die Temperatur etwas länger.
Richtig knackigen Frost (ich hab doch mal in Physik aufgepasst) erreicht man, wenn man die Suppe anpustet. Dadurch wird die Wärmeenergie wesentlich besser abtransportiert und erreicht (auf kleinen Raum) bis zu -33°C
Die Luftfeuchtigkeit schlägt sofort am Sensor nieder:
Das Schöne ist: das Zeug verdunstet so ziemlich rückstandsfrei und scheint einen halbwegs hohen Widerstand zu haben, zumindest gab es auch bei einem Vollbad keine Probleme beim Auslesen.
Hier noch ein kleines Diagramm von einem der Messvorgänge (kein Kälterekord):
Einheit ist °C, Dauer waren etwa zwei Minuten.
Wer kennt das nicht?
Man programmiert was und irgendwie will es einfach nicht – echt macht genau das Gegenteil vom dem, was es eigentlich sollte.
Im Quellcode kann man keinen Fehler finden, augenscheinlich ist alles richtig – fast.
Heute hat es fast eine Stunde gedauert, bis ich mir selbst auf die Schliche gekommen bin.
Der Code (Javascript) sah in etwa wie folgt aus:
for(var x = 0; x < objs.length; x++) {
if(objs[x].id = myid) {
objs.splice(x, 1);
break;
}
}
Jetzt sieht man es natürlich sofort: = ist eine Zuweisung und wird immer wahr – dadurch wird immer das erste Objekt aus dem Array gelöscht. Richtig wäre ein == gewesen.
Solche Ein-Byte-Fehler passieren (zumindest mir) gerne mal.
Dumm nur, dass man sowas in Javascript nicht sieht. Richtig ärgerlich wird das Ganze dann, wenn man nicht wirklich gut debuggen kann, so zum Beispiel auf einem µC. Für mein aktuelles Miniprojekt (Wiki-Eintrag gibt’s die nächsten Tage) hab‘ ich als Userdebug Software-UART verwendet, Debugwire gibt’s auf dem kleinen ATTiny leider nicht (wobei ich nichtmal die Hardware dafür hab).
Ärgerlich bleibt so eine Zeitverschwendung allemal.
Obwohl es nicht so ganz dazu passt, ein kleiner Link von Robert aus dem IRC: Products with Customer Tags
In einem PHP-Script, das ich gerade schreibe, lass‘ ich Datensätze von Logdateien umstrukturieren und in eine Datenbank schreiben.
Damit die Log-Datenbank schlank bleibt, werden die Daten gesplittet und auf mehrere Tabellen aufgeteilt – wird ein neuer Satz eingefügt, wird erst geprüft, ob dieser bereits vorhanden ist und, wenn nicht, eingefügt. Die ganzen Statements liegen prepared im Cache.
Nachdem ich für die Anbindung PDO verwende (und somit schnell zwischen verschiedenen Datenbankarten wechseln kann), wollte ich wissen, wie performant SQLite ist.
Die Kontrahenten sind:
MySQL 5.0.51b (bräucht mal wieder ein Update), nichtindizierte MyISAM-Datenbank
SQLite 3.3.7
Der Unterbau ist für beide gleich:
PHP 5.2.6, aufgerufen per Kommandozeile
Windows XP Professional 32 Bit
Speicherort der Datenbanken jeweils auf Systempartition
Intel Core 2 Quad 2,4GHz
4GB (3,25GB effektiv) RAM
Das Erstellen/Abfragen von 92143 Zeilen (verteilt auf 5 Tabellen, Primary Keys und Auto-Increment vorhanden) dauerte:
MySQL: 268,8 Sekunden
SQLite: 52,5 Sekunden
Ein erstaunliches Ergebnis, wie ich finde!
Schade ist da nur, dass viele Webhoster SQLite nicht anbieten. Grund hierfür: bei SQLite kann man die Anzahl der Datenbank schlechter kontrollieren.
