Fehlermeldungen Fensterkontakte

Begonnen von Tedious, 01 Juni 2020, 11:57:55

Vorheriges Thema - Nächstes Thema

Tedious

Hi,

nachdem FHEM gestern formidabel gecrasht ist bin ich gerde dabei alles neu zu implementieren. Leider scheitere ich an allen Fensterkontakten mit folgender Fehlermeldung:

2020.06.01 11:55:01 3:  cm, source device 0621dd has no name !
2020.06.01 11:55:01 3:  cm, Re-Pairing device MAX_0621dd of type ShutterContact with serial JEQ0608068
2020.06.01 11:55:01 1:  MAX_Parse, ohne Namen msg: MAX,1,define,0621dd,ShutterContact,JEQ0608068,0
2020.06.01 11:55:01 1:  ERROR: empty name in readingsBeginUpdate
2020.06.01 11:55:01 1:  stacktrace:
2020.06.01 11:55:01 1:      main::readingsBeginUpdate           called by ./FHEM/14_CUL_MAX.pm (861)
2020.06.01 11:55:01 1:      main::CUL_MAX_Parse                 called by fhem.pl (3985)
2020.06.01 11:55:01 1:      main::Dispatch                      called by ./FHEM/00_CUL.pm (953)
2020.06.01 11:55:01 1:      main::CUL_Parse                     called by ./FHEM/00_CUL.pm (831)
2020.06.01 11:55:01 1:      main::CUL_Read                      called by fhem.pl (3789)
2020.06.01 11:55:01 1:      main::CallFn                        called by fhem.pl (760)
2020.06.01 11:55:01 1:  readingsUpdate(,firmware,1.3) missed to call readingsBeginUpdate first.
2020.06.01 11:55:01 1:  stacktrace:
2020.06.01 11:55:01 1:      main::readingsBulkUpdate            called by ./FHEM/14_CUL_MAX.pm (862)
2020.06.01 11:55:01 1:      main::CUL_MAX_Parse                 called by fhem.pl (3985)
2020.06.01 11:55:01 1:      main::Dispatch                      called by ./FHEM/00_CUL.pm (953)
2020.06.01 11:55:01 1:      main::CUL_Parse                     called by ./FHEM/00_CUL.pm (831)
2020.06.01 11:55:01 1:      main::CUL_Read                      called by fhem.pl (3789)
2020.06.01 11:55:01 1:      main::CallFn                        called by fhem.pl (760)
2020.06.01 11:55:01 1:  readingsUpdate(,testresult,15) missed to call readingsBeginUpdate first.
2020.06.01 11:55:01 1:  stacktrace:
2020.06.01 11:55:01 1:      main::readingsBulkUpdate            called by ./FHEM/14_CUL_MAX.pm (863)
2020.06.01 11:55:01 1:      main::CUL_MAX_Parse                 called by fhem.pl (3985)
2020.06.01 11:55:01 1:      main::Dispatch                      called by ./FHEM/00_CUL.pm (953)
2020.06.01 11:55:01 1:      main::CUL_Parse                     called by ./FHEM/00_CUL.pm (831)
2020.06.01 11:55:01 1:      main::CUL_Read                      called by fhem.pl (3789)
2020.06.01 11:55:01 1:      main::CallFn                        called by fhem.pl (760)
2020.06.01 11:55:01 1:  readingsUpdate(,PairedTo,123344) missed to call readingsBeginUpdate first.
2020.06.01 11:55:01 1:  stacktrace:
2020.06.01 11:55:01 1:      main::readingsBulkUpdate            called by ./FHEM/14_CUL_MAX.pm (864)
2020.06.01 11:55:01 1:      main::CUL_MAX_Parse                 called by fhem.pl (3985)
2020.06.01 11:55:01 1:      main::Dispatch                      called by ./FHEM/00_CUL.pm (953)
2020.06.01 11:55:01 1:      main::CUL_Parse                     called by ./FHEM/00_CUL.pm (831)
2020.06.01 11:55:01 1:      main::CUL_Read                      called by fhem.pl (3789)
2020.06.01 11:55:01 1:      main::CallFn                        called by fhem.pl (760)
2020.06.01 11:55:01 1:  readingsUpdate(,SerialNr,JEQ0608068) missed to call readingsBeginUpdate first.
2020.06.01 11:55:01 1:  stacktrace:
2020.06.01 11:55:01 1:      main::readingsBulkUpdate            called by ./FHEM/14_CUL_MAX.pm (865)
2020.06.01 11:55:01 1:      main::CUL_MAX_Parse                 called by fhem.pl (3985)
2020.06.01 11:55:01 1:      main::Dispatch                      called by ./FHEM/00_CUL.pm (953)
2020.06.01 11:55:01 1:      main::CUL_Parse                     called by ./FHEM/00_CUL.pm (831)
2020.06.01 11:55:01 1:      main::CUL_Read                      called by fhem.pl (3789)
2020.06.01 11:55:01 1:      main::CallFn                        called by fhem.pl (760)


Die FKs wurden resettet, denn der Versuch sie neu anzulegen. Lege ich sie von Hand an senden sie keinen Status. Hab ich irgendwo einen Dreher?

Grüße Sascha
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

Wzut

Die erste Frage ist wie um alles in der Welt kommt man auf die Idee bei irgendwelchen FHEM Problemen seine Geräte einem Werksreset zu unterziehen ?
Die zweite Frage ist dann wie du es geschafft hast Geräte ohne Namen zu erzeugen ? oder war das autocreate ?
Da das Kind nun schon im Brunnen liegt würde ich erst einmal alle FKs aus FHEM entfernen , autocreate auf enable setzen und das CUL_MAX Device auf verbose 5.
Dann FHEM neu starten, den EVENT Monitor aufmachen und den Filter auf MAX.* setzen und den Haken bei FHEM Log.
Als nächstes mal einen FK open/close schalten lassen (nicht den Anlern Knopf drücken !)
Was sagt der Event Monitor / Log ? Wird ein MAX Gerät erzeugt ?
Wenn nein : Pairmode am cm Device setzen und den Knopf drücken.
Was sagt jetzt Event Monitor / Log ?



Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Tedious

Wie man auf die Idee kommt? Weil sie sich nicht mehr pairen ließen. Sehe ich aber als unkritisch - Batterien raus, waren, rein, Knopf gedrückt halten ;)
Warum? Nunja, weil ich nach Totalschaden einen neuen Brix einrichten musste. Backup ließ sich nicht einspielen, leider haben einzelne Module - warum auch immer, die Abhängigkeiten sind installiert - zum direkten und unreproduzierbaren Start/Crash-Loop von FHEM geführt. Das wiederum führte dazu dass die Load kontiniuerlich bie nahezu 100% lag und SQL Amok lief. Nach 8 Stunden Bugfixing war ichs denn leid, hab eine blanke FHEM.cfg eingespielt und alles neu implementiert. Bis auf die MAX-FKs, die wollten in der Gesamtheit nicht ;)

80% habe ich inzwischen implementiert bekommen, der Rest meldet leider nach wie vor "cm, source device 0621dd has no name !"
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

Wzut

oh oh da liegt aber ein dickes falsch Verstehen vor. Wenn du MAX Geräte auf Werkseinstellung zurück setzt löschst du intern Register mit Werten,
das hat absolut nichts mit FHEM zu tun. D.h. auch wenn man FHEM ganz neu aufsetzt gibt es keinen Grund die Geräte direkt anzufassen.
Nun gut, du müsstest jetzt als nächstes herausfinden was es mit der Leiche 0621dd  auf sich hat. Es kann ja nicht sein das mehr als FK die für sich beansprucht und wie die in deiner fhem.cfg verankert ist.
Ich würde dir ja gerne helfen , aber solange du dich weigerst meine Fragen zu beantworten und  keine cm verbose 5 Logs lieferst kann ich nur das Muster auf dem Boden meiner Kaffeetasse versuchen zu deuten .... 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Tedious

Sorry für die kurze Antwort, ich bin auf der Arbeit. Insofern kann/konnte ich das gerade nicht komplett beantworten.

Ums noch mal auseinander zu dröseln (außer dem was ich schon geschrieben hatte).

Im ersten Post steht ein Log-Auszug beim Versuch das Gerät zu pairen. Die Punkte die Du genannt hat hatte ich schon alle probiert (autocreate, Event erzeugen, etc.). Ca. 80% sind neu angelernt, beim Rest kommt immer ein "source device has no name". Genau aus dem Grund erzeugt er auch kein Device, deswegen war ich ratlos und hatte den Post generiert. Händisch erzeugen geht zwar, aber er empfängt keine Readings (state ???).

Grundlegendes Setup -1 x MapleCun, ein Stack als Cul_Max, Erdgeschoss. 1x umgeflashter Cube im Keller, beide in einer cm-Wolke. Komplettes Setting lief bis zum Crash tadellos. Kann heute Abend noch v5-Logs schicken, klar.
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

Wzut

Der erste Log ist fast nutzlos da er nicht mit verbose 5 erstellt wurde und so für mich wichtige Informationen fehlen.
Und helfen würden ggf. auch vollständige lists der beiden CULs und des CM Device.
Um mehr über 0621dd zu erfahren gib diese bitte mal im cm Device bei get deviceinfo ein und poste die Ausgabe.
Diese 0621dd muß sich auch irgendwo in deiner fhem.cfg verstecken, FHEM erfindet die Adresse nicht einfach mal eben so,
denn selbst wenn mal ein fehlerhafter Eintrag in $modules{defptr}{MAX} sein sollte, überlebt der einen FHEM Neustart nicht.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Tedious

Hi,

hier die Infos:

get deviceinfo liefert "no MAX device". In der fhem.cfg findet sich kein 0621dd (geprüft klassisch via Notepad++).

Die Lists:

cm:
Internals:
   CulMax_MAXID 123344
   CulMax_MSGCNT 164
   CulMax_RAWMSG Z0B01063010948D1234560012
   CulMax_RSSI -82.5
   CulMax_TIME 2020-06-04 10:23:17
   CulMax_VERSION 154
   DEF        123456
   FUUID      5c5c285c-f33f-4ec3-4acb-17b86f11ca6bb836
   IODev      CulMax
   IOgrp      mapleCUL,CulMax
   LASTInputDev mapleCUL
   MSGCNT     239
   NAME       cm
   NR         38
   STATE      CulMax:ok,mapleCUL:ok Last:mapleCUL
   SVN        21994
   TYPE       CUL_MAX
   addr       123344
   cnt        0
   mapleCUL_MAXID 123344
   mapleCUL_MSGCNT 200
   mapleCUL_RAWMSG Z0B01063010948D1234560012
   mapleCUL_RSSI -83.5
   mapleCUL_TIME 2020-06-04 10:23:17
   mapleCUL_VERSION 154
   pairmode   0
   retryCount 0
   sq         0
   Helper:
     DBLOG:
       state:
         myDbLog:
           TIME       1591258997.65358
           VALUE      CulMax:ok,mapleCUL:ok Last:mapleCUL
   READINGS:
     2020-02-12 10:24:49   packetsLost     13138
     2020-06-04 10:23:17   state           CulMax:ok,mapleCUL:ok Last:mapleCUL
   sendQueue:
Attributes:
   IODev      CulMax
   IOgrp      mapleCUL,CulMax
   alias      cm
   fakeSCaddr 222222
   fakeWTaddr 111111
   room       CULs


mapleCUL:
Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/serial/by-id/usb-STM32_MapleCUL_000856c5-if00@38400 4444
   DeviceName mapleCUL
   FD         8
   FHTID      4444
   FUUID      5c5c285c-f33f-4ec3-027c-15e2f865d0659ce9
   NAME       mapleCUL
   NR         23
   NR_CMD_LAST_H 2
   PARTIAL   
   RAWMSG     *r55F1E7000332000E16BCFB3D
   RSSI       -83.5
   STACKED    mapleCUN2
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) MapleCUNx4_0F (F-Band: 868MHz)
   initString X21
Zr
Za123344
Zw111111
   mapleCUL_MSGCNT 19905
   mapleCUL_TIME 2020-06-04 10:43:43
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2020-05-03 09:29:57   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2020-06-03 18:44:44   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2020-06-01 14:27:34   credit10ms      3600
     2019-01-18 21:21:59   fhtbuf          AE
     2019-01-18 22:28:49   raw             *r55F1EE000532003429990548
     2020-06-04 10:43:43   state           Initialized
     2020-01-14 07:50:50   version         V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) MapleCUNx4_0F (F-Band: 868MHz)
   XMIT_TIME:
     1591202692.03083
     1591202692.66212
Attributes:
   alias      CUL_Max
   icon       cul_cul
   maxid      123344
   model      CUL
   rfmode     MAX
   room       CULs


OK


CUL_Max
Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXOefhltxz
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   CulMax_MSGCNT 165
   CulMax_TIME 2020-06-04 10:43:55
   DEF        192.168.192.52:2323 1234
   DeviceName 192.168.192.52:2323
   FD         15
   FHTID      1234
   FUUID      5ed4034d-f33f-4ec3-6356-48c40aa08ee68d65
   NAME       CulMax
   NR         152
   NR_CMD_LAST_H 2
   PARTIAL   
   RAWMSG     Z0B1C063000CC6F1234560010E8
   RSSI       -86
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUBe (F-Band: 868MHz)
   initString X21
Zr
Za123344
Zw111111
   Helper:
     DBLOG:
       credit10ms:
         myDbLog:
           TIME       1591245922.21403
           VALUE      3600
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2020-06-01 14:05:32   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2020-06-03 18:44:49   cmds             B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
     2020-06-04 06:45:22   credit10ms      3600
     2020-06-04 10:43:55   state           Initialized
   XMIT_TIME:
     1591242328.20481
     1591245922.21607
Attributes:
   alias      Cul_Max_Keller
   maxid      123344
   rfmode     MAX
   room       CULs
   verbose    1


OK


Verbose 1 liefere ich noch nach, bin (leider wieder) auf der Arbeit.. ;)
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

Wzut

OK, die drei sehen ganz gut aus , bis auf eine Kleinigkeit beim cm :
ZitatDEF        123456
hier würde ich das DEF auf deine eigentlich verwendete MAXID 123344 ändern, einfach um mögliche Fehlerquellen zu vermeiden/auszuschliessen.

OK es findet sich also nichts mit 0621dd in deiner fhem.cfg, aber aus irgend einem Grund wird beim Repairing  festgestellt das da etwas halbes bereits vorhanden ist.
Um hier sauber zu werden leg doch bitte mittels define den FK mit dieser Adresse von Hand an und speichere die FHEM config.
Auch wenn du meinst er sendet dann nichts, das sieht man dann schon im verbose 5 Log, auf jeden Fall sind dann schon mal die ganzen Warnings weg.

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Tedious

Danke für den Hinweis, editiere ich.

Und jetzt wirds lustig - jetzt waren ca. 12 Stunden die Batterien draussen - Batterien rein, hat sich gepaired. :-/
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

Wzut

schön für dich aber unbefriedigend für mich.
Ich hätte gern gewusst wie es zu diesen unvollständigen defines kommt und es gefixt, so kann ich lediglich zukünftig darauf anders reagieren.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Tedious

Kann ich verstehen - ich verstehe auch lieber warum etwas nicht funktioniert hat, denn weiß ich das beim nächsten Mal :-/ aber als Hotfix kann ich nur sagen - versuchen das Ding mal nicht nur 1 oder 2 Minuten, sondern Stunden bis einem Tag ohne Betterien liegen lassen..

Nevertheless - danke für Deine Hilfe und Deine Arbeit am Modul!
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...