Neue 1-Wire-Module für Raspberry Pi u.a.

[Dr. Boris Neubert]

Hallo,

ich war der Meinung, der Welt noch einen dritten Satz von 1-Wire-Modulen schenken zu müssen. Die Module benötigen die Serverkomponente von OWFS. Sie hängen nicht mit den anderen 1-Wire-Modulen von FHEM zusammen, deren Namen aus Großbuchstaben bestehen.

Es wird ein OWServer-Gerät definiert, das die Verbindung mit dem owserver herstellt. Für jedes Gerät am Bus wird ein OWDevice-Gerät definiert. OWDevice ist generisch und erkennt automatisch, um welches Gerät es sich handelt. Im Moment werden nur DS18S20-Präzisionsthermometer erkannt. Das OWDevice-Modul läßt sich aber auch mit nur geringen Perl-Kenntnissen sehr einfach um weitere Geräte erweitern - zur Not hier danach fragen.

Eine Besonderheit ist der Proof-of-Concept in OWDevice: ein Gerät meldet dynamisch die passenden Interfaces (bei DS18S20 ist das "temperature"), so daß Benutzeroberflächen darauf reagieren können.

Die Module laufen bei mir auf meinem Raspberry Pi. Details zu Hardware und Software habe ich für Euch auf die Schnelle hier:

http://neubert-volmar.de/Hausautomation/RaspberryPi/index.html

aufgeschrieben. Die Module sind eingecheckt und morgen früh über update erhältlich. Die Dokumentation ist in der commandref.

Viele Grüße
Boris

[Willi]

Hallo Boris,

hört sich gut an. Da ich auch auf OWFS (One Wire FileSystem) schwöre und derzeit eine Kopie der alten Module von Martin einsetze (mit Erweiterung für Dual-Counter), könnte das meine neue Lösung sein.

Sieht vom Code her schön einfach aus.

Ich konnte nicht warten. Daher habe ich es mal sofort probiert.

In der Anleitung steht, dass man OWNet.pm austauschen muss.

Also habe ich folgendes gemacht:
#wget http://owfs.cvs.sourceforge.net/viewvc/owfs/owfs/module/ownet/perl5/OWNet/lib/OWNet.pm
#sudo cp -p OWNet.pm  /usr/local/share/perl/5.10.1/OWNet.pm

Danach habe ich den OWFS-Server in FHEM definiert (IP-Adresse hier beim Posting mal gegen 222.222.222.222 ausgetauscht ;-) :
fhem> define myOWServer OWServer 222.222.222.222:4301
fhem> list myOWServer
Internals:
   DEF        222.222.222.222:4301
   NAME       myOWServer
   NR         382
   STATE      ???
   TYPE       OWServer
   Fhem:
     Protocol   222.222.222.222:4301
Attributes:

fhem>
fhem> get myOWServer devices

Zeigt als leider nichts an.

Auf der Console sieht man dann folgende Fehlermeldungen:

Use of uninitialized value $payload_data in length at /usr/local/share/perl/5.10.1/OWNet.pm line 357.
Use of uninitialized value $payload_data in pack at /usr/local/share/perl/5.10.1/OWNet.pm line 359.

Hast Du eine Idee was ich machen muss?

Wird sich das Problem, dass man OWNet.pm austauschen muss in absehbarer Zukunft erübrigen? Ansonsten wird diese beim nächsten "apt-get upgrade" evtl. wieder überschrieben......

Grüße

Willi

[fladdy]

Super, ich hatte den DS 2482 schon seit Tagen im Warenkorb meines bevorzugten Bauteile-Resellers und habe nur auf diese Info gewartet. Mal sehen, wann der kommt - ich werde das auf jeden Fall testen. War das Löten auf den SMD-Adapter schwierig?

[det.]

Hallo fladdy,

Du löst etwas Kolofonium in Spiritus auf, klebst mit der Lösung den Chip auf der Leiterplatte fest - wartest bis das trocken ist - und lötest dann ein Beinchen nach dem anderen in Ruhe fest, ohne das sich der Chip dabei verschiebt. Dazu brachst Du eine Lötnadel oder eine Lötstation ( je nach Geldbeutel (//images/smiley_icons/icon_wink.gif) und eine Lupe mit Licht ( je nach Alter der Augen)...

[ext23]

Mit dem Festkleben ist ja auch interessant, aber das ist immer so aggressiv das Zeugs ...

Ich mach das mit SMD immer so:

- Das ist ja noch das "Große" SMD, ich tu die Pads immer verzinnen (Bei selbst geätzten Platinen benutze ich immer Fittingslotpaste und schmiere damit die Platine ein, danach den Heißluftföhn rüber halten bis alles flüssig ist, Rest abwischen)

- Vielleicht noch mit etwas Löthonig die Sache beschmieren, oder das aufgelöste Baumharz in Alkohol geht auch

- Dann den Chip Positionieren und die beiden äußersten Beine anlöten, also einfach den Lötkolben nehmen und mit einer normale DICKEN! Lötspitze drauf drücken bis man so ein ganz leichtes absenken des Beines spürt (Ohne Zugabe von Lot). Prüfen ob der Chip richtig sitzt, falls nicht korrigieren.

- Dann den Lötkolben OHNE Zugabe von Lot über alle Beine ziehen (langsam) bis man merkt, dass sich alle Beinchen nach und nach auf die Platine anlegen (Ja man merkt es wirklich, die biegen sich ein µ nach unten und liegen dann auf der Platine richtig auf, je mehr die Pads vorher verzinnt wurden desto stärker der Effekt)

So und das mit der dicken Lötspitze meine ich ernst. Je kleiner eine Lötspitze desto weniger Energie kann diese übertragen weshalb Lötnadeln da auch weniger geeignet sind für diesen Zweck. Und da wir mit Flussmittel arbeiten und ohne Zugabe von weiterem Lot entstehen in der Regel auch keine Brücken, denn das Flussmittel verhindert dies. Danach alles mit einer Lupe prüfen und eventuelle Brücken mit Flussmittel bearbeiten oder eine Nadel nehmen und etwas kratzen.

Also bis jetzt bin ich mit der Methode ganz gut gefahren.

[Dr. Boris Neubert]

Super, ich hatte den DS 2482 schon seit Tagen im Warenkorb meines bevorzugten Bauteile-Resellers und habe nur auf diese Info gewartet. Mal sehen, wann der kommt - ich werde das auf jeden Fall testen. War das Löten auf den SMD-Adapter schwierig?

Freut mich!

Ich habe ein Eck-Pad auf der Platine verzinnt, dann den SMD-Chip draufgesetzt, mit der Pinzette runtergedrückt und das Beinchen mit dem Lötkolben erhitzt und festgelötet. Dann das gegenüberliegende Beinchen aufs Pad gelötet und dann die restlichen Beinchen. Überschüssiges Lötzinn mit Entlötlitze aufgenommen. Ging ganz einfache. Auf www.mikrocontroller.net gibt es auch eine Anleitung.

Die SMD-Adapterplatinen hatte (10 Stück SOIC8 für 1,99 EUR zzgl. 1,50 EUR Versand) aus der eBucht.

Viele Grüße
Boris

[Willi]

Hat jemand das Modul von Boris zum laufen gebracht (siehe meine Probleme im Posting vom 23.12)?


MfG Willi

[joachimm]

Echt klasse Arbeit,

derzeit nutze ich wirklich sehr zufriedenstellend die GPIO4 Lösung von Fladdy da ich derzeit nur Temperatur messe. Kann ich denn damit künftig auch den DS2423 und DS2406 damit betreiben? Vielen Dank.

Joachim

[appi]

Hallo Willi
ich habe die selben Fehler wenn ich auf meinen remoten OWserver  zugreiffe.

Use of uninitialized value $payload_data in length at /usr/local/share/perl/5.10.0/OWNet.pm line 357.
Use of uninitialized value $payload_data in pack at /usr/local/share/perl/5.10.0/OWNet.pm line 359.

gruss
Remo

[appi]

Hallo Boris
mein obiger Beitrag ist falsch. Ich habe es problemlos an meinem Testsystem zu laufen gebracht.

DS18B20 - DS9490 - MR3020 - Wifi - FHEM Server.

Diese Lösung gefällt mir sehr gut. würde gerne noch OWDevices für ein Counter erweitern. Für den DS18B20 habe ich den Family Code in der Zeile 68 auf: if($family eq "28") geändert.
Kannst du mir bitte einen Tip für das einlesen und verarbeiten von Counterdaten DS 2423, als Ersatz für OWCOUNT.pm  geben.

Besten Dank und Grüsse
Remo

[Willi]

Hallo Boris
mein obiger Beitrag ist falsch. Ich habe es problemlos an meinem Testsystem zu laufen gebracht.

Hallo Remo,

was hast Du gemacht, damit der auch von Dir beschriebene Fehler beim Remote-Zugriff per OWFS "Use of uninitialized value $payload_data " nicht mehr auftaucht?

MfG Willi

[appi]

Hallo willi
auf einem anderen System installiert. Wie in der Anleitung geschrieben, habe ich nur das Modul OWNet.pm in das FHEM Verzeichnis kopiert.
Ich vesuche noch den Unterschied zwischen meinem Guruplug mit dem aktiven FHEM und meinem Testsystem zu finden. FHEM kann es nicht sein, da auf beiden Systemen der selbe Stand nach update installiert ist.
auf dem Aktiven sytem sagt perl -v: This is perl, v5.10.0
auf meinem Testsystem perl -v: This is perl 5, version 14, subversion 2 (v5.14.2)

ev. ist das der Unterschied.

gruss
Remo

[Dr. Boris Neubert]

Hallo Boris
mein obiger Beitrag ist falsch. Ich habe es problemlos an meinem Testsystem zu laufen gebracht.

DS18B20 - DS9490 - MR3020 - Wifi - FHEM Server.

Diese Lösung gefällt mir sehr gut. würde gerne noch OWDevices für ein Counter erweitern. Für den DS18B20 habe ich den Family Code in der Zeile 68 auf: if($family eq "28") geändert.
Kannst du mir bitte einen Tip für das einlesen und verarbeiten von Counterdaten DS 2423, als Ersatz für OWCOUNT.pm  geben.

Besten Dank und Grüsse
Remo

Hallo,

in den einzelnen Zweigen der if-elsif-Anweisung ab Zeile 68 von 11_OWDevice.pm können die Familien abgearbeitet werden.

Der Code müßte so aussehen:

Code Auswählen Erweitern


      if($family eq "10" '' $family eq "28") {
        # 18S20 high precision digital thermometer
        unshift @getters, qw(temperature templow temphigh);
        unshift @setters, qw(templow temphigh);
        unshift @polls, qw(temperature);
        $interface= "temperature";
      } elsif($family eq "1D") {
        # 2423 4k RAM with counter
        # hier die Readings zwischen die Klammern eintragen, die zusätzlich zu address alias family id power type gelesen werden koennen
        unshift @getters, qw();    
        # hier die Readings zwischen die Klammern eintragen, die zusätzlich zu alias geschrieben werden koennen
        unshift @setters, qw();
        # hier die Readings zwischen die Klammern eintragen, die regelmaessig automatisch gelesen werden sollen
        unshift @polls, qw();
        #$interface= "count";
      };


Die Readings, die Du lesen und schreiben kannst, kannst Du über die Webseite

Code Auswählen Erweitern

http://DeinOWFSServer:2121

herausfinden, wenn Du zu dem Eintrag von dem Counter browst (28.xxxxxxxxxxxx directory).

Ich bin Dir dankbar, wenn Du den Code wieder hier postest. Ich baue ihn dann ein, damit er per Update an alle verteilt wird.

Viele Grüße
Boris
     

[Dr. Boris Neubert]

Sorry für die späte Rückmeldung, ich habe Deinen Post übersehen.

Sieht vom Code her schön einfach aus.

Das ist Absicht! Das vereinfacht die Wartung enorm.

Auf der Console sieht man dann folgende Fehlermeldungen:

Use of uninitialized value $payload_data in length at /usr/local/share/perl/5.10.1/OWNet.pm line 357.
Use of uninitialized value $payload_data in pack at /usr/local/share/perl/5.10.1/OWNet.pm line 359.

Kannst Du mal schauen, ob /usr/local/share/perl/5.10.1/OWNet.pm den folgenden Tag hat:

Code Auswählen Erweitern

$Id: OWNet.pm,v 1.23 2012/07/17 01:54:09 alfille Exp $

Ich vermute, daß use OWNet.pm das CPAN-Modul zieht. Am besten deinstallierst Du alle OWNet.pm, die Du findest, und kopierst das richtige Modul ins FHEM-Verzeichnis,

Wird sich das Problem, dass man OWNet.pm austauschen muss in absehbarer Zukunft erübrigen? Ansonsten wird diese beim nächsten "apt-get upgrade" evtl. wieder überschrieben......

Ich weiß nicht, wie man CPAN dazu bringt, die aktuelle Fassung des Moduls ins Repository einzustellen. Solange würde ich das Modul weder mit apt-get noch mit cpan holen sondern von Hand.

Viele Grüße
Boris

[Willi]

Sorry für die späte Rückmeldung, ich habe Deinen Post übersehen.

Sieht vom Code her schön einfach aus.

Das ist Absicht! Das vereinfacht die Wartung enorm.

Das sollte auch ein Lob sein! Ich bin ein FAN des KISS-Prinzips.

Kannst Du mal schauen, ob /usr/local/share/perl/5.10.1/OWNet.pm den folgenden Tag hat:

Code Auswählen Erweitern

$Id: OWNet.pm,v 1.23 2012/07/17 01:54:09 alfille Exp $

Ich vermute, daß use OWNet.pm das CPAN-Modul zieht. Am besten deinstallierst Du alle OWNet.pm, die Du findest, und kopierst das richtige Modul ins FHEM-Verzeichnis,

Ja, genau diese Version ist es. Hatte ich ja vorher kopiert. Das Modul scheint wohl ein paar Abhängigkeiten zu haben, die bei Perl v10 so nicht laufen.

Ich werde es jetzt auf einem anderen System mit Perl v14 testen. Auf dem Ubuntu-System wird leider nur v10 bereitgestellt.