HM-SEC-SD & HM-SEC-SD-2 zusammenbringen

Begonnen von Wondermusic, 12 November 2018, 09:36:50

Vorheriges Thema - Nächstes Thema

Wondermusic

Hallo zusammen,

aufgrund eines kleinen Vorfalls bei mir zu Hause musste ich leider feststellen, dass eine Alarmierung wie ich es mir mal vorgestellt habe nicht erfolgt ist...
Zum Hergang... Am Samstag ist bei mir ein Brand ausgebrochen, der aber glücklicherweise noch glimpflich ausgegangen ist. Ich habe, wie man meiner Sig entnehmen kann, insgesamt 3 alte und 4 neue Rauchmelder. Vier davon befinden sich in meinem Wohnbereich und 3 in der Anliegerwohnung.

Aufgrund eines techn. Defektes ist, hinter meinem Kamin in der Wand, ein Feuer entstanden (Fertighaus -> Holz und Rigipswände). Die Rauchentwicklung hat, wie es sein soll, einen Rauchmelder ausgelöst und alle anderen im Team haben ebenfalls Alarm geschlagen.
Leider ist mir jetzt im Nachhinein aufgefallen, dass die 3 alten den Alarm nicht entgegen genommen haben, da sich diese nicht mehr im Team befinden. Dies ist mir bis gestern nicht aufgefallen da in der PeerList alle aufgelistet sind (neue und alte). Tatsächlich ist es aber so, dass einer der Melder in der Anliegerwohnung nun als TeamLead eingetragen ist und die anderen beiden an diesem "angemeldet" sind.

Wie ich nun eben dem WIKI entnommen habe, können nicht beide Meldertypen im gleichen Team sein, was ich leider sehr unglücklich finde zumal der Eintrag anscheinend erst nach meiner Installation dort hinzugefügt wurde (ich weiß das der WIKI- Ersteller da nichts zu kann...  ;) Das soll auch kein Vorwurf sein!).

Nun aber zu meiner Frage...
Wie kann ich es schaffen zwei unterschiedliche Typen unter einen Hut zu bringen? Ein zweites virtuelles Team erstellen und per notify "untereinander verbinden"? Also TeamVirtuel_1 (Neue Melder) soll Alarm schlagen wenn TeamVirtuel_2 (alte Melder) eine Rauchentwicklung meldet und umgekehrt?
Hat schon jemand ähnliche Erfahrungen oder Programierungen eingerichtet und eventuell Probleme damit?

Gruß,
Richy
RPi 3B+ FHEM-Server mit HM-MOD-RPI-PCB
RPi2 mit HM-MOD-RPI-PCB
HM-CFG-LAN
RPi 4 mit ioBroker
>100 HM Sensoren & Aktoren, div. ESP8266 via mqtt, ems-esp

frank

wenn ich mich richtig erinnere, hat jemand mal berichtet, dass er alle rm, beide modelle, mit einem virt teamlead gepeert hat.

ich würde das jedenfalls mal probieren und dann mit testspray überprüfen.
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

Wondermusic

Hallo Frank,

hmm, erstmal Danke für den Hinweis!  :)
Ich habe die drei alten jetzt mal vom sdLead getrennt und dem virtuelen TeamLead hinzugefügt. Laut peerList beim Virtuellen Lead und einzelner Rauchmelder sind sie nun alle mit dem Virtuellen Leader gepeert.

TeamCall funktioniert laut Reading. Muss ich nachher mal testen ob die alle Anspringen wenn ich ein alarmOn sende (oder meine Frau pustet mal Zigarettenrauch da rein  ;D).
Wenn es geht, sollte der Eintrag im WIKI dann vielleicht wieder geändert werden...? Die Aussage wäre dann ein wenig irreführend. Oder entsprechend klarer definieren, falls die Aussage bedeuten soll dass dies nicht zutrifft, wenn man einen Virtuellen Teamleader einrichtet.

Ich verstehe nur nicht warum die drei alten nicht mehr im Team waren, obwohl ich diese nie per Befehl entfernt habe. Ich habe ja nach Neuanschaffung nur die neuen dem Team hinzugefügt...

Gruß,
Richy
RPi 3B+ FHEM-Server mit HM-MOD-RPI-PCB
RPi2 mit HM-MOD-RPI-PCB
HM-CFG-LAN
RPi 4 mit ioBroker
>100 HM Sensoren & Aktoren, div. ESP8266 via mqtt, ems-esp

frank

ZitatTatsächlich ist es aber so, dass einer der Melder in der Anliegerwohnung nun als TeamLead eingetragen ist und die anderen beiden an diesem "angemeldet" sind.
das hört sich an, als wären alle sauber mit einem der gruppe gepeert. da das peering jeweils im rm gespeichert ist, kann es eigentlich nicht aus "versehen" umgepeert worden sein.

eventuell waren sie bereits so gepeert und danach hast du dann erst versucht sie mit dem virt teamlead zu peeren? das wäre für mich eine erklärung dafür, dass die 3 zumindestens im virt teamlead eingetragen waren.
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

Wondermusic

Das ist es ja warum ich es nicht nachvollziehen kann.
Ich habe mich schon bei der ersten Einrichtung der alten Melder stringent an das WIKI, in Verbindung mit dem Virtuellen TeamLead, gehalten...
Und es hat ja auch alles über den Virtuellen funktioniert, inklusive Benachrichtigung (über ein notify - damals noch per Mail) beim testen.

Leider habe ich dann beim einbinden der neuen nicht nachgesehen ob sich was bei den alten verändert hat...  :-\
Nun ja, ist ja alles noch einigermaßen gut gegangen.
RPi 3B+ FHEM-Server mit HM-MOD-RPI-PCB
RPi2 mit HM-MOD-RPI-PCB
HM-CFG-LAN
RPi 4 mit ioBroker
>100 HM Sensoren & Aktoren, div. ESP8266 via mqtt, ems-esp

Otto123

Der erwähnte Link im Wiki  ist nicht frei erfunden sondern führt zu eq3, die Aussage dort ist lediglich ins Wiki übernommen.

Was immer damit genau seitens eq3 gemeint ist  ::)
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

ZitatLeider habe ich dann beim einbinden der neuen nicht nachgesehen ob sich was bei den alten verändert hat...  :-\
Nun ja, ist ja alles noch einigermaßen gut gegangen.
"get hminfo configCheck" hätte es sofort gezeigt.
vielleicht hin und wieder mal checken. natürlich besonders nach einfügen neuer devices.

das "umpeeren" bleibt ein rätsel.
oder hast du mal mit ccu/pivccu/eq3-sw gespielt?
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

Wondermusic

Zitat von: frank am 12 November 2018, 15:00:54
das "umpeeren" bleibt ein rätsel.
oder hast du mal mit ccu/pivccu/eq3-sw gespielt?

Ich habe irgendwann zwischen dem einfügen der alten und neuen Melder auf VCCU umgestellt, da ich mir einen Pi mit HM-MOD-RPI-PCB dazugeholt habe...
Meinst Du da ist irgendwas schief gelaufen?

Jedenfalls bringt bei mir das get HM configCheck eine ganze Menge Fehler. Ist aber hier das erste mal das ich davon was lese - so oft bin ich hier aber auch nicht unterwegs, denn wenn mal was läuft, dann läufts, also Danke für den Hinweis auf diese Möglichkeit der Fehlersuche...
Never change a running system. Denn trotz der ganzen anderen Fehler kann ich keine Einschränkung feststellen. Die Sicherheitsrelevanten Teile sind jedenfalls nicht in der Liste mit drin (oder sagen wir besser - nicht mehr).

Aber da habe ich ja dann was für die kalten Winterabende... Kann also sein das ich mich demnächst öfter mal mit blöden Fragen zu Wort melde - falls nicht schon jemand anders ein ähnliches Problem hatte. ;)

Gruß,
Richy
RPi 3B+ FHEM-Server mit HM-MOD-RPI-PCB
RPi2 mit HM-MOD-RPI-PCB
HM-CFG-LAN
RPi 4 mit ioBroker
>100 HM Sensoren & Aktoren, div. ESP8266 via mqtt, ems-esp

frank

ZitatIch habe irgendwann zwischen dem einfügen der alten und neuen Melder auf VCCU umgestellt, da ich mir einen Pi mit HM-MOD-RPI-PCB dazugeholt habe...
Meinst Du da ist irgendwas schief gelaufen?
wenn du die vccu von fhem/cul_hm meinst, dann nein.
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

Wondermusic

Sooo, jetzt habe ich es endlich mal geschafft die Rauchmelder life zu testen (mit Zigarettenrauch natürlich...).
Leider sieht es so aus, dass die alten SD's nicht mit anspringen, obwohl sich alle in einem virtuellen Team Lead befinden.
Es geht auch laut log eine Meldung an die alten Melder, aber leider erzeugen diese kein Warnsignal, wo hingegen die SD2's alle anspringen und Lärm machen.

Diese Einschränkung das alte nicht mit neuen funktionieren scheint wohl doch richtig zu sein - auch wenn alle nur an einem virtuellen Teamleader hängen.

Von daher ist die alte Fragestellung wohl doch wieder aktuell. Wie bekomme ich eine Gegenseitige Alarmierung zweier virtueller Teams hin? notify? doif? Was könnte wirkllich fehlerfrei funktionieren?

Für Anregungen und Hilfe wär eich sehr dankbar. :)

Gruß,
Richy
RPi 3B+ FHEM-Server mit HM-MOD-RPI-PCB
RPi2 mit HM-MOD-RPI-PCB
HM-CFG-LAN
RPi 4 mit ioBroker
>100 HM Sensoren & Aktoren, div. ESP8266 via mqtt, ems-esp

frank

ich habe gerade noch mal gesucht. nach diesem thread sollte es eigentlich doch funktionieren. das klingt jedenfalls ziehmlich seriös. https://forum.fhem.de/index.php/topic,90927.0.html

voraussetzung ist natürlich, dass der melder, der den rauch erkennt, funktechnisch alle anderen rm mit seiner alarmmessage direkt erreichen kann. nur die rm, die diese message hören, heulen mit. bei den sd2 könnte man wohl einen der gruppe als repeater konfigurieren.

hast du den test mt jedem melder ausgeführt, oder war der getestete zufällig zu weit von den sd entfernt?
was sagt hminfo configCheck?
was passiert bei alarm/test ausgelöst am fhem teamlead?

sicherlich könntest du zb mit 2 teams plus notify eine verbindung erreichen. aber erstens würde ich fhem aussen vor lassen wegen sicherheit und zweitens soll eine alarmierung der sd2 über den teamlead keine laute alarmierung erzeugen.

meine sd1 haben zusätzlich einen alarmeingang für die vernetzung mit kabel, um zb reichweitenprobleme zu lösen.

ich würde versuchen mit kabel und/oder repeateroption beim sd2 ein funktionierendes rm netz zu installieren.
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

Wondermusic

Zitat von: frank am 27 November 2018, 10:35:45
hast du den test mt jedem melder ausgeführt, oder war der getestete zufällig zu weit von den sd entfernt?
Ich habe zum testen nur den Rauchmelder im Eingangsbereich bei mir (SD2) verwendet. Dieser befindet sich schräg über dem anderen (SD) der Anliegerwohung. Also ein Reichweitenproblem dürfte das nicht sein (ca. 3 - 3,5m).

Zitat
was sagt hminfo configCheck?
was passiert bei alarm/test ausgelöst am fhem teamlead?
Die Log- Dateien des Teamlead, als auch aller SD's zeigen eine Alarmierung an, aber dennoch höre ich aus der Anliegerwohnung nix wenn ich oben aktiviere. Akkustisch reagiern nur die SD-2. Anders herum habe ich es nicht testen können.

Log Rauchmelder Flur oben (SD-2):
2018-11-26_15:24:40 og_eb_Flur smoke_detect: og_eb_Flur
2018-11-26_15:24:40 og_eb_Flur smoke-Alarm_01
2018-11-26_15:24:40 og_eb_Flur trigLast: Rauchmelder_Team:198
2018-11-26_15:24:40 og_eb_Flur trig_Rauchmelder_Team: 198_1
2018-11-26_15:24:54 og_eb_Flur smoke_detect: none
2018-11-26_15:24:54 og_eb_Flur off
2018-11-26_15:24:54 og_eb_Flur trigLast: Rauchmelder_Team:0
2018-11-26_15:24:54 og_eb_Flur trig_Rauchmelder_Team: 0_2


Log Rauchmelder Flur unten (SD):

2018-11-26_15:24:40 ug_flged_rauchmelder smoke_detect: og_eb_Flur
2018-11-26_15:24:40 ug_flged_rauchmelder smoke-Alarm_01
2018-11-26_15:24:54 ug_flged_rauchmelder smoke_detect: none
2018-11-26_15:24:54 ug_flged_rauchmelder off


Log TeamLead:

2018-11-26_15:24:40 Rauchmelder_Team eventNo: 01
2018-11-26_15:24:40 Rauchmelder_Team level: 198
2018-11-26_15:24:40 Rauchmelder_Team smoke_detect: og_eb_Flur
2018-11-26_15:24:40 Rauchmelder_Team smoke-Alarm_01
2018-11-26_15:24:40 Rauchmelder_Team trigger_cnt: 1
2018-11-26_15:24:54 Rauchmelder_Team eventNo: 02
2018-11-26_15:24:54 Rauchmelder_Team level: 0
2018-11-26_15:24:54 Rauchmelder_Team smoke_detect: none
2018-11-26_15:24:54 Rauchmelder_Team off
2018-11-26_15:24:54 Rauchmelder_Team trigger_cnt: 2



Ein configCheck meldet mir "nur" Fehler über meine KeyMatic, Garagentor und die zwei Funkfernbedienungen. Was nicht schlimm ist, da ich nur die Schaltzustände benötige und die KeyMatic eh nicht per fhem steuern möchte (ist aber ein Pairproblem das ich nicht gelöst bekomme - was aber wie gesagt nicht weiter schlimm ist).


configCheck done:

missing register list
    Schloss_Haustuere: RegL_00.,RegL_01.,RegL_03.HM_482AE9_unlock,RegL_03.HM_482AE9_lock,RegL_03.HM_4B8148_unlock,RegL_03.HM_4B8148_lock

peer not verified. Check that peer is set on both sides
    Schloss_Haustuere p:HM_482AE9_lock
    Schloss_Haustuere p:HM_482AE9_unlock
    Schloss_Haustuere p:HM_4B8148_lock
    Schloss_Haustuere p:HM_4B8148_unlock

PairedTo missing/unknown
    Schloss_Haustuere

PairedTo mismatch to IODev
    Schluessel_Richy paired:0x000000 IO attr: xxxxxx.
    Schluessel_Sylvi paired:0x000000 IO attr: xxxxxx.


Zitat
sicherlich könntest du zb mit 2 teams plus notify eine verbindung erreichen. aber erstens würde ich fhem aussen vor lassen wegen sicherheit und zweitens soll eine alarmierung der sd2 über den teamlead keine laute alarmierung erzeugen.
Ich habe zwischenzeitlich den anderen Threat gefunden wo jmike eine derartige Lösung genannt hat. Habe auch schon auf seine PN eine Antwort erhalten - Danke nochmal! :)
Werde hier über zwei notify's gehen und Abstand vom doif nehmen.

Zitat
meine sd1 haben zusätzlich einen alarmeingang für die vernetzung mit kabel, um zb reichweitenprobleme zu lösen.
ich würde versuchen mit kabel und/oder repeateroption beim sd2 ein funktionierendes rm netz zu installieren.
Was die Repeaterfunktion angeht dürfte das doch laut WIKI nicht gehen... Oder ist das in dem Fall egal?
Kabel legen ist leider keine Option.  :(

Gruß,
Richy
RPi 3B+ FHEM-Server mit HM-MOD-RPI-PCB
RPi2 mit HM-MOD-RPI-PCB
HM-CFG-LAN
RPi 4 mit ioBroker
>100 HM Sensoren & Aktoren, div. ESP8266 via mqtt, ems-esp

frank

du hast laut log einen trigger 198 ausgelöst.
war das ein testalarm durch drücken eines tasters am rauchmelder? ein echter alarm müsste meiner meinung nach einen trigger 200 auslösen.

eventuell heulen die sd1 nur mit, wenn ein echter alarm registriert wird.
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