Fehler seit heutigem Update [ FB 7390 / CUL im FS20 mode / OWX / RFXTRX ] FHEM 5.3 dev.

[rudolfkoenig]

> was für Angaben werden denn benötigt

Das habe ich gefuehlt mehr als 100-mal geschrieben: Ich will das Problem selbst nachstellen koennen, versetzt euch also einfach in meine Lage, und erwartet keine Wunder. Ich benoetige eine fhem.cfg (moeglichst minimal), bei dem das Problem deterministisch(!) auftritt. Genau erklaeren, falls ich zum Ausloesen des Problems etwas durchfuehren muss.


> hängt möglicherweise mit der FHT-Meldung actuator: unknown_69: 65% zusammen

Sicher nicht.

[det.]

Hallo Rudolf,
Vergiss es, genau diese Erklärung in welchem Zusammenhang das Problem auftritt können wir nicht liefern, außer dem Zeitpunkt ab dem es aufgetreten ist, und dem Zeitraum vorher, als es noch nicht auftrat.
Da es bei der Vielzahl der Module und den dafür verantwortlichen Autoren verständlicherweise keinen globalen Changelog gibt, ist für Dich wie auch für uns kaum nachvollziehbar, was sich verändert hat und dementsprechend für mögliche Probleme in bestimmten Konstellationen sorgt.
Ich kann damit gut leben, das das geniale FHEM von Zeit zu Zeit etwas experimentell reagiert. In dem Jahr indem ich jetzt dabei sein durfte, gab es immer mal wieder Sachen, die sich durch die emsige Arbeit der Entwickler, denen ich hiermit herzlich danken möchte, wie " von selbst" gelöst haben.
Ich habe seit 2 Tagen den RPI mit COC vom Netz genommen, das hat mMn durch die zwei Funkdevice ( CUL an FB und COC am RPi) zu möglichen Problemen geführt, auch nachdem ich den COC in den von mir garnicht genutzten MAX Modus versetzt habe. Den werde ich an einen Freund verschenken und damit etwas zur Verbreitung von FHEM beitragen.
Seit dem sind diese Meldungen bei mir nicht mehr aufgetreten.

[Prof. Dr. Peter Henning]

Das mit den FHT ohne Batterien ist nun wirklich kein Verfahren, das man irgend jemandem empfehlen sollte.

Natürlich neigen die meisten Anwender zu induktiven Schlussweisen - hier wird das aber doch etwas zu weit getrieben

Das mit den "mehreren Funkdevices" kann es aber auch nicht sein.

Ich betreibe parallel an ein und demselben RPi einen COC, einen CUL und im Netz auch noch einen CUNO. Nachdem ich den CUNO durch einen zweiten RPi von der Aufgabe befreit habe, seine etwas kryptische 1-Wire-Software abzuarbeiten, vollkommen problemlos. Zu den gesammelten Erfahrungen mit CUL und CUNO gehört, dass diese ab und zu durch reine Software-Interaktion in undefinierte Zustände versetzt werden - und ein paar Stunden brauchen, um da wieder herauszukommen.

Was lernt man daraus ?

1. Es wäre eigentlich nötig, alle im Zusammenhang mit CUL/CUNO/COC auftretenden Probleme zu sammeln, systematisch auszuwerten und (unter Beachtung der Versionen von Hard- und Software) zu dokumentieren. Das geschieht nicht, und deshalb steht man immer leicht als Meckerer da. Insofern schade, als die gemeinsame Anstrengung sicher so viele Informationen zu Tage fördern würde, dass man die Probleme nachhaltig beheben kann.

2. Für den konkreten Fall:  Es gibt einen Weg, den CUL wieder in einen definierten Zustand zu versetzen. Nämlich ihn neu zu flashen. Würde ich mal probieren ...

LG

pah

[Marci]

Moin,

ich habe ein ähnliches Problem:

Code Auswählen Erweitern

2013.02.23 12:50:08 2: CUL: unknown message ? (? (? (? (? (? (?i A Z E G MH72740198010046 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.02.23 12:50:08 2: CUL: unknown message ? (? (? (? (? (? (?e of B C F36b00911 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.02.23 12:50:09 2: CUL: unknown message ? (? (? (? (? (? (? F i A Z E GF36b00911 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.02.23 12:50:09 2: CUL: unknown message ? (? (? (? (? (? (?B C F i F36b00911 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.02.23 12:50:09 2: CUL: unknown message ? (? (? (? (? (? (?F i A Z E F36b00911 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.02.23 12:54:05 2: CUL: unknown message ? (? (? (? (? (? (?H23870088913524 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.02.23 12:55:29 2: CUL: unknown message ? (? (? (? (? (? (?i A Z E G H72740101020047 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.02.23 12:59:18 2: CUL: unknown message ? (? (? (? (? (? (? of B C FH23870088613524 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.02.23 13:00:50 2: CUL: unknown message ? (? (? (? (? (? (?of B C F H72740104020047 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x

Das sind die Meldungen meiner beiden Sensoren HMS100T und HMS100TF und das Problem scheint die fhem.pl zu sein. Die letzte funktionierende Version ist die Rev. 2661 vom 2013-02-08 08:22:04Z, bei allen Dev-Versionen die danach kamen, können die Meldungen offensichtlich nicht verarbeitet werden. Kann mir jemand die nächste Rev. der fhem.pl sagen? Dann würde ich evtl. mal gucken, wo die Unterschiede liegen. Vielleicht kann ich das Problem ja selber identifizieren und beheben, wobei ich es fast nicht glaube, da ich mich gerade erst in Perl einarbeite (auch beruflich) und bei fhem sowieso noch gar keinen Überblick habe. Leider ist das Browsen des Trunks ja ziemlich zäh und ein Timeout ist nicht selten (zumindest über den Webbrowser; mit einem SVN-Client habe ich es noch nicht probiert).

Oder kann jemand das eigentliche Problem schon ad-hoc identifizieren?