Weitere Informationen

Allein, nicht allein, doch allein und überhaupt: RRD cross-platform
Friday, January 29, 2010, 17:00 - Geeks & Co., Painseeker, Linux, Hausautomation, PlugComputing
Allein zu sein, das ist kein schönes Gefühl. Komischerweise bekomme ich das bei meinen Projekten des öfteren ;)

Nachdem ich nun einen meiner SheevaPlugs zum primären Hausautomatisationsknoten gemacht habe und FHEM darauf auch schön läuft, war der nächste logische Schritt, auch die Langzeitdatenaufzeichnung mittels RRD zu aktivieren, um den betagten, energiehungrigeren FSC Scenic xS entsorgen und einmotten zu können.

Und wenn man die Daten erst mal hat, das Auswerten kann ja auch von anderen System erfolgen, NFS und ähnliches macht's möglich … ja, aber nicht bei plattformabhängigen Datenbasen, wie sie RRD nun einmal leider erzeugt: 
wusel@server-1:~$ rrdtool info /mounts/plug-2/rrd-fhem/Parkplatz_TH/temperature.rrd 
ERROR: This RRD was created on another architecture
Schön, daß wir drüber gesprochen haben … Ich hatte das in der Tat vergessen, aber für optimale Performance schreibt RRD nuneinmal die lokale Speicherabbildung des Daten in die Datei. Und die Darstellung unterscheidet sich leider zwischen Ubuntu auf armel und Ubuntu auf x86 — die Ausgabe ist keine rauspatchbare Schikane, denn rrdtool testet nach dem Einlesen einen »magischen Wert«, und der differiert, leider, obwohl beide Plattformen nach »little-endian«-Notation laufen.

Ich fühlte mich erst einmal allein gelassen, nachdem ich googelte und mehr so nichts deutlich neueres als eine Frage aus 2002 bzw. vage Diskussionen zu dem Thema fand:
Aber, niemals die Hoffnung aufgeben — und siehe, Überlegungen gibt es schon und ein Projekt für die Übergangszeit, welches mir helfen könnte — also doch nicht alleine!

Gelesen, gezogen, geinstalliert; geht nicht: 
wusel@server-1:~$ tird-rrdtool -arch arm dump /mounts/plug-2/rrd-fhem/Huette_TH/temperature.rrd 
ERROR: This RRD was created on other architecture
Und wieder zu früh gefreut und auch wieder allein; armel wird augenscheinlich nicht unterstützt; klar, das Gros der bisherigen Router auf einer Embedded-Plattform waren vom Typ mips.

Tcha. Da habe ich also nun meine Daten auf einem kleinen, energiesparenden – aber eben FPU-schwachen – »Plug«, nur weiterverarbeiten unter x86 kann ich sie derzeit nur, wenn ich sie periodisch auf dem Plug ex- und dann auf x86 wieder importierte. Das hätte ich gerne *nur* auf x86 gemacht, aber dazu jetzt ein static binary unter qemu für meine arm5el-Systeme zu bauen, sprengt doch etwas den Rahmen; da wird das kleine Kistchen halt die eine oder andere CPU-Überstunde schieben müssen, bis rrdtool 1.5 cross-platform-Unterstützung mitbgringt … (Oder ich versuche mich an einem "repacking" der Daten beim Einlesen, aber wahrscheinlich ist's es soo einfach nicht, wenn man die Datenrepräsentation sich ansieht.)

»[…] und alles andere mit Software lösen (ich bin Informatiker)…«
Tuesday, January 26, 2010, 07:51 - Geeks & Co., Painseeker, Linux, Hausautomation, Technologien
Hachja. Hausautomation ist schon ein lustiges Thema. Den frühen, vergangenen, Abend habe ich damit verbracht, das Netz zu durchforsten nach einer – kostengünstigen – Möglichkeit, meinen Energieverbrauch (elektrisch; der Rest läuft ja über WEG) zu erfassen. Die Stadtwerke als (derzeitiger) Lieferant bieten, auch auf Nachfrage im Januar 2010, keine »monatliche Abrechnung« an, wie es gesetzlich eigentlich nun vorgeschrieben ist; Smarter Zähler mit Ausleseoption für mich seitens der Stadtwerke fällt also flach. Die IR-Sensor-Lösung Marke ELV/Conrad auch, da der stylische Schlumberger-Zähler in Rauchglas-Optik die Messung verhindert. Bleibt also nur entweder den Wecker auf 6 zum täglichen Zählerstandablesen stellen — oder ein eigener Zähler mit Schnittstelle zwischen Zuleitung vom Zähler im Keller und dem Rest des Sicherungskastens.

Da ich eher nicht so der Frühaufsteher bin, schon gar nicht an 7 Tagen in der Woche, würde ich das Ablesen schon gerne Maschinen überlassen – also Investition ein einen Drehstromzähler mit Schnittstelle. Hmm, welcher Schnittstelle, auch da gibt's ja viele Varianten, von auskunftsfreudig (M-Bus: Wirk-, Scheinleistung, Spannug, Strom, cos phi, Frequenz, …) bis lobotomisiert (S0: 10-1000 Impulse/kWh), von teuer (im oberen 300er Bereich mit M-Bus) bis fast günstig (Artikel-Nr.: 125411 - 62 von Conrad, 129,-- für einen Drehstromzähler mit S0).

S0 hat die AVM-Box im Kämmerchen auch, leider den ISDN-S0 und nicht die Ausführung nach DIN 43864 … dafür ist dann wieder Extra-Hardware notwendig, entweder im lustigen Selbstbau oder doch einfach als Zählermodul mit normiertem Anschluß – irgendwie tendiere ich ja doch zu letzterem. Ja. Ich werde alt ;) (Wobei ich noch checken muß – mentale Notiz hier –, ob denn der verwendete Zähler von digitemp oder OWFS unterstützt werden; kaum etwas würde an meinem Ego kratzen, wenn ich beim Anschluß an die Linux-Box erst feststellen müßte, daß grade dieser Chip (noch) nicht unterstützt wird … Warum ich das erwähne? Empirischer Wert …)

Nungut; nachdem diese »Details« klar sind, heißt es nun, einen E-ticker zu finden, der mir das qualifiziert einbaut, ohne dafür gleich meinen Arm oder mein Gemächt zu verlangen — kostet mich die Messung das, was ich n Jahren an Energie einspare, ist das für mich, zum nachvollziehbaren Leidwesen des Elektrikers, wenig spannend noch das Thema …

Irgendwie finde ich das alles sehr … bemerkenswert. Das Plugwise-System ist schon cool – habe heute eine Neuinstallation mit laufendem Snooping der seriellen Kommunikation gemacht, ich glaube, da gibt's noch lustige Befehle zu dekodieren –, aber für die 10-20 zusätzlichen »Circles« für einen sinnvolleren Überblick würden noch immer keine Gesamtsicht bringen. Wie aber stecke ich einen Schuko-Zwischenstecker in meine Deckenleuchte? Wechselstromzähler – unbeglaubigt, aber das sind ELVs EMs oder Plugwises Circles ja auch nicht – mit S0-Schnittstelle gibt's schon für ca. 25,-- EUR als Neuware in der Bucht; je S0 ca. 20 EUR (2x S0 auf 1-Wire < 40 EUR) dazu macht 45,-- EUR/Stromkreis – da wären Plugwises Stealth-Kästen mit rd. 40 EUR günstiger, aber normal kaufen kann man die wieder nicht … (Abgesehen davon, daß der Stealth nur ein Circle ohne Stecker & Buchse ist — wieso ist der *teurer*‽) Und wieso hat noch kein Hersteller etwas entwickelt, was einen gesamten Strang vielleicht nicht schalten, aber zumindest messen kann? Stay tuned; mehr demnächst, in diesem Theater …

Plugwise vs. ELV FS-20 — ein erster Vergleich
Sunday, January 17, 2010, 00:15 - Geeks & Co., Painseeker, Linux, Hausautomation, Technologien
Ich habe ja schon drauf hingewiesen, daß ich mir, in Erweiterung meines Heimautomatisationszoos, auch ein Starter-Set von Plugwise habe kommen lassen. Ich bin nun dazu gekommen, es in Betrieb zu nehmen.

Der rein optische Systemvergleich fällt, wenig überraschend, klar zu Gunsten von Plugwise aus — deren Zwischenstecker (im Bild links) sind nicht nur weniger platzraubend, sie sehen eleganter aus und verfügen insbesondere über die Fähigkeiten zweier ELV-Dinosaurier in einem – kleineren – Gerät: Energie messen und Verbraucher schalten. Für diese Funktion benötigt man bei ELV mir unverständlicherweise zwei Zwischenstecker vom Typ Eisberg … Hinzu kommt – einer der Hauptgründe für mich, nach Alternativen zu suchen –, daß das ELV-System satte 4, in Worten: Vier, Energiemeßzwischenstecker vorsieht — wohlgemerkt in Funkreichweite, d. h. kauft sich ein Nachbar auch dieses System, messen beide jeweils intermittierend den Stromverbrauch des anderen :(

Aber auch die inneren Werte unterscheiden sich deutlich; setzt ELV auf die ISM-Frequenz 868,35 MHz mit ihren uni-direktionalen System (d. h. Schaltvorgänge werden vom Empfänger nicht quittiert; ein typisches FS-20-Gerät ist entweder ein Sender oder ein Empfänger), setzt Plugwise auf neuste Technologie:
Plugwise uses wireless Zigbee 2.4 GHz dynamic MESH technology.
  • reliable and with high quality.

  • 128-bit AES encrypted security.

  • full MESH network support.

  • open international standard (with private protocol).

  • easily extended with additional plugs or more networks.

  • each device has its own unique MAC-address.
Darüber hinaus speichern die kleinen Zwischenstecker von Plugwise auch noch den Verbrauch, sodaß auch ohne kurze Pollintervalle ein Verbrauch sinnvoll aufzeichen- und auswertbar bleibt. Allerdings: augenscheinlich machen sie wirklich nur auf Kurzstrecke, denn die Empfehlung von Plugwise lautet: nicht mehr als 5-10m Abstand zwischen den Plugs lassen; bei Empfangsproblemen einfach mehr Plugs verbauen — und in der Tat, während ich im 1. Stock noch relativ zuverlässig Sensordaten von FS20-Komponenten empfange, ist nach 5m und »um die Ecke« die Verbindung zwischen Plugwise-USB-Stick im PC und dem Plugwise-Zigbee-Netz futsch :(

Preislich ist es auch ein Unterschied; während ein »Circle« genannter Zwischenstecker mit € 36,51 zu Buche schlägt, kosten eine FS20 ST-3 Funk-Schaltsteckdose 22,95 und eine EM 1000-FM Funk-Messstelle Energie gleich 39,95. Neben dem Preisvorteil – für die gleiche Leistung, Schalter- und Empfangsinfrastruktur mal Außen vor gelassen, zahlt man bei Plugwise »nur« 58% dessen, was die beiden Zwischenstecker von ELV kosteten – darf man den technologischen Vorteil nicht außer Acht lassen: den Schaltzustand kann man bei Plugwise erfragen, bei ELV muß man hoffen …

Bevor dieser Text allerding zu sehr nach einem Verkaufstext für Plugwise zu riechen beginnt, hier die Wermutstropfen:
  • Kein deutscher Vertrieb bisher; deutschsprachige Seiten noch dürftiger als die englischsprachigen.

  • Inbetriebnahme des Plugwise-Netzes aus den ganzen »Circle«-Zwischensteckern nur über die proprietäre, nur für MS Windows verfügbare, Plugwise-Software »The Source«.

  • Plugwise verlangt in den Lizenzbedingungen zu »Source« offenbar, daß man seinen Stromverbrauch, »anonym«, über die Plugwise-Software »Source«, an Plugwise übermlttelt. Das finde ich für ein Stück Kaufsoftware, die faktisch ein Dongle für die gekaufte Hardware ist, schon ein reichlich starkes Stück. (Ohne diese Einwilligung zur Datenübermittlung schließt Plugwise den Kunden bockig von weiteren Softwareupdates aus, bis er sich wieder besonnen habe … Und das bei einer niederländischen Software, be-merk-ens-wert.)

  • Das Protokoll der Plugs untereinander und mit dem USB-Stick ist proprietär; das ansich ist nichts schlimmes, zumal die Ansteurung des USB-Sticks teilweise (soweit, daß man schalten und messen kann) rausgefunden wurde.
    Allerdings hat es den Anschein, daß Plugwise als Hersteller des Protokolls anderen Nutzern Steinen in den Weg legen will; auch gab es bislang offensichtlich keinerlei Zugehen seitens Plugwise auf die (Linux-) OpenSource-Heimautomatisation-Community.

  • Zwar sind die Plugs deutlich größer als die digitalSTROM-Lüsterklemmen, haben aber gegenüber jenem hypothetischen System den Vorteil, daß sie am Markt erhältlich sein; Weiterentwicklungen wie »The Stealth« (€ 41,46 lt. Preisliste, also deutlich teurer noch als der einfache Plug, obwohl von der technischen Basis) scheinen aufgrund fehlender Zertifizierung nur in »Projekten« in Zusammenarbeit mit Elektrikern verfügbar zu sein. Dabei würde ich schon gerne die Deckenlampe messen und schalten können …
Das alles vergällt mir die Freude am System ein wenig; nunja, nächster Schritt ist die Anpassung von FHEM für den Plugwise-USB-Stick (»The Stick«), dann geht's ans praktische Erfahrungen sammeln — sicherlich auch, was Zuverlässigkeit und Reichweite angeht …
2 Kommentare 2 Kommentare (1101 mal angeschaut)  | [1 Trackbacks]  | Permalink  |  (2.9/24)

JFTR: VMware Server 1.x und Ubuntu 9.10
Tuesday, January 12, 2010, 16:27 - Geeks & Co., Verschiedenes, Painseeker, Linux
Da meine hübschen VMware-Installationen, genauer: ihre virtuellen Disks, für VirtualBox hätten konvertiert werden müssen (und der erste Versuch ein nicht sehr vertrauen erweckendes File erzeugte), habe ich noch einen Versuch mit VMware gemacht, diesmal aber mit VMware Server 1.0.10.

Und dank des hervorragenden Artikels How To Install VMware Server 1.0.x On An Ubuntu 9.10 Desktop ist es mir gelungen. Tricky und ich habe nun nen Custom-Kernel am Start, aber irgendwas ist ja immer. Anders als VMware Server 2, der anstartete und sich dann ins Knie schoß, rennen meine VMs nun seit einigen Tagen wieder — dank X4 und 4 GB RAM auch flotter als vorher ;)

»nicht genügen Speicherplatz«
Saturday, January 9, 2010, 16:27 - Verschiedenes, Painseeker
[UPD] [INFO] 'C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\Avira\AntiVir Desktop\BACKUP\' benötigt 6150526 Bytes freien Speicherplatz.
[UPD] [INFO] 'C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\Avira\AntiVir Desktop\TEMP\UPDATE\' benötigt 58141692 Bytes freien Speicherplatz.
[UPD] [INFO] 'C:\Programme\Avira\AntiVir Desktop\' benötigt 30008542 Bytes freien Speicherplatz.
[UPD] [ERROR] Update kann nicht ausgeführt werden, nicht genügen Speicherplatz.
[UPD] [INFO] Laufwerk: C:\, freie Kapazität: 62439424 Bytes.
Tja.

Vielleicht sind 58 MB für's Update von ollen Virendefinitionen ja auch etwas oversized?


Zurück Weiter