Habe einen DS2408 in einem Relaismodul von DENKOVI am 1-Wire hängen.
owfs, owserver, owhttpd läuft auf dem System, ich kann auf den Baustein über owhttpd zugreifen und die Relais schalten.
In FHEM ist OWSERVER und OWSWITCH eingerichtet.
In OWSWITCH sehe ich die Readings von port A-H.
wenn ich in der Oberfläche des Moduls "set" "output" entweder A ON oder A OFF eingebe, passiert nichts.
auch im log ist nichts zu sehen.
wenn ich von extern über owhttpd die Relais schalte, werden die Zustandsänderungen aber in FHEM angezeigt.
hier die Definitionen:
define 1wire OWServer 127.0.0.1:4304
define Switch1 OWSWITCH 29.4B4816000000 3
attr Switch1 IODev 1wire
attr Switch1 model DS2408
attr Switch1 room OWDevice
wer hilft mir weiter?
Gruss,
Herbert
Such mal nach Denkovi und 1wire, genau das Thema wurde vor kurzem diskutiert und gelöst.
habe den thread gelesen.
die dort diskutierte Sache mit der Spannungsversorgung scheint mir in meinem Fall nicht zuzutreffen, da ich ja die Relais über owhttpd schalten kann, und das läuft ja im gleichen System.
Ich tippe noch auf das Attribut "stateS"
Allerdings ist mir der Sinn und Einsatz dieses Attributs trotz lesen in der Doku und diversen Beiträgen nicht klar.
Vielleicht kann mir ja da jemand auf die Sprünge helfen!
Hallo zusammen,
habe das selbe Problem. Habe einen 0 bis 10 V Steller der einen DS2408 hat.
Der DS2408 wird im owfs erkannt und ich kann ihn auf über owhttpd ansteuern.
FHEM verbindet sich auf den owserver und erkennt auch den DS2408 als OWDevice und zeit auch die Channels an.
Wenn ich ein OWSWITCH erstelle, egal ob mit model id oder fam.id, die Channels werden zwar richtig ausgelesen aber wenn ich versuche über gpio oder output etwas zu setzten, kommt einfach gar nichts. Die Seite ladet neu und das war es.
FHEM ist auf den neuesten Stand. Habe im OWServer Modul auch einen Kommentar gefunden, der besagt, dass man sich das OWNet.pm Modul selbst runterladen soll weil es bei CPAN outdated ist. Habe ich getan aber ohne Erfolg.
mfg
Flexor
Ich such jetzt nicht extra danach, bin aber der Meinung, dass in einem Fall der Busmaster als Ursache identifiziert wurde.
stateS wird in der commandref für OWSWITCH erklärt.
wie schon oben gesagt, habe ich die Commandref gelesen....
ich kapiere die dortige (kurze) Erklärung aber leider nicht.
vielleicht kann mir jemand das für einen noch nicht so Versierten in einfachen Worten erklären.
Mit der Erklärung im Commandref für stateS kann ich auch nicht anfangen.
Ich glaube nicht das es der Bus Master ist. Denn mit owhttpd geht alles und owhttpd benutzt ja auch nur den owserver über das tcp Port.
mfg
Flexor
Ich tippe darauf, dass eventuell in der Installation der ow-Komponenten auf dem System was fehlen könnte.
Man kann ja auf 2 Wegen, entweder über aptitude oder über make install aus der source installieren.
Meine Installation war Version 3.1p0 über make install und dann Startscripts für owfs,owserver und owhttpd.
Funktioniert ja auch, nur halt leider nicht mit FHEM.
Würde nun gerne mal deinstallieren und die apt-get Methode anwenden.
Wie kann ich mein altes ow (mit make install installiert) sauber entfernen, ohne irgenwas zu zerschiessen?
Gruss Herbert
Na Leute, das ist doch wirklich simpel erklärt: "StateS" ist ein String, der an die Anzeige "ON" angehängt wird, wenn der Ausgang EXTERN kurzgeschlossen wird. Schalter und Feststellung des Schaltzustandes gehen nämlich getrennt.
Betreffend das Zusammenspiel zwischen OWSWITCH und Owserver:: Bei OWserver hat sich vieles geändert, auch auf der FHEM-Seite. Nicht auszuschließen ist aus meiner Sicht, dass dabei die Zusammenarbeit mit OWSWITCH nachhaltig gestört wurde. Das wäre zwar leicht zu beheben, ich habe aber im Moment aus beruflichen Gründen nicht die Zeit dafür. Der Code steht in der subroutine sub OWFSSWITCH_SetState($$) ab Zeile 960 - Zeile 1004 des OWSWITCH-Moduls.
LG
pah
Heureka!!!
also ich habe das Problem für meinen Teil gelöst.
ich habe ow* das ich manuell installiert habe entfernt und mit apt-get neu installiert.
und sieheda, alles funzt!
bliebe nur noch zu klären, was der Unterschied zwischen einer Installation mit "make install" und "apt-get" ist.
Gruss und schöne Feiertage,
Herbert
Hallo zusammen,
Der Unterschied liegt wahrscheinlich darin das du über apt-get die Version 2.8 bekommst wo es die erwähnten Änderungen am owserver noch nicht gibt.
Das Problem ist alles lauft bei mir auf einem PI. Das owfs Repository lieft aber leider kein Paket für die ARMHF, nur für ARMEL.
Ich werde mir mal die OWFSSWITCH_SetState($$) Routine ansehen, viellecht komm ich ja zu einem Ergebnis.
mfg
Flexor
Hallo,
Bei mir ist exakt das selbe Problem. Über owfs httpserver lässt sich der PIO setzen über FHEM nicht.
Gibt es Fortschritte bei dir oder gibt es eine Lösung mittlerweile?
Zitatsudo apt-cache policy owserver
owserver:
Installiert: 2.9p8-6
Installationskandidat: 2.9p8-6
Versionstabelle:
*** 2.9p8-6 0
500 http://ftp.de.debian.org/debian/ stable/main armhf Packages
100 /var/lib/dpkg/status
Gruß
Zitat von: Phill am 01 Mai 2015, 12:13:21
Hallo,
Bei mir ist exakt das selbe Problem. Über owfs httpserver lässt sich der PIO setzen über FHEM nicht.
Gibt es Fortschritte bei dir oder gibt es eine Lösung mittlerweile?
Gruß
Mal andere owfs Version prüfen 2.8...
http://forum.fhem.de/index.php/topic,33478.msg259395.html#msg259395
Greetz
Eldrik
Ich habe ein verzweigtes sternförmiges 1-Wire Netzwerk mit zwei Hubs im Einsatz. Die Hubs werden ab OWFS Version >= 3.0pX unterstützt. Systematisches Durchtesten verschiedener OWFS Versionen zeigt nur bis Version 2.8pX funktioniert das Auslesen und auch das Schalten über FHEM (PIO) zuverlässig.
Wie beide disjunkten Anforderungen unter einen Hut zu bringen? Ich habe die Fähigkeit des OWFS OWSERVER eingesetzt, der es ermöglicht OWSERVER miteinander zu verbinden und 1-wire-Informationen durchzuschleifen. Ich setze die Version 3.1p0 als "Frontend" für meine Hubs ein, die Version 2.8p21 für FHEM und habe mittels der Option "-s" beide owserver verbunden. Ich habe zwei Versionen kompiliert und in verschiedene Verzeichnisse installiert.
In meinem Startup-Script steht:
/opt/owfs31/bin/owserver -C --masterhub=/dev/ttyACM0 --masterhub=/dev/ttyACM1 -p 4305
/opt/owfs28/bin/owserver -C -s 4305 -p 4304
sleep 3
/opt/owfs28/bin/owfs -m /1wire -s 4304
In FHEM ist konfiguriert:
define OWFS_IF OWServer localhost:4304
Damit ist es mir möglich neuere 1-wire Komponenten einzusetzen und in Ruhe das Nachziehen bei FHEM abzuwarten.
Hi Alle, ich habe das gleiche Problem.
Am Linux-Rechner hängt ein LinkUSBi (USB FTTI Serial DS9097U) und daran per OneWire neben ein Paar (4 Stück) Parasitären DS18B20 und DS18S20 eine 8 Port Relaiskarte mit nem DS2408 mit eigener Stromversorgung.
Früher lief das System direkt mit FHEM --> OWSWITCH --> OWX (direkt ans serial device /dev/onewire) zuverlässig aber manchmal zeitverzögert. Wegen den Timing-Problemen die vermutlich an den Parasitären DS18x20 (?) hängt versuche ich seit Wochen die Kombination FHEM --> OWSWITCH --> OWSERVER, aber leider schaltet der DS2408 nicht. Alles andere funktioniert (Temperatursensoren).
Nebenbei: Der OWSERVER (Version 3.1p0) mit OWHTTPD (V 3.1p0) funktioniert einwandfrei und schaltet die Relais zuverlässig.
Ich hab hier ein paar Logs vom OWSERVER (error-level=9) die auf die Ursache hinweisen könnten, leider fehlt mir aber etwas Fachwissen um das genau deuten zu können. Vielleicht kann das aber der eine und/oder andere von euch Developern...
Ein einfaches set OWSW gpio 255 endet in der Fehlermeldung "Error interpreting input value" und "Error writing to /29.9D0308000000/PIO.ALL" des OWSERVER.
Siehe Log-Auszug des OWSERVER:
DEBUG: handler.c:(132) OWSERVER tcp connection persistence -- reusing connection now.
DEBUG: ow_tcp_read.c:(63) attempt 24 bytes Time: 10.000000 seconds
DEBUG: ow_tcp_read.c:(113) read: 24 - 0 = 24
DEBUG: from_client.c:(66) FromClient payload=41 size=15 type=3 sg=0x10E offset=0
DEBUG: from_client.c:(74) FromClient (no servermessage) payload=41 size=15 type=3 controlflags=0x10E offset=0
DEBUG: ow_tcp_read.c:(63) attempt 41 bytes Time: 10.000000 seconds
DEBUG: ow_tcp_read.c:(113) read: 41 - 0 = 41
DEBUG: handler.c:(73) Persistence requested
DEBUG: handler.c:(153) START handler /29.9D0308000000/PIO.ALL
CALL: data.c:(103) DataHandler: parse path=/29.9D0308000000/PIO.ALL
DEBUG: ow_parseobject.c:(163) /29.9D0308000000/PIO.ALL
CALL: ow_parsename.c:(102) path=[/29.9D0308000000/PIO.ALL]
DEBUG: ow_cache.c:(912) Looking for device 29 9D 03 08 00 00 00 8A
DEBUG: ow_cache.c:(1070) Search in cache sn 29 9D 03 08 00 00 00 8A pointer=0x7f63c5032134 index=0 size=4
DEBUG: ow_cache.c:(1086) Value found in cache. Remaining life: 76 seconds.
DEBUG: ow_presence.c:(76) Found device on bus 0
CALL: data.c:(149) Write message
DEBUG: write.c:(51) WriteHandler: hd->sm.payload=41 hd->sm.size=15 hd->sm.offset=0 OWQ_size=15 OWQ_offset=0
DEBUG: ow_parseobject.c:(114) /29.9D0308000000/PIO.ALL with extension 0
OWQ OneWireQuery structure of /29.9D0308000000/PIO.ALL
OneWireQuery size=15 offset=0, extension=-1
Byte buffer OneWireQuery buffer, length=15
--000: 2C 30 2C 30 2C 30 2C 30 2C 30 2C 30 2C 30 00
<,0,0,0,0,0,0,0.>
Cleanup = 0012 OneWireQuery I=-1275064096 U=3019903200 F=6.92019E-310 Y=-1275064096 D=
--- OneWireQuery done
DEBUG: ow_write.c:(136) Error interpreting input value.
DEBUG: ow_write.c:(112) Error writing to /29.9D0308000000/PIO.ALL
DEBUG: ow_parsename.c:(61) /29.9D0308000000/PIO.ALL
DEBUG: data.c:(193) DataHandler: FS_ParsedName_destroy done
DEBUG: data.c:(207) DataHandler: cm.ret=-22
DEBUG: to_client.c:(76) payload=0 size=0, ret=-22, sg=0x10E offset=0
DEBUG: to_client.c:(85) No data
DEBUG: data.c:(226) Finished with client request
Ich hab auch mal auf localhost gesnifft, um zu sehen was der unterschied zwischen dem was OWHTTPD im Vergleich zu FHEM/OWSWITCH/OWSERVER macht, dabei fällt folgendes auf:
schreib ich das PIO.ALL an den 2408 per OWHTTPD geht z.B. so was über die Leitung:
...............(.......D......../29.9D0308000000/PIO.ALL.1,0,0,0,0,0,0,0
Wenn FHEM/OWSWITCH/OWSERVER das macht dann eher so was:
..e...Z........)................/29.9D0308000000/PIO.ALL.1,1,1,1,1,1,1,1.
Man beachte den zusätzlichen Punkt am Ende der Zeile.
Das passt mit dem Wert in der spitzen Klammer beim OWSERVER Debug zusammen, da ist wohl auch ein zusätzlicher Punkt drin <,0,0,0,0,0,0,0.> und es sind nur sieben (statt acht) Nullen.
Vielleicht hilfts. Wäre toll.
Liebe Grüße
de hefe
Ich schau es mir an - wird aber sicher bis zum Wochenende dauern.
Bitte mal einen Versuch machen, der nicht nur aus 1 oder 0 besteht. Sondern idealerweise mit 10000000 und mit 00000001
LG
pah
Wie eldrik schon sagte. Bei OWSERVER Versionen über die 2.8 hinaus lassen sich via fhem definitv keine 2408 schalten. Downgrade- dann funktionierts auch. Habe auch schon einige Zeit damit verplempert.
Joachim
Sicher, dass das nur dieser bekannte Fehler ist, d.h. tritt das auch mit OWDevice auf ? Dann kann ich mir die Arbeit sparen.
LG
pah
Hi, so, ein Tag ist rum, die Familie im Bett un de Vadder bastelt wieder:
@pah: Hier die gewünschten OWSERVER Logs:
set OWSW output A on
ergibt
CALL: data.c:(149) Write message
DEBUG: write.c:(51) WriteHandler: hd->sm.payload=41 hd->sm.size=15 hd->sm.offset=0 OWQ_size=15 OWQ_offset=0
DEBUG: ow_parseobject.c:(114) /29.9D0308000000/PIO.ALL with extension 0
OWQ OneWireQuery structure of /29.9D0308000000/PIO.ALL
OneWireQuery size=15 offset=0, extension=-1
Byte buffer OneWireQuery buffer, length=15
--000: 2C 30 2C 30 2C 30 2C 30 2C 30 2C 30 2C 30 00
<,0,0,0,0,0,0,0.>
Cleanup = 0012 OneWireQuery I=-1946153952 U=2348813344 F=6.92864E-310 Y=-1946153952 D=
--- OneWireQuery done
DEBUG: ow_write.c:(136) Error interpreting input value.
DEBUG: ow_write.c:(112) Error writing to /29.9D0308000000/PIO.ALL
DEBUG: ow_parsename.c:(61) /29.9D0308000000/PIO.ALL
DEBUG: data.c:(193) DataHandler: FS_ParsedName_destroy done
DEBUG: data.c:(207) DataHandler: cm.ret=-22
DEBUG: to_client.c:(76) payload=0 size=0, ret=-22, sg=0x10E offset=0
DEBUG: to_client.c:(85) No data
DEBUG: data.c:(226) Finished with client request
und
set OWSW output H on
zeigt
CALL: data.c:(149) Write message
DEBUG: write.c:(51) WriteHandler: hd->sm.payload=41 hd->sm.size=15 hd->sm.offset=0 OWQ_size=15 OWQ_offset=0
DEBUG: ow_parseobject.c:(114) /29.9D0308000000/PIO.ALL with extension 0
OWQ OneWireQuery structure of /29.9D0308000000/PIO.ALL
OneWireQuery size=15 offset=0, extension=-1
Byte buffer OneWireQuery buffer, length=15
--000: 2C 30 2C 30 2C 30 2C 30 2C 30 2C 30 2C 31 00
<,0,0,0,0,0,0,1.>
Cleanup = 0012 OneWireQuery I=-1946153904 U=2348813392 F=6.92864E-310 Y=-1946153904 D=
--- OneWireQuery done
DEBUG: ow_write.c:(136) Error interpreting input value.
DEBUG: ow_write.c:(112) Error writing to /29.9D0308000000/PIO.ALL
DEBUG: ow_parsename.c:(61) /29.9D0308000000/PIO.ALL
DEBUG: data.c:(193) DataHandler: FS_ParsedName_destroy done
DEBUG: data.c:(207) DataHandler: cm.ret=-22
DEBUG: to_client.c:(76) payload=0 size=0, ret=-22, sg=0x10E offset=0
DEBUG: to_client.c:(85) No data
DEBUG: data.c:(226) Finished with client request
und ... OWDevice mit OWSERVER hat bei mir auch nicht funktioniert, das ist aber gleich getestet.
Liebe Grüße
Hefe
HI @all,
mit OWDEVICE und OWSERVER hab ich das gleiche Problem. Der 2408 schaltet nicht.
Im OWSERVER Debug ist der Wert in der spitzen Klammer immer um eine Stelle nach Links verschoben, das erste zeichen Links fehlt und rechts kommt ein Punkt hinzu.
z.B.
set DS2408_9D... PIO.BYTE 123
ergibt im OWSERVER Debug
<23.>
Hilft das jetzt weiter oder ist's vergebliche Liebesmühe?
Liebe Grüße
Hefe
Das hilft sehr viel weiter, denn es bedeutet, dass die Fehlerquelle nicht in OWSWITCH zu finden ist. Sondern dass der zu setzende Wert in Zeile 982 korrekt an OWServer weiter gegeben wird, OWServer aber mit der bemängelten Version von OWFS nicht fertig wird.
Spart mir viel Arbeit, danke.
LG
pah
Hi pah, was bedeutet das jetzt für die User mit dem Problem (wie z.B. mich)?
Kann das jetzt jemand anderes reparieren?
LG
hefe
Hai,
Du musst mit dpkg -r die entsprechenden 1wire Pakete deinstallieren. Die Konfigdateien bleiben somit erhalten. Lade Dir von http://www.fhemwiki.de/wiki/OWServer_&_OWDevice (http://www.fhemwiki.de/wiki/OWServer_&_OWDevice) das Paket owfs_2.8p17-1_all.zip runter und installiere die notwendigen Module. Dann klappts auch...
Joachim
Hi Joachim,
die Sache mit der alten Version von OWFS kenn ich schon. Das wäre vermutlich eine Lösung wenn ich eine Debian basierte Linux Distribution einsetzen würde. Ich fahr allerdings Arch Linux und da gibt es im AUR nur die Version 3.10. Ne alte OWFS Version gibt's nicht.
Meine wichtigste Frage ist allerdings: Will ich das überhaupt? Will ich eine alte Version von OWFS installieren? ;) IMHO nicht nachhaltig, da jeder neue FHEM/OneWire User erst mal in das gleiche Loch fallen wird...
Ich hab mich hier im Forum angemeldet und mir gerne die Zeit genommen zu versuchen den Entwicklern (ich bin keiner... eher so der Netzwerk/WLAN/Sysadmin) zu helfen dem Problem auf die Schliche zu kommen. Wenn ich PAH richtig verstanden habe, dann sind die Module OWDEVICE und OWSWITCH nicht das Problem, sondern wahrscheinlich das FHEM-Modul OWSERVER, welches zumindest teilweise (beim WRITE ins OneWire) inkompatibel mit Versionen von OWFS (>Version 2.8) ist.
Macht es jetzt sinn, mit den Erkenntnissen aus diesem Thread an die Entwickler des OWSERVER FHEM Moduls zu gehen und mal zu fragen wie es mit dem Problem steht? Soll/Kann ich das machen? Macht es evtl. mehr Sinn, wenn PAH das machen würde (weil er denen als Entwickler evtl. das Problem besser beschreiben kann)?
Liebe Grüße
de Hefe
ZitatMacht es evtl. mehr Sinn, wenn PAH das machen würde
Sonst noch Probleme ?
pah
Hi pah, ich verstehe ... also "Nein".
Dann versuch ich mal mein Glück bei den Entwicklern von 10_OWServer.pm
Liebe Grüße
de Hefe
Habe heute endlich meinen BananaPi in Betrieb genommen. Leider bin ich nun auch von diesem Fehler betroffen, da ich jetzt OWServer für die 1Wire Anbindung verwende. Gibt es hier schon eine Lösung?
Oder kann ich alternativ meine 3 mit i2c angeschlossenen DS2482-100 unter Linux noch anders einbinden ?
Damit OWSWITCH mit den neueren Versionen des OWServer funktioniert ist die Datei OWNet.pm in Verzeichnis FHEM/lib durch die aktuelle zu ersetzten. Diese befindet sich im Sourcearchive unter folgendem Link:
https://sourceforge.net/projects/owfs/files/owfs/3.1p5/owfs-3.1p5.tar.gz/download (https://sourceforge.net/projects/owfs/files/owfs/3.1p5/owfs-3.1p5.tar.gz/download)
Die Datei OWNet.pm ist im Verzeichnis
module/ownet/perl5/OWNet/lib