OWSWITCH schaltet nicht

[HRueck]

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

[UweH]

Such mal nach Denkovi und 1wire, genau das Thema wurde vor kurzem diskutiert und gelöst.

[HRueck]

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!

[Flexor]

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

[UweH]

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.

[HRueck]

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.

[Flexor]

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

[HRueck]

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

[Prof. Dr. Peter Henning]

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

[HRueck]

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

[Flexor]

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

[Phill]

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?

sudo 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ß

[eldrik]

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

[ph573]

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:

Code Auswählen Erweitern

 
/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:

Code Auswählen Erweitern


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.

[hefe]

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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern


  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:

Code Auswählen Erweitern

...............(.......D......../29.9D0308000000/PIO.ALL.1,0,0,0,0,0,0,0

Wenn FHEM/OWSWITCH/OWSERVER das macht dann eher so was:

Code Auswählen Erweitern

..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

Code Auswählen Erweitern

<,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