Neuartiges 1-Wire Interface

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

Vorheriges Thema - Nächstes Thema

UweH

Moin,

ich habe das auch grad mal getestet, kann die Erfahrung von corny456 bestätigen. Nach der eingestellten Zeit unterbricht das Modul die Verbindung und OWX_ASYNC baut sie wieder auf.

Wäre auch zu einfach gewesen...  :'(

Peter_64

Hallo Norbert,
mal aktueller Stand...

zu -> einlesen der Sensoren!
Es wird nur ein Sensor von 7 angezeigt (mit get Modem1 ...), aber die 7 manuell angelegten Sensoren laufen seit Tagen stabil und ohne jeden Fehler.

zu ->Reconnect!
Hier habe ich ebenfalls am Kristech den Timeout mit 120 sec. OWID's 60 gesetzt. Nach fhem.cfg speichern kam bei dem Modem disconnect, was auch so blieb, ein anschießender shutdown bringt Init Failed:OWX_SER::Detect 1-Wire bus Modem1:interface not detected answer ...usw. Dann geht nichts mehr, erst wenn ich das Interface stromlos setze und einen shutdown ausführe geht alles wie es soll.

Ich hoffe die Infos können helfen, es läuft ja eigentlich schon ganz gut ...danke.

UweH

Kurzes Statement nach einer Woche Betrieb mit drei LAN/1Wire-Interfaces und zeitweise einem WLAN/1Wire-Interface auf Cubieboard 2 über OWX_ASYNC: Läuft!
Da man den China-Interfaces per Weboberfläche einen Restart verpassen kann, ist die Verbindungsaufnahme nach einem shutdown restart kein Problem.

UweH

Moin,

ich hatte vor längerer Zeit schon einmal in diesem Thread (Seite 15 oder Umgebung) ein paar Bildchen von meinem WLAN/1-Wire-Interface gezeigt... Auf Grund vieler Anfragen, die mich in den letzten Tagen erreichen (ich hatte das Teil vor kurzem mal erwähnt und nun ploppt es hoch...), hier mal ein paar Daten zum WLAN/1-Wire-Interface. Das WLAN-Modul selbst ist eine Empfehlung von pah (s. irgendwo weiter vorn), der Rest ist SMD-Hühnerfutter. Da die eine Hälfte der Schaltung lieber 5V mag und die andere 3,3V, werden kurzerhand beide Spannungen aus der 12V-Versorgungsspannung mittels Schaltregler gewonnen. Die Pegelanpassung erfolgt mit schnellen Optokopplern. Alles zusammen passt in das bewährte 2-fach Hutschienengehäuse.
Wer sich solch ein Teil zusammenschrauben will, kann die Target-Datei bekommen, ich könnte maximal die Platinen liefern. Zeit für Fertiggeräte u. ä. habe ich leider nicht.

tomster

Platine + Bestückungsliste tät's. WiFi-Midul ist ohnehin schon zu mir unterwegs...
Sag an: wie weiter?
Merci & schönen abend!

Peter_64

Auch von meiner seite noch das Statement !

1xLAN/1Wire-Interfaces über OWX_ASYNC:
Alles läuft bestens, 3xds2413, 6 temperature, 1ds2406, auch das einlesen der Sensoren geht bestens auf einmal ?
Danke Tobias




Alexander Bauer

Hallo,

ich habe auch einen Kristech am laufen.

Auch ich habe das Problem, das der Apdater nach einem Verlust der Verbindung keine neue Verbindung akzeptiert. Zwischenzeitlich habe ich Kontakt mit Kristech,
sie konnten das Problem bisher anscheinend nicht reproduzieren.

Mal sehen, was sie zu socat meinen.
--

Fhem auf Cubietruck mit Debian Wheezy und Homematic und 1-Wire

UweH

Zitat von: Alexander Bauer am 27 August 2014, 22:23:08
Zwischenzeitlich habe ich Kontakt mit Kristech,
Dieser Effekt beschränkt sich aber nicht nur auf die Kristech-Teile, das passiert auch bei meinen China-Adaptern (http://www.wvshare.com/product/UART-ETH-E001.htm und dem WLAN-Interface. Und es ist auch völlig egal, ob die Verbindung von socat aufgebaut wurde oder von OWX_ASYNC. Daher bin ich mal gespannt, ob Kristech eine Lösung anbieten kann...

Prof. Dr. Peter Henning

So,

ich melde mich nach längerer Abstinenz auch wieder zurück.

Habe zwar immer noch zuviel um die Ohren - aber schraube schon wieder ein wenig an den OW...-Modulen.

LG

pah

Peter_64

Hallo zusammen,
nach einem Update heute kam im Log  folgende Fehlermeldung!

2014.10.09 21:03:42 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.09 21:03:42 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.09 21:03:42 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.09 21:03:42 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.09 21:04:10 1: PERL WARNING: Argument "45.2M-BM-0C" isn't numeric in numeric lt (<) at (eval 40) line 1.
2014.10.09 21:04:10 1: PERL WARNING: Argument "45.2M-BM-0C" isn't numeric in numeric gt (>) at (eval 41) line 1.
2014.10.09 21:04:10 1: PERL WARNING: Argument "45.2M-BM-0C" isn't numeric in numeric lt (<) at (eval 46) line 1.

Hat jemand eine Idee an was es liegen kann ?
Ich arbeite mit OWX_ASYNC habe einige Tempfühler und ds2413 dran, hatte keine Fehler vor dem Update ?

Besten Dank im voraus für einen Tipp





ntruchsess

an OWX_ASYNC wurde in den letzten 2 Monaten nichts geändert. Du hast ein Device in der fhem.cfg, dessen TYPE mit 'OW' beginnt, das aber keine 'ROM_ID' gesetzt hat: https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/00_OWX_ASYNC.pm#L580

Wie das mit dem Update zusammenhängt, erschließt sich mir erst mal nicht.

Gruß,

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

Peter_64

Hallo Norbert,
ich habe jetzt alle Device durch, alle  OWX - Devices hatten das ROM_ID gesetzt. Bei den beiden Modem OWX_ASYNC steht zweimal FF drin. Die  OWDevice der OWServer haben alle IODev stehen z.B. DS9490r, nur beim OWServer selbst steht bei DS9490r keine IODev.

Hier noch mal ein Auszug vom Log.
Sorry wegen falscher Info... der Fehler ist zum ersten mal bereits am 5.10.2014 ohne Update aufgeschlagen.

Eine Idee ?

2014.10.10 00:16:26 1: PERL WARNING: Argument "42.8M-BM-0C" isn't numeric in numeric gt (>) at (eval 348) line 1.
2014.10.10 00:18:09 0: Server shutdown
2014.10.10 00:18:13 1: Including fhem.cfg
2014.10.10 00:19:59 1: Including ./log/fhem.save
2014.10.10 00:20:12 0: Server started with 61 defined entities (version $Id: fhem.pl 6707 2014-10-08 08:30:15Z rudolfkoenig $, os linux, user fhem, pid 8434)
2014.10.10 00:20:22 1: PERL WARNING: Argument "42.8M-BM-0C" isn't numeric in numeric lt (<) at (eval 27) line 1.
2014.10.10 00:20:22 1: PERL WARNING: Argument "42.8M-BM-0C" isn't numeric in numeric gt (>) at (eval 28) line 1.
2014.10.10 00:20:22 1: PERL WARNING: Argument "42.8M-BM-0C" isn't numeric in numeric lt (<) at (eval 33) line 1.
2014.10.10 00:20:22 1: PERL WARNING: Argument "42.8M-BM-0C" isn't numeric in numeric gt (>) at (eval 34) line 1.
2014.10.10 00:20:25 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.10 00:20:25 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.10 00:20:25 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.10 00:20:25 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.10 00:20:25 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.10 00:20:25 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014

softsand

Hallo an alle,

Zu dem Problem "Init Failed:OWX_SER::Detect 1-Wire bus Modem1:interface not detected answer" konnte ich folgendes bisher feststellen:
Auf meinem System (Raspi - IF-ETH mit Kristech - auf Kanal1: Umweltsensor - Temperatursensor DS18B20 - Auf Kanal2: Switch DS2408 - Module u.a. Stellmotor, Pid20)
wird der Kanal mit den Sensoren jedesmal blockiert wenn innerhalb von ca 10 sec. nach dem Auslesen eines Sensors ein Schaltbefehl zum Switch gesendet wird, dies tritt dummerweise innerhalb weniger Stunden Betrieb mal auf. Zur Zeit lasse ich den PID aus, so werden keine Schaltbefehle gesendet und es läuft seit einigen Tagen problemlos. Zum Test nochmals einige Schaltbefehle von "Hand" gesendet Blockade erfolgte wieder nach dem ein Schaltbefehl in den 10sec.-Fenster lag. Folglich würde ich auf ein Timing- oder ein Puffer-Problem tippen.
Leider fehlt mir die Zeit das momentan weiter zu verfolgen. Vielleicht hat jemand die Zeit das zu Prüfen.

Grüße
Michel

Prof. Dr. Peter Henning

Bitte mal separaten Thread lesen und diese Meldung dort noch einmal posten

http://forum.fhem.de/index.php/topic,27607.0.html

LG

pah

softsand

Hi,

kann ich machen aber bitte vorher kurz eine PN.
Ich gehe bis jetzt davon aus, dass es nicht mit OWSwitch zusammenhängt, da:
- bei nicht der Bus mit den Aktoren blockiert sondern der mit den Sensoren (kann weiter schalten aber keine Sensoren mehr auslesen)
- funktioniert erst wieder wenn ich alles stromlos mache (wie hier schon öfters erwähnt)
- Fehler bestand schon vor dem Update von OWSwitch
weswegen ich es hier gepostet habe

Nachtrag:
Getestet OWX mit Socat für beide Kanäle und OWX_Async für beide Kanäle. Mischbetrieb OWX mit Socat für Kanal 1 und OWX_Async für Kanal 2 nicht getestet.
OWSwitch wird mit set xxx output angesprochen.

Grüße
Michel