OWX asynchron überarbeitet

[AHA1805]

Das ist wohl ein Regression-bug, der verhindert das auf emulierten DS2423 der state aktualisiert wird. Habe ich gerade gefixed (da ich erst heute abend testen kann erst mal auf github): 21_OWCOUNT.pm

aktuell ist OWX_ASYNC noch kompatibel mit den noch nicht auf Protothreads umgebauten Frontendmodulen. Die 'alte' asynchrone API baue ich in naher Zukunft aber aber zurück, beides zu supporten macht keinen Sinn.

Gruß,

Norbert

Cool, vielen Dank.

Werde ich dann mal testen und Rückmeldung geben.
Ansonsten bin ich mit der OWX_ASYNC Version sehr zufrieden, habe absolut keine Verzögerungen mehr durch 1Wire abfragen.

Schöne Grüße
aus dem verregneten München
Hannes

Gesendet von Unterwegs mit Tapatalk 4

[ntruchsess]

Offenbar bestimmt nun aber das Interval im OWX_ASYNC einheitlich für alle Fühler den Abfragezyklus. Damit kann ich leben.

das ist der Sinn von 'onkick': Wenn zentral 'dokick' gesetzt ist wird die Temperaturmessung für alle(!) DS18B20 parallel angestoßen (d.h. alle mit dem gleichen zentralen Interval), anschließend werden alle mit 'onkick' konfigurierten Devices auch ausgelesen. Ein am Frontendmodul konfiguriertes Interval wird dann ignoriert (auch wenn es auf 9999 steht).

Das Modul OWTHERM überprüft, ob es Lesefehler gibt (ERRCOUNT) Wenn das 5x passiert ist, wird das Intervall auf 9999 gesetzt.

Jetzt muss ich erst mal rausfinden, warum das beim Neustart passiert, obwohl das Device sonst funktioniert... Aber vieleicht sollte man dieses 'auf 9999'-setzen einfach ausbauen. Was ist denn der Nutzen davon, dass man ein bischen weniger sinnlosen Traffic auf dem 1-Wire-bus erzeugt?

Gruß,

Norbert

[ntruchsess]

Die gesetzten Werte waren aber nach dem ersten Messwertupdate dann doch wieder auf 9999.

Das war jetzt wohl ein trivial-fix. Da ich erst heute abend wieder selber testen kann der Bugfix hier auf Github: 21_OWTHERM.pm

Gruß,

Norbert

[det.]

lassen sich die 'invalid CRC'-meldungen einem bestimmten Device(typ) zuordnen? Dummerweise gibt's zu viele Stellen in den OWX-Frontend-modulen, die das (ohne Angabe des Devices) im Fehlerfall so loggen.

Gruß,

Norbert

leider nicht, nachdem ich gestern update auf dem Produktiv Cubie2 mit 2 synchronen OWX über USB durchgeführt habe, hab ich das heute zig mal im LOG. Keine Ahnung, wie ich das eingrenzen soll? Vorschläge ?

[ntruchsess]

Keine Ahnung, wie ich das eingrenzen soll? Vorschläge ?

Du könntest die aktuelle 00_OWX_ASYNC.pm (plus OWX_SER.pm, OWX_Executor.pm und OWX_DS2480.pm) manuell einspielen und anschließend die Frontendmodule einzeln upgraden und dazwischen jeweils einen aussagekräftigen Testlauf machen. 00_OWX_ASYNC.pm ist aktuell noch rückwärtskompatibel mit der bisherigen asynchronen API.

EDIT: Ich habe die kontextfreien 'invalid CRC'-Log-meldungen umgebastelt, jetzt sollte man mehr sehen. Die angepassten Module sind auf Github (testen kann ich selber erst später):
21_OWAD.pm
21_OWCOUNT.pm
21_OWMULTI.pm
21_OWSWITCH.pm
21_OWTHERM.pm

EDIT: angepasste 00_OWX_ASYNC.pm, falls der Fehler im Hintergrund auftritt:
00_OWX_ASYNC.pm

Gruß,

Norbert

[det.]

Hallo Norbert,
Danke! Die Meldung kommt von einem bisher unauffälligen Switch DS2406 aus dem Fuchs Shop auf meinem Boden zur Steuerung der WW Zirkulation. Ausgelöst wird das duch ein set OUTPUT A off im 3min Takt von einem notify aus der Anfangszeit meiner FHEM Versuche. Das sollte schon lange durch ein THRESHOLD ersetzt werden, aber es funktionierte eben bisher einfach. Wie ich den CRC Fehler dort wegbekommen soll, ist mir nicht klar. An dem Bus hängen noch 11 weitere Devices bunt gemischt aus der 1-wire Welt und bisher ging das eben immer.

[ntruchsess]

Hallo Norbert,
Danke! Die Meldung kommt von einem bisher unauffälligen Switch DS2406 aus dem Fuchs Shop auf meinem Boden zur Steuerung der WW Zirkulation. Ausgelöst wird das duch ein set OUTPUT A off im 3min Takt von einem notify aus der Anfangszeit meiner FHEM Versuche. Das sollte schon lange durch ein THRESHOLD ersetzt werden, aber es funktionierte eben bisher einfach. Wie ich den CRC Fehler dort wegbekommen soll, ist mir nicht klar. An dem Bus hängen noch 11 weitere Devices bunt gemischt aus der 1-wire Welt und bisher ging das eben immer.

D.h. mit einem anderen DS2406 funktioniert das set Output und nur mit diesem nicht?

[det.]

D.h. mit einem anderen DS2406 funktioniert das set Output und nur mit diesem nicht?

ja, genau und mit diesem bis gestern auch...

[ntruchsess]

hmm... vieleicht einfach zu viel los auf Deinem Bus? Wenn ich in meiner Testinstallation die intervalle alle auf 5 Sekunden runterdrehe kriege ich auch CRC-Errors von den OWCOUNTS und dem OWMULTI. Wahrscheinlich interferiert die periodische Bussuche beim 'dokick' doch mit Kommandfolgen (wie beim DS2406 set der I/O-pins). Ich werde mal testen, ob das besser läuft, wenn die Bussuche serialisiert und nicht parallel zu den anderen Tasks läuft.

Sonst scheinen die kleineren Fixes von heute ja zu tun, was sie sollen, ich habe das grade ins SVN committed.

Gruß,

Norbert

[Starkstrombastler]

Bei mir verhalten sich die DS18B20 merkwürdig.

1.
Am Bus hängen 14 Sensoren die fleißig Messwerte liefern. Die Abfrage mit 'get ... devices' liefert aber nur 6 Sensoren als present.

2.
Bei jedem Abfrageintervall wird eine Alarmmeldung ausgegeben, obwohl sich kein Sensor im Alarmbereich befindet:

Code Auswählen Erweitern


2014.05.13 23:39:33.138 1:  Alarms = FF.FFFFFFFFFFFF.FF

Befindet sich ein Messwert tatsächlich im Alarmbereich, so wird korrekt ausgegeben, obige Alarmmeldung erscheint dann nicht, z.B.:

Code Auswählen Erweitern


2014.05.13 23:15:18.813 1:  Alarms = 28.58BCE1040000.A7


3.
Wenn ein Temp-Sensor vorübergehend abgeklemmt war, dann werden die Internals 'owg_th' und  'owg_tl'  auf die Default-Werte zurückgesetzt, obwohl die zugehörigen Attribute gesetzt sind.

OWX_ASYNC version = 5.1
OWTHERM version = 5.16

[Starkstrombastler]

Ergänzung:

Im Putty tauchen regelmäßig folgende Zeilen auf:

Code Auswählen Erweitern


Use of uninitialized value $data in concatenation (.) or string at ./FHEM/OWX_SER.pm line 194.
Use of uninitialized value $numread in numeric gt (>) at ./FHEM/OWX_SER.pm line 197.

Das scheint zu Fehler Nr.2 im vorhergehenden Posting zu gehören.

[ntruchsess]

Code Auswählen Erweitern


Use of uninitialized value $data in concatenation (.) or string at ./FHEM/OWX_SER.pm line 194.
Use of uninitialized value $numread in numeric gt (>) at ./FHEM/OWX_SER.pm line 197.


dafür hatte ich gestern abend schon einen initialen Fix ins SVN committed, den habe ich grade noch mal verfeinert: OWX_SER.pm (auf GitHub, noch ungetestet, kommt heute abend in's SVN)

Gruß,

Norbert

[cwagner]

Hallo, mir scheint, dass es im Modul für den DS2308 (OWX_Switch) noch einen Punkt gibt. Das Reading present entspricht nicht dem Modulstatus - ich habe auch den Eindruck, dass PRESENT manchmal auf 0 steht, obwohl ich (fast) keine Fehlfunktion feststellen kann.

Hier ein eingekürztes Listing...

Code Auswählen Erweitern

Internals:
   ALARM      0
   ASYNC      1
   CFGFN      ./FHEM/1wire_devices.cfg
   CHANGED
   DEF        DS2408 68980C000000
   INTERVAL   30
   IODev      OWio1
   NAME       Switch_Heizkeller
   NR         102
   OW_FAMILY  29
   OW_ID      68980C000000
   PRESENT    1
   ROM_ID     29.68980C000000.da
   STATE      Brenner: OFF Mischer_weniger: OFF Mischer_mehr: OFF Waschkueche: ON EWT: OFF F: OFF G: OFF H: OFF
   TYPE       OWSWITCH
   Readings:
     2014-05-14 08:30:11   Brenner         OFF
     2014-05-14 08:30:11   EWT             OFF
     2014-05-14 08:30:11   F               OFF
     2014-05-14 08:30:11   G               OFF
     2014-05-14 08:30:11   H               OFF
     2014-05-14 08:30:11   Mischer_mehr    OFF
     2014-05-14 08:30:11   Mischer_weniger OFF
     2014-05-14 08:30:11   Waschkueche     ON
     2014-05-14 08:30:03   alarm           0
     2014-05-14 08:30:02   present         0
     2014-05-14 08:30:11   state           Brenner: OFF Mischer_weniger: OFF Mischer_mehr: OFF Waschkueche: ON EWT: OFF F: OFF G: OFF H: OFF
   owg_val:
     1
     1
     1
     0
     1
     1
     1
     1
   owg_vax:
     1
     1
     1
     0
     1
     1
     1
     1
Attributes:
   AName      Brenner|status

....

   interval   30
   model      DS2408
...



Das "fast" resultiert auf den ersten drei vollständigen FHEM-Abstürzen im produktiven Betrieb seit 1,5 Jahren in den letzten drei Tagen. Die letzte über Telnet aufgefangene Meldung war da nämlich jedes Mal ein Meldung von OWSwitch...
aktuell verwendete Module: Stand SVN bzw. wenn neuer aus Deinem Github von gestern Abend 21 Uhr.

Was kann ich tun, um hilfreiche Infos heranzubringen bzw. besser den eigentlich Absturz zu dokumentieren, falls er sich wiederholt?

Herzliche Grüße

Christian

[ntruchsess]

Die letzte über Telnet aufgefangene Meldung war da nämlich jedes Mal ein Meldung von OWSwitch...
[...]
Was kann ich tun, um hilfreiche Infos heranzubringen bzw. besser den eigentlich Absturz zu dokumentieren, falls er sich wiederholt?

Die Meldung(en) aus dem Telnet würden schon mal sehr helfen

Das mit dem Present muss ich mal gründlich überarbeiten. Da habe ich erst mal nix dran geändert, das arbeitet noch nach der synchronen logic. Vor Ablauf einer 1-Wire-Befehlsfolge wird present auf 0 gesetzt, nach erfolgreichem Abschluss der Befehlsfolge wieder auf 1. Bei Fehler bleibt's auf 0. Im Gegensatz zur synchronen Logik (die alles andere blockiert) kann man bei der  asynchronen Verarbeitung die 0 während des Ablaufs der 1-Wire-Befehlsfolge nämlich sehen.

Gruß,

Norbert

[ntruchsess]

Code Auswählen Erweitern


Use of uninitialized value $data in concatenation (.) or string at ./FHEM/OWX_SER.pm line 194.
Use of uninitialized value $numread in numeric gt (>) at ./FHEM/OWX_SER.pm line 197.

Der Fix hierfür ist jetzt auch im SVN. Damit ist der aktuelle Stand per update installierbar. Danke allen Testern für Ihr Feedback!

Gruß,

Norbert