Schlagwort-Archive: PHP

PHP: Gekürzte var_dump()-Ausgaben abschalten

“Mal schnell” ein paar Daten im PHP-Code lesbar ausgeben funktioniert üblicherweise sehr zuverlässig mit var_dump(). Auf einem System zeigte sich das Phänomen, dass lange Strings oder verschachtelte Arrays nicht vollständig angezeigt wurden. Ursache ist die Standardkonfiguration vieler Distros der PHP-Extension xdebug. In der entsprechenden ini-Datei lässt sich das Kürzen mit folgenden Zeilen unterbinden:

xdebug.var_display_max_data=-1
xdebug.var_display_max_children=-1
xdebug.var_display_max_depth=-1

PHP mail(): Sonderzeichen im Betreff richtig Codieren

Na das ist mir noch nie aufgefallen: Offenbar ist die mail()-Funktion von PHP nicht in der Lage deutsche Sonderzeichen im Betreff korrekt zu verarbeiten. Die erste Meldung besagte, dass der Betreff bei einigen Providern verstümmelt ankommen würde. Der IT-Fluch schlug natürlich wieder zu: Sowohl mein Thunderbird als auch K9-Mail und Roundcude zeigten keinen Fehler. Dankenswerterweise brachte dann Amavis die Erleuchtung:

X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char C3 hex):
Subject: Testm\303\203\302\244il

Argument, so passt das nicht… In den Mailheadern ist das genünschte “ä” einfach nur als UTF-8-“ä” vorhanden – E-Mails sind aber üblicherweise nur 7 Bit… Um den Betreff korrekt zu versenden muss man den String vorab mit mb_mime_mimeheader in die richtige Form bringen:

mail('empfang@emfang.em', mb_encode_mimeheader('Testmäil', 'UTF-8', 'Q'), 'Text');

PHP (Linux, CLI) clear screen

Wenn man PHP auf der CLI nutzt könnte man in die Versuchung kommen den Bildschirm leeren zu wollen, also in etwa das selbe, was der Linux-Befehl “clear” macht. Da bei exec (so vermute ich) die Termcaps nicht übergeben werden funktioniert ein exec(‘clear’); nicht sonderlich. Wenn man immer das selbe Terminal nutzt lassen sich die nötigen Steuerzeichen direkt als echo hinterlegen. Um die Zeichen zu ermitteln loggt man sich normal auf der gewünschten Konsole ein und startet “clear | xxd” – hier sieht man die für das aktuelle Terminal nötigen Steuerzeichen in Hex. In meinem Fall

0000000: 1b5b 481b 5b32 4a .[H.[2J

in PHP verpackt ergibt sich dann (ausgeschrieben) folgende Zeile:

echo chr(0x1b) . chr(0x5b) . chr(0x48) . chr(0x1b) . chr(0x5b) . chr(0x32) . chr(0x4a);

Alternative für vzcompress / Volkszähler

Seit einiger Zeit nutze ich – wie auch vorgestellt –  das Projekt Volkszähler um meine Messwerte zu erfassen. Der Grund für den Wechsel ist schnell erkennbar: Es ist dem angestaubten RRDTool designtechnisch um Generationen voraus, technisch hatte ich jedoch bereits damals bedenken angemeldet: Die Daten wandern einfach in eine MySQL-Datenbank – rrdtool verwendet hier ein System, welches die zeitliche Auflösung mit dem Alter der Daten senkt und so Speicher spart.

Das Ergebnis war zu erwarten: Über 10GB belegte meine Datenbank zuletzt, also muss Abhilfe geschafft werden. Genau für diesen Zweck findet ich im offiziellen Repo ein Tool namens “vzcompress“, welches unter Angabe der Kanäle und Zeiten per Argument alte Daten nach Zeiträumen zusammenfasst und somit nachträglich den Speicherverbrauch senken kann. Kann. Leider ist das Script nur für Pulssensoren (MeterInterpreter) geeignet, lässt man es auf einen Datenbestand mit absoluten Sensoren (SensorInterpreter) los wird der Datenbestand wegen der in dem Fall unpassenden Zusammenfassungsmethode quasi zerstört.

Also auf in den Kampf: Da sich mein Perl in Grenzen hält habe ich die Funktion in PHP neu implementiert und passend zu meinen Anforderungen erweitert. Das Script liest nun die verfügbaren Kanäle direkt auf den Konfigurationsdateien bzw. der Datenbank aus und unterstützt ein oder mehrere Kompresssionsschemata um ein abgestuftes Komprimieren zu ermöglichen, also z.B.

Die bisher bei Volkszähler implementierten Sensoren wählen automatisch eine passende Methode:

Als Zeitstempel wird immer das Ende der zusammengefassten Zeitperiode verwendet. Auf der Konsole können Live-Statusmeldungen ausgegeben werden um den Fortschritt zu verfolgen. Getestet (im Sinne von es sind noch Daten da die stimmen könnten) ist das Ganze gegen MySQL und SensorInterpreter, andere Sensoren sollten funktionieren, bei anderen Datenbanken könnte es Probleme geben, da die SQL-Queries hardcoded sind.

Das Script selbst findet sich auf Github – für den Betrieb muss ggf. noch eine JSON-Datei gepatched werden.
Dank der Mailingsliste konnten bereits ein paar Schnitzer erkannt und zum Teil auch schon behoben werden. Auch einige interessante Verbesserundvorschläge versprechen noch bessere Ergebnisse.

Updates für php-dio und fusecompress-1 @ AUR

Soderle, kleinen Frühjahrsputz für mein Archlinux veranstaltet: php-dio ist jetzt auf Version 0.0.7 – eigentlich unnötig, da offenbar nur Änderungen für Windows drin sind, aber hey, die Optik spielt ja auch eine Rolle. Zudem habe ich mich mal erbarmt und die C-Variante von Fusecompress auf die aktuelle Version gehoben bzw. einige Compile-Patches eingearbeitet – mal schauen, sollte die letzte Version endlich die FUSE-Abstürze auf meinem PC beheben adoptiere ich es eventuell dauerhaft, aber erst mal wird jetzt die neue Version mit meinem /home auf Herz und Nieren getestet…

PHP Google+ Library – und es postet doch…

Google+ dümpelt weiter vor sich hin – zwar hält mich die mangelhafte Clientauswahl weiterhin davon ab dort mehr im “Tagesgeschäft” zu machen, allerdings sind Features wie die Hangouts Gold wert. Meine erste Anforderung für regelmäßige Nutzung bin ich nun einmal angegangen: Ich möchte posten. Nicht über einen vorgegebenen Client, meine Rechner sammeln ohnehin schon eine Menge Informationen zusammen und die sind vermutlich nicht nur für mich interessant. Gut, dass es eine API gibt. Nicht. Googe stellt zwar bereits eine API mit OAuth & Co zur Verfügung, aber die ist derzeit nur lesend zu benutzen.

Zum Glück bin ich nicht der einzige mit diesem Wunsch, so hat Luka Pusic bereits einen Google+-Bot in PHP geschrieben und praktischerweise auf GitHub veröffentlicht. Statt mit einer API zu kämfen emuliert sein Script schlichtweg einen (Handy)Browser und liefert so die Daten bei Google ab. Zwar ist das Ganze nicht unbedingt für Webapplikationen brauchbar, für lokale Single-User-Scripte wie meine aber perfekt. Auf Basis seines Codes habe ich nun eine kleine Google+-Library gebastelt – neben etwas Codeputz gibt es auch eine Funktion um einen Status mit Bilddatei zu veröffentlichen. Leider ist das Mobilinterface recht eingeschränkt, sodass bisher keine (schönen) Links oder Verknüpfungen zu anderen Personen auf G+ möglich sind. Also kein allumfassender G+-Zugriff, aber genug um z.B. einen Twitter2G+-Bot zu realisieren, wie er sich derzeit auf meinem Account austobt. Die Post sind momentan auf den Kreis “Öffentlich” hardcoded, sollte sich aber bei Bedarf recht leicht anpassen lassen.

Den Code der G+-Lib gibt’s auf GitHub, der Twitter-Bot ist noch nicht so komplex, als das sich das lohnen würde. Und wenn ich schon mit den neuen Netzen rumspiele kann man das Projekt dann auch Flattrn.

Eigenbau vs. Volkszähler

Derzeit baue ich wieder an meinen Erfassungssystemen – neben dem Temperaturmonitoring ist nun auch der in BB5 vorgestellte Stromzähler in etwas größerer Ausführung im Dauerbetrieb. Die Systeme selbst laufen zufriedenstellend, aber mir fehlte im Eigenbaufrontend etwas Eyecandy.

Erst mal zu meinem Eigenbau: Die Sensoren liefern ihre Daten über verschiedene Wege an meinen Homeserver – dort schreiben entsprechende Daemons die Daten in eine RRD-Datenbank weg. Bei Aufruf der GUI werden aus den Datenbanken entsprechende Diagramme erstellt bzw. Statistiken errechnet. Vorteil ist die effiziente und ausgereifte Speicherung der Daten: das verwendete RRDTool ist “gut abgehangen” und speichert lediglich Differenzwerte, was eine Menge Platz spart. Die Erstellung der Grafiken nimmt ggf. etwas Zeit in Anspruch, mit entsprechendem Caching lässt sich das aber verschmerzen. Fertige Systeme für Interaktion mit den Programmen sind derzeit nicht eingebaut.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2012/04/p1-150×150.pngBild: https://www.adlerweb.info/blog/wp-content/uploads/2012/04/p2-150×150.png

Auf einem der letzten Chaos Communication Congress’e war mir ein Projekt ins Auge gefallen, welches sich Volkszähler nennt – deren Ziele entsprechen ungefähr auch meinem System und da als Scriptsprache PHP zum Einsatz kommt würde das Ganze eine gute Basis für mich darstellen. Gesagt getan – dank der einfachen HTTP-API kann mein Sensor-Daemon die Daten – neben der weiterhin laufenden RRD – auch bei der Volkszähler-Middleware abliefern. Nach etwas Codestudium sogar mit Timestamp, welches einen Import meiner Daten möglich machen würde. Ein valider Aufruf sieht z.B. so aus: middleware.php/data/aaa-bbb-ccc-sen-sor-id.json?operation=add&value=123&ts=1334416684000.

Die GUI zeigt sich – abgesehen einiger Differenzen wegen meiner PHP-Konfiguration ganz kooperativ und stellt die Diagramme in perfekt angepasster Größe dar. Per Maus kann man einzelne Zeitbereiche nach Bedarf vergrößern, die Daten in anderen Formaten exportieren oder die angezeigten Sensoren dynamisch ändern.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2012/04/p3-150×150.png

Sorgen mache ich mir jedoch bei einem Blick unter die Haube: Alle Messwerte werden in eine – in diesem Fall MySQL – Datenbank geschrieben, bei den hier werdendeten Sensoren kommen so pro Monat hochgerechnet über 700MB an Datenvolumen zusammen. Meine RRD-Datenbank hat für eine Speicherdauer von mehreren Jahren gerade mal 4 MB. Etwas optimieren könnte man noch, so kann man wie auch bei RRD die Auflösung älterer Daten verringern, also z.B. nur einen Messpunkt alle 5 Minuten beibehalten, jedoch sind diese Funktionen nur von Haus aus dabei und müssten separat erstellt werden.

Da mein Server einiges an Speicher zu bieten hat werde ich mich an letzteres eventuell mal ransetzen, vorerst bleibt jedoch die gute, alte RRD in Betrieb.

BitBastelei #5: Stromverbrauch am PC darstellen

BitBastelei #5: Stromverbrauch am PC darstellen

(13 MB) 00:09:06

2010-12-17 13:28 🛈

Korrekturen:

  • Wenn man auf der Volkszaehler-Seite statt Wiki die Folien bemüht findet man Dokumentation
  • Zur Ergänzug, da ich nur das Tagesdiagramm gezeigt hatte: Natürlich habe ich auch einen “Live”-Modus, bei meinem Zäher erhalte ich ca. alle 2-3 Sekunden einen neuen Wert

Links zum Thema:

Mediacenter-Zwischenstand

Inzwischen wächst mein Touchscreen-Mediacenter langsam weiter – das neue Menüesign habe ich vom “Telekom-Haus” abgekupfert (Bild), die Startseite enthält nun nurnoch das aktuelle Wetter sowie die Vorhersage für die nächsten Stunden, die Steuerung der einzenen Relais ist auf eine eigene, momentan noch etwas spartanische, Seite des Menüs gewandert. Videos werden noch immer als eine “Coverparade” angezeigt, auf Klick/Touch lassen sich IMDB-Infos einblenden und das Video abspielen – dank neuer Radeon-Karte im PCI-Slot auch etwas flüssiger als bisher. Audio wird ebenfalls einen neuen Anstrich erhalten: Zwar greife ich immernoch auf Amarok (und somit auch dessen Metadaten und die gesammelten Statistiken und Bewertungen aller PCs) zurück, allerdings wird dieser nun direkt über meine PHP/HTML-GUI gesteuert – DCop machts möglich. Neu dabei kommt am Ende noch die Möglichkeit über LAN auf einige Ressourcen eines anderen PCs zuzugreifen – ich denke dabei an einen Embedded-Rechner mit DVD-Laufwerk am Monitor oder auch einen Rechner mit TV-Karten.

Mehr Wetter

Ach ja… Feiertag… Endlich etwas Zeit zum Basteln. Heutiges Ziel war ein SHT11, ein Sensor, welcher mir in Zukunkt neben der bereits vorhendenen Temperatur auch die relative Luftfeuchte liefern soll. Hardwareseitig war das SMD-Gehäuse für mich als Groblöter ein Alptraum, aber mit etwas Geduld und einem guten Klecks Heißkleber sollte das ganze fürs erst halten. Softwareseitig bin ich, wie bei den meisten Problemen, bei Mikrocontroller.net schnell fündig geworden. Zwar musste der Code für meinen Mega8 noch etwas angepasst werden (dieser nutzt andere Registernamen und -größen für RS232), aber der Grundcode lief, nach ein paar Tritten gegen den MAX232, einwandfrei. Auf dem PC läuft wie immer ein PHP-Script, welches die Daten entgegen nimmt und in eine RRD verfrachtet. Das ebenfalls in PHP realisierte Frontent bedient sich zudem den Formeln von Wettermail.de und berechnet so aus Temperatur und Luftfeuchte einige Nährungswerte für Taupunkt sowie die Menge des Wassers in Gramm pro m³ Luft – und weils gerade so lustig war darf das Frontend auch noch Datum, Zeit, Sonnenaufgang, Sonnenuntergang und Sonnenhöchststand berechnen.

Jetzt muss ich nurnoch einen passenden Standort für das Gebilde finden – Werte von meinem Schreibtisch nutzen mir nicht all zu viel. Zwar habe ich bereits einen Temperatursensor außen, aber der Befindet sich auf der Südseite des Hauses, was man deutlich an den Temperatur-Peaks gegen 11-12h sehen kann. Naja, bei einer nötigen Datenrate von 8 Byte pro Sekunde sollte die Buslänge schonmal kein Problem darstellen.

90479052