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
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 ?
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 !"
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 ....
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.
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.
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.. ;)
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.
Danke für den Hinweis, editiere ich.
Und jetzt wirds lustig - jetzt waren ca. 12 Stunden die Batterien draussen - Batterien rein, hat sich gepaired. :-/
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.
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!