HM-SEC-SD Rauchmelder: Pairing-, Konfigurations- und Kommunikationsprobleme

Begonnen von FHEMbaer, 18 Mai 2021, 09:48:34

Vorheriges Thema - Nächstes Thema

Otto123

Zitat von: frank am 19 Mai 2021, 11:03:16
in der vccu existiert zb ein eigener key,
Das erhöht die Komplexität und mindert die Erfolgschancen erstmal ins unermessliche :)
Eigentlich kann der RM3 Deinen eigenen Key nicht bekommen solange er nicht gepairt ist.
Woher sollte der jetzt einen völlig eigenen Key haben? (also er hat normalerweise den eq3 Systemkey)
Kann man meiner Meinung nur sicher herausfinden in dem man Werkreset versucht. Ist das erfolgreich, hat er keinen. Wird das mit rot quittiert hat man entweder einen Fehler gemacht oder er hat einen eigenen Key. Wenn das so ist und Du hast ihn nicht sieht es ziemlich schlecht aus.

Der RM1 hat aber auch keinen anderen key, bei dem ist pairing und Kommunikation ok?!

Achtung! Handbuch für den Werkreset genau lesen - das wird oft falsch verstanden und damit falsch gemacht.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

FHEMbaer

Das Pairing zwischen den Rauchmeldern könnte entstanden sein als ich in einer der zahlreichen Runden des Re-Pairings beide zeitgleich in diesem Mode hatte :'(

Den einschränkenden Bemerkungen entnehme ich das ein Werksreset kein wirklicher Werksreset ist sondern ein mehr oder weniger definierter Zwischenzustand entsteht und das damit dann der Rauchmelder nur noch als Stand-Alone-Gerät taugt?

Ich habe noch einen HM-CFG-USB, allerdings vermutlich Version 1 (den mit der Gummiantenne). Ließe sich dieser prinzipiell an einem Raspi nutzen und unter FHEM einbinden?

Otto123

1. klingt wahrscheinlich

2. Nein ein Werksreset ist ein Werksreset Alles wird gelöscht, Register, die Peers und das pairing. Das Gerät ist danach im Auslieferungszustand. Damit ist es selbstverständlich als Stand-Alone-Gerät tauglich. Das ist bei Homematic immer so.

3. Klar sollte der gehen, ich wüsste nicht warum nicht. Allerdings kann ich Dich da nicht unterstützen, habe ich nie gemacht. Steht aber hoffentlich alles im Wiki!

Aber besorg Dir doch das Aufsteckmodul solange es das noch gibt. 20€ ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

FHEMbaer

Zitat von: Otto123 am 19 Mai 2021, 14:05:59
Nein ein Werksreset ist ein Werksreset Alles wird gelöscht, Register, die Peers und das pairing. Das Gerät ist danach im Auslieferungszustand. Damit ist es selbstverständlich als Stand-Alone-Gerät tauglich. Das ist bei Homematic immer so.
Damit wäre doch mit einem Werksreset ein Neustart möglich, soll heißen VCCU, Team Device & Lead sind jetzt glatt gezogen. Wenn ich das Funkproblem löse, dann könnte ich doch die vier Melder zurücksetzen und neu beginnen. Oder ist die Hoffnung das nach Behebung des Funkproblems auch die Devices mehr oder minder problemlos funktionieren werden?

Zitat
Klar sollte der gehen, ich wüsste nicht warum nicht. Allerdings kann ich Dich da nicht unterstützen, habe ich nie gemacht. Steht aber hoffentlich alles im Wiki!
Ich werde mich 'mal einlesen und schauen...

Zitat
Aber besorg Dir doch das Aufsteckmodul solange es das noch gibt. 20€ ;)
Ist damit https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi gemeint? Sind die bei elv im Abverkauf?

frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

FHEMbaer

Zitat von: frank am 19 Mai 2021, 16:43:28
warum nicht erstmal damit, um voran zu kommen?
zu einfach?

Nein, ich habe den Thread noch nicht durchgearbeitet und deshalb noch verstanden worum es geht. Die Nutzung dieses Moduls statt des Standardmoduls ist warum angezeigt? Wenn Kommunikationsproblem im CUL selbst liegt, was hilft dann das Einbindungsmodul? Gibt es in dem referenzierten Thread einen entsprechenden Einsprung damit ich den Kontext erschließen kann?

frank

du musst nicht den thread lesen und verstehen.
nur das modul tauschen, weil ein cul damit grundsätzlich an vielen stellen besser kommuniziert.
anschliessend natürlich fhem restart.

bis der alte hmusb bei dir läuft, falls er überhaupt läuft und falls er auch tripple burst für die sd2 kann, könnte weihnachten werden.  ;)

um mal up-to-date zu sein, besorg dir den hmuart, falls es mit deinem cul so nichts wird.

wenn du dann immer noch zeit und lust hast, kannst du den alten hmusb immer noch zusätzlich in dein system als backup io integrieren.

aber selbst mit zeit und lust, würde ich vorher den cul dann noch auf tsculfw aufrüsten.

my 2 cent
gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

FHEMbaer

Zitat von: frank am 19 Mai 2021, 17:37:20
...nur das modul tauschen, ...
Das heißt einfach das vorhandene Perl-Modul durch das aus dem Thread austauschen, oder sind noch weitere Konfigurationen/Abhängigkeiten vor einem Neustart zu beachten?

Zitat
bis der alte hmusb bei dir läuft, falls er überhaupt läuft und falls er auch tripple burst für die sd2 kann, könnte weihnachten werden.  ;)
O.k. das hört sich wirklich danach an es erst anzugehen wenn mir wirklich gaaaaanz langweilig sein sollte ;)

Zitat
um mal up-to-date zu sein, besorg dir den hmuart, falls es mit deinem cul so nichts wird.
Passt zwar nicht ins Gehäuse, ist aber schon 'mal bestellt. Ich hoffe statt des Drahtstummels kann ich auch ein Pigtail verlöten um eine richtige Antenne anzubringen...

Zitat
aber selbst mit zeit und lust, würde ich vorher den cul dann noch auf tsculfw aufrüsten.
Das hört sich nach Plan C an – Plan A ist jetzt erst einmal das CUL-Einbindungsmodul zu tauschen, dann als Schritt B hmUART als primäres IO-Modul einzubinden.

frank

die nachfrage lässt meine glocken läuten: vorsicht!

am besten:
1. alte datei umbenennen, nicht löschen, zb 00_CUL.pm_alt.
2. neue datei in den ordner kopieren.
3. die rechte von alt und neu vergleichen und ggf angleichen.

auf linux zb über "ls -al" die rechte anschauen und vergleichen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Otto123

Ja, das Modul in Deinem Link. Abverkauf wüsste ich nicht, die kosten immer so. Aber elv wird den Verkauf von altem Homematic (nicht IP) Zeugs irgendwann einstellen.

ZitatPasst zwar nicht ins Gehäuse,
Hängt davon ab :) man kann ihn anders zusammenlöten
Man kann ihn aber auch per USB anschließen!
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

Zitat von: Otto123 am 19 Mai 2021, 18:19:44
man kann ihn anders zusammenlöten

das wiki hat aber eine irreführende beschreibung, finde ich:
ZitatMan kann ohne weiteres das UART-Modul unter dem PCB-Modul montieren (Bild links, das Modul muss entsprechend gedreht werden), damit wird die Gesamthöhe geringer und es passt problemlos in jedes Gehäuse. Es kann sein, dass jetzt aber Kühlkörper oder ähnliches seitens der Pi-Platine stören.

es darf eben nicht gedreht werden. das zeigen die bilder auch sehr schön.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Otto123

Danke für den Hinweis, weiß nicht wie diese Satzfolge entstanden ist. Habe das mit dem Drehen einfach gestrichen und noch was ergänzt. ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

FHEMbaer

Trotz neuem CUL-Modul und zeitlicher Gelassenheit bin ich keinen wirklichen Schritt weiter. Alle 4 Rauchmelder melden protState
CMDs_pending, commState CMDs_done_Errors:1
und state IOerr. Das getConfig liegt mittlerweile 24h zurück...

Ich schwanke jetzt zwischen flashen einer anderen FirmWare auf den nanoCUL und den Zusammenbau eines USB-basierten Moduls mit dem elv Modul. Wenn ich Ansatz zwei wähle, wäre es dann nicht besser die Rauchmelder in den Werkszustand zurückzusetzen und von vorne zu beginnen?

frank

mach mal ein werkreset beim rm3 wie in deer bedienungsanleitung beschrieben.
setze im device von rm3 attr autoreadreg=5_missing.
dann setze im cul verbose=4.

jetzt paire den rm3 und poste den ausschnitt aus fhem.log.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html