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

[Reinerlein]

Hi Boris,

yup, die beiden laufen auf demselben Raspberry Pi. Ich hatte vorher auch localhost in der Config stehen, aber ebenfalls ohne Reaktion.

Meine OWFS.conf sieht folgendermaßen aus:

Code Auswählen Erweitern

# Sample configuration file for the OWFS suite for Debian GNU/Linux.
#
#
# This is the main OWFS configuration file. You should read the
# owfs.conf(5) manual page in order to understand the options listed
# here.

######################## SOURCES ########################
#
# With this setup, any client (but owserver) uses owserver on the
# local machine...
! server: server = localhost:4304
#
# ...and owserver uses the real hardware, by default fake devices
# This part must be changed on real installation
# server: FAKE = DS18S20,DS2405
#
# USB device: DS9490
server: usb = all
#
# Serial port: DS9097
#server: device = /dev/ttyS1
#
# owserver tcp address
#server: server = 192.168.10.1:3131
#
# random simulated device
#server: FAKE = DS18S20,DS2405
#
######################### OWFS ##########################
#
mountpoint = /mnt/1wire
allow_other
#
####################### OWHTTPD #########################

http: port = 2121

####################### OWFTPD ##########################

#ftp: port = 2120

####################### OWSERVER ########################

server: port = localhost:4304

Im Anhang ist mal ein Screenshot von der Weboberfläche von OWFS.

Grüße Reinerlein

[Reinerlein]

Hi Boris,

ich hab jetzt was auf dem Bildschirm.
Ich habe nochmal die fhem-Konfiguration auf localhost umgestellt.

Also:

Code Auswählen Erweitern

define OWServer OWServer localhost:4304
attr OWServer room Server

Jetzt erhalte ich bei "get OWServer devices" eine Liste anzeigt:

Code Auswählen Erweitern

28.B42472040000 DS18B20
81.4FB730000000 DS1420

Aber angelegt wird trotzdem noch nichts. Wird dieses Device noch nicht vom Code erkannt? Da war doch was mit dem Family Code...

Aber wieso stört die Sache mit der IP Adresse eigentlich? Die Verbindung hatte er doch auch so aufgemacht...

Grüße Reinerlein

[Reinerlein]

Hi Boris,

ich habe jetzt auch auf der Konsole diese Fehlermeldungen:

Code Auswählen Erweitern

Use of uninitialized value $payload_data in addition (+) at /etc/fhem/fhem/FHEM/OWNet.pm line 357.
Use of uninitialized value $payload_data in pack at /etc/fhem/fhem/FHEM/OWNet.pm line 359.

Auf jeden Fall ist da jetzt was anders (//images/smiley_icons/icon_smile.gif)

Grüße Reinerlein

[Reinerlein]

Hi Boris,

OK, ich habe gerade herausgefunden, dass dort ja gar keine Devices automatisch erzeugt werden, sondern, dass man sich die angeschlossenen Devices nur ausgeben lassen kann.
Wenn ich mein Device nun anlege, erhalte ich auch die Temperatur des Sensors angezeigt.

Schön. Das klappt nun also. Trotzdem habe ich ab und zu die oben beschriebene Fehlermeldung. Scheint aber nicht maßgeblich zu stören.

Danke für das Modul (//images/smiley_icons/icon_smile.gif)

Grüße Reinerlein

[Reinerlein]

Hi,

nach ein bißchen Betrieb, kann ich noch folgende Fehlermeldungen anbieten:

Code Auswählen Erweitern

Use of uninitialized value $string in substitution (s///) at /etc/fhem/fhem/FHEM/99_Utils.pm line 64.
Use of uninitialized value $string in substitution (s///) at /etc/fhem/fhem/FHEM/99_Utils.pm line 65.
Use of uninitialized value $value in concatenation (.) or string at /etc/fhem/fhem/FHEM/11_OWDevice.pm line 119.
Use of uninitialized value $value in concatenation (.) or string at /etc/fhem/fhem/fhem.pl line 2961.

Diese Meldungen kommen ständig auf der Konsole an...

Die Zeilen 64 und 65 in 99_Utils.pm sind Zeilen der trim()-Funktion:

Code Auswählen Erweitern

$string =~ s/^\s+//;
$string =~ s/\s+$//;

Zeile 119 in 11_OWDevice.pm ist die Zeile in der sub "OWDevice_ReadValue()":

Code Auswählen Erweitern

$hash->{STATE}= "$reading: $value" if($reading eq $getters[0]);

Zeile 2961 in fhem.pl ist die Zeile in der sub "readingsBulkUpdate()":

Code Auswählen Erweitern

my $rv= "$reading: $value";

Da scheint also etwas nicht ganz anzukommen...

Grüße Reinerlein

[Dr. Boris Neubert]

Hallo,

das ist eine Sammelantwort auf eine Reihe von Beiträgen.

Nachdem das Modul nun schon bei einigen in Betrieb ist, habe ich folgende Ergänzungen und Kommentare zur neuesten Version (ab morgen per update verfügbar):

- neue 1-Wire-Geräte: 18B20, 2423, 2413
- wenn man sich mit dem owserver verbindet und keine Fehlermeldung kommt, heißt das nicht, daß es funktioniert
- ein häufiges Problem ist die Spezifikation der server-Anweisung auf dem owserver; am besten hat man zwei, eine mit localhost und eine mit dem FQDN
- falls ein Reading nicht gelesen werden kann, wird es nicht ausgewertet und eine Meldung ins Log geschrieben (unterdrückt undefined-value-Meldungen)

Viele Grüße
Boris

[Martin Fischer]

- neue 1-Wire-Geräte: 18B20, 2423, 2413

ergänzt um:
- 2405, 2406, 2407, 2408

gruß martin

[Dr. Boris Neubert]

Code Auswählen Erweitern

use
einbinden. dazu kannst du den relativen pfad angeben. also statt use FOO::BAR; geht auch ein use ../foo/bar.pm

Habe mich für die minimalinvasive Lösung mit einem neuen Verzeichnis FHEM/lib und use lib::OWNet.pm entschieden.

Ist es richtig, in contrib/fhemupdate.control.fhem die beiden Zeilen

Code Auswählen Erweitern


DIR FHEM/lib
MOV FHEM/OWNet.pm unused


einzutragen?

Fehlt noch was, oder kommt dann FHEM/lib/OWNet.pm mit dem nächsten Update von selbst?

Grüße
Boris

[Martin Fischer]

Code Auswählen Erweitern


DIR FHEM/lib
MOV FHEM/OWNet.pm unused


einzutragen?

Fehlt noch was, oder kommt dann FHEM/lib/OWNet.pm mit dem nächsten Update von selbst?

es fehlt noch ein "UPD FHEM/lib/OWNet.pm". und warum verschiebst du OWNet.pm nach unused anstatt es gleich zu löschen, wenn du eh sicherstellst, dass das "neue" OWNet.pm in FHEM/lib liegt?

die einträge aus dem contrib werden übrigens nicht automatisch in das update übernommen. sonst könnte jeder der schreibrecht auf SVN hat dort "wilde sau" spielen. rudi muss das manuell in bezug auf das update ergänzen.

also bei solch änderungen immer auch rudi informieren, sonst wunderst du dich am nächsten tag, warum update nicht das tut, was du eigentlich wolltest.

gruss

[Martin Fischer]

OWDevice ergänzt um:

1-wire LCD controller by Louis Swart

morgen via update verfügbar...

gruss martin

(siehe Anhang / see attachement)

(siehe Anhang / see attachement)

[Willi]

OWDevice ergänzt um:

1-wire LCD controller by Louis Swart

Super!

[appi]

gratuliere, einfache super Löung. Danke

Remo

[UweH]

Hi Martin,

der Louis Swart-Controller braucht 5V, eine einfache Anbindung des DS2482 bringt aber nur 3,3V auf den Bus. Oder funktioniert das auch so?
Ich habe daher gleich mal einen Plan entworfen...3,3V auf 5V Levelshifter mit angeflanschtem DS2482. Hast Du oder einer der Mitstreiter hier schaltungstechnische Verbesserungsvorschläge?

Gruß
Uwe

[UweH]

Ui...kann man Beiträge nicht editieren? Find keinen Knopp dafür... :o
Wollte doch noch ein Bildchen anhängen.
Grober Entwurf der Platine, ohne Finetuning.

Uwe

[Martin Fischer]

der Louis Swart-Controller braucht 5V, eine einfache Anbindung des DS2482 bringt aber nur 3,3V auf den Bus. Oder funktioniert das auch so?

ich denke mal nein... es ist aber jederzeit möglich einfach in sein 1-wire netz eine stabile 5V versorgung einzuspeisen. aber das sollte dann mal einer erläutern, der davon mehr versteht als ich. mein know-how beschränkt sich auf den nachbau von lösungen.

gruss martin

p.s. "bearbeiten" ist zur zeit disabled. siehe thread im FHEM Forum.