Hallo Mitstreiter,
habe heute nach dem Update folgende Sachen festgestellt:
21_OWTHERM - FHEM startet nicht mit der Version von heute - nach Austausch mit älterer Version geht's wieder;
Im LOG finden sich fortlaufen solche Einträge:
2013.02.12 19:04:11 2: CUL_0: unknown message ? (K97223009002B89FT001C00A600E4 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:04:11 2: CUL_0: unknown message ? (? (K97223009002A G M R T001C0069A6E4 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:04:21 2: CUL_0: unknown message ? (? (? (K97223009002A G M R TH90530105000003 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:04:51 2: CUL_0: unknown message ? (? (? (? (K97223e of B CT0D6200A6F5F7 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:04:57 2: CUL_0: unknown message ? (? (? (? (? (K97 C F i A G M R T V W XFDB7D003A4FEE is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:04:57 2: CUL_0: unknown message ? (? (? (? (? (? () Use oneFDB7D013A4FEC is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:05:07 2: CUL_0: unknown message ? (? (? (? (? (? (B C F i A G T5615D802E4 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:05:09 2: CUL_0: unknown message ? (? (? (? (? (? B C F i A G MT5615D882E4 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:05:23 2: CUL_0: unknown message ? (? (? (? (? (? f B C F HBC1A017400001E is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:06:02 2: CUL_0: unknown message ? (? (? (? (? (? (?B C F i A GT001C00A600E4 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:06:02 2: CUL_0: unknown message ? (? (? (? (? (? (of B C F i T001C0069A6E3 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:06:14 2: CUL_0: unknown message ? (? (? (? (? (? (f B C F i A T7C99680224 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:06:14 2: CUL_0: unknown message ? (? (? (? (? (? B C F i A T7C99688225 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:06:34 2: CUL_0: unknown message ? (? (? (? (? (? C F i A G M FDB7D003A4FF2 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:06:34 2: CUL_0: unknown message ? (? (? (? (? (? (of B C F i AFDB7D013A4FF0 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.12 19:06:47 2: CUL_0: unknown message ? (? (? (? (? (? (of B C F i K97233009002BA9FT0D6200A6F5F7 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
Eine Beeinträchtigung von weiteren Funktionen konnte ich dabei bisher nicht feststellen.
Unter bestimmten Startbedingungen führt die letzte Version von OWTHERM zu einer unendlichen Rekursion. Ist behoben und eingecheckt - werde ich morgen noch einmal genau testen.
LG
pah
Hallo Peter,
vielen Dank, OWTHERM macht wieder was es soll.
Es gibt allerdings neue LOG Einträge in der Form:
2013.02.13 07:59:38 3: OWTHERM: Device OWX_01_56EA4E0E0000 defined.
2013.02.13 08:28:23 3: OWX: Search 2nd return has wrong parameter with length = 0
2013.02.13 09:31:15 3: OWX: Search 2nd return has wrong parameter with length = 0
2013.02.13 09:42:07 3: OWX: Search 2nd return has wrong parameter with length = 0
und das OWID Device verschwindet aus der Übersicht, falls die überwachte Tür beim restart zufällig offen steht. Das wurde zwar schon früher mal diskutiert, aber ich halte es trotzdem immer noch für nicht hilfreich. Es müsste doch möglich sein, die OWID Device beim restart zu initialisieren, auch wenn sie nur in der config eingetragen und gerade physisch offline sind. Das das bei den anderen Sensortypen keinen Sinn macht ist klar. So sieht man gleich, ob die Dinger funktionieren, anders als bei OWFS.
Das geht auch, "verschwinden" können nur die automatisch definierten Devices. Also trag es bitte von Hand in die Konfigurationsdatei ein, dann geht es nimmer weg.
LG
pah
Hallo Peter,
stimmt! Von Hand eingetragenes OWID bleibt!
allerdings ist da offenbar ein Problem, was ich bis letztes Wochenende so nicht im LOG hatte:
2013.02.13 13:05:06 3: OWX: Search 2nd return has wrong parameter with length = 0
2013.02.13 13:05:06 1: OWX: Search CRC failed
2013.02.13 13:37:46 3: OWX: Search 2nd return has wrong parameter with length = 0
2013.02.13 13:37:46 1: OWX: Search CRC failed
(1wire device /dev/ttyUSB0 mit DS2480)
Das führte heute Vormittag zum Totalausfall des 1wire Systems innerhalb FHEM.
Gut das ich heute Bürotag habe...
Oha - das ist das erste Mal, dass ich diese Meldung sehe.
Kann eigentlich auch gar nicht vorkommen. Nicht einmal, wenn ein definiertes OWID Device nicht vorhanden ist - es wird sang- und klanglos als "not present" markiert.
Irgendwelche genaueren Informationen, wie es dazu kam ?
LG
pah
genauere Informationen kann ich nicht viele liefern, habe das LOGfile zwischendurch gelöscht, da es wegen div. Fehler - Einträge zu lang wurde. Seit meinem letzten Post ist noch so ein Eintrag dazugekommen.
An meiner Konfiguration geändert hat sich: 1x DS2438 und 1x DS2401 sind dazugekommen (funktionieren beide) und seit gestern früh die erst fehlgeschlagenen und heute erfolgreichen Updates eingespielt. Im Januar LOG, den ich noch gespeichert habe ist kein solcher Eintrag.
2013.02.13 13:05:06 3: OWX: Search 2nd return has wrong parameter with length = 0
2013.02.13 13:05:06 1: OWX: Search CRC failed
2013.02.13 13:37:46 3: OWX: Search 2nd return has wrong parameter with length = 0
2013.02.13 13:37:46 1: OWX: Search CRC failed
2013.02.13 14:05:57 3: OWX: Search 2nd return has wrong parameter with length = 0
2013.02.13 14:05:57 1: OWX: Search CRC failed
dann sind da noch seit heute diese komischen Einträge - mit Auswirkung auf den dann erst nach Rausziehen und Neueinstecken funktionierenden CUL:
2013.02.13 12:38:53 2: CUL_0: unknown message ? (H90530118000010 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:38:53 2: CUL_0: unknown message ? (? (H905301180000T0D6200A60DFE is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:39:02 2: CUL_0: unknown message ? (? (? (H90530118A G M R T V W T001C002614EB is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:39:21 2: CUL_0: unknown message ? (? (? (? (H90530e of B CHBC1A017100001D is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:40:04 2: CUL_0: unknown message ? (? (? (? (? (H905 B C F i A FDB7D003A4F0E is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:40:04 2: CUL_0: unknown message ? (? (? (? (? (? (of B C F i FDB7D013A4F0E is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:40:05 2: CUL_0: unknown message ? (? (? (? (? (? (f B C F i AT2D7AFA02ED is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:40:05 2: CUL_0: unknown message ? (? (? (? (? (? B C F i A G MT2D7AFA82ED is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:40:06 2: CUL_0: unknown message ? (? (? (? (? (? B C F i A G M T5615D802F9 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:40:06 2: CUL_0: unknown message ? (? (? (? (? (? of B C F i A GT5615D882F8 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:40:08 2: CUL_0: unknown message ? (? (? (? (? (? f B C F i A G MT7C99680224 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:40:08 2: CUL_0: unknown message ? (? (? (? (? (? of B C F i A T7C99688225 is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:40:27 2: CUL_0: unknown message ? (? (? (? (? (? B C F i AT0D6200A60DFE is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:40:32 2: CUL_0: unknown message ? (? (? (? (? (? (B C F i A G FDB7D003A4F0F is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:40:33 2: CUL_0: unknown message ? (? (? (? (? (? (of B C F i FDB7D013A4F0E is unknown) Use one of B C F i A G M R T V W X e f m l t u x
2013.02.13 12:40:42 1: /dev/ttyACM0 disconnected, waiting to reappear
2013.02.13 12:40:52 3: Setting CUL_0 baudrate to 9600
2013.02.13 12:40:52 1: /dev/ttyACM0 reappeared (CUL_0)
2013.02.13 12:40:52 3: CUL_0: Possible commands: BCFiAGMRTVWXefmltux
Was sagt den der CUL, wenn Du mit "get CUL_0 raw V" seine Version abfragst ?
LG
pah
er sagt: CUL_0 raw => V 1.44 CUL868
und seit
2013.02.13 15:12:48 1: OWX: Search CRC failed
2013.02.13 15:25:52 1: OWX: Search CRC failed
2013.02.13 15:26:02 1: OWX: Search CRC failed
2013.02.13 15:26:12 1: OWX: Search CRC failed
2013.02.13 15:26:22 1: OWX: Search CRC failed
.
.
2013.02.13 16:47:17 1: OWX: Search CRC failed
2013.02.13 16:47:27 1: OWX: Search CRC failed
ist das 1wire wieder total ausgefallen mit einer endlosen Liste dieser Einträge. Dazwischen sind immer mal wieder folgende Meldungen:
2013.02.13 15:28:19 3: OWMULTI: Could not get values from device OWX_26_E8B804000000, reason invalid data length, 0 instead of 11 bytes
2013.02.13 15:29:42 3: OWSWITCH: Could not get values from device OWSWITCHB, reason invalid CRC
2013.02.13 15:33:11 3: OWMULTI: Could not get values from device OWX_Wassermelder, reason invalid CRC
2013.02.13 15:33:16 3: OWMULTI: Could not get values from device OWX_26_E8B804000000, reason invalid CRC
2013.02.13 15:38:50 3: OWSWITCH: Could not get values from device OWSWITCHBoden, reason invalid CRC
etc. die Meldungen betreffen alle DS2406 und DS2438, also nicht etwa nur den neu dazu gekommenen.
Hallo,
ich habe gestern das UPDATE gemacht, und ganz ähnliche Vorkommnisse, allerdings benutzte ich kein OW.
Auszug aus log:
2013.02.15 15:29:47 0: Server started with 196 defined entities (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2707 2013-02-12 12:56:55Z rudolfkoenig $, pid 3741)
2013.02.15 15:30:21 2: CUL1: unknown message EOB
2013.02.15 15:30:21 2: CUL1: unknown message LOVF
2013.02.15 15:30:21 2: CUL1: unknown message EOB
2013.02.15 15:30:21 2: CUL1: unknown message ? (LOEOB 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.15 15:30:21 2: CUL1: unknown message LOVF
2013.02.15 15:30:21 2: CUL1: unknown message ? (? (LOEOB is unknT2B1600A606F9 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.15 15:30:21 2: CUL1: unknown message LOVF
2013.02.15 15:30:22 2: CUL1: unknown message ? (LO? (? (LOEOB iA Z E G M R TLOVF 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.15 15:30:41 2: CUL1: unknown message ? (? (LO? (? (LOE i A Z ET162CB902EF 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.15 15:30:42 2: CUL1: unknown message ? (? (? (LO? (? (LOT162CB982EF 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.15 15:30:54 2: CUL1: unknown message ? (? (? (? (LO? (? T406200A633EA 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.15 15:30:56 2: CUL1: unknown message ? (? (? (? (? (LO?A Z E G T40620069A6EA 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.15 15:31:03 2: CUL1: unknown message ? (? (? (? (? (? ( C F i A Z T33731902F6 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.15 15:31:03 2: CUL1: unknown message ? (? (? (? (? (? (T33731982F7 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.15 15:31:30 2: CUL1: unknown message ? (? (? (? (? (? (?T350800A60DF2 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.15 15:31:39 2: CUL1: unknown message ? (? (? (? (? (? (A Z E G M R TT523C00A61319 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.15 15:31:40 2: CUL1: unknown message ? (? (? (? (? (? ( of B C F iT523C00692619 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.15 15:31:53 2: CUL1: unknown message ? (? (? (? (? (? (f B C F i A T4F1000AA001A 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.15 15:31:54 2: CUL1: unknown message LOVF
usw.
Ein get CUL1 version gibt ein CUL1 version => V 1.51 CUL868
Das kommt vor, wenn die serielle Schnittstelle auf "echo" steht, und dem armen culfw seine eigene Daten zurueckgibt.
Normalerweise schaltet fhem echo ab, wenn die CUL Definition mit @xxxx gemacht wird, und wir haben vor ein-zwei Jahren ausfuehrlich diskutiert, wie man dieses Problem lokalisieren kann (siehe stty -a)
Hallo Rudolf,
Komisch ist, dass der Fehler in den ca. 12 Monaten vor dem Update am Montag Morgen nicht aufgetreten ist. Das config sieht bei mir an der Stelle @xxxxx so aus:
define CUL_0 CUL /dev/ttyACM0@9600 1034
define 1wire OWX /dev/ttyUSB0
attr 1wire buspower real
define TRX1 TRX /dev/ttyUSB1@38400
bei mir trat der Effekt jeweils nicht mehr auf, nachdem ich den CUL abgezogen und wieder eingesteckt habe. Das ist als Lösung auf Dauer natürlich mehr als zweifelhaft.
Das sieht so aus, dass das Update am 11.2. zwei Probleme losgetreten hat. Das OWXTHERM Problem hat pah am nächsten Tag gelöst. Das OWX Sytem funktioniert seit dem einwandfrei.
Das mag alles sein, aber ich werde mit diesen Angaben das Problem nicht in vertretbaren Zeit finden koennen.
was für Angaben werden denn benötigt, um ein Fehlverhalten einzugrenzen, was bis 10.2 2012 nicht auftrat und dann offenbar durch ein Update "eingeschleppt" wurde?
Ich helfe da gern mit, wenn Du sagt was Du brauchst.
Ich helfe ebenfalls gerne, das Problem habe ich aber "dummylike" lösen können:
Ich habe heute Nacht sowohl die FB, auf der FHEM läuft, als auch ALLE FHTs ausgeschaltet (Strom weg bzw Batterien raus).
Heute Morgen alles nacheinander wieder eingeschaltet, Fehler seit ca. 2 Stunden nicht wieder aufgetreten...
Das Gelbe vom Ei ist es sicherlich nicht, aber immerhin ein workaround...
Grüße, kostra
P.S.: Es hängt möglicherweise mit der FHT-Meldung actuator: unknown_69: 65% zusammen, die habe ich auch im log gefunden...
> 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.
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.
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
Moin,
ich habe ein ähnliches Problem:
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?