EibPC Stromzähler-auslesen

[fbirkholz]

Hallo,
nachdem ich jetzt meinen EibPC in Betrieb genommen habe, kommen mir natürlich immer mehr Ideen wo ich diesen verwenden könnte. Folgende Ausgangssituation, ich habe:
1. Einen EibPC mit freier serieller Schnittstelle
2. Eine installierte Hager BKE Datenschnittstelle mit seriellem Anschluss
3. eHz EDL21 Iskra-MT681 von der ENBW
(Der Iskra hat laut Doku folgendes Kommunikationsprotokoll:– SML, gemäß FNN LH 1.0 bzw. MUC-Lastenheft. http://www.vde.com/de/fnn/arbeitsgeb...2010-01-13.pdf)

Nun mein Wunsch/Frage an die EibPC Experten/User:
1. Ist es möglich mit dem EibPC den Iskra über die BKE (zB. mit Readrs232) auszulesen und die Daten auf den EibPC abzulegen, bzw. hat dies vielleicht sogar schon mal jemand gemacht?
2. Wenn diese Abfrage zyklisch läuft, wie sehr lastet das den EibPC wohl aus (ich möchte nicht den EibPC wegen SML- Protokollauslesen in die Knie zwingen)?

Gruß
Franc

[bmx]

IMHO: Vergiß es! Kryptografie und ähnliches ist derzeit nicht mit vertretbarem Aufwand mit dem EibPC machbar.

Gruß,
Bernd

[fbirkholz]

Schade , hatte gehofft mir ein weiteres Gerät zu sparen...

Gruß
Franc

[enertegus]

IMHO: Vergiß es! Kryptografie und ähnliches ist derzeit nicht mit vertretbarem Aufwand mit dem EibPC machbar.

Ist SML nicht eine strukturierte Datenübertragung bzw. was hat das mit Kryptografie zu tun? Ich würde http://www.vde.de/de/fnn/arbeitsgebi...n_SML_1-03.pdf jedenfalls als Datenstruktur deuten. Das schaut vom Grundsatz nicht viel anders aus als das HA7E Zeugs.
Man muss ja nicht gleich das ganze Protokoll implementieren, sondern einen
Teil davon (siehe S. 42 im Link). Schaut aus meiner Sicht machbar aus.

[bmx]

Ok, dann zitiere ich mal aus dem 1. PDF (fnn_lastenheft-edl_1-0_2010-01-13.pdf) des Threaderstellers:

7.1.3 Ausgabe der Datensätze
Jede DSS ersetzt den Impulsgeber, d.h. sie sendet ohne besondere Anfrage überwiegend alle 2 Sekunden
(siehe Kapitel 7.1.5.1, dort Bild 4) eine kurze Mitteilung.

Ich verstehe das so, das alle 2 Sekunden ein Paket von max. 250 Byte über die serielle hereinkommt.

7.1.6 Signatur

Muß nicht genutzt werden, das ist korrekt.

Im von Dir zitierten zweiten PDF findet sich in (30) und (31) die Anforderung einen CRC16 zu bilden. Das sehe ich derzeit im EibPC noch nicht als trivial an. Ihr könntet das natürlich als Funktion implementieren für die nächste Runde ...

Gruß,
Bernd

[enertegus]

Ok, dann zitiere ich mal aus dem 1. PDF (fnn_lastenheft-edl_1-0_2010-01-13.pdf) des Threaderstellers:
Ich verstehe das so, das alle 2 Sekunden ein Paket von max. 250 Byte über die serielle hereinkommt.

Hm, das wäre zu klären.

Im von Dir zitierten zweiten PDF findet sich in (30) und (31) die Anforderung einen CRC16 zu bilden.

Ja, aber die Datenanforderung wäre ja ein bestimmte Nachricht, sodass man die auch vorweg berechnen kann.
Und wenn die Daten eh zyklisch kommen, ist dies nicht mal notwendig.

[Jambala]

Umsetzen läßt sich sicher einiges mit dem EibPC, aber ich würde mir vorher gut überlegen ob dazu die Programmiererfahrung und die Zeit vorhanden ist.

Für mich hört sich das nach einem Thema an, was man mit zusätzlicher Hardware deutlich effizienter umsetzen kann.

Ich mache in letzter Zeit häufiger im nachhinein die Erfahrung viel mehr Zeit in ein Thema zu investieren als ursprünglich gedacht und am Ende bei 90% Realisierung aufgeben zu müssen, weil das letzte Stück Wegesstrecke dann doch gar nicht oder nicht mit vertretbarem Aufwand umsetzbar ist.

Das waren z.B. eine Feiertagsberechnung (mod mit f16), eine stundengenaue Sommer/Winterzeitvariable oder Internet Wetterbericht (Textkodierung/multiple IP Abfragen), die immer im Laufe der Arbeit zu einer "Sackgasse" (Edit: oder besser Aufwandsspirale) wurden.

Vor diesem Hintergrund einfach vorher kritisch überlegen, was vermutlich der für Dich bessere Weg ist.

[MarkusS]

Ein CRC16 ist wirklich keine Rocketscience, zumal die Hauptarbeit (Polynomdivision) im Zähler geleistet wird. Theoretisch (böse) könnte man den CRC auch ignorieren (der hängt eh nur hinten dran am jeweiligen Datum) mit dem Risiko dass bei der Übertragung irgendwo ein Bit gekippt und der Wert falsch ist.

Etwas Gefrickel ist die Implementierung von SML im jeweiligen Zähler, da gibt es etliche Datenfelder die optional sind, ggf. kriegt man nur den Zählerstand (ggf. mehrfach für mehrere Tarife), ggf. kriegt man noch Voltwert(e) (1-3 Stück), Stromwert(e) (1-3 Stück), Leistung(en) (1-3 Stück), Min./Max-Werte u.s.w. Muss man halt überlegen wie weit man das implementieren will.

Last but not least muss man ggf. "richtig" mit den Zählern reden. Einige schicken ihre Daten einfach zyklisch, andere wollen gefragt werden.

Insgesamt denke ich dass die Anzahl der Varianten relativ übersichtlich ist, SML ist eigentlich gut normiert und wie man eine RS232 anprechen kann ist eigentlich auch übersichtlich, ist ja kein verqueres KNX-RS232-Protokoll hintendran.

Die Frage ist halt wie weit die Füsse tragen. Spätestens wenn mehrere Zähler ausgelesen werden sollen kommt man mit einer RS232 nicht mehr weit. Das Konzept sieht vor dass es für mehrere Zähler einen MUC gibt (dann könnte man ggf. den MUC abfragen, muss dann halt die Werte verschiedener Zähler und ggf. Medien (Strom, Gas, Wasser, ...) sortieren oder noch eins drüber hat man einen Konzentrator der mehrere MUCs einsammelt ...

[saft6luck]

Die CRC16 ist nicht schwer, zumal man sie sehr einfach mit einer LUT erschlagen kann.

Die Umsetzung in das Programmiermodell einer SPS und im speziellen des eibPCs kostet dann nur noch etwas "Kreativität" (Arrays in Strings(!) und entsprechende chaotische Zugriffsfunktionen, Schleifen gibt es nicht, etc.).

Der Rest sollte 1:1 wie bei der HA7E gehen. Nicht trivial, aber offensichtlich machbar

Wenn man beim eibPC etwas Sportsgeist zeigt, dann ist eben der Weg das Ziel