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 (//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
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 (//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
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?
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)...
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.
Zitat von: fladdy schrieb am So, 23 Dezember 2012 22:25Super, 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
Hat jemand das Modul von Boris zum laufen gebracht (siehe meine Probleme im Posting vom 23.12)?
MfG Willi
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
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
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
Zitat von: appi schrieb am Do, 27 Dezember 2012 09:34Hallo 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
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
Zitat von: appi schrieb am Do, 27 Dezember 2012 09:34Hallo 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:
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
http://DeinOWFSServer:2121herausfinden, 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
Sorry für die späte Rückmeldung, ich habe Deinen Post übersehen.
Zitat von: Willi schrieb am So, 23 Dezember 2012 21:03Sieht vom Code her schön einfach aus.
Das ist Absicht! Das vereinfacht die Wartung enorm.
Zitat von: Willi schrieb am So, 23 Dezember 2012 21:03Auf 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:
$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,
ZitatWird 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
Zitat von: Dr. Boris Neubert schrieb am Do, 27 Dezember 2012 11:03Sorry für die späte Rückmeldung, ich habe Deinen Post übersehen.
Zitat von: Willi schrieb am So, 23 Dezember 2012 21:03Sieht 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.
ZitatKannst Du mal schauen, ob /usr/local/share/perl/5.10.1/OWNet.pm den folgenden Tag hat:
$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.
Zitat von: Willi schrieb am So, 23 Dezember 2012 21:03Hallo Boris,
fhem> define myOWServer OWServer 222.222.222.222:4301
Mir fällt gerade noch auf, daß Du 4301 als Port hast. Ist das so gewollt? Der Standardport ist nämlich 4304.
Grüße
Boris
Hallo,
also ich habe das Modul auch gerade probiert. Im Log erhalte ich bei Verbose 4 dann auch die Ausgabe, dass die Verbindung mit owserver angeblich erfolgreich zustandegekommen ist. Danach ist aber Ruhe auf der Ecke.
Ich erhalte auch mit "get devices" keine Ausgabe, allerdings auch keinerlei Fehlermeldung, einfach stille.
Wenn ich im Filesystem schaue, sehe ich meinen angeschlossenen Temperatursensor. Seitens OWFS sollte also erstmal alles stimmen.
Was kann ich denn noch tun, um das Problem einzugrenzen?
Danke schon mal, sagt das Reinerlein
Hallo Boris
danke für deine Hilfe. Mit wenig perl Erfahrung habe ich mal die folgenden anpassungen gemacht:
******************************************************************************
# http://owfs.sourceforge.net/family.html (//owfs.sourceforge.net/family.html)
my $family= substr($hash->{fhem}{address}, 0, 2);
if($family eq "10") {
# 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 "28") {
# 18B20 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
unshift @getters, qw(counters.A counters.B);
unshift @setters, qw();
unshift @polls, qw(counters.A counters.B);
$interface= "count";
}
elsif($family eq "3A") {
# 2413 1-Wire Dual Channel Addressable Switch
unshift @getters, qw(PIO.A PIO.B);
unshift @setters, qw(PIO.A PIO.B);
unshift @polls, qw(PIO.A PIO.B);
$interface= "state";
}
******************************************************************************
Funktioniert schon mal gut. Nun bräuchte ich noch Hilfe bei der Umrechnung des Zählersstandes in KG und den Zähler Offset (Nullstellung).
Sollte das ins selbe Modul oder bersser in ein eigens nur für den Counter?
gruss
Remo
Zitat von: Reinerlein schrieb am Do, 27 Dezember 2012 13:05Hallo,
Was kann ich denn noch tun, um das Problem einzugrenzen?
Die relevanten Teile Deiner Konfiguration hier posten.
Grüße
Boris
hiya boris,
OWNet.pm besteht im wesentlichen aus POD einträgen. wenn man das auf die reine funktionalität beschrängt, dann könntest du auch den relevanten code direkt übernehmen, so dass das OWNET.pm modul nicht mehr benötigt wird. das würde vorallem den fritzboxen, etc. entgegen kommen.
ich wollte das seinerzeit auch immer in OWFS.pm einbauen aber aus zeitgründen nie umgesetzt.
gruss martin
Zitat von: appi schrieb am Do, 27 Dezember 2012 13:45Funktioniert schon mal gut. Nun bräuchte ich noch Hilfe bei der Umrechnung des Zählersstandes in KG und den Zähler Offset (Nullstellung).
Sollte das ins selbe Modul oder bersser in ein eigens nur für den Counter?
Ich nehme an, daß Du jetzt irgendwelche Werte in den Readings hast.
Ich würde jetzt einen Dummy für KG anlegen und mit einem Notify füttern:
define Counter OWDevice # das ist Dein Counter
define KG dummy # das Gerät enthält die umgerechneten Werte
define Umrechner notify Counter:Counters.A { my $kg= ReadingsVal("Counter","Counters.A",0)*0.815; fhem("set Counter $kg"); }
Wenn der Counter einen neuen Wert nach Counters.A schreibt, wird das notify aufgerufen. Das rechnet das Readings Counters.A in kg um, indem der Zählerstand mit 0,815 multipliziert wird.
Was muss für Nullstellung gemacht werden?
Grüsse
Boris
Zitat von: Martin Fischer schrieb am Do, 27 Dezember 2012 14:40OWNet.pm besteht im wesentlichen aus POD einträgen. wenn man das auf die reine funktionalität beschrängt, dann könntest du auch den relevanten code direkt übernehmen, so dass das OWNET.pm modul nicht mehr benötigt wird. das würde vorallem den fritzboxen, etc. entgegen kommen.
Ich hatte mir auch genau das überlegt sowie die Alternative,
OWNET.pm bei FHEM mitzuverteilen.
Wie ist das denn mit dem Urheberrecht in beiden Fällen?
Zur Not könnte ich den Modulautor Paul H. Alfille fragen. Vielleicht wird OWFS ja auch gleich so angepaßt, daß CUNO unterstützt wird, oder wird der schon?
Grüße
Boris
Zitat von: Dr. Boris Neubert schrieb am Do, 27 Dezember 2012 12:47Mir fällt gerade noch auf, daß Du 4301 als Port hast. Ist das so gewollt? Der Standardport ist nämlich 4304.
Grüße
Boris
Ja, ist richtig. Ich mag keine Standard-Ports. Mein Fehler, dass ich meinen geheimen Port hier gepostet habe..... ;-)
Zitat von: Dr. Boris Neubert schrieb am Do, 27 Dezember 2012 15:07Ich hatte mir auch genau das überlegt sowie die Alternative, OWNET.pm bei FHEM mitzuverteilen.
Wie ist das denn mit dem Urheberrecht in beiden Fällen?
Zur Not könnte ich den Modulautor Paul H. Alfille fragen. Vielleicht wird OWFS ja auch gleich so angepaßt, daß CUNO unterstützt wird, oder wird der schon?
das brauchst du nicht, boris. owfs steht unter GPL 2. und wenn du die entsprechenden codeabschnitte aus
OWNET.pm übernimmst und dann einen hinweis auf das originale
OWNET.pm machst, sollte das eigentlich in ordnung gehen.
OWNET.pm zu verteilen war auch mal meine ursprüngliche idee im zusammenhang mit der neuen struktur. musst du mal in developers suchen, da hatte ich genau für sowas innerhalb von $moddir eigentlich ein verzeichnis vorgesehen. weiss aber eben nicht mehr wie ich das genannt hatte (//images/smiley_icons/icon_smile.gif)
gruss martin
Zitat von: Martin Fischer schrieb am Do, 27 Dezember 2012 15:30OWNET.pm zu verteilen war auch mal meine ursprüngliche idee im zusammenhang mit der neuen struktur. musst du mal in developers suchen, da hatte ich genau für sowas innerhalb von $moddir eigentlich ein verzeichnis vorgesehen. weiss aber eben nicht mehr wie ich das genannt hatte (//images/smiley_icons/icon_smile.gif)
siehe [Beitrag #30972] (wie verlinke ich das?(//images/smiley_icons/icon_wink.gif)
/usr/share/fhem/lib/siteWie wäre es, wenn wir
OWNet.pm nach
$modpath/libschubsen? Wie bringt man perl bei, dort nach Modulen zu suchen?
Grüße
Boris
aus meiner sicht spricht nichts gegen
$modpath/lib
schau mal in 98_fheminfo.pm. da prüfe ich am anfang ob ein bestimmtes perlmodul exisitert. und wenn es dann exisitert dann kannst du es mittels
use
einbinden. dazu kannst du den relativen pfad angeben. also statt use FOO::BAR; geht auch ein use ../foo/bar.pm
oder noch eleganter:
du, rudi oder ich ergänzen den suchpfad für module in fhem.pl. haben wir für die updategeschichte auch schon ergänzt.
gruss martin
p.s.: beitrag einfach über url verlinken..
Hallo Boris,
naja, die Konfiguration ist ja noch nicht so komplex:
define OWServer OWServer 192.168.0.11:4304
attr OWServer room Server
Wenn ich mir das Element mit "list OWServer" anzeigen lasse, erhalte ich folgende Werte:
Internals:
CFGFN /etc/fhem/config/1Wire.cfg
DEF 192.168.0.11:4304
NAME OWServer
NR 134
STATE Initialized
TYPE OWServer
Fhem:
protocol 192.168.0.11:4304
Attributes:
room Server
Das sieht meiner Meinung nach alles gut aus.
Wenn ich jetzt aber ein "get OWServer devices" ausführe, dann erhalte ich einfach keine Ausgabe des Ergebnisses - es wird einfach wieder diesselbe Seite angezeigt. Es wurden auch keine Devices angelegt oder ähnliches. Im Log steht zu dem Vorgang nichts.
Ich habe mal zum Testen bei OWFS den Webserver aktiviert, um zu sehen, ob der die Devices überhaupt auflistet. Das sieht auch gut aus. Es wird auch mein Temperatursensor mit korrektem Wert angezeigt.
OWNet.pm habe ich keine im System installierte, sondern direkt deinen Downloadlink verwendet, und die Datei direkt in das FHEM Verzeichnis gelegt. Dazu war auch vor diesem Download eine entsprechende Fehlermeldung im Log. Nach dem Download des Moduls und der Ablage war im Log keine Fehlermeldung mehr.
Es scheint so zu sein, dass der Aufruf
my @dir= split(",", $owserver->dir()); in der Datei OWServer.pm eine leere Liste liefert. Obwohl ja auch mindestens zwei Elemente vorhanden sind: Der USB Adapter mit seiner ID und eben der Temperatursensor. Oder werden reine IDs von $owserver->dir() weggefiltert? Dann könnte es sein, dass nur ein Element kommt, und dann nicht mehr am Komma gesplittet werden kann...
Danke schon mal für deine Hilfe.
Grüße Reinerlein
Hi nochmal,
ich habe gerade mal eine log-Ausgabe eingebaut:
Log 1, $owserver->dir();
Direkt hinter der normalen Ermittlung (hinter Zeile 186).
Da kommt nur ein Leerstring als Ausgabe im log an...
Vielleicht hilft das ja.
Grüße Reinerlein
Hallo
Ich habe das die OWServer und OWDevice Module erfolgreich in Betrieb genommen. OWFS habe ich nach der Anleitung von Martin Fischer auf seiner Website entnommen und auf einem Dockstar mit Debian Squeeze installiert.
Zurzeit habe ich einen Temperatur Sensor DS1820 angeschlossen welcher naach Änderung der DeviceFamily in OWDevice von 10 nach 28 (Danke Remo!)auch primar funktioniert. Im Log erscheint nach festgelegten Interval folgende Einträge:
2012.12.28 06:26:34 1: DEBUG>temperature,templow,temphigh,address,alias,family,id,power,type
2012.12.28 06:28:14 1: DEBUG>temperature,templow,temphigh,address,alias,family,id,power,type
2012.12.28 06:29:54 1: DEBUG>temperature,templow,temphigh,address,alias,family,id,power,type
2012.12.28 06:31:34 1: DEBUG>temperature,templow,temphigh,address,alias,family,id,power,type
2012.12.28 06:33:14 1: DEBUG>temperature,templow,temphigh,address,alias,family,id,power,type
Das müllt mein Log so ziemlich zu. Ich habe schon probiert den Loglevel auf 5 zu stellen, jedoch bringt das nichts. Gibt es eine Möglichkeit die Einträge zu eliminieren?
Danke für die tollen Module und die Anleitung für OWFS von Martin! Toll (//images/smiley_icons/icon_lol.gif)
Gruss Dani
Hallo Reinerlein,
laufen OWFS und FHEM auf demselben oder verschiedenen Rechnern und wie sieht die OWFS-Konfiguration /etc/owfs.conf aus?
Grüße
Boris
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:
# 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
Hi Boris,
ich hab jetzt was auf dem Bildschirm.
Ich habe nochmal die fhem-Konfiguration auf localhost umgestellt.
Also:
define OWServer OWServer localhost:4304
attr OWServer room Server
Jetzt erhalte ich bei "get OWServer devices" eine Liste anzeigt:
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
Hi Boris,
ich habe jetzt auch auf der Konsole diese Fehlermeldungen:
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
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
Hi,
nach ein bißchen Betrieb, kann ich noch folgende Fehlermeldungen anbieten:
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:
$string =~ s/^\s+//;
$string =~ s/\s+$//;
Zeile 119 in 11_OWDevice.pm ist die Zeile in der sub "OWDevice_ReadValue()":
$hash->{STATE}= "$reading: $value" if($reading eq $getters[0]);
Zeile 2961 in fhem.pl ist die Zeile in der sub "readingsBulkUpdate()":
my $rv= "$reading: $value";
Da scheint also etwas nicht ganz anzukommen...
Grüße Reinerlein
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
Zitat von: Dr. Boris Neubert schrieb am Fr, 28 Dezember 2012 21:39- neue 1-Wire-Geräte: 18B20, 2423, 2413
ergänzt um:
- 2405, 2406, 2407, 2408
gruß martin
Zitat von: Martin Fischer schrieb am Do, 27 Dezember 2012 17:01use
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
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
Zitat von: Dr. Boris Neubert schrieb am Sa, 29 Dezember 2012 11:28
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
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)
Zitat von: Martin Fischer schrieb am So, 30 Dezember 2012 00:21OWDevice ergänzt um:
1-wire LCD controller by Louis Swart
Super!
gratuliere, einfache super Löung. Danke
Remo
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
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
Zitat von: UweH schrieb am So, 30 Dezember 2012 22:08der 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.
Die Geschichte mit der 5V-Einspeisung hab ich schon in Gebrauch, aber da treten (zumindest bei mir) Phänomene auf, die ich messtechnisch erst mal erfassen muss. Ich habe einen kleinen Zwischenstecker, der mir externe 12V und 5V auf den Bus schickt. Mit den 5V hab ich Probleme...ist aber ein anderes Thema...
Hallo zusammen herzlichen Dank für dieses Modul.
Es löst bei mir die Problemem mit dem in OWX (noch) nicht unterstützten USB controller 9490R und das Problem, das mit OWFS keine Counter unterstützt werden.
Dafür schafft es ein neues .... es wird nichts mehr geloggt und die Temepraturen der Sensosren sind auf dem Stand von vor dem Update.
Aber schön der Reihe nach:
System : Ubuntu 12.04 LTS SP1 mit aktuellem FHEM ->Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2372 2012-12-28 10:52:16Z rudolfkoenig $, pid 890)
Definition in fhem.cfg:
define 1WireOWFS OWServer 127.0.0.1:4304
define Speicher3.unten OWDevice 2027A9020000 180
define Speicher3.oben OWDevice A7DBFF020000 180
....
define EG.Elternschlafzimmer OWDevice 4391BC030000 180
define Garage OWDevice B57ACC020000 180
define TotalHaus FileLog /var/tmp/HausTotalTemp-%Y.log EG.Elternschlafzimmer:temperature|EG.Gang:temperature|EG.Kueche:temperature|EG.Kinderzimmer:temperature|EG.Gang:temperature|Garage:temperature|OG.Gang:temperature|OG.Grossmutter.Stube:temperature|OG.Kinderzimmer:temperature|Aussentemperatur:temperature|UG.Weinkeller:temperature|Test:temperature
ein list 1WireOWFS ergibt Internals:
DEF 127.0.0.1:4304
NAME 1WireOWFS
NR 39
STATE Initialized
TYPE OWServer
Fhem:
protocol 127.0.0.1:4304
Attributes:
ein get 1WireOWFS devices ergibt 28.2027A9020000 DS18B20
28.0864BC030000 DS18B20
81.E0CC30000000 DS1420
28.BC44CC020000 DS18B20
28.B0E6A8020000 DS18B20
1D.02D50D000000 DS2423
28.9826A3020000 DS18B20
28.A65CCC020000 DS18B20
28.A4B7FF020000 DS18B20
28.BE87CC020000 DS18B20
28.F180CC020000 DS18B20
28.2206A3020000 DS18B20
28.EA0FA9020000 DS18B20
28.B57ACC020000 DS18B20
28.7A09A9020000 DS18B20
28.BD65CC020000 DS18B20
28.CECCFF020000 DS18B20
28.833DCC020000 DS18B20
28.4391BC030000 DS18B20
28.F10FA9020000 DS18B20
28.85F6A8020000 DS18B20
81.4D8130000000 DS1420
28.8D29A9020000 DS18B20
28.CDB5FF020000 DS18B20
28.5D23A9020000 DS18B20
28.A7DBFF020000 DS18B20
28.5706A3020000 DS18B20
81.0B3930000000 DS1420
wenn ich aber auf einen Temeperatursensor gehe steht dort immer noch der uralte Temeperaturwertvon vor mahr als einer Stunde.
DEF F10FA9020000 180
IODev 1WireOWFS
NAME Speicher1.oben
NR 49
STATE T: 59.5625 L: 10 H: 90 P: 1 A: 0 W: none
TYPE OWDevice
Readings present 1 2012-12-31 22:30:51
temperature 59.5625 (Celsius) 2012-12-31 22:30:51
temphigh 90 2012-12-31 22:30:51
templow 10 2012-12-31 22:30:51
warnings none 2012-12-31 22:30:51
Logs werden auch keine geschrieben (seit Umstellung). Vor Umstellung sah der log wie folgt aus ....
2012-12-31_22:30:52 Speicher1.oben tempraw: 59.5625
2012-12-31_22:30:53 Speicher1.unten tempraw: 51.2500
2012-12-31_22:30:54 Speicher.Vorlauf tempraw: 55.3125
2012-12-31_22:30:55 Speicher.Ruecklauf tempraw: 43.9375
2012-12-31_22:30:56 Heizung.Vorlauf tempraw: 51.4375
2012-12-31_22:30:58 Heizung.Ruecklauf tempraw: 46.1875
2012-12-31_22:30:59 Aussentemperatur tempraw: -0.5000
2012-12-31_22:31:00 Solar tempraw: 20.2500
2012-12-31_22:31:01 Boiler.unten tempraw: 39.9375
2012-12-31_22:31:02 Boiler.oben tempraw: 54.6250
2012-12-31_22:31:03 Heizkessel tempraw: 52.6250
2012-12-31_22:31:44 Speicher3.unten tempraw: 41.5000
2012-12-31_22:31:45 Speicher3.oben tempraw: 45.5000
vor dem Update arbeitetet ich mit OWFS und OWTEMP.
Rechner ist bereits mehrfach neu gestartet.
Jede Hilfe ist willkommen -> Herzlichen Dank!
Gutes neues Jahr an alle!
Gruss Andi
Hi,
Frohes Neues :-)
Also bei mir habe ich bei der Definition den Family-Code noch davor, also z.B.:
define hwr_WTemp OWDevice 28.436C71040000 600
Bist du sicher, dass das vorher mal ging?
Grüße Reinerlein
Hallo zusammen
Ein gutes Neues Jahr an alle und herzlichen Dank für die neuen 1Wire Module!
Zu meiner Ausgangslage:
Ich betreibe OWFS auf einem Dockstar mit Debian Squeeze welcher 100% funktioniert (IP: 192.168.2.15).
FHEM ist auf einem ODROID-X mit Debian Wheezy am rennen seit 2 Monaten ohne Probleme (IP: 192.168.2.22)mit aktueller FHEM-SVN Version.
Wenn ich nun die neuen 1Wire Module am ODROID-X definiere, gehe ich wie folgt vor:
define OWFS OWServer 192.168.2.15:4304
Den Server finde ich dann in "Unsorted", mit Status Initialisiert. Nach einem "save" und anschliessendem "shutdown restart" ist mein Eintrag des OWFS kurz zu sehen, nach etwa 5 Sec ist er dann nicht mehr zu finden in der Weboberfläche.
Im Log (Verbose 3 & 4) habe ich keinen Eintrag der auf einen Fehler hindeutet gefunden.
Um sicherzustellen, dass mein OWFS auf dem Dockstar funktioniert, habe ich einen weiteren Dockstar mit Debian Squeeze (IP: 192.168.2.25) aufgesetzt und danach fhem.deb installiert. Den gleichen Eintrag define OWFS OWServer 192.168.2.15:4304 wieder definiert und "save", "shutdown restart" eingegeben und siehe da, FHEM zeigt den OWServer an. Ich konnte auch alle meine DS1820 anzeigen lassen mit get OWFS devices. Somit ist in meinen Augen bewiesen, dass OWFS funktioniert!
Das Problem ist somit auf meinem ODROID-X zu suchen. Um sicherzustellen, dass alle Module auf dem aktuellen Stand sind, habe ich am ODROID-X update force eingegben. Auch nach dem "shutdown restart" war alles unverändert: OWServer ist ein paar Sekunden zu sehen, danach weg.
Ich habe mit ODROID-X mit "apt-get update" und "apt-get upgrade" aktualisiert, keine Besserung. Die Perlversion ist This is perl 5, version 14, subversion 2 (v5.14.2).
Wer kann mir einen Tip geben wo ich suchen muss um den Fehler zu finden? Danke vielmals für die Hilfe.
Gruss Dani
Hoi Dani
ich habe diesen Fehler auch gemerkt. Ursache auf meinem System das OWX Modul von Pah, welches deinen OWServer löscht.
OWX löschen.....
gruss und ein gutes neues Jahr.
Remo
Genau das war der Fehler!!
Herzlichen Dank Reinerlein! -> die angezeigten Temperaturen waren die letzten Werte von OWTEMP (OWFS). Ich hatte die Gerätenamen nicht geändert. Jetzt funtioniert log und Grafik einwandfrei.
Das Modul macht Spass! Einfach, ohne grosse Abhängigkeiten, OWFS Kompatibel .... was will mann noch mehr :)
Als nächstes kommt der Zähler des Stromverbrauches dran -> DS2423.
Gruss und nochmals Dank
Andi
Hallo Remo
Ein gutes Neues Jahr!
Zitatich habe diesen Fehler auch gemerkt. Ursache auf meinem System das OWX Modul von Pah, welches deinen OWServer löscht.
OWX löschen.....
Genau das war es! :=)
Danke für den Tipp!
Gruss Dani
Hallo
habe auf meinem FHEM 5.3 CVS heute Nachmittsg ein update gemacht. Nun funktioniert OWServer und OWDevices nicht mehr korrekt:
Es können keine Werte mehr gelesen werden.
Im Log steht:
2013.01.01 17:49:36 3: OW.Count.1: reading counters.A did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
2013.01.01 17:49:36 2: dummy set Verbrauch -141.694
2013.01.01 17:49:41 3: OW.SW.1: reading PIO.A did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
2013.01.01 17:49:41 3: OW.SW.1: reading PIO.B did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
2013.01.01 17:49:41 3: OW.temp3: reading temperature did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
Jedoch funktiniert get myRemoteOWServer devices:
10.FBBC18020800 DS18S20 OW.temp2
10.C738A9010800 DS18S20 OW.temp1
28.F68D08040000 DS18B20 OW.temp3
81.5BDA2D000000 DS1420
1D.87860F000000 DS2423 OW.Count.1
Was kann das sein ?
Bin froh wenn es wieder läuft, habe alle OWX Modul abgelöst.
gruss
Remo
Hallo,
ich wollte nur mal kurz Danke sagen. Habe OWFS mit FHEM schon länger im Einsatz, allerdings nicht so elegant. OWX konnte ich nie nutzen da ich keinen kompatiblen Busmaster habe. Dass ich jetzt direkt in FHEM und ohne Umwege meine Switches bedienen kann ist schon sehr cool. Sobald mein Display läuft werde ich sicherlich auch die LCD-Integration nutzen.
Danke an alle die hier so tatkräftig mitgearbeitet haben!
Da bin ich aber platt!! Hab heute das erste mal seit vor Weihnachten wieder mal Zeit gehabt ins Forum zu schauen.
Ist ja unglaublich, was hier "mal eben so" auf die Beine gestellt wird. Danke dafür.
Musste aber erst mal etwas lesen und installieren.
Sachstand:
ich hab die Anleitung von Boris abgearbeitet und nach dieser Anleitung OWFS installiert.
http://wiki.temperatur.nu/index.php/OWFS_with_i2c_support_on_Raspberry_Pi_%28English_version%29 (//wiki.temperatur.nu/index.php/OWFS_with_i2c_support_on_Raspberry_Pi_%28English_version%29)
Das Gute: unter cat /mnt/1wire/10.F6877C010800/temperature
kann ich die Temperatur meines zur Zeit einzigen TempSensors abrufen.
Nur mit fhem hab ich noch meine Probleme.
Weder liefert mir ein "get OWServer devices" eine Antwort, noch sieht man die Temperatur des manuell angelegten Devices.
Auch bei mit stehen dazu im log die o.g. Fehlermeldung aus der fhem.pl line 2961
Was mache ich noch falsch?
VG
Ralf
Zitat von: dougie schrieb am Di, 01 Januar 2013 18:53Was mache ich noch falsch?
Hast Du es mal mit
http://neubert-volmar.de/Hausautomation/RaspberryPi/index.html abgeglichen?
Grüße
Boris
Zitat von: Markus Niemann schrieb am Di, 01 Januar 2013 18:03Dass ich jetzt direkt in FHEM und ohne Umwege meine Switches bedienen kann ist schon sehr cool.
Moin,
das irritiert mich jetzt etwas...direkt hieße ohne Busmaster, aber die ersten Zeilen der Boris'schen Anleitung beziehen sich auf die Ankoppelung der 1-Wire-Devices über einen Busmaster mit dem DS2482-100.
Klär mich mal auf...
Danke und Gruß
Uwe
Hallo Uwe,
mit "direkt" meine ich ohne Umweg z.B. über Scripts. So hab ich es nämlich vorher gemacht. Natürlich habe ich einen Busmaster.
Grüße,
Markus
OK, Danke.
Ich saß hier mit großen Augen :o
Hallo Remo,
Zitat von: appi schrieb am Di, 01 Januar 2013 17:55Im Log steht:
2013.01.01 17:49:36 3: OW.Count.1: reading counters.A did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
2013.01.01 17:49:36 2: dummy set Verbrauch -141.694
2013.01.01 17:49:41 3: OW.SW.1: reading PIO.A did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
2013.01.01 17:49:41 3: OW.SW.1: reading PIO.B did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
2013.01.01 17:49:41 3: OW.temp3: reading temperature did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
auch nach längerer Betrachtung des Codes fällt mir nicht ein, woran es liegen kann.
Kannst Du bitte mal in 11_OWDevice.pm eine Debug-Zeile wie unten markiert einfügen und das Ergebnis aus dem Log hier posten?
###################################
sub
OWDevice_ReadValue($$) {
my ($hash,$reading)= @_;
my $address= $hash->{fhem}{address};
my $value= OWDevice_ReadFromServer($hash, "/$address/$reading");
Debug "/$address/$reading => $value"; ##### DIESE ZEILE
if(defined($value)) {
$value= trim($value) if(AttrVal($hash,"trimvalues",1));
my @getters= @{$hash->{fhem}{getters}};
$hash->{STATE}= "$reading: $value" if($reading eq $getters[0]);
} else {
Log 3, $hash->{NAME} . ": reading $reading did not return a value";
}
return $value;
}
Was gibt Dein OWFS-HTTP-Server an Angaben zu den Geräten zurück (
http://deinserver:2121)?
Wenn es am Code liegen sollte, komme ich vor dem nächsten Wochenende nicht mehr zu einem Fix. Bitte nimm in diesem Fall erst einmal die Module 10_OWServer.pm und 11_OWDevice.pm aus Deinem Backup.
Viele Grüße
Boris
Hallo Boris
mit Debugzeile:
Subroutine OWDevice_Initialize redefined at /opt/fhem/FHEM/11_OWDevice.pm line 35.
Subroutine OWDevice_GetDetails redefined at /opt/fhem/FHEM/11_OWDevice.pm line 54.
Subroutine OWDevice_ReadFromServer redefined at /opt/fhem/FHEM/11_OWDevice.pm line 141.
Subroutine OWDevice_ReadValue redefined at /opt/fhem/FHEM/11_OWDevice.pm line 163.
Subroutine OWDevice_WriteValue redefined at /opt/fhem/FHEM/11_OWDevice.pm line 183.
Subroutine OWDevice_UpdateValues redefined at /opt/fhem/FHEM/11_OWDevice.pm line 194.
Subroutine OWDevice_Attr redefined at /opt/fhem/FHEM/11_OWDevice.pm line 216.
Subroutine OWDevice_Get redefined at /opt/fhem/FHEM/11_OWDevice.pm line 241.
Subroutine OWDevice_Set redefined at /opt/fhem/FHEM/11_OWDevice.pm line 260.
Subroutine OWDevice_Define redefined at /opt/fhem/FHEM/11_OWDevice.pm line 290.
Use of uninitialized value $value in concatenation (.) or string at /opt/fhem/FHEM/11_OWDevice.pm line 169.
2013.01.01 19:53:17 1: DEBUG>/10.C738A9010800/temperature =>
2013.01.01 19:53:17 3: OW.temp1: reading temperature did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
Use of uninitialized value $value in concatenation (.) or string at /opt/fhem/FHEM/11_OWDevice.pm line 169.
2013.01.01 19:53:17 1: DEBUG>/10.FBBC18020800/temperature =>
2013.01.01 19:53:17 3: OW.temp2: reading temperature did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
Use of uninitialized value $value in concatenation (.) or string at /opt/fhem/FHEM/11_OWDevice.pm line 169.
2013.01.01 19:53:17 1: DEBUG>/1D.87860F000000/counters.A =>
2013.01.01 19:53:17 3: OW.Count.1: reading counters.A did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
Use of uninitialized value $value in concatenation (.) or string at /opt/fhem/FHEM/11_OWDevice.pm line 169.
2013.01.01 19:53:17 1: DEBUG>/1D.87860F000000/counters.B =>
2013.01.01 19:53:17 3: OW.Count.1: reading counters.B did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
Use of uninitialized value $value in concatenation (.) or string at /opt/fhem/FHEM/11_OWDevice.pm line 169.
2013.01.01 19:53:22 1: DEBUG>/1D.87860F000000/counters.A =>
2013.01.01 19:53:22 3: OW.Count.1: reading counters.A did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
2013.01.01 19:53:22 2: dummy set Verbrauch -141.694
Use of uninitialized value $value in concatenation (.) or string at /opt/fhem/FHEM/11_OWDevice.pm line 169.
2013.01.01 19:54:06 1: DEBUG>/3A.E24E03000000/PIO.A =>
2013.01.01 19:54:06 3: OW.SW.1: reading PIO.A did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
Use of uninitialized value $value in concatenation (.) or string at /opt/fhem/FHEM/11_OWDevice.pm line 169.
2013.01.01 19:54:06 1: DEBUG>/3A.E24E03000000/PIO.B =>
2013.01.01 19:54:06 3: OW.SW.1: reading PIO.B did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
Use of uninitialized value $value in concatenation (.) or string at /opt/fhem/FHEM/11_OWDevice.pm line 169.
2013.01.01 19:54:06 1: DEBUG>/28.F68D08040000/temperature =>
2013.01.01 19:54:06 3: OW.temp3: reading temperature did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
Use of uninitialized value $value in concatenation (.) or string at /opt/fhem/FHEM/11_OWDevice.pm line 169.
2013.01.01 19:54:06 1: DEBUG>/3A.E24E03000000/PIO.A =>
2013.01.01 19:54:06 3: OW.SW.1: reading PIO.A did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
Use of uninitialized value $value in concatenation (.) or string at /opt/fhem/FHEM/11_OWDevice.pm line 169.
2013.01.01 19:54:06 1: DEBUG>/3A.E24E03000000/PIO.B =>
2013.01.01 19:54:06 3: OW.SW.1: reading PIO.B did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
Use of uninitialized value $value in concatenation (.) or string at /opt/fhem/FHEM/11_OWDevice.pm line 169.
2013.01.01 19:54:06 1: DEBUG>/28.F68D08040000/temperature =>
2013.01.01 19:54:06 3: OW.temp3: reading temperature did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
qwtttpd liefert:
top highest level directory
10.FBBC18020800 10.FBBC18020800 directory
10.C738A9010800 10.C738A9010800 directory
28.F68D08040000 28.F68D08040000 directory
81.5BDA2D000000 81.5BDA2D000000 directory
1D.87860F000000 1D.87860F000000 directory
bus.0 bus.0 directory
uncached uncached directory
settings settings directory
system system directory
statistics statistics directory
structure structure directory
simultaneous simultaneous directory
alarm alarm director
Danke für deinen Support.
gruss Remo
ps: die Umrechnung mit Zähleroffset läuft:
OW.Count.1:counters.A.* { my $kg1 = ((ReadingsVal("OW.Count.1","counters.A","0"))-3490)*0.0406 ;; fhem "set Verbrauch $kg1"}
Zitat von: appi schrieb am Di, 01 Januar 2013 19:57
Use of uninitialized value $value in concatenation (.) or string at /opt/fhem/FHEM/11_OWDevice.pm line 169.
2013.01.01 19:53:17 1: DEBUG>/10.C738A9010800/temperature =>
2013.01.01 19:53:17 3: OW.temp1: reading temperature did not return a value
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 2961.
Hmm, wir sind so schlau als wie zuvor. OWDevice_ReadFromServer() liefert undef zurück. Daran ist aber seit der ersten Version nichts geändert worden. Kannst Du bitte mal fhem stoppen, den owserver neu starten, und dann fhem wieder starten?
Wenn das nicht hilft, dann bitte zurück aufs Backup und weiter am Wochenende.
ZitatOW.Count.1:counters.A.* { my $kg1 = ((ReadingsVal("OW.Count.1","counters.A","0"))-3490)*0.0406 ;; fhem "set Verbrauch $kg1"}
Früher oder später kommt noch was generisches à la
attr OW.Count.1 virtualReadings Verbrauch,(ReadingsVal("OW.Count.1","counters.A","0"))-3490)*0.0406
Viele Grüße
Boris
Ich habe das Problem mit den "did not return a value" auch ...
Folgendes kann ich bei mir aber feststellen:
1: Wenn ich den FHEM Server neu starte sieht es wie folgt aus:2013.01.01 20:26:57 1: Including fhem.cfg
2013.01.01 20:26:57 3: telnetPort: port 7072 opened
2013.01.01 20:26:57 3: WEB: port 8083 opened
2013.01.01 20:26:57 3: WEBphone: port 8084 opened
2013.01.01 20:26:57 3: WEBtablet: port 8085 opened
2013.01.01 20:26:57 3: No I/O device found for Aussenlicht
2013.01.01 20:26:57 3: S0Stromzaehler: I/O device is 1WireOWFS
2013.01.01 20:26:57 3: S0Stromzaehler: reading counters.A did not return a value
2013.01.01 20:26:57 3: S0Stromzaehler: reading counters.B did not return a value
2013.01.01 20:26:57 2: dummy set S0old 0
2013.01.01 20:26:57 2: dummy set S0dif 0
2013.01.01 20:26:57 3: Speicher3.unten: I/O device is 1WireOWFS
2013.01.01 20:26:57 3: Speicher3.unten: reading temperature did not return a value
2013.01.01 20:26:57 3: Speicher3.oben: I/O device is 1WireOWFS
2013.01.01 20:26:57 3: Speicher3.oben: reading temperature did not return a value
...
2013.01.01 20:26:57 3: Heizkessel: reading temperature did not return a value
2013.01.01 20:26:57 3: EG.Kueche: I/O device is 1WireOWFS
2013.01.01 20:26:57 3: EG.Kueche: reading temperature did not return a value
2013.01.01 20:26:57 3: EG.Kinderzimmer: I/O device is 1WireOWFS
2013.01.01 20:26:57 3: EG.Kinderzimmer: reading temperature did not return a value
2013.01.01 20:26:57 3: EG.Gang: I/O device is 1WireOWFS
2013.01.01 20:26:57 3: EG.Gang: reading temperature did not return a value
2013.01.01 20:26:57 3: OG.Grossmutter.Stube: I/O device is 1WireOWFS
2013.01.01 20:26:57 3: OG.Grossmutter.Stube: reading temperature did not return a value
2013.01.01 20:26:57 3: OG.Gang: I/O device is 1WireOWFS
2013.01.01 20:26:57 3: OG.Gang: reading temperature did not return a value
2013.01.01 20:26:57 3: UG.Weinkeller: I/O device is 1WireOWFS
2013.01.01 20:26:57 3: UG.Weinkeller: reading temperature did not return a value
2013.01.01 20:26:57 3: OG.Kinderzimmer: I/O device is 1WireOWFS
2013.01.01 20:26:57 3: OG.Kinderzimmer: reading temperature did not return a value
2013.01.01 20:26:57 3: EG.Elternschlafzimmer: I/O device is 1WireOWFS
2013.01.01 20:26:57 3: EG.Elternschlafzimmer: reading temperature did not return a value
2013.01.01 20:26:57 3: Garage: I/O device is 1WireOWFS
2013.01.01 20:26:57 3: Garage: reading temperature did not return a value
2013.01.01 20:26:59 2: Fronius100 will read from solarview at 192.168.0.1:15000 every 300 seconds
2013.01.01 20:26:59 1: Including ./log/fhem.save
2013.01.01 20:27:00 1: usb create starting
2013.01.01 20:27:00 3: Opening CUL device /dev/ttyACM0
2013.01.01 20:27:00 3: Can't open /dev/ttyACM0: Permission denied
2013.01.01 20:27:00 1: usb create end
2013.01.01 20:27:00 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2372 2012-12-28 10:52:16Z rudolfkoenig $, pid 882)
Danach ist Ruhe und das der Swerver und 1 Wire läuft!
2: Wenn ich die fhem.cfg editiere und speichere, ist es meist (nicht immer!) so, dass die "not return a value" keine Ruhe geben und ich gezwungen bin den Server neu zu starten dann folgt 1:
Mehr jkann ich dazu auch nicht sagen ....
Gruss Andi
Das Problem ist, wenn man (noch) mehr als einen Fehler hat. Wie ich zum Beispiel. ;-)
Nochmal etwas mehr Info von meinem Setup:
Ich verwende meinen RPi mit COC Modul. Dort hängt der DS2482 ja eigentlich auch nur am i2c Bus.
Ich muss dazu sagen, das ich wirklich kein Linus Profi bin, sondern noch ziemlich am Anfang stehe, aber ich hab's hin bekommen OWFS zu kompilieren und zu installieren (ein apt-get install OWFS hatte zwar funktioniert, aber der http und ftp deamon meldete ein FAIL beim Systemstart, also hab ich das wieder removed und das ganze Paket installiert und kompiliert).
Problem: der http und ftp deamon startet immer noch nicht.
Wo kann ich denn nachsehen, woran das liegen könnte??
Was OWFS an sich angeht, so scheint es ja prinzipiell zu laufen, da mein TempSensor ja angelegt wurde, und die Temperaturen in /mnt/1wire vorhanden sind.
Aber ich denke das mein Fehler mit dem fehlenden http deamoin zu tun hat, daher sollte ich erst mal das fixen.
VG
Ralf
Nachtrag: ich hab gerade gesehen, das mir OWFS eine zweite owfs.conf angelegt hat.
Die von Boris habe ich wie beschrieben in /etc/owfs.conf angelegt, aber ich hab auch noch eine in /usr/share/owfs
Welche ist die "richtige"?
VG
Ralf
Hallo
in der ersten Zeile liegt wahrscheinlich das Problem. Die OWDevices haben kein OWServer zugeordnet.
2013.01.02 09:06:15 5: No I/O device or ReadFn found for OW.Count.1
2013.01.02 09:06:15 3: OW.Count.1: reading counters.A did not return a value
2013.01.02 09:06:15 5: Triggering OW.Count.1 (1 changes)
Frege: laufen bei jemandem die Module OWServer und OWDevice noch einwandfrei?
grussRemo
Hallo Remo
Ich benutze die OWServer(SVN:2383) und OWDevice(SVN:2392), diese funktionieren bei mir.
Ich habe jedoch festgestellt, dass wenn ich an FHEM arbeite und mittels "rereadcfg" die Config neu einlese bei mir auch diese Fehler auftreten. Jedoch, wenn ich nach den Änderungen die Module mittels "shutdown restart" neu lade, ist der Fehler weg und die Tempsensoren und Counter funktionieren einwandfrei.
Ich hoffe, dass das auch bei dir helfen wird!
Gruss Dani
...ich hab das gerade mal versucht bei mir nachzuvollziehen.
Ich kann den owfs http deamon manuell mit
/opt/owfs/bin/owhttpd -d /dev/i2c-1 -p 2121
starten, und dann läuft er auch! Also muss der Aufruf entweder defekt sein, oder irgendwelche Rechte unzureichend (?)
Mal sehen ob ich rausfinden kann, wo das bei mir schief läuft.
VG
Ralf
Jetzt bin ich aber von den Socken!
Ich hatte vor den Feiertagen angefangen meine eigenen OWFS-Module zu basteln.
Gut das ich noch nicht sehr weit gekommen bin, bisher liefen nur Temperatursensoren.
Hat sich ja jetzt erledigt - vielen dank für die Module!
Ich werde das gleich mal testen...
Gruß,
Thorsten
Hallo Boris
meine Installation OWServer und OWDevice funktioniert wieder. Ich hatte den folgenden Fehler:
2013.01.02 09:06:15 5: No I/O device or ReadFn found for OW.Count.1
2013.01.02 09:06:15 3: OW.Count.1: reading counters.A did not return a value
Ich habe die Alias der Devices gelöscht und die Devices mit modify neu erstellt/geändert.
Danach wurden die Devices wieder ausdelesen.
Gruss
Remo
Hallo Ralf,
Zitat von: dougie schrieb am Mi, 02 Januar 2013 08:52Ich muss dazu sagen, das ich wirklich kein Linus Profi bin, sondern noch ziemlich am Anfang stehe, aber ich hab's hin bekommen OWFS zu kompilieren und zu installieren (ein apt-get install OWFS hatte zwar funktioniert, aber der http und ftp deamon meldete ein FAIL beim Systemstart, also hab ich das wieder removed und das ganze Paket installiert und kompiliert).
hmm, bei mir lief ein
apt-get install owserver auf dem Raspi sauber durch:
dpkg -l '*owserver*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=====================-===============-===============-================================================
ii owserver 2.8p15-1 armhf Backend server for 1-Wire control
Mit diesem /etc/owfs.conf
! server: server = localhost:4304
server: device = /dev/i2c-1 # i2c port: DS2482-100
http: port = 2121
ftp: port = 2120
server: port = localhost:4304
server: port = raspi:4304
Celsius
läuft es bei mir einwandfrei.
Grüße
Boris
Also bei mir auf dem pi ließ sich OWFS auch ganz normal mit apt-get install owfs installieren....
Als 1-Wire Adapter benutze ich ja ein Ibuttonlink Link45.
Das ist ein RS 232-Adapter aber der funktioniert sogar mit einem RS232 -> USB Adapter an meinem Atom Server problemlos.
Ich das läuft auch unter dem PI. Aber das gehört hier nicht hin.
Aktuell läuft mein 1-wire Zugriff remote über den Atom Server.
Die neuen Module laufen bei mir soweit problemlos.
OWFS rules!
Schöne Lösung, Uwe! Passt! :-)
Ich überlege derzeit eine Art "Standard-Platine" zu layouten, auf der man alle gängigen 1Wire Devices bestücken kann.
Das Ganze mit reichlich Lötbrücken, damit man flexibel nur das verwenden kann/muss, was man auch wirklich braucht.
Das sollte einen grösseren Interessentenkreis erreichen, als nur eine Eizenlanwendung.
Sollte man das mal andenken?
Ich verwende allerdings nur EAGLE und kann daher andere Design-Files nicht verarbeiten. Mein Platinenhersteller ist auch nicht wirklich teuer, überzeugt aber mit guter Qualität.
Würde mich freuen, wenn da mal das allgemeine Interesse bekundet würde.
[sorry for OT]
VG
Ralf
Zitat von: UweH schrieb am So, 30 Dezember 2012 22:08Hi 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
So, moin zusammen :-)
Ich hab mir vorgenommen, das heute ans Laufen zu bekommen.
Irgendwie habe ich irgendwas bei der Installation falsch gemacht, und muss das jetzt fixen. Aber ohne Hilfe werde ich das wahrscheinlich nicht so schnell hin bekommen.
Aber ich fasse nich mal zusammen.
Hardware: RPi mit COC und einem einzelnen TempSensor am COC
Problem: beim Start des RPi bekomme ich zwei Fehlermeldungen, und ich bekomme partout keine Werte vom Temp Sensor.
Starting 1-Wire FTP server: owftpd failed!
Starting 1-Wire HTTP deamon: owhttpd failed!
Ich kann mit
pi@raspberrypi ~ $ sudo /opt/owfs/bin/owhttpd -d /dev/i2c-1 -p 2121
pi@raspberrypi ~ $ sudo /opt/owfs/bin/owftpd -d /dev/i2c-1 -p 2120
beides starten, und dann läuft es auch.
Ein ps -A | grep ow liefert
pi@raspberrypi ~ $ ps -A | grep ow
1930 ? 00:14:24 owserver
2084 ? 00:00:00 owfs
2258 ? 00:00:00 owhttpd
2261 ? 00:00:00 owftpd
Hier der Nachweis, das der Service läuft, und der Sensor erkannt wird.
(siehe Anhang / see attachement)
Meine Zeilen aus der fhem.cfg:
define OWServer OWServer 192.168.1.18:4304
attr OWServer room OW_RPi
define OW_Temp_Test OWDevice 10.069C54020800 120
Meine /etc/owfs.conf
server: device = /dev/i2c-1 # i2c port: DS2482-100
http: port = 2121
ftp: port = 2120
server: port = localhost:4304
server: port = raspberry:4304
Celsius
Auszug aus dem Log-File:
2013.01.03 09:16:46 1: Including /etc/fhem.cfg
2013.01.03 09:16:48 3: tPort: port 7072 opened
2013.01.03 09:16:49 3: WEB: port 8083 opened
2013.01.03 09:16:50 3: WEBphone: port 8084 opened
2013.01.03 09:16:50 3: WEBtablet: port 8085 opened
2013.01.03 09:16:51 3: Opening CUL_0 device /dev/ttyACM0
2013.01.03 09:16:52 3: Setting CUL_0 baudrate to 9600
2013.01.03 09:16:52 3: CUL_0 device opened
2013.01.03 09:16:53 3: CUL_0: Possible commands: BCFiAGMRTVWXefmltux
2013.01.03 09:16:53 3: Opening COC_1 device /dev/ttyAMA0
2013.01.03 09:16:53 3: Setting COC_1 baudrate to 38400
2013.01.03 09:16:53 3: COC_1 device opened
2013.01.03 09:16:53 3: COC_1: Possible commands: mBCFAZOGMRTVWXefltux
2013.01.03 09:16:53 2: Switched COC_1 rfmode to HomeMatic
2013.01.03 09:17:28 3: Opening CUNO_3 device 192.168.1.24:2323
2013.01.03 09:17:29 3: CUNO_3 device opened
2013.01.03 09:17:29 3: CUNO_3: Possible commands: mBCFDiAGMRTVWXOefltuxEcq
2013.01.03 09:17:31 3: OW_Temp_Test: I/O device is OWServer
2013.01.03 09:17:31 3: OW_Temp_Test: reading temperature did not return a value
2013.01.03 09:17:31 1: Including /var/log/fhem/fhem.save
2013.01.03 09:17:33 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2372 2012-12-28 10:52:16Z rudolfkoenig $, pid 1770)
2013.01.03 09:19:31 3: OW_Temp_Test: reading temperature did not return a value
2013.01.03 09:21:31 3: OW_Temp_Test: reading temperature did not return a value
2013.01.03 09:23:31 3: OW_Temp_Test: reading temperature did not return a value
2013.01.03 09:25:31 3: OW_Temp_Test: reading temperature did not return a value
2013.01.03 09:27:31 3: OW_Temp_Test: reading temperature did not return a value
2013.01.03 09:29:31 3: OW_Temp_Test: reading temperature did not return a value
2013.01.03 09:31:31 3: OW_Temp_Test: reading temperature did not return a value
2013.01.03 09:33:31 3: OW_Temp_Test: reading temperature did not return a value
Frage 1: wie/ wo kann ich nachschauen, warum der automatische Start von owftpd und owhttpd fehl schlägt?
Frage 2: was kann noch die Ursache sein, das ich keine Werte vom TempSensor bekomme?
Vielen Dank für eure Hife!! :-)
VG
Ralf
Mist, vergessen.... auf meinem RPi läuft auch noch ein proftpdraspberrypi ftp server... kann es sein, das der einen Konflikt verursacht?
Hallo Ralf,
du benötigst für die Verbindung mit FHEM nur die Komponente "owserver" von OWFS. Alle anderen, also owhttp usw werden nicht gebraucht. Jetzt ist die Frage welchen Port owserver bei dir nutzt. Mit dem Befehl "sudo netstat -tulpn" kannst du das recht einfach herausfinden, bei mir sieht die Ausgabe so aus:
tcp 0 0 0.0.0.0:[u]45678[/u] 0.0.0.0:* LISTEN 15534/owserver
Bei mir läuft owserver auf Port 45678, also sieht die definition in fhem folgendermassen aus:
define owserver OWServer localhost:45678
Vielleicht hilft dir das weiter.
Grüße,
Markus
Hallo Boris,
bei mir sieht das so aus:
dpkg -l '*owserver*'
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Enpackt/halb konFiguriert/
Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name Version Architektur Beschreibung
+++-=====================-===============-===============-================================================
ii owserver 2.8p15-1 armhf Backend server for 1-Wire control
Was sagt mir das? Alles ok oder kaputt? Werd daraus nicht schlau... :(
Mein owserver wird definitiv gestartet, sehe ich auch beim Booten des Raspi, ich kann aber mit i2cdetect keine angeschlossenen Devices erkennen. Einmal hat bisher das Auslesen der Devices über den http-zugriff geklappt, seitdem werden aber diese beiden Devices auch angezeigt, wenn ich sie vom Bus trenne...
Ich hab jetzt mal testweise zwei DS18B20, zwei DS2413, einen DS2450 und einen LCD-Controller dran...wird nichts erkannt.
Gruß
Uwe
Danke dir Markus,
ja, ich glaube das hilft. Ein "sudo netstat -tulpn" sagt bei mir
1930/owserver
tcp 0 0 0.0.0.0:8083 0.0.0.0:* LISTEN
Und da ich meinen OWServer mit Port 4304 definiert habe, kann da wohl auch nichts kommen.
Das brächte mich dann zu der Frage, wie ich die Komponenten owhttpd und owftpd wieder deaktiviere (obwohl es mich schon interessiert hätte, was bei mir schief läuft), und wo ich den Port des owservers definieren kann?
VG
Ralf
Zitat von: Markus Niemann schrieb am Do, 03 Januar 2013 10:22Hallo Ralf,
du benötigst für die Verbindung mit FHEM nur die Komponente "owserver" von OWFS. Alle anderen, also owhttp usw werden nicht gebraucht. Jetzt ist die Frage welchen Port owserver bei dir nutzt. Mit dem Befehl "sudo netstat -tulpn" kannst du das recht einfach herausfinden, bei mir sieht die Ausgabe so aus:
tcp 0 0 0.0.0.0:[u]45678[/u] 0.0.0.0:* LISTEN 15534/owserver
Bei mir läuft owserver auf Port 45678, also sieht die definition in fhem folgendermassen aus:
define owserver OWServer localhost:45678
Vielleicht hilft dir das weiter.
Grüße,
Markus
Ahh, mist. Zeilenumbruch... hier die korrekte Zeile:
tcp 0 0 127.0.0.1:4304 0.0.0.0:* LISTEN 1933/owserver
Und jetzt wird auch hier LICHT!!!! :D
(siehe Anhang / see attachement)
Ich hab die Ddefinition des OWservers in der fhem.cfg abgeändert, weil da war die IP vom RPi eingetragen.
Mit localhost funktioniert das sofort auf Anhieb!!
define OWServer OWServer localhost:4304
attr OWServer room OW_RPi
define OW_Temp_Test OWDevice 10.069C54020800 120
Saubere Sache!!
Boa, Boris, ... glaube damit machst du ne Menge Leute glücklich!! :-)
VG
Ralf
So weit war ich auch schon, nur wenn ich andere Devices anstöpsele, kommt das System offenbar aus dem Takt...
Was passiert, wenn Du einen anderen DS1820 ansteckst? Kannst Du mit "i2cdetect -y 1" auf der Konsole die Devices auslesen?
Gruß
Uwe
...weiss nicht ob ich die Frage beantworten kann ;-)
Ich hab gerade mal hinter mich gegriffen, und einen DS2413 gegriffen und angeklemmt, und das scheint er nicht zu mögen.
Hier die Response von meinem RPi:
pi@raspberrypi ~ $ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
Es ist in der Tat so, das ich dann keine Antwort mehr bekomme. Auch nicht vom Temp-Sensor. Klemme ich den 2413 wieder ab, kommen auch wieder Temperaturen vom Sensor.
Die Antwort auf i2cdetect hat sich währenddessen nicht verändert.
VG
Ralf
Deckt sich mit meinen Erfahrungen. Du bekommst aber wenigstens auf i2cdetect eine Antwort. Das hat bei mir noch nie funktioniert. Einmal wurden zwei Devices erkannt und dann nie wieder. Als wenn die festgetackert in einer Datei eingefroren wären...
Da ich mit meiner geringen Erfahrung ja nicht genau weiss, was ich hier tue, nur noch der Hinweis:
Ich hab inzwischen die packages owftpd und owhttpd deinstalliert.
owfs liess sich nicht deinstallieren, weil es laut apt-get gar nicht installiert ist... hm....
Also hab ich das startscript aus init.d und mit update-rc.d entfernt. Seit dem läuft nur noch owserver. Hoffe das war richtig so; zumindest hab ich jetzt keine Fehlermeldungen mehr während des Systemstarts.
VG
Ralf
Hallo
nun läuft bei mir das Modul (OWDevice)von Boris perfekt.
Frage: Wie kann ich die Kommastellen der Temp. Sensoren auf eine Stelle beschränken?
gruss und danke für dieses Super Modul.
Gruss
Remo
Zitat von: appi schrieb am Do, 03 Januar 2013 14:00Frage: Wie kann ich die Kommastellen der Temp. Sensoren auf eine Stelle beschränken?
Neu in diesem Theater dank Rudi (ab morgen im Update): Attribut stateFormat
Grüße
Boris
Nachtrag zu meinen Tests heute und Korrektur meiner obigen Angaben. ;)
Das Modul von Boris funktioniert auch mit mehreren Temp Sensoren einwandfrei, und sogar ein DS2413 wird erkannt.
Hatte heute vormittag etwas falsch angeschlossen.
Nächster Schritt wäre dann die Ports des 2413 zu definieren?
Nochmals vielen Dank und sorry wegen der vielen Anfängerfragen.
VG
Ralf
(siehe Anhang / see attachement)
So jetzt habe ich auch mal was...
Ich habe einige 1-Wire-Komponenten definiert.
# Verbindung zum OWSERVER über die neuen Module von Boris Neubert
define myOWServer OWServer 192.168.178.2:3030
#1-Wire Gerätedefinitionen
define temp_wohnzimmer OWDevice 28.5AC1DF000000 300
attr temp_wohnzimmer icon icoTempHausEG
attr temp_wohnzimmer room Wohnzimmer
define temp_brauchwasser OWDevice 10.4B0AE5000800 300
attr temp_brauchwasser icon icoTempWasser
attr temp_brauchwasser room Heizung
define temp_mischer_vorlauf OWDevice 28.69BBDF000000 300
attr temp_mischer_vorlauf icon icoTempHeizung
attr temp_mischer_vorlauf room Heizung
define ds2423_zaehler_strom OWDevice 1D.601209000000 300
define ds2408_relais OWDevice 29.568E01000000 300
define ds2438_sensor_zisterne OWDevice 26.200776000000 300
define ds2405_schalter_lueftung_aus OWDevice 05.10062A000000 10
Die Abfrage der Sensoren funktioniert soweit, allerdings hat ein Sensor wohl Schizophrenie?
(siehe Anhang / see attachement)
Der Temperatursensor zeigt auch die readings vom DS2408???
Im log tauchen ständig solche Zeilen auf:
2013.01.04 06:10:32 3: ds2408_relais: reading PIO.7 did not return a value
2013.01.04 06:13:54 3: temp_wohnzimmer: reading temperature did not return a value
2013.01.04 06:13:54 3: temp_brauchwasser: reading temperature did not return a value
2013.01.04 06:13:54 3: temp_mischer_vorlauf: reading temperature did not return a value
2013.01.04 06:13:54 3: ds2408_relais: reading PIO.0 did not return a value
Im Anhang nochmal meine komplette fhem.cfg und ein Auszug aus den logs
Ist das ein Bug oder ein Feature?
Habe ich etwas falsch gemacht?
Die Module sind vom 2013.01.02
Danke und gruß,
Thorsten
Feedback: Seit dem Update heute Morgen wird der TempWert zwar einwandfrei ermittelt und gelogged, aber im Frontend nicht mehr angezeigt.
Das Attribut stateFormat habe ich nicht verwendet. :-)
VG
Ralf
Zitat von: Dr. Boris Neubert schrieb am Do, 03 Januar 2013 19:28Zitat von: appi schrieb am Do, 03 Januar 2013 14:00Frage: Wie kann ich die Kommastellen der Temp. Sensoren auf eine Stelle beschränken?
Neu in diesem Theater dank Rudi (ab morgen im Update): Attribut stateFormat
Grüße
Boris
Ich habe jetzt mal ein update gemacht.
Die Meldugen aus dem log sind jetzt verschwunden.
Allerdings wird im State kein wert mehr angezeigt.
Und das mein Brauchwassertemperaturfühler immer noch meint er wäre ein DS2408 - hat sich auch nicht geändert...
Ich schaue mir das zuhause mal genauer an...
Stunden später...ich bekomme es einfach nicht hin. Alles lt. Anwiesungen eingerichtet, owserver läuft und egal, ob ich die Temperatursensoren anklemme oder nicht, es werden nur beiden einmal erkannten Devices angezeigt, sowohl im Frontend als auch per http. Auch der http-Zugriff mit unterschiedlichen Browsern bringt immer dieselbe Anzeige. Irgendwo sind diese IDs festgetackert und ändern sich nicht mehr.
Hat dazu jemand eine Idee?
Ist auch egal, ob ich den COC-1wire oder mein i2c/1wire-Interface benutze.
Gruß
Uwe
Mit dem folgenden Setting wird wieder der State (eine Dezimalstelle hinter dem Komma) geschrieben:
attr tempDevice stateFormat { sprintf("T: %.1f",ReadingsVal("tempDevice","temperature",0)) }
"tempDevice" dabei einfach durch den Namen des Devices ersetzen.
Hallo Uwe,
die beiden Eintrage, die Du siehst sind keine einmal erkannten physikalischen Devices. Das sind die FAKE-Eintrage, die durch die Zeile
# random simulated device
server: FAKE = DS18S20,DS2405
in der /etc/owfs.conf entstehen. Wenn ich die Zeile nicht auskommentiere, habe ich die auch (siehe Anhang).
(siehe Anhang / see attachement)
Zitat von: UweH schrieb am Fr, 04 Januar 2013 13:02Stunden später...ich bekomme es einfach nicht hin. Alles lt. Anwiesungen eingerichtet, owserver läuft und egal, ob ich die Temperatursensoren anklemme oder nicht, es werden nur beiden einmal erkannten Devices angezeigt, sowohl im Frontend als auch per http. Auch der http-Zugriff mit unterschiedlichen Browsern bringt immer dieselbe Anzeige. Irgendwo sind diese IDs festgetackert und ändern sich nicht mehr.
Hat dazu jemand eine Idee?
Ist auch egal, ob ich den COC-1wire oder mein i2c/1wire-Interface benutze.
Gruß
Uwe
Das witzige ist ja, dass sie auch in meiner owfs.conf auskommentiert sind... :o
Tja, wenn der owserver meine angeschlossenen Sensoren am COC erkennen würde, dann könnte ich auch aml probieren, ob das i2c-Interface funktioniert. Hab's heute mal zusammengeschraubt...
Zitat von: dougie schrieb am Fr, 04 Januar 2013 12:05Feedback: Seit dem Update heute Morgen wird der TempWert zwar einwandfrei ermittelt und gelogged, aber im Frontend nicht mehr angezeigt.
gefixt und eingecheckt und morgen ueber Update verfuegbar.
Gruesse
Boris
Funktioniert einwandfrei! Danke Boris!
VG
Ralf
Hi Boris,
wäre es möglich ein model-Attribut innerhalb von OWDevice automatisch zu setzen (z.B. DS18B20)?
Grüße Fladdy.
Hej hej,
kleine Frage:
Seit einigen Wochen bekomme ich bei meinen Updates immer folgende Fehlermeldung:
Housekeeping:
==> deleting /usr/lib/fhem/FHEM/OWNet.pm failed: No such file or directory
Hab schon probiert, das File per touch anzulegen oder auch das controls_fhem.txt zu löschen... aber die Meldung kommt immer wieder.
Jemand eine Idee, was ich dafür/dagegen tun kann? :-)
Thx a lot!
Greetz,
Gerhard
Zitat von: Mr. P schrieb am Sa, 05 Januar 2013 11:31Seit einigen Wochen bekomme ich bei meinen Updates immer folgende Fehlermeldung:
Housekeeping:
==> deleting /usr/lib/fhem/FHEM/OWNet.pm failed: No such file or directory
Jemand eine Idee, was ich dafür/dagegen tun kann? :-)
Nichts kannst Du dagegen tun. Bis wir es wieder aus dem Update-Control ausbauen kannst Du es ignorieren.
Viele Grüße
Boris
Zitat von: fladdy schrieb am Sa, 05 Januar 2013 10:34wäre es möglich ein model-Attribut innerhalb von OWDevice automatisch zu setzen (z.B. DS18B20)?
Ja. Baue ich gelegentlich mal ein.
Grüße
Boris
Hallo ich habe meine Temp-Sensoren alle soweit zugeordnet und Lauft auch soweit gut.
Jetzt mein Problem ich mochte gerne mein Vorlauf und Rücklauf Heizung auf
Floorplan anzeigen so zum Beispiel 40,3C aber wenn ich es jetzt einfüge sieht es so aus.
Vorlauf
temperature: 26.125
kann einer Helfen bitte?
Gruß
Martin
Zitat von: Martin schrieb am Sa, 05 Januar 2013 18:36Jetzt mein Problem ich mochte gerne mein Vorlauf und Rücklauf Heizung auf
Floorplan anzeigen so zum Beispiel 40,3C aber wenn ich es jetzt einfüge sieht es so aus.
Vorlauf
temperature: 26.125
kann einer Helfen bitte?
stateFormat ist Dein Freund.
Viele Grüße
Boris
Ja habe ich irgendwo was von gelesen aber nicht wie ich damit umgehen muss?
Kannst du mir bitte eine Starthilfe geben wie ich das machen muss.
Habe da nicht wirkliche was gefunden damit ich es verstehen kann.
Gruß
Martin
ZitatKannst du mir bitte eine Starthilfe geben wie ich das machen muss.
Habe da nicht wirkliche was gefunden damit ich es verstehen kann.
attr myDevice stateFormat temperature °CVielleicht mache ich das OWDevice noch ein bisschen schlauer, damit es selbst anhand der Interfaces die Darstellung erstellt.
Viele Grüße
Boris
Super Danke für die schnelle Hilfe hat auch geklappt .
ich hatte aber noch mal gesucht im Netz nach stateFormat es wird leider nicht erklärt.
Auch nicht auf den Fhem Seiten schade eigentlich für Anfänger wie mich.
Gruß
Martin
Hallo
Ich habe diesen Beitrag (//knx-user-forum.de/special/Digitales%20Schluesselbrett%20mit%201-Wire%20iButtons/) mit dem iButton Schlüsselbrett gelesen, welches ich gerne umsetzen möchte.
Frage dazu: Werden die iButton (DS1990A) von OWServer und OWDevice unterstützt?
Danke!
Gruss Dani
Zitat von: Martin schrieb am So, 06 Januar 2013 00:05ich hatte aber noch mal gesucht im Netz nach stateFormat es wird leider nicht erklärt.
Auch nicht auf den Fhem Seiten schade
Es ist erklärt und Du hast es nicht gefunden.
In der commandref, der zentralen Doku, ist es erklärt, siehe hier:
http://fhem.de/commandref.html#attr.
Viele Grüße
Boris
Zitat von: eppi schrieb am So, 06 Januar 2013 07:45Frage dazu: Werden die iButton (DS1990A) von OWServer und OWDevice unterstützt?
OWDevice ist ein generisches Modul und unterstützt alle Geräte, die OWFS unterstützt. Zur Erkennung ist nur eine kleine Ergänzung im Modul nötig. Ob OWFS die iButtons unterstützt, liest Du auf deren Webseite nach.
Viele Grüße
Boris
Hallo Boris
ZitatOb OWFS die iButtons unterstützt, liest Du auf deren Webseite nach
gesucht, gefunden (//owfs.org/index.php?page=ds1990a) :=)
Dann werde ich mal die Bestellung absetzen.
Danke und Gruss Dani
Hallo 1wire-Mitstreiter,
durch tatkräftige Unterstützung von fladdy ist es gelungen, auch meinen widerspenstigen Raspi dazu zu bringen, über i2c mit den angeschlossenen Sensoren/Devices zu kommunizieren.
Nachdem auch ein komplett neues Image und Update und und und den gleichen Erfolg brachte (nämlich nix), hatte fladdy dann offenbar eine Eingebung.
Ich fasse den Mailverkehr hier Ausschnittweise zusammen, damit andere nicht auch verzweifeln...
pi@raspberrypi ~ $ sudo i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
Aber, wenn ich statt der 0 die 1 übergebe:
pi@raspberrypi ~ $ sudo i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
Es existieren zwei Devices auf einem Raspberry für I2C:
pi@raspberrypi ~ $ ls /dev/i2*
/dev/i2c-0 /dev/i2c-1
Jetzt musst Du aber noch Deine owfs.conf anpassen und aus
server: device = /dev/i2c-1 # i2c port: DS2482-100
server: device = /dev/i2c-0 # i2c port: DS2482-100
machen.
Grund für zwei Devices:
You may have noticed the driver registers two I2C busses. One is the the BSC0 bus that has pins on the GPIO connector, the other is BSC1 which has pins on the camera connector.
Warum die jetzt vertasucht sind? Keine Ahnung - vielleicht liedt es an der Version der Kernel-Treiber oder am der Raspberry Hardware-Revision (256MB erste/zweite Generation bzw. 512MB).
Und hier die Lösung:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=37&t=20146 (//www.raspberrypi.org/phpBB3/viewtopic.php?f=37&t=20146)
Damit funktioniert es nun.
Weiterer positiver Effekt: Ich konnte mein i2c-Interface testen und auch das läuft. Damit kann man den i2c-Bus ohne COC nutzen.
Details dazu bald in der Bastelecke (neben den anderen lustigen kleinen Basteleien von mir, die da schon zu sehen sind ;-) ).
Wäre jemand so nett folgende Ergänzung in die 11_owdevice.pm einzupflegen?
} elsif($family eq "20") {
# 2450 - 1-Wire Quad A/D Converter
# added by markus niemann
unshift @getters, qw(volt.A volt.B volt.C volt.D);
unshift @setters, qw();
unshift @polls, qw(volt.A volt.B volt.C volt.D);
#$interface= "state";
volt.A - volt.C sind die für mich interessanten Daten (Strom-/Spannungsdaten eines 1-Wire Hub von eservice-online), ggf lohnt es sich aber weitere auszulesen:
/20.9E5810000000/8bit
/20.9E5810000000/CO2
/20.9E5810000000/PIO.ALL
/20.9E5810000000/PIO.A
/20.9E5810000000/PIO.B
/20.9E5810000000/PIO.C
/20.9E5810000000/PIO.D
/20.9E5810000000/address
/20.9E5810000000/alarm
/20.9E5810000000/alias
/20.9E5810000000/crc8
/20.9E5810000000/family
/20.9E5810000000/id
/20.9E5810000000/locator
/20.9E5810000000/memory
/20.9E5810000000/pages
/20.9E5810000000/power
/20.9E5810000000/r_address
/20.9E5810000000/r_id
/20.9E5810000000/r_locator
/20.9E5810000000/set_alarm
/20.9E5810000000/type
/20.9E5810000000/volt.ALL
/20.9E5810000000/volt.A
/20.9E5810000000/volt.B
/20.9E5810000000/volt.C
/20.9E5810000000/volt.D
/20.9E5810000000/volt2.ALL
/20.9E5810000000/volt2.A
/20.9E5810000000/volt2.B
/20.9E5810000000/volt2.C
/20.9E5810000000/volt2.D
hallo markus,
Zitat von: Markus Niemann schrieb am So, 06 Januar 2013 12:27Wäre jemand so nett folgende Ergänzung in die 11_owdevice.pm einzupflegen?
} elsif($family eq "20") {
# 2450 - 1-Wire Quad A/D Converter
# added by markus niemann
unshift @getters, qw(volt.A volt.B volt.C volt.D);
unshift @setters, qw();
unshift @polls, qw(volt.A volt.B volt.C volt.D);
#$interface= "state";
ich war vor einer woche schon kurz davor das einzuchecken aber hatte dann nochmal mit boris gesprochen.
das design von OWDevice ist (aus meiner sicht) noch nicht ganz rund. hintergrund ist nämlich:
PIO.A ... PIO.D PIO.ALL
read-write, yes-no
Pins used for digital control. 1 turns the switch on (conducting). 0 turns the switch off (non-conducting).
Control is specifically enabled. Reading volt will turn off this control.entscheidend dabei ist der letzte satz. bei volt bzw. volt2 ist es umgekehrt:
volt.A ... volt.D volt.ALL
8bit/volt.A ... 8bit/volt.D 8bit/volt.ALL
read-only, floating point
Voltage read, 16 bit resolution (or 8 bit for the 8bit directory). Range 0 - 5.10V.
Output ( PIO ) is specifically disabled.da jede abfrage des busses aber auch gleichzeitig mit einer last verbunden ist, sollte das erst im modul geregelt werden.
wenn nämlich alle readings in @gettes und @polls aufgenommen werden, dann erfolgen auch überflüssige abfragen. es gibt noch ein paar weitere devices, die sich so verhalten.
ich wollte da nun nicht in boris' codebasis eingreifen, aber boris wollte sich gedanken dazu machen. es gilt ebenso noch eine saubere lösung umzusetzen, wie ein auslesen von "unterverzeichnissen" also z.b. "HIH3600/humidity" sauber in den readings dargestellt werden soll.
gruß martin
Zitat von: UweH schrieb am So, 06 Januar 2013 12:01Ich fasse den Mailverkehr hier Ausschnittweise zusammen, damit andere nicht auch verzweifeln...
Das steht in Kurzform auch in dem Link im Ursprungsposting dieses Threads.
War das zu versteckt?
Grüße
Boris
Zitat von: Martin Fischer schrieb am So, 06 Januar 2013 13:53wenn nämlich alle readings in @gettes und @polls aufgenommen werden, dann erfolgen auch überflüssige abfragen. es gibt noch ein paar weitere devices, die sich so verhalten.
Ich bin der Meinung, daß der aktuelle Stand das alles berücksichtigt:
Die @getters definieren die Readings, die man Abfragen
kann. Tatsächlich abgefragt wird ein Reading aber nur mit [code]get myDevice theReading[/code Dabei wird nur genau das Reading abgefragt und kein anderes.
Die @polls sind diejenigen Readings, die automatisch alle x Sekunden abgefragt werden, wenn man ein Polling-Intervall beim define angibt.
Auf Deine Anmerkung hin hatte ich noch das Attribut polls eingeführt, über das der Anwender angeben kann, welche Readings er pollen möchte, wenn er mit der Vorgabe nicht zufrieden ist.
Aus meiner Sicht müßte damit alles laufen, sogar Readings der Form "foo/bar", also aus Unterverzeichnissen von OWFS, wobei ich diesen letzten Punkt noch nicht getestet habe. Du hattest mir den Tip gegeben, es mit den FAKE-Devices zu tun.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert schrieb am Sa, 05 Januar 2013 13:11Zitat von: fladdy schrieb am Sa, 05 Januar 2013 10:34wäre es möglich ein model-Attribut innerhalb von OWDevice automatisch zu setzen (z.B. DS18B20)?
Ja. Baue ich gelegentlich mal ein.
Erledigt und morgen verfügbar. Beim define wird es aus dem Reading type gesetzt.
Grüße
Boris
Zitat von: Dr. Boris Neubert schrieb am So, 06 Januar 2013 16:22Auf Deine Anmerkung hin hatte ich noch das Attribut polls eingeführt, über das der Anwender angeben kann, welche Readings er pollen möchte, wenn er mit der Vorgabe nicht zufrieden ist.
Aus meiner Sicht müßte damit alles laufen, sogar Readings der Form "foo/bar", also aus Unterverzeichnissen von OWFS, wobei ich diesen letzten Punkt noch nicht getestet habe. Du hattest mir den Tip gegeben, es mit den FAKE-Devices zu tun.
ah, ich erinnere mich... muss bei mir irgendwie untergegangen sein..
gruss martin
Offenbar nicht, ich habe auch eben nochmal gesucht und bin nicht fündig geworden.
Es gibt diesen Link http://neubert-volmar.de/Hausautomation/RaspberryPi/index.html (//neubert-volmar.de/Hausautomation/RaspberryPi/index.html) und diesen http://wiki.temperatur.nu/index.php/OWFS_with_i2c_support_on_Raspberry_Pi_%28English_version%29 (//wiki.temperatur.nu/index.php/OWFS_with_i2c_support_on_Raspberry_Pi_%28English_version%29).
Was übersehe ich?
Danke!
Die Tatsache, dass man bei RevA-Raspberrys /dev/i2c-0 statt /dev/i2c-1 nehmen muss, habe ich auch nicht in Deiner Anleitung gefunden. Vielleicht kannst Du das ja noch aufnehmen/hervorheben.
Zitat von: Dr. Boris Neubert schrieb am So, 06 Januar 2013 16:41Zitat von: Dr. Boris Neubert schrieb am Sa, 05 Januar 2013 13:11Zitat von: fladdy schrieb am Sa, 05 Januar 2013 10:34wäre es möglich ein model-Attribut innerhalb von OWDevice automatisch zu setzen (z.B. DS18B20)?
Ja. Baue ich gelegentlich mal ein.
Erledigt und morgen verfügbar. Beim define wird es aus dem Reading type gesetzt.
Grüße
Boris
Zitat von: fladdy schrieb am So, 06 Januar 2013 18:42Die Tatsache, dass man bei RevA-Raspberrys /dev/i2c-0 statt /dev/i2c-1 nehmen muss, habe ich auch nicht in Deiner Anleitung gefunden. Vielleicht kannst Du das ja noch aufnehmen/hervorheben.
Hab's aufgenommen in
der Anleitung Grüße
Boris
folgende neue devices zu 11_OWDevice hinzugefügt:
DS1822 - Econo 1-Wire Digital Thermometer
DS1825 - Programmable Resolution 1-Wire Digital Thermometer with ID
DS1904 - RTC iButton
DS1920 - iButton version of the thermometer
DS1990A - Serial Number iButton
DS2401 - Silicon Serial Number
DS2415 - 1-Wire Time Chip
DS2417 - 1-Wire Time Chip with Interrupt
DS2436 - Battery ID/Monitor Chip
DS2438 - Smart Battery Monitor
DS2450 - Quad A/D Converter
gruss martin
WOW!
Sehr beeindruckend! Jetzt fehlt lediglich noch irgend eine geeignete Anbindung vom CUNO.
Jedenfalls gibt es jetzt eine echte Lösung, um von der FritzBox auf den RPi umziehen zu können.
Ganz tolle Kino!
Vielen Dank,
Ralf
Zitat von: Dr. Boris Neubert schrieb am So, 06 Januar 2013 16:22Auf Deine Anmerkung hin hatte ich noch das Attribut polls eingeführt, über das der Anwender angeben kann, welche Readings er pollen möchte, wenn er mit der Vorgabe nicht zufrieden ist.
mir ist dabei aufgefallen, das nach setzen von polls der state nicht mehr aktualisiert wird. ist das nun ein seiteneffekt von stateFormat?
Code anzeigenInternals:
DEF 26.126545010000 60
IODev OWFS
NAME owmulti
NR 31
STATE temperature: 25.9375
TYPE OWDevice
Readings:
2013-01-06 19:28:45 HIH4000/humidity 47.3232
2013-01-06 19:28:45 VAD 2.14
2013-01-06 19:28:45 VDD 4.73
2013-01-06 19:00:11 state temperature: 25.9375
2013-01-06 19:28:45 temperature 26.8125
Fhem:
address 26.126545010000
interval 60
getters:
MultiSensor/type
offset
S3-R1-A/current
S3-R1-A/illumination
S3-R1-A/gain
B1-R1-A/pressure
B1-R1-A/gain
B1-R1-A/offset
HIH4000/humidity
HTM1735/humidity
DATANAB/humidity
humidity
date
disconnect/date
disconnect/udate
endcharge/date
endcharge/udate
udate
CA
EE
IAD
temperature
VAD
VDD
vis
CA
EE
IAD
date
disconnect/date
disconnect/udate
address
alias
family
id
power
type
polls:
temperature
HIH4000/humidity
VAD
VDD
setters:
offset
S3-R1-A/gain
DATANAB/reset
date
disconnect/date
disconnect/udate
endcharge/date
endcharge/udate
udate
CA
EE
IAD
alias
Attributes:
model DS2438
polls temperature,HIH4000/humidity,VAD,VDD[/code]
ZitatAus meiner Sicht müßte damit alles laufen, sogar Readings der Form "foo/bar", also aus Unterverzeichnissen von OWFS, wobei ich diesen letzten Punkt noch nicht getestet habe. Du hattest mir den Tip gegeben, es mit den FAKE-Devices zu tun.
ich habe es getestet, die sensoren erweitert und eingecheckt.
virtualReadings ist aber noch nicht drin, so wie ich es gesehen habe.
gruss martin
...ich kann gar nicht sagen, wie sehr ich mich über dieses Modul freue! :-)
VG
Ralf
;-)
Hallo Ralf,
hast Du da auch schon z.B. einen Temperaturwert in's Display gebeamt? Bei OWLCD läuft's z.B. so:
{OWXLCD_SetLine($defs{'Display_2'},0,"Aussen $defs{'Temp.Aussen'}{STATE}")}
Ich habe versucht, das abzuwandeln, aber ich komm nicht auf den richtigen Dreh... :(
Moin Uwe,
ja, hab ich. Ist aber nur eine von vielen Möglichkeiten.
Zunächst hab ich mir lediglich ein at für die fhem.cfg geschrieben, das alle 5 Minuten das Display updated, indem die Funktion prg_LCDup aufgerufen wird.
define LCDup at +*00:05:00 {prg_LCDup()}
attr LCDup alignTime 00:00:00
attr LCDup room OW_RPi
In der 99_MyUtils.pm habe ich mir dann die dazugehörige Funktion geschrieben.
###########
sub
prg_LCDup()
{
my $LCD_text = sprintf("%.1f",ReadingsVal("OW_Temp_Test","temperature",0))." C" ;
fhem ("set LCD line20.1 Ralfs Buero:$LCD_text");
}
So finde ich es maximal flexibel und kann mir meine Funktion beliebing verändern oder erweitern.
Hilft das weiter?
(siehe Anhang / see attachement)
Super, Danke.
Genau das war's. :))
So - ich hatte ja irgenwie ein spinnende Konfiguration.
Ich habe nochmal ein update ausgeführt, und die OWDevices neu erstellt, jetzt läuft alles ;-)
Vielen dank nochmal für die tolle arbeit mit den Modulen!
Gruß,
Thorsten
Hallo,
ich würde mich freuen, wenn die Nutzer von OWServer/OWDevice ein fheminfo send absetzen könnten, damit ich einen Eindruck davon gewinne, wieviele Installationen der Module es gibt. Je stärker die Verbreitung desto größer meine Motivation, die Module weiterzuentwickeln.
Danke und viele Grüße
Boris
Zitat von: Dr. Boris Neubert schrieb am Mo, 07 Januar 2013 21:30Hallo,
ich würde mich freuen, wenn die Nutzer von OWServer/OWDevice ein fheminfo send absetzen könnten, damit ich einen Eindruck davon gewinne, wieviele Installationen der Module es gibt. Je stärker die Verbreitung desto größer meine Motivation, die Module weiterzuentwickeln.
Danke und viele Grüße
Boris
Boris,
hab ich schon vor zwei Tagen gemacht. Ich bin allerdings immer noch von den Socken, was ihr mal eben so zwischendurch auf die Beine gestellt habt, und wie stabil stabil das funktioniert.
Wähend Villariba schon logged, wird in Villabacho noch gebastelt.
Ich hab heute die letzten fehlenden Infos bekommen, was ich noch ändern und ergänzen muss, damit 1-Wire und fhem zukünftig rock-solid und ohne all die Einschränkungen läuft.
Ich werde berichten und hoffe, das das zu deiner Motivation beitragen wird.
VG
Ralf
Hallo habe zwei Probleme um mir die Temperaturen vernünftig Anzeigen zulassen habe ich
attr Vorlauf stateFormat { sprintf("%.1f°C",ReadingsVal("Vorlauf","temperature",0)) }
Eingefügt aber erst wenn ich modify ausführe wird es richtig angezeigt.
Kann ich das nicht automatisch machen so das beim Fhem Start modifi ausgeführt wird?
Zweites Problem Temperatur wird doppelt gelogt finde aber den Fehler nicht.
2013-01-08_17:03:41 Vorlauf temperature: 46.9375
2013-01-08_17:03:41 Vorlauf temperature: 46.9375
2013-01-08_17:06:34 Vorlauf temperature: 43.125
2013-01-08_17:06:34 Vorlauf temperature: 43.125
Meine cfg
define Vorlauf OWDevice 28.915B09040000 300
attr Vorlauf fp_Grundriss 150,200,4,
attr Vorlauf group 1Wire
attr Vorlauf icon icoTempHausEG
attr Vorlauf room 1Wire
attr Vorlauf stateFormat { sprintf("%.1f°C",ReadingsVal("Vorlauf","temperature",0)) }
define FileLog_Vorlauf FileLog ./log/Vorlauf/Vorlauf-%Y.log Vorlauf
attr FileLog_Vorlauf logtype temp4:Temp/Act,text
attr FileLog_Vorlauf room 1Wire
define weblink_Vorlauf weblink fileplot FileLog_Vorlauf:temp4:CURRENT
attr weblink_Vorlauf label "Vorlauf Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_Vorlauf room 1Wire
Gruß
Martin
Martin,
auch bei mir werden die Temperaturen aktuell immer doppelt ins Log geschrieben.
Und wegen deiner Anzeige: du musst warten, bis der nächste Wert vom Sensor geholt wird, dann wird die Anziege erst upgedated.
VG
ralf
Zitat von: Martin schrieb am Di, 08 Januar 2013 17:11Zweites Problem Temperatur wird doppelt gelogt finde aber den Fehler nicht.
2013-01-08_17:03:41 Vorlauf temperature: 46.9375
2013-01-08_17:03:41 Vorlauf temperature: 46.9375
2013-01-08_17:06:34 Vorlauf temperature: 43.125
2013-01-08_17:06:34 Vorlauf temperature: 43.125
Habe ich auch. Das Problem tritt bei mir seit 04.01. auf. Muß ich analysieren.
Grüße
Boris
Boris,
was mir gestern Abend noch in den Sinn kam:
Benötigt man ein IODev für 1-Wire Devices, wenn es mehrere OWServer in der Konfiguration gibt?
Aktuell suchen sich alle Devices "ihren" Server laut LogFile ganz automatisch und legen das IODev selber an, aber im PullDownMenu des Devices fehlt IODev als Option.
Bei mir funktioniert das aktuell zwar problemlos ohne das ich was getan hätte, aber ich dachte ich frag mal lieber. :-)
VG
Ralf
Hi,
ist soetwas wie die VFUNCTION in OWAD/OWMULTI verfügbar?
Der DS2450 liefert zb. nur Volt zurück und daraus muss ich zb. einen Prozentwert (Bodenfeuchte) ausrechnen
zZ setze ich ausschließlich die Module von pah ein, ich würde aber gerne mal diese Module hier testen....
Ich glaube mir ist noch was aufgefallen: wenn bei laufendem fhem ein OWServer abhanden kommt, hängt sich fhem auf. Ich musste heute noch etwas Software auf meinem Remote OWServer nachinstallieren und dabei ein paar mal neu booten.
Sowohl fhem auf der FritzBox als auch auf dem RPi hingen danach fest. Der RPi konnte auch nicht mehr mit sudo reboot gestartet werden, weil sich der fhem Prozess nicht stoppen lassen wollte.
Auf der FritzBox hab ich den fhem Prozess gekillt und neu gestartet.
Meinst du man kann da was dran machen?
VG
Ralf
Zusatz:
(1) In der commandref taucht die folgende Zeile bei OWDevice zwei mal auf:
2413 1-Wire Dual Channel Addressable Switch
(2) Irgendwie bekomme ich keine Readings von den Ports des 2413.
OWFS sagt mir, das es zum Lesen das sensed.A und sensed.B property gäbe.
ZitatPio.a Pio.b Pio.all Pio.byte
read-write, yes-no
State of the open-drain output ( PIO ) pin. 0 = non-conducting (off), 1 = conducting (on) .
Writing zero will turn off the switch, non-zero will turn on the switch. Reading the PIO state will return the switch setting. To determine the actual logic level at the switch, refer to the sensed property.
ALL references both channels simultaneously, comma separated.
BYTE references both channels simultaneously as a single byte, with channel A in bit 0.
sensed.A sensed.B sensed.ALL sensed.BYTE
read-only, yes-no
Logic level at the PIO pin. 0 = ground. 1 = high (~2.4V - 5V ). Really makes sense only if the PIO state is set to zero (off), else will read zero.
ALL references both channels simultaneously, comma separated.
BYTE references both channels simultaneously as a single byte, with channel A in bit 0.
Aber mein RPi sagt mir
ZitatUnknown argument sensed.A, choose one of PIO.A PIO.B address alias family id power type
Oder hab ich was übersehen?
VG
Ralf
Zitat von: Tobias schrieb am Do, 10 Januar 2013 13:04Hi,
ist soetwas wie die VFUNCTION in OWAD/OWMULTI verfügbar?
Der DS2450 liefert zb. nur Volt zurück und daraus muss ich zb. einen Prozentwert (Bodenfeuchte) ausrechnen
noch nicht.. kommt aber noch..
gruss martin
Zitat von: dougie schrieb am Do, 10 Januar 2013 14:49Unknown argument sensed.A, choose one of PIO.A PIO.B address alias family id power type
sensed.[A|B] fehlt.. ich trags nach... morgen dann via update..
gruss
Zitat von: dougie schrieb am Do, 10 Januar 2013 14:49(1) In der commandref taucht die folgende Zeile bei OWDevice zwei mal auf:
2413 1-Wire Dual Channel Addressable Switch
gefixt.
BN
Zitat von: dougie schrieb am Do, 10 Januar 2013 07:53Benötigt man ein IODev für 1-Wire Devices, wenn es mehrere OWServer in der Konfiguration gibt?
Aktuell suchen sich alle Devices "ihren" Server laut LogFile ganz automatisch und legen das IODev selber an, aber im PullDownMenu des Devices fehlt IODev als Option.
Man benötigt es nicht, weil sich das OWDevice dem zuletzt definierten OWServer anschließt. Habe das Attribut aber der Vollständigkeit ergänzt.
Boris
Zitat von: dougie schrieb am Do, 10 Januar 2013 13:25Ich glaube mir ist noch was aufgefallen: wenn bei laufendem fhem ein OWServer abhanden kommt, hängt sich fhem auf.
Ich habe mir den Code in
OWNet.pm angesehen und ich kann nicht ausschließen, daß es bei einem Verbindungsabbruch zu einem Hänger in einem System Call kommt. Hier auf die Suche zu gehen mag ich mir nicht antun.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert schrieb am Do, 10 Januar 2013 20:54Ich habe mir den Code in OWNet.pm angesehen und ich kann nicht ausschließen, daß es bei einem Verbindungsabbruch zu einem Hänger in einem System Call kommt. Hier auf die Suche zu gehen mag ich mir nicht antun.
Viele Grüße
Boris
Damn it... muss ich versuchen anders abzufangen. Aber danke für's Nachsehen anyway!!!
VG
Ralf
Hi Martin, Boris,...
das Problem mit den doppelten Logeinträgen hab ich auch....
Noch komischer ist's nach dem gestrigen update, seither sind die Values unterschiedlich...
DEF 10.67C6697351FF 120
IODev my_OWServer
NAME my_OWDevice
NR 39
STATE temperature: 79.5141
TYPE OWDevice
Readings
state temperature: 79.5141 2013-01-12 15:33:06
temperature 99.61 2013-01-12 15:33:06
Was ich bisher gefunden habe:
1) Das Problem ist nicht auf OWDevice beschränkt. Es tritt auch bei OWTERM und auch bei FHT auf
2) Es tritt nur bei reading temperature auf ???
3) besser: es tritt nur auf wenn ein reading name / value exakt gleich nach reading state kopiert wird.
das ist bei OWTERM, OWDevice und FHT (measured-temp) der Fall.
Wenn ich den code richtig verstehe, wird dann auch für reading state ein event getriggered,
der völlig gleich aussieht wie der event für das reading temperatue.
damit funktionieren die filelog regex <device>:temperature.* natürlich nicht !
da hab ich zumindest soo interpretiert (mit hilfe des event-monitors)...
l.g. erwin
hallo erwin,
> das Problem mit den doppelten Logeinträgen hab ich auch....
komischweise konnte ich das bei mir während der entwicklung gestern nicht nachstellen. aber
boris hat sich das schon auf die todo genommen.
mein verdacht war gestern:
es fehlte in OWDevice eine routine, die beim löschen eines device selbiges aus der liste der
definierten devices austrägt und vorallem auch die internen timer löscht.
mir ist das nämlich aufgefallen als ich gestern ein testdevice gelöscht hatte und trotzdem
weiterhin fleissig logeinträge im definierten intervall eingingen. die fehlene routine habe
ich aber gestern hinzugefügt und boris meinen "verdacht" mal weitergegeben.
> Noch komischer ist's nach dem gestrigen update, seither sind die Values unterschiedlich...
auch das ist komisch und trat (zumindest gestern) nicht auf. da jedoch die funktion für die
event in einer zentralen funktion innerhalb von fhem liegen und du schreibst, das es auch
bei anderen "nicht" OWDevice modulen auftritt, müssen wir uns das mal mit rudi gemeinsam ansehen.
vielleicht hat das auch was mit der umstellung des "state" zu tun.
> Wenn ich den code richtig verstehe, wird dann auch für reading state ein event getriggered,
> der völlig gleich aussieht wie der event für das reading temperatue.
> damit funktionieren die filelog regex <device>:temperature.* natürlich nicht !
ja, ist mir gestern auch aufgefallen. das hängt mit der neuen behandlung von state zusammen.
da sollte rudi nochmal ran, da ich das auch etwas "unglücklich" zu parsen finde.
gruss martin
> ... Es tritt auch bei OWTERM und auch bei FHT auf
Da mich Martin auf diese Diskussion aufmerksam gemacht hat: stimmt, FHTs loggen neuerdings measured-temp zweimal.
Ursache war der Aufruf von:
readingsBulkUpdate($def, "state", "measured-temp: $val");
in FHT.pm, nachdem vorher fuer "measured-temp" auch ein readingsBulkUpdate aufgerufen wurde. Meine Loesung (getestet & eingecheckt):
readingsBulkUpdate($def, "state", "measured-temp: $val", 0);
damit wird fuer diesen zweiten Aufruf kein Event generiert. Vmtl. muss sowas auch in den anderen betroffenen Modulen eingebaut werden.
Zitat von: rudolfkoenig schrieb am So, 13 Januar 2013 10:46>
readingsBulkUpdate($def, "state", "measured-temp: $val", 0);
damit wird fuer diesen zweiten Aufruf kein Event generiert. Vmtl. muss sowas auch in den anderen betroffenen Modulen eingebaut werden.
Ich schlage vor, in readingsBulkUpdate ein
$changed= 0 unless defined($changed);an den Anfang zu setzen. Dadurch braucht man keine drei Zustände (undef, 0, 1) im restlichen Code zu berücksichtigen
Viele Grüße
Boris
Hi Rudolf,
danke für den Fix, funktioniert perfekt!
Für die anderen Module verwende ich als temp. fix :
attr <device> event-on-update-reading temperature
damit wird nur für temperature ein event generiert/geloggt - und nicht für state...
Danke auch an Boris und Martin für die großartigen Module!
l.g. erwin
Frage:
Ist IODev jetzt eigentlich ein Setting oder ein Attribut? :-)
(siehe Anhang / see attachement)
Zitat von: dougie schrieb am So, 13 Januar 2013 17:36Frage:
Ist IODev jetzt eigentlich ein Setting oder ein Attribut? :-)
IODev wird mit attr gesetzt, ist aber technisch weder ein Reading noch ein Attribut sondern eine FHEM-interner Wert (so wie STATE, NR, NAME, ...).
Grüße
Boris
Danke Boris,
Frage bezog sich darauf, das ich das IODev zwar mit attr gesetzt hatte, fhem aber beharrlich den "anderen" Server als den Richtigen erachtete.
Nach dem zweiten Setzen des attr ist es dann übernommen worden. Irgendwie hat da was gehakt. Der DS2450 ist auch nicht automatisch als solcher erkannt worden.
Jetzt läuft's erst mal und ich teste weiter.
VG
Ralf
Hier noch ein Hinweis für diejenigen, die einen RPi mit USB/Seriell Interface und FTDI Chip betreiben!
Die Implementierung von USB auf dem RPi (Raspbian Wheezy) ist wohl noch buggy, und mein MP00202 1W USB Busmaster Adapter mit FT232RL brachte den RPi alle paar Stunden unregelmässig zum Absturz.
Danke an Boris mit dem Tipp wo ich fragen kann.
Als Antwort bekam ich den Hinweis, die USB Geschwindigkeit runter zu setzen.
ZitatA quick solution could be adding dwc_otg.speed=1 to /boot/cmdline.txt it will switch usb to 1.1 only so the network speed will decrease significantly.
Seit dem läuft mein RPi mit owserver stabil.
BR
Ralf
Zu früh gefreut!
Gerade war der Remote-OWServer wieder "weg" und nicht mehr via ping erreichbar.
Der fhem Prozess auf dem anderen RPi war weg, konnte aber wieder gestartet werden.
Fehlermeldung beim Re-Start von fhem:
Use of uninitialized value $payload_data in addition (+) at /usr/share/fhem/FHEM/lib/OWNet.pm line 357.
Use of uninitialized value $payload_data in pack at /usr/share/fhem/FHEM/lib/OWNet.pm line 359.
Ich glaube 1Wire mit USB/FT232 ist momentan auf dem RPi noch nicht brauchbar.
Sieht wohl so aus, als müsste ich mir doch noch einen i2c Adapter bauen.
VG
Ralf
Zitat von: dougie schrieb am Mo, 14 Januar 2013 09:42Ich glaube 1Wire mit USB/FT232 ist momentan auf dem RPi noch nicht brauchbar.
Bei mir läuft's damit seit vorgestern ohne Hänger. USB/FT232/DS2480 als Busmaster auf RPi 1 und auf RPi 2 I2C/DS2482-Interface als Busmaster.
Kurioserweise erkennt weder OWX noch OWserver das Display auf RPi 1. Wenn ich den zweiten RPi aus der Konfiguration nehme, klappt's wieder.
Auf RPi 2 wird es in jeder Kombination erkannt... :o
> Kurioserweise erkennt weder OWX noch OWserver das Display auf RPi 1.
wenn du ein "Luis Swart" lcd einsetzt, dann findet owserver den familycode "FF" ggf. nur, wenn owserver mit dem argument "--serial_regulartime" gestartet wird. die info kommt direkt von paul.
siehe auch man owserver:
--serial_flextime | --serial_regulartime (DS2480B)
Changes details of bus timing (see DS2480B datasheet). Some devices, like the Swart LCD cannot work with flextime.
gruss martin
...wird bei mir mit einem "get <owserver> devices" problemlos erkannt.
VG
Ralf
(siehe Anhang / see attachement)
Zitat von: dougie schrieb am Mo, 14 Januar 2013 09:42Use of uninitialized value $payload_data in addition (+) at /usr/share/fhem/FHEM/lib/OWNet.pm line 357.
Use of uninitialized value $payload_data in pack at /usr/share/fhem/FHEM/lib/OWNet.pm line 359.
die meldung ist jetzt abgefangen. hatte aber nichts mit dem von dir geschilderten problem zu tun.
gruss martin
Hallo Martin,
Danke für den Tipp.
Die Befehle muss ich sicher in /etc/init.d/owserver eintragen, ich vermute mal, unter d_start(). Wenn ja, wo genau?
Danke
hallo uwe,
Zitat von: UweH schrieb am Mo, 14 Januar 2013 18:54Die Befehle muss ich sicher in /etc/init.d/owserver eintragen, ich vermute mal, unter d_start(). Wenn ja, wo genau?
als argument für den aufruf von owserver in deinem /etc/init.d/owserver script.
wenn du nicht genau weisst wo, dann setz hier einfach mal dein script rein. dann zeig ich dir die stelle.. aber hier bitte mittels bbcode code tags einschliessen (macht es lesbarer).
gruss martin
Hi Martin,
das sist so aus:
#!/bin/sh
### BEGIN INIT INFO
# Provides: owserver
# Required-Start: $remote_fs $syslog $network $named
# Required-Stop: $remote_fs $syslog $network $named
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: 1-wire TCP server
# Description: Start and stop a TCP server for 1-wire control.
### END INIT INFO
PATH=/sbin:/bin:/usr/sbin:/usr/bin
CONFFILE=/etc/owfs.conf
DESC="1-Wire TCP Server"
NAME="owserver"
DAEMON=/usr/bin/$NAME
PIDDIR=/var/run/owfs
PIDFILE=$PIDDIR/$NAME.pid
# Gracefully exit if the package has been removed.
test -x $DAEMON || exit 0
. /lib/lsb/init-functions
d_start() {
[ -d $PIDDIR ] || {
mkdir -m 0775 -p $PIDDIR
chown root:root $PIDDIR >/dev/null 2>&1
}
start-stop-daemon --start --quiet --oknodo --exec $DAEMON -- -c $CONFFILE \
--pid-file $PIDFILE
# ensure the daemon has been started
sleep 1
pidofproc -p $PIDFILE $DAEMON >/dev/null
}
d_stop() {
start-stop-daemon --stop --quiet --oknodo --exec $DAEMON
sleep 1
if [ -f $PIDFILE ] && ! ps h `cat $PIDFILE` > /dev/null
then
# Stale PID file (owserver was successfilly stoped),
#remove it
rm -f $PIDFILE
fi
}
d_status() {
pidofproc -p $PIDFILE $DAEMON > /dev/null
}
case "$1" in
start)
log_daemon_msg "Starting $DESC" "$NAME"
d_start
log_end_msg $?
;;
stop)
log_daemon_msg "Stopping $DESC" "$NAME"
d_stop
log_end_msg $?
;;
restart|force-reload)
log_daemon_msg "Restarting $DESC" "$NAME"
d_status && d_stop
d_start
log_end_msg $?
;;
status)
d_status
if [ $? -eq 0 ];then
log_success_msg "$NAME is running"
else
log_failure_msg "$NAME is not running"
fi
;;
*)
echo "Usage: /etc/init.d/$NAME {start|stop|restart|force-reload|status}" >&2
exit 1
;;
esac
exit 0
#!/bin/sh
[...]
d_start() {
[ -d $PIDDIR ] || {
mkdir -m 0775 -p $PIDDIR
chown root:root $PIDDIR >/dev/null 2>&1
}
start-stop-daemon --start --quiet --oknodo --exec $DAEMON -- -c $CONFFILE \
--serial_regulartime --pid-file $PIDFILE
# ensure the daemon has been started
[...]
schreibe es einfach vor "--pid-file $PIDFILE". siehe oben..
gruss martin
Also ich habe einen Link45 Busmaster mit RS232 über einen billigen USB->Seriell Konverter mit Profilinc Chipsatz im Einsatz.
Läuft seit einigen Tagen ohne Probleme...
Ich hoffe ich bekomme meinen RS485 Adapter (HS485 BUS) zum laufen... der hat einen FTDI-Chip
Zitat von: dougie schrieb am Mo, 14 Januar 2013 08:04Hier noch ein Hinweis für diejenigen, die einen RPi mit USB/Seriell Interface und FTDI Chip betreiben!
Die Implementierung von USB auf dem RPi (Raspbian Wheezy) ist wohl noch buggy, und mein MP00202 1W USB Busmaster Adapter mit FT232RL brachte den RPi alle paar Stunden unregelmässig zum Absturz.
Danke an Boris mit dem Tipp wo ich fragen kann.
Als Antwort bekam ich den Hinweis, die USB Geschwindigkeit runter zu setzen.
ZitatA quick solution could be adding dwc_otg.speed=1 to /boot/cmdline.txt it will switch usb to 1.1 only so the network speed will decrease significantly.
Seit dem läuft mein RPi mit owserver stabil.
BR
Ralf
Ich bin hier die ganzen Tage noch am Testen, und das herabsetzen der USB Geschwindigkeit hilft auf jeden Fall!!
Das Ganze hat aber einen kleinen Haken: ich hab mir den Schaltplan vom RPi mal genauer angesehen, und der 9512 LAN Interface Chip des RPi ist auch ein USB Device, das auf dem gleichen Bus/Controller wie die externen Ports hängt. Daher würgt man mit dem Setting auch die Netzwerkgeschwindigkeit auf USB 1.1 Niaveau ab.
Ist bei mir nicht so wild, weil das Ding nur owserver spielt, aber sollte man vielleich im Hinterkopf behalten.
Ich bin zuversichtlich, das es da aber irgendwann nen Fix für Raspbian gibt.
VG
Ralf
Zitat von: thoweiss schrieb am Di, 15 Januar 2013 07:47Also ich habe einen Link45 Busmaster mit RS232 über einen billigen USB->Seriell Konverter mit Profilinc Chipsatz im Einsatz.
Läuft seit einigen Tagen ohne Probleme...
Ich hoffe ich bekomme meinen RS485 Adapter (HS485 BUS) zum laufen... der hat einen FTDI-Chip
...manchmal beisse ich mich auch an Sachen fest. :-)
Diese FTDI FT232 USB/seriell Sache ist so was. Es wäre sicher einfacher, eben einen i2c Adapter zu bauen, aber das würde ja keinen weiter bringen.
Ich hab hier diese Story gefunden, nachder der dwc_otg Driver (mindestens) einen Bug hat.
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=23544&start=125 (//www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=23544&start=125)
Bevor jetzt alle ihren Kernel updaten: ich hab das mal gerade bei mir gemacht und USB wieder auf Full-Speed gesetzt.
Ich werde berichten, ob sich was verbessert hat.
VG
Ralf
Danke Martin, werde ich testen. :)
Update:
Das Kernel-Update hat auf alle Fälle was gebracht. Der RPi mit dem MP00202 USB Adapter läuft seit heute Morgen einwandfrei und ohne einen Hänger.
Kann ich also für alle Betroffenen empfehlen. Anleitung: hier -> https://github.com/Hexxeh/rpi-update (//github.com/Hexxeh/rpi-update)
Da ich mich da aber nicht auf den Erfolg verlassen wollte, hab ich zwischendurch eben den i2c-Adapter von Boris nachgebaut. Zusätzlich hab ich noch einen 3,3V/5V Level Shifter für den Bus eingebaut und einen Schalttransistor für GPIO 17. Sorry for quick 'n dirty.
(siehe Anhang / see attachement)
(siehe Anhang / see attachement)
VG
Ralf
Zitat von: dougie schrieb am Mi, 09 Januar 2013 13:06auch bei mir werden die Temperaturen aktuell immer doppelt ins Log geschrieben.
Das liegt daran, daß das state-Reading gesetzt wird und die regex vom FileLog auch die Wertänderung vom state-Reading erfaßt und mitloggt.
Ich habe das jetzt so geändert, daß bei OWDevice Änderungen von state niemals ein Event erzeugen. Im SVN und ab morgen per update.
Viele Grüße
Boris
Hallo Dougie
Hat sich bei der Stabilität etwas verbessert?
Welche Kernel-Version hast du jetzt drauf?
Kann man den Kernel nicht auch mit apt-get dist-upgrade ziehen?
Ich habe auch sporadisch Probleme mit meinem USB-RS232 Wandlern...
Gestern hatte sich mein pi dann zum ersten mal komplett verabschiedet - war nicht mehr über ssh erreichbar.
Zitat von: dougie schrieb am Di, 15 Januar 2013 10:04http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=23544&start=125
Bevor jetzt alle ihren Kernel updaten: ich hab das mal gerade bei mir gemacht und USB wieder auf Full-Speed gesetzt.
Ich werde berichten, ob sich was verbessert hat.
VG
Ralf
Gruß,
Thorsten
Hi Thorsten,
oh ja!! Seit meinem Post ist mein RPi kein einziges mal mehr stehen geblieben oder hat sonst Probleme gemacht.
Tatsächlich steht er seit Samstag in meiner Garage mit dem Polen-USB-Adapter und liefert in seiner eigentlichen Funktion mit einwandfreier Zuverlässigkeit als OWServer meine Werte. Von meiner bescheidenen Position aus, kann ich diese Kombination empfehlen.
Ob man das Kernel-Update auch anders bekommen kann, vermag ich nicht zu beurteilen. Ich gehe davon aus, das das früher oder später auch den Weg ins offizielle Image findet, aber ich lasse meinen RPi erst mal so laufen, um ein paar Langzeit-Erfahrungen zu machen.
Auf jeden Fall ist die Kombination RPi/OWserver/OWDevice eine ganz andere Welt, als die Kombination CUNO/"die alten Module".
Dies ist natürlich nur meine persönliche Sichtweise ;-)
VG
Ralf
Na dann will ich das einmal probieren.
Klappt das mit raspi-update problemlos?
Irgenwo hatte ich gelesen, das man sich damit sein System auch zerschießen kann...
es mMn immer ein guter Plan, von der SD Card des RaspbPi vor solchen Experimenten ein Image auf dem heimischen PC zu speichern. Da kannst Du Dir den letzten Stand zurückspielen, falls was schief gegangen ist. Das geht schneller, als das komplette System neu aufzusetzten.
Ja, auch das viel gepriesene Linux kann man sich total zerschiessen - das geht durchaus nicht nur bei Windows.
Die regelmäßige Nutzung von apt-get upgrade und update hat meinen RaspbPi in Verbindung mit einigen Tipps hier aus dem Forum inzwischen sehr stabil gemacht.
So bei mir hat das update auch geklappt...
Mal sehen ob es etwas gebracht hat...
Ich habe jetzt Kernel 3.6.11+ lt. uname -a
gruß,
Thorsten
Zitat von: thoweiss schrieb am Mi, 23 Januar 2013 19:07So bei mir hat das update auch geklappt...
gruß,
Thorsten
Und? Wie läuft's? :-)
Ich wollte nur noch mal eben was zusammenfassen, das sich andere vielleicht ein besseres Bild machen können.
Zugegeben: seit Boris und Martin die neuen Module raus gebracht haben, hab ich alles versucht diese in die Knie zu zwingen.
Relativ frustriert von den Erfahrungen mit CUNO und OWX wollte ich meine Haussteuerung auf keinen Fall einer derart unzuverlässigen Umgebung zumuten.
Was soll ich sagen? Es läuft einfach!
War ich bislang auf drei oder maximal 4 Devices am Bus beschränkt, bevor das OWX-Modul ausstieg, läuft jetzt alles so wie ich es gewohnt bin.
Anbei mal zwei Bilder. Das erste zeigt die aktuelle Konfiguration im Haus, die zweite die in der Garage.
(siehe Anhang / see attachement)
(siehe Anhang / see attachement)
Ich möchte dennoch nicht den Eindruck erwecken das wäre Plug-N-Play!
Bis der RPi bei mir als OWServer stabil lief, hat es etwas gedauert, weil die USB Implementierung noch buggy war.
Nachdem ich den Bus hier im Haus immer mehr erweitert (und verlängert) habe, musste ein RC Glied für die nötige Kompensation sorgen. Da war etwas Basteln und testen angesagt.
Was noch fehlt ist eine kleine Anpassung in der
OWNet.pm (kein Bestandteil von fhem oder OWServer / OWDevice) das fhem nicht einfriert, sollte man ein angeschlossener OWServer das Netz verlassen.
Sicher fehlen auch noch ein paar kleine kosmetische Anpassungen, die ich aber nach den Schwierigkeiten der letzten Monate nur noch als "nice to have" betrachte.
Mir ist für eine Haussteuerung eine grundsolide Technik allemal lieber, als ein Feature-strotzendes Etwas, was aber in meiner Umgebung nicht sinnvoll eingesetzt werden kann.
Für mich ist die Suche nach der richtigen Hard- & Software hiermit abgeschlossen und ich muss mich nur noch um die eigentliche Konfiguration kümmern.
Meine komplette Heizung läuft inzwischen über HomeMatic, unwichtigere Schaltaufgaben über FS20, und die verbleibenden Lücken schliesse ich mit 1-Wire.
Ich hoffe das es anderen bei der Entscheidung hilft, wenn sie wie ich vor dem Berg an Informationen stehen und wissen möchten was geht und was nicht.
Viele Grüsse
Ralf
Also bis jetzt scheint es zu laufen...
Hier mal meine devices:
10.A81EE5000800 DS18S20 DS18S20_A81EE5000800
10.F2FAE4000800 DS18S20 DS18S20_F2FAE4000800
10.16FDE4000800 DS18S20 DS18S20_16FDE4000800
10.AEFCE4000800 DS18S20 DS18S20_AEFCE4000800
10.4B0AE5000800 DS18S20 temp_brauchwasser
28.5AC1DF000000 DS18B20 temp_wohnzimmer
28.6602AC010000 DS18B20 DS18B20_6602AC010000
28.310CAE010000 DS18B20 DS18B20_310CAE010000
28.69BBDF000000 DS18B20 temp_mischer_vorlauf
28.E912AE010000 DS18B20 DS18B20_E912AE010000
28.A370AC010000 DS18B20 DS18B20_A370AC010000
26.200776000000 DS2438 ds2438_sensor_zisterne
29.568E01000000 DS2408 ds2408_relais
05.10062A000000 DS2405 ds2405_schalter_lueftung_aus
1D.601209000000 DS2423 ds2423_zaehler_strom
Allerdings läuft mein pi seit dem Kernel-Update wieder mit 700 Mhz - vorher hatte ich 950 Mhz weil bei mir außer FHEM noch weitere Leistungshungrige Anwendungen (Zoneminder) laufen...
Ich werde den Takt mal wieder hochsetzen und dann Berichten...
Wow! Auch ne ganze Menge & schön, das es läuft!
Da bei mir keine Performance-kritischen Anwendungen laufen, lasse ich meine Rpis auf Standard-Takt.
Bei meinen ersten Versuchen mit höherem Takt hab ich mir die Daten auf der SD Karte fragmentiert (SD-Card Data-Corruption), seit dem lasse ich die Finger davon.
Bei mir steht jetzt noch auf dem Plan den Stromzähler einzubinden und die Rücklauf-Temperatur der Heizung mit auf zu nehmen. Ich glaube dann hab ich so langsam alles zusammen.
VG
Ralf
Bis jetzt läuft alles...
Da Kernel-Update scheint es gebracht zu haben.
Dann kann ich mal meine FHEM-Konfiguration nochmal sauber von Null aufsetzen und den Misterhouse abschalten.
Ich muss nur mein Webinterface von MH nach FHEM migrieren - aber das ist eine Andere Baustelle ;-)
(siehe Anhang / see attachement)
Gruß,
Thorsten
Moin Thorsten,
kurze off Topic Frage,
Welche Lüftungsanlage hast Du?
gruß Joachim
Also ich habe eine Junkers Aerastar 250 - da ist noch Klappertechnik drin.
Die Lüfterstufen werden über einen Stufentrafo geschaltet,
ich habe die mitgelieferte Fernbedienung durch 4 Finder-Relais ersetzt.
Die Relais steuere ich über einen DS2408 an.
Die Aktuellen Geräte haben eine Fernbedienung mit Display und werden wohl über einen Bus mit der Anlage verbunden.
Bei Bedarf kann ich mal eine ausführliche Beschreibung in mein Blog stellen.
Danke,
dann muss ich doch selber weiter basteln.
Lüftungsanlage Comfoair 550 mit serieller Schnittstelle.
Gruß Joachim
Wie müsste/könnte ich eine Anfrage definieren, wenn ich z.B. 5 Messwerte innerhalb kurzer Zeit brauche, um einen Wert zu mitteln?
Wenn ich es innerhalb eines Programms mache, möchte ich fhem mit "sleep" nicht länger als 5 Sekunden blockieren, aber dann bekomme ich auch mit Setting uncached 5 mal den selben AD Wandler Wert, eben so wie OWServer ihn liefert.
Gibt es da eine andere Möglichekeit?
VG
Ralf
...ich möchte die Gelegenheit nutzen, um mal eine Lanze für die vielgeschundene Stabilität des RPi zu brechen. Bei mir laufen 4 Stück im Dauerbetrieb. 2 Stk 256er und 2 Stk 512er.
Einer als openELEC xbmc am Fernseher,
einer als Remote OWServer in der Halle,
einer als fhem Backup-Server mit CUL & COC & 1Wire,
einer als TestGerät mit OWServer, LogitechMediaServer, MediaClient.
Alle verfügen über die aktuellen Updates und laufen mit dem standard-Takt seit vielen Tagen ohne einen einzigen Reboot.
Ich kann aktuell nicht nachvollziehen, warum behauptet wird die Dinger seien nicht stabil.
Das Einzige, was bei mir Schwierigkeiten macht, ist der squeezelite MediaClient. Aber das Problem scheint bekannt. Wenn ich den Prozess ab und zu neu starte, stört das den RPi aber überhaupt nicht.
VG
Ralf
Hi,
Blöde Frage bevor ich was falsches tue: laufen die module auch mit einem cuno?
Danke.
W
Vlt. mal das Modul NT5000.pm unter "contrib" anschauen. Das bedient einen Sunways NT5000 Wechselrichter mit serieller Schnittstelle.
LG
pah
Nein, weil das darunter liegende OWFS nicht auf dem CUNO arbeitet.
Der CUNO (und auch COC) wird unterstützt vom Backendmodul OWX und den zugehörigen Frontendmodulen OWAD,OWCOUNT,OWID etc. Diese fragen die Schnittstelle ab, die die Firmware des CUNO (culfw) zu 1-Wire bietet - und da liegt ein erheblicher Schwachpunkt. Denn diese Firmware sorgt ab und zu dafür, dass sich der CUNO aus der gesamten Kommunikation verabschiedet. Das ist aber keine Schuld der OWX-Module - sondern dasselbe Verhalten entsteht reproduzierbar, wenn man den CUNO direkt von Hand über raw-Kommandos abfragt.
Diese Diskussion wurde bei FHEM schon mehrfach geführt, und hat schon erhebliche Streitereien nach sich gezogen.
Der langen Rede kurzer Sinn: CUNO und 1-Wire geht mit OWX, kann aber bei Installationen mit viel Funkverkehr und komplizierter 1-Wire Kommunikation zu Problemen führen. Die Module OWAD, OWCOUNT etc. unterstützen allerdings auch OWServer als Backend. Bei mir läuft inzwischen auf einem Raspberry Pi ein wild gemischtes System, in dem die Frontendmodule OWAD, OWCOUNT etc.
- drei verschiedene USB/1-Wire-Adapter über OWX-Backend
- einen CUNO über OWX-Backend
- einen COC über OWX-Backend
- einen separaten RaspberryPi mit OWFS über OWServer
bedienen.
LG
pah
Die stabile und straight forward Variante wäre ein Raspberry Pi mit installiertem owserver zu verwenden.
Zusammen mit einem geeigneten OW Adapter (gibt hier viele Beispiele im Forum) bildet das eine kostengünstige und belastbare Basis für den Einsatz der OWServer/OWDevice Module.
Alles andere hab ich nicht vernünftig ans Laufen bekommen.
CUNO wird gebraucht, wenn eine über das LAN abgesetzte Funk-Schnittstelle benötigt wird.
VG
Ralf
Habe das 70_NT500.pm zum Testen aus dem SVN geladen: Klappt super. Und das ohne Solaranlage, nur mit Emulator.
Leider kann ich nirgends die zugehörigen nt5000*.gplot Dateien finden... So bleiben mir die feien Ansichten verschlossen.
Jorge
Hi Jorge,
schreibt dir doch so ein gplot eben selber. Hab mich da auch kurz einarbeiten müssen - war aber nicht schlimm.
VG
Ralf
Bitte diese Diskussion in den Thread "NT5000 Solar Inverter" im Forumsteil "Sonstiges" verlagern.
Denn mit dem Thema, das hier disktuiert wird, hat das nun wirklich nichts zu tun - und mit den Autoren dieses Threads noch weniger.
Direkter Link zum neuen Thread (dort gibt es auch die Plotbeispiele)
http://forum.fhem.de/index.php?t=tree&goto=70926&rid=376#msg_70926 (//forum.fhem.de/index.php?t=tree&goto=70926&rid=376#msg_70926)
LG
pah
Hi Ralf,
Zitat von: dougie schrieb am Di, 15 Januar 2013 16:59Update:
Das Kernel-Update hat auf alle Fälle was gebracht. Der RPi mit dem MP00202 USB Adapter läuft seit heute Morgen einwandfrei und ohne einen Hänger.
Kann ich also für alle Betroffenen empfehlen. Anleitung: hier -> https://github.com/Hexxeh/rpi-update
Habe mich exakt an die Anleitung gehalten, aber sowie ich auf irgendein USB-Gerät (hier UsbStick mit usbIP) zugreifen möchte gibts fehler, bzw das GErät ist nicht mehr verfügbar.
pi@raspberrypi ~ $ ls -ail /dev/sda*
4013 brw-rw---T 1 root floppy 8, 0 Mär 30 19:28 /dev/sda
4014 brw-rw---T 1 root floppy 8, 1 Mär 30 19:28 /dev/sda1
pi@raspberrypi ~ $ sudo usbip bind --busid 1-1.2
usbip: error: unable to bind device on 1-1.2
pi@raspberrypi ~ $ ls -ail /dev/sda*
ls: Zugriff auf /dev/sda* nicht möglich: Datei oder Verzeichnis nicht gefunden
pi@raspberrypi ~ $
@raspberrypi ~ $ uname -a
Linux raspberrypi 3.6.11+ #401 PREEMPT Fri Mar 29 22:59:09 GMT 2013 armv6l GNU/Linux
Gibts ev noch etwas zu beachten bei usb-Nutzung
Hallo Thread-Mitleser,
ich würde Morgen auch gerne meine ersten Gehversuche mit den "neuen 1-Wire-Modulen für RPi", machen und habe gerade einen DS 2482-100S auf einen ADP-SO 8 Adapter gelötet. Nun habe ich aber festgestellt, dass ich nur rückstellende Sicherungen mit 250 mA statt 200 mA und keine 60 Ω-EMV-Ferrit-Entstörfilter habe.
Daher meine Fragen:
- wie groß ist die Gefahr, den RPi zu bricken, wenn ich es ohne bzw. den stärkeren Sicherungen versuche?
- funktioniert das Ganze anfangs evtl. auch ohne die Entstörfilter?
Edith fragt noch: Gibt es einen bedrahteten Ersatztyp zum BSS123 aus Ralfs Schaltplan (http://forum.fhem.de/index.php?topic=9707.msg58007#msg58007)? Im Lesen von (vor allem englischen) Datenblättern scheitere ich regelmäßig und die Ersatztypen u.a. auf mikrocontroller.net (//www.mikrocontroller.net/part/BSS123) sind (für mich) nicht zielführend.
Zunächst würde ich einen (oder zwei) DS18B20+ anschließen wollen (im Endausbau einige mehr) sowie (wenn es geht) einen von Ralfs (aka Dougie) alternativen 1-Wire Countern (http://forum.fhem.de/index.php?topic=10962.0) (wobei ich noch schauen muss, ob die Spannungsversorgung vom RPi dafür ausreicht).
Das ganze soll auf einem neuen RPi erfolgen, den ich gleich schon mal mit Raspbian usw. bestücken werde (FHEM läuft auf einem anderen System).
Die Sicherungen und Filter werde ich gleich noch bestellen, käme dann aber erst am kommenden Wochenende zum testen. Falls die Gefährdung des RPi zu groß ist, warte ich aber lieber.
Danke und Gruß
Thomas
Anstatt des BSS123 kannst du problemlos auch einen BS170 (Standard FET (Feld-Effekt-Transistor)) nehmen :-)
...und Du kannst problemlos ohne Filter und mit 250mA testen. Trotzdem würde ich bei + und - aufpassen ;-)
Der RPi hat übrigens eingangsseitig einen Verpolschutz, wie ich festgestellt habe...hihi :o ;-)
Hi,
Zitat von: UweH schrieb am So, 07 April 2013 10:05... Trotzdem würde ich bei + und - aufpassen ;-)
+ war da, wo es weh tut? 8-)
Scherz beiseite, ich danke Ralf und Uwe.
Gruß
Thomas
Hallo Ralf,
Zitat von: dougie schrieb am Di, 15 Januar 2013 16:59... Zusätzlich hab ich noch einen Schalttransistor für GPIO 17 ("eingebaut").
Ich muss/möchte mal (als RPi-Outsider) nachfragen: Wofür ist bzw. wozu dient die Beschaltung des GPIO 17?
Danke und Gruß
Thomas
Sooo...
herzlichen Dank an Boris und auch an Ralf, der mich zu dieser Lösung gebracht hat.
Es läuft grundsätzlich, "schön" machen und Einbindung in FHEM kommt ab nächstem Wochenende. Ich hatte zwar ein paar Probleme (owserver zu installieren ist das Eine, zusätzlich owfs das Zweite (mit dem man dann besser "sieht" ;) ), aber die waren lösbar, vor allem durch nochmaliges lesen der Anleitungen und der darin stehenden Angaben.
Da ich ja noch editieren kann: Nun noch ein Bild der Modulnutzung bei mir ;) (5 x alt. DS 2423 Counter von dougie, 2 noch unbenutzt (aber das kommt noch) und 3 x DS18B20+)
(siehe Anhang / see attachement)
Es läuft, loggt und plottet und wartet auf Erweiterung/Ausbau 8)
Gruß
Thomas
Hallo,
ich bin sehr interessiert an der Kombination Raspberry Pi und 1Wire. Allerdings würde ich gerne auf den i2c Busmaster (DS2482-100) Chip verzichten.
Kann ich auch mit der BitBang (GPIO4) Implementation und OWFS arbeiten?
Ich weiss, dass das Modul w1-therm die DS18x20 TemperaturChips verarbeiten kann.
Ich möchte allerdings auch noch S0 Pulse über die Lösung von Dougie (Alternative zum DS2423 Counter) zählen.
Muss da der Busmaster (DS2482) zwingend verwendet werden, oder geht das auch über die BitBang Variante?
Stefan
Vergiss das bitte!
Der 1W Chip macht die gesamte Kommunikation mit dem 1W Bus perfekt nach Standard. Was besseres gibt es nicht. Was spricht dagegen, den zu verwenden?
VG
Ralf