Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Das kommt davon, wenn man zu faul ist mal eben die Kernel Version zu prüfen. Irgendwie hatte ich im Hinterkopf, dass Ubuntu 12.10 einen neueren Kernel verwendet.
Makki hatte mir gestern noch einen neuen Kernel für das Wiregate aufgespielt. Danach funktionierte die Kommunikation mit dem Schreib-Lese-Kopf ohne Probleme!
leider kann ich noch nicht berichten, hatte (habe?) wohl probleme mit dem USB-Wandler. Nun habe ich einen neuen und werde testen.
Ein erster Zwischenerfolg:
Den gleichen Zähler, nämlich EMH-EHZ-H benutze ich für die Wärmepumpe mit 2 Tarifen. Irgendwie gab's da wohl ein Sichtproblem zwischen Zähler und Lesekopf, wie sich eher zufällig herausstelle.
Aber nun:
Mirko, dazu bräuchte ich ausser den OBIS
#0701000F0700FF = 7.0 FIXME !!! [0F]0700
#070100010801FF = 1.8.1
noch die
#070100010802FF = 1.8.2
#070100010800FF = ???
Ist das was größeres?
Leider verstehe ich nicht ganz, wie Du da vorgehst.
Die Hex-Obis sind ja im skript nur kommentiert.
Eigentlich ist es ganz einfach. Auch bei SML wird der s.g. OBIS-Code verwendet.
Im SVN hab ich den Link zu Wikipedia hinterlegt das wiederum auf ein die Erklärung der Codes verweist.
Beispiel:
1.8.0 = Gesamtbezug über alle Tarife
1.8.1 = Bezug Tarif 1
1.8.2 = Bezug Tarif 2
usw.
2.8.0 = Einspeisung über alle Tarife
2.8.1 = Einspeisung Tarif 1
usw.
Dann gibt es noch diverse andere Codes für Leistung, Spannung pro Phase usw. hier ist es jedoch vom EVU/Messstellenbetreiber abhängig welche Werte der Zähler liefert. Das EVU bestellt die Zähler meist vorkonfiguriert beim Hersteller.
Im SML Protokoll werden diese Codes nun auch verwendet, das zeigt der Kommentar im Plugin:
#070100010801FF = 1.8.1
Das FIXME! bezieht sich auf einen Wert den ich bei Dir keinem Obis-Code zuordnen konnte. Da würde es nur helfen das mit mehreren Zählern zu vergleichen...bleibt also als Aufgabe für zukünftige Nutzer ... "0F" ist dort irgendwie nicht nachvollziehbar.
So jetzt zum eigentlichen Problem:
Die Werte die Du auslesen willst trägst Du hier ein:
Zählerstände haben hier immer den DPT14 und c=counter.
Ein Momentanwert (Leistung,Spannung etc.) bekommt DPT9 g=gauge
Den Faktor muss man ausprobieren ... das hab ich nun nicht implementiert ... so tief wollte ich mich nicht in SML einlesen.
Leider gibt es bzgl des Test schlechte neuigkeiten.
Datt ding will einfach nich.
Hab mir anstelle des PL2303 Wandler einen FTDI FT232R Wandler getauscht.
Dem neuen Wandler wird nun auch ein Namen (/dev/usbserial-A601NKCL) im WG zugewiesen (udev??)
Das hat Makki erwirkt. Beim PL2303 war dies danach nicht der Fall.
Jedoch nach ca 3h ist das WG mit dem neuen Wandler auch nicht mehr erreichbar. Da hilft nur ein Spannung abschalten.
Ich werde nun mal den cornjob deaktivieren und den Wandler aber stecken lassen. Mal gucken was passiert.
Mirko,
könntest Du mir noch diese Zeile erklären (aufruf cornjob)
/usr/bin/perl /home/user/sml.pl das hier: >/dev/null 2>&1
Das sorgt dafür dass keine Nachricht an root geschickt wird.
Falls ein aktiver email-Dienst im WireGate hinterlegt ist würde Dir das Wiregate sonst jedes mal die Ausgabe per Mail schicken
das beruhigt.
Als nachdem der Wandler nun lange am WG ohne Nutzung ist und das System läuft, kanns nun mehr nur an Cron, dem skript oder irgendwas mit usb liegen.
ich habe ein ähnliches Verhalten. Mein raspberry hängt sich nach ca 4 bis 5 Stunden Scriptlaufzeit einfach auf. Ich hab jetzt schon verschiedenste Sachen getestet:
- Skript darf nur einfach laufen (siehe vorherige Post)
- hab parallel Logging mitlaufen lassen ob die Last nach oben geht - Fehlanzeige, steht auf einmal
- gleiches für den Speicher - ebenso Fehlanzeige,.
Momentan vermute ich, dass es an der tty-Behandlung im Perl liegt, da der Rapsi mit vzlogger und dem gleichen Lesekopf tagelang problemlos läuft.
Ich habe jetzt das Perlscript so verändert, das es als Schleife alle 20 Sekunden die tty liest und die Daten ausgibt ohne den Port zu schließen. Ist quasi ein Daemon geworden.
Der Test läuft seit heute - ich werde berichten.
mangels eigenen SML-Zählers kann da natürlich was im Argen sein. Die Fehlerbehandlung war ja auch nicht implementiert.
Perl + Serielle + Ich sind über Device::SerialPort auch nie richtig Freunde geworden. Generell ist das sehr "gewöhnungsbedürftig" ich hatte mal 3 (drei!) Alix1D die beim gleichen Script anders reagierten (bis hin zum wegfliegen des USB).
Versuch das ganze vielleicht mal so umzustellen wie hier: SourceForge.net Repository - [openautomation] Contents of /tools/d0-IEC62056-meter/iec62056-meter.pl
Ab Zeile 66 bzw. 86 wircd das ganze über "echo socat" gelöst ...
Die Device::SerialPort Geschichte würde ich in Perl als "broken" bezeichnen. Damit habe ich schon Tage verbracht.
@Lio:
Ich vermute da USB-Probleme ... will aber auch nicht ausschließen dass das Script irgendwo mal ins leere läuft.
ja, ist immer noch das gleiche Thema. Ich möchte meinen ED300L auslesen, der spricht ja SML.
Das neue Script scheint das Problem zu lösen, hat die ganze Nacht anstandslos Daten geliefert. Ich mach das mal schick, dann stell ich es hier ein.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar