Neuartiges 1-Wire Interface

[ntruchsess]

Ich dachte Norbert ist dabei die Software in owxasync zu integrierten.

Bin ich auch... Ist aktuell nur ein bischen eng, weil ich eine (richtige) Baustelle vor dem Haus habe die an den Wochenenden einiges an Kraft zehrt (und OWX_ASYNC macht in manchen Szenarien wie Dis- und Reconnect etc... noch etwas Schluckauf, der erst mal auskuriert werden will, bevor ich weitere Interfaces aktiv supporte).

Gruß,

Norbert

[Prof. Dr. Peter Henning]

Tja, so ist das...

Ich brauche sicher noch Wochen, um mich wieder etwas frei zu schaufeln...

LG

pah

[matthias soll]

OK alles gut wollte auch nicht drängeln.
LG
Matze

[ntruchsess]

Ich dachte Norbert ist dabei die Software in owxasync zu integrierten.

ist jetzt drin. Mit den richtigen Grundlagen im OWX_ASYNC/OWX_SER/OWX_DS2480 war es eigentlich nur noch ein 3-Zeiler...

unterstützt erst mal eine Konfiguration als TCP-Client (der über Ethernet angebundene DS2480 ist also der TCP-Server).
Die Definition geht beispielsweise so:

Code Auswählen Erweitern

define owx OWX_ASYNC 192.168.0.69:4444 (IP-addresse des Moduls 192.168.0.69, Port 4444).

Hat (wie alle TCP-Clients) aber noch das Problem dass das Betriebssystem ein Abschalten bzw. vom Netzwerk entfernen des Ethernet-moduls erst mal (bis zum TCP-Timeout) nicht bemerkt und der Adapter mitunter minutenlang 'Active' bleibt, während die Request alle in Timeout laufen. Da will ich noch einen Error-counter einbauen, der beim Überschreiten eines Schwellwerts einen FHEM-seitigen disconnect macht und danach versucht wieder neu zu verbinden.

Unterstützung für OWX_ASYNC im TCP-Server-mode kommt noch.

EDIT: der Timeout-counter ist jetzt auch schon drin. Mit dem Attribut 'maxtimeouts' (default 5) kann man konfigurieren, nach wie vielen Timeouts hintereinander OWX_ASYNC selber die Verbindung abbricht und versucht neu aufzubauen. Die Erkennungszeit hängt natürlich von der Aktivität (bzw. dem Interval der Devices) ab. Der Reconnect dauert danach zwar auch ein bischen (das ist die in DevIo_Opendev eingebaute Logic, die exzessive wiederholte Verbindungsaufbauversuche einbremst), aber alles in allem immer noch deutlich fixer als auf die TCP-Timeouts zu warten.

EDIT: Es müssen alle(!) OWX-relevanten Dateien (OWX_ASYNC, OWX_SER, OWX_DS2480 und alle OWXXX-clients) geupdated werden, die neue Funktionalität baut auf Changes im OWX_ASYNC auf die nicht zu älteren Versionen der Devices kompatibel sind.

Gruß,

Norbert

[DannyP]

Hallo,
Das Thema kommt wie gerufen. Im Keller liegt keine 1wire Verkabelung, aber eine LAN dose. Dafür wäre dieses Interface ja dann praktisch um 1wire Sensoren im Keller zu nutzen.
Wird jemand die Platine fertig bestückt / als sammelbestellung anbieten? Oder kann man evtl. Sogar jetzt schon was bekommen?
Schöne grüße & vielen Dank. Super Idee und super Arbeit!

[Tobias]

Ich habe noch 3 leere Platinen für je 2€ anzubieten.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[UweH]

ist jetzt drin.
unterstützt erst mal eine Konfiguration als TCP-Client (der über Ethernet angebundene DS2480 ist also der TCP-Server).
Die Definition geht beispielsweise so:

Code Auswählen Erweitern

define owx OWX_ASYNC 192.168.0.69 4444 (IP-addresse des Moduls 192.168.0.69, Port 4444).

Hallo Norbert,

erst mal vielen Dank für Deine Mühe.
Mit socat läuft es zwar, aber extrem unkomfortabel...

Der Verbindungsaufbau zum Interface (Kristech) produziert erst mal nur "OWX: Define failed, unable to identify interface type 192.168.xxxx". In Deinem Beispiel ist der Port mit einem Leerzeichen von der IP getrennt, nicht mit einem Doppelpunkt. Setze ich den Port mit einem Doppelpunkt dahinter, wird das define angelegt, ich bekomme dann keine Fehlermeldung, sondern ein "disconnected" im state.

Ich habe die 3 Dateien aus sourceforge in mein FHEM-Verzeichnis gepackt und den socat-Aufruf aus /etc/init.d/fhem auskommentiert. Soweit alles richtig?

Edit: Ein "get ... devices" produziert: OWX: Discover called with unknown interface serial on bus 1wire at ./FHEM/00_OWX_ASYNC.pm line 417.
Ein "get ... version" liefert "5.8". Viellleicht hilft das weiter...

[ntruchsess]

In Deinem Beispiel ist der Port mit einem Leerzeichen von der IP getrennt, nicht mit einem Doppelpunkt.

Oh, danke. Da gehört natürlich ein Doppelpunkt dazwischen. Hab meinen Post korrigiert.

Ich habe die 3 Dateien aus sourceforge in mein FHEM-Verzeichnis gepackt[...]Soweit alles richtig?

Du musst alle(!) OWX-dateien aktualisieren, die OWX-Clients von vor dem OWX_ASYNC-update letzter Woche sind nicht kompatibel mit dem aktellen code.

Ein "get ... version" liefert "5.8".

im SVN ist mittlerweise Version 5.10 Damit geht dann auch ein Reconnect bei temporärem Aus- und Wiedereinschalten des Ethernetmoduls.

[UweH]

Das "alle" irritiert mich jetzt etwas... 00_OWX_ASYNC.pm kam per Update und dann finde ich nur noch OWX_SER.pm und OWX_DS2480.pm. Ich verstehe offenbar am System was nicht...

Edit: Nee, Moment , ich versteh es gerade...hab's gefunden (schäm...)

[UweH]

So, alle ( ) OWX-Dateien aktualisiert, Version ist jetzt 5.1 (soll dann wohl 5.10 heißen) und mit dem richtigen Port klappt's dann auch 

[det.]

Hallo Norbert,
ist kaum zu fassen - es funktioniert auf Anhieb mit beiden DS2480 von Tobias Platine! Vielen Dank, da kann die 1-wire Erweiterung in Richtung Garten hinter dem Haus über Netzwerkkabel weitergehen.

[UweH]

Hallo Norbert,

alles, was ich bisher getestet habe, funktioniert, nur...ich kann beim LCD mit dem Befehl "set LCD backlight on" bzw. "off" die Hintergrundbeleuchtung nicht mehr schalten. Was ist das denn für ein kurioses Verhalten? Kann das jemand bestätigen?
Ich habe versucht, mir hier: http://forum.fhem.de/index.php/topic,13580.270.html Fakten zu holen, werde aber nicht fündig.

[det.]

alles, was ich bisher getestet habe, funktioniert, nur...ich kann beim LCD mit dem Befehl "set LCD backlight on" bzw. "off" die Hintergrundbeleuchtung nicht mehr schalten. Was ist das denn für ein kurioses Verhalten? Kann das jemand bestätigen?

Ja, das Verhalten habe ich auch - aber nicht erst seit heute - auf dem CUBIE2 mit USB Interface und auf dem RPI mit USB und dem KRISTEC Interface. Ist das Displax nach dem Serverneustart erst mal an leuchtet es (und Backlight lässt sich nicht mehr ausschalten) - das ist der Normalzustand und war mir nicht Wert hier anzumerken. Wenn es allerdings wie bei dem Test RPI ausgegangen ist (ich hatte das vor diesem Post auf mangelnde Stromversorgung nur über den RPI USB geschoben) lässt sich Backlight nur durch FHEM reboot wieder zum Leben erwecken.

[UweH]

Das ist ja interessant. Ich habe ein Testsystem mit OWX_ASYNC auf einem Cubie 2 aufgesetzt und da zeigt das Display dieses Verhalten. Hab ich bisher noch nie beobachtet, weder auf meinem FHEM-Livesystem noch auf einem Test-Raspi. Werd morgen mal die OWX_ASYNC-Geschichte auf dem Raspi testen, bin ja mal gespannt.

[ntruchsess]

OWLCD ist bei mir ein bischen das Problemkind. Ich habe zwar den zugehörigen 1-Wire LCD-Controller, aber meine Displays (ein 2004 und ein 1602) scheinen nicht die passende Pinbelegung zu haben. Das hat bei mir auch mit dem synchronen OWX nicht richtig funktioniert, daher bin ich was das Testen angeht da vollständig auf Euch angewiesen. Ich werfe aber gerne noch mal einen Blick drauf, ob der asynchrone Code für 'Backlight on/off' tatsächlich so implementiert ist, dass das gleiche über die Leitung gehen sollte. Geht denn sonst alles mit dem LCD?

Gruß,

Norbert