OWX asynchron überarbeitet

Begonnen von ntruchsess, 30 Juni 2013, 00:55:59

Vorheriges Thema - Nächstes Thema

det.

Hallo Norbert,
Vielen Dank, dass Du Dich so schnell mit der Sache beschäftigst. Da ich derzeit auf Arbeit bin, nur über Fernzugang auf Webinterface - OWLCD zeigt bei Version 3.35. Bin mir nicht sicher, ob ich die Datei auf dem Produktivsystem getauscht habe. Auf dem Test Cubietruck hatte ich es getan und mal kurz ein Display dran. Da ging es. Ich teste heute Abend.
LG
det.

ntruchsess

OWLCD 3.35 ist schon die asynchrone Version. Na dann mache ich mich mal auf die Suche, welches Modul im asynchronen Modus noch einen synchroner Aufruf ins OWX macht.
Wäre nett, wenn Du das OWLCD asynchron mal sorgfältig durchtestest, bei mir wollte es nämlich nicht (d.h. gar nicht, weder synchron noch asynchron auch mit der 3.34, es blieb einfach dunkel).

Gruß,

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

det.

#92
Hallo Norbert,
hatte zwischenzeitlich die Module fehlerhaft runtergeladen... Jetzt aber den asynchronen Zwischenstand:
FHEM startet nicht mit definiertem OWX_ASYNC... also Busmaster abgezogen, reset am Cubie  .. Start FHEM ... OWX ohne ASYNC definiert  . Busmaster angesteckt shutdown restart im Webinterface - läuft:
ZitatOWX: 1-Wire devices found on bus 1wire_0
20.70C707000000      DS2450     OWX_20_70C707000000
20.B7CB07000000      DS2450     OWX_20_B7CB07000000
28.F213DD030000      DS18B20    OWX_28_F213DD030000
28.76B82A040000      DS18B20    OWX_28_76B82A040000
28.EE81DA030000      DS18B20    OWX_28_EE81DA030000
28.A5A5DA030000      DS18B20    OWX_28_A5A5DA030000
28.1B7BDA030000      DS18B20    OWX_28_1B7BDA030000
12.4EF17B000000      DS2406     OWX_12_4EF17B000000
26.CCDB16000000      DS2438     OWX_26_CCDB16000000
29.565713000000      DS2408     OWX_29_565713000000
FF.430800000100      LCD        OWX_FF_430800000100
über edit files - fhem.cfg Definition in OWX_ASYNC geändert - save fhem.cfg = > jetzt läuft OWX asynchron und viel schneller - allerdings ohne LCD, das hatte ich offenbar nur im synchronen Modus gesehen. Da es die letzten Zeichen einfaach weiter anzeigt, fällt das nicht gleich auf. Praktikabel ist diese Methode nicht wirklich, auch wenn die Sache nachdem man sie so umständlich gestartet hat flüssig alle Sensoren im 5s Intervall abruft. Einen Filelog habe ich nicht definiert, aber man kann über longpoll sehr schön die Veränderung der Daten sehen.
Da die Sensoren und der Cubietruck unnütz bei mir im Homeoffice rumliegen, kannst Du gern schreiben, was ich daran wie noch testen soll. Das Produktivsystem werde ich erst mal nicht mit den Änderungen quälen.
LG
det.

ntruchsess

Zitat von: ntruchsess am 14 April 2014, 15:18:48
Na dann mache ich mich mal auf die Suche, welches Modul im asynchronen Modus noch einen synchroner Aufruf ins OWX macht.

Bingo :-), bin in der methode 'OWID_GetValues' fündig geworden.

noch nicht im SVN, sondern erst mal auf Github (branch owx_async_nothread): 21_OWID.pm. Muss selber erst noch mit 'echter Hardware' testen.

Gruß,

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

det.

...die asynchrone Variante schaltet die OWSWITCHs nicht, nach Änderung auf synchron geht es - kommt bei asynchon PRESENT 0 und es ändert sich der STATE bei set output A on etc. nicht - Versionen sind jeweils die aktuellen von heute aus diesem Beitrag.
LG
det.

ntruchsess

die heutigen Änderungen (OWID, OWSWITCH) habe ich ins SVN commitet. OWSWITCH output hat hier mit einem DS2406 mal funktiont, dann wieder nicht. Input war kein Problem. Da bin ich aktuell noch am Untersuchen.
Warum der initiale Bus-search mit Autocreate der Devices mit einem DS2480 Busmaster nicht tut, bin ich auch noch am untersuchen. Mit einem Arduino über Ethernet geht das, der ruft OWX_ASYNC_Init auf, sobald er verbindet, beim DS2480 wird das über die NotifyFn gemacht, wenn global init fertig ist, nur da passiert nix. Naja, ich werds schon finden, nur jetzt ists mir zu spät für heute...

Gruß,

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

det.

Hallo Norbert,
habe heute Abend nach update auf beiden Systemen noch mal getestet. OWX synchron - es funktioniert OWID, OWCOUNT, OWSWITCH, etc. wie gewünscht. Auf dem Testsystem mit OWX_ASYNC - rennt im 5s Takt OWAD, OWMULTI und OWTHERM. OWSWITCH funktioniert noch nicht (nur direkt nach dem Start mal kurz, danach present 0). Die Performance ist irre mit 10 Sensoren trotz dokick im 5s Takt. Ich freue mich schon drauf, das bei wesentlich mehr Devices im Produktivsystem bald einzusetzen. Ich kann gern auch das Display noch testen, hab davon noch 2 rumliegen, nur bisher geht es ja async überhaupt nicht.
LG
det.

ntruchsess

Hallo Detlef,

ja, Performance ist schon mal schick. Das zeigt doch, dass ich damit auf dem richtigen Weg bin. Die Devices, auf die lesend zugegriffen werden, scheinen ganz brauchbar zu funktionieren. Schwierigkeiten machen die Funktionen, bei denen mehrere 1-Wire Befehle unmittelbar hintereinander (und voneinander abhängig) ausgeführt werden. Also so was wie Schreiben -> Lesen (für Prüfsumme) -> Prüfsumme schreiben. Da kann bei der asynchronen Ausführung dann etwas dazwischenrutschen, was die Befehlsfolge stört. (Deshalb geht z.B. die Erkennung der DS2423-Varianten noch nicht, da wird der Speicher gelesen, mit einem anderen Wert überschrieben, wieder gelesen und anschließend der ursprüngliche Wert wieder hineingeschrieben). Da muss ich konzeptionell noch etwas wie eine transaktionale Klammer oder eine Art Lock implementieren, damit für ein Device während einer asynchron ausgeführten Befehlsfolge nachfolgende Aufrufe nicht zwischenrein gemischt werden können. Also im Prinzip weiß ich schon, was es können muss, ich will es aber sauber und nicht als Hack machen, sonst versteht es hinterher keiner mehr.

Wg. dem OWLCD: hab grade 21_OWLCD.pm Versioni 3.35 (aus meinem Github) sowohl mit dem normalen OWX, als auch mit OWX_ASYNC getestet, alles an einem DS2480 Busmaster. Im Prinzip scheint beides zu gehen. Jedenfalls macht es mit meinem LCD das gleiche, wie die Version 3.34 aus dem FHEM-SVN, auch wenn das ziemlicher Murks ist. Eigentlich kann ich nur in Zeile 0 vernünftig schreiben. Alle anderen Zeilen produzieren entweder gar nichts, oder an der falschen Stelle. Irgendwie scheinen meine beiden Displays (ein 2004 und ein 1602) nicht zur Pinbelegung des OWLCD-controllers zu passen. Backlight on/off, LCD on/off und die GPIOs gehen jeweils einwandfrei. Vieleicht kannst Du ja mal abtesten, wie das bei Dir ist...

Gruß,

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

det.

@ Norbert,
Genau so, lass Dir Zeit. Es geht ja inzwischen synchron alles. Die LCD teste ich morgen gern - nach der Arbeit....
LG
det.

det.

hallo Norbert,
neue Meldungen auf der Konsole nach Neustart, restart über FHEMWEB ging nicht:
root@cubie3:~# service fhem status
fhem is not running
root@cubie3:~# service fhem start
jetzt startet fhem...
root@cubie3:~# Use of uninitialized value in concatenation (.) or string at ./FH                                              EM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
root@cubie3:~# Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.
Use of uninitialized value in concatenation (.) or string at ./FHEM/OWX_Executor.pm line 216.

get 1_wire_0 devices   - geht asynchron nicht, das angesteckte Display wird nicht gefunden.
LG
det.

det.

oh, ist das System empfindlich,
habe zum Test von den ehemals 10 Sensoren nur ein Thermometer und das Display dran gelassen und FHEM über Konsole neu gestartet:

OWX: 1-Wire devices found on bus 1wire_0
28.F213DD030000      DS18B20   OWX_28_F213DD030000
FF.430800000100       LCD          OWX_FF_430800000100

nach lcd off und anschliessendem lcd on schreibt es bei lcd test alle 4 Zeilen des Testtextes von pah, allerdings sterbend langsam. Da gibt es offenbar noch ein Problem, was auch die OWSWITCH irgendwann schalten lässt, nur nicht unmittelbar nachdem man das ausgelöst hat.
LG
det.

ntruchsess

Zitat von: det. am 16 April 2014, 16:47:08
schreibt es bei lcd test alle 4 Zeilen des Testtextes von pah, allerdings sterbend langsam.
Danke für's testen. Funktioniert OWLCD Version 3.35 denn mit dem normalen OWX, oder macht es da auch solche Probleme? Das mit der 'sterbend langsamen' Ausführung gehe ich gleich mal an, ich denke, ich weiß, woran das liegt.

Gruß,

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

det.

Zitat von: ntruchsess am 16 April 2014, 18:13:03
Funktioniert OWLCD Version 3.35 denn mit dem normalen OWX?
Damit geht es perfekt, 5 Thermometer und 2 x OWAD dran, 20s Abfrageintervall - 4x Temperatur auf dem Display angezeigt - ein Sensor in die Schreibtischleuchte gesteckt - klettert systematisch und wird ohne Verzögerung angezeigt - jetzt schon auf 67,6°C
LG
det.

ntruchsess

danke Dir ;-)

hab OWLCD 3.35 grade ins SVN committet. Die schlechte Performance beim Schreiben liegt nicht am Modul selbst, das kommt vom asynchronen Scheduling in der OWX_Executor.pm. Da arbeite ich jetzt dran. Stay tuned...

Gruß,

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

det.

gern, das ist ja das Mindeste und leider auch Einzige, was ich dazu beitragen kann.
Die Sensoren gehen offensichtlich alle prima mir der asynchronen Variante. Die Aktoren zicken (noch) rum.
LG
det.