Tester gesucht

[UweH]

Ein Absetzen von "set ... output A on" führt im asynchronen Modus übrigens zum Absturz von FHEM mit folgenden Meldungen:

Code Auswählen Erweitern

2016.03.11 18:03:26 1: [OWX_Qomplex] Added to OWX send queue dev=3A10850C000000CF numread=2 at 1457715806 664756
2016.03.11 18:03:26 1:    Queue contains 1 entries after insertion
2016.03.11 18:03:26 1:     => 3A10850C000000CF expecting 2 bytes, waiting
2016.03.11 18:03:26 1: ----------------------------------------------
2016.03.11 18:03:26 1: [OWX_PrQueue] starting send-receive cycle, queue length 1. Setting entry to active
2016.03.11 18:03:26 1: +++++++++++++++++++++++++++++++
2016.03.11 18:03:26 3: Sending out        0x55 0x3a 0x10 0x85 0x0c 0x00 0x00 0x00 0xcf 0xf5 0xff 0xff
2016.03.11 18:03:26 1: ----------------------------------------------
2016.03.11 18:03:26 1: [OWX_Qomplex] Added to OWX send queue dev=3A10850C000000CF numread=1  at 1457715806 751944
2016.03.11 18:03:26 1:    Queue contains 2 entries after insertion
2016.03.11 18:03:26 1:     => 3A10850C000000CF expecting 2 bytes, active
2016.03.11 18:03:26 1:     => 3A10850C000000CF expecting 1 bytes, waiting
2016.03.11 18:03:26 1: ----------------------------------------------
2016.03.11 18:03:26 1: [OWX_PrQueue] still waiting for reply, delay sending from queue
2016.03.11 18:03:26 1: [OWX_Qomplex] Added to OWX send queue dev=3A10850C000000CF numread=2  at 1457715806 754460
2016.03.11 18:03:26 1:    Queue contains 3 entries after insertion
2016.03.11 18:03:26 1:     => 3A10850C000000CF expecting 2 bytes, active
2016.03.11 18:03:26 1:     => 3A10850C000000CF expecting 1 bytes, waiting
2016.03.11 18:03:26 1:     => 3A10850C000000CF expecting 2 bytes, waiting
2016.03.11 18:03:26 1: ----------------------------------------------
2016.03.11 18:03:26 1: [OWX_PrQueue] still waiting for reply, delay sending from queue
2016.03.11 18:03:26 1: OWX_Read: nonzero buffer length 2, expected 2, calling callback
2016.03.11 18:03:26 1: buffer is 0x55 0x3a 0x10 0x85 0x0c 0x00 0x00 0x00 0xcf 0xf5 0x5a 0x5a
2016.03.11 18:03:26 1: A ON☇ B ON☇
2016.03.11 18:03:26 1: OWX_Read: 1wire_USB queue contains 2 entries after removal of active entry
2016.03.11 18:03:26 1: ----------------------------------------------
2016.03.11 18:03:27 1: [OWX_PrQueue] starting send-receive cycle, queue length 2. Setting entry to active
2016.03.11 18:03:27 1: +++++++++++++++++++++++++++++++
2016.03.11 18:03:27 3: Sending out        0x55 0x3a 0x10 0x85 0x0c 0x00 0x00 0x00 0xcf 0x5a 0xfe 0x01 0xff
2016.03.11 18:03:27 1: ----------------------------------------------
2016.03.11 18:03:27 1: OWX_Read: 1wire_USB received -4 instead of 1 bytes
2016.03.11 18:03:27 1: buffer is 0x55 0x3a 0x10 0x85 0x0c 0x00
2016.03.11 18:03:27 1: ----------------------------------------------

[UweH]

FHEM schmiert ab, wenn man ein Device physikalisch kurz aus dem Bus rausnimmt

[Prof. Dr. Peter Henning]

Edit: Ups, da ist noch ein gravierender Fehler "Set Output" geht noch nicht, weil darin aufeinander folgende LESE und SCHREIB-Vorgänge auftauchen. Bitte stattdessen set gpio verwenden.

Das Stoppen beim Entfernen vom Bus ist beabsichtigt - benutze ich als Notaustieg

LG

pah

[det.]

Asynchron machts nicht, FHEM stürzt sofort ab, nachdem ich an einem der zwei Busmaster asynchronus=1 setze.
Heute Morgen Absturtz mit folgenden Log Einträgen:

Code Auswählen Erweitern

Died at ./FHEM/00_OWX.pm line 1095.
2016.03.12 05:12:52 1: ----------------------------------------------
2016.03.12 05:12:52 1: buffer is 0x98
2016.03.12 05:12:52 1: OWX_Read: 1wire_2 received -9 instead of  bytes
2016.03.12 05:12:52 1: PERL WARNING: Use of uninitialized value $numexp in concatenation (.) or string at ./FHEM/00_OWX.pm line 1092.
2016.03.12 05:10:31 1: OWX_Complex called with data 0xa5 0xe0 0x01

[Prof. Dr. Peter Henning]

Das sieht nach einem inkonsistenten Systemzustand aus - welche Devices hängen da dran ?

LG

pah

[det.]

Das läuft aber gefühlt 2 Jahre ohne Probleme und Änderungen. Die Busmaster sind die von locutus, daran:

OWX: 1-Wire devices found on bus 1wire_2 

28.FC8EC0030000      DS18B20        Temp.Sauna

12.4EF17B000000      DS2406/DS2507  OWSWITCH_Garten

1D.6DD80F000000      DS2423         OWCOUNT_KG

OWX: 1-Wire devices found on bus 1wire_3

1D.CE680F000000      DS2423         OWCOUNT_STROM 

1D.F1490F000000      DS2423         OWCOUNT_WITT 

Da soll noch die Gartenbewässerung dran, aber das verlegt sich leider nicht von selbst. 

Daher so wenig, aber das ist zum Testen ideal, da ohne Komfortverlust im Absturzfall

[UweH]

Wenn ich den Busmaster im laufenden Betrieb auf asynchron umstelle, kann ich danach z.B. von einem DS1820 per "get ... temperature" noch die Temperatur abholen, im nächsten Moment stürzt FHEM aber ab:

Code Auswählen Erweitern

2016.03.12 09:18:58 1: [OWX_Qomplex] Added to OWX send queue dev=1053375502080039 numread=0 at 1457770738 233583
2016.03.12 09:18:58 1:    Queue contains 1 entries after insertion
2016.03.12 09:18:58 1:     => 1053375502080039 expecting 0 bytes, waiting
2016.03.12 09:18:58 1: ----------------------------------------------
2016.03.12 09:18:58 1: [OWX_PrQueue] starting send-receive cycle, queue length 1. Setting entry to active
2016.03.12 09:18:58 1: +++++++++++++++++++++++++++++++
2016.03.12 09:18:58 3: Sending out        0x55 0x10 0x53 0x37 0x55 0x02 0x08 0x00 0x39 0x44
2016.03.12 09:18:58 1: ----------------------------------------------
2016.03.12 09:18:58 1: [OWX_Qomplex] Added to OWX send queue dev=1053375502080039 numread=9  at 1457770738 320762
2016.03.12 09:18:58 1:    Queue contains 2 entries after insertion
2016.03.12 09:18:58 1:     => 1053375502080039 expecting 0 bytes, active
2016.03.12 09:18:58 1:     => 1053375502080039 expecting 9 bytes, waiting
2016.03.12 09:18:58 1: ----------------------------------------------
2016.03.12 09:18:58 1: [OWX_PrQueue] still waiting for reply, delay sending from queue
2016.03.12 09:18:58 1: OWX_Read: Zero buffer ok
2016.03.12 09:18:58 1: OWX_Read: 1wire_USB queue contains 1 entries after removal of active entry
2016.03.12 09:18:58 1: ----------------------------------------------
2016.03.12 09:18:59 1: [OWX_PrQueue] starting send-receive cycle, queue length 1. Setting entry to active
2016.03.12 09:18:59 1: +++++++++++++++++++++++++++++++
2016.03.12 09:18:59 3: Sending out        0x55 0x10 0x53 0x37 0x55 0x02 0x08 0x00 0x39 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2016.03.12 09:18:59 1: ----------------------------------------------
2016.03.12 09:18:59 1: OWX_Read: 1wire_USB received -4 instead of 9 bytes
2016.03.12 09:18:59 1: buffer is 0x55 0x10 0x53 0x37 0x55 0x02
2016.03.12 09:18:59 1: ----------------------------------------------
Died at ./FHEM/00_OWX.pm line 1095.

Wenn ich FHEM dann mit aktiviertem asynchronous neu starte, kann ich Temperaturen abholen und auch den value des DS2890 setzen, ich bekomme den Status aber nicht angezeigt...siehe Screenshot.

[Prof. Dr. Peter Henning]

OK, habe jetzt verschiedene Stellen, an denen ich nacharbeiten muss.

Melde mich mit verbesserten Modulen.

LG

pah

[Prof. Dr. Peter Henning]

OK, here we go.

Die Module OWID, OWVAR, OWTHERM, OWSWITCH, OWCOUNT, OWAD, OWMULTI liegen hier in verbesserten Versionen bei, die sowohl mit dem alten OWX, als auch mit dem neuen asynchronen laufen (OWLCD fehlt noch). Unerwünschte Effekte sind nicht ausgeschlossen, darum nur als Beta3 hier angehängt. Insbesondere für die Nutzung mit dem ALTEN OWX_ASYNC und OWServer müsste man vielleicht noch testen.

OWY sollte (bei Umbenennung in 00_OWX.pm, natürlich !) das alte OWX ersetzen, hat ein Attribut für die asynchrone Behandlung. Achtung: Bisher nur mit USB-Busmastern. Die Benennung als OWY dient bei mir nur dazu, mein eigenes OWX vor dem Überschreiben zu sichern.

OWX_SER muss natürlich auch installiert werden.

Das beigelegte OWY produziert noch massenhaft Log-Einträge.

Fahrplan:

Dieses Wochenende baue ich OWLCD um (falls ich nicht doch lieber auf den Golfplatz gehe...) DONE, siehe übernächsten Post.

Bis nach Ostern sollten Tests mit dem alten OWX_ASYNC und OWServer abgeschlossen sein.

Dann werden diese Modulversionen released.

Dann wird das asynchrone Backend finalisiert und auf die anderen Interfacetypen (COC/CUN und TCP/IP) erweitert.

LG

pah

EDIT: Fluch der bösen Tat - das zuerst hochgeladene OWID hatte einen Fehler. Bitte durch das jetzt hier vorhandene ersetzen.

[UweH]

Was mir sofort aufgefallen ist...die Readings werden nicht automatisch aktualisiert. In keinem Modul.

Gruß
Uwe

Edit: Das betrifft den asynchronen Modus.

[Prof. Dr. Peter Henning]

Das liegt daran, dass das Update erst eine ganze Weile nach dem Absetzen des Kommandos erfolgt.
EDIT: Wundert mich insofern, als die Updates nach Ablauf der entsprechenden Kommandos bei mir sehr schön automatisch erfolgen

Anbei das (vorläufig) letzte der Frontendmodule in der Version 6.0beta3, OWXLCD. Muss vlt. von det. getestet werden, mein LCD-Controller hat irgendeine Macke.

LG

pah

[det.]

Guten Morgen pah,
Mein kleines System hat im synchronen Modus die Nacht gut überstanden. Die LCD sind am Hauptsystem angebunden, da hatte ich gestern Nacht nur das Modul ausgetauscht und reload des Moduls angeschoben, alle anderen OWX Module nicht angefasst. Da fehlte beim LCD die set und get Zeile, es kamen paar Meldungen auf dem Screen und es lief nicht. Sorry, es war zu spät zum ausführlichen Test. Würde aber gern alles auf dem Produktivsystem erst ersetzen, wenn es hier 2-3 Erfolgsmeldungen gibt.

[Prof. Dr. Peter Henning]

In der aktuellen Version (6.0beta3) gibt es noch das Problem, dass wegen einer fehlenden Variablen im ALTEN OWX Fehlermeldungen generiert werden.

Die lassen sich unterdrücken, indem man im ALTEN 00_OWX.pm die Zeile

use vars qw{%owg_family %gets %sets $owx_version $owx_debug $owx_async};

um den letzten fett gedruckten Teil ergänzt und danach einfügt

$owx_async=1;

Ein weiterer Schönheitsfehler ist, dass in dem oben publizierten OWSWITCH noch eine Debugmeldung verblieben ist: .... Calling GetModState w. 1 0

Die hat nichts zu bedeuten, kann man ignorieren.

Erfolgsmeldungen ? Klar doch.
Von diesen beiden kleinen Schönheitsfehlern abgesehen laufen alle neuen Frontendmodule in meinem Produktivsystem  mit dem ALTEN OWX stabil und ohne Probleme - inklusive des LCD-Controllers. Der hat (wie gewünscht) ein neues Attribut lcdgeometry bekommen.

LG

pah

Next Step: Testen mit ALTEM OWX_ASYNC (hier sind ggf. noch Anpassungen nötig, weil ich die Aufrufe von OWX...BiNValues vereinheitlicht habe)
                    Testen mit OWServer als Backend
                    Freigeben
               

[UweH]

Der hat (wie gewünscht) ein neues Attribut lcdgeometry bekommen.

Super, funktioniert. Habe auch mal einen LCD-Controller angeschlossen, läuft problemlos. Das Umstellen per lcdgeometry ist sehr hilfreich 
Lediglich OWCOUNT konnte ich noch nicht testen, meine Counter sind im Produktivsystem verbaut.

Gruß
Uwe

[det.]

Hallo pah - perfekt, Danke!
Läuft auf dem Produktivsystem, LCD Parameter ist sehr nützlich, besonders in Phasen mit noch vielen updates. OWCOUNT zählt seit gestern Mitternacht auch ohne Probleme.
Deinem Termin zu Ostern steht offenbar nichts Grundsätzliches entgegen.