Neuartiges 1-Wire Interface

Begonnen von Prof. Dr. Peter Henning, 18 Januar 2014, 21:00:45

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten 1 ... 17 18 19 20 21 ... 32
Benutzer-Aktionen

UweH

#270
01 August 2014, 18:10:26
Hallo,

dazu muss ich auch mal meinen Senf dazugeben...ich habe ebenfalls zwei LAN/DS2480-Interfaces laufen (unter OXW_ASYNC, einmal KrisTech und ein Chinateil, siehe diesen Thread weiter vorn), an denen diverse Devices hängen. Erfahrungen bisher:

  • Ich habe mehrere Anläufe gebraucht, bis FHEM kapiert hatte, dass ich zwei Interfaces einrichten möchte. Beim Erstellen der Definition eines Interfaces:
Code Auswählen
define 1wire_1 OWX_ASYNC xxxxx
    über die Kommandozeile geht noch alles gut, beim zweiten friert FHEM ein. Jedesmal und reproduzierbar. Ich habe dann die fhem.cfg auf der Konsole editiert und rebootet. Auch da braucht's schon mal zwei- oder drei FHEM Neustarts, bevor die Verbindungen da sind. Dazu muss aber vorher die Stromversorgung der Interfaces kurz unterbrochen bzw. ein Restart des Interfaces durchgeführt werden, sonst gibt's keine Verbindung. Sehr merkwürdig. [/li]
  • Nach einem "shutdown restart" werden die Verbindungen meist wieder hergestellt, aber eben auch nicht immer. Dann hilft ein Restart der Interfaces (siehe oben...) und FHEM bekommt sie sofort zu fassen. 
  • Ein Ausfall eines Interfaces nimmt FHEM hin und bleibt am Leben, nach ca. 1min wird die Verbindung auf "disconnected" gesetzt. Nachdem das Interface wieder aktiviert wurde, braucht FHEM dann auch ca. 1 min, bis die Verbindung wieder steht. Sehr hübsch  :)
  • Und: Wenn die Interfaces laufen, dann laufen sie auch. Während des "normalen" Betriebes kam es bisher zu keinem Verbindungsabbruch  :)

@ntruchsess:
Soweit also schon sehr gut, nur das Problem, dass OWX_ASYNC die Verbindung zu einem schon ewig laufenden Interface nicht mehr aufbaut, kannst Du hoffentlich noch beheben. Es sei denn, das betrifft nur mich...  >:(
Daten dazu kann ich gerne liefern, wenn Du mir sagst, was Du brauchst.
Das Interface ist dann übrigens anpingbar, die Weboberfläche erreichbar. Nur für OWX_ASYNC existiert es offenbar nicht.

det.

#271
01 August 2014, 18:35:32
wenn schon die Meckerecke heute geöffnet hat - meine 2 USB Interface an dem. Cubie2 bringen im ASYNC Modus zwar FHEM  nicht zum Absturz, aber letztes Wochenende in Urlaub gefahren, da lieferte eines davon (das aus China) keine Werte mehr. Über VPN shutdown restart - ging kurz, dann wieder keine Werte. Der China Adapter hat keine serial - werde morgen mal gegen einen anderen tauschen und berichten.
LG
det.

UweH

#272
01 August 2014, 18:59:53
Zitat von: det. am 01 August 2014, 18:35:32
wenn schon die Meckerecke heute geöffnet hat

Oh, bitte nicht missverstehen, mein Beitrag vorhin soll kein Meckern gewesen sein...wir testen ja schließlich.

det.

#273
01 August 2014, 19:03:40
Zitat von: UweH am 01 August 2014, 18:59:53
Oh, bitte nicht missverstehen, mein Beitrag vorhin soll kein Meckern gewesen sein...wir testen ja schließlich.
na... das war ironisch gemeint - wenn wir Dysfunktionen nicht melden, kann sie Norbert auch nicht beseitigen
LG
det.

UweH

#274
01 August 2014, 19:08:46
 :) 8) Jo

Ich hoffe, dass ich am WE noch dazu komme, den dritten LAN/1-Wire-Adapter zusammen zu löten, dann quäle ich OWX_ASYNC mit drei von den Dingern... :o

ntruchsess

#275
03 August 2014, 21:41:43 Letzte Bearbeitung: 03 August 2014, 22:12:07 von ntruchsess
Zitat von: Peter_64 am 01 August 2014, 12:36:10
Die Einstellungen buspower -> parasitic und maxtimeouts -> 1 denke sollten passen. Gibt es eine alternative die Fühler zu aktivieren ?
Wenn Du die Sensoren in der fhem.cfg umbenennst, dann werden Sie beim Starten bzw. get <...> devices nicht gelöscht. Nur - wenn die Devices bei der Bussuche nicht antworten, dann wahrscheinlich beim normalen Auslesen auch nicht :-(
Ich seh schon, ich muss das mit parasitärer Versorgung selber mal testen...

Zitat von: UweH am 01 August 2014, 18:10:26
Beim Erstellen der Definition eines Interfaces:
Code Auswählen
define 1wire_1 OWX_ASYNC xxxxxüber die Kommandozeile geht noch alles gut, beim zweiten friert FHEM ein.
Das muss ich mir erst mal näher ansehen, so aus dem Stegreif habe ich da keine Erklärung für. Zum Glück habe ich ja 2 Ethernet<->1Wire Interfaces zum testen da...
Zitat von: UweH am 01 August 2014, 18:10:26
Dazu muss aber vorher die Stromversorgung der Interfaces kurz unterbrochen bzw. ein Restart des Interfaces durchgeführt werden, sonst gibt's keine Verbindung.[...]meist wieder hergestellt, aber eben auch nicht immer. Dann hilft ein Restart der Interfaces (siehe oben...)
Wenn ein FHEM-seitiger Verbindungsneuaufbau nicht geht, dann liegt das am Interface, das keine neue Verbindung entgegen nimmt, auch wenn die vorherige Verbingung geschlossen wurde. Spätestens beim FHEM-neustart wird der Socket beim beenden des Perl-prozesses zuverlässig geschlossen - wenn das Interface damit nicht klarkommt ist das natürlich schlecht. Deshalb geht es nach einem Interface-reset auch sofort wieder, OWX_ASYNC versucht regelmäßig wieder neu zu verbinden - bis es eben klappt. Wenn das Interface keine neue Verbindung entgegen nimmt, dann kann man FHEM-seitig daran nichts ändern :-(
Eventuell geht es besser, wenn man das Interface nicht als Server laufen läßt, sonder so einstellt, dass OWX_ASYNC einen Serversocket öffnet und das Interface sich dahin verbindet. Im FRM habe ich das so gelöst - das muss ich aber erst ins OWX_ASYNC implementieren...
Wenn die Verbindung erst mal steht, macht es keinen Unterschied.

Gruß,

Norbert
while (!asleep()) {sheep++};

eldrik

#276
04 August 2014, 08:04:28
Zitat von: ntruchsess am 03 August 2014, 21:41:43
Wenn ein FHEM-seitiger Verbindungsneuaufbau nicht geht, dann liegt das am Interface, das keine neue Verbindung entgegen nimmt, auch wenn die vorherige Verbingung geschlossen wurde. Spätestens beim FHEM-neustart wird der Socket beim beenden des Perl-prozesses zuverlässig geschlossen - wenn das Interface damit nicht klarkommt ist das natürlich schlecht. Deshalb geht es nach einem Interface-reset auch sofort wieder, OWX_ASYNC versucht regelmäßig wieder neu zu verbinden - bis es eben klappt. Wenn das Interface keine neue Verbindung entgegen nimmt, dann kann man FHEM-seitig daran nichts ändern :-(
Eventuell geht es besser, wenn man das Interface nicht als Server laufen läßt, sonder so einstellt, dass OWX_ASYNC einen Serversocket öffnet und das Interface sich dahin verbindet. Im FRM habe ich das so gelöst - das muss ich aber erst ins OWX_ASYNC implementieren...
Wenn die Verbindung erst mal steht, macht es keinen Unterschied.

Gruß,

Norbert

Hi,

genau das Verhalten  habe ich in der Vergangenheit bei dem Kristech Teil in Verbindung mit socat und OWServer als auch OWX bereits beobachten können, scheinbar nimmt das Interface nach einem Fhem Abbruch keine Verbindungen mehr entgegen oder der 1Wire Busmaster lässt sich nicht neu initialisieren, da das Kristech Teil auch keine Möglichkeit mitbringt es über das Netzwerk neu zu starten ist zwangsweise ein Stecker ziehen notwendig, es sei denn man kann die Stromversorgung anderweitig remote schalten (Homematic etc.) ::) daher fristet es sein Dasein derzeit in der Schublade :( und es werkeln weiter die Raspberrys mit Uwes 1Wire Aufsteckmodul in meinen Unterverteilungen...

Greetz
Eldrik

Peter_64

#277
04 August 2014, 08:47:59 Letzte Bearbeitung: 04 August 2014, 19:38:49 von Peter_64
Hallo Norbert,
Zitat
,,Nur – wenn die Devices bei der Bussuche nicht antworten, dann wahrscheinlich beim normalen Auslesen auch nicht"

Wenn ich die Devices einzeln in die Konsole klopfe sind Sie alle da, und geben richtige Werte aus. Zum Test habe ich Anschluss autocreate deaktiviert um die Devices zu halten, was auch klappte. Beim Schalten des DS2413 (A off) kam eine Fehlermeldung am Modem(habe ich leider nicht mehr), dann ging nichts mehr auch Neustart FHEM und Stromlos/ Adapter brachen nichts. Mit RPI Neustart waren die Modem wieder aktiv, die Bussuche bringt 1 Device von 7 vorhandenen. Ich hoffe die Infos können Dir helfen...

EDIT:
Hier doch noch die Fehlermeldung welche nach kurzem ordentlichen laufen immer kommt.
Modem1
Init Failed: OWX_SER::Detect 1-Wire bus Modem1: interface not detected, answer was 0x03 0x41 0x43 0x03 0x81

Gruß und danke

corny456

#278
04 August 2014, 15:13:39
Hallo zusammen,

Könnte es vlt. sein das man damit der Reconnect funktioniert und das Kristech Teil neue Verbindungen entgegen nimmt einen Timeout definieren muss?
Standardmäßig steht der auf 0 also kein Timeout...
Siehe Screenshot...

ntruchsess

#279
04 August 2014, 22:23:56
den Timeout auf Seiten des Kristech-interfaces zu setzen ist vielversprechend. Kannst Du das mal testen und berichten? Ich hab vorraussichtlich erst am Wochenende wieder die Gelegenheit dazu...

Gruß,

Norbert
while (!asleep()) {sheep++};

corny456

#280
05 August 2014, 13:58:55
Kann ich machen...
wie konstruiere ich denn am sinnvollsten das Problem um es testen zu können?

eldrik

#281
05 August 2014, 14:05:47
Hi,

ich würde sagen FHEM starten, Kristech anbinden und FHEM nach dem Einlesen von Sensoren und eines Save von FHEM, hart beenden und danach wieder versuchen normal eine Verbindung herzustellen.

Greetz
Eldrik

corny456

#282
05 August 2014, 14:59:45
Hallo,

Also...
1. im Kristech einen Timeout von 5 Sekunden eingestellt.
2. FHEM hat eine Verbindung und bekommt werte von den DS18B20.
3. killall perl
4. Käffchen geholt.
5. service fhem start

Hier das log...  :-\
Code Auswählen

2014.08.05 14:48:36 1: 192.168.178.40:23 disconnected, waiting to reappear (1W_IF_ETH_1_1)
2014.08.05 14:48:36 1: 192.168.178.40:23 reappeared (1W_IF_ETH_1_1)
2014.08.05 14:48:36 1: 192.168.178.40:26 disconnected, waiting to reappear (1W_IF_ETH_1_2)
2014.08.05 14:48:36 1: 192.168.178.40:26 reappeared (1W_IF_ETH_1_2)
2014.08.05 14:48:42 1: 192.168.178.40:23 disconnected, waiting to reappear (1W_IF_ETH_1_1)
2014.08.05 14:48:42 1: 192.168.178.40:23 reappeared (1W_IF_ETH_1_1)
2014.08.05 14:48:42 1: 192.168.178.40:26 disconnected, waiting to reappear (1W_IF_ETH_1_2)
2014.08.05 14:48:42 1: 192.168.178.40:26 reappeared (1W_IF_ETH_1_2)
2014.08.05 14:48:48 1: 192.168.178.40:23 disconnected, waiting to reappear (1W_IF_ETH_1_1)
2014.08.05 14:48:48 1: 192.168.178.40:23 reappeared (1W_IF_ETH_1_1)
2014.08.05 14:48:48 1: 192.168.178.40:26 disconnected, waiting to reappear (1W_IF_ETH_1_2)
2014.08.05 14:48:48 1: 192.168.178.40:26 reappeared (1W_IF_ETH_1_2)


dann mal einen shutdown restart  :-\
Code Auswählen

2014.08.05 14:56:44 3: OWX_ASYNC_Disconnect
2014.08.05 14:56:44 1: 192.168.178.40:23 disconnected, waiting to reappear (1W_IF_ETH_1_1)
2014.08.05 14:56:44 1: 192.168.178.40:23 reappeared (1W_IF_ETH_1_1)
2014.08.05 14:56:44 3: OWX_SER::Detect 1-Wire bus 1W_IF_ETH_1_1: interface master DS2480 detected for the first time
2014.08.05 14:56:50 3: OWX_ASYNC_Disconnect
2014.08.05 14:56:50 1: 192.168.178.40:26 disconnected, waiting to reappear (1W_IF_ETH_1_2)
2014.08.05 14:56:50 1: 192.168.178.40:26 reappeared (1W_IF_ETH_1_2)
2014.08.05 14:56:50 3: OWX_SER::Detect 1-Wire bus 1W_IF_ETH_1_2: interface master DS2480 re-detected
2014.08.05 14:56:50 3: OWX_ASYNC_Disconnect
2014.08.05 14:56:50 1: 192.168.178.40:23 disconnected, waiting to reappear (1W_IF_ETH_1_1)
2014.08.05 14:56:50 1: 192.168.178.40:23 reappeared (1W_IF_ETH_1_1)
2014.08.05 14:56:50 3: OWX_SER::Detect 1-Wire bus 1W_IF_ETH_1_1: interface master DS2480 detected for the first time
2014.08.05 14:56:56 3: OWX_ASYNC_Disconnect
2014.08.05 14:56:56 1: 192.168.178.40:26 disconnected, waiting to reappear (1W_IF_ETH_1_2)
2014.08.05 14:56:56 1: 192.168.178.40:26 reappeared (1W_IF_ETH_1_2)
2014.08.05 14:56:56 3: OWX_SER::Detect 1-Wire bus 1W_IF_ETH_1_2: interface master DS2480 re-detected
2014.08.05 14:56:56 3: OWX_ASYNC_Disconnect
2014.08.05 14:56:56 1: 192.168.178.40:23 disconnected, waiting to reappear (1W_IF_ETH_1_1)
2014.08.05 14:56:56 1: 192.168.178.40:23 reappeared (1W_IF_ETH_1_1)
2014.08.05 14:56:56 3: OWX_SER::Detect 1-Wire bus 1W_IF_ETH_1_1: interface master DS2480 detected for the first time
2014.08.05 14:57:02 3: OWX_ASYNC_Disconnect
2014.08.05 14:57:02 1: 192.168.178.40:26 disconnected, waiting to reappear (1W_IF_ETH_1_2)
2014.08.05 14:57:02 1: 192.168.178.40:26 reappeared (1W_IF_ETH_1_2)
2014.08.05 14:57:02 3: OWX_SER::Detect 1-Wire bus 1W_IF_ETH_1_2: interface master DS2480 re-detected


Grüße Marius

ntruchsess

#283
05 August 2014, 15:42:10
5 Sekunden Timeout ist wohl etwas arg kurz. Ich weiß ja nicht, was der Timeout genau aussagt, aber wenn es bedeutet, dass nach 5 Sekunden ohne Daten das Interface restartet, dann kann das so nicht funktionieren - dann müsste der Timeout länger sein als die Pausen in der Kommunikation (also länger als das kürzeste eingestellte Interval eines OWX-devices) + Sicherheitszuschlag.

Gruß,

Norbert
while (!asleep()) {sheep++};

corny456

#284
05 August 2014, 16:05:12 Letzte Bearbeitung: 05 August 2014, 16:10:06 von corny456
Auf den Trichter bin ich dann auch gekommen nachdem ich nochmal drüber nachgedacht habe...  ::)

Hab jetzt mal den Intervall der OWID's auf dem Board auf 60 Sekunden und den Timeout des Kristech Moduls auf 120 Sekunden gestellt...
Sieht vielversprechend aus. Die Verbindung wird nach jedem harten beenden von fhem wieder aufgebaut...

Werde das mal weiter beobachten...

Edit:
Komando zurück...
Das Kristech Modul trennt jetzt alle 120 Sekunden die Verbindung. Auch wenn ein device innerhalb der Zeit abgefragt wird.
Drucken
Nach oben Seiten 1 ... 17 18 19 20 21 ... 32
Benutzer-Aktionen