OWX asynchron überarbeitet

[det.]

na schalt dokick doch mal ein - ich weiß ehrlich nicht genau, ob der heutige Patch da wirklich was hilft, weil ich nicht weiß, ob der von Christian gemeldete Timeout sachlich richtig (es wären tatsächlich keine Daten mehr gekommen), oder falsch (hat viel zu früh zugeschlagen) war. Auf meinem Testsystem macht das Timing ja (auch mit dokick) praktisch keine Probleme - aber das sagt wenig, wenn es um quasiparallele Verarbeitung geht ist das Timing ja immer Plattformabhängig.
Gruß, Norbert

Hallo Norbert,
das war es leider noch nicht, ein Zweig mit 13 DS1820 fiel heute morgen gegen 4 ohne jegliche LOG Einträge aus (immer nur die Thermometer, die anderen Devices gehen weiter) - habe das dokick auf 0 gesetzt und neu gestartet - geht bisher wieder. Der andere Zweig, da hatte ich zum Test nur einen DS1820 auf onkick gesetzt, alle anderen auf onread gelassen. da hat genau dieser heute früh gegen 7 aufgehört, Werte zu liefern.
Habe alle wieder auf onread - für mich ist das eigentlich so ok, der Server ist schnell genug um damit klar zu kommen.

[sweetie-pie]

Hallo zusammen,

ich war ein paar Tage weg, jetzt habe ich auch mal wieder getestet...

Zunächst mal heute morgen ein Update gemacht:

Code Auswählen Erweitern

# $Id: 00_OWX_ASYNC.pm 6378 2014-08-07 22:01:18Z ntruchsess $
# $Id: 00_OWX.pm 6392 2014-08-11 15:25:00Z ntruchsess $
# $Id: 11_OWX_FRM.pm 2013-03 - ntruchsess $
# $Id: 21_OWAD.pm 6378 2014-08-07 22:01:18Z ntruchsess $
# $Id: 21_OWCOUNT.pm 6379 2014-08-07 22:31:34Z ntruchsess $
# $Id: 21_OWID.pm 6263 2014-07-16 12:42:19Z ntruchsess $
# $Id: 21_OWLCD.pm 6378 2014-08-07 22:01:18Z ntruchsess $
# $Id: 21_OWMULTI.pm 6379 2014-08-07 22:31:34Z ntruchsess $
# $Id: 21_OWSWITCH.pm 6379 2014-08-07 22:31:34Z ntruchsess $
# $Id: 21_OWTEMP.pm 6164 2014-06-25 13:40:30Z ntruchsess $
# $Id: 21_OWTHERM.pm 6379 2014-08-07 22:31:34Z ntruchsess $
# $Id: OWX_DS2480.pm 6398 2014-08-12 21:22:18Z ntruchsess $
# $Id: OWX_Executor.pm 5927 2014-05-21 21:56:37Z ntruchsess $
# $Id: OWX_FRM.pm 6378 2014-08-07 22:01:18Z ntruchsess $
# $Id: OWX_SER.pm 6398 2014-08-12 21:22:18Z ntruchsess $


Bis eben hatte ich meine 11 Sensoren mit OWX betrieben, was allerdings das System ausbremste. Nun wollte ich nochmal OWX_ASYNC testen. Dazu habe ich alle Devices und den Adapter gelöscht. Die Config geschrieben und fhem neu gestartet.

Dann habe ich OWX_ASYNC neu angelegt:
Der Adapter wir erkannt und initialisiert. Das get Devices wirft abwechselnd immer solche oder ähnliche Fehlermeldungen:

Code Auswählen Erweitern

OWX_SER::Search CRC failed : CC.CD0C00000000.00 at ./FHEM/OWX_SER.pm line 390.
OWX_SER::Search CRC failed : CC.CD0C00000000.00 at ./FHEM/OWX_SER.pm line 390.
OWX_DS2480: Search 2nd return has wrong parameter with length = 17 at ./FHEM/OWX_DS2480.pm line 354.
OWX_DS2480: Search 2nd return has wrong parameter with length = 22 at ./FHEM/OWX_DS2480.pm line 354.
OWX_DS2480: Search 2nd return has wrong parameter with length = 19 at ./FHEM/OWX_DS2480.pm line 354.


Jetzt kommt das viel größere Problem:
Weil es das ASYNC nicht richtig lüppt, wollte ich zurück zu den normalen OWX. Also alles gelöscht, config geschrieben, Neustart.
OWX eingerichtet, adapter wird erkannt, get Devices ausgeführt und nun kommt:

Code Auswählen Erweitern

OWX: 1-Wire devices found on bus OWio1
00.000000000000      unknown    OWX_00_000000000000

*PANIK*

Es werden keine Devices mehr am Bus gefunden. Das sagt das Log dazu:

Code Auswählen Erweitern

2014.08.16 11:26:41 1: OWX: Serial device /dev/ttyUSB1 defined
2014.08.16 11:26:41 1: OWX: 1-Wire bus OWio1: interface master DS2480 re-detected
2014.08.16 11:26:50 1: OWX: 1-Wire devices found on bus OWio1 (OWX_00_000000000000)

Ich habe aus lauter Not schon meine Installation auseinander gerupft um den Bus zu verkleinern und noch einen anderen Adapter versucht, alles ohne Erfolg.. immer mit den gleichen Ergebnis.

Kann mit bitte jemand sagen, welche Module ich genau zurückspielen muss? Ich habe den Zusammenhang der Module noch nicht ganz verstanden.

00_OWX.pm und 00_OWX_ASYNC.pm greifen beide auf OWX_SER.pm und dann auf  21_OWTHERM.pm zu?
Was machen den die anderen Module wie  21_OWTEMP.pm?
Ist das Problem evtl. weil ich eine Uralt-Installation habe die historisch gewachsen ist?

Hier noch weiter Systeminfos:

Code Auswählen Erweitern

root@zeus:~# perl -v

This is perl, v5.10.1 (*) built for i486-linux-gnu-thread-multi

Copyright 1987-2009, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

root@zeus:~# uname -a
Linux zeus 2.6.32-64-generic #128-Ubuntu SMP Tue Jul 15 08:34:12 UTC 2014 i686 GNU/Linux

Gruß
  Holger

[ntruchsess]

Hallo Holger,
Ich hab grade testweise ein FHEM-5.5 aus dem tar-file installiert und per update auf aktuellen Stand gebracht und sowohl OWX, als auch OWX_ASYNC mit einem DS2480 Busmaster from scratch neu aufgesetzt. Tat alles wie es soll. Merkwürdig dass es bei Dir nicht klappt. Die Versionen die bei Dir per update rüberkommen sind sehen soweit auch korrekt aus (abgesehen davon, dass einige mittlerweile gelöschte Dateien bei Dir noch vorhanden sind: 11_OWX_FRM.pm und OWX_Executor.pm gibt's im SVN gar nicht mehr, da hat das Löschen beim update wohl nicht funktioniert... (21_OWTEMP wird übrigens nicht mehr aktiv gepflegt, da durch OWTHERM ersetzt)

Hast Du die Hardware mal durchgestartet? OWX kann den Busmaster nämlich nicht wirklich resetten, wenn der nicht mehr auf die Baudrate synchronisiert ist, dann kann es sein, dass die Buskommunikation nicht mehr geht.

Wg. Downgrade: das normale 00_OWX.pm hat keine Abhängigkeiten zu OWX_SER oder so, das redet direkt mit OWTHERM und Konsorten.

Gruß,

Norbert

[det.]

Hallo. Norbert,
Hast Du inzwischen eine Idee, warum OWTHERM mit OWX_ASYNC auf schnellen Servern nicht dauerhaft läuft? Auf den RPI gibts bei mir den Effekt nicht. Da geht es mit mehreren USB Adaptern und dem Kristech über Netzwerk prima seit letzterem Wochenende.
Das Löschen von überflüssigen Modulen scheint nicht automatisch zu funktionieren. Die sind bei mir auch alle noch da. Da wäre ein Hinweis, welche alle genau nicht mehr nötig sind hier gut.

[sweetie-pie]

Hallo Norbert,

zunächst vielen Dank für deine Bemühungen.

Zunächst die gute Nachricht: Es läuft nun offenbar... 

Nun die schlechte Nachricht: Ich weiß nicht woran es schlussendlich lag... 

Ich habe mit update force alles geupdated und dann alle alten Module per Hand ausgemistet.
Dann habe ich weiterhin festgestellt, dass sich gelegentlich mein ttyUSB ändert, deswegen habe ich mal einen symbolischen Link via udev-rules angelegt und verwende nun diesen in der Parametrierung.

Ich werde  nun mal ein wenig testen. Danke...

Gruß
Holger

[ntruchsess]

Hallo Detlev,

Hast Du inzwischen eine Idee, warum OWTHERM mit OWX_ASYNC auf schnellen Servern nicht dauerhaft läuft?

Ich vermute, dass die Temperaturwandlung fehlschlägt, wenn der DS18B20 während der Wandlung bei einer Bussuche angesprochen wird. Genau das passiert bei der Kombination 'dokick/onkick'. Vieleicht kannst Du das ja mal mit 'attr power=parasitic' testen, dann wird alles serialisiert abgearbeitet und die 'dokick'-Bussuche sollte erst nach dem Auslesen der Sensoren drankommen. (Dabei dürfen die Intervalle natürlich nicht zu kurz sein, weil der 1-Wire-bus während der 1-Sekunden Gedenkpause vom OWTHERM dann ja für andere Aufgaben blockiert ist).

Das Löschen von überflüssigen Modulen scheint nicht automatisch zu funktionieren. Die sind bei mir auch alle noch da. Da wäre ein Hinweis, welche alle genau nicht mehr nötig sind hier gut.

Ich zähl mal auf, welche Dateien benötigt werden:

00_OWX.pm (für Arduino, DS2480, DS9097, CUNO, owfs aka OWServer)
00_OWX_ASYNC.pm (für Arduino, DS2480 und DS9097)
10_FRM.pm (für Arduino, sowohl OWX als auch OWX_ASYNC)
10_OWServer.pm (für owfs)
21_OWAD.pm
21_OWCOUNT.pm
21_OWID.pm
21_OWLCD.pm
21_OWMULTI.pm
21_OWSWITCH.pm
21_OWTHERM.pm
OWX_DS2480.pm (für OWX_ASYNC mit DS2480 und DS9097)
OWX_DS9097.pm (für OWX_ASYNC mit DS9097)
OWX_FRM.pm (für OWX_ASYNC mit Arduino)
OWX_SER.pm (für OWX_ASYNC mit DS2480 und DS9097)
GPUtils.pm (für OWX_ASYNC)
lib/ProtoThreads.pm (für OWX_ASYNC)

die 11_OWX_*.pm und OWX_Executor.pm sind obsolet (sollten aber abgesehen von sinnlosen Einträgen in der Commandref keinen Schaden anrichten, wenn sie noch rumliegen)

Gruß,

Norbert

[fhem-challenge]

Hi Norbert,

obwohl ich ja auch seit langem das Problem mit OWX_ASYNC auf schnellen Rechner habe, stelle ich aber teilweise Unterschiede in den Releases von OWX_ASYNC fest. Seit dem vorletzten "update" habe ich wieder deutlich mehr Ausfälle meiner DS18B20. Mit der OWX_ASYNC ca. Anfang August hatte ich nach ca. 1 Tag die Ausfälle (reproduzierbar da ich zwischen den OQX_ASYNC Versionen wechsele und das Problem damit mitwechselt). Seit dem vorletzten Update ca. all 3-4 Stunden. Ich nutze "doKick", deaktiviere es aber heute einmal und melde mich, wenn ich hier etwas "erkennen" kann.

Anonsten "resettet" meine "Not-"Funktion den Firmata...

Code Auswählen Erweitern

check_owx_async {
my @@device=devspec2array("TYPE=OWTHERM");
my $must_reset = 0;
my $watch_time = "900";
my $iodev = "";
foreach(@@device)
{
my $state_time = $defs{$_}{READINGS}{"temperature"}{TIME};
my $last_activity_since = int(time - time_str2num($state_time));
if ($last_activity_since > $watch_time)
{
my $iodev_ow = AttrVal($_,"IODev","");
$iodev = AttrVal($iodev_ow,"IODev","");
fhem ("get $_ temperature");
$must_reset = 1
}
}
if ($must_reset == 1)
{
if ($iodev)
{
fhem ("set $iodev reset");
Log 3,"Warnung: $iodev wird neu gestartet, da OWX_ASYNC nicht erreichbar ist"
}
doWarning($iodev,"OWX_ASYNC meldet sich nicht und wurde neu gestartet")
}
}



...nicht schön,  aber ich hoffe, das ich die Funktion bald loswerde


Viele Grüße!

Andreas

Hallo Detlev,

Ich vermute, dass die Temperaturwandlung fehlschlägt, wenn der DS18B20 während der Wandlung bei einer Bussuche angesprochen wird. Genau das passiert bei der Kombination 'dokick/onkick'. Vieleicht kannst Du das ja mal mit 'attr power=parasitic' testen, dann wird alles serialisiert abgearbeitet und die 'dokick'-Bussuche sollte erst nach dem Auslesen der Sensoren drankommen. (Dabei dürfen die Intervalle natürlich nicht zu kurz sein, weil der 1-Wire-bus während der 1-Sekunden Gedenkpause vom OWTHERM dann ja für andere Aufgaben blockiert ist).

Ich zähl mal auf, welche Dateien benötigt werden:

00_OWX.pm (für Arduino, DS2480, DS9097, CUNO, owfs aka OWServer)
00_OWX_ASYNC.pm (für Arduino, DS2480 und DS9097)
10_FRM.pm (für Arduino, sowohl OWX als auch OWX_ASYNC)
10_OWServer.pm (für owfs)
21_OWAD.pm
21_OWCOUNT.pm
21_OWID.pm
21_OWLCD.pm
21_OWMULTI.pm
21_OWSWITCH.pm
21_OWTHERM.pm
OWX_DS2480.pm (für OWX_ASYNC mit DS2480 und DS9097)
OWX_DS9097.pm (für OWX_ASYNC mit DS9097)
OWX_FRM.pm (für OWX_ASYNC mit Arduino)
OWX_SER.pm (für OWX_ASYNC mit DS2480 und DS9097)
GPUtils.pm (für OWX_ASYNC)
lib/ProtoThreads.pm (für OWX_ASYNC)

die 11_OWX_*.pm und OWX_Executor.pm sind obsolet (sollten aber abgesehen von sinnlosen Einträgen in der Commandref keinen Schaden anrichten, wenn sie noch rumliegen)

Gruß,

Norbert

[ntruchsess]

...nicht schön,  aber ich hoffe, das ich die Funktion bald loswerde

Das nenn ich mal einen kreativen Workaround. Ich hätte nicht gedacht, dass irgedwer mit 'set <FRM> reset' tatsächlich was anfangen kann, das habe ich damals eigentlich nur der Vollständigkeit halber mit rein genommen.
Das resetten des FRM-devices hilft wohl indirect: Beim reset der Firmata kappt der Arduino temporär die Verbindung, beim anschließenden reconnect triggert FRM eine Neuinitialisierung des OWX_ASYNC-devices, welches wiederum alle konfigurierten Clients reinitialisiert

Ich bau mal den Fehlercounter im OWTHERM um - das ist aktuell so designed, dass es (hardcoded) nach 5 Fehlern den Sensor praktisch abstellt (intervall auf 9999 Sekunden). Ich halte das für nicht wirklich schlau, ich mach das mal konfigurierbar.

Gruß,

Norbert

[det.]

Ich vermute, dass die Temperaturwandlung fehlschlägt, wenn der DS18B20 während der Wandlung bei einer Bussuche angesprochen wird. Genau das passiert bei der Kombination 'dokick/onkick'. Vieleicht kannst Du das ja mal mit 'attr power=parasitic' testen, dann wird alles serialisiert abgearbeitet und die 'dokick'-Bussuche sollte erst nach dem Auslesen der Sensoren drankommen. (Dabei dürfen die Intervalle natürlich nicht zu kurz sein, weil der 1-Wire-bus während der 1-Sekunden Gedenkpause vom OWTHERM dann ja für andere Aufgaben blockiert ist
Gruß,

Norbert

sorry, der Versuch meldet:

OWX_ASYNC: ignoring attribute dokick because buspower is parasitic

[ntruchsess]

OWX_ASYNC: ignoring attribute dokick because buspower is parasitic

oh, ja klar. Hätte ich doch noch mal in meinen eigenen code schauen sollen
D.h ich hab mir den dokick-task grade noch mal genauer angesehen - das Temperaturwandlungsdelay ist ja im Task selber, nur das Auslesen selbst kann quasiparallel zur Bussuche erfolgen... Aber irgendwo da liegt der Wurm begraben. Ich muss ihn nur noch finden
Auf die Parallelverarbeitung will ich an der Stelle aber nicht komplett verzichten - die ist unverzichtbar, wenn man schnell auf Veränderungen am present-reading (z.B. OWID) reagieren will.

Gruß,

Norbert

[det.]

Auf die Parallelverarbeitung will ich an der Stelle aber nicht komplett verzichten - die ist unverzichtbar, wenn man schnell auf Veränderungen am present-reading (z.B. OWID) reagieren will.
Gruß,
Norbert

Hallo Norbert,
um mal was positives zu berichten, die Probleme mit OWID sind gelöst, das geht jetzt prima. Um das Intervall dort dauerhaft auf 15 zu setzen, muß das Intervallin OWX-ASYNC dann auch auf 15 gesetzt sein? Bisher stellt sich das nach jeden Neustart wieder auf 300 zurück. Das ist für Türkontakte nicht optimal.

[fhem-challenge]

Das nenn ich mal einen kreativen Workaround. Ich hätte nicht gedacht, dass irgedwer mit 'set <FRM> reset' tatsächlich was anfangen kann, das habe ich damals eigentlich nur der Vollständigkeit halber mit rein genommen.
Das resetten des FRM-devices hilft wohl indirect: Beim reset der Firmata kappt der Arduino temporär die Verbindung, beim anschließenden reconnect triggert FRM eine Neuinitialisierung des OWX_ASYNC-devices, welches wiederum alle konfigurierten Clients reinitialisiert

Ich bau mal den Fehlercounter im OWTHERM um - das ist aktuell so designed, dass es (hardcoded) nach 5 Fehlern den Sensor praktisch abstellt (intervall auf 9999 Sekunden). Ich halte das für nicht wirklich schlau, ich mach das mal konfigurierbar.

Gruß,

Norbert

Ja, [Firmata] reset hilft in der Tat. Darüber hinaus hatte ich noch mit dem Configurable Firmata Sketch ein Problem (ich lasse es auf dem Mega 2560 laufen). In einigen "unklaren" Konstellationen hängte sich sogar bei Abfrage der TempWerte durch FHEM auch der Arduino auf. Das habe ich nun durch den neuen Bootloader im Arduino Mega unter Verwendung des Watchdogs lösen können.

Ich muss den Aufwand deshalb treiben, da ich (vielleicht zu früh), diese Umgebung auch produktiv einsetze (Heizungs und Poolsteuerung).

Viele Grüße!

Andreas

[cwagner]

Hi Norbert,

nachdem, wie berichtet owx_async nun bei mir recht stabil läuft und ich den Performance-Gewinn sehr schätzen gelernt habe, gehe ich nun den verbleibenden, regelmäßigen Fehlermeldungen nach, die ich gar nicht verstehe:

Code Auswählen Erweitern

2014.08.19 23:09:59 4: OWX_ASYNC_RunTasks: OWio1 task exited: OWX: 1-Wire devices found on bus OWio1
20.0C2C0C000000      DS2450         Umweltsensor
10.787E83020800      DS18S20/DS1920 T_Vorlauf_FBH
10.541E0B000800      DS18S20/DS1920 T_Warmwasser
10.0576A8020800      DS18S20/DS1920 T_Heizung
28.905F9B010000      DS18B20        Aussenluft
28.A8A49B010000      DS18B20        T_Ruecklauf_Anhebung
28.CA0FAC040000      DS18B20        Zuluft
28.0E37AC040000      DS18B20        Abluft
28.AEE870010000      DS18B20        Dachfenster_Sued
28.810671010000      DS18B20        T_Ruecklauf
28.1307AC040000      DS18B20        Fortluft
26.10F326010000      DS2438         TF_Galerie
29.68980C000000      DS2408         Switch_Heizkeller

2014.08.20 00:08:05 1: OWX_SER::Search CRC failed : 18.541E0B000800.35
2014.08.20 00:08:05 4: OWX_ASYNC_PT_Kick: Failure in alarm-search: OWX_SER::Search CRC failed : 18.541E0B000800.35 at ./FHEM/OWX_SER.pm line 390.

2014.08.20 00:54:31 1: OWX_SER::Search CRC failed : 20.0C2C0C000000.FF
2014.08.20 00:54:31 4: OWX_ASYNC_PT_Kick: Failure in search: OWX_SER::Search CRC failed : 20.0C2C0C000000.FF at ./FHEM/OWX_SER.pm line 390.

2014.08.20 03:34:40 1: OWX_SER::Search CRC failed : 20.0C2C0C0000F8.FF
2014.08.20 03:34:40 4: OWX_ASYNC_PT_Kick: Failure in search: OWX_SER::Search CRC failed : 20.0C2C0C0000F8.FF at ./FHEM/OWX_SER.pm line 390.

2014.08.20 03:37:44 1: OWX_SER::Search CRC failed : 20.0C2C0CFEFFFF.FF
2014.08.20 03:37:44 4: OWX_ASYNC_PT_Kick: Failure in alarm-search: OWX_SER::Search CRC failed : 20.0C2C0CFEFFFF.FF at ./FHEM/OWX_SER.pm line 390.

2014.08.20 04:15:14 1: OWX_SER::Search CRC failed : 20.0C2C0C80FFFF.FF
2014.08.20 04:15:15 4: OWX_ASYNC_PT_Kick: Failure in search: OWX_SER::Search CRC failed : 20.0C2C0C80FFFF.FF at ./FHEM/OWX_SER.pm line 390.

2014.08.20 04:21:18 1: OWX_SER::Search CRC failed : 20.0C2C0C0000FF.FF
2014.08.20 04:21:18 4: OWX_ASYNC_PT_Kick: Failure in alarm-search: OWX_SER::Search CRC failed : 20.0C2C0C0000FF.FF at ./FHEM/OWX_SER.pm line 390.
2014.08.20 06:26:25 2: OWX: 1-Wire devices found on bus OWio1 (Umweltsensor,T_Vorlauf_FBH,T_Warmwasser,T_Heizung,Aussenluft,T_Ruecklauf_Anhebung,Zuluft,Abluft,Dachfenster_Sued,T_Ruecklauf,Fortluft,TF_Galerie,Switch_Heizkeller)
2014.08.20 06:26:25 4: OWX_ASYNC_RunTasks: OWio1 task exited: OWX: 1-Wire devices found on bus OWio1
20.0C2C0C000000      DS2450         Umweltsensor
10.787E83020800      DS18S20/DS1920 T_Vorlauf_FBH
10.541E0B000800      DS18S20/DS1920 T_Warmwasser
10.0576A8020800      DS18S20/DS1920 T_Heizung
28.905F9B010000      DS18B20        Aussenluft
28.A8A49B010000      DS18B20        T_Ruecklauf_Anhebung
28.CA0FAC040000      DS18B20        Zuluft
28.0E37AC040000      DS18B20        Abluft
28.AEE870010000      DS18B20        Dachfenster_Sued
28.810671010000      DS18B20        T_Ruecklauf
28.1307AC040000      DS18B20        Fortluft
26.10F326010000      DS2438         TF_Galerie
29.68980C000000      DS2408         Switch_Heizkeller


Das Spannende: followalarms =off auf OWio1 und es gibt keine Devices 18.541E0B000800.35 und 20.0C2C0C0000FF.FF. Ich finde auch kein Device mit dieser Nummer in meinen CFGs.

Was kann ich gegebenenfalls noch tun, um die auszumerzen? Warum aber wird überhaupt nach einem Alarm auf denen gesucht?

Herzliche Grüße

Christian

[ntruchsess]

Das habe ich nun durch den neuen Bootloader im Arduino Mega unter Verwendung des Watchdogs lösen können.
Ich muss den Aufwand deshalb treiben, da ich (vielleicht zu früh), diese Umgebung auch produktiv einsetze (Heizungs und Poolsteuerung).

Hallo Andreas,

Watchdog ist etwas, was in der Arduino-(software)-plattform einfach fehlt um die Teile produktiv in Steuerungen einzusetzen. Die Teile sind ohne abgestimmte Entstörmaßnahmen sowieso nicht EMV-fest genug und stürzen gerade in Verbindung mit z.b. billigen Relaisplatinen ja gerne mal ab. Ich denke man findet keinen µC in einer komerziellen Steuerung auf dem kein Watchdog realisiert ist.

vieleicht magst Du dazu ja mal ein kleines Tutorial ins Wiki stellen?

Gruß,

Norbert

[ntruchsess]

Code Auswählen Erweitern


2014.08.20 00:08:05 1: OWX_SER::Search CRC failed : 18.541E0B000800.35
2014.08.20 00:08:05 4: OWX_ASYNC_PT_Kick: Failure in alarm-search: OWX_SER::Search CRC failed : 18.541E0B000800.35 at ./FHEM/OWX_SER.pm line 390.
...
10.541E0B000800      DS18S20/DS1920 T_Warmwasser


Das Spannende: followalarms =off auf OWio1 und es gibt keine Devices 18.541E0B000800.35 und 20.0C2C0C0000FF.FF. Ich finde auch kein Device mit dieser Nummer in meinen CFGs.

Was kann ich gegebenenfalls noch tun, um die auszumerzen? Warum aber wird überhaupt nach einem Alarm auf denen gesucht?

Hallo Christian,

die Alarm-suche sucht nicht geziehlt nach dem Device 18.541E0B000800.35, sondern findet es. Das passiert offenbar weil das 10.541E0B000800 bei der Alarm-search falch geantwortet hat. (Das gibt natürlich einen CRC-fehler, dafür ist der CRC ja da!). Das hat mit followAlarms auch nichts zu tun (das Attribut ist ein nicht ausimplementiertes Relikt vermutlich von Peter Henning, in OWX_ASYNC tut es bisher auch noch nichts). Eigentlich könnte man es weglassen - oder die Durchführung der Alarm-search von diesem Attribut abhängig machen (so das man sie ganz abstellen kann). Ich wüßte auch nicht, was man als sinnvolle Folgeaktion außer setzen des 'alarm'-readings implementieren könnte (auf das Reading kann man ja mit einem notify reagieren).
Ich vermute mal stark, dass das Problem daher kommt, dass beim OWX_ASYNC die Alarm-search läuft während die DS18B20 gerade Ihre Temperaturwandlung machen. Das ändere ich gerade.

Gruß,

Norbert