Huhu ihr Lieben,
Lösungsansatz im letzten Beitrag
lange hat es gedauert, nun habe ich mal wieder ein dickes Problem.
Nachdem mein nanoCUL zunehmend den Dienst quittiert und jeden Epileptiker mit seinen zwei LEDs ins Nirwana schicken könnte, habe ich beschlossen die neue a-culfw auf den Arduino zu flashen. Alles top gelaufen. (Normalerweise habe ich das Diskolicht mit dem Entfernen der Spannungsquelle behoben, sprich USB raus und wieder rein.) Jedenfalls ging danach alles wieder prima, bis auf, dass das Heizungsthermostat sich absolut nicht anlernen lassen wollte.
Ich schaute, alles sendet fleißig Daten, meine Temperatursensoren welche über HM laufen, der Türsensor.
Also fix Batterien raus, wieder rein, pairen angestoßen. Wieder nix. Das habe ich etliche Male probiert. Irgendwann schaute ich, wird denn, wenn ich das alte Device lösche, per autocreate ein neues angelegt? Siehe da, mein nanoCUL scheint auch das Thermostat zu empfangen. Nur die 30 Sekunden auf dem Ventil verstreichen, es zeigt keine Verbindung zum CUL an. Aus mir unerklärlichen Gründen empfängt also der CUL Daten, denn er weiß ja um die Anwesenheit des Thermostates, aber Pairen geht partout nicht.
Nun weiter, hmInfo kontaktiert. So viel habe ich dort noch nie gesehen:
missing register list
Max_Heizung: RegL_00.
Max_Heizung_Clima: RegL_01.,RegL_07.
Max_Heizung_ClimaTeam: RegL_01.
Max_Heizung_Climate: RegL_01.
Max_Heizung_Weather: RegL_01.
Max_Heizung_WindowRec: RegL_01.
Max_Heizung_remote: RegL_01.
Max_Sensor: RegL_00.
Max_Sensor_Values: RegL_01.
Max_Tur: RegL_00.,RegL_01.
Sensor_Draussen: RegL_00.
Sensor_Draussen_Values: RegL_01.
peer list incomplete. Use getConfig to read it.
incomplete: Max_Heizung_Clima:
incomplete: Max_Heizung_ClimaTeam:
incomplete: Max_Heizung_Climate:
incomplete: Max_Heizung_Weather:
incomplete: Max_Heizung_WindowRec:
incomplete: Max_Heizung_remote:
incomplete: Max_Tur:
peer not verified. Check that peer is set on both sides
wz_vT_Sensor1 p:Max_Heizung_Weather
templist mismatch
Max_Heizung_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
Die IT-Steckdosen über den gleichen CUL können auch geschaltet werden. Ich verstehe nicht so recht, wie ich, ohne eine Änderung, außer einem Update, alles so gegen die Wand fahren konnte.
Nun bin ich heillos überfragt. Natürlich, die obligatorische Suche nach einem Thema mit möglicher Lösung wurde erledigt. Leider ohne Erfolg.
Ich hoffe, jemand möge mich erleuchten können und sich kurz hier zu Wort melden, da ich ungern wieder alles von vorn aufsetzen möchte, zumindest den HM-Part.
Ich danke euch,
Grüße, Max!
Moin
Da sich keiner opfert, will ich mal versuchen zu helfen.
Als erstes der Hinweis, ein CUL ist nicht das IODev der Wahl fuer HM!
Um das HMInfo zu bereinigen, solltest Du mal auf den entsprechenden devices ein getConfig machen. Aber daran denken, dass Du irgendwann zuviel Traffic erzeugst, und der CUL eine Zwangspause macht!
Ein list vom CUL und zumindest vom HM-CC-RT-DN waeren hilfreich. Die anderen drei kannst du aber auch gleich mit einstellen.
Deine Beschreibung mit Batterie raus/rein leuchtet auch nicht ein! Die mittlere Taste lange druecken bringt auch den pairing-Modus.
Gruss Christoph
Hi,
Die IT-Steckdosen über den gleichen CUL können auch geschaltet werden. Mehrere Protokolle parallel über einen CUL bei Homematic? Vergiss es ... :-X
Gruß Otto
Guten Abend ihr,
danke für eure Antworten. Zuerst möchte ich auf die letzte eingehen.
Ich hatte bis jetzt noch kein Problem damit, den CUL für das Steuern von Homematic und IT-Steckdosen zu missbrauchen. Da die 3 Steckdosen im gleichen Raum sind, wie der Sender komme ich mit der geringeren Reichweite bei 433MHz prima aus. Ansonsten wird ja alles bei 868MHz gefüttert.
Ich verstehe leider nicht, wieso dies nun nicht funktionieren soll, wenn es doch schon seit 6 Monaten einwandfrei läuft.
Letztendlich laufen die Steckdosen ja weiterhin prima.
Weshalb gilt ein CUL nicht als bevorzugtes IODev? Das mein nanoCUL nicht die beste Leistung erbringt, das verstehe ich komplett, aber viele setzen ja auch auf CUL's von Busware usw.
Batterie raus/rein und alle 3 Tasten beim einlegen der Batterien startet das Thermostat in einem Werkszustand. Ist eigentlich das selbe, wie wenn ich es per reset zurücksetze. Habe ich beides probiert. Das Pairing habe ich dann letztendlich wie von dir beschrieben, mit dem Drücken der mittleren Taste, angestoßen. Entschuldigt meine unklare Ausführung.
Die Liste, die benötigt wird vom Thermostat:
Internals:
CFGFN
DEF 613D91
FUUID 5cbe5473-f33f-38d4-a0b5-254102358f49c34c
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 1
NAME Max_Heizung
NOTIFYDEV global
NR 137
STATE CMDs_pending
TYPE CUL_HM
chanNo 01
channel_01 Max_Heizung_Weather
channel_02 Max_Heizung_Climate
channel_03 Max_Heizung_WindowRec
channel_04 Max_Heizung_Clima
channel_05 Max_Heizung_ClimaTeam
channel_06 Max_Heizung_remote
lastMsg No:01 - t:00 s:613D91 d:000000 1400954F4551313731323937385900FFFF
nanoCUL_MSGCNT 1
nanoCUL_RAWMSG A1A018400613D910000001400954F4551313731323937385900FFFF::-58.5:nanoCUL
nanoCUL_RSSI -58.5
nanoCUL_TIME 2019-04-23 01:55:31
protCmdPend 21 CMDs_pending
protLastRcv 2019-04-23 01:55:31
protRcv 2 last_at:2019-04-23 01:55:31
protState CMDs_pending
rssi_at_nanoCUL cnt:2 min:-58.5 max:-58.5 avg:-58.5 lst:-58.5
READINGS:
2019-04-23 02:13:30 Activity dead
2019-04-23 01:55:31 D-firmware 1.4
2019-04-23 01:55:31 D-serialNr OEQ1712978
2019-04-23 01:55:31 R-pairCentral set_0x310597
2019-04-23 21:54:05 state CMDs_pending
cmdStack:
++A001310597613D9100050000000000
++A001310597613D91000802010A310B050C97
++A001310597613D910006
++A011310597613D9186041E
++A011310597613D9186041E
++A011310597613D91860409
++A011310597613D91860409
++A001310597613D9100040000000000
++A001310597613D910103
++A001310597613D9101040000000001
++A001310597613D910203
++A001310597613D9102040000000001
++A001310597613D910303
++A001310597613D9103040000000001
++A001310597613D910403
++A001310597613D9104040000000001
++A001310597613D9100040000000007
++A001310597613D910503
++A001310597613D9105040000000001
++A001310597613D910603
++A001310597613D9106040000000001
helper:
HM_CMDNR 1
PONtest 1
mId 0095
peerFriend
peerOpt -:thermostat
regLst 0
rxType 140
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +613D91,02,00,00
nextSend 1555977331.90532
prefIO
rxt 2
vccu
p:
613D91
00
00
00
mRssi:
mNo 01
io:
nanoCUL:
-52.5
-52.5
prt:
bErr 0
sProc 2
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rssi:
at_nanoCUL:
avg -58.5
cnt 2
lst -58.5
max -58.5
min -58.5
shRegW:
07 04
shadowReg:
tmpl:
Attributes:
DbLogExclude .*
IODev nanoCUL
IOgrp VCCU:nanoCUL
actCycle 000:10
actStatus dead
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
model HM-CC-RT-DN
room CUL_HM
serialNr OEQ1712978
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
List vom Türsensor:
Internals:
DEF 5F4B27
FUUID 5c66ee05-f33f-38d4-030d-66b3717fd9d11e09
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 34
NAME Max_Tur
NOTIFYDEV global
NR 39
NTFY_ORDER 50-Max_Tur
STATE closed
TYPE CUL_HM
chanNo 01
lastMsg No:3B - t:41 s:5F4B27 d:000000 015100
nanoCUL_MSGCNT 34
nanoCUL_RAWMSG A0C3B86415F4B27000000015100::-53:nanoCUL
nanoCUL_RSSI -53
nanoCUL_TIME 2019-04-23 21:40:53
protCmdDel 4
protCmdPend 3 CMDs_pending
protLastRcv 2019-04-23 21:40:53
protRcv 34 last_at:2019-04-23 21:40:53
protResnd 3 last_at:2019-04-23 01:48:41
protResndFail 1 last_at:2019-04-23 02:30:09
protSnd 4 last_at:2019-04-23 02:30:06
protState CMDs_pending
rssi_at_nanoCUL cnt:34 min:-54 max:-51.5 avg:-52.75 lst:-53
READINGS:
2019-04-23 01:37:03 Activity alive
2018-11-08 23:47:26 D-firmware 1.0
2018-11-08 23:47:26 D-serialNr OEQ1429255
2018-11-08 23:47:26 R-pairCentral set_0x310597
2018-11-08 23:47:26 aesKeyNbr 00
2019-04-23 21:39:56 alive yes
2019-04-23 21:40:53 battery ok
2019-04-23 21:40:53 contact closed (to broadcast)
2019-04-23 21:39:56 recentStateType info
2019-04-23 21:39:56 sabotageError off
2019-04-23 21:40:53 state closed
2019-04-23 21:40:53 trigDst_broadcast noConfig
2019-04-23 21:40:53 trigger_cnt 81
cmdStack:
++A0013105975F4B2700040000000000
++A0013105975F4B2701040000000001
++A0013105975F4B270103
helper:
HM_CMDNR 59
getCfgList all
getCfgListNo ,4
mId 00C7
peerFriend peerAct,peerVirt
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5F4B27,02,00,00
nextSend 1556048453.52326
rxt 2
vccu VCCU
p:
5F4B27
00
00
00
prefIO:
nanoCUL
mRssi:
mNo 3B
io:
nanoCUL:
-47
-47
prt:
bErr 0
sProc 2
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_nanoCUL:
avg -52.75
cnt 34
lst -53
max -51.5
min -54
shadowReg:
tmpl:
Attributes:
DbLogExclude .*
IODev nanoCUL
IOgrp VCCU:nanoCUL
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SCO
room 10_Max_Zimmer,CUL_HM
serialNr OEQ1429255
subType threeStateSensor
List vom CUL-HM:
Internals:
CMDS ABCEeFfGiKlMNRTtUVWXxZ
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 0000
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
FD 8
FHTID 0000
FUUID 5c66ee01-f33f-38d4-c40d-e884339e572cce30
NAME nanoCUL
NR 20
NR_CMD_LAST_H 64
PARTIAL
RAWMSG A0F12A253444029310597010300923218F6
RSSI -79
STATE Initialized
TYPE CUL
VERSION V 1.26.06 a-culfw Build: 315 (2019-04-07_19-59-48) nanoCUL868 (F-Band: 868MHz)
initString X21
Ar
nanoCUL_MSGCNT 944
nanoCUL_TIME 2019-04-23 22:22:36
owner_CCU VCCU
MatchList:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2019-04-23 01:37:01 cmds A B C E e F f G i K l M N R T t U V W X x Z
2019-04-23 02:18:55 raw is00000000000000000000000101000001
2019-04-23 22:22:36 state Initialized
2019-04-23 00:47:54 uptime 0 00:24:36
2019-04-23 01:42:59 version V 1.26.06 a-culfw Build: 315 (2019-04-07_19-59-48) nanoCUL868 (F-Band: 868MHz)
XMIT_TIME:
1556047362.06549
1556047407.37769
1556047527.26244
1556047539.0351
1556047573.57862
1556047715.99674
1556047724.24955
1556047725.53041
1556047862.98791
1556047946.19981
1556047985.94834
1556048123.62704
1556048158.65125
1556048302.37475
1556048316.85236
1556048460.55531
1556048462.90947
1556048479.83475
1556048590.00918
1556048656.77349
1556048659.59991
1556048768.96249
1556048833.71128
1556048856.40074
1556048933.41305
1556049010.64741
1556049053.2336
1556049083.37013
1556049187.57545
1556049219.08175
1556049250.09288
1556049340.27437
1556049364.51238
1556049446.97823
1556049447.1773
1556049447.37111
1556049510.9777
1556049541.44609
1556049541.64517
1556049541.83128
1556049643.84738
1556049667.42878
1556049718.40223
1556049809.39199
1556049840.75465
1556049895.32914
1556049936.85034
1556050037.65735
1556050072.24882
1556050114.05794
1556050234.57398
1556050249.17155
1556050276.76246
1556050424.97604
1556050426.09013
1556050431.50043
1556050558.66473
1556050603.00754
1556050628.42558
1556050742.12014
1556050779.92376
1556050825.36202
1556050911.08373
1556050956.83489
helper:
000000:
QUEUE:
444003:
QUEUE:
444029:
QUEUE:
5F4B27:
QUEUE:
613D91:
QUEUE:
Attributes:
DbLogExclude .*
hmId 310597
rfmode HomeMatic
room 96_Geräte
Und der VCCU, falls benötigt:
DEF 310597
FUUID 5c66ee05-f33f-38d4-6dd8-11cdfbb1f8b7f326
IODev nanoCUL
NAME VCCU
NOTIFYDEV global
NR 21
NTFY_ORDER 50-VCCU
STATE nanoCUL:ok
TYPE CUL_HM
assignedIOs nanoCUL
channel_01 VCCU_Btn1
READINGS:
2019-04-23 22:19:42 IOopen 1
2019-04-23 00:38:44 R-pairCentral set_0x000000
2019-04-23 22:19:42 state nanoCUL:ok
2018-11-10 21:11:57 unknown_444003 received
2018-11-10 20:59:50 unknown_444005 received
2018-11-10 21:14:53 unknown_444029 received
2018-11-08 23:17:14 unknown_5F4B27 received
2019-02-05 22:20:28 unknown_613D91 received
helper:
HM_CMDNR 79
mId FFF0
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu VCCU
ioList:
nanoCUL
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
shadowReg:
tmpl:
Attributes:
DbLogExclude .*
IODev nanoCUL
IOList nanoCUL
IOgrp VCCU
expert 2_raw
model CCU-FHEM
room 96_Geräte
subType virtual
webCmd virtual:update
Und zu guter Letzt noch das "bereinigte" (Sensor_Zelt ist zu ignorieren, da dort die Batterien versagt haben):
missing register list
Max_Heizung: RegL_00.
Max_Heizung_Clima: RegL_01.,RegL_07.
Max_Heizung_ClimaTeam: RegL_01.
Max_Heizung_Climate: RegL_01.
Max_Heizung_Weather: RegL_01.
Max_Heizung_WindowRec: RegL_01.
Max_Heizung_remote: RegL_01.
Max_Tur: RegL_00.,RegL_01.
Sensor_Zelt: RegL_00.
Sensor_Zelt_Values: RegL_01.
peer list incomplete. Use getConfig to read it.
incomplete: Max_Heizung_Clima:
incomplete: Max_Heizung_ClimaTeam:
incomplete: Max_Heizung_Climate:
incomplete: Max_Heizung_Weather:
incomplete: Max_Heizung_WindowRec:
incomplete: Max_Heizung_remote:
incomplete: Max_Tur:
peer not verified. Check that peer is set on both sides
wz_vT_Sensor1 p:Max_Heizung_Weather
templist mismatch
Max_Heizung_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
Nachdem ich mir das ganze mal angeschaut habe, scheint auch der Türsensor ja keine Kommandos anzunehmen, lediglich sendet er Daten an den CUL.
Es scheint sich also nicht um das Thermostat zuhanden, sondern der Fehler liegt bei der Konfiguration der VCCU bzw. des CULs. Wobei es ja auch vor dem Wechsel auf die neue Firmware nicht funktioniert hat, bzw. der Fehler erst urplötzlich seit kurzem auftritt.
Im Endeffekt funktionierte es nicht, ich versuchte es mit der Firmware zu beheben, und es geht immernoch nicht. Vielleicht ein Fehler durch ein FHEM-Update?
Ich habe ja nichts verändert und seit dem Roommate-Debakel bin ich etwas zögerlich.
Grüße, Max :)
Hallo Max,
warum das nicht funktioniert? Weil Homematic bidrectional kommuniziert, d.h. in beiden Richtungen erfordern die meisten Kommunikationsschritte eine ununterbrochene beidseitige Kommunikation. Jede Frage erfordert eine Antwort, jede Information eine Bestätigung. Gerade beim pairing gehen mehrere Frage/Antworten hin und her.
Wenn da zwischendurch die Tür zufällt ist die Kommunikation gestört. Sicher reicht deine Betriebsart aus um ab und an einen Temperaturwert vom Sensor zu empfangen, aber für viel mehr nicht.
Also tue Dir einen Gefallen und kauf Dir einen IO von Homematic und nutze den CUL für IT.
https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale
Gruß Otto
Nabend Otto,
liege ich in der Annahme richtig, dass der CUL nur die Frequenz wechselt, wenn wirklich auch ein Befehl an eine IT-Steckdose versendet wird?
So müsste doch, sofern kein IT-Befehl versendet wird, eine vollumfängliche Kommunikation zwischen den Homematicgerätschaften und dem CUL möglich sein?
Ich habe nun, um diesen Fehler auszuschließen, dass Pairing nochmal angestoßen. Es funktionierte wieder nicht, obwohl keine Kommandos an die IT's gesendet wurden.
Sicherlich ist deine Art der Kommunikation mit HM-Geräten besser geeignet, da weniger fehleranfällig. Dennoch erschließt sich in meinem Falle nicht die Fehlerquelle. Ich bin ja nicht nur hier um das Ding zum Laufen zu bekommen, sondern weil ich es verstehen will und es mich ziemlich wurmt, es nicht in den Griff zu bekommen.
Grüße, Max.
Es ist nicht meine Art der Kommunikation, es ist die von Homematic.
Deine Fehlerquelle ist der CUL und dessen Firmware! Die 7 Zeilen nach der Auflistung in dem kurzen Artikel, den ich verlinkt habe, hast Du gelesen?
Aber Du kannst gerne weiter probieren, wenn Du viel Glück hast wird das Pairing irgendwann funktionieren.
Vorher solltest Du in der VCCU folgendes tunset VCCU clear unknownDev
und in den Geräten vor neuen Pairingversuch :
set <> clear msgEvents
Edit:
Unklar ist mir wieso deine VCCU diese Reading hat:
2019-04-23 00:38:44 R-pairCentral set_0x000000
Keine Ahnung wie so etwas passiert
Woher hast Du diese hmId ?
DEF 310597
Hast Du die schon immer? Hast Du die gewählt? Oder hat die eines Deiner Geräte?
Warum musst Du nach dem CUL Wechsel eigentlich neu pairen?
Gruß Otto
Moin
@Otto: HM und IT parallel geht schon immer mit dem CUL, der schaltet beim Senden um. Das der CUL halt nicht das IODev der Wahl ist, steht auf einem anderen Blatt, und haben wir jetzt ausreichend eroertert.
@bromosky: Du solltest mal sehen, dass Du Deine devices alle der Reihe nach anlernst. Denn von den beiden Gezeigten ist keiner fertig gepaired. Ruhe und Geduld, sowie eine erneute Lektuere ueber das Pairen sollten Dich zum Ziel fuehren. Wenn Du die devices jedesmal resettest, dann kommst Du natuerlich in einen Teufelskreis! Zudem hast Du mit dem HM-Sec-SCO und dem HM-CC-RT-DN zwei Diven, die schon gerne mehrere Anlaeufe brauchen. Ganz nebenbei, der HM-Sec-SCO ist ein Twostate und nicht Threestate!
Du solltest jetzt einfach mal Ottos Hinweis folgen, und die ganzen Meldungen loeschen, und dann langsam von vorne anfangen, bis das set_0x310597 und CMDs_pending weg ist, und dann zum naechsten device gehen.
Gruss Christoph
Guten Morgen,
es bedurfte einer weiteren Nachtschicht und einem Backup aus dem Jahre 2018 und schon ließen sich die Geräte wieder pairen.
Alles schien reibungslos zu funktionieren. Nach einem Update all und einem shutdown restart fingen dann wieder die Probleme an.
Ich bin nun dabei, das Backup erneut aufzuspielen und werde diesesmal kein Update ausführen. Ich hatte ja sowieso die Vermutung, dass mir das Update neulich irgendwas gehörig zerschossen hätte.
Ich halte euch aber auf dem Laufenden, ob das wirklich der Weisheits letzter Schluss ist.
Schönen Tag euch allen, Max.
Hallo Max,
Irgendwie verstehe ich diese Aussagen nicht mehr. Du pairest neu nachdem Du update gemacht hast? Oder was hast Du für Probleme nachdem alles "in Ordung" war und Du update und shutdown restart gemacht hast?
Es geht nur um Homematic Probleme?
Das Du die vorhergehende Version beliebiger, auch einzelner Modul Dateien nach einem update mit restore in sekunden (ohne Nachtschicht ;)) wiederherstellen kannst, weißt Du?
Gruß Otto
Ich melde mich nun auch mal wieder zu Wort.
Vorab, es funktioniert mittlerweile fast alles Tadellos wieder. Der Türsensor zickt zwar, aber ich bin mir sicher, das ich das pairen einfach ein paar mal, wie von @pc1246 beschrieben, behoben bekomme.
Ich habe wieder das Backup als Ausgang benutzt. Ein restore habe ich natürlich mehrfach ausprobiert. Es wollte jedoch nicht den Fehler beheben. Ich nehme an, da mein CUL seit ca 1,5 Monaten gelegentlich ausfällt, ohne jegliche Änderung an ihm vorgenommen zu haben, das Problem sich irgendwo in FHEM eingeschlichen hat. Dies ist jedoch nur eine Vermutung.
Jedenfalls war es mir möglich, Sensoren und Thermostat alle zu pairen (wie gesagt mit Ausnahme des Türsensors, welcher jedoch den state sendet und mehr brauche ich ja auch nicht). Es ist also alles wieder funktionstüchtig. Nur woran es jetzt genau lag, kann ich noch nicht sagen. Ich werde jetzt, wo ich wirklich alles beim Alten habe, ein Backup machen und dann einfach alles updaten außer den Homematic.pm. Ein Versuch ists ja wert. Jedenfalls hat es nichts mit der Firmware des Sticks oder mit Fehlern der Homematic-Geräte zutun sondern es muss ein Softwarefehler in irgendeinem FHEM-Modul sein.
Das ist der neuste Stand. Ich danke euch Otto und pc1246 für eure Hilfe soweit.
@Otto123
Nein, ich paire nicht neu nach einem Update. Nach einem Update waren die Geräte schlicht nicht mehr gepairt. Shutdown restart wurde natürlich gemacht.
Ich wusste aber dennoch nicht, dass ich einzelne Module wiederherstellen kann aus einem restore?! Ich habe in der commandref gesucht und entweder hatte ich mal wieder Tomaten auf den Augen oder dazu steht nichts?
Wie gesagt, ich werde nach einem Backup die HM.pm ausklammern und dann wissen wir, ob es wirklich an dem Modul liegt.
Grüße, Max.
Hallo Max,
pairen ist ein Vorgang, bei dem die Zentrale (FHEM) und dein HM Geräte die hmId "austauschen"/gegenseitig bekannt geben. D.h. FHEM kennt seine hmId aus der Definition, das Gerät hat anschließend seine hmId im eigenen Speicher. Das so etwas flächendeckend verloren geht, kann ich mir nicht vorstellen. Bei einzelnen Geräten soll das schon vorgekommen sein.
Es gibt den Fall, das Definition aus FHEM verschwinden, weil ein Update / Modul fehlerhaft war. Hat aber nichts mit pairen zu tun.
Zum restore (https://commandref.fhem.de/#restore) (ja die Doku ist knapp) ;) Aber wie so oft kann man einfach ein bisschen rumprobieren um Klarheit zu schaffen.
Gib einfach mal restore listin der FHEM Kommandozeile ein.
Dann restore list update
Dann mit einem dort angezeigtem Pfad, z.B.
restore list update/2019-03-23Dann weiter
restore list update/2019-03-23/FHEM Das Restore von einer Datei ginge so. Beispiel:
restore update/2019-03-23/FHEM/10_CUL_HM.pm
Achtung manche Module brauchen mehrere Dateien um konsistent zu funktionieren!
Beispiel:
HMConfig.pm + 10_CUL_HM.pm
Gruß Otto
Wie Otto schon geschrieben hat (daher habe ich das "damals" nicht auch noch "bestätigt") und ich (leidlich) selbst erfahren habe ist ein CUL wirklich nichts für Homematic!
Kann klappen (eine Weile) bis: fhem anderes Timing hat/bekommt (was du als "Bug" interpretieren könntest) oder ein Gerät um die Ecke kommt, was eben (noch) empfindlich(er) auf Timing reagiert...
Bei mir war es "damals" der Klingelsensor...
Alles lief gut nur der wollte ums verr.... nicht ;)
Dann bin ich auf die Timing-optimierte FW umgestiegen...
...damit ging dann auch dieses neue (empfindliche) Gerät.
Letzenendes bin ich dann auf eine "vernünftige" IO-/Funk-HW umgestiegen (in meinem Fall: HM-CFG-USB bzw. mittlerweile HMOD-PCB).
Weil folgendes der Fall ist:
Bei Verwendung eines CUL ist dieser "nur" ein Funkmodul.
Die ganzen Telegramme usw. kommen aus fhem.
Wenn fhem etwas langsam reagiert (und das Gerät empfindlich ist), kommen eben (manchmal) ACKS (weil Homematic ist bidirektional: Frage/Befehl - Antwort/ACK) zu spät und dann geht das schief.
Die "timing-optimierte" FW (zusammen mit Anpassungen in Homematic-Modulen) "entspannt" das (etwas) aber es bleibt vom Ablauf wie es ist...
Fhem etwas "langsam" und schon kann ein Problem kommen.
(daher ist auch das zwischendrin senden in anderen Frequenzen nicht gut: weil auch hier währenddessen Meldungen verloren gehen können / nicht müssen: kann klappen kann aber auch schief gehen)
Bei Verwendung eines "echten" Homematic-IOs werden die Acks direkt von dem "Funkmodul" gesendet. D.h. es ist "entkoppelt" von fhem (zumindest bzgl. ACKS) d.h. wenn ein Gerät Daten schickt werden die Pakete (bis zu einem gewissen Grad) gepuffert und schon mal quittiert. D.h. fhem kann sich "etwas Zeit lassen" diese zu bearbeiten...
Daher ist es vermutlich kein (echter) Bug in der neuen fhem Version, sondern (natürlich) ein anderes Timing was eben zu (diesen) Problemen führt (führen kann).
Aber wie immer (da wir ja in einer freien Welt leben und auch fhem "offen" ist): dein System! Lass es laufen, wie es für dich passt...
Gruß, Joachim
Ich war zu vorlaut und zu voreilig.
Es geht wieder nicht, ohne jegliches zutun. Ihr scheint wirklich alle recht zu haben. Es muss irgendwo einen Fehler in der Kommunikation geben. FHEM hat ja nichts geändert.
Ich war damals froh, den nanoCUL zusammgeschustert zu bekommen und eine günstige Lösung für die Kommunikation gefunden zu haben. Anscheinend ist nun der Punkt gekommen, wo es heißt, kaufste billig, kaufste zwei mal. Ärgerlich, aber nun ist das Kind ja in den Brunnen gefallen.
Der Bausatz HM-MOD-RPI-PCB ist wohl also des Rätsels Lösung. Solangsam wird mir wohl auch die Zeit zu schade (und mein Schlaf zu knapp).
Dort heißt es dann einfach zusammenlöten, aufstecken, in FHEM definieren und mit der VCCU verbinden und alles sollte wieder gehen?
Oder stelle ich mir das jetzt viel zu leicht vor? Denn bei dem lesen des Wikis zu der GPIO-Variante kommen mir ziemlich viele Fragen auf.
Grüße und nochmals vielen Dank für eure Hilfe, besonders an Otto für sein restore-Exkurs. Wieso findet man sowas weder im Wiki noch im Commandref.
Max.
EDIT: Wenn ich mich, an den Blogbeitrag von dir Otto, entlanghangel, so ist es mir möglich die GPIO-Variante auch an dem gleichen RaspberryPi zu betreiben, auf dem auch FHEM läuft, richtig?
Zitat von: bromosky am 25 April 2019, 15:00:37
Anscheinend ist nun der Punkt gekommen, wo es heißt, kaufste billig, kaufste zwei mal. Ärgerlich, aber nun ist das Kind ja in den Brunnen gefallen.
Ging mir auch so...
...bzw. hatte ich den nanoCUL "parallel" zum Spielen (Testsystem)...
Bis es mir dann zu dumm wurde ;)
ABER: bei dir kann/muss er ja für die anderen Aufgaben (IT oder so) bleiben. War also nicht ganz "umsonst". Und: jetzt kann er sich daruf konzentrieren. Bzw. mit einem anderen Funkmodul (433MHz) sogar richtig gut ;)
Zitat von: bromosky am 25 April 2019, 15:00:37
Der Bausatz HM-MOD-RPI-PCB ist wohl also des Rätsels Lösung. Solangsam wird mir wohl auch die Zeit zu schade (und mein Schlaf zu knapp).
Dort heißt es dann einfach zusammenlöten, aufstecken, in FHEM definieren und mit der VCCU verbinden und alles sollte wieder gehen?
Oder stelle ich mir das jetzt viel zu leicht vor? Denn bei dem lesen des Wikis zu der GPIO-Variante kommen mir ziemlich viele Fragen auf.
So der Plan...
...der eigentlich so funktionieren sollte. :)
Zitat von: bromosky am 25 April 2019, 15:00:37
Grüße und nochmals vielen Dank für eure Hilfe, besonders an Otto für sein restore-Exkurs. Wieso findet man sowas weder im Wiki noch im Commandref.
Jep, danke.
Wusste ich auch noch nicht ;)
Zitat von: bromosky am 25 April 2019, 15:00:37
EDIT: Wenn ich mich, an den Blogbeitrag von dir Otto, entlanghangel, so ist es mir möglich die GPIO-Variante auch an dem gleichen RaspberryPi zu betreiben, auf dem auch FHEM läuft, richtig?
Hab mich zwar nicht entlang gehangelt ;)
Aber betreibe 2 HMOD-PCB:
einen als Aufsteckmodul auf dem selben PI wo auch fhem läuft (Testsystem 1)
und einen per USB-Adapter auch auf dem selben PI auf dem fhem läuft (Testsystem 2)
Gruß, Joachim
Im Wiki stehen viele Möglichkeiten.
Grundlegend lötest Du den zusammen und steckst ihn auf die Gpio am den Pi. VCCU hast Du schon, geht damit nahtlos.
Wenn Du fragen zu dem was im Wiki steht oder zu meinem Text (der im Wiki ist auch in Stücken von mir), dann frag einfach :)
Gruß Otto
P.S. Joachim :-* :D
P.P.S. Ja das mit dem restore "Kurs" steht schon lange auf meiner toDo Liste - kommt bald versprochen ;)
Hallo,
ich habe mich gestern an den Lötkolben gesetzt und es funktioniert alles mit der HMOD-PCB. Alles lies sich wunderbar pairen. Überhaupt gar keine Probleme mehr. Einfach die VCCU auf den anderen Sender umgestellt und fertig wars. Der nanoCUL läuft nun nur noch für IT.
Ich verstehe auch absolut nicht, wieso man so häufig von den CUL's im Homematic-Bereich etwas liest, wenn die HMOD-PCB etwa gleichteuer ist und anscheinend deutlich weniger Fehlerpotential bietet.
Danke nochmals an Otto, für seinen tollen Blogbeitrag. Einfach einmal die wichtigsten Schritte gemacht. Überhaupt kein Hexenwerk. Danke!
Und danke auch an die anderen, die sich hier gemeldet hatten.
Kurzer Lösungsansatz:
Durch falsches Timing kann es offensichtlich zu Fehlern bei der Kommunikation zwischen CUL's und HM-Geräten kommen.
Dieser lies sich bei mir leider nicht mehr beheben, weder durch restore, noch durch mehrmalig erneutes Pairen mit dem nanoCUL.
Die Lösung, welche korrekte Timings herstellen kann und bei mir das Problem gelöst hat, war der Selbstbausatz HMOD-PCB-RPI.
Fix zusammengelötet und folgendes Softwaretechnisch gemacht (Alle Befehle von @Otto123):
Bei mir handelt es sich um einen Raspberry Pi 3B+, deshalb musste ich ergänzen mit:
sudo nano /boot/config.txt folgenden Text:
enable_uart=1
dtoverlay=pi3-miniuart-bt
force_turbo=1
Aus sudo nano /boot/cmdline.txt löschte ich dann console=serial0,115200
Danach sudo systemctl disable serial-getty@ttyAMA0.service
Zuletzt noch mit sudo nano /etc/init.d/fhem folgendes Einfügen: sleep 10
Weiter in der Console mit: wget https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3 und sudo cp coprocessor_update.eq3 /opt/fhem/FHEM/firmware/
Einmal Neustarten mit sudo reboot
In FHEM folgt dann:
define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId xxxxxx <- Die x mit Hexadezimal ersetzen, sprich eure gewünschte HMid
set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3 Flasht neue Firmware auf eure HMOD-PCB. Das hat bei mir beim ersten mal nicht funktioniert. Einfach 5 Minuten warten, nochmal den Befehl in FHEM senden. Bei Bedarf wiederholen.
Und dann hat es bei mir tadellos funktioniert, nachdem ich bei der VCCU die gleiche HMid eingegeben habe, wie bei der HMUARTLGW.
Otto hat noch weitere Tipps und Tricks in seinem Blogbeitrag verewigt, falls es nach diesen Befehlen nicht funktioniert, kann ich euch nur wärmstens empfehlen, sich dort mal alles durchzulesen. Auch für die Leute, die die Hintergründe für die Befehle wissen wollen, ist der Blogbeitrag sehr zu empfehlen.
Ich hoffe, ich konnte etwas helfen.
Grüße, Max :)