Hallo zusammen,
ich habe mir nun einen Raspberry Pi bestellt und hoffe das er bald ankommt. Diesen möchte ich mit dem SD0 Modul von busware erweitern (Link (//busware.de/tiki-index.php?page=SD0)) um damit Zwischenzähler und Gaszähler mit S0-Schnittstelle auszulesen. Des weiteren verfügt das SD0 Modul noch über einen D0-Bus für den Anschluss eines Smart-Meter.
Da ich noch absolut neu im rPI-Bereich bin, stelle ich hier nun die Frage, wie man die S0-Anschlüsse in FHEM einbindet bzw. die Zähler mit FHEM ausliest. Über welches FHEM-Device/Module würde dies funktionieren?
Vorab schon mal vielen Dank,
Dennis
Hallo Forum,
ich muss diesen Punkt noch einmal aufgreifen und von meinen Problemen berichten.
http://busware.de/tiki-index.php?page=SD0_Installation (//busware.de/tiki-index.php?page=SD0_Installation) habe ich durchgeführt, wobei beim letzten Befehl
avrdude -p atmega1284p -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:SD0.hex
unter Root-Rechten die Fehlermeldung
Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding
erscheint.
Dennoch würde ich sagen, dass die Sache passt.
# uname -a
Linux raspberrypi 3.6.11-busware+ #3 PREEMPT Tue Apr 2 23:37:43 CEST 2013 armv6l GNU/Linux
# hexdump -C /sys/bus/i2c/devices/0-0050/eeprom
00000000 53 44 30 20 56 31 2e 31 20 53 54 41 4e 44 41 52 |SD0 V1.1 STANDAR|
00000010 44 20 32 30 31 33 2d 30 33 2d 30 38 0a ff ff ff |D 2013-03-08....|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000100
Ein Funktionstest via
#minicom -b 38400 -o -D /dev/ttyAMA0
führte nicht dazu, dass ich Impulse nachsweisen konnte. Am Zähler liegt es nicht.
Stattdessen habe ich auch den Weg via http://files.busware.de/RPi/README.raspbian (//files.busware.de/RPi/README.raspbian)
getestet. Mit dem Image sollte es doch out of the box funktionieren, oder?
/var/log/fhem/fhem-2013-04.log medlet jedoch "Cannot init /dev/ttyAMA0, ignoring it"
In der /etc/fhem.cfg findet sich
define COC CUL /dev/ttyAMA0@38400 1234
Ist das korrekt?
Über "minicom -b 38400 -o -D /dev/ttyAMA0" kann ich mit diesem Image die Impulse nachweisen.
Ein apt-get update und upgrade führt nicht zum Erfolg.
Würde mich über eine kurze Unterstützung freuen.
Gruß
Heiko
Hallo BiberFHEM,
ich stehe vor dem gleichen Problem wie du. Hast du dein Problem inzwischen lösen können?
Welche Firmware hast du genommen?
Welches RPi-Image?
Ich kann zwar das SD0-Board flashen, aber ich bekommen keine Signale.
Schon mal vielen Dank für deine Antwort
mfg
Nafti
Gibt es hier neue Erkenntnisse?
Funktioniert es inzwischen?
Hallo Forengemeinde,
auch ich bin auf diesen Thread gestossen, als ich nach dem SD0 Interface von busware und Raspberry suchte.
Auch ich habe derzeit dem Teil noch nichts entlocken können.
Physikalisch wird es vom System erkannt, nachdem ich den von busware vorkompilierten Kernel aufgespielt habe.
# hexdump -C /sys/bus/i2c/devices/0-0050/eeprom
00000000 53 44 30 20 56 31 2e 31 20 53 54 41 4e 44 41 52 |SD0 V1.1 STANDAR|
00000010 44 20 32 30 31 33 2d 30 39 2d 30 33 0a ff ff ff |D 2013-09-03.ÿÿÿ|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ|
Aber dann verliessen sie ihn. Ich weiss derzeit weder, welche Firmware, welche Treiber oder welches Skript man zum Auslesen nehmen kann.
Hat es denn schon jemand aus der FHEM Gemeinde zwischenzeitlich hinbekommen, das Interface anzusprechen und würde mir (uns) auf die Sprünge helfen, wie er das geschafft hat?
Ich danke Euch für Hinweise aller Art, damit ich das Teil ansprechen kann.
Gruß,
Ralf
Hallo,
falls es noch jemanden interessiert, in diesem Forum habe ich ein HowTo gefunden, das SD0 Interface einzubinden und anzusprechen.
http://knx-user-forum.de/knx-eib-forum/24918-raspberry-und-sd0.html
Vielen Dank dort an "Pete2004"
Derzeit hab ich also 2 Möglichkeiten. Mit der Standard Main.hex werden alle Impulse als Ticks vom vzfeeder Perl Skript erkannt und in die hinterlegte DB geschrieben. Heisst aber auch: Läuft das Skript nicht, sind die Ticks bis zum nächsten Start verloren, Pufferung ist nicht.
Man kann sich aber auch eine andere main.hex kompilieren. Wenn ich diese flashe und minicom als Terminal nehme, kann ich mir die Stände der 4 Sensoren auslesen sowie Ticks seit letzter Abfrage etc. Damit könnte man sich auch schön ein Abfrage basteln. Alles in eine Datei wegschreiben alle x Minuten und aus den Spalten/Zeilen die Werte auslesen, die nötig sind. Vor allem sind die Werte auf der SD0 Erweiterung gepuffert, also nicht weg.
Aber unabhängig von dieser Möglichkeit. Kann ich mir denn die Werte, die mir das Perl Skript ausgibt und derzeit in eine MySQL DB pumpt, nicht auch in FEHM ausgeben lassen? Ich müsste ja dann "nur" die DB abfragen. In FHEM bin ich echt noch nicht firm, sorry.
Danke Euch und schönes WE,
Ralf
Hallo zusammen,
ich habe mich mal daran gemacht, die SD0-Erweiterung in FHEM einzubinden. Hierzu habe ich die Firmware_common ein wenig modifiziert und ein Modul für FHEM gebaut. Ein Firmware-File findet sich im Anhang, das zugehörige Modul auch.
Für die fhem.cfg:
define mySD0 SD0 /dev/ttyAMA0@38400
define sd0_1.log FileLog /opt/fhem/log/sd0_1.log mySD0:.*_1.*
attr sd0_1.log logtype text
define sd0_2.log FileLog /opt/fhem/log/sd0_2.log mySD0:.*_2.*
attr sd0_2.log logtype text
define sd0_3.log FileLog /opt/fhem/log/sd0_3.log mySD0:.*_3.*
attr sd0_3.log logtype text
define sd0_4.log FileLog /opt/fhem/log/sd0_4.log mySD0:.*_4.*
attr sd0_4.log logtype text
Die Firmware zählt die Impulse auch wenn FHEM nicht läuft, es sollt also kein Impuls verloren gehen.
Das Ganze funktioniert soweit, ist aber momentan eher auf meine Bedürfnisse angepasst und wenig konfigurierbar (Anpassungen sind im Code zu machen).
Wenn ich Zeit und Lust habe, werde ich da noch ein wenig weiterbasteln.
EDIT: Patch für Firmware angehängt
Gruß
Sven
Hallo Sven,
das ist ja mal klasse von dir. Ich hab mir mit meinen kümmerlichen Fähigkeiten schon den Kopf zerbrochen, wie ich Minicom per Batch ausführen kann, um die Schnittstellen abzufragen.
Visualisieren wollte ich die Ergebnisse dann mit PRTG. Aber nun durch deine Arbeit werde ich mir FHEM wieder auf dem Raspi installieren und schauen, ob ich mit deiner Firmware meine SD0 Erweiterung abfragen lassen kann.
Danke Dir nochmals,
Ralf
Meine SD0 ist unterwegs. Ich habe 3 einphasige S0 Zähler nebst Raspi in die Verteilung eingebaut. Eventuell komme ich am WE zum aufklemmen.
Meine Frage ist, wie kann ich am "dümmsten" das SD0 auslesen und die Werte an den "Haupt Raspi" auf dem FHEM läuft über WLAN übertragen? Also S0 Zähler -> SD0 interface -> Raspi -> WLAN -> FHEM Raspi
Hallo, klinkt interessant was ihr da schreibt. Bei wem läuft das Teil schon zur Erfassung der Zähler z.B. Gas und Strom und welche Leseköpfe setzt ihr ein? Weiterhin würde ich gern wissen wie ihr das ganze dann in FHEM umgesetzt habt um die Zälerstände zu erfassen. Muss ein FW Patch erfolgen oder funktioniert mittlerweile auch die original FW von Busware?
Ich habe hier was interessantes gefunden wo es funktioniert, nur leider nicht mit FHEM.
http://www.s0control.de/s0control-basic/ (http://www.s0control.de/s0control-basic/)
Gruß
cerberus
Hallo,
das Thema SD0 und Fhem scheint ja doch nicht so umfangreich zu sein, wie ich hoffte. Das SD0 hatte ich die Tage nach einem kurz Blick ins Forum bestellt und nun stellt sich so nach und nach raus, dass die Einbindung wohl doch nicht so einfach ist.
Eine offizielle Unterstützung wird es kaum geben, sehe ich das richtig? Mit dem oben gelieferten Modul komme ich leider auch am zweiten Abend nicht weiter, hier ist wohl die Firmware nicht mehr kompatibel.
Nachtrag:
mit der oben beigefügten Firmware startet doch das Logging, mein Fehler ;-).
Mittlerweile betreibe ich drei S0 Geräte an der SD0 Erweiterung, nach und nach mit immer mehr Problemen.
Der Eltako Stromzähler funktioniert dank Halbleiter Auslöung wunderbar, mit einem S0 Wasserzähler begannen die Probleme (Relais prellt). Der Wasserzähler hat aber niemals länger als ein paar hundert Millisekunden angezogen, von daher hat ein 30nF Kondensator gut geholfen.
Ende war jetzt mit einem IN-Z62 Gas-Zähler, welcher je nach Laune auch mal auf dem Relais "stehen" bleibt und auch ansonsten massiv am prellen ist.
Mit Kondensatoren war hier nichts mehr zu machen, es bliebt nur noch eine Modifaktion der Firmware:
Der angehangene Patch entprellt nicht nur einen gerade angezogenen Eingang (wie es ein Kondensator tut), sondern auch den Ausschaltvorgang (bleibt ein Zähler also auf "geschlossen" stehen, wir auch nach einem prellenden "offen" kein Wert mehr gezählt was bei mir bis heute morgen leider so war).
Die Entprellzeit kann in "s0.h" in der Definition "S0_DEBOUNCE" nach Lust angepasst werden, ich habe 250ms gewählt.
Der Patch muss auf die orginalen Quellen angewendet werden, die Änderungen von Gong sind inklusive (diese laufen bei mir seit Ende 2014 absolut problemlos).
Nachtrag:
Firmware fertig kompiliert angehangen.