FHEM Forum

FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: martinp876 am 21 März 2015, 17:28:26

Titel: HM-SEC-SD-2 neu
Beitrag von: martinp876 am 21 März 2015, 17:28:26
Es gibt oder wird geben einen neuen SD. hier scheint es ein paar inovationen zu geben.
er hat einen trpple-burst mode(kein Burst mehr). Vermutung ist, dass man 3 bursts senden muss um ihn zu erwecken. Das würde sicher stellen, dass er bei einem einfachen burst nicht aufwacht und somit Batterie spart, wenn mit einfachburst devices kommuniziert wird.
=> der mode ist unklar - wenn jemand ein Device hat können wir versuchen es zum Laufen zu bringen.

ob man sie mit normalen SDs peeren kann ist somit auch nicht klar. diese senden einfachburst - aber 3 messages. Nun ja, vielleicht ist das auch mit tripple gemeint.

das Device liefert nebenbei 2 neue Zustände: teamAlarm-probleme und einen Zustand der Rauchkammer. genaueres weiss ich nicht
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: xsasx am 19 Mai 2015, 10:13:33
Bin grad auf der Suche nach Rauchmeldern nur erschreckt mich die Info im Netz der Fehlalarme. Wann kommen die V2 denn ?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 19 Mai 2015, 10:23:28
Ausser dem Vermerk in der CCU2 Software ist soweit nichts über v2 bekannt.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: hoscho am 28 Mai 2015, 11:23:09
Der Rauchmelder HM-Sec-SD-2 wird voraussichtlich im Herbst 2015 verfügbar sein. Der neue Rauchmelder wird gespeist über eine 10 Jahres Batterie. Er verfügt ferner über eine große Testtaste sowie ein Fliegenschutzgitter (siehe: www.elv.de/topic/ausloesenden-rauchmelder-einer-gruppe-identifizieren.html).
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 01 Juni 2015, 10:41:35
Der Rauchmelder HM-Sec-SD-2 wird voraussichtlich im Herbst 2015 verfügbar sein. Der neue Rauchmelder wird gespeist über eine 10 Jahres Batterie. Er verfügt ferner über eine große Testtaste sowie ein Fliegenschutzgitter (siehe: www.elv.de/topic/ausloesenden-rauchmelder-einer-gruppe-identifizieren.html).

Ah, das hört sich ja eigentlich sehr interessant an, danke. Denke mal ich werde die ausprobieren, auch wenn es irgendwie recht gefährlich ist Early Adopter bei eq3 zu sein ;)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: ritchie am 23 Juli 2015, 18:42:32
Hallo Zusammen,

ich werde auch auf die Rauchmelder warten.

was bedeutet eigenlich
Zitat
Denke mal ich werde die ausprobieren, auch wenn es irgendwie recht gefährlich ist Early Adopter bei eq3 zu sein

Schlechte Erfahrungen gemacht ?  Da ich gleich 13 Stück brauche, wäre sowas nicht wirklich schön, wenn ich abends geweckt werde.

Viele Grüße
R.


Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 18 November 2015, 10:11:52
Hi zusammen,

auch wenn der Thread schon älter ist, der HM-SEC-SD-2 wird wohl bald kommen.
Habe folgendes durch Zufall entdeckt
http://www.eq-3.de/Downloads/Software/HM-CCU2-Firmware_Updates/HM-CCU2-2.15.5/changelog.txt (http://www.eq-3.de/Downloads/Software/HM-CCU2-Firmware_Updates/HM-CCU2-2.15.5/changelog.txt)
2.13.7
- Erweiterungen / Verbesserungen
  [HMCCU2-537]  Einem eingebundenen LAN-Gateway kann nun ein Name zugeordnet werden.
  [HMCCU2-591]  Vergleichszeitraum für Diagramme hinzugefügt.
  [HMCCU2-642]  Einbindung eines LAN-Gateways vereinfacht.
  [HMCCU2-687]  2-fach Funksender (HM-RC-2-PBU-FM) hinzugefügt.
  [HMCCU2-688]  Display-Fernbedienung (HM-RC-Dis-H-x-EU) hinzugefügt.
  [HMCCU2-690]  Darstellung des realen Dimm-Levels bei Dimmern mit virtuellen Kanälen (im Expertenmodus).
  [b][HMCCU2-692]  HM-Sec-SD-2 (Rauchmelder) hinzugefügt.[/b]
  [HMCCU2-695]  HM-LC-Sw1-DR (Treppenhausautomat) hinzugefügt.

und das ist nicht die letzte Version, die letzte ist 2.15.5.

Kann daraus jemand evtl. eine Info ableiten, oder hat jemand den HM-SEC-SD-2 schon irgendwo zum kauf gesehen?


LG Christian
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: xsasx am 09 Dezember 2015, 10:21:22
Würd mich auch interessieren- gibts den nun schon ?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: no_Legend am 09 Dezember 2015, 10:24:14
Mich würde auch freuen wenn der Rauchmelder nicht nur Optisch Arbeiten würde.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: ChrisW am 10 Dezember 2015, 16:23:34
Scheint noch immer nicht im Shop zu sein ???...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Morgennebel am 09 Februar 2016, 18:34:04
Guten Abend,


soeben kam die Nachricht, daß die neuen Modelle ab heute auf ehomeportal vorbestellbar seien. Lieferbar ab Q2/2016.

Es wird auch darauf hingewiesen, daß sich nur Modell gleicher Bauart als Gruppe definieren lassen.

Ciao, -MN
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 10 Februar 2016, 10:21:33
Interessante Info, allerdings finde ich die Teile nirgendwo auf der Seite.

Gruß Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Morgennebel am 10 Februar 2016, 14:58:05
Hi Marcel,


das kam im RSS-Feed von ehomeportal auf dem Handy. Webseiten schaue ich so selten an...

Ciao, -MN
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Thomas X am 14 Februar 2016, 09:13:47
Guten Abend,

soeben kam die Nachricht, daß die neuen Modelle ab heute auf ehomeportal vorbestellbar seien. Lieferbar ab Q2/2016.
Es wird auch darauf hingewiesen, daß sich nur Modell gleicher Bauart als Gruppe definieren lassen.

Ciao, -MN

Hm. Aber im FHEM müsste man die doch über einen virtuellen Teamlead verbinden können, oder? Ich habe natürlich jetzt den ersten HM-SEC-SD gakauft. Mehr noch nicht, da ich erstmal die Fehlalarme abwarten wollte. Aber seit 3 Wochen im Einatz und alles ruhig. Nur will ich dann jetzt nicht das "alte" Modell kaufen.

Zumal der "neue" m.E. besser aussieht.  ;)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 14 Februar 2016, 18:38:46
Zumal der "neue" m.E. besser aussieht.  ;)
so viel zum Thema Geschmack...

Dient die fest eingebaute Batterie lediglich dem Rauchsensor oder wird diese auch für den Funkverkehr genutzt? Im Datenblatt wird ja nur von den fest verbauten Li-Batterien gesprochen. Mein Kaufantrieb wäre in erster Linie der Insektenschutz.

Gruß!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: no_Legend am 15 Februar 2016, 09:00:12
Wenn das Bild hier stimmt, sind die Neuen Rachmelder aber ziemlich hässlich:
http://www.ehomeportal.de/HomeMatic-System/Sensoren/HomeMatic-Funk-Rauchwarnmelder-HM-Sec-SD-2-VDS-3er-SET-Q-Zertif-NEU-.htm?shop=shop&SessionId=&a=article&ProdNr=eQ131408A2&t=1598&c=2020&p=2020
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 15 Februar 2016, 11:45:42
Hallo no_Legend
Grundsaetzlich gebe ich Dir recht. Aber wieviele schoene Rauchmelder gibt es denn? Und ganz haesslich sind Sie ja nicht, da gibt es schlimmere! Und mit VDS und Q Zertifikat als Funk fuer €50,- bzw. 3 fuer €140,- (ELV) gibt es auch eher wenige! Schon gar nicht wenn man Sie dann auch noch in FHEM einbinden will!
Gruss Christoph
P.S.: Ich habe schoene, Gira Dual! Leider ohne Funkmodule, da die ja nicht mit FHEm funktionieren!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: no_Legend am 15 Februar 2016, 11:55:44
Hallo no_Legend
Grundsaetzlich gebe ich Dir recht. Aber wieviele schoene Rauchmelder gibt es denn? Und ganz haesslich sind Sie ja nicht, da gibt es schlimmere! Und mit VDS und Q Zertifikat als Funk fuer €50,- bzw. 3 fuer €140,- (ELV) gibt es auch eher wenige! Schon gar nicht wenn man Sie dann auch noch in FHEM einbinden will!
Gruss Christoph
P.S.: Ich habe schoene, Gira Dual! Leider ohne Funkmodule, da die ja nicht mit FHEm funktionieren!

Da hast du auch wieder recht.

Haben die Gira nicht auch einen Alarm ausgang?

Was ich bisher leider nicht gefunden habe sind Decken Einbau Rauchmelder.
Also von der Bauweise her wie ein 12V spot oder so.

Gruß Robert
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 15 Februar 2016, 12:10:52
Hallo Robert
Die Gira haben einen Alarmausgang, aber der hilft mir ja nichts da kein Kabel da! >:(
Und bei den Eingelassenen wird man wohl keine Zulassung bekommen, die sitzen dann ja nicht so wirklich im Rauch!?
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 15 Februar 2016, 12:27:04
Zitat
Die Gira haben einen Alarmausgang, aber der hilft mir ja nichts da kein Kabel da!
den kontakt kannst du doch sicherlich auswerten. irgend ein interface-device?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: no_Legend am 15 Februar 2016, 12:56:41
den kontakt kannst du doch sicherlich auswerten. irgend ein interface-device?

Wenn du einfach einen schaltkontakt abfragen kannst gibt es ja genug Homematic devices.
Ansonten könnte man auch per Reverse Engieering probieren das 433Mhz funk Modul per CUL direkt anzubinden.
Da bin ich aber kein Experte Drin. Gibt es auch schon threads für. Mal die Board suche nehmen.
http://forum.fhem.de/index.php?topic=19065.0
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 15 Februar 2016, 13:11:59
Hallo Frank
Die Gira's haben einen festen Kontakt eingebaut, dafuer brauche ich ein Kabel, da in dem RM wenig Platz ist. Alternativ koennte ich das Funkmodul von Gira einsetzen, das leider nicht wirklich guenstig ist, und bei ca. 7 RM ist mir das zu heftig! Da kaufe ich dann lieber neue, die ich dann auch mit FHEM nutzen kann, als Alarmmelder, und Gira geht ja nicht mit FHEM!
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 15 Februar 2016, 13:24:41
Hallo robert
Du hast mich ja ganz heiss gemacht. Leider sehe ich das so, dass die RM's nicht INSTA Funk machen, also geht es so nicht! Es gab schon zich Fragen und Ansaetze, nur leider ist nicht wirklich etwas verwertbares dabei rausgekommen.
Aber nun genug OT, es geht ja hier um etwas voellig anderes!
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 15 Februar 2016, 16:53:30
Also auf ELV.de ist er jetzt auch aufgetaucht. Optisch ist er okay, sicherlich nicht schlimmer als die alten. Interessant finde ich:

- Er arbeitet als Repeater für die anderen Rauchmelder. Zumindest mein Verständnis vom alten Modell war dass alle im Team sich haben "sehen" müssen, insofern wäre das ein großes Plus.
- Der auslösende Melder kann explizit und ohne Trickserei bestimmt werden
- Verbesserter Insekten-Schutz. Gibt ja die Vermutung dass das ein Großteil der Fehlalarme verursacht hat.

Mal sehen wie leicht er sich in FHEM mit den diversen Adaptern integrieren lässt. Gab ja die Spekulation dass er eine neue Art von (bzw längeren) Burst benutzt um nicht bei jedem normalen Burst mit aufwachen zu müssen und damit Batterie zu sparen. 10 Jahre Lebensdauer ist ja auch ne ordentliche Ansage. Aber wenn das passt werde ich wohl mal investieren müssen, das waren nämlich genau die Punkte die mich bisher gestört haben.

Gruß Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: no_Legend am 15 Februar 2016, 21:24:09

Also auf ELV.de ist er jetzt auch aufgetaucht. Optisch ist er okay, sicherlich nicht schlimmer als die alten. Interessant finde ich:

- Er arbeitet als Repeater für die anderen Rauchmelder. Zumindest mein Verständnis vom alten Modell war dass alle im Team sich haben "sehen" müssen, insofern wäre das ein großes Plus.
- Der auslösende Melder kann explizit und ohne Trickserei bestimmt werden
- Verbesserter Insekten-Schutz. Gibt ja die Vermutung dass das ein Großteil der Fehlalarme verursacht hat.

Mal sehen wie leicht er sich in FHEM mit den diversen Adaptern integrieren lässt. Gab ja die Spekulation dass er eine neue Art von (bzw längeren) Burst benutzt um nicht bei jedem normalen Burst mit aufwachen zu müssen und damit Batterie zu sparen. 10 Jahre Lebensdauer ist ja auch ne ordentliche Ansage. Aber wenn das passt werde ich wohl mal investieren müssen, das waren nämlich genau die Punkte die mich bisher gestört haben.

Gruß Marcel

Die alten lösen bei mir nach einander aus.
Mehrere sehen den oder anderen Rauchmelder nicht.

Tricksen muss ich nicht, zumindest sehe ich das nicht als tricksen an.
Die Anleitung ist glaub ich im Wiki.

Ich werde jetzt nicht auf die neuen umstellen.
Sehe dafür nicht wirklich einen Grund oder großen Vorteil.

Gruß Robert
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 15 Februar 2016, 23:57:47
Tricksen muss ich nicht, zumindest sehe ich das nicht als tricksen an.
Die Anleitung ist glaub ich im Wiki.
Ich hab nur gelesen dass es mit der CCU sehr umständlich ist, kann mir gut vorstellen dass es in FHEM besser gelöst ist.

Zitat
Ich werde jetzt nicht auf die neuen umstellen.
Sehe dafür nicht wirklich einen Grund oder großen Vorteil.
Nö, wenn die Dinger bei Dir so funktionieren wie sie sollen würde ich das auch nicht, wozu auch. Sie sind günstiger als viele andere Funk-Melder, aber trotzdem nicht gerade billig.

Gruß Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Joker am 20 März 2016, 13:55:37
Der Melder ist bei ELV ja jetzt bestellbar.

Was mich ein bisschen stutzig macht: Der hat ja eine nicht wechselbare (!) 10-Jahres Batterie, wie hier auch schon geschrieben wurde.

In der Anleitung steht ein ganzer Rattenschwanz an Bedingungen, die eingehalten werden müssen damit die Lebensdauer erreicht wird. ich habe mich mit der Thematik noch nicht weiter beschäftigt, aber machen andere Hersteller das auch? Wenn jetzt aus irgendwelchen Gründen die Batterie schon nach zwei Jahren schwach ist, kann ich das Ding wegwerfen??
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 22 März 2016, 12:44:22
Wenn jetzt aus irgendwelchen Gründen die Batterie schon nach zwei Jahren schwach ist, kann ich das Ding wegwerfen??

so wird es sein

Ich habe den HM-SEC-SD-2 heute in FHEM eingebunden, die Batterie Statusanzeige fehlt noch und der state steht leider dauerhaft auf "RESPONSE TIMEOUT:RegisterRead" -> muss man dazu dann bei jedem getConfig den Knopf in der Mitte drücken?

Gruß!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Garry am 22 März 2016, 13:00:29
Naja, so ein Gerät kann man schlecht auf 10Jahre Dauerbetrieb unter allen Umständen auslegen.
Der übliche Gebrauch - 10 Jahre Bereitschaft und ein Alarmfall wird sicher abgedeckt und geprüft sein.
Den Energiebedarf für einen täglichen Fehlalarm wird ehrer nicht abgedeckt werden - genausowenig wie das ständige
Kommunizieren, einschalten der Notbeleuchtung etc.
Massnahmen die ein Austausch der Batterie aktiv unterbinden sind denkbar, eventuell sogar durch die Normen gefordert zumal es ja eine Vorgabe gibt dass Rauchmelder nach 10Jahren ausgetauscht werden müssen.


Garry
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 22 März 2016, 13:56:25
Tatsächlich müssen die Rauchmelder natürlich ununterbrochen im Funk lauschen, sonst könnten sie ja nicht auslösen wenn ein Team-Nachbar auslöst. Allerdings wurde, so ist zumindest die gängige Vermutung, ein neue Art von Burst-Modus integriert damit sie nicht bei jedem Fenster öffnen mit aufwachen. Wie das physikalisch und logisch aussieht ist aber soweit ich weiss noch unbekannt, insofern ist es kein Wunder dass die FHEM Integration noch nicht komplett ist.

Gruss Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Joker am 22 März 2016, 16:17:47
Auszug aus der Anleitung:

Die Batterielebensdauer von typisch 10 Jahren kann nur unter
folgenden Bedingungen erreicht werden:
•Pro Jahr dürfen max. 52 Funktionstests durchgeführt werden und ein
Alarm für 60 Sekunden innerhalb der Gruppe auftreten.
•Während der gesamten Laufzeit dürfen eine Inbetriebnahme, zwei
Reichweitentests sowie ein einmaliges Anlernen an eine Gruppe
durchgeführt werden.
•Der Störanteil durch andere Funksender im 868 MHz-Bereich darf
nicht höher als 15 Sekunden am Tag sein.
•Die Betriebsumgebungstemperatur von +5° bis +30°C muss eingehalten werden

Alles bis auf den vorletzten Punkt sollte eigentlich immer gegeben sein. Was den vorletzten Punkt betrifft, das wird natürlich schwierig rauszufinden.
Mir wir gar nicht so recht bewußt dass Rauchmelder nach 10 Jahren ausgetauscht werden müssen. Wenn die Batterie auch wirklich an die 10 Jahre ran kommt, dann passt das ja.

Ich denke ich warte noch bis die FHEM-Integration vollständig ist. Passiert denn an der Stelle etwas?

Wir in Bayern haben ja noch bis 31.12.2017 Zeit mit der Nachrüstung  ;D
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 22 März 2016, 17:40:57
DIN   14676
6.5 Austausch des Rauchwarnmelders
Der Rauchwarnmelder ist spätestens 10 Jahre + 6 Monate nach dem Datum der Inbetriebnahme auszutauschen oder einer Werksprüfung mit Werksinstandhaltung zu unterziehen.
Ich schau mir die Dinger an wenn's soweit ist... eventuell reicht ja auch Reinigung + Lithium-Batterie Wechsel, wenn man ein passendes Modell auftreiben kann, zumindest im privat-Bereich. Wir sprechen uns in 10 Jahren wieder ;)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Prof. Dr. Peter Henning am 24 März 2016, 22:23:13
Zitat
Der Störanteil durch andere Funksender im 868 MHz-Bereich darf nicht höher als 15 Sekunden am Tag sein.


Nicht erfüllbar in einem voll ausgrüsteten SmartHome

Zitat
Die Betriebsumgebungstemperatur von +5° bis +30°C muss eingehalten werden

Nicht erfülbar im sonnigen Baden. Im letzten Sommer waren es auch im Innenraum über 30 °C

Meine Rauchmelder der 1. Generation mit Firmware 1.0 funktionieren tadellos.

Die VdS-Zertifizierung fällt als Geschäftstätigkeit in dieselbe Klasse wie Immobilienmakler und Telefondesinfzierer. 

LG

pah
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 24 März 2016, 22:33:57
Das mit den 10 Jahren wird sicherlich nicht hinhauen. Möglicherweise hätte man ja auch die 10-Jahres Batterie auf den Alarm bzw. die Bereitschaft beschränken und dann dem Funkverkehr ein separates Batteriefach spendieren können.

Gruß!

Nachtrag:

Mal 'ne Frage am Rande... gibt es ähnliche Geräte (FHEM freundlich) auch als Brandmelder mit Hitzefunktion? Ich bin gerade dabei die Küche zu renovieren und ein Austausch des alten Melders ist eh an der Zeit.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 24 März 2016, 22:50:49
Meine Rauchmelder der 1. Generation mit Firmware 1.0 funktionieren tadellos.

Im Grunde hast Du da recht, die erste Generation ist völlig ausreichend. Nur fehlt da das Metallgitter, welches kleine Insekten davon abhält gelegentlich Fehlalarme auszulösen. Ansonsten könnte ich auf die 10 Jahres Batterie auch verzichten und alle 2 Jahre mal höchst persönlich die Batterie austauschen.

Meiner Meinung nach beschränkt sich der Nutzen der Einbindung von Rauchmeldern in FHEM eh auf 3 wesentliche Punkte:
1. Man kann Fehlalarme protokollieren, die meist nachts stattfinden und bei denen man sich ohne Angabe des auslösenden Sensors "den Wolf" sucht.
2. Man kann erkennen ob so langsam aber sicher die Batterie getauscht werden muss -> Das verhindert dann unangenehme Signalmeldungen, die man meist auch erst nachts wahrnimmt und besonders gerne wenn man selbst auf Dienstreise ist und die Frau dann nachts wegen dieser Meldungen anruft.
3. Man bekommt auch bei Abwesenheit infos darüber ob und wann sich ein wütender Mob vor der Haustüre versammelt und meine Rauchmelder-Installation verflucht.

Zum Thema VdS hatte ich vor langer Zeit mal beim ZDF WISO folgendes gefunden:
Zitat
VdS übernimmt ab 31.03.2015 das Kriterium "10-Jahres-Batterie“ in ihren normalen Testzyklus. Rauchmelder mit geringerer Batterielaufzeit und ohne fest eingeschweißte Batterie erhalten dann kein VdS-Siegel mehr. Für VdS-Sprecher Scharr hat die eingeschweißte Batterie Vorteile: "Wir beobachten immer wieder, dass die Rauchmelder, wenn die Batterie nach einem Jahr oder so leer ist, von der Decke genommen werden und die Batterie dann nicht sofort erneuert wird. Das ist gefährlich. Genauso kommt es vor, dass die 9V-Blockbatterie genommen wird, wenn die Batterie in einer Fernbedienung leer ist“, so Scharr. Das verhindere die eingeschweißte Batterie. Nach zehn Jahren, wenn die Batterie leer ist, muss allerdings der komplette Melder entsorgt werden.

1. Die Batterie eines Rauchmelders sollte nicht schon nach einem Jahr leer sein. Zudem signalisiert der Rauchmelder über einen längeren Zeitraum periodisch eine schwache Batterie durch unangenehme Geräusche.
2. Bei wem passt eine 9 V Block Batterie in die Fernbedienung?
3. Wenn man schon die Batterie eines Rauchmelders für die Fernbedienung nutzt, wer tauscht dann in solchen Haushalten die Rauchmelder nach 10 Jahren aus... bzw. kontrolliert ob diese nicht bereits nach 9 Jahren die Funktion eingestellt haben?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 25 März 2016, 02:11:21

Zitat
Der Störanteil durch andere Funksender im 868 MHz-Bereich darf
nicht höher als 15 Sekunden am Tag sein.
Nicht erfüllbar in einem voll ausgrüsteten SmartHome
Ich glaube hiermit sind wirklich System-fremde Störungen gemeint, die der Empfänger Chip fälschlicherweise als (Triple-)Burst erkennen könnte und damit die CPU aufweckt. Normalen Funk-Verkehr auf 15 Sekunden am Tag zu limitieren wäre dann doch arg unrealistisch.

Besten Gruss, Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Prof. Dr. Peter Henning am 25 März 2016, 04:35:19
VdS: Eigentlich wäre hier mal eine EU-Beschwerde fällig, weil damit ganz klar ein Monopol errichtet wird, mit dem ausländische Unternehmen benachteiligt werden. Mal sehen, so etwas habe ich schon öfter gemacht. Die EU-Kommission hat eine ganze Abteilung, die dann richtig nette Prüfverfahren einleitet.

Störanteil: Langsam, ein Funkempfänger wid ja nicht aufgeweckt, weil er selektiv auf etwas bestimmtes "lauscht". Sondern er muss immer wach sein und die einlaufenden Signale auf irgendetwas überprüfen, was er weiter verarbeiten kann. Und weil eine einfache Drahtantenne nicht bis drei zählen kann, ist die CPU eben niemals ganz lahm gelegt. Die 15% beziehen sich also auf den gesamten Funkverkehr.

Rauchmelder: Zu kurz gedacht. Selbstverständlich kann man gerade die HM-Rauchmelder (weil von außen einschaltbar !) sehr wohl zur Alarmsignalisierung nutzen. Das habe ich in Ansätzen hier:
http://www.fhemwiki.de/wiki/Modul_Alarmanlage

und genauer hier

http://www.amazon.de/Smart-Home-Hacks-Hausautomatisierung-selber/dp/3960090129

beschrieben. Mit dem Modul "Alarm" geht das sehr komfortabel - und selbstverständlich auch so, dass das Ding nach kurzer Zeit wieder ausgeht. Im vergangenen Sommer hat es mal 30 Sekunden lang gepiept, weil bei einem Starkregen-Event Wasser in den Keller gelaufen ist. Sehr hilfreich bei kritischen Situationen - und natürlich braucht es eine Panikschaltung, die das auch sofort wieder stoppt. Bei mir eine ganze Gruppe von Lichtschaltern - Betätigung cancelt auch den Rauchmelder.

1. Generation: Noch nie einen Fehlalarm gehabt. Und der auslösende Melder signalisiert durch seine LED den Alarmzustand.

LG

pah
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 25 März 2016, 23:57:11
Störanteil: Langsam, ein Funkempfänger wid ja nicht aufgeweckt, weil er selektiv auf etwas bestimmtes "lauscht". Sondern er muss immer wach sein und die einlaufenden Signale auf irgendetwas überprüfen, was er weiter verarbeiten kann. Und weil eine einfache Drahtantenne nicht bis drei zählen kann, ist die CPU eben niemals ganz lahm gelegt. Die 15% beziehen sich also auf den gesamten Funkverkehr.
Die Antenne kann nicht bis 3 zählen, der CC1101 Chip aber schon, und nur der muss periodisch aufwachen (bei Homematic wohl 3 mal pro Sekunde) um zu checken ob was in der Luft liegt. Die MCU wird erst dann per Interrupt geweckt wenn's was spannendes zu erzählen gibt. SD-2 hat hier einen unbekannten "TRIPLE_BURST" noch dazu, was evtl nur bedeutet dass er eben nur einmal pro Sekunde aufwacht. Egal wie, die 15 Sekunden ergeben für mich weiterhin keinen Sinn. Man könnte schließlich auch 23 Stunden am Tag ohne Energie-Verlust störsenden wenn man nur zufällig die 45 Minuten, die der Chip wach ist, ausspart...

Gruß Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 26 März 2016, 08:16:58
So ganz verstehe ich die Diskussion nicht.
Empfangen ist eins. Wenn viele bursts kommen ist mehr zu tun. Wenn noch dazu der SD adressiert wird kostet es richtig Batterie. Unschön, lebensverkuerzend.
Senden ist ein anderes Thema. Hier müssen die 1% eingehalten werden. Aber senden muss er nicht so oft, wenns nicht dauernd brennt.
Wo entsteht jetzt eine Lücke?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Prof. Dr. Peter Henning am 26 März 2016, 12:06:48
Die Diskussion dreht sich um die konkrete Frage, ob nicht in einem voll ausgebauten SmartHome mit diversen Geräten im ISM-Band die 15% überschritten werden.
Ist insofern akademisch, als das nur durch Ausprobieren der Batterierlebensdauer zu lösen wäre.

LG

pah
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 26 März 2016, 20:36:34
Koennte man messen, wenn es wirklich interessiert. Verbrauchte energie unter den angenommenen Bedingungen. Kapazität der Akkus.
Störsender sollten nur dann einen relevanten Einfluss haben, wenn burst im Spiel ist.
Mir zu akademsich.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: brmpfl am 30 März 2016, 15:01:59
so wird es sein

Ich habe den HM-SEC-SD-2 heute in FHEM eingebunden, die Batterie Statusanzeige fehlt noch und der state steht leider dauerhaft auf "RESPONSE TIMEOUT:RegisterRead" -> muss man dazu dann bei jedem getConfig den Knopf in der Mitte drücken?

Gruß!

Moin,

bist Du hier weitergekommen?
Ich stehe aktuell vor der Entscheidung, für meinen 2. Wohnsitz Rauchmelder kaufen zu müssen/wollen.
Über kurz oder lang kommen wir um die HM-SEC-SD-2 nicht drum rum. Da kann ich auch die nehmen.
Nur werden die denn zwischenzeitlich voll unterstützt?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 30 März 2016, 15:30:01
Moin,

bist Du hier weitergekommen?
Ich stehe aktuell vor der Entscheidung, für meinen 2. Wohnsitz Rauchmelder kaufen zu müssen/wollen.
Über kurz oder lang kommen wir um die HM-SEC-SD-2 nicht drum rum. Da kann ich auch die nehmen.
Nur werden die denn zwischenzeitlich voll unterstützt?

leider nicht
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 30 März 2016, 21:27:56
Schon mal geloggt?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 30 März 2016, 21:45:30
Dann lasst mich doch bitte wissen wie und was ich loggen soll. Auch wenn bei mir aktuell die Zeit knapp ist, sollte man doch Prioritäten setzten ;-)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Zeitisen am 30 März 2016, 22:00:18
Hallo,

ich habe einen SD2 eingebunden in Fhem.

Der Zustand ist lesbar. Ein Alarm kommt an.
Was nicht funktioniert wie im Wiki beschrieben, ist das Auslösen eines Alarms.

Wenn mir jemand sagt, was ich wie aufzeichnen soll, dann werde ich das tun.
Hier die Aktionen "set teamCall", "set alarmOff", "set alarmOn","set alarmOff"

2016.03.30 21:56:45.226 0: HMLAN_Send:  HMLANCFG S:SC919827C stat:  00 t:00000000 d:01 r:C919827C m:05 9440 48CBF0 48CBF0 0001
2016.03.30 21:56:45.637 0: HMLAN_Parse: HMLANCFG R:RC919827C stat:0002 t:00000000 d:FF r:7FFF     m:05 9440 48CBF0 48CBF0 0001
2016.03.30 21:56:51.087 0: HMLAN_Send:  HMLANCFG S:SC9199962 stat:  00 t:00000000 d:01 r:C9199962 m:06 9441 48CBF0 48CBF0 010C01
2016.03.30 21:56:51.190 0: HMLAN_Send:  HMLANCFG S:SC91999C9 stat:  00 t:00000000 d:01 r:C91999C9 m:07 9441 48CBF0 48CBF0 010C01
2016.03.30 21:56:51.378 0: HMLAN_Send:  HMLANCFG S:SC9199A85 stat:  00 t:00000000 d:01 r:C9199A85 m:08 9441 48CBF0 48CBF0 010C01
2016.03.30 21:56:51.472 0: HMLAN_Parse: HMLANCFG R:RC9199962 stat:0002 t:00000000 d:FF r:7FFF     m:06 9441 48CBF0 48CBF0 010C01
2016.03.30 21:56:52.098 0: HMLAN_Parse: HMLANCFG R:RC9199A85 stat:0002 t:00000000 d:FF r:7FFF     m:08 9441 48CBF0 48CBF0 010C01
2016.03.30 21:56:52.726 0: HMLAN_Parse: HMLANCFG R:RC91999C9 stat:0002 t:00000000 d:FF r:7FFF     m:07 9441 48CBF0 48CBF0 010C01
2016.03.30 21:57:05.030 0: HMLAN_Send:  HMLANCFG I:K
2016.03.30 21:57:05.035 0: HMLAN_Parse: HMLANCFG V:03C4 sNo:KEQ1023952 d:2575DB O:FE5515 t:76893AD2 IDcnt:0012 L:15 %
2016.03.30 21:57:06.942 0: HMLAN_Send:  HMLANCFG S:SC919D750 stat:  00 t:00000000 d:01 r:C919D750 m:09 9441 48CBF0 48CBF0 010BC8
2016.03.30 21:57:07.046 0: HMLAN_Send:  HMLANCFG S:SC919D7B9 stat:  00 t:00000000 d:01 r:C919D7B9 m:0A 9441 48CBF0 48CBF0 010BC8
2016.03.30 21:57:07.305 0: HMLAN_Send:  HMLANCFG S:SC919D8BC stat:  00 t:00000000 d:01 r:C919D8BC m:0B 9441 48CBF0 48CBF0 010BC8
2016.03.30 21:57:07.362 0: HMLAN_Parse: HMLANCFG R:RC919D750 stat:0002 t:00000000 d:FF r:7FFF     m:09 9441 48CBF0 48CBF0 010BC8
2016.03.30 21:57:07.955 0: HMLAN_Parse: HMLANCFG R:RC919D8BC stat:0002 t:00000000 d:FF r:7FFF     m:0B 9441 48CBF0 48CBF0 010BC8
2016.03.30 21:57:08.583 0: HMLAN_Parse: HMLANCFG R:RC919D7B9 stat:0002 t:00000000 d:FF r:7FFF     m:0A 9441 48CBF0 48CBF0 010BC8
2016.03.30 21:57:10.911 0: HMLAN_Send:  HMLANCFG S:SC919E6D1 stat:  00 t:00000000 d:01 r:C919E6D1 m:0C 9441 48CBF0 48CBF0 010C01
2016.03.30 21:57:10.912 0: HMLAN_Send:  HMLANCFG I:K
2016.03.30 21:57:10.918 0: HMLAN_Parse: HMLANCFG V:03C4 sNo:KEQ1023952 d:2575DB O:FE5515 t:768951CD IDcnt:0012 L:19 %
2016.03.30 21:57:11.018 0: HMLAN_Send:  HMLANCFG S:SC919E73C stat:  00 t:00000000 d:01 r:C919E73C m:0D 9441 48CBF0 48CBF0 010C01
2016.03.30 21:57:11.262 0: HMLAN_Send:  HMLANCFG S:SC919E831 stat:  00 t:00000000 d:01 r:C919E831 m:0E 9441 48CBF0 48CBF0 010C01
2016.03.30 21:57:11.314 0: HMLAN_Parse: HMLANCFG R:RC919E6D1 stat:0002 t:00000000 d:FF r:7FFF     m:0C 9441 48CBF0 48CBF0 010C01
2016.03.30 21:57:11.922 0: HMLAN_Parse: HMLANCFG R:RC919E831 stat:0002 t:00000000 d:FF r:7FFF     m:0E 9441 48CBF0 48CBF0 010C01
2016.03.30 21:57:12.550 0: HMLAN_Parse: HMLANCFG R:RC919E73C stat:0002 t:00000000 d:FF r:7FFF     m:0D 9441 48CBF0 48CBF0 010C01

für spezielle Aktionen bitte melden.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 30 März 2016, 22:30:16
so ganz nebenbei, R-pairCentral steht dauerhaft auf set_0x123456... Readings sind keine mehr da... irgendwie hat der RM keine Lust mehr auf FHEM
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 06 April 2016, 20:25:26
Hi zusammen,

meine ersten 3 HM-SEC-SD-2 sind angekommen. Der erst ist mal mit FHEM angebunden, bis auf State = ? (3 mal, aber das wird ein Smilie) am Anfang passte alles.
Auch im Logfile habe ich meinen Funktionstest sehen können.
Bisher keine Gruppe / Teams gebildet und kein Probealarm ausgelöst.

Werde die kommenden Tage dann mal weiter testen und hier berichten.
Gibt es denn schon eine offizielle Unterstützung für das Model oder braucht noch jemand Infos?

Ich melde mich mit neuen Infos, wenn es was zu berichten gibt.


LG Christian
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 06 April 2016, 22:17:14
soweit nichts neues im Westen!

state = RESPONSE TIMEOUT:RegisterRead
activity = unknown
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 07 April 2016, 22:02:45
Ist er den gepairt? Logge das pairing.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 08 April 2016, 09:04:17
ich denke nicht dass er (zumindest) korrekt gepaart wurde:

     2016-03-31 15:15:32   PairedTo        0x000000

Für das logging reichen dir die standardmäßigen Angaben die ins LogFile geschrieben werden?

Gruß!

Nachtrag:

Ich habe den Rauchmelder mal gelöscht und neu angelernt. Was mir dabei aufgefallen ist:

1. der state als reading existiert nicht

2.     2016-04-08 09:12:57   R-pairCentral   set_0x123456
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: savage7 am 08 April 2016, 15:28:38
Hallo,

habe mir auch einen HM-SEC-SD-2 zugelegt um ihn als Alarm für meine Alarmanlage zu nutzen.
Das Einbinden in Fhem funktionierr wie gewohnt problemlos. Readings bekam ich aber erst nachdem ich testweise einen Probealarm ausgelöst habe.

Was ich nicht geschafft habe ist einen Alarm Ton per fhem abzuspielen, ich bin nach dieser Anleitung vorgegangen:
http://www.fhemwiki.de/wiki/HM-SEC-SD_Rauchmelder

Habe nun einen virtuellen TeamLead, in beiden peerlists scheinen die Geräte auf:
kueche.rauchmelder:
peerList Rauchmelder.Team

Rauchmelder.Team:
peerList kueche.rauchmelder

Wenn ich nun "set Rauchmelder.Team alarmOn" ausführe passiert nichts. Auch ein teamCall bewirkt nichts.

Hat vielleicht jemand einen Tipp für mich an was es noch liegen könnte?
Hat jemand schon erfolgreich einen Alarm auf einem HM-SEC-SD-2 abgespielt?

Danke!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 08 April 2016, 18:14:35
Zitat
habe mir auch einen HM-SEC-SD-2 zugelegt um ihn als Alarm für meine Alarmanlage zu nutzen.
da bin ich ja gespannt, wie lange die batterie funktioniert. falls du das alarmieren noch in gang bringst.  ;)

am besten messages sniffen, wie im wiki homematic sniffen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Zeitisen am 08 April 2016, 20:58:36
Hallo,

habe ich ja schon in Antwort #45 beschrieben.
Alarmauslösen geht nicht. Ich habe die Logs da mit gepostet.
Allerdings kann ich nichts damit anfangen. Das wäre was für martinp876.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 08 April 2016, 21:38:51
nach dem sniffen gemäß http://www.fhemwiki.de/wiki/Homematic_Nachrichten_sniffen

2016.04.08 21:20:45.394 4: CUL_Parse: CUL1 A 14 31 845E 2743E3 000000 849B90003FFE039609060108 -70
2016.04.08 21:20:45.540 4: CUL_Parse: CUL1 A 0C A6 8470 35C5E9 000000 00BF3B46 -39
2016.04.08 21:20:45.562 4: CUL_Parse: CUL1 A 0F 53 8610 302774 000000 0A98BF0E000029 -53.5
2016.04.08 21:20:48.278 4: CUL_Parse: CUL1 A 0F B9 8610 3C4B71 000000 0A98C80F000021 -57.5
2016.04.08 21:20:50.731 4: CUL_Parse: CUL1 A 0C 57 865A 35B6D2 000000 98C13B25 -55.5
2016.04.08 21:21:10.732 4: CUL_Parse: CUL1 A 0C 57 8470 35B6D2 000000 00C13B25 -55.5
2016.04.08 21:22:11.706 4: CUL_Parse: CUL1 A 0F 87 8610 36990C 000000 0A98CD0E00000B -68.5
2016.04.08 21:22:13.671 3: CUL_HM set HM_48C9D4 unpair
2016.04.08 21:22:14.832 4: CUL_Parse: CUL1 A 0F C2 8610 38E2C3 000000 0A98C20E0E003E -43
2016.04.08 21:22:27.732 4: CUL_Parse: CUL1 A 0F 41 8610 2C8BC7 000000 0A98C10C000021 -57.5
2016.04.08 21:22:30.855 4: CUL_Parse: CUL1 A 14 32 845E 2743E3 000000 849BC800404F039A0910FF03 -72.5
2016.04.08 21:23:04.733 4: CUL_Parse: CUL1 A 0C 58 865A 35B6D2 000000 98C13C24 -56
2016.04.08 21:23:05.333 4: CUL_Parse: CUL1 A 0C A7 865A 35C5E9 000000 98BF3B46 -39
2016.04.08 21:23:10.959 4: CUL_Parse: CUL1 A 0F 54 8610 302774 000000 0A98BF0E000029 -53.5
2016.04.08 21:23:15.577 4: CUL_Parse: CUL1 A 14 41 845E 3ACB82 000000 80077400003D00210901FE01 -73.5
2016.04.08 21:23:24.737 4: CUL_Parse: CUL1 A 0C 58 8470 35B6D2 000000 00C13C24 -56
2016.04.08 21:23:25.333 4: CUL_Parse: CUL1 A 0C A7 8470 35C5E9 000000 00BF3B46 -39
2016.04.08 21:23:41.747 4: CUL_Parse: CUL1 A 1A 8E 8400 48C9D4 000000 1000AA4E455130303033393035CE00010021 -57.5
2016.04.08 21:23:41.762 3: CUL_HM pair: HM_48C9D4 smokeDetector, model HM-SEC-SD-2 serialNr NEQ0003905
2016.04.08 21:23:41.848 4: CUL_send:  CUL1As 10 8F A001 FAFAFA 48C9D4 00050000000000
2016.04.08 21:23:42.011 4: CUL_Parse: CUL1 A 11 8F A002 48C9D4 FAFAFA 04B23EBBDA99490020 -58
2016.04.08 21:23:42.015 1: CUL_HM HM_48C9D4 need Crypt::Rijndael to answer signing request with CUL
2016.04.08 21:23:42.112 4: CUL_send:  CUL1As 0A 8F 8002 FAFAFA 48C9D4 00
2016.04.08 21:23:42.125 4: CUL_send:  CUL1As 17 90 A001 FAFAFA 48C9D4 000802010AFA0BFA0CFA16001F00
2016.04.08 21:23:42.300 4: CUL_Parse: CUL1 A 11 90 A002 48C9D4 FAFAFA 0418D38D0F3627001D -59.5
2016.04.08 21:23:42.304 1: CUL_HM HM_48C9D4 need Crypt::Rijndael to answer signing request with CUL
2016.04.08 21:23:42.401 4: CUL_send:  CUL1As 0A 90 8002 FAFAFA 48C9D4 00
2016.04.08 21:23:42.413 4: CUL_send:  CUL1As 0B 91 A001 FAFAFA 48C9D4 0006
2016.04.08 21:23:42.588 4: CUL_Parse: CUL1 A 11 91 A002 48C9D4 FAFAFA 0467DC48A927B80021 -57.5
2016.04.08 21:23:42.598 1: CUL_HM HM_48C9D4 need Crypt::Rijndael to answer signing request with CUL
2016.04.08 21:23:42.690 4: CUL_send:  CUL1As 0A 91 8002 FAFAFA 48C9D4 00
2016.04.08 21:23:42.840 4: CUL_Parse: CUL1 A 0F BA 8610 3C4B71 000000 0A98C80F000021 -57.5
2016.04.08 21:23:54.442 4: CUL_Parse: CUL1 A 1A 92 8400 48C9D4 000000 1000AA4E455130303033393035CE0001001F -58.5
2016.04.08 21:23:54.459 3: CUL_HM set HM_48C9D4 getConfig
2016.04.08 21:23:54.543 4: CUL_send:  CUL1As 10 92 B001 FAFAFA 48C9D4 00040000000000
2016.04.08 21:23:55.061 4: CUL_Parse: CUL1 A 18 92 A010 48C9D4 FAFAFA 0202000A000B000C0016001F00000024 -56
2016.04.08 21:23:55.162 4: CUL_send:  CUL1As 0A 92 8002 FAFAFA 48C9D4 00
2016.04.08 21:23:55.174 4: CUL_send:  CUL1As 0B 93 A001 FAFAFA 48C9D4 0103
2016.04.08 21:23:55.347 4: CUL_Parse: CUL1 A 0E 93 A010 48C9D4 FAFAFA 010000000024 -56
2016.04.08 21:23:55.448 4: CUL_send:  CUL1As 0A 93 8002 FAFAFA 48C9D4 00
2016.04.08 21:24:30.334 4: CUL_Parse: CUL1 A 0F C3 8610 38E2C3 000000 0A98C20E0E003F -42.5
2016.04.08 21:24:36.965 4: CUL_Parse: CUL1 A 0F 88 8610 36990C 000000 0A98CD0E000008 -70
2016.04.08 21:24:59.484 4: CUL_Parse: CUL1 A 0F 42 8610 2C8BC7 000000 0A98C10C000023 -56.5
2016.04.08 21:25:22.105 4: CUL_Parse: CUL1 A 14 33 845E 2743E3 000000 849C1600405D039B0912FF08 -70
2016.04.08 21:25:45.086 4: CUL_Parse: CUL1 A 0C A8 865A 35C5E9 000000 98BF3B46 -39
2016.04.08 21:25:54.578 4: CUL_Parse: CUL1 A 14 42 845E 3ACB82 000000 80077400003B0021090AFF00 -74
2016.04.08 21:26:05.084 4: CUL_Parse: CUL1 A 0C A8 8470 35C5E9 000000 00BF3B46 -39
2016.04.08 21:26:08.235 4: CUL_Parse: CUL1 A 0C 59 865A 35B6D2 000000 98C23C25 -55.5
2016.04.08 21:26:18.237 4: CUL_Parse: CUL1 A 0E 65 8410 35B6D2 000000 0B98C20B0025 -55.5
2016.04.08 21:26:23.343 4: CUL_Parse: CUL1 A 0F BB 8610 3C4B71 000000 0A98C80F000021 -57.5
2016.04.08 21:26:28.235 4: CUL_Parse: CUL1 A 0C 59 8470 35B6D2 000000 00C23C25 -55.5
2016.04.08 21:26:31.334 4: CUL_Parse: CUL1 A 0F C4 8610 38E2C3 000000 0A98C20E0E003E -43
2016.04.08 21:26:47.712 4: CUL_Parse: CUL1 A 0F 89 8610 36990C 000000 0A98CD0E00000A -69
2016.04.08 21:27:16.984 4: CUL_Parse: CUL1 A 0F 43 8610 2C8BC7 000000 0A98C20C000020 -58
2016.04.08 21:27:58.856 4: CUL_Parse: CUL1 A 14 34 845E 2743E3 000000 849C5E00405F039B0910FF06 -71
2016.04.08 21:28:10.336 4: CUL_Parse: CUL1 A 0C A9 865A 35C5E9 000000 98BF3B46 -39
2016.04.08 21:28:19.079 4: CUL_Parse: CUL1 A 14 43 845E 3ACB82 000000 80077500003C002108FFFFFE -75
2016.04.08 21:28:27.461 4: CUL_Parse: CUL1 A 0F 56 8610 302774 000000 0A98BF0E000029 -53.5
2016.04.08 21:28:30.336 4: CUL_Parse: CUL1 A 0C A9 8470 35C5E9 000000 00BF3B46 -39
2016.04.08 21:28:49.346 4: CUL_Parse: CUL1 A 0F BC 8610 3C4B71 000000 0A98C80F000021 -57.5
2016.04.08 21:28:57.235 4: CUL_Parse: CUL1 A 0C 5A 865A 35B6D2 000000 98C23C26 -55
2016.04.08 21:29:17.236 4: CUL_Parse: CUL1 A 0C 5A 8470 35B6D2 000000 00C23C26 -55
2016.04.08 21:29:19.986 4: CUL_Parse: CUL1 A 0F 44 8610 2C8BC7 000000 0A98C20C000022 -57
2016.04.08 21:29:22.085 4: CUL_Parse: CUL1 A 0F C5 8610 38E2C3 000000 0A98C20E0E003E -43
2016.04.08 21:29:48.216 4: CUL_Parse: CUL1 A 0F 8A 8610 36990C 000000 0A98CD0E00000A -69
2016.04.08 21:30:11.916 3: CUL_HM set HM_48C9D4 getConfig
2016.04.08 21:30:11.918 4: CUL_send:  CUL1As 10 94 B001 FAFAFA 48C9D4 00040000000000
2016.04.08 21:30:17.147 4: CUL_HM_Resend: HM_48C9D4 nr 2
2016.04.08 21:30:17.156 4: CUL_send:  CUL1As 10 94 B001 FAFAFA 48C9D4 00040000000000
2016.04.08 21:30:21.108 4: CUL_Parse: CUL1 A 14 35 845E 2743E3 000000 849C9F004082039D0912FD09 -69.5
2016.04.08 21:30:21.337 4: CUL_Parse: CUL1 A 0C AA 865A 35C5E9 000000 98BF3B46 -39
2016.04.08 21:30:29.331 4: CUL_Parse: CUL1 A 14 44 845E 3ACB82 000000 80077500003F0021090AFA01 -73.5

1 x unpair
1 x pair
1 x getConfig

am Ende kommt das bei raus:
Internals:
   CFGFN
   CUL1_MSGCNT 7
   CUL1_RAWMSG A0E93A01048C9D4FAFAFA0100000000::-56:CUL1
   CUL1_RSSI  -56
   CUL1_TIME  2016-04-08 21:23:55
   DEF        48C9D4
   IODev      CUL1
   LASTInputDev CUL1
   MSGCNT     7
   NAME       HM_48C9D4
   NR         266
   NTFY_ORDER 50-HM_48C9D4
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   lastMsg    No:93 - t:10 s:48C9D4 d:FAFAFA 0100000000
   protCmdDel 2
   protLastRcv 2016-04-08 21:23:55
   protResnd  1 last_at:2016-04-08 21:30:17
   protResndFail 1 last_at:2016-04-08 21:30:21
   protSnd    11 last_at:2016-04-08 21:30:11
   protState  CMDs_done_Errors:1
   rssi_at_CUL1 avg:-57.57 min:-59.5 max:-56 lst:-56 cnt:7
   Helper:
     Dblog:
       Activity:
         Dblog:
           TIME       1460143434.566
           VALUE      alive
       D-firmware:
         Dblog:
           TIME       1460143434.566
           VALUE      1.0
       D-serialnr:
         Dblog:
           TIME       1460143434.566
           VALUE      NEQ0003905
       R-paircentral:
         Dblog:
           TIME       1460143435.18984
           VALUE      0x000000
       Rawmsg:
         Dblog:
           TIME       1460143435.46198
           VALUE      A0E93A01048C9D4FAFAFA0100000000::-56:CUL1
       Rssi:
         Dblog:
           TIME       1460143435.46198
           VALUE      -56
       Aeskeynbr:
         Dblog:
           TIME       1460143422.70938
           VALUE      00
       State:
         Dblog:
           TIME       1460143821.28945
           VALUE      RESPONSE TIMEOUT:RegisterRead
   Readings:
     2016-04-08 21:23:54   Activity        alive
     2016-04-08 21:23:54   D-firmware      1.0
     2016-04-08 21:23:54   D-serialNr      NEQ0003905
     2016-04-08 21:23:55   PairedTo        set_0xFAFAFA
     2016-04-08 21:23:55   R-pairCentral   0x000000
     2016-04-08 21:23:42   aesKeyNbr       00
     2016-04-08 21:30:21   state           RESPONSE TIMEOUT:RegisterRead
     Regl_00.:
       VAL
   Helper:
     HM_CMDNR   148
     cSnd       01FAFAFA48C9D40103,01FAFAFA48C9D400040000000000
     getCfgListNo
     mId        00AA
     peerIDsRaw ,00000000
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +48C9D4,00,00,00
       nextSend   1460143435.44753
       rxt        0
       vccu       vCCU
       p:
         48C9D4
         00
         00
         00
       prefIO:
         CUL1
     Mrssi:
       mNo        93
       Io:
         CUL1       -54
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         CUL1
       flg        A
       ts         1460143435.3528
       ack:
         HASH(0x35acb90)
         938002FAFAFA48C9D400
     Rssi:
       At_cul1:
         avg        -57.5714285714286
         cnt        7
         lst        -56
         max        -56
         min        -59.5
     Shadowreg:
Attributes:
   IODev      CUL1
   IOgrp      vCCU:CUL1
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   comment    nach dem sniffen: verbose löschen
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,
   room       CUL_HM
   serialNr   NEQ0003905
   subType    smokeDetector
   verbose    4
   webCmd     statusRequest
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 10 April 2016, 11:49:45
state = RESPONSE TIMEOUT:RegisterRead
activity = unknown

Ich klinke mich mal ein, wenn ich darf?!
Habe seit gestern auch drei solcher Melder und renne gegen die gleichen und ähnliche Probleme an...
Die "autarke Vernetzung" der drei Sensoren untereinander funktioniert problemlos. Allerdings ist es mir bisher nicht gelungen, alle drei Sensoren in FHEM korrekt zu pairen.
Der als Repeater aktive und ein weiterer Sensor kommt nicht über den Status "PairedTo set_0xF10000 / R-pairCentral 0x000000" hinweg, der Dritte im Bunde steht auf "PairedTo 0xF10000 / R-pairCentral 0xF10000", aber bei allen laufen Kommandos wie z.B. "getConfig" gnadenlos auf einen TimeOut. Dabei spielt es auch keine Rolle, ob der jeweilige Sensor gerade ein "Nickerchen" macht oder z.B. durch den s.g. "Kommunikationstest" hellwach ist.
Das Pairing habe ich bestimmt 20 mal in unterschiedlichen Versionen versucht (Werkseinstellungen, unterschiedliche Reihenfolgen, direktes Pairing, blablub...), ohne auch nur ein mal ein sauberes Ergebnis erzielen zu können. Was aber immer identisch ist: Wenn ich FHEM in den Pairingmode schalte und einen der Sensoren in den Pairingmodus bringe, scheitert der erste Versuch immer und unabhängig vom Sensor mit einer roten Signalisierung am Selben. Erst der zweite Versuch kommt mit einer grünen LED.

Zum Thema Batterie: Die lässt sich austauschen, wenn man bereit ist, den Sensor zu öffnen und neue Batterien (2) einzulöten. Sollte Bedarf bestehen, kann ich dazu gerne mal ein bebildertes HowTo basteln

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 10 April 2016, 13:32:00
Hi zusammen,
ich bin leider noch nicht weiter dazu gekommen zu testen. Aber danke für die Info zwecks  Batterie Wechsel, ich habe Interesse an deinen bisherigen Erkenntnissen.

Bezüglich den Meldern und FHEM, im Wiki (http://www.fhemwiki.de/wiki/HM-SEC-SD_Rauchmelder) sund auch in der Homematic Anleitung, man soll die Melder erst mit der Zentrale verbinden und dann die Teams über die zentrale per peering erstellen. Ich würde diesen Weg weiterverfolgen. Bei mir klappt das peering mit einem virtuellen Teamlead aber nicht.  Im Melder sehe ich nichts. Evtl. komme ich heute Abend mal dazu, das Ganze zu sniffen.

LG Christian
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 10 April 2016, 13:43:06
... zwecks  Batterie Wechsel, ich habe Interesse an deinen bisherigen Erkenntnissen.
Gerne... Mache ich die kommende Woche wohl mal fertig, sobald ich wieder Platz auf'm Tisch habe ...

man soll die Melder erst mit der Zentrale verbinden und dann die Teams über die zentrale per peering erstellen
Ja, das hatte ich auch so verstanden und bei den ersten geschätzten 15 Versuchen auch so gemacht. Nur bei den letzten Versuchen hatte ich darauf verzichtet, da schon von mir aus abzusehen war, das da irgend etwas nicht funktioniert. Daher hatte ich die dann ausserhalb von FHEM miteinander verknuddelt, so das zumindest die zugedachte Funktionalität gewährleistet ist.

BTW: Es ist natürlich (mal wieder) von eQ3 nicht zu Ende gedacht... die Lösung mit dem Reed- Kontakt im Melder und dem Magnet auf dem Träger ist zwar schick, aber so bald man die Trägerplatten an die Decke geschraubt resp. geklebt hat, kommt man nicht umhin, sich irgendwie mit Magneten was zu basteln, um die Sensoren unabhängig von den Trägerplatten bedienen zu können; es wird wohl niemand die Platten wieder von der Decke schrauben wollen ^^
Im Zuge der Batterie- Doku werde ich wohl mal schauen, ob ich den Reed gegen einen schnöden Schalter tauschen kann...
Titel: Antw:HM-SEC-SD-2 neu - Batterie tauschen / Schalter einbauen
Beitrag von: M_I_B am 10 April 2016, 17:40:48
Zum Thema Batterietausch:

Wenn man den Sensor von unten betrachtet, findet man am Außenrand 4 kleine Schlitze. Mit einem Schraubendreher nun in diese Schlitze hinein und die darin befindlichen Kunststoffnasen nach außen drücken. Dabei gleichzeitig etwas Zug auf den Deckel ausüben. Das ganze ist dann 4 mal zu erledigen und schon hat man den ganzen Schlunz offen vor sich liegen (Bild 1 & 2).

Nun findet man an der Platine rings herum 4 weitere Plastiknasen (Bild 4). Um die Platine nun da raus zu bringen, mit einem Holz- oder Kunststoffspatel unter die Platine hebeln und gleichzeitig an der Stelle mit dem Daumen die entsprechende Kunststoffnase mit Gefühl etwas zurück biegen. Das Ganze ebenfalls 4 mal und nun kann man die Platine aus dem Unterteil entnehmen. Unbedingt darauf achten, keine Bauteile abzubrechen und das Insektenschutzgitter nicht einzudrücken!

Wenn man nun den Sensor umdreht, findet man die beiden Lithium-Zellen. Das sind Standard-Industriezellen und bei den üblich Verdächtigen zu erwerben. Das Auslöten ist allerdings etwas kniffelig, da die Minus- Anschlüsse genau unter dem Schallwandler liegen. Am Einfachsten ist es, eine Zelle mit der einen Hand etwas unter Spannung zu halten und mit der anderen Hand den Lötkolben unter den Schallwandler zu führen. Ist der Anschluss erstmal raus, lässt sich der doppelte Plus- Anschluss problemlos regeln.

In Bild 4 habe ich mal den Reed- Kontakt bezeichnet und dort sind auch die Leiterbahnen für einen SMD-(Um-)Schalter zu erkennen. In Bild 5 das Ganze noch mal von der anderen Seite. Dort habe ich im Weiteren die Leiterbahnen verfolgt und markiert. Eingeschaltet wird mit der Verbindung zwischen PLUS (links) und dem Mittelanschluss (von der Außenkante aus gesehen). Der Schalter arbeitet offensichtlich auf den davor befindlichen Transistor, für was auch immer der gut sein soll. Aber da das Platinenlayout bereits einen Umschalter vorsieht... Der Reed muß natürlich bei Einsatz eines Schalters ausgelötet werden. Und R1 ist eine Sicherung und kein Widerstand...

Habe ich was vergessen?

Edit sagte gerade, das vermutlich der Schalter von Reichelt mit der Nummer "SS SMD402 (http://www.reichelt.de/?&ARTICLE=112181)" passen wird. Ich besorge mir erst mal ein paar und berichte dann ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 11 April 2016, 12:21:38
Hallo M_I_B
Da ich die Melder mit Magnetolinks an die Decke bringen wollte, macht mich der Reedkontakt etwas nervoes. Von wo wirkt der Magnet darauf? (seitlich oder von oben)
Das Aus- und Einbauen der Batterie ist ja nicht ganz unproblematisch, da die Melder doch jetzt eine Art "Haltbarkeitsdatum" haben. Oder denkst du da nur an vorzeitig leere Batterien?
Danke und Gruss Christoph

P.S.: Sollten wir Martin eventuell einen bestellen, so dass er Ihn vernuenftig einbinden kann?!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 11 April 2016, 12:28:09
Wow, sehr cool, danke für die Bilder!

@Christoph: Das "Haltbarkeitsdatum" bzw die Empfehlung gilt praktisch für jeden Melder. Wenn Du bisher Deine Melder länger als 10 Jahre benutzt hast spricht wenig dagegen das bei den neuen nicht auch zu machen. Nur der Wechsel ist halt schwieriger.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: fhem-hm-knecht am 11 April 2016, 12:53:16
@DerFrickler

Zitat
2016.04.08 21:23:42.015 1: CUL_HM HM_48C9D4 need Crypt::Rijndael to answer signing request with CUL

Warum hast du das Perlmodul nicht installiert? so wie es dasteht.

Der SD2 ist wohl ein AES Gerät.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 11 April 2016, 21:35:40
@DerFrickler

Warum hast du das Perlmodul nicht installiert? so wie es dasteht.

Der SD2 ist wohl ein AES Gerät.

Die Frage kann ich Dir auch nicht wirklich beantworten... insbesondere da die Mitteilung ja nicht nur ein mal im log Stand. Aber seit der Installation des Moduls läuft es besser. Problematisch ist aber auch die Tatsache dass der Rauchmelder lediglich über einen einzigen Taster verfügt, der zum Prüfen und auch zum Anlernen dient. Bis dann endlich alle "set" verschwunden und alle "Commands" abgearbeitet waren, wussten alle Nachbarn das ich mich aktuell mit Rauchmeldern beschäftige. Beschwerden konnten von mir aus aber nicht entgegen genommen werden, da erste Tinnitus Symptome sich bemerkbar machten.

Meine Meinung: Man sollte Sensor und Funk getrennt halten, sowohl in der Bedienung als auch im Bezug auf die Batterien. Man kann ja durchaus an der fest eingebauten Batterie für den Sensor festhalten, nur das Funkmodul sollte davon unabhängig betrachtet werden. Beim alten Rauchmelder hat das mit den getrennten Tastern ja auch geklappt.

Um nicht ständig auf die Leiter steigen zu müssen habe ich den Rauchmelder kurzzeitig demontiert, wobei mir beim Abnehmen des Melders vom Deckenhalter etwas Kunstoff vom Entriegelungshebel abgebrochen ist... Mal eben so den Entriegelungshebel betätigen, drehen und abziehen mag theoretisch klasse klingen, bei der Umsetzung hapert es dann. Jetzt kann man den Rauchmelder nicht mal mehr fest in den Deckenhalter einrasten lassen.

Meine Meinung: Das Teil ist eine Fehlkonstruktion! Man hätte ja auch den alten Rauchmelder um einen Insektenschutz erweitern können.

Gruß!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 12 April 2016, 00:14:18
... Magnetolinks ... Von wo wirkt der Magnet darauf? (seitlich oder von oben)
Um genau zu sein: seitlich versetzt. Spielt aber keine Rolle. Die Magnetplatten lösen den nicht aus, schon gar nicht, wenn die Gegenplatte anliegt (magnetischer Kurzschluß = kaum Feldlinien ausserhalb).
Edit: Optional warte noch ein bisschen, bis ich den passenden Schalter gefunden und das HowTo dazu habe. Dann hast Du die Sorge mit dem Reed nicht mehr ...

Das Aus- und Einbauen der Batterie ist ja nicht ganz unproblematisch, da die Melder doch jetzt eine Art "Haltbarkeitsdatum" haben. Oder denkst du da nur an vorzeitig leere Batterien?
Ich denke da an beides. Natürlich erst mal vordringlich an vorzeitig leere Bakterien, da wir ja alles Bastler und Frickler sind und eh davon auszugehen ist, das die 10 Jahre eher ein theoretischer Wert ist. Aber auch nach Ablauf der 10 Jahre kann man m.E. problemlos mal die Rauchkammer reinigen und neue Batterien einbauen. Ich sehe ebenso wie MarcelK keinen Grund, nach entsprechenden Wartungsaktionen einen solchen RM zu entsorgen, der vollkommen OK ist. Aber das muss natürlich jeder selber entscheiden.

P.S.: Sollten wir Martin eventuell einen bestellen, so dass er Ihn vernuenftig einbinden kann?!
Auch wenn Martin mich bisher mit kaum zu überbietender Arroganz bedacht hat, wäre ich bereit, mich an den Kosten zu beteiligen ...

Aber seit der Installation des Moduls läuft es besser.
...öhhh... Ist mir irgendwie entgangen; welches Modul wo resp. wie installieren?
Edit: Also hier nach (http://fhemwiki.de/wiki/AES_Encryption) müsste ich das der SCC per Attribut mitgeben. Allerdings scheitert das bei mir, da die SCC das wohl nicht kann?!? Oder mache ich da einen Denkfehler?

... bei der Umsetzung hapert es dann. Jetzt kann man den Rauchmelder nicht mal mehr fest in den Deckenhalter einrasten lassen.
...tztztz... Grobmotoriker  ;D ;D ;D
Aber hast schon recht. Das "Ausklinken" geht ja noch, aber das Einriegeln von der Leiter aus hat so seine Tücken. Wie ich schon sagte: eQ3 denkt/entwickelt selten mal was zu Ende...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: fhem-hm-knecht am 12 April 2016, 01:14:56
Zitat
...öhhh... Ist mir irgendwie entgangen; welches Modul wo resp. wie installieren?
Edit: Also hier nach müsste ich das der SCC per Attribut mitgeben. Allerdings scheitert das bei mir, da die SCC das wohl nicht kann?!? Oder mache ich da einen Denkfehler?

Bevor ich den Beitrag geschrieben hätte , hätte ich das perl Modul installiert und die Erkennnisse gelogt und mitgeteilt ;)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 12 April 2016, 07:24:23
... ähhh ... Sorry Hary, aber ich hab keinen blassen Schimmer, was Du mir damit sagen möchtest ?!?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 12 April 2016, 08:58:02
welches Modul wo resp. wie installieren?
das Perl-Modul meinte ich...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 12 April 2016, 10:09:48
... wenn Du "libcrypt-rijndael-perl" meinst... ist schon?
Mensch, schreibt doch nicht immer im Telegrammstil. Es ist für jeden fast unmöglich zu erraten, was denn der andere genau meint...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 12 April 2016, 10:23:51
... wenn Du "libcrypt-rijndael-perl" meinst... ist schon?
Mensch, schreibt doch nicht immer im Telegrammstil. Es ist für jeden fast unmöglich zu erraten, was denn der andere genau meint...

Ja, ich meine das Crypt::Rijndael. Allem Anschein nach bestand vor dem Einsatz des HM-SEC-SD-2 keinerlei Notwendigkeit für dieses Perl-Modul.

Gruß!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 12 April 2016, 10:43:17
Ja, ich meine das Crypt::Rijndael. Allem Anschein nach bestand vor dem Einsatz des HM-SEC-SD-2 keinerlei Notwendigkeit für dieses Perl-Modul.
Da wäre/bin ich mir nicht so sicher; was ist mit dem KeyMatic? Unabhängig davon ist das Modul ja nicht (nur) für FHEM gemacht, sondern ein allgemeines Modul für Debian u.a., welches auch für viele andere Software benötigt wird. Ich hatte das schon vor längerem für was anderes installiert (weiß nicht mehr was; irgendwas mit VPN oder Tunneling oder so, was nicht funktioniert hat).

Wie dem auch sei... Halten wir für meine Seite / Config fest, nachdem die Bedingungen nun geklärt sind:

Also stehe ich erneut vor der Frage, was bei mir denn anders ist, das ich zu keinem akzeptablem Ergebnis komme.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: fhem-hm-knecht am 12 April 2016, 11:25:53
Zitat
Die SCC akzeptieren das ATTR "hmKey" nicht, so das ich keinen Key festlegen kann.

beim Cul kann man den "hmkey" auch nicht direkt festlegen  :o
deswegen die vccu anlegen , dort geht es,  ;)

hat doch aber alles nichts mit dem HM-SEC-SD-2 zu tun.

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: no_Legend am 12 April 2016, 11:32:48
beim Cul kann man den "hmkey" auch nicht direkt festlegen  :o
deswegen die vccu anlegen , dort geht es,  ;)

hat doch aber alles nichts mit dem HM-SEC-SD-2 zu tun.

Kann der CUL jetzt AES?

Gruß Robert
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 12 April 2016, 11:33:24
deswegen die vccu anlegen , dort geht es,  ;)
hat doch aber alles nichts mit dem HM-SEC-SD-2 zu tun.

... okay (grübel) ... Dann habe ich da irgendwie wohl was vollkommen falsch verstanden. Dann sind das zwei ganz verschiedene paar Schuhe, die vollkommen unabhängig voneinander laufen, wenn ich das nun richtig verstanden habe?

Ich versuche heute Abend mal was anderes: Ich werde mal ein Rasbian Mini, FHEM und libcrypt auf einer zweiten SD installieren, um dann mal zu versuchen, ob ich die Melder dann mit einem Vergleichbaren Ergebnis zu dem Euren gepairt bekomme. Vielleicht liegt das Problem ja ganz wo anders (vor dem Terminal sowieso, um dem Spruch zuvor zu kommen 8) )
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 12 April 2016, 11:40:53
Moin
Kurze Frage, was bewirkt der Reedkontakt? Ich haette erwartet, dass er den Melder stummschaltet, und man so die Konfiguration vornehmen kann!?
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 12 April 2016, 11:42:41
was bewirkt der Reedkontakt?
Nöö, der schaltet das komplette Teil aus. Der sitzt direkt in der + Zuleitung von den Batterien zum Sensor ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 12 April 2016, 12:13:56
Nöö, der schaltet das komplette Teil aus. Der sitzt direkt in der + Zuleitung von den Batterien zum Sensor ...
Na toll! So langsam entferne ich mich dann doch von den RM's!
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: kvo1 am 12 April 2016, 12:22:17
Hallo Zusammen,
ich trage mich hier mal kurz ein, weil ich das Thema acuh angehen will, nun aber verunsichert bin ob man den alten (HM-SEC-SD) oder neuen RM
(HM-SEC-SD-2) nehmen sollte  :-\

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 12 April 2016, 12:57:28
Hallo kvo1
Ich glaube die Ueberlegung gibt es nicht! Irgendwo hatte ich gelesen, dass der alte RM nun nicht mehr VDS ist. Also hoechstens noch als Signalgeber! Sonst waere ich da wohl auch bei Dir!
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: gompf am 12 April 2016, 18:19:15
Moin!  Nächster SD2 Kunde...
Funktioniert soweit wie bei den Vorstreitern.
Ich denke unser Problem ist zunächst der noch fehlende "tripple burst" mode seitens hmusb/fhem, um den Melder von uns aus zu wecken. Statusmeldungen/Alarme werden vom Melder soweit ich das sehen kann korrekt an FHEM gemeldet, IDs der CUL/Gruppenmitglieder sind "drin". Nur ansprechen kann ich den Melder ebenfalls nicht (team call/on/off).
Hängt im Moment am Testsystem mit hmusb/hm-usb-cfg2. NanoCul/culFW habe ich noch nicht getestet. 
Gruß,
gompf
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 12 April 2016, 18:21:46
...dass der alte RM nun nicht mehr VDS ist. Also hoechstens noch als Signalgeber! ...

Dann wäre es doch mal interessant zu wissen was das bedeutet. Ein Feuer und damit verbundener Rauch tritt unabhängig von Rauchmelder auf. Demnach kann uns eine VDS Zertifizierung davor nicht schützen. Die Argumente warum es umbedingt eine feste Batterie sein muss um die Zertifizierung zu bekommen sind mit Verlaub Schwachsinn:

1. Derjenige, der die Batterie des Rauchmelders für die Fernbedienung des Fernsehers benutzt, der nimmt auch den Rauchmelder von der Decke und verstaut diesen im Keller wenn dieser eine schwache Batterie signalisiert.
2. Viele Rauchmelder haben 9 V Blockbatterien, Fernbedienungen sicherlich nicht? oder?

Demnach mal die Frage hier ins Forum: Was bringt die VDS zertifizierung? Kann man im Schadensfall mit Nachteilen z.B. durch die Versicherung rechnen wenn man keine zertifizierten Melder benutzt? Oder ist diese Zertifizierung nur für vermietete Immobilien wichtig?

Dann noch mal eine Mitteilung die ich hier http://www.ehomeportal.de/HomeMatic-System/Sensoren/HomeMatic-Funk-Rauchmelder-Nicht-mehr-verfuegbar-siehe-eQ131408-und-eQ131408A2.htm?shop=shop&SessionId=&a=article&ProdNr=eQ76676&t=1598&c=2020&p=2020 (http://www.ehomeportal.de/HomeMatic-System/Sensoren/HomeMatic-Funk-Rauchmelder-Nicht-mehr-verfuegbar-siehe-eQ131408-und-eQ131408A2.htm?shop=shop&SessionId=&a=article&ProdNr=eQ76676&t=1598&c=2020&p=2020) gefunden habe:

HomeMatic Funk-Rauchmelder Nicht mehr verfügbar ! siehe eQ131408 und eQ131408A2

Gruß!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 13 April 2016, 08:45:38
Hallo Frickler
Ich habe noch die eine oder andere Fernbedienung mit 9 Volt Block! Allerdings nicht mehr in Benutzung. Aber meine Gardena Bewaesserungsuhr hat auch einen 9 volt Block. Ob wirklich jemand eine Leiter holt, um den RM zu pluendern halte ich fuer an den Haaren herbeigezogen. Die VDS Geschichte wird am Ende wichtig sein fuer die Versicherung, die sich dann eventuell querstellt. Hier http://vds.de/de/zertifizierungen/verzeichnisse/rauchwarnmelder/ steht mal warum die alten nicht mehr VDS Anerkennung haben. Gilt nur fuer jetzt gekaufte Geraete, Bestandsschutz gilt erstmal bis zum "Ablaufdatum"! Da das im wahrsten Sinne des Wortes ein Spiel mit dem Feuer ist, lasse ich mich persoenlich nicht darauf ein. Muss jetzt halt mal schauen welche es denn werden . Zeit habe ich, da ja bereits welche installiert sind, nur halt ohne Funk!
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 13 April 2016, 09:02:15
Die VDS Geschichte wird am Ende wichtig sein fuer die Versicherung, die sich dann eventuell querstellt.

Das ist auch meine Annahme, nur bricht ein Feuer nicht in Abhängigkeit einer Zertifizierung des Rauchmelders aus...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 13 April 2016, 10:21:47
nur bricht ein Feuer nicht in Abhängigkeit einer Zertifizierung des Rauchmelders aus...
Genau so sehe ich das auch. Aber darum geht es bei VdS nicht. Der VdS ist inzwischen ebenso wie die GEZ eine Geldbeschaffungsmaschine. Ursprünglich waren die Aufträge des VdS ziemlich sinnvoll (sind sie eigentlich immer noch), aber die ganze Sache hat eine rein auf finanziellen Gewinn gerichtete Eigendynamik entwickelt. Ich war viele Jahre im Bereich Elektronischer Objektschutz selbstständig und musste mich damit täglich herum schlagen. Dabei war es fast immer so, das es vollkommen identische Geräte (Rauchmelder, Hitzemelder, PIR/US/Radar- Melder, Kameras, Alarmzentralen, Wählgeräte, Akkus, ....) einmal mit und einmal ohne VdS- Zertifizierung gab; müßig zu erwähnen, das jene mit VdS annährend das Doppelte oder mehr gekostet haben. Das erschließt sich niemandem. Doof nur, das man dagegen kaum angehen kann, da sich u.a. die Versicherungen da mit eingeklinkt haben. Das ist eine für beide Seiten geldwerte Symbiose, die kaum zu sprengen ist.

BTW: Das erklärt vermutlich auch, warum auf der Platine vom Layout her ein Schalter vorgesehen ist. Da hat der VdS vermutlich gesagt, das es so nicht geht, da der dumpfe Kunde ja vergessen könnte, den Schalter auf ON zu stellen, wenn er das Teil an die Decke pappt...

Edit: Zitat von der VdS- Seite:
Zitat
Rauchwarnmelders von mindestens 10 Jahren erlaubt.
Danach dürfte der RM eigentlich keine Zulassung erhalten. denn schon in der BDA steht ganz klar, das die 10 Jahre nur unter ganz gewissen Umständen erreicht werden, was dem kleinen aber feinen Wörtchen "mindestens" entgegen steht ...

Na toll! So langsam entferne ich mich dann doch von den RM's!
... wieso? Erkläre mal bitte ...

... einem Vergleichbaren Ergebnis zu dem Euren gepairt bekomme. Vielleicht liegt das Problem ja ganz wo anders ...
Tja... Gesagt, getan... Und es ist tatsächlich so, aus welchen Gründen auch immer. Mit einer blanken Neuinstallation klappte das auf Anhieb. Ich bin dann beigegangen und habe den ganzen FHEM- Ordner ohne Configdateien auf die alte SD kopiert, perl und crypto mit autoclean/purge deinstalliert und neu installiert und das Problem scheint nun auch hier weg zu sein. Ich nehme an, das hier irgend eine Datei einen Knacks hatte oder fehlte. Ich kann es aber nicht nachvollziehen...
Zumindest ist jetzt alles da und das Pairing funktioniert nun auf Anhieb, unabhängig vom Sensor/Aktor.
Einzige andere Änderung: Offensichtlich hat die Reichweite des IT-SCC seit dem deutlich nachgelassen. Ich sehe zwar keinen Zusammenhang und es ist ja auch IT und nicht HM, aber merkwürdig ist es schon.

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 13 April 2016, 12:03:32

... wieso? Erkläre mal bitte ...

Naja, wenn das Gefiedel staendig losgeht, wenn ich beim Konfigurieren einmal zuviel die Taste druecke, dann werde ich bekloppt, und mein Hund auch! Wenn dann die anderen auch noch froehlich mitmachen, dann habe ich die Nachbarn auch irgendwann auf der Matte stehen. Oder ich hoere Sie, wie weiter oben schon geschrieben wurde, gar nicht mehr klingeln!Aber wahrscheinlich ist das auch wieder von diesem Verein vorgeschrieben. EQ3 haette dann aber ruhig eine Config-Taste spendieren duerfen, die haben andere (z.B. Fireangel) auch.
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 13 April 2016, 12:14:57
... das sehe ich nicht so verbissen ...
Im Normalfall kann es ja nur passieren, das Du die Taste zu kurz betätigst. Und auch dann piepst das Teil nur 3 mal. Die anderen RM ignorieren diesen Test vollkommen. Auch verstehe ich nicht, warum. Wenn die RM einmal angelernt sind, besteht doch keine Notwendigkeit eines Tastendruckes. Und wenn man die wachhalten will, dann kann man alle verbundenen RM mit dem Reichweitentest eine Weile ohne gequieke wach halten.
Ansonsten als letzte Option: Deckel abmachen und Kreppband, Filzgleiter o.d.G. über die Schallöffnung... hilft auch beim Frickeln auf'm Tisch ;)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Afterburner am 15 April 2016, 14:29:53
Ich bin jetzt auch gerade auf der Suche nach Rauchmeldern, wollte erst die normalen HM-SEC-SD haben um sie in FHEM zu integrieren. Durch Zufall habe ich dann die HM-SEC-SD-2 entdeckt und hier im Thread die Info mit dem VDS was mich jetzt komplett verwirrt.

Probleme mit der Versicherung ? Wenn das Ding piept und ich wach werde dann ist doch alles OK, den Schaden hat man doch so oder so.
Preislich sind ja beide Systeme gleich teuer, optisch sind beide kein Hingucker. Das alte System schaut etwas dezenter aus, das neue ist etwas praktischer.

Aber auf Nummer sicher zu gehen würde ich dann zum neuen System greifen, wenn gleich ich den Mist nicht verstehe, aber ich zahle ja auch GEZ ^^

Was meint ihr, bekommen wir das über FHEM noch hin das wir die RM zum Test piepen lassen können ? Ich habe den HM USB Stick
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: cerberus am 18 April 2016, 08:54:44
Hallo, ich habe meine Rauchmelder mit dem virtuellen TeamLead gepeert, sowie im WIKI beschrieben. Was mir aufgefallen ist das ich bei den alten HM-SEC-SD als Attibut peerIDs auch der TeamLead eingetragen wird, was jedoch bei den HM-SEC-SD-2 nicht der Fall ist, obwohl das Peering geklappt hat und die Rauchmelder auch im TeamLead zu sehen sind steht im RM bei peerIDs nur 00000000.


Bei mit funktioniert der TeamCall, der StatusRequest auch nicht (Alarmauslösung habe ich noch nicht versucht)

Grüße
cerberus
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 18 April 2016, 20:52:32
Mache ein getconfig. Klappt es und was steht dann drin?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Mirak am 18 April 2016, 20:54:00
Hallo,

ich habe ebenfalls 3 der neuen HM-SEC-SD-2 im Einsatz. Bei mir tauchen auch alle drei peerIDs im virtuellen TeamLead auf. Allerdings wird bei mir im RM bei peerID auch die des TeamLead angezeigt.

Kann gleichfalls bestätigen, dass TeamCall usw. nicht funktioniert.

Gruß
Rainer
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 19 April 2016, 10:31:36
... alle drei peerIDs im virtuellen TeamLead ...  / ... im RM bei peerID auch die des TeamLead ... / ... dass TeamCall usw. nicht funktioniert.
*zustimm*
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 19 April 2016, 20:46:41
wichtig ist, dass de Teamlead im RM eingetragen ist.
Ihr könnt einmal loggen. a) wenn ein teamcall ausgelöst wird und b) wenn ein SD einen Teamcall auslöst. Das kann man bei einem SD. sollte auch bei einem SD-2 funktionieren.
sniffen bitte.
Vielleicht ist da etwas anders... werden wir sehen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 20 April 2016, 07:18:25
P.S.: Sollten wir Martin eventuell einen bestellen, so dass er Ihn vernuenftig einbinden kann?!
Hallo Martin
Wie schon einmal von mir vorgeschlagen, wuerden wir Dir einen Sponsorn! Fuer uns hat es den Vorteil, dass er perfekt eingebunden ist, und fuer Dich, dass Du nicht immer auf Vermutungen und Halbwahrheiten bauen musst. (siehe Bewegungsmelder)
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 20 April 2016, 08:14:27
Hallo Martin
Wie schon einmal von mir vorgeschlagen, wuerden wir Dir einen Sponsorn! Fuer uns hat es den Vorteil, dass er perfekt eingebunden ist, und fuer Dich, dass Du nicht immer auf Vermutungen und Halbwahrheiten bauen musst. (siehe Bewegungsmelder)
Gruss Christoph

Sehe ich genau so und würde mich beteiligen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mele am 20 April 2016, 08:30:42
Hallo Martin
Wie schon einmal von mir vorgeschlagen, wuerden wir Dir einen Sponsorn! Fuer uns hat es den Vorteil, dass er perfekt eingebunden ist, und fuer Dich, dass Du nicht immer auf Vermutungen und Halbwahrheiten bauen musst. (siehe Bewegungsmelder)
Gruss Christoph

Ich sponsere mit!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 20 April 2016, 08:31:44
... dann sind's schon 4, oder habe ich mich verzählt?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: kvo1 am 20 April 2016, 08:55:13
... dann sind's schon 4, oder habe ich mich verzählt?
ich auch !... fünf  ;)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 20 April 2016, 12:48:42
ich auch !... fünf  ;)

das hängt davon ab wer schon mitgezählt wurde... ansonsten 6
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 20 April 2016, 13:05:20
das hängt davon ab wer schon mitgezählt wurde... ansonsten 6

Zähle ich doch mal:
--> 50 / 8,33 Euronen derzeit pro Person
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 20 April 2016, 13:48:35
Ich habe eine ELV-Card, bringt noch mal 3% und keine Versandkosten!
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 20 April 2016, 13:52:52
... pffft ... Wer hat die nicht?  ;D
Ich hätte demnächst einiges zu bestellen, aber wenn wer näher dran ist, ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: gompf am 20 April 2016, 15:19:36
Zähle ich doch mal:
  • pc1246
  • christian.uhlmann
  • mele
  • kvo1
  • DerFrickler
  • ...ike ...

7. gompf
-> ~7,15€

BTW: Wenn ich die RMs nochmals "richtig" mit virtuellem Teamleader paire, funktioniert dann der Gruppenalarm im Falle das FHEM/virtueller TL down sind?

Gruß,
Gompf
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 20 April 2016, 15:27:46
... ich hoffe, ich gebe das jetzt richtig wieder; man möge mich korrigieren ...

Das Eine hat mit dem Anderen nix zu tun. Du pairst ja erst einmal alle vorhandenen RM mit FHEM, dann peerst Du die untergeordneten RM mit dem TL (was im Falle des ausgefallenen FHEM e.t.c. die Gruppenalamierung sicher stellt; BDA Seite 9/10 oder per FHEM Kommandozeile) und dann in FHEM mit dem virtuellenTL...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: cerberus am 20 April 2016, 19:12:28
Hallo,

bei mir taucht die  peerID des TeamLead leider nicht im RM auf.

Was mache ich flasch? Mit den HM-SEC-SD hat es doch auch funktioniert.

Gruß
cerberus
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: grappa24 am 20 April 2016, 19:30:17
Ich würd mich auch als Sponsor beteiligen  8)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: brmpfl am 21 April 2016, 14:11:00
Ich schließe mich als Sponsor an.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 21 April 2016, 14:21:47
wichtig ist, dass de Teamlead im RM eingetragen ist.
Ihr könnt einmal loggen. a) wenn ein teamcall ausgelöst wird und b) wenn ein SD einen Teamcall auslöst. Das kann man bei einem SD. sollte auch bei einem SD-2 funktionieren.
sniffen bitte.
Vielleicht ist da etwas anders... werden wir sehen.

Hallo Martin,

ich würde mal die organisation der Beschaffung der RM's übernehmen.
Aber ich würde gerne kurz von dir wissen, ob dir das passt.

Folgenden 14 Leute beteiligen sich:

Macht bei  48,40 € (49,90€ abzüglich 3% ELV-Card Rabatt) sind das für jede nur 6,05 4,80 €.
Bei zweien 96,80 € also 9,60 €. Wenn Martin sich meldet überlege ich aber sogar schon ein weiteres 3er Set für mich zu bestellen und dann diese Martin zur Einbindung zu geben und dann selber weiter zu verwenden :)

Habe jetzt 2 RM's bei Conrad bestellt, da ich dort noch eine Gutschein hatte. Dadruch ist der Preis auf 92,40 € gesunken was bei 14 Unterstützern je 6,60 € sind.
Ihr bekommt eine PN mit den Zahlungsmöglichkeiten.

Also wenn es dir passt bitte eine kurze Info und dann per PN gerne deine Adresse, dann bestell ich gleich einen RM.


Danke und Grüße

Christian

Update: 23.04.2016 10:27:
- jschmitt, MadMax-FHEM und Bytechanger hinzugefügt
- Bestellung getätigt: Conrad mit Gutschein 2 RM's für 92,40 €
Update: 23.04.2016 10:39:
- Morgennebel hinzugefügt
- PN an die Unterstützer ist raus mit 6,60 € pro Kopf
Update: 23.04.2016 15:24
- Update Geldstatus
Update: 25.04.2016 11:59
- Update Geldstatus
Update: 25.04.2016 15:00
- Update Geldstatus
Update: 26.04.2016 10:56
- Update Geldstatus
Update: 10.05.2016 00:14
- Update Geldstatus, alles erhalten. Vielen Dank an alle
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 21 April 2016, 15:08:38
 ;)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 21 April 2016, 19:10:27
Bisher sind die folgenden 8 Leute dabei:
  • pc1246
  • christian.uhlmann
  • mele
  • kvo1
  • DerFrickler
  • gompf
  • grappa24
  • brmpfl

... hmmm ... Bin ich unerwünscht? Hab ich kein Problem mit, aber sagen sollte man es mir dann schon ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Mirak am 21 April 2016, 20:35:38
Hi, ich beteilige mich auch gerne am Kauf

Gruß
Rainer
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 21 April 2016, 22:01:59
Also zum Team/Peering einrichten und testen braucht man ja eigentlich zwei :P
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: kvo1 am 21 April 2016, 23:53:02
Also zum Team/Peering einrichten und testen braucht man ja eigentlich zwei :P
wenn sich noch paar Leute finden, dann sollten uns auch 2 SD´s nicht in den finanziellen Ruin treiben  :)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 21 April 2016, 23:54:24
... hmmm ... Bin ich unerwünscht? Hab ich kein Problem mit, aber sagen sollte man es mir dann schon ...

Sorry, doch bist du. Habe dich und Mirak nachgetragen und noch Kleinigkeiten in dem Post (https://forum.fhem.de/index.php/topic,35298.msg442384.html#msg442384 (https://forum.fhem.de/index.php/topic,35298.msg442384.html#msg442384)) geändert.
Aber wir müssen warten bis wir eine Info von Martin erhalten.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 22 April 2016, 10:00:18
... ok, hätte ja sein können, da Martin und ich uns nicht wirklich auf's Fell schauen können und ja von der Seite was hätte kommen können; alles gut 8)

wenn sich noch paar Leute finden, dann sollten uns auch 2 SD´s nicht in den finanziellen Ruin treiben  :)

Hätte ich auch kein Problem mit. Bei so vielen Leuten kommen wir auch bei 2 Stück nicht über 10 Tacken ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: jschmitt am 22 April 2016, 17:19:06
Hallo allerseits,

also ich wäre auch mit dabei. Je mehr umso günstiger...
(Ich selbst habe 12 "alte" SD und just heute drei Fehlalarme...)

Viele Grüße,

Johannes
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 22 April 2016, 22:46:55
Wenn ich welche habe werde ich es testen. Logisch.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 22 April 2016, 22:53:28
gut denn, christian.uhlmann will das alles organisieren... wie stellst Du Dir das mit dem Geld einsammeln vor? Überweisung, PayPal?

Gruß!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 22 April 2016, 22:55:51
wie stellst Du Dir das mit dem Geld einsammeln vor? Überweisung, PayPal?
... für mich kommt nur Überweisung in Frage; PayPal habe ich schon lange nicht mehr ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MadMax-FHEM am 23 April 2016, 00:00:52
Hallo,

ich lese ja schon immer fleißig mit da ich überlege die SD-2 einzusetzen.

Habe auch über SD schon nachgedacht aber (wegen evtl. [häufiger] Fehlalarme) nicht umgesetzt...

Daher: wenn es (noch geht) würde ich mich auch beteiligen.

paypal wäre mir am liebsten...
...Überweisung geht nat auch...

Gruß, Joachim
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 23 April 2016, 06:31:04
Hab's schon einige bestellt.
Daher bin ich auch an einer schnellen Umsetzung interessiert und wäre dabei.

Gruß

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 23 April 2016, 10:07:38
@christian.uhlmann
Bestellst Du die dann direkt zu Martin?! Ansonsten musst Du den Weiterversand bitte bedenken! Nach meiner Rechnung sind es jetzt €8,10 fuer jeden! Ich schicke es per Paypal als Freund, dann kostet es Dich keine Gebuehren.
@martinp876
Hast Du Christian schon Deine Adresse geschickt?
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 23 April 2016, 10:16:17
... ich habe es gerade noch mal für Christian zusammen gefasst:


Wenn wer übersehen wurde, einfach laut "HIER" schreiben ;)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Morgennebel am 23 April 2016, 10:33:59
Ich beteilige mich auch gerne.

Ciao, -MN
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Morgennebel am 23 April 2016, 10:39:36
Was ich gerne betonen würde: ich habe Dank fhem viel Geld gespart und einen erheblichen Luxusgewinn.

Daher würde ich das Projekt auch monatlich finanziell unterstützen (natürlich am liebsten gegen eine Quittung), wenn sich dies irgendwie organisieren lässt. Davon können dann neue Geräte (wie hier) oder andere Dinge bezahlt werden.

Ciao, -MN
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 23 April 2016, 10:42:50
Hallo zusammen,

Martin hat Kontakt mit mir aufgenomme, 2 RM's von Conrad mit Gutschein zu 92,40 € sind bestellt.
Bei 14 Unterstützern sind das 6,60 € für jeden, eine PN mit den Daten von mir ist raus.

Im Post weiter oben https://forum.fhem.de/index.php/topic,35298.msg442384.html#msg442384 (https://forum.fhem.de/index.php/topic,35298.msg442384.html#msg442384) habe ich auch alles zusmamengefasst und ich aktualisiere die Daten.


Vielen Dank an alle und Grüße

Christian
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 23 April 2016, 10:45:43
Daher würde ich das Projekt auch monatlich finanziell unterstützen ...
Das wäre m.M.n. aus organisatorischen Gründen viel zu aufwändig. Da solche Dinge nicht ganz so oft vorkommen, kann ich mir kaum vorstellen, das hier ein sinnvolles Kosten/Nutzen- Verhältnis bei raus kommt.
Ich würde es für solche Dinge eher bevorzugen, das Forum um eine Funktionalität zu erweitern, in der sich (zahlende) Unterstützer zu einem Beschaffungsprojekt eintragen und was vom Initiator entsprechend verwaltet werden kann resp. Programmierer entsprechend "Anträge" stellen können... Bedarfsgerecht halt...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Morgennebel am 23 April 2016, 10:50:23
Wie wäre es mit einer Umfrage im Forum, wer fhem regelmäßig unterstützen würde (und mit welchem Betrag), um das Potential abzuschätzen?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 23 April 2016, 12:35:24
Hallo Zusammen,

ich werde Devices die ich nicht besitze und nicht wirklich brauch gerne auf diese Weise testen. Einiges habe ich eh selbst anderes bekommt man mit logs auf die Reihe.
FHEM generell zu unterstützen ist Rudi der Ansprechpartner. Ich habe damit eigentlich wenig zu tun.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: chbla am 23 April 2016, 19:33:02
Servus die Herren - ich will die Diskussion nicht unbedingt unterbrechen, aber bin gerade auf der Suche nach passenden, Teamfaehigen Rauchmeldern.
Verwende Homematic ueber FHEM mit einem HMLAN, Thermostaten usw und wuerde das gerne so gut wie moeglich integrieren.

Da frage ich mich ob sich die neue Version lohnt, ich kenne mich da zu wenig aus - kann mir da jemand vielleicht kurz sagen wie das mit den neuen Aussieht?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 23 April 2016, 19:52:18
... woher weißt Du, das hier alles "Herren" sind  ;D

Spaß beiseite... Ich kenne die alten RM nur von Bildern und aus den Negativ- Berichten und kann daher keinen direkten Vergleich anstellen. Was ich aber sagen kann ist, das die neuen RM (3 Stück derzeit) bisher noch keinen einzigen Fehlalarm verursacht haben, obwohl ein RM recht nah am Kaminofen hängt (im Durchgang WZ/EZ) und einer im Kellergang mit naturgemäß reichlich arachnophobischem Getier...
Auch das man einen oder mehrere RM gleichzeitig als Repeater benutzen kann, war bei den alten RM m.W. nicht möglich (man möge mich korrigieren...). Das hat mir hier schon den Ar*** gerettet, da hier nur Stahlbeton verbaut ist (oder sonst was, was enorm schirmt).
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 24 April 2016, 00:29:22
Ich habe bisher nur die alten. Ich hatte keinen Fehlalarm. Was ich nicht sagen kann ist ob ein alarm korrekt erkannt werden würde.
Korrekt, die alten geben keinen alarm weiter. Mit Sicherheit nicht.
Bei den neuen werde ich es bald wissen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 24 April 2016, 08:54:02
Hallo,

ich würde gerne wissen, ob ein Michen alt/neu möglich ist?
D.h. in meinem Fall alle im Selben "virtuellen" Team anmelden.
Das hätte aber dem Nachteil, dass man vermutlich nicht AES nutzen könnte (das können die Neuen ja auch!).
(Ich befürchte immer noch, dass irgendwann ein Nachbar aus spass ein Alarmbefehl gibt ;-)  )

>>>>>>>>>> Da ich selber ein wenig Programmiere, interessiert es mich brennend, wie man jetzt vorgeht und den Verkehr mitsnifft, und
was dann zu tun ist!
Vielleicht könnte ich hier einige Hinweise bekommen...


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 24 April 2016, 09:25:39
wenn ich das Device habe werde ich erst einmal testen - und dann die Kombination alt neu prüfen- alte habe ich im Einsatz.

Wie geht man vor? nun man löst kommandos am Device aus und snifft mit. dann wertet man aus.
was zu tun ist? Sniffen einschalten wir im wiki beschrieben. dann nachdenken.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: chbla am 24 April 2016, 09:45:54
Danke fuer die Antwort oben
Dann machts wohl Sinn gleich die neuen zu kaufen ..
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 24 April 2016, 19:38:40
deine Entscheidung. gib mir erst einmal das nächste Wochenende für eine Aussage.
Generell bin ich optimistisch, dass das Device funktioniert. Brauchst du ein Detail dann warte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: chbla am 24 April 2016, 20:13:55
Danke - war nur generell gedacht, ganz so billig sind die Dinger ja auch nicht das ich mir da gleich 10 kaufe.. :)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 27 April 2016, 21:47:10
Die melder sind soeben angekommen, danke an alle.
Erste ergebnisse: anlernen an die zentrale problemlos.
Die melder werden wohl nicht den alarm melder zu melder weiterreichen. Das sehe ich nicht am melder, das steht in der anleitung. Jeder melder muss zu allen in reichweite sein.
Das peeren ist identisch beschrieben. Werde ich testen, erwarte aber keine unterschiede.

Mehr am wochenende
Es gibt mehr register
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MadMax-FHEM am 27 April 2016, 21:50:33
Hi martinp876,

vielen Dank schon mal!

Bin gespannt!

Will demnächst auch meine Wohnung ausrüsten...

Gruß, Joachim
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 27 April 2016, 21:55:42
Die melder werden wohl nicht den alarm melder zu melder weiterreichen. Das sehe ich nicht am melder, das steht in der anleitung. Jeder melder muss zu allen in reichweite sein.
Fehlt in Deiner Anleitung Kapitel 7.5?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: kvo1 am 27 April 2016, 22:24:00
Fehlt in Deiner Anleitung Kapitel 7.5?
Hallo Martin,
die Repeaterfunktion wird doch überall erwähnt ! das sollte schon funktionieren!

Gruß Klaus
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 27 April 2016, 23:04:46
... die Repeaterfunktion wird doch überall erwähnt ! das sollte schon funktionieren!

Kann ich nur bestätigen. Habe ich schon in alle Richtungen durchgetestet, allerdings nur mit 3 RM. Lt. Beschreibung sind auch mehrere Repeater möglich... Ohne diese Funktion wäre ich angesichts unserer Stahlbeton-Decken ziemlich aufgeschmissen...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 27 April 2016, 23:13:40
Alte Rauchmelder bestellt?

-Repeaterfunktion - Damit wird doch geworben und steht in der Produktbeschreibung!
Es dürfen maximal 3 Rauchmelder als Repeater eingesetzt werden.


Auch steht in der Anleitung, dass die neuen SD2 nicht kompatibel zu dem Funkprotokoll des SD sind!
max. 40 Rauchmelder im Verbund
Und Punkt 7.5 Repeaterfunktion


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 28 April 2016, 21:49:39
Ok, kann er wohl doch. Seltsamer Kommentar.
Das Register zum Einschalten des repeater ist klar, werde ich am Wochenende einbauen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 30 April 2016, 08:49:44
einiges ist klarer - einen Update habe ich eingestellt. Es fehlt aber noch einiges.

a) der SD arbeitet IMMER mit AES (steht sowieso im handbuch). Um also kommandos zu starten ist (Teamcall,...) muss man AES beherrschen. Das ist ein Hinweis insbesondere für CUL Nutzer

b)repeater habe ich eingeschaltet - bislang ohne sichtbaren Erfolg. Ich sehe keine wiederholungen. Evtl ist es inteligent und wiederholt nicht wenn RSSI zu hoch ist. Das einschalten geht mit Register devRepeatCntMax (seltsamer Name...)

c) die CCU kann ja garnichts. Ich weiss schon warum ich FHEM nutze und nicht die CCU2 ;)

d) Statusrequest ist eingebaut.

e) Rauchtests sind noch komplett offen - ich muss eine Zigarre suchen :)

Der Update ist eingecheckt, more to come
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: morph am 30 April 2016, 08:53:17
wie erkenne ich, ob ich "alte" rauchmelder bekommen habe oder "neue"?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 30 April 2016, 09:51:49
der neue heisst nicht SD sondern SD-2. Die sehen auch ganz anders aus. Der neue hat keine Batterie ;). also keine von dir tauschbare.

Repeater funktioniert jetzt. Was bei 2 Repeatern passiert kann ich nicht deuten - ich vermute einmal das gleiche wir beim Erste.

Neue SW eingecheckt.
Offen immer noch: AES Kalkulation der operationellen Messages
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 30 April 2016, 16:28:26
das Problem aktuell ist die message
01 1441 44E347 44E347 0101960000 03 0A802A78

03 muss die Nummer des keys sein
0A802A78 ist dann der key.
Ich gehe davon aus, dass
01 1441 44E347 44E347 0101960000
kodiert wird.
Da ich keinen Key übertragen habe muss das der Default key sein.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: kvo1 am 30 April 2016, 23:45:38
Hallo Martin,
Lässt sich den AES nicht abschalten ?

Gruß Klaus
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 01 Mai 2016, 07:47:49
Wie ist denn der aktuelle Stand?

Können die Geräte verwendet werden, welche Einschränkung gibt es derzeit?
AES war doch für CUL auch kein Problem, oder?

Gibt es Probleme, wenn ich meinen eigenen AES-Key übertrage?


Gruß

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 01 Mai 2016, 10:42:39
Stand:
das Handbuch stimmt (kein Wunder ;) ):
- Man kann alte und neue SDs nicht direkt peeren.
- man kann einen Repeater einschalten. Kann über FHEM gesteuert und kontrolliert werden.
- Alarme und teamcall werden von FHEM erkannt und angezeigt.
- peeren (teamen) ist möglich
- Burst-verfahren ist funktionsfähig

Offen ist das Thema Teamcall und Alarm von FHEM ein und auszuschalten. Problem ist das AES welches leicht anders funktioniert.
AES wird nicht also Signatur gesendet sondern gleich mit dem Kommando. eQ3 hat sich ein Verfahren ausgedacht was kodiert werden muss. Offensichtlich ist es nicht allein die Message. Man kann eine gesendete Message nicht einfach wiederholen - das wird ignoriert. Das gilt es zu knacken.
Bei meinen SDs habe ich keinen key gesetzt. die SDs verstehe sich also mit dem default-key.
AES Kommunikation zum Einrichten des Device ist nicht gefordert.

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 01 Mai 2016, 11:46:49
Danke für die Mühen.

Also ich nehme für mich mit:

1. ich kann die neuen SDs mit einem VirtuellenTeamLead nach Anleitung Wiki http://www.fhemwiki.de/wiki/HM-SEC-SD_Rauchmelder#virtueller_TeamLead  verbinden
   (hierbei muss ich für jeweils die alten SD und die neuen SD2 jeweils einen eigenen virtuellen TeamLeader bestimmtn)

2. FHEM kann "mitlesen" und bekommt Alarme/Batteriewarnungen mit.

3. derzeit ist es aufgrund des geänderten AES-Verfahrens nicht möglich den SD2 Befehle in Form von TeamCall oder Alarm ein / Alarm aus zu geben..

4. muss ich augrund des geänderten Deviceverhaltens (Burst) andere Attribute als im Wiki vorsehen?
Attribute

besondere Attribute

    msgRepeat sollte auf 1 stehen. SD ist ein burst device, wiederholen von Nachrichten belastet das HMLAN besonders. Die Team-kommandos sind hiervon nicht beeinflusst, also auch nicht das Auslösen eines Alarms.
    actCycle wird auf 99 Stunden gesetzt. Ein SD meldet sich alle 3 Tage bei der Zentrale, was der ActionDetector prüft.
    msgRepeat 1

Allgemein vorgeschlagen

    IODev [HMLAN/HMUSB/CUL]
    autoReadReg 5_readMissing
    event-on-change-reading .*

Optional, nur als Anregung zu verstehen

    devStateIcon off:general_ok *:secur_alarm
    group smokeDetect
    icon secur_smoke_detector


Ich hoffe, dass AES-Problem lässt sich in den Griff bekommen.
Der Batteriestatus wird aber doch übertragen, oder?

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: DerFrickler am 01 Mai 2016, 11:54:38
Der Batteriestatus wird aber doch übertragen, oder?

zwar nur in dieser Form, aber ja..

battery                       ok                    2016-05-01 10:38:57
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 01 Mai 2016, 12:17:28
Alles richtig.
AES fuer Alarme ist nicht abschaltbar.
Batteriestatus wird angezeigt.
Burst erkennt fhem automatisch
Offen ist also das AES.

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: cerberus am 01 Mai 2016, 15:18:28
Hallo, ich bekomme den HM-SEC-SD-2 mit FHEM nicht mal gepaired. Ich nutze ein SCC (CUL) und habe AES bisher nicht verwendet. Muss ich also AES in der VCCU einschalten um die HM-SEC-SD-2 mit FHEM pairen zu können?

Grüße
cerberus
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 01 Mai 2016, 16:52:10
Zitat
Muss ich also AES in der VCCU einschalten um die HM-SEC-SD-2 mit FHEM pairen zu können?
nein. Dieser Teil fuktioniert ohne AES einwandfrei.
Logge das einmal (sniffen). ich sehe kein Problem - hauptsache die CUL funktioniert.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: cerberus am 01 Mai 2016, 18:27:28
Danke Martin, ich habe es erstmal, war ein Empfangsproblem.

Was muß der virtuelle TeamLeader für einen Status haben? Bei mir steht dort immer noch als Status der letzte Alarm drin.

Gruß
cerberus
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 01 Mai 2016, 19:59:40
anbei ein Mitschnitt
sdTeam2 ist der virtuelle Lead.
Es wird alles wieder ausgeschaltet wenn man "den Knopf drückt".
Klappt alles prima.

Level 2 heist dass jemand bei einem mit-melder (SD im Team, ohne Alarm aber tutet) "aus" gedrückt hat. Das werte ich aktuell nicht separat aus.
Der Melder meldet keinen wirklichen Level, das sind fixe Werte, was ihr unter Level zu sehen bekommt.

Ich habe mit und ohne virtuellem Lead getestet - alles prima bei mir.
Jetzt sind die Räucherstäbchen meiner "Besten" alle.
sd4 und sd5 sind die beiden Melder des Teams.
Verbessern könnte man m.E. noch beim Abschalten welcher SD gemeldet und welcher noch nicht aus ist.
Ich denke aber es passt so

Immer noch offen ist das auslösen von Alarmen und teamcall aus der Zentrale (habe ich nicht vergessen - ist aber schwierig). Vielleicht hat jemand eine Idee zu AES berechnungen?


19:45:31.761 CUL_HM sd4 smoke_detect: sd4
19:45:31.761 CUL_HM sd4 smoke-Alarm_10
19:45:31.761 CUL_HM sd4 trigLast: sdTeam2:198
19:45:31.761 CUL_HM sd4 trig_sdTeam2: 198
19:45:31.797 CUL_HM sd5 smoke_detect: sd4
19:45:31.797 CUL_HM sd5 smoke-Alarm_10
19:45:31.811 CUL_HM sdTeam2 eventNo: 10
19:45:31.811 CUL_HM sdTeam2 level: 198
19:45:31.811 CUL_HM sdTeam2 smoke_detect: sd4
19:45:31.811 CUL_HM sdTeam2 smoke-Alarm_10
19:45:31.811 CUL_HM sdTeam2 trigger_cnt: 16

19:45:48.784 CUL_HM sd4 smoke_detect: sd5
19:45:48.784 CUL_HM sd4 smoke-Alarm_12
19:45:48.816 CUL_HM sd5 smoke_detect: sd5
19:45:48.816 CUL_HM sd5 smoke-Alarm_12
19:45:48.816 CUL_HM sd5 trigLast: sdTeam2:2
19:45:48.816 CUL_HM sd5 trig_sdTeam2: 2
19:45:48.830 CUL_HM sdTeam2 eventNo: 12
19:45:48.830 CUL_HM sdTeam2 level: 2
19:45:48.830 CUL_HM sdTeam2 smoke_detect: sd5
19:45:48.830 CUL_HM sdTeam2 smoke-Alarm_12
19:45:48.830 CUL_HM sdTeam2 trigger_cnt: 18

19:45:56.281 CUL_HM sd4 smoke_detect: none
19:45:56.281 CUL_HM sd4 off
19:45:56.281 CUL_HM sd4 trigLast: sdTeam2:0
19:45:56.281 CUL_HM sd4 trig_sdTeam2: 0
19:45:56.313 CUL_HM sd5 smoke_detect: none
19:45:56.313 CUL_HM sd5 off
19:45:56.327 CUL_HM sdTeam2 eventNo: 11
19:45:56.327 CUL_HM sdTeam2 level: 0
19:45:56.327 CUL_HM sdTeam2 smoke_detect: none
19:45:56.327 CUL_HM sdTeam2 off
19:45:56.327 CUL_HM sdTeam2 trigger_cnt: 17
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 01 Mai 2016, 20:36:09
Kurze Frage:

Da ich SD und SD2 jeweils mit eigenem TeamLeader habe, würde ich gerne beide über FHEM "verbinden".

D.h. löst ein Melder eines Teams aus, würde ich über FHEM das andere Team auch aktivieren wollen.
Gleichzeitig soll auch das "Stummschalten" weitergetragen werden.
(JA SD2 geht erst, wenn martin876 das AES-Problem gelöst hat).

Eine Frage insbesondere an martin876: worauf muss ic bei SD und SD2 -Teamleadern triggern, um das Stummschalten zu bekommen?

Also Rauchalarm geht ja mit Rauchmelder_Team:.*smoke-Alarm.* {Aber was kommt beim Stummschalten (SD und SD2) ??
???? Rauchmelder_Team:.*off.* { ????


PS: Grundsätzlich finde ich den SD2 ja besser. Was mich nur stört ist, dass ich in ca. 10 Jahren alle Geräte neu kaufen muss. Bei SD stört mich, dass augenscheinlich die "Rauchkammer" sehr klein ist und gefühlt der Melder mir etwas unempfindlich ist, also erst sehr spät auslöst.

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 02 Mai 2016, 00:14:01
Immer noch offen ist das auslösen von Alarmen und teamcall aus der Zentrale (habe ich nicht vergessen - ist aber schwierig). Vielleicht hat jemand eine Idee zu AES berechnungen?
Schlimmstenfalls haben sie für die SD-2 einen eigenen Key eingeführt. Hast Du noch mehr Beispiel-Telegramme?

War der Burst jetzt eigentlich irgendwas besonderes?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 02 Mai 2016, 06:29:41
Ich kann noch mehr Beispiele schicken.
Tripple burst .... scheint tatsächlich mehr burst zu benötigen. Das wird idR von den Wiederholungen ausreichend geleistet. Bei den Versuchen hat es immer funktioniert mit den gegebenen Einstellungen. Daher sehe ich keinen Grund das io durch mehr versuche stärker zu belasten.
Interessant ist dass im Gegensatz zu den alten alle Alarme nicht 3mal sondern 6mal gesendet und wiederholt werden.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 02 Mai 2016, 11:12:29
Hallo zusammen,
interessant fände ich auch den Kommunikationstest (Kapitel 7.2) dabei sollte einiges per Funk übertragen werden. Hat das schon mal jemand gemacht, könnte man das aus FHEM heraus triggern?

Was mich noch stört ist das alle 43 Sekunden die LED blinkt. Das geht in den Schlafzimmern gar nicht. Muss ich da Kabel abtrennen oder ist das ggf. über eine Register steuerbar?

LG Christian

P.S. Vielen Dank Martin für deine Arbeit.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 02 Mai 2016, 14:02:42
... Kommunikationstest ... könnte man das aus FHEM heraus triggern?
Nette Idee! Ich habe gerade nicht auf'm Schirm, ob die sich nicht sowieso über irgend etwas melden, wenn die Kette gestört ist, aber wenn man aus FHEM heraus regelmäßig einen KommuTest anstoßen und auf Fehler reagieren könnte, wäre das ein netter Sicherheitsgewinn ...

Was mich noch stört ist das alle 43 Sekunden die LED blinkt. Das geht in den Schlafzimmern gar nicht. Muss ich da Kabel abtrennen oder ist das ggf. über eine Register steuerbar?
... wat bist Du empfindlich ;) Aber ok... Wir hatten auch mal einen RM, welcher extrem hell geblinkt hat. Mich störte das nicht, aber Frauchen... Lösung: kleinen selbstklebenden Filzgleiter in weiß über die LED geklebt.
Ich kann mir nicht vorstellen, das man die LED per Register abschalten kann. Das stände m.E. einer Zulassung im Wege...

P.S. Vielen Dank Martin für deine Arbeit.
*zustimm*
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 02 Mai 2016, 21:04:21
Den kommTest nicht falsch verstehen. Das ist der teamcall welcher den kommTest darstellt. Es ist so, dass du ihn von einem SD auslöst und dann ALLE anderen auf bllinken kontrollierst. Dann den nächsten druecken, wieder alle kontrollieren. Und so fort.
Von der zentrale aus geht das in diesem Umfang nicht. Ein SD der gehört hat sendet nichts. Kontrolle nur über die led.

Du kannst also nur prüfen, ob die zentrale Kontakt zu allen hat. Nicht mehr und nicht weniger.
Das aber passiert automatisch. Das device meldet sich regelmässig.
Wer will kann einen statusrequest regelmässig ausführen. Das kostet aber Batterien.

Von der zentrale einen teamcall auszuführen bringt somit wenig added value. Du musst dann alle SDS anschreiten uns LEDs prüfen. Ohne aufstehen geht das nicht.

Da teamcall AES signiert ist kann fhem das aktuell nicht. Aus meiner Sicht ein ärgerlicher aber geringer Verlust.
Fuer alarm sieht es schon anders aus. Auch AES Problem.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 03 Mai 2016, 07:02:24
Klingt nach einem großen Problem mit AES!
Ich hoffe es ist lösbar!

Ich hoffe auch, dass eq3 nicht noch mehr Komponenten mit dieser Verschlüsselung einführt, dann könnte es um FHEM dunkel werden, wenn keine Lösung gefunden wird.


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 03 Mai 2016, 17:57:00
Von der zentrale aus geht das in diesem Umfang nicht. Ein SD der gehört hat sendet nichts. Kontrolle nur über die led.
... ja, das macht Sinn; so weit hatte ich gar nicht gedacht ...

Wer will kann einen statusrequest regelmässig ausführen. Das kostet aber Batterien.
Funktioniert bei mir nicht wirklich. Sobald ich einen StatusRequest anfordere, reagieren alle 3 RM mit:
SCC2_MSGCNT 2
   SCC2_RAWMSG A0E88A61048F213F10000060100002F::-55:SCC2
   SCC2_RSSI  -55
   SCC2_TIME  2016-05-03 17:46:00
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:88 - t:10 s:48F213 d:F10000 060100002F
   peerList   Team_RM,
   protCmdDel 1
   protLastRcv 2016-05-03 17:46:00
   protResnd  2 last_at:2016-05-03 17:46:29
   protResndFail 1 last_at:2016-05-03 17:46:34
   protSnd    4 last_at:2016-05-03 17:46:20
   protState  CMDs_done_Errors:1
   rssi_SCC2  lst:-47 max:-47 min:-47 avg:-47 cnt:1
   rssi_at_SCC2 max:-55 lst:-55 cnt:2 avg:-55.5 min:-56 
Wie man sieht, läuft der z.B. auf einen MISSING ACK. Das passiert auch z.B. bei einem GetConfig o.ä.. Irgendwie wachen die nicht auf. Wenn ich die aber in den Testmode setze (Tastendruck), dann geht's ...
Das die dabei Batterie verpulvern stört mich nicht wirklich. Ob ich die Zellen nun nach 5 Jahren oder 8 Jahren tauschen muss, ist mir ehrlich gesagt mumpe...

Ich hoffe auch, dass eq3 nicht noch mehr Komponenten mit dieser Verschlüsselung einführt, dann könnte es um FHEM dunkel werden, wenn keine Lösung gefunden wird.
... komisch, diese dunkle Wolke geisterte auch schon in meinem Unterbewustsein herum. Das wäre eine gute Option für eQ3, die Leute mit mittleren und großen Installationen an die eigenen Produkte zu binden und diese dann mit noch mehr Marge als jetzt schon zu verticken.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 03 Mai 2016, 20:18:43
Bei eq3 haben fast alle devices AES. Pflicht ist er bei keymatic und dem neuen SD.
Fhem kann AES fuer alle ausser die neuen sd2. Eigentlich auch fuer sd2, nur eben nicht die Kommunikation eines sdlead faken.
Statusrequest ist nicht dokumentiert. Wenn dein device aber auch kein getconfig ausführt liegt es nicht am Kommando. Ist das device gepairt? Das ist das erste Problem.
Lese die config mit dem Button und prüfe das pairing. Ansonsten Logge die messages damit ich den burst sehen kann.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 03 Mai 2016, 20:43:08
Bei eq3 haben fast alle devices AES. Pflicht ist er bei keymatic und dem neuen SD. ...
... vermutlich fehlt mir da der Hintergrund... Aber wenn jetzt eQ3 auf die Idee kommt, die Key's zu wechseln, dann ist aber Essig, oder?

... Ist das device gepairt? Das ist das erste Problem.
Lese die config mit dem Button und prüfe das pairing. Ansonsten Logge die messages damit ich den burst sehen kann.
Klar, das pairing steht korrekt auf der ID 0xF10000 bei "PairedTo" und "R-pairCentral" ohne set o.ä. davor. Das passt zumindest und auch gefakte Alarme (Zigarette) schlagen bei FHEM korrekt auf.
Mit Loggen meinst Du bestimmt die RAW? Muss ich mich erst mal schlau lesen, wie ich das für ein/dieses Gerät exklusiv anderer Messages bewerkstelligen kann; hab ich noch nie gemacht... Wird nachgereicht, sobald ich es auf die Reihe bekommen habe...

BTW: Könnte das ggf. ein Problem des Busware SCC in Verbindung mit einem RPi2 sein? Ich hege so langsam den Verdacht, da ja manchmal auch andere Geräte nicht so reibungslos reagieren, wie das hier oft als üblich beschrieben wird.
Ich plane allerdings, FHEM auf einen Banana M3 umzulegen und zumindest für HM den neuen HM-LAN zu nutzen ...

Nachtrag:
Habe gerade noch mal ein GetConfig gesendet. Den hat er jetzt sofort geschluckt, aber STATE stand weiterhin aus Missing ACK. Dann bin ich böse geworden und habe dem RM einen reset geschickt. Erster Versuch lief wieder auf einen CMD-Error und STATE wechselte von set_reset wieder auf Missing ACK. Also noch mal ... dann ging es ohne Fehler durch und STATE steht nun auf off...
Irgend was hakt da bei der Kommunikation... Abstand SCC mit 8dbi Antenne zum RM ~6m bei fast direkter Sicht.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 03 Mai 2016, 21:15:23
Kann ein Problem sein. Das io muss auf Kommando burst senden. Cul und cuno machen das. Hmlan und hmusb sowieso.

Nein, eq3 wird den key nicht aendern. Und wenn ist das kein Problem. Der User welcher AES nutzen will sollte tunlichst den key aendern! Der eq3 key bietet keinen Schutz da er irgendwo sichtbar sein muss. Sonst könnte ich die Lampen des Nachbarn steuern, oder seine tuer.

Loggen siehe sniffen im wiki, auch selektiv
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 03 Mai 2016, 21:34:27
... ich glaube mal, das ich den AES-Key noch nicht geändert habe. Aber da wir hier auf'm Dorf wohnen und ich wohl das einzige Haus mit so was betreibe, dürfte die Gefahr verschwindend gering sein. Ich werde es trotzdem mal nachholen ... Dank für die Erinnerung!

... Sniffen ... Das war das Wort was mir nicht mehr eingefallen ist ;)

Für meinen SCC müsste ich dann quasi ...

attr global verbose 1
attr global mseclog 1
attr SCC1 verbose 4

einbauen. Aber da geht dann das selektive Loggen nicht wie bei HMlan ala HMID, oder kann ich einfach als letzte Zeile dazu notieren ...
attr global verbose 1
attr global mseclog 1
attr SCC1 verbose 4
attr SCC1 logIDs EG_RM_WZ,EG_RM_FZ,KG_RM_KF
... um ausschließlich die drei Rauchmelder zu loggen?

EDIT:
Also logIDs geht bei SCC nicht.
Ich habe verbose auf 5 gesetzt und das Log mitgelesen, um zu erkennen, wann was passiert. Das ist dabei heraus gekommen:
# set EG_RM_WZ reset #
2016.05.03 22:49:24.539 4: CUL_Parse: SCC2 A 0D 95 8410 448306 F10000 06011900EE -83
2016.05.03 22:49:24.541 5: SCC2 dispatch A0D958410448306F1000006011900::-83:SCC2
# MISSING ACK // CMDs_done_Errors:1 #

# set EG_RM_WZ getConfig #
2016.05.03 22:52:59.979 4: CUL_Parse: SCC2 A 0D A3 8410 448158 F10000 06010E0035 -47.5
2016.05.03 22:52:59.982 5: SCC2 dispatch A0DA38410448158F1000006010E00::-47.5:SCC2
2016.05.03 22:53:43.688 4: CUL_Parse: SCC2 A 0D 96 8410 448306 F10000 06011900F0 -82
2016.05.03 22:53:43.690 5: SCC2 dispatch A0D968410448306F1000006011900::-82:SCC2
# RESPONSE TIMEOUT:RegisterRead // CMDs_done_Errors:1 #
Ich habe immer in Kommentaren darüber geschrieben, was ich gesendet habe und darunter, was das Ergebnis war.
Eigentlich müsste da doch viel mehr an Daten kommen, oder nicht? Auffallen war auch, das Änderungen am Log immer mehr als 30 Sekunden gedauert haben (abzgl. 1 Sekunde Log-Refresh). Daher kann ich nicht sagen, ob die Einträge im Log durch den abgesetzten Befehl ausgelöst wurden oder aber sowieso gekommen wären durch Statusmeldungen anderer HM- Geräte; ich kann die Log- Einträge eh nicht interpetieren ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 04 Mai 2016, 06:24:22
Bei deinem loggen stimmt etwas nicht. Da kein CUL_Send vorkommt wird nichts gesendet. Das ist sicher nicht korrekt da ja Antworten kommen.
Hast du etwas ausgeschnitten?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 04 Mai 2016, 07:47:15
Hast du etwas ausgeschnitten?
...nö, nur die Kommentare hinzu gefügt...
Zum Verständnis gefragt: Wird das "CUL_Send" direkt vom Befehl generiert oder nur dann, wenn tatsächlich der CUL den Befehl empfangen hat? Anders herum: Wenn ich physisch keinen CUL dran habe, würde dann trotzdem von der Software (FHEM) ein "CUL_Send" ins Log geschrieben?

Ich werde von Anfang an das Gefühl nicht los, das die SCC mit der heißen Nadel gestrickt sind. Da hatte ich schon immer Probleme mit, wobei Busware das ziemlich egal ist, wie ich selbst erfahren konnte; Hauptsache verkauft...

Ich mache heute Nachmittag noch mal einen kompletten Neustart, klemme mal ein Scope an und versuche mal zu ergründen, ob diese Probleme auf Hard- oder Softwareseite zu suchen sind.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 04 Mai 2016, 11:32:07
hier gab es das auch schon https://forum.fhem.de/index.php/topic,51002.msg426525.html#msg426525 (https://forum.fhem.de/index.php/topic,51002.msg426525.html#msg426525).
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 04 Mai 2016, 12:27:44
... ja, genau so ist das >:( Was nutzt einem ein Stackable, wenn es gestackt nicht funktioniert?!? Aber Busware will davon nichts hören ...
Wie gesagt: Ich habe die Schn**** gestrichen voll von dem Murks und vorhin (entgegen meinem ersten Impuls) erstmal einen HMlan in Rund bestellt. Wenn ich jetzt noch was vergleichbares zum HMlan für IT finden würde, könnte ich das ganze Busware- Geraffel bei eBay entsorgen ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 Mai 2016, 23:05:09
Na ja, also zumindest das "Stummschalten" der TeamMitglieder würde ich schon gerne über die Zentrale machen können.
Es wäre also toll, wenn es eine Lösung für das AES-Problem gäbe!

Außerdem um zwei Teams über die Zentrale zu koppeln (wie in meinem Fall ein Team alter SD und ein Team neuer SD2) wäre dies eine
zwingende Voraussetzung.

Greets


Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 05 Mai 2016, 21:59:38
Ich kann noch mehr Beispiele schicken.
Dann schick mal bitte. Cryptographie ist nicht mein Fachbereich, Security und Reverse-Engineering im allgemeinen aber schon, insofern würd ich's mir gerne zumindest mal anschauen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 05 Mai 2016, 23:00:02
Hallo,

ich nehme schwer an, dass das diesmal RFChannel::performCBCAuthentification(BidcosFrame&) (https://forum.fhem.de/index.php/topic,20121.msg136834.html#msg136834) ist (siehe rfd aus alter CCU2-FW).

IIRC war das so:
x = 49 <sender> <empfaenger> xx yy zz 00 00 00 00 00 05
xx,yy,zz waren IIRC 3 andere Bytes aus dem Frame

Das ganze wird AES verschlüsselt, dann mit irgendwas ver-Xored und dann nochmal verschlüsselt. Mit was ver-Xored wurde, weiss ich nicht mehr, hab ich mir auch nicht aufgeschrieben damals :-(

Ich hab das nicht weiterverfolgt, da ich dann (komplett ohne Disassembler) den "richtigen" Algorithmus gefunden hatte...

Ich hab im Moment leider keinerlei Zeit, mir das nochmal genauer anzuschauen, aber ein alter rfd und IDA/Hopper könnten hier Erfolg versprechen.

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 06 Mai 2016, 10:36:28
Hallo Michael,

super Hinweis, kann ich mir gerne mal näher im IDA reinziehen (sofern's die Zeit und Family zulässt...). Wieso muss es ein alter rfd sein? Wurde der mal mit Symbole gelinkt oder woher kommen die Namen?

Beste Grüße, Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 06 Mai 2016, 11:24:45
Hallo Marcel,

Wieso muss es ein alter rfd sein? Wurde der mal mit Symbole gelinkt oder woher kommen die Namen?

Anscheinend ist das mittlerweile in der Firmware des Funkmoduls selbst implementiert und nicht mehr im rfd. Zumindest gibts den Code jetzt nicht mehr.

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 06 Mai 2016, 17:30:53
Hallo,

wie frage ich beim virtuellenTeamLeader ab, welcher Rauchmelder Alarm gemeldet hat?

Beim SD - TeamLeader ist es "smoke_detect".
Irgendwie sieht mein TeamLeader fürs SD2 anders aus und hat dieses Reading nicht!

Er ist in FHEM.cfg so konfiguriert:
define TeamDevSD2 CUL_HM 111113
attr TeamDevSD2 IODev HMLAN1
attr TeamDevSD2 model virtual_1
attr TeamDevSD2 subType virtual
attr TeamDevSD2 webCmd virtual
define Rauchmelder_Team2 CUL_HM 11111301
attr Rauchmelder_Team2 alarmDevice Sensor
attr Rauchmelder_Team2 alarmSettings alarm7,|Rauchmelder_Team2:.*smoke-Alarm.*|RauchAlarm|on
attr Rauchmelder_Team2 devStateIcon off:general_ok *:secur_alarm
attr Rauchmelder_Team2 group Rauchmelder Teamleader
attr Rauchmelder_Team2 icon secur_smoke_detector
attr Rauchmelder_Team2 model virtual_1
attr Rauchmelder_Team2 peerIDs bla,blalbla
attr Rauchmelder_Team2 room Rauchmelder
attr Rauchmelder_Team2 webCmd teamCall:alarmOn:alarmOff

Bei Readings gibt es nur peerList und state ...


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 06 Mai 2016, 21:59:53
Sollte gleich sein. Du zeigst das device. Der lead ist der channel.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Depechem am 06 Mai 2016, 22:04:28
Hallo @all,
könnte hier bitte jemand eine kurze gesamte Anleitung zur Anbindung der Rauchmelder in FHEM reinschreiben.
So wie hier bei dem alten SD:
http://www.fhemwiki.de/wiki/HM-SEC-SD_Rauchmelder
Oder sind die Befehle alle identisch?

Vielen Dank im voraus
Gruß Thomas
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 07 Mai 2016, 01:03:13
ich nehme schwer an, dass das diesmal RFChannel::performCBCAuthentification(BidcosFrame&) (https://forum.fhem.de/index.php/topic,20121.msg136834.html#msg136834) ist (siehe rfd aus alter CCU2-FW).

IIRC war das so:
x = 49 <sender> <empfaenger> xx yy zz 00 00 00 00 00 05
xx,yy,zz waren IIRC 3 andere Bytes aus dem Frame

Das ganze wird AES verschlüsselt, dann mit irgendwas ver-Xored und dann nochmal verschlüsselt. Mit was ver-Xored wurde, weiss ich nicht mehr, hab ich mir auch nicht aufgeschrieben damals :-(

Ich hab das nicht weiterverfolgt, da ich dann (komplett ohne Disassembler) den "richtigen" Algorithmus gefunden hatte...
Dieses std::string verseuchte ARM C++ Compilat zu lesen ist ungefähr so witzig wie ne Wurzel-Behandlung. Ich hab ihn trotzden mal in Pseudo-Code umgeschrieben und immerhin stimmt er bisher mit Deinen Erkenntnissen überein  8) (xx=Frame[FrameSize - 6], yy=Frame[FrameSize -5], zz=Frame[0] (Länge?) BTW). Kann nur hoffen dass es auch wirklich was mit dem SD-2 zu tun hat... werd's checken sobald man mir mal ein paar vollständige Frames zeigt.

Beste Grüße, Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 07 Mai 2016, 09:03:01
Kein Unterschied. Nur alarmon/off und teamcall funktionieren nicht.
Edit:
Repeat ist neu. Du kannst,wie in der Anleitung des SD beschrieben, Einige als Repeater konfigurieren. Eq3 beschränkt das in der Anleitung auf max 3 im Team. Sicher kann man mehr eintragen. Ich kann mir vorstellen, dass es zu Problemen mit der funklast führen kann, sollten 5 und mehr SDS anfangen zu wiederholen.
In hm configcheck ist die Prüfung noch nicht drin.

Ich halte es für sinnvoll (intelligent) ein template dafür zu erstellen. Warum? Ist doch nur ein Register? Weil ein template einfach zu verwalten, eine config Prüfung zulässt und eine Wiederherstellung ermöglicht.
Ich werde einen Vorschlag machen, evtl in wiki, mal sehen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 07 Mai 2016, 09:34:49
Also, ich habe keinen Unterschied zu einem Teamleader des alten Teams, dort steht

Altes Team
Internals:
   DEF        11111201
   NAME       Rauchmelder_Team
   NR         211
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   device     TeamDev
   peerList   OG_Flur_RM,K_Party_RM,K_Waesche_RM,
   sdTeam     sdLead
   Readings:
     2016-02-19 16:58:07   eventNo         0C
     2016-02-19 16:58:07   level           1
     2016-05-06 17:29:12   peerList        OG_Flur_RM,K_Party_RM,K_Waesche_RM,
     2016-02-19 16:58:07   smoke_detect    none
     2016-05-06 17:29:12   state           off
     2016-02-19 16:57:57   teamCall        from TeamDev:1
     2016-02-19 16:58:07   trigger_cnt     12
   Helper:
     fkt        sdLead
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Role:
       chn        1
       vrt        1
     Tmpl:
Attributes:
   alarmDevice Sensor
   alarmSettings alarm7,|Rauchmelder_Team:.*smoke-Alarm.*|RauchAlarm|on
   devStateIcon off:general_ok *:secur_alarm
   group      Rauchmelder Teamleader
   icon       secur_smoke_detector
   model      virtual_1
   peerIDs    3BCCCC01,3BCF0601,3BCF1301,
   room       Rauchmelder,Überall
   webCmd     teamCall:alarmOn:alarmOff

TeamLeader SD2
Internals:
   DEF        11111301
   NAME       Rauchmelder_Team2
   NR         514
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   device     TeamDevSD2
   peerList   K_Treppe_RM2,OG_Anna_RM2,OG_Linus_RM2,K_Bastelkeller_RM2,OG_Schlafzimmer_RM2,OG_Maja_RM2,EG_Kueche_RM2,EG_Buero_RM2,EG_Wohnzimmer_RM2,
   sdTeam     sdLead
   Readings:
     2016-05-06 17:29:12   peerList        K_Treppe_RM2,OG_Anna_RM2,OG_Linus_RM2,K_Bastelkeller_RM2,OG_Schlafzimmer_RM2,OG_Maja_RM2,EG_Kueche_RM2,EG_Buero_RM2,EG_Wohnzimmer_RM2,
     2016-05-07 08:47:48   state           off
   Helper:
     fkt        sdLead
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Role:
       chn        1
       vrt        1
     Tmpl:
Attributes:
   alarmDevice Sensor
   alarmSettings alarm7,|Rauchmelder_Team2:.*smoke-Alarm.*|RauchAlarm|on
   devStateIcon off:general_ok *:secur_alarm
   group      Rauchmelder Teamleader
   icon       secur_smoke_detector
   model      virtual_1
   peerIDs    47316A01,47343701,487DB901,487EBB01,487F0B01,487F9B01,4882DA01,48F0F801,48FDC801,
   room       Rauchmelder
   webCmd     teamCall:alarmOn:alarmOff

Daher verstehe ich es nicht??
Dort ist Kein smokeDetect...

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 07 Mai 2016, 17:14:36
Werde ich prüfen. Ich habe einen alarm ausgelöst, der wird vom Team gemeldet. Damit wird er entsprechend verarbeitet. Da ihr dies wahrscheinlich nicht gemacht habt kommt da auch nichts.
Ich werde wohl den zustand aller Mitglieder prüfen müssen um den zustand des Teams abzubilden.
Wenn ein alarm kommt sollte es funktionieren auch bei einem Test. Schon gedrückt?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 07 Mai 2016, 18:40:05
OK, dass wars!
Kommunikationstest durchgeführt, jetzt steht da auch smokeDetect!
Ist etwas verwirrend.
Danke!

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 08 Mai 2016, 09:07:43
Ist es richtig, dass beim Reichweitentest ein "smoke-Alarm" im notify erscheint?
Bei mir ist beim Reichweitentest nun der volle Alarm an SMS, WhatsApp, etc rausgegangen, da
das notify: .*smoke-Alarm.* gegriffen hat!

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 08 Mai 2016, 12:14:17
Bin gerade am überarbeiten. Es sind noch Funktionen des alten SD genutzt worden insbesondere wenn man den virtuellen lead genutzt hat.
Kommt heute noch ein Update.

so, ist eingechecked
Hier auch mein Vorschlag für ein Template welches den Repeater steuert.

set hm templateDef sd2Rep repeat "SD2 setup repeater (1) or not (0)" devRepeatCntMax:p0
set hm templateSet sd4 sd2Rep 0 0
set hm templateSet sd5 sd2Rep 0 1

also sd4 ohne, sd5 mit repeater.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 09 Mai 2016, 21:26:04
ich nehme schwer an, dass das diesmal RFChannel::performCBCAuthentification(BidcosFrame&) (https://forum.fhem.de/index.php/topic,20121.msg136834.html#msg136834) ist (siehe rfd aus alter CCU2-FW).
Hallo Michael,

Treffer :D Ich kann jetzt zumindest bestätigen dass Martins Beispiel mit dem Default-Key und dem CBC Mechanismus signiert wurde. Fraglich sind weiterhin die Bytes "00 03" vor der Signatur. Sie sind Teil des IV, aber werden ansonsten soweit ich das sehe nicht ausgewertet. Key-Nummer find ich daher fraglich. Aber mangels weiterer Beispiele und Hardware muss der Rest der Analyse warten.

Besten Gruß, Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 09 Mai 2016, 22:52:19
Hi Marcel,

Treffer :D Ich kann jetzt zumindest bestätigen dass Martins Beispiel mit dem Default-Key und dem CBC Mechanismus signiert wurde.

Super, klasse :-)

Zitat
Fraglich sind weiterhin die Bytes "00 03" vor der Signatur. Sie sind Teil des IV, aber werden ansonsten soweit ich das sehe nicht ausgewertet. Key-Nummer find ich daher fraglich.

Ich nehme an, dass das ein Counter ist. Da gibts irgendwelche get/set CBC counter Methoden.

Zitat
Aber mangels weiterer Beispiele und Hardware muss der Rest der Analyse warten.

Ich kann Beispiele liefern, die sind aber mit meinem Key signiert...
Kannst Du mir bitte evtl. den Algorithmus zukommen lassen (oder irgendwo beschreiben)? :-)

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 10 Mai 2016, 01:36:30
Kannst Du mir bitte evtl. den Algorithmus zukommen lassen (oder irgendwo beschreiben)? :-)
Hallo Michael,

alles klar, ich hab meine Arbeit jetzt mal hier beschrieben: http://www.kilgus.net/2016/05/10/homematic-cbc-authentication/ (http://www.kilgus.net/2016/05/10/homematic-cbc-authentication/). Der Algorithmus steht für Ungeduldige am Ende ;)

Viel Spaß, Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 10 Mai 2016, 09:49:26
Oh,
klingt gut und hört sich an, als gäbe es bald eine Lösung zum Problem....

@martin876:  Das Repeater template verstehe ich nicht. Gibt es dazu noch eine Beschreibung?
Was ist mit "Template gemeint" ?
Hier auch mein Vorschlag für ein Template welches den Repeater steuert.

Code: [Auswählen]

set hm templateDef sd2Rep repeat "SD2 setup repeater (1) or not (0)" devRepeatCntMax:p0
set hm templateSet sd4 sd2Rep 0 0
set hm templateSet sd5 sd2Rep 0 1
also sd4 ohne, sd5 mit repeater.
Stellt man damit über FHEM den Templatemodus ein und aus und kann ihn überwachen??


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 10 Mai 2016, 10:12:34
Hallo Marcel,

alles klar, ich hab meine Arbeit jetzt mal hier beschrieben: http://www.kilgus.net/2016/05/10/homematic-cbc-authentication/ (http://www.kilgus.net/2016/05/10/homematic-cbc-authentication/). Der Algorithmus steht für Ungeduldige am Ende ;)

Wow, super. Vielen Dank :-)

Ich habe das ganze mal schnell implementiert und ein paar Tests durchgeführt, wobei ich einen TeamCall auslösen und beenden konnte.

Dabei habe ich festgestellt, dass die zwei Bytes vor dem Ciphertext definitiv ein Replay-Counter sind. Meine SD-2 reagieren auf Kommandos nur, wenn der Counter höher als der zuletzt gesehene Counter eines Absenders (der in diesem Fall im Empfänger-Feld steht) ist.

Ich habe mal meine Perl-Implementierung angehängt, evtl. kann Martin da Teile übernehmen.

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 10 Mai 2016, 10:38:30
Dabei habe ich festgestellt, dass die zwei Bytes vor dem Ciphertext definitiv ein Replay-Counter sind. Meine SD-2 reagieren auf Kommandos nur, wenn der Counter höher als der zuletzt gesehene Counter eines Absenders (der in diesem Fall im Empfänger-Feld steht) ist.
Gut, das deckt sich dann mit der Zeile if (iv <= this->AesCbcCounter) return 0; und macht auch Sinn. Die Frage ist dann natürlich wie man den Counter bootstrapt. Z.B auch wenn ein neuer SD-2 zur Gruppe hinzugefügt wird. Der muss ja dann auch wissen welche Zahl gerade aktuell ist.
Die CCU2 sichert den Wert in RFChannel::SaveToXml als "aes_cbc_cnt", der Initialwert wird im RFChannel Constructor auf "1" gesetzt, das dürfte vermutlich aber eh irgendwann überschrieben werden. Der Rest ist dummerweise nicht so einfach zu lesen und jetzt steht leider erstmal wieder bezahlte Arbeit an ;) Vielleicht hast Du ja noch ne Idee.

Viele Grüße, Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 10 Mai 2016, 12:12:52
Hi,

Die Frage ist dann natürlich wie man den Counter bootstrapt. Z.B auch wenn ein neuer SD-2 zur Gruppe hinzugefügt wird. Der muss ja dann auch wissen welche Zahl gerade aktuell ist.

Ich denke, dass alle Geräte sich den letzten Wert der bekannten Absender merken. Damit ist das Bootstrap-Problem gelöst, ich konnte von meiner Zentralen-ID mit Counter-Wert 0 das erste Frame erfolgreich senden, danach musste ich inkrementieren.

Die anderen Geräte der Gruppe waren schon bei Counterwerten >= 3 und haben trotzdem meine Befehle akzeptiert.

Zitat
Die CCU2 sichert den Wert in RFChannel::SaveToXml als "aes_cbc_cnt", der Initialwert wird im RFChannel Constructor auf "1" gesetzt, das dürfte vermutlich aber eh irgendwann überschrieben werden.

So etwas muss Fhem jetzt wohl auch machen. Es muss sich einen globalen Replaycounter (in der VCCU?) für eigene zu sendende Frames merken und die zuletzt gesehenen Werte der einzelnen Geräte in den jeweiligen Geräten.

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Depechem am 10 Mai 2016, 13:36:18
Hallo @all.
Ich wollte die programmierer unter euch mal fragen.

Wird es auf absehbare Zeit(oder überhaupt) möglich sein die Alarme der SD-2 per FHEM zu quittieren(abzuschalten). So bin ich es von den SD gewöhnt und dies finde ich optimal.
Ich muss mir die nächsten 2 Wochen 3 neue Rauchmelder besorgen. Wenn möglich sollte der funktionsumfang mit fhem und dem Rauchmleder ähnlich dem alten SD sein.

Vielen Dank im voraus
Gruß Thomas
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 10 Mai 2016, 13:52:07
Hi,

Ich denke, dass alle Geräte sich den letzten Wert der bekannten Absender merken. Damit ist das Bootstrap-Problem gelöst, ich konnte von meiner Zentralen-ID mit Counter-Wert 0 das erste Frame erfolgreich senden, danach musste ich inkrementieren.

Anscheinend muss der Counter nur inkrementiert werden, wenn die gleiche Nachricht (mit gleicher EventID, Byte 2 der Payload) nochmals gesendet wird.

Dies hier war ein echter SD2 (in dem Fall der Team Leader):

2016-05-10 13:25:16.407: 13 03 14 41 4901F5 4901F5 01030000 0002 572DF464 (Sensor, AES: good, key: ...)
2016-05-10 13:28:02.629: 13 04 14 41 4901F5 4901F5 01049600 0002 2847ACD8 (Sensor, AES: good, key: ...)
2016-05-10 13:29:33.028: 13 05 14 41 4901F5 4901F5 01050000 0002 A7471FE5 (Sensor, AES: good, key: ...)
2016-05-10 13:35:24.478: 13 06 14 41 4901F5 4901F5 01060000 0002 311E758D (Sensor, AES: good, key: ...)

EDIT: Scheint ein Generationszähler zu sein. Nach einem Reboot des SD2 wurde der Counter inkrementiert:

2016-05-10 14:49:36.081: 13 01 14 41 4901F5 4901F5 01019600 0003 730ECE47 (Sensor, AES: good, key: ...)

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 10 Mai 2016, 20:06:01
Ich denke, dass alle Geräte sich den letzten Wert der bekannten Absender merken.
Also sendet jeder SD-2 jetzt mit seiner eigenen ID? Beim alten war es doch so dass alle die ID des Teams hatten, oder hab ich das falsch verstanden? (Hab bisher weder alt noch neu)

Zitat
Anscheinend muss der Counter nur inkrementiert werden, wenn die gleiche Nachricht (mit gleicher EventID, Byte 2 der Payload) nochmals gesendet wird.
Auch das stimmt mit meinem Code überein, da dort das EventID Byte als LSB mitgerechnet wird.

Zitat
EDIT: Scheint ein Generationszähler zu sein. Nach einem Reboot des SD2 wurde der Counter inkrementiert:
Und dann hatte auch nur dieser eine den neuen Zähler oder haben sich alle anderen angepasst?

Viele Grüße, Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 10 Mai 2016, 23:42:37
Hi,

Also sendet jeder SD-2 jetzt mit seiner eigenen ID? Beim alten war es doch so dass alle die ID des Teams hatten, oder hab ich das falsch verstanden? (Hab bisher weder alt noch neu)

Jein. Die neuen (alte habe ich auch nicht, daher weiss ich es nicht) senden mit ihrer ID als Empfänger und der Adresse des Teamleaders als Absender. Wahrscheinlich aus Stromspargründen.

Zitat
Und dann hatte auch nur dieser eine den neuen Zähler oder haben sich alle anderen angepasst?

Nur der eine.

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 11 Mai 2016, 09:03:37
SDS im Team senden "im Namen des Teams" Alarme u.ä.
Daher ist bei alarm oder teamcall der Absender das Team. Das Telegramm ist ein broadcast oder Multicast, somit müssen alle Empfänger prüfen ob sie betroffen sind. Die Empfängeradresse ist erst mal egal.
Nun wird die Empfängeradresse doch gesetzt um zu erkennen, wer es war. SDS machen damit m.w. nichts, oder kaum etwas. Die zentrale kann aber auswerten wer es war.

Das Verfahren ist identisch zu den alten SDs.

Mit Strom sparen hat es nichts zu tun sonder rein mit dem Protokoll. Im Prinzip ist das bei allen anderen Aktoren/Sensoren identisch. Ein Sensor sendet einen Multicast mit seiner Adresse und alle Aktoren prüfen, ob einer ihrer Kanäle aktiv werden müsste. Anders wäre ein longpress zum dimmen mehrerer aktores durch einen Sender nicht simultan möglich.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 11 Mai 2016, 11:00:59

hier nein paar Beispiele für das AES.

m:13 1441 AFFE02 490215 01139600000307B9ACB4
m:13 1441 AFFE02 490215 011397000003B38503F6
m:14 1441 AFFE02 490215 0114960000034916089C
m:14 1441 AFFE02 490215 011497000003019AAC82
m:15 1441 AFFE02 490215 011596000003AEF83F38
m:15 1441 AFFE02 490215 011597000003506AA539
m:12 1441 AFFE02 44E347 011200000004962684B4
m:01 1441 490215 490215 010196000004D4F59F69
m:02 1441 490215 490215 01020000000420D35D9A
m:03 1441 490215 490215 01039600000423B66907
m:04 1441 490215 490215 010400000004B647AFB8
m:05 1441 490215 490215 01059600000407EED62D
m:06 1441 AFFE02 490215 01069700000443DCC4D0
m:07 1441 AFFE02 490215 010796000004D8E22421
m:07 1441 AFFE02 490215 0107970000049D6F0DDE
m:08 1441 AFFE02 490215 010896000004F354B58F
m:08 1441 AFFE02 490215 010897000004A402E38F
m:09 1441 AFFE02 490215 01099600000447DA9DDB
m:0A 1441 AFFE02 490215 010A0000000417F1482F
m:0B 1441 AFFE02 490215 010B96000004A87B4A2A
m:0C 1441 AFFE02 490215 010C00000004A5D9D5C5
m:13 1441 AFFE02 44E347 01139600000421A4BFA4
m:13 1441 AFFE02 44E347 011397000004FF7C48E8
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 15 Mai 2016, 13:51:15
Hallo,

im Anhang mal eine erste Implementierung der AES CBC-Signatur in 10_CUL_HM.pm. Funktioniert soweit, dass ich aus Fhem einen TeamCall ausloesen kann, Alarm habe ich nicht getestet (Sonntag...).

Problem ist noch der Generationencounter, der muesste irgendwo (pro Team/global/?) gespeichert werden und immer beim Ueberlauf der msgNo bzw. beim Fhem-Neustart inkrementiert werden. Was passiert, wenn der Counter bei 65535 ankommt, weiss ich nicht...

EDIT: Habe gerade eine Idee fuer den Generationencounter, Anhang nochmals entfernt
EDIT2: Generationencounter als Reading aesCBCCounter implementiert, wird nur inkrementiert, wenn es wirklich sein muss
EDIT3: Aufruf von CUL_HM_parseSDteam_2 hinzugefuegt

Viele Gruesse
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 15 Mai 2016, 14:32:59
im Anhang mal eine erste Implementierung der AES CBC-Signatur in 10_CUL_HM.pm. Funktioniert soweit, dass ich aus Fhem einen TeamCall ausloesen kann, Alarm habe ich nicht getestet (Sonntag...).
Super. Hatte diese Woche leider keine Zeit mehr mich mit dem Thema zu beschäftigen, aber das Prinzip des Teams (Toll, Ein Anderer Macht's) hat sich mal wieder bestätigt  :P

Cheers, Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 18 Mai 2016, 20:45:55
Wird es bald eine über UPDATE abrufbare Version für den SD2 geben?

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 18 Mai 2016, 21:10:48
Ja. Habe schon einmal getestet. Noch ein paar Kleinigkeiten.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 20 Mai 2016, 18:59:26
ist eingecheckt - testet einmal
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 20 Mai 2016, 19:33:31
Hallo Martin,

ist eingecheckt - testet einmal

Danke :-)

Das hier erscheint mir falsch:
my $msg = "++1441$dst${dst}01${tstNo}9600";
...
my $msg = "++1441$dst${dst}01$tstNo${p}00";

Grund: Du setzt den Absender auf den Team-Leader und signierst die Nachricht. Alle anderen Geräte im Team merken sich den neuen Counter und akzeptieren keine Nachrichten vom "echten" Teamleader mehr (wenn er ein reales Gerät ist und sein Counter kleiner als der der Zentrale ist).

Ich denke, die einzige Chance Nachrichten abzusetzen und kein anderes Gerät auszuschliessen ist es, die Nachrichten unter der ID der Zentrale zu versenden und nicht unter der ID des Teams, also:

my $msg = "++1441$dst${id}01${tstNo}9600";
...
my $msg = "++1441$dst${id}01$tstNo${p}00";

Sonst werden evtl. echte Alarmmeldungen von den anderen Teamteilnehmern nicht mehr akzeptiert.

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 20 Mai 2016, 20:46:14
Hi,

kann man sich nun über UPDATE die Änderungen holen?
Nach UPDATE war aber alles wie bisher.
Ein druck auf teamCall odder alarmOn brachte jeweils eine Fehlermeldung ("Unknown argument teamCall, choose one of peerChan postEvent p ...")

@mgernoth: Nach dem Wiki sollte der TeamLeader aber ein virtuelles Gerät sein. Damit gäbe es dieses Problem doch nicht.
                     Und zumindest beim SD brauchte der TeamLeader nicht aktiv zu werden beim Alarm. Es wurde einfach die ID des TeamLeaders genommen, damit die TeamID individuell ist. Alle Geräte hörten dann auf diese ID.


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 20 Mai 2016, 22:38:27
Update geht morgen, heute svn direkt.

Bei de. Adressen steht als Absender die teamid drin wenn es ein Teamkommando ist.
Als Empfänger der steht das sende device drin.  Das ist bei SDs so.
Die Kommandos koennen nur vom teamlead ausgelöst werden, da sie nur dort eingetragen sind.
Also ist source und dest identisch. Das ist auch bei physikalischen SDs so. Also erst einmal alles korrekt. Die ID kommt nie rein, es sei denn der lead ist dein io oder die vccu.

Hast du das mit den msgcou tern getestet? Aus gutem Grund das Kommando nicht vorhanden.
Fuer mich steht eigentlich gleich ausser Frage, dass man einen virtuellen teamlead nehmen sollte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 20 Mai 2016, 23:15:32
Hallo Martin,

Bei de. Adressen steht als Absender die teamid drin wenn es ein Teamkommando ist.
Als Empfänger der steht das sende device drin.  Das ist bei SDs so.

Ja.

Zitat
Die Kommandos koennen nur vom teamlead ausgelöst werden, da sie nur dort eingetragen sind.
Also ist source und dest identisch. Das ist auch bei physikalischen SDs so. Also erst einmal alles korrekt. Die ID kommt nie rein, es sei denn der lead ist dein io oder die vccu.

Dann dürfen bei den SD2 keine physikalische Teamleads erlaubt werden, da dann der physikalische Leader keine korrekten Nachrichten mehr senden kann, die von den anderen Teammitgliedern akzeptiert werden. Dies ist die Replay-Protection des AES-CBC-Verfahrens!

D.h. wenn ich einmal einen Testalarm per Fhem auslöse, wird der nächste echte Alarm des Teamleaders von den Mitgliedern ignoriert werden!

Wir dürfen hier auf gar keinen Fall die Adresse eines physikalischen Gerätes als Absender (im Empfängerfeld) haben, da sonst echte Alarme untergehen!

Zitat
Hast du das mit den msgcou tern getestet?

Ja

Zitat
Aus gutem Grund das Kommando nicht vorhanden.

Bei mir hat es problemlos funktioniert, die Messages (allerdings habe ich nur Teamcall getestet) mit der ID meiner VCCU im Empfängerfeld abzusenden und alle Teammitglieder haben reagiert.

2016-05-15 17:30:13.219: 13 0C 14 41 4901F5 68EA13 01019600 0005 D6990152 (Sensor, AES: good, key: ...)

4901F5 ist die Adresse meines physikalischen Teamleads (und damit die Teamadresse), 68EA13 die meiner VCCU.

Zitat
Fuer mich steht eigentlich gleich ausser Frage, dass man einen virtuellen teamlead nehmen sollte

Wenn der Teamlead virtuell ist, dann ist es kein Problem, da die ID keinem realen Gerät entspricht.
Falls dem nicht so ist, dürfen aber auf keinen Fall Nachrichten mit der ID des physikalischen Leaders signiert werden!

Mir war nicht klar, dass ich auf jeden Fall einen virtuellen Lead benutzen sollte...

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 21 Mai 2016, 08:57:13
Ok, verstanden. Da hast du sicher recht und es kann so nicht bleiben, da es sich herheitsrelevant ist.
Koennte auch auf den alten SD zutreffen.
Ich werde es durchsehen und die entsprechenden readings überprüfen.

Ich für meinen Teil käme nicht auf die Idee ohne virtuellen lead zu arbeiten - wenn das Team aus mehr als einem besteht. Symetrie, Struktur und Wartung.... nee. Nur um ein virtuelles device zu sparen. Wenn virtuelle device eine Berechtigung haben dann hier.
Aber natürlich kann man anderer Ansicht sein

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 21 Mai 2016, 10:54:39
Ok, verstanden. Da hast du sicher recht und es kann so nicht bleiben, da es sich herheitsrelevant ist.
Koennte auch auf den alten SD zutreffen.
Ich werde es durchsehen und die entsprechenden readings überprüfen.

Danke :-)

Zitat
Ich für meinen Teil käme nicht auf die Idee ohne virtuellen lead zu arbeiten - wenn das Team aus mehr als einem besteht. Symetrie, Struktur und Wartung.... nee. Nur um ein virtuelles device zu sparen. Wenn virtuelle device eine Berechtigung haben dann hier.
Aber natürlich kann man anderer Ansicht sein

Ich muss zugeben, mir keine grossen Gedanken gemacht zu haben. Ich habe einfach das Wiki (teilweise) gelesen und da wird am Anfang der Weg mit einem physikalischen Lead beschrieben. Den Punkt mit dem virtuellen Lead habe ich dann uebersprungen...

Ich werde hier jetzt auch auf virtuell wechseln.

Danke & Viele Gruesse
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 21 Mai 2016, 11:49:37
Trotzdem sollte die Gefahr eines nicht weitergegebenen Alarms beachtet werden!
Es gibt bestimmt noch mehr,die einen physischen lead haben, entgegen der Empfehlung.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 21 Mai 2016, 16:35:01
Zitat
Trotzdem sollte die Gefahr eines nicht weitergegebenen Alarms beachtet werden!
sagte ich schon - keine Kompromisse bei sicherheitsrelevanten Komponenten.
Ich haben es eingecheckt.
Ich sehe es dennch kritisch - habe es nicht komplett durchschaut.
Beobachtung bei Teamcall: der "alte" Zähler war auf 15, ich habe einen reboot gemacht. Mein Zähler (virtueller Lead) startet wieder bei " 0". Die SDs ignorieren die message bis ich 15 mal gesendet habe. Dann ist die testnummer wieder höher als die letzte korrekte.
Ich sehe das generell kritisch. Gut, dass man den SD nicht die Bat entnehmen kann, dann würde er mit 0 beginnen. Die ersten Alarme würden vom Team ignoriert.
Sollte man den SD reseten könnte es zu Problemen kommen.
Was hat sich eQ3 hier wohl gedacht?

Übrigens? Kommandos an das Team kosten extrem IO-performance. Das sind 6 Bursts. Mit teamcall kann man schnell eine Überschreitung der erlaubtern Sendetokens erreichen.
Also sparsam nutzen (macht eh kaum sinn).

neue Version ist in SVN
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 21 Mai 2016, 17:21:41
Lässt sich der counter nicht persistent speichern? Attribut oder so?
Sonst ist nach einem Update Essig...

Wann wird es als normales update hochgeladen?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 21 Mai 2016, 17:51:29
als erstes empfehle ich noch einmal dringender als normal virtuelle Teamleads zu nutzen. Dann lässt man die Devices in ruhe und kann hoffen, das eQ3 keine Lücken in der Spec hat.
Problematisch wäre dann nur noch das senden eines Alarms vom virtuellen SDLead.
Das kann man testen - Kopfhöher nicht vergessen beim Testen!
Den test kannst du einfach durchführen.

Die MsgNummer zu speichern ist nur begrenzt möglich. Mit etwas Glück klappt es, wenn ich es als Reading speichere. Sollte der Grund des restarts ein Absturz sein hilft dies aber nicht.
Weiter ist unklar, wie "scharf" HM die entscheidung macht. Es schein mir sinnlos auf genau deinen höheren Wert zu setzen. Im Übrigen muss der Wert auch einmal keiner sein, nach 255 wäre sonst schluss.

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 21 Mai 2016, 18:03:07
und zur Info: habe bei Stand cnt 19 einen reboot gemacht. Der Teamcall hat mit 01 begonnen und funktioniert.

Da bleibt viel zu testen- wer Lust hat. Ich könnte mir vorstellen, dass der Zähler nicht mit einem der  letzten 10 Werte übereinstimmen darf.
Also wenn der Zäher 25 ist sind alles Werte 16 bis 25 tabu. Viel Spass beim testen :)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 22 Mai 2016, 01:18:37
Hallo Martin,

neue Version ist in SVN

Danke, sieht gut aus :-)
(Bis auf die Fehler, die noch von mir stammen).

Im Anhang noch ein Patch, der das Zusammenspiel mit virtuellen TeamLeads fixed (Keys und HM_CMDNR aus DeviceHash) und eine Warning von mir behebt.

Damit die definierten AES-Keys gefunden werden, muss die IOgrp des virtuellen Geraets eine evtl. definierte VCCU enthalten.

Sollte nicht der hoechste definierte Key genutzt werden, kann der entsprechende Schluesselindex im Attribut aesKey des virtuellen Geraets angegeben werden (das fuehrt im Moment aber noch zu der Meldung: aesKey illegal for virtual devices).

Martin: Schau Dir bitte den Patch mal an und pushe ihn ins SVN, falls er OK ist.

Danke & Viele Gruesse
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 22 Mai 2016, 14:04:24
Hi noch eine Verständnisfrage,

nach einem Neustart von FHEM, werden da vom TeamLead aus Infos von den SD2 gelesen/angefordert?
Ich vermute dies, da zunächst einige Geräte auf Missing ACK stehen. Nach einigen Mintuten geht es wieder.

Wäre wichtig zu wissen, da eine Abfrage jedes Mal Batteriepower kostet, und die Dinger ja nicht gerade günstig sind.
Leere Batterie=neues Gerät = ca. 50 Euro !
Sollten doch 10 Jahre halten, die Geräte.

Gibt es noch etwas, was man beachten sollte in Bezug auf die Lebensdauer der Batterie??

Das Log zeigt
CUL_HM set EG_Kueche_RM2 statusRequest
2016.05.22 14:05:16 3: wetter_gymnich: Read callback: request type was update retry 0, no headers, body empty,
Error: read from http://api.wunderground.com:80 timed out
2016.05.22 14:05:17 3: CUL_HM set EG_Wohnzimmer_RM2 statusRequest
2016.05.22 14:05:18 3: CUL_HM set Garagentor statusRequest
2016.05.22 14:05:19 3: CUL_HM set K_Bastelkeller_RM2 statusRequest
2016.05.22 14:05:20 3: CUL_HM set K_Party_RM statusRequest
2016.05.22 14:05:21 3: CUL_HM set K_Treppe_RM2 statusRequest
Lässt sich der statusRequest unterbinden?
Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 22 Mai 2016, 14:20:13
2 Stück CR17450E ca. 12€ und ein Lötkolben  ;D
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 22 Mai 2016, 14:41:51
autoreadreg abschalten.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 22 Mai 2016, 17:50:24
Hallo,

also autoReadReg steht wie bei den SD auf 5_readMissing. Ganz aus macht doch keinen Sinn, oder?

@M_I_B: Ist das wirklich so einfach zu tauschen? Dachte die Batts wären im Gehäuse fest. Wenn ein Lötaustausch möglich ist und die Dinger (CR17450E) normal zu bekommen ist ja super!
               Also das geht?

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 22 Mai 2016, 17:52:47
... ja, das geht problemlos. Scroll mal bis auf die ersten Seiten zurück. Dort habe ich bebildert beschrieben, wie man das Ding zerlegt und an die einzelnen Bauteile dran kommt ...

https://forum.fhem.de/index.php/topic,35298.msg437627.html#msg437627
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 22 Mai 2016, 17:58:13
1) ja, der Status wird nicht mehr automatisch gelesen wenn man autoReadReg komplett ausschaltet. StatusRequst ist der geringste Level.
Es ist deine Entscheidung, ob du nach einem Restart den Status aller Devices prüfen willst.

2) die Änderungen habe ich eingebaut. Danke.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 22 Mai 2016, 19:26:09
Hallo Martin,

2) die Änderungen habe ich eingebaut. Danke.

Danke :-)

War es Absicht, dass ein temCall jetzt nur noch einmal gesendet wird? Darauf reagieren meine SD2s nicht...

Danke & Viele Gruesse
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 22 Mai 2016, 19:47:43
nein, war ein test. sorry.
 meine hatten reagiert ... aber ich habe einen repeater eingestellt. Das verfahren ist nicht wirklich transparent.

6 mal burst kostet einiges an IO performance. nun ja, so offt wird man den Alarm nicht auslösen.
da fällt mir ein - nicht getestet:
Device a löst einen alarm aus und wir senden AlarmOff von Device B (Zentrale). da sollen die Pieper ... nun ja nicht ausgehen - oder doch?....
muss ich mal nachdenken. Evtl brauchen  wir einen AlarmOffForce?
na besser es tutet. Typisch muss man den Alarm am auslösenden Device abschalten - was sinn macht.
Aber eine Zentrale darf alles - da sitzt jemand der weiss was er tut :)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 23 Mai 2016, 17:35:09
... öhem ...
Ich habe jetzt die ganze Zeit mitgelesen, aber natürlich in der Masse nur Bahnhof verstanden. Was ich glaube verstanden zu haben ist, das man keinen RM als Leader nutzen darf, sondern nur den Virtuellen in FHEM, oder?

Hab ich auch so, wobei allerdings ein RM als Repeater geschaltet ist (geht nicht anders). Wenn ich jetzt im Virtuellen einen AlarmON absetze, reagiert ausschließlich der als Repeater geschaltete RM; alle anderen schweigen.
Soll das so? Oder lässt sich das momentan nicht ändern? Oder habe ich irgend wo was überlesen, was noch zu machen ist?

Korrektur:
Nach vielen Versuchen (bis Frauchen den Drohblick aufsetzte :o ) war in 70% der Fälle nur der als Repeater geschaltete RM am Quaken, in 20% jener im Keller, in 10% beide. Der RM im WZ zeigte sich bei allen Versuchen als einsamer Schweiger ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 23 Mai 2016, 20:09:34
Das sollte definitiv nicht so sein und ist auch nicht verständlich.
A) man kann einen sd als lead nutzen, auch wenn es mir grundsätzlich widerstrebt.
B) wenn du einen alarm auslöst und der mit repeater jault sollten es auch alle member in seinem Bereich tun. Sollte fhem einen Fehler machen( sehe ich aktuell nicht) müsste das repeaten dies korrigieren. Völlig unklar.
C) lege alle SDS nebeneinander und teste. Ich nutze dazu ein Kissen um die Frau gnädig zu stimmen. Sollten alle piepen ist erst einmal alles grundsätzlich ok. Dann kommen die Reichweitetests.
D) probiere teamcall. Achtung: neuste Version nutzen, da zwischendurch ein bug eingebaut wurde. Das geht ohne Geräusch.
E) der ultimative Test ist, den teamcall oder den alarm der Reihe nach von jedem ( in worten: jedem) sd auslösen und jeweils alle auf Empfang prüfen. Anders kannst du nicht sicherstellen, dass jeder auch alle erreicht.

Sollte es bei C Probleme geben dann beschreibe diese und Logge. Probiere dann auch D.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 23 Mai 2016, 21:18:09
... jupp, dachte ich mir, dsa es so nicht sein soll; aber besser ich frag mal. Hätte ja sein können, das mit einem als Repeater irgendwas hakt.
Ich werde Deine Liste mal abarbeiten, aber nicht mehr heute. Die muss ich erstmal einsammeln und allen mal den SMD- Schalter verpassen, die hier schon lange rumliegen; bin ich noch schuldig (im Zusammenhang mit Batterie-Hack).

zu A: Stimme ich Dir zu. Wenn schon FHEM da ist, ist FHEM der Leader und sonst nix; zumindest meine Auffassung ...
zu B&C: ... kläre ich im Karton ... Reichweitentest ist aber ok; gerade gemacht.
zu D: Ok
zu E: Wie löse ich an einem RM einen TeamCall aus? Ich kann doch nur einen Alarm auslösen (Rauchstab) oder einen Test starten?!? Ein TeamCall geht doch nur aus Fhem heraus via virtuellen Leader?!? Jetzt bin ich verwirrt  :o
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 23 Mai 2016, 21:36:09
Teamcall steht in der Anleitung . Lang und kurz druecken oder so.
Wen. Alles klappt ist es die reichweite
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 24 Mai 2016, 14:17:38
zu E: Wie löse ich an einem RM einen TeamCall aus? Ich kann doch nur einen Alarm auslösen (Rauchstab) oder einen Test starten?!? Ein TeamCall geht doch nur aus Fhem heraus via virtuellen Leader?!? Jetzt bin ich verwirrt  :o

Teamcall steht in der Anleitung . Lang und kurz druecken oder so.

In der Anleitung ist der TeamCall als "Kommunikationstest" beschrieben.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 24 Mai 2016, 15:47:19
In der Anleitung ist der TeamCall als "Kommunikationstest" beschrieben.
Jupp, den Zusammenhang habe ich heute Morgen auch plötzlich herstellen können ;)

So... Kurz der noch ausstehende Hardware-Hack zum Thema "Schalter"...
Vorab... Inzwischen ist klar, wo für der Transistor ist. Der entlastet lediglich den Reed- Kontakt und schaltet seinerseits den RM an. Wenn man nämlich z.B. mit dem Lötkolben an den linken Kontakt des Reed kommt (neben den Batterien), schaltet der Transistor durch das eingestreute Brummen durch und den RM an...

Ansonsten passen prinzipiell beide bestellten Schalter (Reichelt: SS ESP101 und SS SMD402), wie man den Bildern entnehmen kann. Ich habe mich für die SMD- Variante entschieden. In beiden Fällen gilt: Schalter links (zu den Zellen) = ON / Schalter rechts (zur Rauchkammer) = OFF. Der Schalter ist dann problemlos mit einem Stift, Schraubendreher o.ä. durch den Schlitz zu erreichen.

Wie man den Trum auseinander bekommt, hatte ich ja bereits unter https://forum.fhem.de/index.php/topic,35298.msg437627.html#msg437627 beschrieben. Wer nicht weiß, wie man den Reed aus- und den Schalter einlötet, sollte es lieber lassen und wen fragen, der das drauf hat. Ich übernehme Garantie dafür, dsa der Hack bei allen meinen drei Rauchmeldern problemlos funktioniert, aber ich übernehme keine Garantie für Dritte.

Und nun die Bilder, die für sich sprechen sollten:
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 24 Mai 2016, 17:35:26
@Martin: ... ich bin jetzt mal der Reihe nach nach Deiner Liste vorgegangen. Dabei konnte ich feststellen, das auf einmal der RM Wohnzimmer im Gegensatz zu gestern auf den TeamCall (Reichweitentest) nicht mehr reagierte. Auch ein Alarm vom Leader kommt nur wie gestern Abend bei den beiden anderen RM an.
Also hab ich alles auf NULL gesetzt... definition raus aus FHEM, im Leader alle RM gelöscht, alle RM Factory, alle neu gepairt, jeden einzelnen neu mit dem Leader gepeert...
Pusteblume >:( Nun geht zwar der aus dem Wohnzimmer wieder, aber dafür zeigt der aus dem Schlafzimmer-Flur genau das Verhalten, wie vorher der aus dem Wohnzimmer.
Auch der WZ-RM hatte vorher nach einem GetConfig ständig mal "RESPONSE TIMEOUT:RegisterRead" o.ä. Probleme. Die sind bei dem jetzt weg, aber dafür jetzt beim SZ-RM vorhanden...

Also bei mir sieht es so aus, als wenn es mit zwei RM immer geht, aber sobald der Dritte hinzu kommt, klemmt es irgendwo ...

Nachtrag: Ich habe mal alle drei RM und den Leader ins gleiche Logfile schreiben lassen und meine Aktionen dokumentiert:
# TeamCall vom Leader
2016-05-24_19:50:04 Team_RM aesCBCCounter: 000038
# AlarmOff vom Leader
2016-05-24_19:50:24 KG_RM_FL smoke_detect: none
2016-05-24_19:50:24 KG_RM_FL off
2016-05-24_19:50:24 KG_RM_FL teamCall: from TeamDev:01
2016-05-24_19:50:24 EG_RM_WZ smoke_detect: none
2016-05-24_19:50:24 EG_RM_WZ off
2016-05-24_19:50:24 EG_RM_WZ teamCall: from TeamDev:01
2016-05-24_19:50:24 EG_RM_SF smoke_detect: none
2016-05-24_19:50:24 EG_RM_SF off
2016-05-24_19:50:24 EG_RM_SF teamCall: from TeamDev:01
2016-05-24_19:50:24 Team_RM aesCBCCounter: 000039
2016-05-24_19:50:24 Team_RM eventNo: 01
2016-05-24_19:50:24 Team_RM smoke_detect: none
2016-05-24_19:50:24 Team_RM off
2016-05-24_19:50:24 Team_RM teamCall: from TeamDev:01
# Ablauf Ende
2016-05-24_19:52:11 EG_RM_SF smoke_detect: none
2016-05-24_19:52:11 EG_RM_SF off
2016-05-24_19:52:11 EG_RM_WZ smoke_detect: none
2016-05-24_19:52:11 EG_RM_WZ off
2016-05-24_19:52:11 KG_RM_FL smoke_detect: none
2016-05-24_19:52:11 KG_RM_FL off
2016-05-24_19:52:11 Team_RM eventNo: 02
2016-05-24_19:52:11 Team_RM level: 0
2016-05-24_19:52:11 Team_RM smoke_detect: none
2016-05-24_19:52:11 Team_RM off
2016-05-24_19:52:46 Team_RM aesCBCCounter: 00003A
# TeamCall vom Leader
2016-05-24_19:53:39 KG_RM_FL smoke_detect: none
2016-05-24_19:53:39 KG_RM_FL off
2016-05-24_19:53:39 KG_RM_FL teamCall: from TeamDev:03
2016-05-24_19:53:39 EG_RM_WZ smoke_detect: none
2016-05-24_19:53:39 EG_RM_WZ off
2016-05-24_19:53:39 EG_RM_WZ teamCall: from TeamDev:03
2016-05-24_19:53:39 EG_RM_SF smoke_detect: none
2016-05-24_19:53:39 EG_RM_SF off
2016-05-24_19:53:39 EG_RM_SF teamCall: from TeamDev:03
2016-05-24_19:53:39 Team_RM aesCBCCounter: 00003B
2016-05-24_19:53:39 Team_RM eventNo: 03
2016-05-24_19:53:39 Team_RM smoke_detect: none
2016-05-24_19:53:39 Team_RM off
2016-05-24_19:53:39 Team_RM teamCall: from TeamDev:03
# AlarmOff vom Leader
2016-05-24_19:54:27 KG_RM_FL smoke_detect: none
2016-05-24_19:54:27 KG_RM_FL off
2016-05-24_19:54:27 KG_RM_FL teamCall: from TeamDev:04
2016-05-24_19:54:27 EG_RM_WZ smoke_detect: none
2016-05-24_19:54:27 EG_RM_WZ off
2016-05-24_19:54:27 EG_RM_WZ teamCall: from TeamDev:04
2016-05-24_19:54:27 EG_RM_SF smoke_detect: none
2016-05-24_19:54:27 EG_RM_SF off
2016-05-24_19:54:27 EG_RM_SF teamCall: from TeamDev:04
2016-05-24_19:54:27 Team_RM aesCBCCounter: 00003C
2016-05-24_19:54:27 Team_RM eventNo: 04
2016-05-24_19:54:27 Team_RM smoke_detect: none
2016-05-24_19:54:27 Team_RM off
2016-05-24_19:54:27 Team_RM teamCall: from TeamDev:04
# Ablauf Ende
2016-05-24_19:54:43 EG_RM_SF smoke_detect: none
2016-05-24_19:54:43 EG_RM_SF off
2016-05-24_19:54:43 EG_RM_WZ smoke_detect: none
2016-05-24_19:54:43 EG_RM_WZ off
2016-05-24_19:54:44 KG_RM_FL smoke_detect: none
2016-05-24_19:54:44 KG_RM_FL off
2016-05-24_19:54:44 Team_RM eventNo: 05
2016-05-24_19:54:44 Team_RM level: 0
2016-05-24_19:54:44 Team_RM smoke_detect: none
2016-05-24_19:54:44 Team_RM off
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 25 Mai 2016, 12:41:19
Hallo MIB,
wozu ist der einbau des Schalters notwendig?

Gruß
Ingo
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 25 Mai 2016, 14:29:38
... notwendig ist der nicht, aber praktisch, wenn man nicht zum Arbeiten am Tisch jedesmal die Deckenhalter mit abschrauben oder provisorisch mit ext. Magneten rumhampeln will.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: wolleboe-go@yahoo.de am 25 Mai 2016, 14:56:37
Hallo zusammen.
Ich versuche mir eine Pushnachricht vom neuen Rauchmelder schicken zu lassen.
Aber (state) ändert sich immer wenn er auslöst   (smoke-Alarm_03) mal 03 mal 05.
was kann ich da in notify für ein state schreiben?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 25 Mai 2016, 15:01:25
smoke-Alarm.*
zum Beispiel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 25 Mai 2016, 15:03:38
Hallo, 

smoke.*  reagiert auf alles, dass mit smoke beginnt.

Geht das alarm abschalten über die zentrale jetzt ohne Probleme?
Sind die updates jetzt im normalen update drin?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 25 Mai 2016, 16:21:00
Update: Geschafft ::)
Bei mir bekomme ich alle drei RM nur sauber ins FHEM, nachdem ich heute noch mal folgendes gemacht habe:


... nu gait dat ...

Die bisherige Vorgehensweise, also erst alle RM pairen und danach jeweils den Peer zum Leader klappt bei mir nicht ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: kvo1 am 25 Mai 2016, 23:35:59
Hallo Micha,
großen Dank das DU dies hier nochmal so gut zusammengefaßt hast, ich lese hier schon ne Weile mit und will mein 3er Pack
auch in Betrieb nehmen ! Dis mit dem Schalter find ick jut !  ;)

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 26 Mai 2016, 09:18:19
auch in Betrieb nehmen ! Dis mit dem Schalter find ick jut !  ;)
Ike och ;)
Danke für die Blumen. Solche Hardwaresachen sind halt meine Welt, wobei mir Röhren noch lieber sind  8)

Noch mal zum Thema TeamLeader:
Mit Erstaunen musste ich heute Morgen nach einem System- Neustart (Raspbian Update) feststellen, das ein Klick in FHEM auf TeamCall auf einen Fehler in FHEM lief :o :o
Nach kurzem Nachschauen stellte ich fest, das der Leader das gestrige Peering "vergessen" hatte; auch in der CFG standen die ID's der drei RM nicht drin... merkwürdig...
Also habe ich das Peering noch mal gemacht und nach jedem Peering zur Sicherheit noch mal "Save Config" geklickt. Es wurden zwar die ID's der RM in den Leader übernommen, aber nicht in die CFG eingetragen. Das musste ich dann per Hand machen.
Vielleicht liegt das daran, das ich nicht alles in der fhem.cfg abgelegt habe, sondern aus der fhem.cfg diverse andere CFG's per include einbinde. Obwohl solche Aktionen bei anderen Dingen funktionieren, klappt das an dieser Stelle auch nach mehreren Versuchen nicht.

... das nur mal so als Hinweis für jene, die ggf. auch aus Übersichtsgründen weitere CFG's per include einbinden ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 26 Mai 2016, 11:31:11
Das komplizierte Vorgehen kann ich nicht verstehen und denke es ist nicht notwendig. Das ganze Löschen und reseten.

Das erste ist immer das pairing - hier wie überall. Es ist hinreichend beschrieben. Beim SD kann man es prüfen indem man einen StatusRequest  ausführt. Der sollte beanwortet werden, alle Kommandos aus der Queue weg und ein CMDs_done in internals.  Ist nicht gepairt muss es wiederholt werden. Sollte es nicht klappten (device bereits gepairt mit einer anderen Zentrale) pairing wiederholen. Ein Löschen in FHEM ist unnötig - bestenfalls ein clear mshEvents.

Hat man gepairt und dies kontrolliert kann man peeren (teamen).
Team-mitglieder kennen nur einen Team-lead. Kennen sie diesen (reagieren auf TeamCall des Lead) ist alles prima. Am Device ist nichts mehr zu ändern - nicht löschen, nichts.
Reagiert es nicht ist es nicht im Team oder in einem anderen Team. Also getConfig und die peers kontrollieren. Steht etwas falsches drin muss der falsche Lead gelöscht werden!!! ein peering überschreibt den peer NICHT. Da nur einen eingetragen wird klappt ein peering also nicht. Es wird  nicht quitiert und es kommt zu Fehlermeldungen im Protokoll. Also - wie immer!!! - nach Konfigurationsaktionen einmal den Ablauf kontrollieren. get hm protoEvents ist dein Freund. set hm clearG msgEvents macht reinen tisch - könnte man vor dem Config testen.
Hat man mit getConfig kontrolliert dass der SD den korrekten Lead als peer eingetragen hat ist alles prima. Der SD solle auf teamCall reagieren  - ebenso reagieren andere Team-mitglieder auf "seinen" teamCall.

Virtueller Lead:
Der Virtuelle Lead kennt alle Mitglieder. Das macht die Kontrolle einfacher - hmInfo kann prüfen. ob alle gepeert sind (ich korrigiere es gerade noch einmal)
Natürlich muss man nach dem peeren en save machen. Ein virtueller Kanal speichert alles in Attributen (also die peers) - und die sind ohne save verloren.

Realer Lead:
der kennt keine TeamMember - nur den Lead (sich selbst). Kann auch nicht kontrollieren, wer da ist.

=> wildes löschen bei nicht-funktion ist nicht  notwendig. Man kann das sehr selektiv machen.
=> wenn einer nicht auf das Team hört liegt es an ihm. nicht am team (so dies funktioniert).


Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 26 Mai 2016, 12:31:13
... ja, das sagst Du :P
Ich hatte den Vorgang ja mehrmals wiederholt, wie es allgemein bekannt ist und von Dir auch eben beschrieben wurde. Auch die Kontrollen waren erst einmal unauffällig, bis eben auf immer genau einen, nämlich der zuletzt gepairte RM, der zwar sauber gepairt war, aber ständig bei z.B. getConfig mit allen möglichen Fehlermeldungen um die Ecke kam. Das war in allen 4 Versuchsreihen reproduzierbar.
Das komplette Löschen habe ich auch aus dem Grund getan, um für alle Versuche exakt die gleiche Grundlage zu schaffen. das sehe ich zumindest als notwendig an, wenn man denn eben genau die gleichen Grundlagen für jeden Versuch schaffen möchte. Ist m.E. auch nicht so problematisch, da mit ein paar Klicks und Copy&Past gesichert. Dsa geht auf jeden Fall deutlich schneller als über FHEM ...

Warum das peering nicht im Attribut des Leaders gespeichert wird, kann ich nicht sagen. Aber ich denke, das liegt ganz einfach daran, das der nicht in der fhem.cfg steht, sondern per include eingebunden wird. Bei anderen per include eingebundenen Sachen, seien es nun Aktoren oder Sensoren oder z.B. auch das DashBoard, funktioniert das Eintragen der geänderten Attribute allerdings.

Na, wie dem auch sei: Es tut ja jetzt wie es soll und ich kann meine Zicken per Mausklick um Aufmerksamkeit resp. Gehörprobe bitten ;D

So bald ich Zeit habe, werde ich FHEM eh auf einen 19" XEON verlagern, die hier noch auf Einbau ins Rack warten (die haben natürlich noch anderes zu tun; wäre sonst etwas überdreht ^^). Dann werde ich ja sehen, ob die doch manchmal unerklärlichen Probleme bei mir an meiner FHEM/RaspBian/RPi/SCC- Installation liegen, oder ob die dann in dieser oder ähnlicher Form auf dem "richtigen" Server auch auftreten...

PS: Ich meine mit Leader natürlich immer einen virtuellen Lead in FHEM; wir waren uns ja einig, das ein Hardware-Lead in der Konstrellation unschlau wäre ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 27 Mai 2016, 23:58:20
Moin,
hab mir grad die neu 10_CUL_HM aus dem SVN geladen und meine 6 neuen SD2 gepairt und mit einem Virtuellen TeamLead gepeert. Hat alles tip top funktioniert.

Mir ist nur aufgefallen, das der zuerst gepairte SD2 ein weiteres Device angelegt hat und das LOG voll mit diesen Meldungen war. Das Device hat den Namen 4C6CF9, der SD2 hat den Namen HM_4C6CF9. Nachdem ich 4C6CF9 gelöscht habe waren die LOG-Meldungen weg.


2016.05.27 22:56:06 2: CUL_HM Unknown device HM_4C6CF9 is now defined
2016.05.27 22:56:06 2: autocreate: define HM_4C6CF9 CUL_HM 4C6CF9
2016.05.27 22:56:06 2: autocreate: define FileLog_HM_4C6CF9 FileLog ./log/HM_4C6CF9-%Y.log HM_4C6CF9
2016.05.27 22:56:59 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:57:00 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:57:11 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:57:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:57:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:57:20 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:57:22 1: Error: 4C6CF9 has no TYPE
2016.05.27 22:57:37 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 7067.
2016.05.27 22:57:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:58:02 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:58:03 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:58:11 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:58:20 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.

Gruß
Ingo
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 28 Mai 2016, 18:34:52
Nachdem der TeamCall vom virtuellen Team-Lead aus nicht funktioniert, habe ich alle SD2's nochmal auf Werkseinstellungen zurück gesetzt und die Dev's in FHEM gelöscht. Dann alles nochmal neu gepairt... getConfig... und dann mit dem virt. Team-Lead gepeert... getConfig... alles ist so wie es soll. Der TeamCall vom virt.Team-Lead aus geht immer noch nicht. Zumindest zeigen die SD2's keine Reaktion - in den Readings der SD2's steht unter teamCall der virt.Team-Lead.


Der TeamCall von einem SD2 aus (Kommunikationstest laut Bed.Anleitung) funktioniert - alle anderen SD2's blinken grün.

Habe das ganze mal gesnifft:

erst mal der TeamCall von einem SD2 aus, mit anschließendem zurücksetzen:
2016.05.28 18:20:26.696 0: HMLAN_Parse: HMLANingo2 R:E4C6CF9   stat:0000 t:03FDBF57 d:FF r:FFB1     m:91 8400 4C6CF9 000000 1000AA4E455130343439373233CE000100
2016.05.28 18:20:31.778 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDD211 d:FF r:FFB2     m:08 1441 191919 4C6CF9 01089600000156B59D7C
2016.05.28 18:20:32.118 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDD4CC d:FF r:FFB2     m:08 1441 191919 4C6CF9 01089600000156B59D7C
2016.05.28 18:20:32.812 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDD787 d:FF r:FFB2     m:08 1441 191919 4C6CF9 01089600000156B59D7C
2016.05.28 18:20:33.517 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDDA43 d:FF r:FFB2     m:08 1441 191919 4C6CF9 01089600000156B59D7C
2016.05.28 18:20:34.215 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDDCFE d:FF r:FFB1     m:08 1441 191919 4C6CF9 01089600000156B59D7C
2016.05.28 18:20:35.026 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDDFB9 d:FF r:FFB0     m:08 1441 191919 4C6CF9 01089600000156B59D7C
2016.05.28 18:21:25.808 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FEA4EA d:FF r:FFB6     m:09 1441 191919 4C6CF9 010900000001316F54AE
2016.05.28 18:21:26.087 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FEA7A5 d:FF r:FFB0     m:09 1441 191919 4C6CF9 010900000001316F54AE
2016.05.28 18:21:26.786 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FEAA60 d:FF r:FFB7     m:09 1441 191919 4C6CF9 010900000001316F54AE
2016.05.28 18:21:27.486 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FEAD1B d:FF r:FFB8     m:09 1441 191919 4C6CF9 010900000001316F54AE
2016.05.28 18:21:28.184 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FEAFD6 d:FF r:FFB8     m:09 1441 191919 4C6CF9 010900000001316F54AE
2016.05.28 18:21:28.883 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FEB291 d:FF r:FFB8     m:09 1441 191919 4C6CF9 010900000001316F54AE

und dann ein teamCall von dem virt.TeamLead aus mit anschließendem alarmOff:

2016.05.28 18:22:11.048 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF5752 d:FF r:FFB4     m:0B 1441 191919 191919 010896000000BC568FC9
2016.05.28 18:22:11.684 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF59C7 d:FF r:FFB4     m:0B 1441 191919 191919 010896000000BC568FC9
2016.05.28 18:22:12.304 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF5C3B d:FF r:FFB4     m:0B 1441 191919 191919 010896000000BC568FC9
2016.05.28 18:22:12.932 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF5EAF d:FF r:FFB5     m:0B 1441 191919 191919 010896000000BC568FC9
2016.05.28 18:22:13.561 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF6124 d:FF r:FFB4     m:0B 1441 191919 191919 010896000000BC568FC9
2016.05.28 18:22:14.190 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF6399 d:FF r:FFB4     m:0B 1441 191919 191919 010896000000BC568FC9
2016.05.28 18:22:55.773 0: HMLAN_Send:  HMLANingo2 S:SF82CF370 stat:  00 t:00000000 d:01 r:F82CF370 m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:55.879 0: HMLAN_Send:  HMLANingo2 S:SF82CF3DA stat:  00 t:00000000 d:01 r:F82CF3DA m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:55.985 0: HMLAN_Send:  HMLANingo2 S:SF82CF445 stat:  00 t:00000000 d:01 r:F82CF445 m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:56.091 0: HMLAN_Send:  HMLANingo2 S:SF82CF4AF stat:  00 t:00000000 d:01 r:F82CF4AF m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:56.597 0: HMLAN_Send:  HMLANingo2 S:SF82CF6A9 stat:  00 t:00000000 d:01 r:F82CF6A9 m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:56.604 0: HMLAN_Parse: HMLANingo2 R:RF82CF370 stat:0002 t:00000000 d:FF r:7FFF     m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:56.703 0: HMLAN_Send:  HMLANingo2 S:SF82CF713 stat:  00 t:00000000 d:01 r:F82CF713 m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:57.038 0: HMLAN_Parse: HMLANingo2 R:RF82CF445 stat:0002 t:00000000 d:FF r:7FFF     m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:57.668 0: HMLAN_Parse: HMLANingo2 R:RF82CF6A9 stat:0002 t:00000000 d:FF r:7FFF     m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:58.204 0: HMLAN_Parse: HMLANingo2 R:RF82CF4AF stat:0002 t:00000000 d:FF r:7FFF     m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:58.924 0: HMLAN_Parse: HMLANingo2 R:RF82CF713 stat:0002 t:00000000 d:FF r:7FFF     m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:59.307 0: HMLAN_Parse: HMLANingo2 R:RF82CF3DA stat:0002 t:00000000 d:FF r:7FFF     m:0C 1441 191919 191919 010900000000760AD9AD

hier noch ein list von dem virt. TeamLead:

Internals:
   CFGFN
   DEF        19191901
   NAME       RM_TeamDev_Btn1
   NR         1509
   STATE      off
   TESTNR     9
   TYPE       CUL_HM
   chanNo     01
   device     RM_TeamDev
   peerList   Garage_SD2,Charly_Sz_SD2,Buero_SD2,Flur_og_SD2,Flur_eg_SD2,Flur_dg_SD2,
   sdTeam     sdLead
   Readings:
     2016-05-28 18:22:55   aesCBCCounter   00000C
     2016-05-28 18:22:56   eventNo         09
     2016-05-28 18:22:56   level           0
     2016-05-28 17:50:30   peerList        Garage_SD2,Charly_Sz_SD2,Buero_SD2,Flur_og_SD2,Flur_eg_SD2,Flur_dg_SD2,
     2016-05-28 18:22:56   smoke_detect    none
     2016-05-28 18:22:56   state           off
     2016-05-28 18:22:11   teamCall        from RM_TeamDev:08
     2016-05-28 18:10:37   trigger         Long_1
     2016-05-28 18:22:56   trigger_cnt     9
   Helper:
     BNO        1
     BNOCNT     1
     count      1
     fkt        sdLead2
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
       vrt        1
     Shadowreg:
     Tmpl:
Attributes:
   model      virtual_1
   peerIDs    4C6C3701,4C6CBC01,4C6CDE01,4C6CED01,4C6CF901,4C6FB901,
   room       __Geraete,__System
   webCmd     press short:press long

und von einem SD2:

Internals:
   CFGFN
   DEF        4C6CF9
   HMLANingo1_MSGCNT 38
   HMLANingo1_RAWMSG E4C6CF9,0000,007D63DC,FF,FFC2,9184004C6CF90000001000AA4E455130343439373233CE000100
   HMLANingo1_RSSI -62
   HMLANingo1_TIME 2016-05-28 18:20:26
   HMLANingo2_MSGCNT 31
   HMLANingo2_RAWMSG E4C6CF9,0000,03FDBF57,FF,FFB1,9184004C6CF90000001000AA4E455130343439373233CE000100
   HMLANingo2_RSSI -79
   HMLANingo2_TIME 2016-05-28 18:20:26
   IODev      HMLANingo1
   LASTInputDev HMLANingo2
   MSGCNT     69
   NAME       Flur_eg_SD2
   NR         1726
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:91 - t:00 s:4C6CF9 d:000000 1000AA4E455130343439373233CE000100
   peerList   RM_TeamDev_Btn1,
   protEvt_AESCom-ok 4 last_at:2016-05-28 17:50:14
   protLastRcv 2016-05-28 18:20:26
   protResnd  1 last_at:2016-05-28 17:50:14
   protSnd    23 last_at:2016-05-28 17:55:34
   protState  CMDs_done
   rssi_HMLANingo1 avg:-47 min:-47 max:-47 lst:-47 cnt:1
   rssi_at_HMLANingo1 avg:-52.39 min:-66 max:-48 lst:-62 cnt:30
   rssi_at_HMLANingo2 avg:-78.78 min:-82 max:-73 lst:-79 cnt:23
   Readings:
     2016-05-28 18:20:26   Activity        alive
     2016-05-28 17:50:14   CommandAccepted yes
     2016-05-28 18:20:26   D-firmware      1.0
     2016-05-28 18:20:26   D-serialNr      NEQ0449723
     2016-05-28 17:55:33   PairedTo        0x355867
     2016-05-28 17:52:26   R-pairCentral   0x355867
     2016-05-28 17:55:33   RegL_00.          02:01 0A:35 0B:58 0C:67 16:00 1F:00 00:00
     2016-05-28 17:50:14   aesCommToDev    ok
     2016-05-28 17:50:14   aesKeyNbr       00
     2016-05-28 17:33:19   alarmTest       ok
     2016-05-28 18:21:25   battery         ok
     2016-05-28 17:33:19   level           0
     2016-05-28 17:55:33   peerList        RM_TeamDev_Btn1,
     2016-05-28 17:33:19   recentStateType info
     2016-05-28 17:55:33   sdRepeat        off
     2016-05-28 17:33:19   smokeChamber    ok
     2016-05-28 18:22:56   smoke_detect    none
     2016-05-28 18:22:56   state           off
     2016-05-28 18:22:11   teamCall        from RM_TeamDev:08
     2016-05-28 18:21:25   trigLast        RM_TeamDev_Btn1:0
     2016-05-28 18:21:25   trig_RM_TeamDev_Btn1 0
   Helper:
     HM_CMDNR   145
     alarmNo    09
     cSnd       013558674C6CF900040000000000,013558674C6CF90103
     mId        00AA
     peerIDsRaw ,19191901,00000000
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4C6CF9,00,02,00
       nextSend   1464452426.71408
       prefIO
       rxt        0
       vccu
       p:
         4C6CF9
         00
         02
         00
     Mrssi:
       mNo        91
       Io:
         HMLANingo1 -60
         HMLANingo2 -79
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       Hmlaningo1:
         avg        -47
         cnt        1
         lst        -47
         max        -47
         min        -47
       At_hmlaningo1:
         avg        -52.4
         cnt        30
         lst        -62
         max        -48
         min        -66
       At_hmlaningo2:
         avg        -78.7826086956522
         cnt        23
         lst        -79
         max        -73
         min        -82
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HMLANingo1
   IOgrp      vccu:HMLANingo1
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,19191901,
   room       CUL_HM
   serialNr   NEQ0449723
   subType    smokeDetector
   webCmd     statusRequest


Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 28 Mai 2016, 19:58:57
Hallo,

erst mal der TeamCall von einem SD2 aus, mit anschließendem zurücksetzen:
2016.05.28 18:20:31.778 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDD211 d:FF r:FFB2     m:08 1441 191919 4C6CF9 01089600000156B59D7C

Die Nachricht ist mit dem Standardkey signiert.

Zitat
und dann ein teamCall von dem virt.TeamLead aus mit anschließendem alarmOff:
2016.05.28 18:22:11.048 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF5752 d:FF r:FFB4     m:0B 1441 191919 191919 010896000000BC568FC9

Die mit einem unbekannten Schluessel. Ist ein eigener Schluessel aktiv, wurde aber evtl. nicht per assignHmKey auf die SD2 uebertragen?

Viele Gruesse
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 28 Mai 2016, 20:33:11
Tjo, dass wars... nu läufts!

Danke!!

Hoffe ich hab das nicht im Thread überlesen... hab extra 2x gelesen, bevor ich gepostet hab...
gehört nicht hier her, aber es lässt mir nu keine Ruhe: Warum habe ich das bei anderen Device die auch AES nutzen (z.B. HM-SEC-KEY) nicht machen müssen?

Gruß
Ingo
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 29 Mai 2016, 22:16:00
Hi,

gehört nicht hier her, aber es lässt mir nu keine Ruhe: Warum habe ich das bei anderen Device die auch AES nutzen (z.B. HM-SEC-KEY) nicht machen müssen?

Da musst Du es auch machen, es "funktioniert" aber trotzdem, da die Geraete angeben, welchen Schluessel sie benutzen. Die KeyMatic fordert einfach immer Signaturen mit dem Standardschluessel an und HMLAN bzw. Fhem beantwortet die Signaturanfrage passend (siehe aesKeyNbr nach einer Schaltaktion/Configaenderung, wenn da 0 steht, wird der Standardkey verwendet).
Wenn Du einen eigenen Schluessel benutzt, muss dieser per assignHmKey bzw. HM-Software auf das Geraet uebertragen werden.

Viele Gruesse
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pataya am 02 Juni 2016, 11:31:07
Moin,

klappt alarmOn/Off nun oder ist das seitens EQ3 nicht realisierbar?
Wäre sonst fast dazu geneigt die HM-SEC-SD zu nehmen, allerdings haben die kein Fliegengitter, bzw. AES  ::)

Gruß
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 02 Juni 2016, 11:53:12
Moin,

klappt alarmOn/Off nun oder ist das seitens EQ3 nicht realisierbar?
Wäre sonst fast dazu geneigt die HM-SEC-SD zu nehmen, allerdings haben die kein Fliegengitter, bzw. AES  ::)

Gruß

das klappt!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pataya am 02 Juni 2016, 12:09:40
super, dann steht der Bestellung ja nichts im Wege 8)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 03 Juni 2016, 19:29:05
Hi,

ich würde jetzt gerne auch mal die Geschichte über die FHEM Zentrale testen.
Kann ich über diese "Fremdbefehle" etwas kaputt machen? Habe hier irgendwo gelesen, wenn der Counter falsch steht, werden Feuermeldungen von den anderen Geräten ignoriert?
Welche Gefahren bestehen, bestehen überhaupt welche?
Zumindest TeamCall und AlarmOff wollte ich über die Zentrale nutzbar machen...

AlarmOff um den Alarm generell zu deaktivieren, hab ihn auf einen Taster gelegt, und wenn nun im virtuellen Leader das Reading level > 198 ist, wird alarmOff gesendet....


Zusatzfrage: kann ich meinen eigenen AES-Key übertragen, oder gibt es dann Probleme??

Ich gehe davon aus, dass alle Neuerungen nun im "normalen" Update drin sind, oder muss ich sie mir von der Entwicklungsumgebung/SourceSafe ziehen??


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 03 Juni 2016, 22:09:58
Hi,

ich würde jetzt gerne auch mal die Geschichte über die FHEM Zentrale testen.
Kann ich über diese "Fremdbefehle" etwas kaputt machen? Habe hier irgendwo gelesen, wenn der Counter falsch steht, werden Feuermeldungen von den anderen Geräten ignoriert?
Welche Gefahren bestehen, bestehen überhaupt welche?
So wie ich das sehe, sind das alte Geschichten, die SD2 sind nun eingebunden und funktionieren.
Zitat
Zumindest TeamCall und AlarmOff wollte ich über die Zentrale nutzbar machen...
TeamCall und AlarmOff funktionieren.
Zitat
AlarmOff um den Alarm generell zu deaktivieren, hab ihn auf einen Taster gelegt, und wenn nun im virtuellen Leader das Reading level > 198 ist, wird alarmOff gesendet....
Den SD2 bei einem echten Alarm automatisch abzuschalten, wiederspricht meiner Meinung nach dem eigentlichen Sinn eines Rauchmelders!
Zitat
Zusatzfrage: kann ich meinen eigenen AES-Key übertragen, oder gibt es dann Probleme??
Du solltest bei HM einen eigenen AES-Key nutzen und nicht den vom Werk aus voreingestellten, der ist ist nämlich quasi der ganzen Welt bekannt und daher relativ sinnlos. Probleme gibt es meines Wissens nach nur, wenn du deinen neuen Schlüssel verlierst - also am besten auch außerhalb von FHEM sichern.

Zitat
Ich gehe davon aus, dass alle Neuerungen nun im "normalen" Update drin sind, oder muss ich sie mir von der Entwicklungsumgebung/SourceSafe ziehen??
jo, ist normaler Bestandteil von FHEM

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 Juni 2016, 08:04:31
Danke für die Antwort.

Bezog die Counterprobleme u.a. auf dieses Post:
https://forum.fhem.de/index.php/topic,35298.msg453091.html#msg453091

Wenn also ein SD resettet wird oder der Leader durch Neustart wieder bei 0 beginnt, werden die Befehle ignoriert!
Das Problem mit dem Counter besteht meines Wissens nach immer noch?! (martinp876) ??

Vielleicht könnte martin876 die noch möglichen Probleme/Risiken darstellen??


Muss ich eigenlich SIGN ON schalten, oder nutzt der SD2 immer den AES Key??

2 Rauchmelder zeigen an, dass sie mit der Zentrale geapairt sind, reagieren auchauf getConfig, aber bei assignAES laufen sie mit ERROR gegen die Wand??
Soll ich sie reseten und neu einbinden??
Internals:
   CUL0_MSGCNT 3
   CUL0_RAWMSG A0D83A61048F0F81DA46206010000::-59.5:CUL0
   CUL0_RSSI  -59.5
   CUL0_TIME  2016-06-03 12:56:43
   DEF        48F0F8
   HMLAN1_MSGCNT 27
   HMLAN1_RAWMSG R1A13E15F,0001,08EFC219,FF,FFC0,91A01048F0F81DA462011111130100000000
   HMLAN1_RSSI -64
   HMLAN1_TIME 2016-06-04 08:22:38
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     30
   NAME       EG_Buero_RM2
   NR         532
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:91 - t:10 s:48F0F8 d:1DA462 011111130100000000
   peerList   Rauchmelder_Team2,
   protCmdDel 2
   protLastRcv 2016-06-04 08:22:38
   protResnd  1 last_at:2016-06-04 08:23:05
   protResndFail 1 last_at:2016-06-04 08:23:10
   protSnd    5 last_at:2016-06-04 08:23:03
   protState  CMDs_done_Errors:1
   rssi_HMLAN1 cnt:1 lst:-53 min:-53 avg:-53 max:-53
   rssi_at_CUL0 max:-47.5 avg:-51.5 min:-59.5 cnt:3 lst:-59.5
   rssi_at_HMLAN1 lst:-64 cnt:23 min:-69 avg:-62.82 max:-61
   Readings:
     2016-06-02 23:02:40   Activity        alive
     2016-06-04 08:08:34   CommandAccepted yes
     2016-05-12 19:54:56   D-firmware      1.0
     2016-05-12 19:54:56   D-serialNr      NEQ0243833
     2016-06-04 08:22:37   PairedTo        0x1DA462
     2016-05-08 22:44:01   R-pairCentral   0x1DA462
     2016-06-04 08:22:37   RegL_00.          02:01 0A:1D 0B:A4 0C:62 16:00 1F:00 00:00
     2016-06-04 08:08:34   aesCommToDev    ok
     2016-06-04 08:08:34   aesKeyNbr       00
     2016-06-03 12:56:43   alarmTest       ok
     2016-06-03 12:56:43   battery         ok
     2016-06-03 12:56:43   level           0
     2016-06-04 08:22:38   peerList        Rauchmelder_Team2,
     2016-06-03 12:56:43   recentStateType info
     2016-06-04 08:22:37   sdRepeat        off
     2016-06-03 12:56:43   smokeChamber    ok
     2016-06-04 08:23:10   state           MISSING ACK
   Helper:
     HM_CMDNR   146
     cSnd       011DA46248F0F800040000000000,011DA46248F0F80103
     mId        00AA
     peerIDsRaw ,11111301,00000000
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +48F0F8,00,00,00
       nextSend   1465021358.58842
       rxt        0
       vccu       vccu
       p:
         48F0F8
         00
         00
         00
       prefIO:
         HMLAN1
     Mrssi:
       mNo        91
       Io:
         HMLAN1     -62
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1465021358.50547
       ack:
         HASH(0x37d4208)
         9180021DA46248F0F800
     Rssi:
       Hmlan1:
         avg        -53
         cnt        1
         lst        -53
         max        -53
         min        -53
       At_cul0:
         avg        -51.5
         cnt        3
         lst        -59.5
         max        -47.5
         min        -59.5
       At_hmlan1:
         avg        -62.8260869565217
         cnt        23
         lst        -64
         max        -61
         min        -69
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   actCycle   099:00
   actStatus  alive
   autoReadReg 5_readMissing
   devStateIcon off:general_ok *:secur_alarm
   event-on-change-reading .*
   expert     2_raw
   firmware   1.0
   group      Rauchmelder EG
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,11111301,
   room       CUL_HM,Rauchmelder
   serialNr   NEQ0243833
   subType    smokeDetector
   webCmd     statusRequest



Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 04 Juni 2016, 09:21:57
Hast du ein
set <SD2> assignHmKey
gemacht?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 04 Juni 2016, 11:03:48
Hallo,

Wenn also ein SD resettet wird oder der Leader durch Neustart wieder bei 0 beginnt, werden die Befehle ignoriert!
Das Problem mit dem Counter besteht meines Wissens nach immer noch?! (martinp876) ??

Die SD haben einen 16bit Generationenzähler, der Teil des Counters ist und bei jedem Reboot erhöht wird. Er überlebt auch einen Factory-Reset. Wenn man einen SD allerdings 65536 mal bootet ist wahrscheinlich Schluss.

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 Juni 2016, 11:31:39
Ja, ich habe im Device auf set assignHmKey gedrückt. Bei allen 7 SD2 hats geklappt, nur 2 SD2 sperren sich. Ich bekomme dann immer ein MissingAck ?

Wie muss ich weiter vorgehen???


Ich habe einen auch mal resettet und neu eingebunden.
getConfig funktioniert auch ohne Fehler...

TeamCall kommt auch bei den betreffenden Devices an und sie führen ihn aus!



Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 04 Juni 2016, 14:37:18
Wenn dein TeamCall läuft und ein getConfig auch, dann geht doch quasi alles...

wäre es evtl. möglich, dass du beim Testen deinen HMlan in den Overload treibst?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 Juni 2016, 16:47:06
Denke nicht, was nicht geht ist das assignHmKey, das läuft auf ein missing ack, ein getConfig danach geht aber, daher denke h nicht overload.

Reicht es bei sd2 aus nur den aes zu übertragen, da sie eh immer mit aes übertragen?

Ich bekomme akso meinen Key nicht auf die zwei sd2.
Interessant, wie die jetzt reagieren, wenn ein sd auslöst und ja meinen aes hat...

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 04 Juni 2016, 17:25:40
Also wenn der TeamCall funktioniert, dann wird mit AES wohl alles in Ordnung sein und der Key ist schon ordnungsgemäß übertragen worden.

Ich hab bei mir grad auch nochmal assignHmKey gemacht - endet auch in einem missing ACK... Ob das nun aus irgendwelchen Gründen logisch oder aber ein Fehler ist, kann ich dir auch nicht sagen.
Meine SD2 funktionieren auf jeden Fall alle, TeamCall geht von jedem Melder und dem Virtuellen TeamLead aus. Ein richtiger Probealarm steht mangels Rauch noch aus - wird aber folgen...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 05 Juni 2016, 10:13:23
Na ja, könnte ja auch der "alte" AES Key sein. Also sicher bin ich nicht, dass der übertragen wurde...
In anderen AES-Komponenten kommt dann nach dem Übertragen das Reading "aesKeyNbr 00" vor.
Das fehlt bei diesen SD2 komplett, daher gehe ich davon aus, dass der Key NICHT übertragen wurde!!

so nach einem reset ist jetzt auch hier aesKeyNbr drin.
Habe aber festgestellt, dass sich z.B. ein Fenstersensor beharrlich weigert, dies in seinen Readings anzuzeigen.
Scheint aber trotzdem zu funktionieren, da aes Comm immer als OK quittiert wird.

ABER: Missing Ack scheint an größeres Problem zu sein. Nach einem FHEM Neustart holt sich der Teamleader alle Infos seines Teams.
          Dabei fällt mir auf, dass mindestens immer ein SD2 dabei ist, der zunächst MissingAck meldet, später (einige Minuten) geht es dann....

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Depechem am 09 Juni 2016, 19:33:10
Hi ich muss jetzt auch noch mal nachfragen da ich nicht mehr ganz durchsehe?!
Ich besitzte seit einer ganzen Weile die alten SDs in FHEM bei denen auch Teamcall und Alarm OFF funkionieren.
Seit 1-2 Monaten habe ich auch 3 SD2 in FHEM eingebunden. Zu dieser Zeit funktionierte ja noch kein Teamcall und Alarm OFF/ON.
Laut diesem Forum soll dies jetzt angeblich auch funktionieren.
Die SD2 hatte ich einzeln und nicht untereinander gepaired. so hier:
set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set acto
wenn ich jetzt im FHEM unter dem SD2 Rauchmeldern Teamcall oder Alarm ON anwähle passiert aber nix!?

Was mache ich falsch?
Update Check bei fhem ist gemacht
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 09 Juni 2016, 21:12:59
Wenn fhem aktuell ist kann es nur an den AES keys liegen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Depechem am 09 Juni 2016, 21:28:25
Wenn fhem aktuell ist kann es nur an den AES keys liegen.

Was müsste ich da tun? Hab sie eigentlich nur angelegt und mit sich selbst gepairt
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 09 Juni 2016, 21:36:17
Hi ich muss jetzt auch noch mal nachfragen da ich nicht mehr ganz durchsehe?!
Ich besitzte seit einer ganzen Weile die alten SDs in FHEM bei denen auch Teamcall und Alarm OFF funkionieren.
Seit 1-2 Monaten habe ich auch 3 SD2 in FHEM eingebunden. Zu dieser Zeit funktionierte ja noch kein Teamcall und Alarm OFF/ON.
Laut diesem Forum soll dies jetzt angeblich auch funktionieren.
Die SD2 hatte ich einzeln und nicht untereinander gepaired. so hier:
set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set acto
wenn ich jetzt im FHEM unter dem SD2 Rauchmeldern Teamcall oder Alarm ON anwähle passiert aber nix!?

Was mache ich falsch?
Update Check bei fhem ist gemacht
deine Problembschreibung ist noch nicht so ganz durchsichtig.
Daher nehme ich jetzt mal an, dass du für die neuen SD2 keinen VirtuellenTeamLead hast.
Falls doch, hast du deine SD2 zumindest nicht mit diesem gepeert, da du ja mit dem oben genannten Befehl den SD2 mit sich selbst gepeert hast (du hattest gepairt geschrieben - ich nehme mal an, dass war ein Versehen). Somit ist wohl klar, dass du keinen TeamCall auslösen kannst, da du kein Team hast.

Also zum richtigen Vorgehen:

- SD2 mit FHEM pairen
- dem SD2 den aktuelle AES-Key zuweisen mit:set <SD2> assignHmKey- einen virtuellenTeamLead für die SD2 erstellen (wie im FHEM-WiKi zu HM-SEC-SD beschrieben)(einen VirtuellenTeamLead für den alten SD und den neuen SD2 gemeinsam verwenden funktioniert nicht)
- den VirtuellenTeamLead mit dem SD2 peeren, mit: set <virtTeamLead> peerChan 0 <SD2> single set actor
das wars.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 09 Juni 2016, 21:41:27
Was müsste ich da tun? Hab sie eigentlich nur angelegt und mit sich selbst gepairt
du hast nicht gepairt sonder gepeert

pairen ==> Verbindung zwischen dem Device und der Zentrale - in diesem Fall also dem SD2 und FHEM herstellen

peeren ==> z.B. den SD2 mit einem virtuellenTeamLead oder mit sich selbst verbinden

peeren und pairen ist nicht das gleiche! falls du die Begriffe nicht kennst, die sind im einsteiger wiki beschrieben
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Depechem am 11 Juni 2016, 21:44:37
deine Problembschreibung ist noch nicht so ganz durchsichtig.
Daher nehme ich jetzt mal an, dass du für die neuen SD2 keinen VirtuellenTeamLead hast.
Falls doch, hast du deine SD2 zumindest nicht mit diesem gepeert, da du ja mit dem oben genannten Befehl den SD2 mit sich selbst gepeert hast (du hattest gepairt geschrieben - ich nehme mal an, dass war ein Versehen). Somit ist wohl klar, dass du keinen TeamCall auslösen kannst, da du kein Team hast.

Also zum richtigen Vorgehen:

- SD2 mit FHEM pairen
- dem SD2 den aktuelle AES-Key zuweisen mit:set <SD2> assignHmKey- einen virtuellenTeamLead für die SD2 erstellen (wie im FHEM-WiKi zu HM-SEC-SD beschrieben)(einen VirtuellenTeamLead für den alten SD und den neuen SD2 gemeinsam verwenden funktioniert nicht)
- den VirtuellenTeamLead mit dem SD2 peeren, mit: set <virtTeamLead> peerChan 0 <SD2> single set actor
das wars.

Also das mit dem pairen und peeren hab ich verwechselt. Danke für die Info.
Natürlich habe ich als erstes mit fhem gepaired.
Da beim anschlagen eines Rauchmelders nicht gleichzeitig mehrere Rauchmelder  mit angehen sollen (da bei anschalgen eines Rauchmelders meine Sirene im ganzen Haus dröhnt) will ich nicht mehrere Rauchmelder mit einander im Team verbinden.
Deshalb dachte ich, das ich (wie bei den alten SD`s)  nur ein:
set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actormachen muss und ihn damit mit sich selbst peeren.
Bei den alten Rauchmeldern kann ich dann ein teamCall / alarmOn  / alarmOff ausgeben!

Nur bei den neuen funktioniert das nicht!?

Warum sollt eich unbedingt einen virtuellenTeamLead erstellen?
-dies würde gleichzeitig bedeuten das ich pro Rauchmelder einen neuen virtuellenTeamLead anlegen müsste, oder!? ( sonst springen alle gleichzeitig an oder?)

Ich habe mal einen virtuellenTeamLead erstellt:
define TeamDev CUL_HM 111111
set TeamDev virtual 1
rename TeamDev_Btn1 Team_Rauch_Thomas_Buero
und ein:
set Team_Rauch_Thomas_Buero peerChan 0 Rauch_Thomas_Buero single set actorgemacht.
In den Internals des Rauchmelders wird dann auch
peerList: Team_Rauch_Thomas_Bueroangezeigt.
Im Rauchmelder wird dann bei den "set" Befehlen kein alarmOff/On/teamCall mehr angezeigt
Wenn ich dann den Befehl:
set Team_Rauch_Thomas_Buero teamCalloder
set Team_Rauch_Thomas_Buero alarmOneingebe wird in den Readings des Rauchmelders folgendes angezeigt:
teamCall from TeamDev:02
Der Rauchmelder selber gibt aber keinerleih Ton von sich!?
Das gleiche ist bei alarmOn / Off

Brauch ich unbedingt den virtueller TeamLead und / oder was mache ich noch falsch!?

Vielen Dank im voraus
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 11 Juni 2016, 23:46:21
wenn du kein Team erstellen willst, dann mach es halt nicht...

Das du unbedingt einen virtuellenTeamLead erstellen sollst, habe ich nicht gesagt. Da aber in deiner Problembeschreibung nichts davon stand, dass du KEIN Team erstellen willst, bin ich davon ausgegangen, dass du es machen möchtest wie wahrscheinlich 99% aller Funkvernetzten-Rauchmelder-Nutzer...

Ich lese bei deinen Schritten nichts von 'set <SD2> assignHmKey' ohne das geht sicher nix - egal ob mit sich selbst gepeert oder mit dem virtTeamLead.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Depechem am 12 Juni 2016, 01:09:06
wenn du kein Team erstellen willst, dann mach es halt nicht...

Das du unbedingt einen virtuellenTeamLead erstellen sollst, habe ich nicht gesagt. Da aber in deiner Problembeschreibung nichts davon stand, dass du KEIN Team erstellen willst, bin ich davon ausgegangen, dass du es machen möchtest wie wahrscheinlich 99% aller Funkvernetzten-Rauchmelder-Nutzer...

Ich lese bei deinen Schritten nichts von 'set <SD2> assignHmKey' ohne das geht sicher nix - egal ob mit sich selbst gepeert oder mit dem virtTeamLead.

Danke für deine Geduld  :-[

Ok also muss für teamCall / alarmOn nicht zwingend ein virtuellenTeamLead erstellt werden. Dann muss es an etwas anderm liegen.
Die Readings des Rauchmelders werden im fhem akualisiert nur aus fhem ansprechen (teamCall alarmOff / On geht nicht)
Ja 'set <SD2> assignHmKey' habe ich bei den Rauchmeldern sowie jetzt auch beim TeamDev ausgeführt.
Also nur direkt 'set Rauch_Thomas_Buero assignHmKey' ohne irgend etwas dran zu hängen!?
Was mich dabei wundert das die Rauchmelder danach sofort in den MISSING ACK gehen
Wenn ich gleich danach ein statusRequest mache ist MISSING ACK wieder weg!?

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 12 Juni 2016, 08:29:46
dann musst du uns mal mehr Infos geben.
Einträge im LogFile - list vom Device.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 12 Juni 2016, 18:06:25
@martinp876 

Ist es korrekt, dass ein statusRequest bei den SD2 keine Events produziert?

nur ein:
2016-06-12 17:58:30.893 CUL_HM RM_TeamDev_Btn1 off
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Depechem am 14 Juni 2016, 13:29:02
dann musst du uns mal mehr Infos geben.
Einträge im LogFile - list vom Device.

hier das list. hilft dies weiter?

Internals:
   DEF        48F3EA
   HMUSB_MSGCNT 8
   HMUSB_RAWMSG R4EA5C7C6,0001,0D6F92F1,FF,FFB9,87A61048F3EA372DDE0601000043
   HMUSB_RSSI -71
   HMUSB_TIME 2016-06-14 13:22:16
   IODev      HMUSB
   LASTInputDev HMUSB
   MSGCNT     8
   NAME       Rauch_Keller_Eisenbahn
   NR         566
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:87 - t:10 s:48F3EA d:372DDE 0601000043
   peerList   self01,
   protCmdDel 2
   protIOerr  1 last_at:2016-06-11 22:45:14
   protLastRcv 2016-06-14 13:22:16
   protSnd    8 last_at:2016-06-14 13:22:16
   protState  CMDs_done
   rssi_HMUSB avg:-66.5 cnt:2 lst:-67 max:-66 min:-67
   rssi_at_HMUSB lst:-71 cnt:8 avg:-74.62 min:-83 max:-70
   sdTeam     sdLead
   Readings:
     2016-06-11 22:44:17   Activity        alive
     2016-05-13 11:53:37   CommandAccepted yes
     2016-05-13 12:13:59   D-firmware      1.0
     2016-05-13 12:13:59   D-serialNr      NEQ0244049
     2016-06-09 15:58:17   PairedTo        0x372DDE
     2016-05-13 11:50:19   R-pairCentral   0x372DDE
     2016-06-09 15:58:17   RegL_00.        02:01 0A:37 0B:2D 0C:DE 16:00 1F:00 00:00
     2016-05-13 11:53:37   aesCommToDev    ok
     2016-05-13 11:53:37   aesKeyNbr       00
     2016-06-14 13:22:16   alarmTest       ok
     2016-06-14 13:22:16   battery         ok
     2016-06-11 22:22:14   eventNo         04
     2016-06-14 13:22:16   level           0
     2016-06-11 22:44:17   peerList        self01,
     2016-05-13 12:11:57   powerOn         2016-05-13 12:11:57
     2016-06-14 13:22:16   recentStateType info
     2016-06-09 15:58:17   sdRepeat        off
     2016-06-14 13:22:16   smokeChamber    ok
     2016-06-11 22:22:14   smoke_detect    none
     2016-06-14 13:22:16   state           off
     2016-06-09 15:05:56   teamCall        from :00
     2016-05-13 12:14:09   trigLast        Rauch_Keller_Eisenbahn:150
     2016-05-13 12:14:09   trig_Rauch_Keller_Eisenbahn 150
     2016-05-13 12:14:09   trigger_cnt     1
   Helper:
     HM_CMDNR   135
     cSnd       01372DDE48F3EA010E,01372DDE48F3EA010E
     fkt        sdLead2
     mId        00AA
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +48F3EA,00,00,00
       nextSend   1465903336.22985
       prefIO
       rxt        0
       vccu
       p:
         48F3EA
         00
         00
         00
     Mrssi:
       mNo        87
       Io:
         HMUSB      -69
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMUSB
       flg        A
       ts         1465903336.17605
       ack:
         HASH(0x39d2b68)
         878002372DDE48F3EA00
     Rssi:
       Hmusb:
         avg        -66.5
         cnt        2
         lst        -67
         max        -66
         min        -67
       At_hmusb:
         avg        -74.625
         cnt        8
         lst        -71
         max        -70
         min        -83
Attributes:
   IODev      HMUSB
   actCycle   099:00
   actStatus  alive
   alarmDevice Sensor
   alarmSettings alarm7,|Rauch_Keller_Eisenbahn:smoke-Alarm_.*|Rauchmelder Keller Eisenbahn ausgelößt|on
   alias      Rauch Keller Eisenbahn
   autoReadReg 5_readMissing
   devStateIcon smoke-Alarm.*:message_presence@red off:message_presence@green
   expert     2_raw
   firmware   1.0
   group      T Rauchmelder
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,48F3EA01,
   room       Alarmanlage,Rauchmelder
   serialNr   NEQ0244049
   subType    smokeDetector
   webCmd     statusRequest
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Depechem am 14 Juni 2016, 13:33:28
und dies steht im Logfile wenn ich teamCall auslöße
2016.06.14 13:30:52.579 1: PERL WARNING: Argument "from" isn't numeric in sprintf at ./FHEM/10_CUL_HM.pm line 5143, <GEN245481> line 1.
2016.06.14 13:30:52.580 1: CUL_HM Rauch_Keller_Eisenbahn need Crypt::Rijndael to generate AES-CBC signature

Ein 'set Rauch_Thomas_Buero assignHmKey' ohne irgend etwas dran zu hängen habe ich gemacht!?
Was mich dabei wundert das die Rauchmelder danach sofort in den MISSING ACK gehen
Wenn ich gleich danach ein statusRequest mache ist MISSING ACK wieder weg!?

Dies wird dabei im Logfile angezeigt:
2016.06.14 13:44:02.840 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in regexp compilation at ./FHEM/10_CUL_HM.pm line 2738.
2016.06.14 13:44:04.818 1: PERL WARNING: Use of uninitialized value $mh{"devN"} in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 1291, <GEN246344> line 1.
2016.06.14 13:44:04.818 1: PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/10_CUL_HM.pm line 1294, <GEN246344> line 1.

Am Rauchmelder selbst kann ich einen teamCall Test auslößen(über Taste am RM) dieser teamCall wird im fhem auch angezeigt, nur anders herum nicht :-(
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 14 Juni 2016, 14:57:26
Klingt für mich, als hättest Du das modul nicht installiert.

Wenn FHEM AES können soll, muss es installiert sein!

Wiki:  http://fhemwiki.de/wiki/AES_Encryption

"Damit die AES-Kommunikation mit einem CUL genutzt werden kann, muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein."

Also auf dem Hostsystem das Modul installieren!
Also im Falle eines Raspi-Systems: sudo apt-get install libcrypt-rijndael-perl
(http://www.fhemwiki.de/wiki/Raspberry_Pi)



Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 14 Juni 2016, 15:00:38
und dies steht im Logfile wenn ich teamCall auslöße
2016.06.14 13:30:52.579 1: PERL WARNING: Argument "from" isn't numeric in sprintf at ./FHEM/10_CUL_HM.pm line 5143, <GEN245481> line 1.
2016.06.14 13:30:52.580 1: CUL_HM Rauch_Keller_Eisenbahn need Crypt::Rijndael to generate AES-CBC signature

Damit sollte die Frage beantwortet sein, das Paket Crypt::Rijndael fehlt, dieses Perl Modul musst du installieren.

nähers dazu auch hier: http://www.fhemwiki.de/wiki/AES_Encryption (http://www.fhemwiki.de/wiki/AES_Encryption)



Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Depechem am 14 Juni 2016, 15:23:36
Klingt für mich, als hättest Du das modul nicht installiert.

Wenn FHEM AES können soll, muss es installiert sein!

Wiki:  http://fhemwiki.de/wiki/AES_Encryption

"Damit die AES-Kommunikation mit einem CUL genutzt werden kann, muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein."

Also auf dem Hostsystem das Modul installieren!
Also im Falle eines Raspi-Systems: sudo apt-get install libcrypt-rijndael-perl
(http://www.fhemwiki.de/wiki/Raspberry_Pi)



Greets

Byte

Oh man genau daran lag es.
Vielen Dank nun geht alles!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: michaelapp am 14 Juni 2016, 16:36:13
Hallo zusammen,

ich habe vorhin versucht einen Baugleichen BOSCH OW3000 einzubinden welches auch ohne Probleme funktioniert hat.
Ich habe den Rauchmelden zum testen mit sich selbst gepeert.

Anschließend ist er auf MISSING ACK gegangen, nach einem Klick auf statusRequest ist MISSING ACK weg.

Internals:
   CFGFN
   DEF        34AB66
   HMLAN1_MSGCNT 26
   HMLAN1_RAWMSG R4F49E1A1,0001,01CAD10E,FF,FFCE,10A01034AB66123ABC060100002D
   HMLAN1_RSSI -50
   HMLAN1_TIME 2016-06-14 16:21:30
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     26
   NAME       HM_34AB66
   NR         236
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:10 - t:10 s:34AB66 d:123ABC 060100002D
   protCmdDel 1
   protLastRcv 2016-06-14 16:21:30
   protResnd  1 last_at:2016-06-14 16:19:40
   protResndFail 1 last_at:2016-06-14 16:19:46
   protSnd    26 last_at:2016-06-14 16:21:30
   protState  CMDs_done
   rssi_HMLAN1 max:-45 cnt:5 min:-50 lst:-45 avg:-47.6
   rssi_at_HMLAN1 cnt:26 max:-40 avg:-50.8 lst:-50 min:-59
   Readings:
     2016-06-14 16:06:57   Activity        alive
     2016-06-14 16:06:54   CommandAccepted yes
     2016-06-14 16:06:53   D-firmware      1.1
     2016-06-14 16:06:53   D-serialNr      LBO0162266
     2016-06-14 16:19:47   PairedTo        0x123ABC
     2016-06-14 16:06:57   R-pairCentral   0x123ABC
     2016-06-14 16:19:47   RegL_00.          02:01 0A:12 0B:3A 0C:BC 00:00
     2016-06-14 16:21:30   battery         ok
     2016-06-14 16:21:30   level           0
     2016-06-14 16:21:30   recentStateType info
     2016-06-14 16:21:30   state           off
   Helper:
     HM_CMDNR   16
     cSnd       01123ABC34AB66010E,01123ABC34AB66010E
     mId        0042
     peerIDsRaw ,00000000
     rxType     2
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +34AB66,00,00,00
       nextSend   1465914090.16536
       prefIO
       rxt        0
       vccu
       p:
         34AB66
         00
         00
         00
     Mrssi:
       mNo        10
       Io:
         HMLAN1     -48
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1465914090.08062
       ack:
         HASH(0x1029c88)
         108002123ABC34AB6600
     Rssi:
       Hmlan1:
         avg        -47.6
         cnt        5
         lst        -45
         max        -45
         min        -50
       At_hmlan1:
         avg        -50.8076923076923
         cnt        26
         lst        -50
         max        -40
         min        -59
     Shadowreg:
Attributes:
   IODev      HMLAN1
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.1
   model      HM-SEC-SD
   msgRepeat  1
   peerIDs    00000000,
   room       CUL_HM
   serialNr   LBO0162266
   subType    smokeDetector
   webCmd     statusRequest

Sagt State = off das er Offline ist oder wie muss ich das verstehen?

Dann noch eine Frage zum Batterie Status. Wir haben im Haus insgesamt 14 Stück verbaut und ich möchte auf die Battery ein Notify per Email Benachrichtigung legen. Kenn der Rauchmelder nur den Status  "OK" wenn die Batterie voll ist? oder gibt es noch nen anderen Status?

Gruß
Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 14 Juni 2016, 17:33:14
ich habe vorhin versucht einen Baugleichen BOSCH OW3000 einzubinden welches auch ohne Probleme funktioniert hat.
Der Bosch ist Baugleich zum HM-SEC-SD, in diesem Thread geht es allerdings um den Nachfolger.

Zitat
Sagt State = off das er Offline ist oder wie muss ich das verstehen?
Das heißt dass aktuell kein Alarm ist.

Gruß Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: michaelapp am 14 Juni 2016, 17:49:49
Hallo Marcel,

danke für die Info.

Ich habe gerade ein Notify auf die Batterie gesetzt um mir eine Email zu schicken wenn die Batterie leer ist.
Zum testen habe ich einfach mal den Status ok genutzt:

define Rauchmelder notify RM_DG_Sued_Lager:battery:OK {DebianMail('mail@apperger.de',$NAME.' ON',$EVENT);; }
Ich habe dann die Batterien vom Rauchmelder aus und eingebaut und gedacht das er sich wieder am FHEM meldet und somit die notify auslöst.
Kann es sein, das der Rauchmelder nach dem Batterietausch neu angemeldet werden muss?

Gruß
Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 14 Juni 2016, 18:35:44
Hallo Marcel,

danke für die Info.

Ich habe gerade ein Notify auf die Batterie gesetzt um mir eine Email zu schicken wenn die Batterie leer ist.
Zum testen habe ich einfach mal den Status ok genutzt:

define Rauchmelder notify RM_DG_Sued_Lager:battery:OK {DebianMail('mail@apperger.de',$NAME.' ON',$EVENT);; }
Ich habe dann die Batterien vom Rauchmelder aus und eingebaut und gedacht das er sich wieder am FHEM meldet und somit die notify auslöst.
Kann es sein, das der Rauchmelder nach dem Batterietausch neu angemeldet werden muss?

Gruß
Michael

neu anlernen: nein

dein notify reagiert auf ein 'OK' im Reading steht aber 'ok' und das klappt dann von wegen case sensitive nicht
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: michaelapp am 14 Juni 2016, 19:34:54
Hallo Marcel,

danke für den Hinweis :-)

define Rauchmelder notify RM_DG_Sued_Lager:battery:ok {DebianMail('mail@apperger.de',$NAME.' ON',$EVENT);; }
Sollte soweit aber gehen oder?

Ich habe die Batterien mal raus und reingemacht und habe gedacht somit kann ich notify testen. Leider ohne Erfolgt.

Ist das mit dem aus raus und reinmachen der Batterien nicht möglich oder ist mein notify nicht korrekt?

Gruß
Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 14 Juni 2016, 19:52:46
es muss halt ein passendes Event kommen, sonst löst das notify nicht aus... kannst ja mal im EventMonitor schauen ob etwas passiert wenn du die Batterien raus nimmst und wieder einlegst. Aber ich tippe mal das da kein Event mit battery kommt.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 14 Juni 2016, 21:39:51
Hi,

ich tippe eher darauf, dass Du dich ans Wiki gehalten hast und ein event-on-change .* gesetzt hast.
Da der Melder vermutlich bereits in FHEM mit Battery ok im Reading steht, reagiert er nicht mehr auf eine erneute Meldung!
Zum Test müsstest Du das event-on-change attribut entfernen!

Ansonsten sind HM-Geräte plaudertaschen und melden i.d.R. bei jedem mal ihren Batteriestatus!

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: michaelapp am 14 Juni 2016, 21:45:24
Hallo zusammen,

ich habe mir jetzt damit beholfen das ich ein event-on-update auf alles setzen und dann noch ein event-min-internal mit 60 Sekunden.

event-min-interval .*:60
event-on-update-reading .*

Funktioniert hervorragend :-)

Gruß
Michael



Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: cerberus am 14 Juni 2016, 23:00:30
Hallo, ist es möglich mal ein komplette Zusammenfassung für die Inbetriebnahme zu bekommen.

Wie oder was muss ich im virtuellen Teamleader oder der  VCCU  definieren um die AES für die RM´s zu nutzen?

Grüße
cerberus
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 14 Juni 2016, 23:10:06

Also zum richtigen Vorgehen:

- SD2 mit FHEM pairen
- dem SD2 den aktuelle AES-Key zuweisen mit:set <SD2> assignHmKey- einen virtuellenTeamLead für die SD2 erstellen (wie im FHEM-WiKi zu HM-SEC-SD beschrieben)(einen VirtuellenTeamLead für den alten SD und den neuen SD2 gemeinsam verwenden funktioniert nicht)
- den VirtuellenTeamLead mit dem SD2 peeren, mit: set <virtTeamLead> peerChan 0 <SD2> single set actor
das wars.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 14 Juni 2016, 23:39:40
Hallo zusammen,

ich habe mir jetzt damit beholfen das ich ein event-on-update auf alles setzen und dann noch ein event-min-internal mit 60 Sekunden.

event-min-interval .*:60
event-on-update-reading .*

Funktioniert hervorragend :-)

Gruß
Michael
dann kannst du auch einfach das event on change reading löschen...

event-on-update-reading hebelt ein event-on-change-reading ja wieder aus. und das event-min-interval verhindert, dass das Event öfter als 60 Sekunden kommt - die meißten Devices die regelmäßig senden, tun dies maximal alle 2-5 Minuten...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: michaelapp am 15 Juni 2016, 00:30:43
Hallo,

Du hast recht es kommen nicht mehr so viele notifys, aber trotzdem kommen noch ein paar durch :-(

Das event on change habe ich im Moment gar nicht implementiert.

Hast Du ne andere Idee?

Gruß
Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 15 Juni 2016, 06:26:36
@Cerberus
Zitat
Hallo, ist es möglich mal ein komplette Zusammenfassung für die Inbetriebnahme zu bekommen.

Wie oder was muss ich im virtuellen Teamleader oder der  VCCU  definieren um die AES für die RM´s zu nutzen?

M.E. nach sind die SD2 eine Ausnahme und nutzen IMMER AES. Wenn Du keinen eigenen Schlüssel definiert hast, nutzen Sie den Standardkey.
Bitte verbessern, wenn ich hier quatsch erzähle.

Alles zu AES findet man hier im Wiki: http://fhemwiki.de/wiki/AES_Encryption
Auf jeden Fall muss das Rijndael-Perl-Modul installiert sein.
Also im Falle eines Raspi-Systems: sudo apt-get install libcrypt-rijndael-perl
(http://www.fhemwiki.de/wiki/Raspberry_Pi)

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 15 Juni 2016, 06:33:45
@michaelapp

Im "Normalbetrieb" finde ich bei Homematic-Devices ein event-on-change .* sehr sinnvoll.
Ich möchte ja nur ein Notify bekommen, wenn sich etwas getan (also verändert) hat!
Ansonsten kenne ich den Zustand ja schon!!

Also immer wieder auf Battery ok  oder auf Window close  zu reagieren macht wohl keinen Sinn....

In Deinem Fall war es ja auch nur zu Testzwecken, ob das notify mit der Batterieüberwachung trifft...

Ein allgemeines
.*:[Bb]attery.* { if ($EVENT !~ m/ok/) {
      SendWhatsApp(1,'Batterieleer', $NAME.': '.$EVENT);
     Log3 $NAME, 3, "$NAME : Batteriewarnung $EVENT";
  }
 }

ginge auch und trift alle Geräte die Battery oder battery senden und im EVENT KEIN "ok" vorkommt!

Oder ein weiteres Beispiel, dass viele Sabotagealarme trifft:
.*:[Ss]abotage.* {
   if("$EVENT" !~ m/off/) {
       SendWhatsApp(1, $NAME.': '.$EVENT,'FHEM Sabotagealarm');
     }
 }


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: michaelapp am 17 Juni 2016, 17:56:06
@byte

gibt es eine feste Zeit wo sich der Rauchmelder am FHEM meldet also z.b alle 5 Stunden?

Wenn ich Deine notify benutze

define RM2 notify .*:[Bb]attery.* if {($EVENT !~ m/ok/) {DebianMail('mail@apperger.de',$NAME,$EVENT);;}}
erhalte ich folgende Fehlermelung im Log

2016.06.17 18:05:29 3: RM2 return value: Unknown command if, try help.Unknown command }, try help.
Gruß
Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 17 Juni 2016, 21:21:08
@byte

gibt es eine feste Zeit wo sich der Rauchmelder am FHEM meldet also z.b alle 5 Stunden?

Wenn ich Deine notify benutze

define RM2 notify .*:[Bb]attery.* if {($EVENT !~ m/ok/) {DebianMail('mail@apperger.de',$NAME,$EVENT);;}}
erhalte ich folgende Fehlermelung im Log

2016.06.17 18:05:29 3: RM2 return value: Unknown command if, try help.Unknown command }, try help.
Gruß
Michael

ich bin zwar nicht @byte, aber guck dir mal die klammern an... Die Fehlermeldung will sagen, dass sie das Command if nicht kennt...und das liegt an einer fehlenden { vor dem if...

EDITH sagt:
da fehlt ja quasi keine, die ist nur an der falschen Stelle... 'if' is ja schon Perl und muss daher in die geschweifte Klammer.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 17 Juni 2016, 22:35:46
So ist es. In meinem Beispiel Code ist sie vorhanden.
Ich finde es auch übersichtlicher es in mehrere Zeilen zu schreiben. Benutzer dazu Feb def Editor!

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: raspklaus am 23 Juni 2016, 13:49:03
Nachdem ich meine alten Rauchmelder nun gegen Homematic tauschen will, hier meine Frage:

Welche sollte man denn nehmen, die SD oder die SD-2 ?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto am 23 Juni 2016, 15:52:29
Zitat
Welche sollte man denn nehmen, die SD oder die SD-2

Warum noch die alten nehmen?

Die SD-2 laufen doch.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: budy am 08 Juli 2016, 11:28:57
…genau! Gerade gestern habe ich mit Hilfe des Wikis und dieses Threads, den ich vorher gelesen habe, 3 neue SD-2 problemlos in meinen FHEM integriert bekommen. Jetzt brauche ich noch mal drei für die Schlafzimmer und dann lasse ich es mal im Haus krachen… ;)

…und wenn die Familie morgens nicht aufstehen will…  :o

Gruß,
Stephan
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: budy am 09 Juli 2016, 15:58:52
…das einzige was nicht funktioniert ist tatsächlich, einen Alarm über den virtuellen TeamLead auszulösen. Das geht erst nachdem ich einen TeamCall über den TeamLead abgesetzt habe. Anschließend lässt sich ein Alarm auslösen - und auch wieder beenden.

Gruß,
Stephan
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: HoTi am 18 Juli 2016, 11:25:50
Hallo zusammen,

ich bekomme diese Verdammten Rauchmelder nicht ans Laufen mit FHEM. Es ist irgendetwas mit dem AES aber ich weiß nicht was ich da noch falsch mache.

Kann mir jemand einen Tipp geben? Ich habe mal Verbosen 5 und ein List von einem Rauchmelder gemacht:

2016.07.18 11:22:07 5: CUL_HM RM_Kinderzimmer protEvent:CMDs_pending pending:1
2016.07.18 11:22:07 3: CUL_HM set RM_Kinderzimmer statusRequest
2016.07.18 11:22:07 5: CUL_HM RM_Kinderzimmer protEvent:CMDs_processing... pending:0
2016.07.18 11:22:08 4: CUL_HM_Resend: RM_Kinderzimmer nr 2
2016.07.18 11:22:14 5: CUL_HM RM_Kinderzimmer protEvent:CMDs_done_Errors:1

Das List:
Internals:
   DEF        487FB9
   IODev      hmusb
   NAME       RM_Kinderzimmer
   NR         921
   NTFY_ORDER 50-RM_Kinderzimmer
   STATE      MISSING ACK
   TYPE       CUL_HM
   protCmdDel 4
   protResnd  3 last_at:2016-07-18 11:22:08
   protResndFail 3 last_at:2016-07-18 11:22:14
   protSnd    3 last_at:2016-07-18 11:22:07
   protState  CMDs_done_Errors:1
   sdTeam     sdLead
   Readings:
     2016-07-18 11:15:41   Activity        unknown
     2016-07-08 15:58:18   CommandAccepted yes
     2016-07-08 15:58:13   D-firmware      1.0
     2016-07-08 15:58:13   D-serialNr      NEQ0249591
     2016-07-08 15:57:28   PairedTo        0x000000
     2016-07-08 15:57:28   R-pairCentral   0x000000
     2016-07-08 15:57:28   RegL_00.        02:00 0A:00 0B:00 0C:00 16:00 1F:00 00:00
     2016-07-08 15:58:14   SDteam          add_HM_487FEA
     2016-07-08 15:58:18   aesKeyNbr       00
     2016-07-08 16:01:08   alarmTest       ok
     2016-07-08 16:01:08   battery         ok
     2016-07-08 16:25:28   eventNo         03
     2016-07-08 16:25:28   level           0
     2016-07-08 16:01:08   powerOn         2016-07-08 16:01:08
     2016-07-08 16:01:08   recentStateType info
     2016-07-08 15:58:18   sabotageAttackId_ErrIoId_487FEA cnt:4
     2016-07-08 15:58:18   sabotageAttack_ErrIoAttack cnt 4
     2016-07-08 15:57:28   sdRepeat        off
     2016-07-08 16:01:08   smokeChamber    ok
     2016-07-08 16:25:28   smoke_detect    none
     2016-07-18 11:22:14   state           MISSING ACK
   Helper:
     HM_CMDNR   4
     cSnd       012516B7487FB9010E,012516B7487FB9010E
     fkt        sdLead2
     mId        00AA
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +487FB9,00,00,00
       prefIO
       rxt        0
       vccu
       p:
         487FB9
         00
         00
         00
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Tmpl:
Attributes:
   IODev      hmusb
   actCycle   099:00
   actStatus  unknown
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,
   room       CUL_HM
   serialNr   NEQ0249591
   subType    smokeDetector
   verbose    5
   webCmd     statusRequest
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 18 Juli 2016, 11:31:59
2016-07-08 15:57:28   R-pairCentral   0x000000zumindestens hier war er nicht gepairt.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: cerberus am 21 Juli 2016, 19:24:19


Wo definiere ich den AESkey im virtuellen TeamLeader oder in der VCCU?

Grüße
cerberus
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 21 Juli 2016, 19:51:07
in der VCCU.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 25 Juli 2016, 08:33:24
... 24.07.2016 - Fehlalarm um 01:40 ...

Dabei sind folgende Merkwürdigkeiten aufgefallen:

Der laut LOG auslösender RM im Keller hat keinen Alarmton abgegeben und kein Notlicht eingeschaltet, wie es die beiden RM im EG taten. Dafür blinkte der auslösende RM hektisch rot. Ein Abschalten des Alarms war am auslösenden RM nicht möglich.

Die RM im OG funktionierten korrekt. Abschaltung über diese RM nicht möglich.

TeamLeader zeigte keinen Alarm mehr an, nachdem ich den Rechner erreicht hatte, da sich der Alarm nicht am RM löschen lies. Auch ein mehrfaches Senden von AlarmOFF über den TeamLeader half nicht, den Alarm zu löschen.

Da zwischenzeitlich meine Frauen und vor allem unsere Tiere langsam irre wurden, habe ich die RM alle abgeschaltet (SchalterHack) und bis zum Morgen li8egen lassen. Seit dem alles wieder normal...


@Martin: War es denn nicht mal von Dir so gemacht worden, das der TeamLeader das Sagen hat und ein Alarm vom TM zu löschen ist? Mir ist so als wenn mal gesagt wurde, das der TM der Master ist und der Anwender am Rechner wissen sollte, was er tut (oder so ähnlich).

Die zweite Frage ist natürlich, warum der auslösende RM keinen Laut von sich gegeben hat; funktionieren tut er und auch ein TeamCall wird brav gemeldet

Dritte Frage bezieht sich auf die Art der Alamierung: Mir war so, das ein TeamCall ein anderes Intervall hat wie ein "echter" Alarm, oder nicht? Hier zumindest unterscheiden sich beide Arten der Signalgebung nicht; 3 x Signal - Pause, 3 x Signal - Pause ...


2016-07-24_01:39:37 HM1RM1 smoke_detect: HM1RM3
2016-07-24_01:39:37 HM1RM1 smoke-Alarm_01
2016-07-24_01:39:37 HM1RM2 smoke_detect: HM1RM3
2016-07-24_01:39:37 HM1RM2 smoke-Alarm_01
2016-07-24_01:39:37 HM1RM3 battery: ok
2016-07-24_01:39:37 HM1RM3 smoke_detect: HM1RM3
2016-07-24_01:39:37 HM1RM3 smoke-Alarm_01
2016-07-24_01:39:37 HM1RM3 trigLast: Team_RM:198
2016-07-24_01:39:37 HM1RM3 trig_Team_RM: 198
2016-07-24_01:39:37 Team_RM eventNo: 01
2016-07-24_01:39:37 Team_RM level: 198
2016-07-24_01:39:37 Team_RM smoke_detect: HM1RM3
2016-07-24_01:39:37 Team_RM smoke-Alarm_01
2016-07-24_01:39:37 Team_RM trigger_cnt: 1
2016-07-24_01:39:42 HM1RM3 trigLast: Team_RM:199
2016-07-24_01:39:42 HM1RM3 trig_Team_RM: 199
2016-07-24_01:39:42 Team_RM trigger_cnt: 1
2016-07-24_01:42:26 HM1RM1 battery: ok
2016-07-24_01:42:26 HM1RM1 smoke_detect: none
2016-07-24_01:42:26 HM1RM1 off
2016-07-24_01:42:26 HM1RM1 trigLast: Team_RM:2
2016-07-24_01:42:26 HM1RM1 trig_Team_RM: 2
2016-07-24_01:42:26 HM1RM2 smoke_detect: none
2016-07-24_01:42:26 HM1RM2 off
2016-07-24_01:42:26 HM1RM3 smoke_detect: none
2016-07-24_01:42:26 HM1RM3 off
2016-07-24_01:42:26 Team_RM eventNo: 01
2016-07-24_01:42:26 Team_RM level: 2
2016-07-24_01:42:26 Team_RM smoke_detect: none
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 25 Juli 2016, 20:14:35
Lead ist nicht ganz korrekt. Ich glaube immee behauptet zu haben, dass es keinen lead gibt. Philoyophie ist, dass es ein komplett verteiltes system ist. Keines der devices hat eine sonderstellung.
Nun ja. Da sind beim sd2 schon einmal die repeater.
Und einer muss seine hmid hergeben um diese als teamid zu nutzen. Dieser wird als lead genutzt.
Da die hmid des lead genutzt wird um teamcall und alarm zu steuern werden die kommandos auch nur ueber diese entity ausgeloest.

Warum der sdkeller nicht hupt kann ich nicht sagen, wuerde aber mit zigarre in den keller gehen um das sicher zu stellen.
Ich werde am wochenende versuche machen. Von welchem sd man loeschen kann wenn ein alarm ansteht.
Ist mir aktuell unklar ob dies von jedem geht oder nur vom ausloesenden, oder dann nir lokal, oder.....
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 25 Juli 2016, 21:22:38
Jo, in der Anleitung steht:
Durch das Anlernen zweier oder mehrerer Rauchwarnmelder wird ein Funknetz gebildet. Der Rauchalarm eines Rauchwarnmelders im Netz wird dadurch automatisch an alle anderen Melder im Netz mit der gleichen Gruppenadresse weitergegeben.
....
Die ersten beiden Rauchwarnmelder im System definieren eine Gruppenadresse. Jeder weiter Rauchwarnmelder kann an einen beliebigen bereits im System befindlichen Rauchwarnmelder angelernt werden und erhält automatisch die vorab definierte Gruppenadresse.

!! Jeder Rauchwarnmelder innerhalb eines Systems muss jeden anderen Rauchwarnmelder des Systems und ggf. die Zentrale erreichen können.
...

7.3 Stummschaltung bei Alarm

Bei unerwünschten Alarmen kann der Alarm für 10 Minuten deaktiviert werden.
...
Der Alarm wird stumm geschaltet und die Rauchdetektion für 10 Minuten deaktiviert. Für die Zeit blinkt LED alle 10 Sek. rot. Eine Alarm-Stummschaltung bei Alarm führt zur Alarm-Deaktivierung bei allen über Funk vernetzten Rauchwarnmeldern, die keinen eigenen Alarm haben, d.h. keinen Rauch in der Rauchkammer. Rauchmelder mit eigenem Alarm können nur direkt am entsprechenden Gerät deaktiviert werden... .

Also sollte man über das virtuelle-Teammitglied (diese Bezeichnung pass wohl besser als TeamLead) alle Rauchmelder für 10 Minuten stumm schalten können, bis auf den, an dem der Alarm entstanden ist.

Von einem richtigen Team-Mitglied aus stellt man den Alarm mit einem kurzen Tastendruck ab.


Zu den Blinksignalen:

Rauchalarm lokal: rotes Blinekn und Notbeleuchtung mit anschließender LED-Nachlaufzeit von 24 h (30 min schnelles Blinken, anschließend doppeltes Blinken alle 43 s. Vorzeitige Beendigung des schnellen Blinkens ist durch Tastendruck möglich.)

Das würde ja das hektische Blinken erklären...

Das Verhalten liesse sich so erklären: Der Melder wurde durch "irgendwas" fehl ausgelöst und bis du bei dem Melder gewesen warst, lag dieser "Fehler" nicht mehr an. Daher kein Alarm und keine Notbeleuchtung mehr sondern nur noch das schnelle rote Blinken.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 26 Juli 2016, 00:31:09
@Martin: ... ich meinte auch den "Virtuellen" Leader. Da im Grunde kein RM den Leader macht sondern FHEM (auch wenn einer dafür seine ID hergeben muss), hatte ich es eben als TL bezeichnet...Aber gut... Das is wohl Haarspalterei ;)
Noch mal zu meiner Konfig: Der (pöse) RM im Keller, ein RM auf dem Flur im Schlaftrakt, ein RM im Durchgang WZ/EZ, welcher auch den Repeater macht, da sonst der im Schlaftrakt den im Keller nicht "hört".
Auslösen des Test funktioniert bei allen und alle bekommen es auch mit. Ebenso das Auslösen/Löschen aus FHEM über den TL. Daran sollte es also nicht liegen; da gab es bisher auch keine Störungen.
Den "Zigarrentest" mache ich mit den genormten Qualmstengeln für RM; hab noch ein paar aus der Vergangenheit (VdI- zertifizierte Räucherstäbchen  ;D ;D ::) ). Aber dafür muss ich immer Zeiten abpassen, wenn die Frauen, Hund und Katzen außer Haus sind, sonst ticken die aus; der WAF/PAF solch einer Aktion ist doch sehr gering...

@automatisierer: ... Deine Schlussfolgerung hatte ich zu erst auch, aber nach Rücksprache mit meinen Frauen war ich innerhalb 2 Minuten im Keller (da steht die meiste Technik, die qualmen kann...). Auch wenn der einen Fehlalarm hatte, so ist das doch immerhin ein Alarm, was ja auch die hektisch blinkende LED angesagt hat. Dennoch war Schweigen und Dunkelheit; sollte nicht sein...


@Allgemein: Ich werde das mal weiter beobachten. Vielleicht tragen wir mal alle gemeinsam solche "Fehlalarme" mit all den Begleitumständen zusammen, in der Hoffnung, da irgendwann einen Zusammenhang erkennen zu können ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 26 Juli 2016, 08:09:42
Der Begriff Teamleader provoziert offensichtlich immer wieder Fehlinterpretationen. Vielleicht sollte man einen anderen Begriff wählen?

Ich habe das System so verstanden:
Der sogenannte Teamleader gibt nur seinen Namen. Ansonsten wird er vom System als normaler Rauchmelder wargenommen!

Es beunruhigt mich nur der Fehlarlarm des SD2. Das Problem schien es beim SD auch schon mal gegeben zu haben. Damals wurde durch ein Softwareupdate mit Auslöseverzögerung gegengesteuert (m.E. schlechte Lösung, da ich eine frühe Warnung bevorzuge). Der SD2 soll ja ein Fliegengitter haben..


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 26 Juli 2016, 08:44:36
Der SD2 soll ja ein Fliegengitter haben..
... hat er. Innenleben ist gut auf den Bildern zum SchalterHack zu sehen ...

Na, warten wir mal, wie viele Meldungen über Fehlalarme es in Zukunft geben wird; ich bin ja da sicherlich nicht der Einzige auf der Welt ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 26 Juli 2016, 11:01:17
Tja, habe 9 sd2 und 3 sd.
Mal sehen, wann es mich erwischt..


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 26 Juli 2016, 12:05:37
Hallo zusammen,
meine 6 SD-2 hängen seit dem Wochenende. Davor waren zwei für mehre Wochen im Testbetrieb. Bisher keine Fehlalarme.
Christian
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: N4unch0rch am 29 Juli 2016, 16:50:59
Hallo zusammen. Ich habe insgesamt 8 RMs die ich einbinden will, es scheitert bei mir jedoch schon beim Ersten. Ich kann ich nicht gescheit pairen. Ich setzte den RM und FHEM in den Pairing-Modus und der RM schlägt im Event Monitor auf, schickt seine Daten und wird per AutoCreate angelegt.
Anschließend zieht er sich den AES-Key und dieser wird abgelehnt, aber wieso ? Und wieso kann ich ab diesem Moment nichtmehr mit dem RM kommunizieren ? Ab dann bekomme ich immer: No ACK.
Ich habe das schon mehrmals neu versucht und jedesmal das selbe Problem.
Hier die LOGs:

2016.07.29 16:44:25.969 0 : HMLAN_Parse: HMUSB R:E47CC31 stat:0000 t:00071F90 d:FF r:FFD1 m:89 8400 47CC31 000000 1000AA4E525730303037313336CE000100
2016-07-29 16:44:26.010 Global global UNDEFINED HM_47CC31 CUL_HM 47CC31
2016-07-29 16:44:26.010 Global global DEFINED HM_47CC31
2016-07-29 16:44:26.010 Global global DEFINED FileLog_HM_47CC31
2016-07-29 16:44:26.010 Global global SAVE
2016.07.29 16:44:26.101 0 : HMLAN_Send: HMUSB S:S371D0E7F stat: 00 t:00000000 d:01 r:371D0E7F m:8A A001 123400 47CC31 00050000000000
2016-07-29 16:44:26.113 CUL_HM ActionDetector status_HM_47CC31: alive
2016-07-29 16:44:26.118 CUL_HM HM_47CC31 Activity: alive
2016-07-29 16:44:26.118 CUL_HM HM_47CC31 D-firmware: 1.0
2016-07-29 16:44:26.118 CUL_HM HM_47CC31 D-serialNr: NRW0007136
2016-07-29 16:44:26.118 CUL_HM HM_47CC31 sdRepeat: invalid
2016.07.29 16:44:26.289 0 : HMLAN_Parse: HMUSB R:E47CC31 stat:0100 t:000720BF d:FF r:FFD0 m:8A A002 47CC31 123400 04F6C0BB821BEA00
2016-07-29 16:44:26.296 CUL_HM HM_47CC31 aesCommToDev: pending
2016-07-29 16:44:26.296 CUL_HM HM_47CC31 aesKeyNbr: 00
2016.07.29 16:44:27.217 0 : HMLAN_Parse: HMUSB R:R371D0E7F stat:0030 t:000720C4 d:00 r:FFD0 m:8A A002 47CC31 123400 04F6C0BB821BEA00
2016.07.29 16:44:27.218 0 : HMLAN_Parse: HMUSB AES code rejected for 123400 48
2016.07.29 16:44:27.225 0 : HMLAN_Send: HMUSB S:S371D132F stat: 00 t:00000000 d:01 r:371D132F m:8B A001 123400 47CC31 000802010A120B340C00
2016.07.29 16:44:27.227 0 : HMLAN_Send: HMUSB I:K
2016-07-29 16:44:27.237 CUL_HM HM_47CC31 aesKeyNbr: 00
2016.07.29 16:44:27.281 0 : HMLAN_Parse: HMUSB V:03C7 sNo:NEQ0369509 d:49AD75 O:123400 t:000724B4 IDcnt:0003 L:89 %
2016-07-29 16:44:27.287 HMLAN HMUSB loadLvl: batchLevel
2016.07.29 16:44:27.858 0 : HMLAN_Parse: HMUSB R:R371D132F stat:0008 t:00000000 d:FF r:7FFF m:8B A001 123400 47CC31 000802010A120B340C00
2016.07.29 16:44:27.859 0 : HMLAN_Parse: HMUSB no ACK from 47CC31
2016.07.29 16:44:30.161 0 : HMLAN_Send: HMUSB S:S371D1EA5 stat: 00 t:00000000 d:01 r:371D1EA5 m:8B B001 123400 47CC31 000802010A120B340C00
2016-07-29 16:44:30.399 FRITZBOX FritzBox disabled
2016-07-29 16:44:31.001 CUL_HM HM_47CC31 Activity: alive
2016.07.29 16:44:31.005 0 : HMLAN_Send:  HMUSB I:+47CC31,00,01,00
2016.07.29 16:44:31.986 0 : HMLAN_Parse: HMUSB R:R371D1EA5 stat:0208 t:00000000 d:FF r:7FFF m:8B B001 123400 47CC31 000802010A120B340C00
2016.07.29 16:44:31.987 1 : HMLAN_Parse: HMUSB new condition Warning-HighLoad
2016-07-29 16:44:31.992 HMLAN HMUSB cond: Warning-HighLoad
2016-07-29 16:44:31.992 HMLAN HMUSB Xmit-Events: ERROR-Overload:8 ok:5 disconnected:8 init:7 Warning-HighLoad:11
2016-07-29 16:44:31.992 HMLAN HMUSB prot_Warning-HighLoad: last
2016.07.29 16:44:31.995 0 : HMLAN_Parse: HMUSB no ACK from 47CC31
2016-07-29 16:44:34.232 CUL_HM HM_47CC31 ResndFail
2016-07-29 16:44:34.237 CUL_HM HM_47CC31 MISSING ACK
2016-07-29 16:44:37.024 CUL_HM HM_47CC31 unreachable
2016-07-29 16:44:40.412 FRITZBOX FritzBox disabled
2016.07.29 16:44:46.075 0 : HMLAN_Send: HMUSB S:S371D5CD1 stat: 00 t:00000000 d:01 r:371D5CD1 m:8C B001 123400 47CC31 00040000000000
2016.07.29 16:44:47.892 0 : HMLAN_Parse: HMUSB R:R371D5CD1 stat:0208 t:00000000 d:FF r:7FFF m:8C B001 123400 47CC31 00040000000000
2016.07.29 16:44:47.893 0 : HMLAN_Parse: HMUSB no ACK from 47CC31
2016-07-29 16:44:50.416 FRITZBOX FritzBox disabled
2016.07.29 16:44:50.753 0 : HMLAN_Send: HMUSB S:S371D6F17 stat: 00 t:00000000 d:01 r:371D6F17 m:8C B001 123400 47CC31 00040000000000
2016.07.29 16:44:52.229 0 : HMLAN_Send: HMUSB I:K
2016.07.29 16:44:52.244 0 : HMLAN_Parse: HMUSB V:03C7 sNo:NEQ0369509 d:49AD75 O:123400 t:00078635 IDcnt:0003 L:99 %
2016-07-29 16:44:52.251 HMLAN HMUSB loadLvl: suspended
2016.07.29 16:44:52.564 0 : HMLAN_Parse: HMUSB R:R371D6F17 stat:0208 t:00000000 d:FF r:7FFF m:8C B001 123400 47CC31 00040000000000
2016.07.29 16:44:52.565 0 : HMLAN_Parse: HMUSB no ACK from 47CC31
2016-07-29 16:44:56.669 CUL_HM HM_47CC31 ResndFail
2016-07-29 16:44:56.680 CUL_HM HM_47CC31 RESPONSE TIMEOUT:RegisterRead

Ich hoffe es kann mir jemand weiterhelfen, ich möchte ungern umsonst soviel Geld investiert haben.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 29 Juli 2016, 17:30:03
2016.07.29 16:44:27.218 0 : HMLAN_Parse: HMUSB AES code rejected for 123400 48
hast du das perl modul installiert: crypt-rijindael oder so ähnlich?

2016-07-29 16:44:31.992 HMLAN HMUSB Xmit-Events: ERROR-Overload:8 ok:5 disconnected:8 init:7 Warning-HighLoad:11 der hmusb ist auch am sendelimit.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 29 Juli 2016, 19:27:33
Es meist du mit:
Zieht er sich den aes-key?
Mit den sd2 kommst du schnell ins overload. Sind halt burst devices. Dann geht für eine Stunde nix mehr...

Wurde der aes-key erfolgreich übertragen?
Versuchs erstmal mit pairen und zieh mit getConfig die Daten. Davon schauen, ob erfolgreich gepaird wurde, also die zentrale eingetragen ist.
Ggf. Mal einen reichweitentest starten.
Wenn der rm nicht die zentrale hat,akzeptiert er auch nix..

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: N4unch0rch am 30 Juli 2016, 13:02:34
Hallo und vielen Dank für die schnelle Antwort.

Das Modul habe ich installiert, dass er ins Overload kommt weiß ich, nervt auch ziemlich beim Testen.
Die Zentrale ist im RM eingetragen, ich kann jedoch auch kein getConfig machen, danach kommt immer ein "no ACK".

2016.07.30 13:01:14.958 0 : HMLAN_Send: HMUSB S:S3B7715A3 stat: 00 t:00000000 d:01 r:3B7715A3 m:04 B001 123400 47CC29 00040000000000
2016.07.30 13:01:16.856 0 : HMLAN_Parse: HMUSB R:R3B7715A3 stat:0008 t:00000000 d:FF r:7FFF m:04 B001 123400 47CC29 00040000000000
2016.07.30 13:01:16.857 0 : HMLAN_Parse: HMUSB no ACK from 47CC29
2016-07-30 13:01:19.048 FRITZBOX FritzBox disabled
2016.07.30 13:01:20.707 0 : HMLAN_Send: HMUSB I:K
2016.07.30 13:01:20.723 0 : HMLAN_Parse: HMUSB V:03C7 sNo:NEQ0369509 d:49AD75 O:123400 t:04613BF7 IDcnt:0004 L:89 %
2016-07-30 13:01:20.732 HMLAN HMUSB loadLvl: batchLevel
2016.07.30 13:01:20.912 0 : HMLAN_Send: HMUSB S:S3B772CE4 stat: 00 t:00000000 d:01 r:3B772CE4 m:04 B001 123400 47CC29 00040000000000
2016.07.30 13:01:22.739 0 : HMLAN_Parse: HMUSB R:R3B772CE4 stat:0208 t:00000000 d:FF r:7FFF m:04 B001 123400 47CC29 00040000000000
2016.07.30 13:01:22.748 0 : HMLAN_Parse: HMUSB no ACK from 47CC29
2016-07-30 13:01:25.995 CUL_HM HM_47CC29 ResndFail
2016-07-30 13:01:26.011 CUL_HM HM_47CC29 RESPONSE TIMEOUT:RegisterRead
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 30 Juli 2016, 20:38:40
wenn du nen overload hast, sollte das mit einmal aus- und einstecken weg sein, ne stunde warten musst du da nicht.

zum Rest, list vom Device machen und posten, dann kann man evtl. sehen woran es liegt.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Thomask am 30 Juli 2016, 23:56:34
Hallo,
ich habe lange gezögert, welche Rauchmelder ich mir zulegen soll.
Habe mich dann für die neuen SD2 entschieden.
3er Pack bei ELV bestellt und eingebunden mit virtuellen TeamLead in FHEM.
Ging auch alles glatt.
Hatte die Dinger keine Woche in Betrieb und die Biester gingen alle 3 (korrekt, waren ja mit dem Teamlead gepeert) mitten in der Nacht ohne Grund los.
Habe sie sofort an ELV zurückgeschickt und anstandslos Gutschrift zugesagt bekommen.
Sind also anscheinend auch nicht besser als die SD.
Fehlalarme sind völlig inakzeptabel (Urlaub u.ä.).
Gruß
Thomas
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 31 Juli 2016, 08:04:57
Komisch, bei Dir scheint der "Feinstaub" sehr hoch zu sein  ;)
Ich habe 12 Stück, davon auch einige (SD und SD2) im Keller. Da ist es sehr staubig :D
Einer in der Küche (war mal SD, jetzt SD2) .....
Bisher noch keinen Fehlalarm gehabt...


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: docb am 31 Juli 2016, 18:51:29
Servus,
ich schaffe es irgendwie nicht, meine SD mit den SD2 zusammen mit einem Teamlead zum laufen zu bekommen.
Der Teamlead ist mit allen vieren gepeert (EG und KE sind die "alten", KZ und UGSZ die SD2), es reagieren aber nur die zwei neuen auf TeamCall und AlarmOn/Off.
Hat jemand eine Idee?
Viele Grüße
doc

Hier der Teamlead:
Internals:
   CFGFN
   DEF        11311301
   NAME       Rauchmelder_TL
   NR         1181
   STATE      off
   TESTNR     6
   TYPE       CUL_HM
   chanNo     01
   device     TeamDev
   peerList   EG_Rauchmelder,KE_Rauchmelder,KZ_Rauchmelder,UGSZ_Rauchmelder,
   sdTeam     sdLead
   Readings:
     2016-07-31 18:40:25   aesCBCCounter   00000F
     2016-07-31 18:40:58   eventNo         02
     2016-07-31 18:40:58   level           0
     2016-07-31 18:38:17   peerList        EG_Rauchmelder,KE_Rauchmelder,KZ_Rauchmelder,UGSZ_Rauchmelder,
     2016-07-31 18:34:36   recentAlarm     TeamDev
     2016-07-31 18:40:58   smoke_detect    none
     2016-07-31 18:40:58   state           off
     2016-07-31 18:40:25   teamCall        from TeamDev:06
     2016-07-31 18:40:58   trigger         Short_2
     2016-07-31 18:40:58   trigger_cnt     2
   Helper:
     BNO        2
     BNOCNT     1
     count      2
     fkt        sdLead2
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
       vrt        1
     Tmpl:
   Nb:
     cnt        1
Attributes:
   model      virtual_1
   peerIDs    1E8B0601,1E8C1201,49916401,49918201,
   room       Z_Alarm
   webCmd     press short:press long

Bei den PeerIDs bei meinem alten SD1 ist komischerweise auch eine 00000000 mit dabei, die finde ich aber beim neuen auch.
Hier ein Alter:
Internals:
   CFGFN      ./devices.conf
   DEF        1E8B06
   IODev      LANInterfaceEG
   LANInterfaceEG_MSGCNT 9
   LANInterfaceEG_RAWMSG R41CD1530,0001,1212DBA6,FF,FFC6,0BA0101E8B06286526011131130100000000
   LANInterfaceEG_RSSI -58
   LANInterfaceEG_TIME 2016-07-31 18:32:55
   LANInterfaceUG_MSGCNT 10
   LANInterfaceUG_RAWMSG E1E8B06,0000,0135455D,FF,FFB1,0BA0101E8B06286526011131130100000000
   LANInterfaceUG_RSSI -79
   LANInterfaceUG_TIME 2016-07-31 18:32:55
   LASTInputDev LANInterfaceEG
   MSGCNT     19
   NAME       EG_Rauchmelder
   NR         456
   NTFY_ORDER 50-EG_Rauchmelder
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:0B - t:10 s:1E8B06 d:286526 011131130100000000
   peerList   Rauchmelder_TL,
   protCmdDel 2
   protErrIoAttack 3 last_at:2016-07-31 17:22:32
   protLastRcv 2016-07-31 18:32:55
   protResnd  1 last_at:2016-07-31 18:32:32
   protResndFail 1 last_at:2016-07-31 18:32:36
   protSnd    14 last_at:2016-07-31 18:32:55
   protState  CMDs_done
   rssi_LANInterfaceUG cnt:1 lst:-72 avg:-72 max:-72 min:-72
   rssi_at_LANInterfaceEG cnt:9 avg:-58 lst:-58 min:-58 max:-58
   rssi_at_LANInterfaceUG min:-79 max:-74 cnt:10 lst:-79 avg:-75.9
   Readings:
     2016-07-31 17:19:48   Activity        alive
     2016-07-31 18:17:05   CommandAccepted yes
     2015-04-27 15:57:39   D-firmware      1.0
     2015-04-27 15:57:39   D-serialNr      JEQ0732773
     2016-07-31 18:32:54   PairedTo        0x28____
     2015-04-27 15:59:22   R-pairCentral   0x28____
     2016-07-31 18:32:54   RegL_00.          02:01 0A:28 0B:65 0C:26 00:00
     2016-07-31 17:20:24   battery         ok
     2016-07-31 17:20:24   level           1
     2016-07-31 18:32:55   peerList        Rauchmelder_TL,
     2016-07-31 17:20:24   recentStateType info
     2016-07-31 12:44:31   sabotageAttack_ErrIoAttack cnt 2
     2016-07-31 17:22:32   sabotageAttack_ErrIoAttack cnt 3
     2016-07-31 18:40:58   smoke_detect    none
     2016-07-31 18:40:58   state           off
     2016-07-31 18:40:25   teamCall        from TeamDev:06
   Helper:
     HM_CMDNR   11
     cSnd       012865261E8B0600040000000000,012865261E8B060103
     mId        0042
     peerIDsRaw ,11311301,00000000
     rxType     2
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +1E8B06,00,02,00
       nextSend   1469982774.20472
       rxt        0
       vccu       vccu
       p:
         1E8B06
         00
         02
         00
       prefIO:
         LANInterfaceEG
     Mrssi:
       mNo        0B
       Io:
         LANInterfaceEG -56
         LANInterfaceUG -79
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         LANInterfaceUG
       flg        A
       ts         1469982775.79672
       ack:
         HASH(0x30900cc)
         0B80022865261E8B0600
     Rssi:
       Laninterfaceug:
         avg        -72
         cnt        1
         lst        -72
         max        -72
         min        -72
       At_laninterfaceeg:
         avg        -58
         cnt        9
         lst        -58
         max        -58
         min        -58
       At_laninterfaceug:
         avg        -75.9
         cnt        10
         lst        -79
         max        -74
         min        -79
     Shadowreg:
     Tmpl:
   Nb:
     cnt        2
Attributes:
   IODev      LANInterfaceEG
   IOgrp      vccu:LANInterfaceEG
   actCycle   099:00
   actStatus  alive
   aesKey     2
   alias      EG
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.0
   group      Rauchmelder
   icon       secur_smoke_detector
   model      HM-SEC-SD
   msgRepeat  1
   peerIDs    00000000,11311301,
   room       Z_Alarm
   serialNr   JEQ0732773
   subType    smokeDetector
   webCmd     alarmOn:alarmOff

Hier ein Neuer:
Internals:
   DEF        499182
   IODev      LANInterfaceEG
   LANInterfaceEG_MSGCNT 13
   LANInterfaceEG_RAWMSG R41C0857D,0001,12064C46,FF,FFC0,90A010499182286526011131130100000000
   LANInterfaceEG_RSSI -64
   LANInterfaceEG_TIME 2016-07-31 18:19:11
   LANInterfaceUG_MSGCNT 13
   LANInterfaceUG_RAWMSG E499182,0000,0128B60C,FF,FFCF,90A010499182286526011131130100000000
   LANInterfaceUG_RSSI -49
   LANInterfaceUG_TIME 2016-07-31 18:19:11
   LASTInputDev LANInterfaceEG
   MSGCNT     26
   NAME       UGSZ_Rauchmelder
   NR         1124
   NTFY_ORDER 50-UGSZ_Rauchmelder
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:90 - t:10 s:499182 d:286526 011131130100000000
   peerList   Rauchmelder_TL,
   protCmdDel 1
   protErrIoAttack 3 last_at:2016-07-31 17:22:49
   protEvt_AESCom-ok 1 last_at:2016-07-31 18:18:01
   protLastRcv 2016-07-31 18:19:11
   protResnd  1 last_at:2016-07-31 17:20:42
   protResndFail 1 last_at:2016-07-31 17:20:47
   protSnd    15 last_at:2016-07-31 18:19:11
   protState  CMDs_done
   rssi_LANInterfaceEG max:-56 min:-56 lst:-56 avg:-56 cnt:1
   rssi_at_LANInterfaceEG min:-67 max:-63 lst:-64 avg:-65.45 cnt:11
   rssi_at_LANInterfaceUG min:-50 max:-33 cnt:11 avg:-44.18 lst:-49
   Readings:
     2016-07-31 17:19:48   Activity        alive
     2016-07-31 18:18:01   CommandAccepted yes
     2016-07-30 19:44:54   D-firmware      1.0
     2016-07-30 19:44:54   D-serialNr      NEQ0249454
     2016-07-31 18:19:10   PairedTo        0x28____
     2016-07-30 19:44:59   R-pairCentral   0x28____
     2016-07-31 18:19:10   RegL_00.          02:01 0A:28 0B:65 0C:26 16:00 1F:00 00:00
     2016-07-31 18:18:01   aesCommToDev    ok
     2016-07-31 18:18:01   aesKeyNbr       02
     2016-07-31 17:50:47   alarmTest       ok
     2016-07-31 17:50:47   battery         ok
     2016-07-31 17:50:47   level           0
     2016-07-31 18:19:11   peerList        Rauchmelder_TL,
     2016-07-31 17:50:47   recentStateType info
     2016-07-31 12:03:50   sabotageAttack_ErrIoAttack cnt 9
     2016-07-31 17:22:49   sabotageAttack_ErrIoAttack cnt 3
     2016-07-31 18:19:10   sdRepeat        off
     2016-07-31 17:50:47   smokeChamber    ok
     2016-07-31 18:40:58   smoke_detect    none
     2016-07-31 18:40:58   state           off
     2016-07-31 18:40:25   teamCall        from TeamDev:06
   Helper:
     HM_CMDNR   144
     cSnd       0128652649918200040000000000,012865264991820103
     mId        00AA
     peerIDsRaw ,11311301,00000000
     rxType     6
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +499182,00,01,00
       nextSend   1469981951.73059
       rxt        0
       vccu       vccu
       p:
         499182
         00
         01
         00
       prefIO:
         LANInterfaceEG
     Mrssi:
       mNo        90
       Io:
         LANInterfaceEG -62
         LANInterfaceUG -49
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         LANInterfaceUG
       flg        A
       ts         1469981951.43772
       ack:
         HASH(0x4486fc4)
         90800228652649918200
     Rssi:
       Laninterfaceeg:
         avg        -56
         cnt        1
         lst        -56
         max        -56
         min        -56
       At_laninterfaceeg:
         avg        -65.4545454545455
         cnt        11
         lst        -64
         max        -63
         min        -67
       At_laninterfaceug:
         avg        -44.1818181818182
         cnt        11
         lst        -49
         max        -33
         min        -50
     Shadowreg:
     Tmpl:
Attributes:
   IODev      LANInterfaceEG
   IOgrp      vccu:LANInterfaceEG
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   group      Rauchmelder
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,11311301,
   room       Z_Alarm
   serialNr   NEQ0249454
   subType    smokeDetector
   webCmd     statusRequest
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 31 Juli 2016, 20:07:48
Kein Wunder, das geht auch nicht.
Sd und sd2 sind nicht kompatibel!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: docb am 31 Juli 2016, 20:28:43
 ;D Ok  - ich dachte das würde wunderbar zusammen funktionieren, weil einige hier ja von einer Installation mit beiden Gerätetypen geschrieben haben.
Könnte ich das über zwei Teamleads (einen für alt, einen für neu) lösen und die mit einem notify verbinden (wenn der eine auslöst, aktiviere den anderen und umgekehrt)? Müsste eigentlich doch funktionieren.
Viele Grüße
doc
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 31 Juli 2016, 20:34:39
;D Ok  - ich dachte das würde wunderbar zusammen funktionieren, weil einige hier ja von einer Installation mit beiden Gerätetypen geschrieben haben.
das hast du wohl falsch verstanden, zusammen in einem TeamLead gibts nicht.
Zitat
Könnte ich das über zwei Teamleads (einen für alt, einen für neu) lösen und die mit einem notify verbinden (wenn der eine auslöst, aktiviere den anderen und umgekehrt)? Müsste eigentlich doch funktionieren.
Viele Grüße
doc
das ist die einzige Möglichkeit, funktioniert dann aber halt nur über FHEM und ist somit nicht "ausfallsicher".
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: docb am 05 August 2016, 16:01:07
Servus,
irgendwie schaffe ich es nicht, meine SD2s in ein Team aufzunehmen. Also so wie die Lists aussehen, müsste mE eigentlich alles passen, aber weder TeamCall noch AlarmOn/Off funktionieren. Der Teamlead ist quasi ohne Funktion. Fällt jemand etwas auf?
Viele Grüße

Hier mein virtueller Teamlead:
Internals:
   CFGFN
   DEF        11311301
   NAME       Rauchmelder_TL_SD2
   NR         1295
   STATE      off
   TESTNR     19
   TYPE       CUL_HM
   chanNo     01
   device     TeamDev_SD2
   peerList   KZ_Rauchmelder,UGSZ_Rauchmelder,
   sdTeam     sdLead
   Readings:
     2016-08-05 15:54:49   aesCBCCounter   000014
     2016-08-05 15:55:00   eventNo         13
     2016-08-05 15:55:00   level           0
     2016-08-05 15:47:20   peerList        KZ_Rauchmelder,UGSZ_Rauchmelder,
     2016-08-05 15:55:00   smoke_detect    none
     2016-08-05 15:55:00   state           off
     2016-08-05 15:54:32   teamCall        from TeamDev_SD2:11
     2016-08-05 15:54:32   trigger_cnt     17
   Helper:
     fkt        sdLead2
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
       vrt        1
     Tmpl:
   Role:
Attributes:
   aesCommReq 1
   group      Rauchmelder
   icon       secur_smoke_detector
   model      virtual_1
   peerIDs    49916401,49918201,
   room       Z_Alarm
   webCmd     press short:press long

Hier einer der SD2s:
Internals:
   DEF        499164
   IODev      LANInterfaceUG
   LANInterfaceEG_MSGCNT 47
   LANInterfaceEG_RAWMSG E499164,0000,09FA7069,FF,FFBA,1884004991640000001000AA4E455130323439343237CE000100
   LANInterfaceEG_RSSI -70
   LANInterfaceEG_TIME 2016-08-05 15:37:17
   LANInterfaceUG_MSGCNT 57
   LANInterfaceUG_RAWMSG E499164,0000,1A552CF2,FF,FFD6,1884004991640000001000AA4E455130323439343237CE000100
   LANInterfaceUG_RSSI -42
   LANInterfaceUG_TIME 2016-08-05 15:37:20
   LASTInputDev LANInterfaceUG
   MSGCNT     104
   NAME       KZ_Rauchmelder
   NR         1119
   NTFY_ORDER 50-KZ_Rauchmelder
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:18 - t:00 s:499164 d:000000 1000AA4E455130323439343237CE000100
   peerList   Rauchmelder_TL_SD2,
   protCmdDel 5
   protEvt_AESCom-ok 4 last_at:2016-08-05 15:31:10
   protIOdly  1 last_at:2016-08-05 15:31:29
   protIOerr  1 last_at:2016-08-05 15:32:29
   protLastRcv 2016-08-05 15:37:20
   protNack   2 last_at:2016-08-05 13:50:02
   protResnd  3 last_at:2016-08-05 13:54:48
   protResndFail 1 last_at:2016-08-05 13:54:53
   protSnd    42 last_at:2016-08-05 15:32:34
   protState  CMDs_done
   rssi_LANInterfaceEG cnt:1 max:-55 avg:-55 min:-55 lst:-55
   rssi_LANInterfaceUG cnt:1 max:-27 avg:-27 lst:-27 min:-27
   rssi_at_LANInterfaceEG lst:-70 min:-72 max:-66 avg:-69.6 cnt:41
   rssi_at_LANInterfaceUG max:-32 avg:-39.09 min:-47 lst:-42 cnt:55
   Readings:
     2016-08-05 15:36:23   Activity        alive
     2016-08-05 15:31:10   CommandAccepted yes
     2016-08-05 15:36:23   D-firmware      1.0
     2016-08-05 15:36:23   D-serialNr      NEQ0249427
     2016-08-05 15:32:33   PairedTo        0x286xxx
     2016-07-31 19:35:17   R-pairCentral   0x286xxx
     2016-08-05 15:32:33   RegL_00.          02:01 0A:28 0B:65 0C:26 16:00 1F:00 00:00
     2016-08-05 15:31:10   aesCommToDev    ok
     2016-08-05 15:31:09   aesKeyNbr       02
     2016-08-05 13:52:17   alarmTest       ok
     2016-08-05 13:52:17   battery         ok
     2016-08-05 13:52:17   level           0
     2016-08-05 15:32:34   peerList        Rauchmelder_TL_SD2,
     2016-08-05 13:52:17   recentStateType info
     2016-08-02 05:19:35   sabotageAttack_ErrIoAttack cnt 6
     2016-08-05 15:32:33   sdRepeat        off
     2016-08-05 13:52:17   smokeChamber    ok
     2016-08-05 15:55:00   smoke_detect    none
     2016-08-05 15:55:00   state           off
     2016-08-05 15:54:32   teamCall        from TeamDev_SD2:11
   Helper:
     HM_CMDNR   24
     cSnd       0128652649916400040000000000,012865264991640103
     mId        00AA
     peerIDsRaw ,11311301,00000000
     rxType     6
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +499164,01,02,02
       nextSend   1470404240.47001
       rxt        0
       vccu       vccu
       p:
         499164
         01
         02
         02
       prefIO:
         LANInterfaceEG
     Mrssi:
       mNo        18
       Io:
         LANInterfaceEG -70
         LANInterfaceUG -40
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       Laninterfaceeg:
         avg        -55
         cnt        1
         lst        -55
         max        -55
         min        -55
       Laninterfaceug:
         avg        -27
         cnt        1
         lst        -27
         max        -27
         min        -27
       At_laninterfaceeg:
         avg        -69.609756097561
         cnt        41
         lst        -70
         max        -66
         min        -72
       At_laninterfaceug:
         avg        -39.0909090909091
         cnt        55
         lst        -42
         max        -32
         min        -47
     Shadowreg:
     Tmpl:
   Role:
Attributes:
   IODev      LANInterfaceEG
   IOgrp      vccu:LANInterfaceEG
   actCycle   099:00
   actStatus  alive
   aesCommReq 1
   aesKey     2
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   group      Rauchmelder
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,11311301,
   room       Z_Alarm
   serialNr   NEQ0249427
   subType    smokeDetector
   webCmd     statusRequest

Hier der Zweite:

Internals:
   DEF        499182
   IODev      LANInterfaceUG
   LANInterfaceEG_MSGCNT 29
   LANInterfaceEG_RAWMSG E499182,0000,0A03D1D9,FF,FFBC,14A010499182286526011131130100000000
   LANInterfaceEG_RSSI -68
   LANInterfaceEG_TIME 2016-08-05 15:47:32
   LANInterfaceUG_MSGCNT 30
   LANInterfaceUG_RAWMSG R5AF57904,0001,1A5E82A0,FF,FFDB,14A010499182286526011131130100000000
   LANInterfaceUG_RSSI -37
   LANInterfaceUG_TIME 2016-08-05 15:47:32
   LASTInputDev LANInterfaceUG
   MSGCNT     59
   NAME       UGSZ_Rauchmelder
   NR         1114
   NTFY_ORDER 50-UGSZ_Rauchmelder
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:14 - t:10 s:499182 d:286526 011131130100000000
   peerList   Rauchmelder_TL_SD2,
   protCmdDel 6
   protEvt_AESCom-ok 4 last_at:2016-08-05 15:47:21
   protEvt_AESerrReject 1 last_at:2016-08-05 13:49:43
   protIOdly  1 last_at:2016-08-05 15:46:15
   protIOerr  1 last_at:2016-08-05 15:47:15
   protLastRcv 2016-08-05 15:47:32
   protNack   1 last_at:2016-08-05 13:49:43
   protResnd  3 last_at:2016-08-05 15:30:22
   protResndFail 2 last_at:2016-08-05 13:46:06
   protSnd    35 last_at:2016-08-05 15:47:32
   protState  CMDs_done
   rssi_LANInterfaceUG cnt:1 max:-28 avg:-28 min:-28 lst:-28
   rssi_at_LANInterfaceEG cnt:25 avg:-69.39 max:-63 min:-78 lst:-68
   rssi_at_LANInterfaceUG lst:-37 min:-48 max:-34 avg:-38.91 cnt:24
   Readings:
     2016-08-05 13:51:04   Activity        alive
     2016-08-05 15:47:21   CommandAccepted yes
     2016-08-05 13:51:04   D-firmware      1.0
     2016-08-05 13:51:04   D-serialNr      NEQ0249454
     2016-08-05 15:47:31   PairedTo        0x286xxx
     2016-07-30 19:44:59   R-pairCentral   0x286xxx
     2016-08-05 15:47:31   RegL_00.          02:01 0A:28 0B:65 0C:26 16:00 1F:00 00:00
     2016-08-05 15:47:21   aesCommToDev    ok
     2016-08-05 15:47:20   aesKeyNbr       02
     2016-08-05 13:52:09   alarmTest       ok
     2016-08-05 13:52:09   battery         ok
     2016-08-05 13:52:09   level           0
     2016-08-05 15:47:32   peerList        Rauchmelder_TL_SD2,
     2016-08-05 13:52:09   recentStateType info
     2016-07-31 17:18:22   sabotageAttack_ErrIoAttack cnt 3
     2016-08-05 15:47:31   sdRepeat        off
     2016-08-05 13:52:09   smokeChamber    ok
     2016-08-05 15:55:00   smoke_detect    none
     2016-08-05 15:55:00   state           off
     2016-08-05 15:54:32   teamCall        from TeamDev_SD2:11
   Helper:
     HM_CMDNR   20
     cSnd       0128652649918200040000000000,012865264991820103
     mId        00AA
     peerIDsRaw ,11311301,00000000
     rxType     6
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +499182,00,01,00
       nextSend   1470404852.14434
       rxt        0
       vccu       vccu
       p:
         499182
         00
         01
         00
       prefIO:
         LANInterfaceEG
     Mrssi:
       mNo        14
       Io:
         LANInterfaceEG -68
         LANInterfaceUG -35
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         LANInterfaceEG
       flg        A
       ts         1470404852.0515
       ack:
         HASH(0x58cee94)
         14800228652649918200
     Rssi:
       Laninterfaceug:
         avg        -28
         cnt        1
         lst        -28
         max        -28
         min        -28
       At_laninterfaceeg:
         avg        -69.4
         cnt        25
         lst        -68
         max        -63
         min        -78
       At_laninterfaceug:
         avg        -38.9166666666667
         cnt        24
         lst        -37
         max        -34
         min        -48
     Shadowreg:
     Tmpl:
Attributes:
   IODev      LANInterfaceEG
   IOgrp      vccu:LANInterfaceEG
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   group      Rauchmelder
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,11311301,
   room       Z_Alarm
   serialNr   NEQ0249454
   subType    smokeDetector
   webCmd     statusRequest

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 05 August 2016, 16:11:44
Ja, sieben statt 6 stellen in der hmid vom Teamlead: 113311301
113311 + 01 für den Channel würde gehen
Lg Christian
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: docb am 05 August 2016, 16:16:36
Hi, danke, wo hast du denn diese komische hmID gefunden? Ich finde überall nur 113113 + 01
Viele Grüße
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 05 August 2016, 17:16:46
Oh Tatsache, da habe ich wohl falsch geschaut. Man sollte sowas nicht am Handy machen, dann passiert sowas auch nicht. Ich schaue heute Abend mal am Rechner
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: docb am 05 August 2016, 17:24:19
So, die Lösung: ich war wohl zu ungeduldig. Nach einer Stunde bin ich wieder rein und auf einmal klappt es (am Overload lag es nicht, das hatte ich kontrolliert).
Fein und danke trotzdem ;-)
Beste Grüße
doc
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: N4unch0rch am 23 August 2016, 22:20:25
Sorry für die späte Antwort. Hier ein Listing von einem meiner RMs, die nachdem sie gepairt wurden nichtmehr kommunizieren.


Internals:
   CFGFN
   DEF        47CBE9
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     4
   NAME       HM_47CBE9
   NR         279
   NTFY_ORDER 50-HM_47CBE9
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   hmusb_MSGCNT 4
   hmusb_RAWMSG RB90CEE23,0030,00147199,00,FFBF,82A00247CBE912340004A51751A53A0600
   hmusb_RSSI -65
   hmusb_TIME 2016-08-23 22:17:28
   lastMsg    No:82 - t:02 s:47CBE9 d:123400 04A51751A53A0600
   protCmdDel 4
   protEvt_AESerrReject 1 last_at:2016-08-23 22:17:28
   protLastRcv 2016-08-23 22:17:28
   protResnd  2 last_at:2016-08-23 22:18:07
   protResndFail 2 last_at:2016-08-23 22:18:12
   protSnd    4 last_at:2016-08-23 22:18:03
   protState  CMDs_done_Errors:1
   rssi_at_hmusb avg:-65 min:-65 max:-65 lst:-65 cnt:2
   Readings:
     2016-08-23 22:17:34   Activity        alive
     2016-08-23 22:17:27   D-firmware      1.0
     2016-08-23 22:17:27   D-serialNr      NRW0007183
     2016-08-23 22:17:27   R-pairCentral   set_0x123400
     2016-08-23 22:17:27   aesCommToDev    pending
     2016-08-23 22:17:28   aesKeyNbr       00
     2016-08-23 22:18:12   state           RESPONSE TIMEOUT:RegisterRead
     Regl_00::
       VAL
   Helper:
     HM_CMDNR   132
     cSnd       0112340047CBE9000802010A120B340C00,0112340047CBE900040000000000
     getCfgListNo
     mId        00AA
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +47CBE9,00,03,00
       nextSend   1471983447.56548
       prefIO
       rxt        0
       vccu
       p:
         47CBE9
         00
         03
         00
     Mrssi:
       mNo        82
       Io:
         hmusb      -63
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         hmusb
       flg        A
       ts         1471983448.46311
       ack:
         HASH(0x16edb60)
         82800212340047CBE900
     Rssi:
       At_hmusb:
         avg        -65
         cnt        2
         lst        -65
         max        -65
         min        -65
     Shadowreg:
       RegL_00:    02:01 0A:12 0B:34 0C:00
Attributes:
   IODev      hmusb
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   room       CUL_HM
   serialNr   NRW0007183
   subType    smokeDetector
   webCmd     statusRequest
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 24 August 2016, 07:18:25
Dein pairing ist nicht abgeschlossen! => R-pairCentral   set_0x123400

Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: N4unch0rch am 29 August 2016, 22:05:34
Und wie genau kann ich das beheben ? Der Melder ist ja ab dem Pairing-Versuch nichtmehr erreichbar.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 30 August 2016, 21:08:19
Du solltest noch in der Lage sein gemäss Anleitung das device in den config Mode zu versetzen. Damit ist die Erreichbarkeit gegeben.
Das device anzusprechen ohne es gepairt zu haben und ohne config zu druecken sollte hoffentlich nicht gehe . Security.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: raspklaus am 31 August 2016, 11:08:16
Hallo zusammen,

ich habe es nun endlich geschafft alle 4 Rauchmelder ans Laufen zu bekommen. Wenn TeamCall funktioniert, dann gehen auch die anderen Funktionen  ;)

Nur ein kleines Problkem habe ich noch mit einem der Melder:

Er scheint irgendwie im Gegensatz zu den anderen nicht AES zu verstehen.
Hier das List von Rauchmelder 2, der AES verarbeitet:

Internals:
   CUL_800HM_MSGCNT 3
   CUL_800HM_RAWMSG A0D86A6104C846B35314306010000::-70:CUL_800HM
   CUL_800HM_RSSI -70
   CUL_800HM_TIME 2016-08-31 07:29:32
   DEF        4C846B
   IODev      CUL_800HM
   LASTInputDev hmusb
   MSGCNT     6
   NAME       Rauchmelder_2
   NOTIFYDEV  global
   NR         2676
   NTFY_ORDER 50-Rauchmelder_2
   STATE      off
   TYPE       CUL_HM
   hmusb_MSGCNT 3
   hmusb_RAWMSG E4C846B,0000,66D6DFF0,FF,FFB4,86A6104C846B35314306010000
   hmusb_RSSI -76
   hmusb_TIME 2016-08-31 07:29:32
   lastMsg    No:86 - t:10 s:4C846B d:353143 06010000
   peerList   Rauchmelder_Team,
   protLastRcv 2016-08-31 07:29:32
   protSnd    3 last_at:2016-08-31 07:29:32
   protState  CMDs_done
   rssi_at_CUL_800HM avg:-70.16 min:-70.5 max:-70 lst:-70 cnt:3
   rssi_at_hmusb avg:-76.66 min:-77 max:-76 lst:-76 cnt:3
   Readings:
     2016-08-29 18:06:24   Activity        alive
     2016-08-27 12:50:57   CommandAccepted yes
     2016-08-27 12:46:48   D-firmware      1.0
     2016-08-27 12:46:48   D-serialNr      NEQ0447764
     2016-08-28 12:12:31   PairedTo        0x353143
     2016-08-27 12:46:44   R-pairCentral   0x353143
     2016-08-28 12:12:31   RegL_00.        02:01 0A:35 0B:31 0C:43 16:00 1F:00 00:00
     2016-08-27 12:50:57   aesCommToDev    ok
     2016-08-27 12:50:57   aesKeyNbr       00
     2016-08-31 07:29:32   alarmTest       ok
     2016-08-31 07:29:32   battery         ok
     2016-08-31 07:29:32   level           0
     2016-08-29 18:06:24   peerList        Rauchmelder_Team,
     2016-08-28 23:59:33   power-daily     0
     2016-08-28 23:59:33   power-daily-last 0
     2016-08-29 17:59:24   power-hourly    0
     2016-08-29 17:59:24   power-hourly-last 0.0
     2016-08-28 23:59:33   power-weekly    0
     2016-08-28 23:59:33   power-weekly-last 0
     2016-08-28 12:10:54   powerOn         2016-08-28 12:10:53
     2016-08-31 07:29:32   recentStateType info
     2016-08-28 12:12:31   sdRepeat        off
     2016-08-31 07:29:32   smokeChamber    ok
     2016-08-28 12:24:43   smoke_detect    none
     2016-08-31 07:29:32   state           off
     2016-08-28 12:24:43   teamCall        from TeamDev:29
   Helper:
     HM_CMDNR   134
     mId        00AA
     rxType     6
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4C846B,00,00,00
       nextSend   1472621372.85965
       rxt        0
       vccu       vccu
       p:
         4C846B
         00
         00
         00
       prefIO:
         CUL_800HM
     Mrssi:
       mNo        86
       Io:
         CUL_800HM  -68
         hmusb      -76
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         CUL_800HM
       flg        A
       ts         1472621372.59497
       ack:
         HASH(0x3b3d838)
         8680023531434C846B00
     Rssi:
       At_cul_800hm:
         avg        -70.1666666666667
         cnt        3
         lst        -70
         max        -70
         min        -70.5
       At_hmusb:
         avg        -76.6666666666667
         cnt        3
         lst        -76
         max        -76
         min        -77
     Tmpl:
Attributes:
   IODev      CUL_800HM
   IOgrp      vccu:CUL_800HM
   actCycle   099:00
   actStatus  alive
   autoReadReg 5_readMissing
   event-on-change-reading .*
   expert     2_raw
   firmware   1.0
   group      Rauchalarm
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,11111101,
   room       Alarmraum,CUL_HM
   serialNr   NEQ0447764
   subType    smokeDetector
   webCmd     statusRequest

und hier das von dem, der AES anscheinend nicht versteht aber trotzdem funktioniert:

Internals:
   CUL_800HM_MSGCNT 2
   CUL_800HM_RAWMSG A0DA3A6104CA1E235314306010000::-71:CUL_800HM
   CUL_800HM_RSSI -71
   CUL_800HM_TIME 2016-08-31 01:36:29
   DEF        4CA1E2
   IODev      CUL_800HM
   LASTInputDev hmusb
   MSGCNT     4
   NAME       Rauchmelder_3
   NOTIFYDEV  global
   NR         2677
   NTFY_ORDER 50-Rauchmelder_3
   STATE      off
   TYPE       CUL_HM
   hmusb_MSGCNT 2
   hmusb_RAWMSG E4CA1E2,0000,6593AC80,FF,FFB0,A3A6104CA1E235314306010000
   hmusb_RSSI -80
   hmusb_TIME 2016-08-31 01:36:30
   lastMsg    No:A3 - t:10 s:4CA1E2 d:353143 06010000
   peerList   Rauchmelder_Team,
   protLastRcv 2016-08-31 01:36:30
   protSnd    2 last_at:2016-08-31 01:36:29
   protState  CMDs_done
   rssi_at_CUL_800HM avg:-70.75 min:-71 max:-70.5 lst:-71 cnt:2
   rssi_at_hmusb avg:-77.5 min:-80 max:-75 lst:-80 cnt:2
   Readings:
     2016-08-29 18:06:24   Activity        alive
     2016-08-27 20:24:58   CommandAccepted no
     2016-08-27 20:25:14   D-firmware      1.0
     2016-08-27 20:25:14   D-serialNr      NEQ0447905
     2016-08-27 20:25:14   PairedTo        0x353143
     2016-08-27 20:21:08   R-pairCentral   0x353143
     2016-08-27 20:25:14   RegL_00.        02:01 0A:35 0B:31 0C:43 16:00 1F:00 00:00
     2016-08-27 20:24:58   aesCommToDev    fail
     2016-08-27 20:24:58   aesKeyNbr       00
     2016-08-31 01:36:29   alarmTest       ok
     2016-08-31 01:36:29   battery         ok
     2016-08-27 20:19:07   eventNo         01
     2016-08-31 01:36:29   level           0
     2016-08-29 18:06:24   peerList        Rauchmelder_Team,
     2016-08-28 23:59:35   power-daily     0
     2016-08-28 23:59:35   power-daily-last 0
     2016-08-29 17:59:26   power-hourly    0
     2016-08-29 17:59:26   power-hourly-last 0.0
     2016-08-28 23:59:35   power-weekly    0
     2016-08-28 23:59:35   power-weekly-last 0
     2016-08-27 20:19:50   powerOn         2016-08-27 20:19:50
     2016-08-31 01:36:29   recentStateType info
     2016-08-27 20:25:14   sdRepeat        off
     2016-08-31 01:36:29   smokeChamber    ok
     2016-08-28 12:24:43   smoke_detect    none
     2016-08-31 01:36:29   state           off
     2016-08-28 12:24:43   teamCall        from TeamDev:29
   Helper:
     HM_CMDNR   163
     mId        00AA
     rxType     6
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4CA1E2,00,00,00
       nextSend   1472600190.12712
       rxt        0
       vccu       vccu
       p:
         4CA1E2
         00
         00
         00
       prefIO:
         CUL_800HM
     Mrssi:
       mNo        A3
       Io:
         CUL_800HM  -69
         hmusb      -80
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         CUL_800HM
       flg        A
       ts         1472600189.87358
       ack:
         HASH(0x3b3d8e0)
         A380023531434CA1E200
     Rssi:
       At_cul_800hm:
         avg        -70.75
         cnt        2
         lst        -71
         max        -70.5
         min        -71
       At_hmusb:
         avg        -77.5
         cnt        2
         lst        -80
         max        -75
         min        -80
     Tmpl:
Attributes:
   IODev      CUL_800HM
   IOgrp      vccu:CUL_800HM
   actCycle   099:00
   actStatus  alive
   autoReadReg 5_readMissing
   event-on-change-reading .*
   expert     2_raw
   firmware   1.0
   group      Rauchalarm
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,11111101,
   room       Alarmraum,CUL_HM
   serialNr   NEQ0447905
   subType    smokeDetector
   webCmd     statusRequest

Wie kann man diesen kleinen Fehler noch beseitigen ?

Danke
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 31 August 2016, 12:22:13
setze doch mal, zumindestens zum testen => attr IOgrp vccu:hmusb
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: raspklaus am 31 August 2016, 12:54:09
Es haben aber alle
IOgrp      vccu:CUL_800HM

Die die mit der Verschlüsselung klarkommen und der der es nicht schafft

Vielleicht kennt Martin das Problem
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 31 August 2016, 13:53:25
genau, und deshalb tauschen, weil der cul schlechteres timing hat.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 31 August 2016, 13:58:03
Hallo,

Hallo zusammen,
Er scheint irgendwie im Gegensatz zu den anderen nicht AES zu verstehen.

Wie testest Du das?

Nur eine Konfigurationsänderung der SD2 führt zu einem AES Challenge-Response (und damit zum Update des Readings). Ein Alarm oder Teamcall tut dies nicht (anderes AES-Verfahren ohne Rückmeldung vom Gerät)!
Und einmal fehlgeschlagene AES-Requests sind nicht ungewöhnlich und können z.B. durch kurzzeitige Funkstörungen verursacht worden sein.

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: raspklaus am 31 August 2016, 14:38:37
Was zB könnte ich an der Konfiguration des betroffenen SD ändern um es zu testen ?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 03 September 2016, 13:24:08
Muss auch noch mal eine Frage nachstellen:

Bisher hat alles wunderbar funktioniert. Sogar bei einem Alarm hat alles so wie es soll geklappt.

Nun musste ich in FHEM einiges umstellen (Bezeichnung, etc) und der FHEM -Server war auch einige Zeit off.
Nun musste ich leider feststellen, dass die SD2 nicht mehr per TeamCall angesprochen werden von FHEM ??

Kann es sein, dass FHEM verschiedene Messages zwischen den SD2s nicht mitbekommen hat und dadurch mit der "Message count" in der AES-Sginierung durcheinander gekommen ist??
Wie kann ich das beheben??


Vermutlich liegt es doch am Reading "aesCBCCounter", oder??
@martin876: Wie war das noch. FHEM musste den Counter irgendwo speichern, sonst wurden die teamCalls ignoriert, wenn die ID tiefer war als der zuletzt gesendete.
                      Wo wird der Counter gespeichert? Im Reading aesCBCCounter?
                      Dieses könnte ich doch mit setreading beeinflussen... (höher setzen??)


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 03 September 2016, 17:09:33
korrekt: Reading aesCBCCounter
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 03 September 2016, 17:55:03
Also im TeamLead einen hohen wert einstellen?
Oder wie gehe ich am schlauesten vor?
Ist ein hex wert...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 03 September 2016, 19:10:29
Hi,

Also im TeamLead einen hohen wert einstellen?
Oder wie gehe ich am schlauesten vor?
Ist ein hex wert...

Setze mal die Generation eins hoch (das sind die ersten zwei Bytes), also wahrscheinlich auf 000100.

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 03 September 2016, 19:23:33
Stellt FHEM sich evtl. nach, wenn du einen TeamCall von einem anderen Rauchmelder aus sendest?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 03 September 2016, 19:30:55
Hallo,

Stellt FHEM sich evtl. nach, wenn du einen TeamCall von einem anderen Rauchmelder aus sendest?

Nein. Der Counter ist pro Geraet und die Rauchmelder merken sich alle Zaehlerstaende der anderen Geraete. Eigentlich sollte man diese Variable nie manuell anpassen muessen. Sollte sie jedoch verloren gehen (z.B. fhem.save korrupt/verloren), dann muss man sie per Hand setzen. Dabei passt man am besten die Generation an (die RM selbst inkrementieren die Generation nach jedem Reboot).

Viele Gruesse
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 03 September 2016, 20:05:13
Danke für die Info.
Was bedeutet "Generation"??

Bei mir ist genau das passiert. fhem.save ist defekt...
Habe in einem Backup den Wert 000006 gelesen.
Aber weder 000100 noch 000200 funktionieren...

Soll ich weiter hoch gehen?
Wenn ich es richtig verstanden habe, ist höher ja egal.

Aber was passiert am Ende, gehts dann wieder auf 0 ??
Und wenn "je Gerät" der Counter gespeichert wird, und alle Signale mit der Adresse des TeamLead gesendet werden, wird dann jeder Alarm (der ja mit der Adresse des TeamLead gesendet wird)
den Counter hochsetzen??

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 03 September 2016, 20:15:34
Hallo,

Was bedeutet "Generation"??

Das ist die "Generation", aus der das letzte Byte ist. Je höher, desto Jünger. In der Nachricht werden diese drei Bytes nicht direkt zusammen gesendet, das letzte Byte ist der normale HM Nachrichtenzähler.

Zitat
Bei mir ist genau das passiert. fhem.save ist defekt...
Habe in einem Backup den Wert 000006 gelesen.
Aber weder 000100 noch 000200 funktionieren...

Hmm, Fhem sollte nicht allzu schnell die Generation hochzählen eigentlich...
Passen die Peerings der einzelnen Teilnehmer noch?

Zitat
Soll ich weiter hoch gehen?
Wenn ich es richtig verstanden habe, ist höher ja egal.

Ja, das kannst Du mal probieren.

Zitat
Aber was passiert am Ende, gehts dann wieder auf 0 ??

Ja, er geht nach FFFFFF wieder auf 0. Aber wie die Teamteilnehmer reagieren hat bisher noch niemand probiert. Ich würde aber annehmen, dass dann die Adresse des TeamLead keine gültigen Nachrichten mehr senden kann und man sich eine neue Adresse suchen muss.

Zitat
Und wenn "je Gerät" der Counter gespeichert wird, und alle Signale mit der Adresse des TeamLead gesendet werden, wird dann jeder Alarm (der ja mit der Adresse des TeamLead gesendet wird) den Counter hochsetzen??

Nein, die einzelnen RM senden schon noch ihre eigene Adresse (allerdings im Empfängerfeld) mit. Und an dieser echten Adresse hängt der Counter in den RM.

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 03 September 2016, 20:42:42
Also ein getConfig auf den Rauchmelder geht.
Internals:
   DEF        48F0F8
   HMLAN1_MSGCNT 11
   HMLAN1_RAWMSG RF1583F99,0001,0A23E58C,FF,FFCF,04A01048F0F81DA462011111130100000000
   HMLAN1_RSSI -49
   HMLAN1_TIME 2016-09-03 20:38:27
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     11
   NAME       EG.bu.Buero.RM2
   NR         467
   NTFY_ORDER 50-EG.bu.Buero.RM2
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:04 - t:10 s:48F0F8 d:1DA462 011111130100000000
   peerList   Rauchmelder.RM2.grp,
   protLastRcv 2016-09-03 20:38:27
   protSnd    6 last_at:2016-09-03 20:38:27
   protState  CMDs_done
   rssi_HMLAN1 min:-41 cnt:1 max:-41 avg:-41 lst:-41
   rssi_at_HMLAN1 avg:-49 max:-49 cnt:6 min:-49 lst:-49
   Readings:
     2016-09-03 14:52:01   Activity        alive
     2016-09-03 13:16:51   D-firmware      1.0
     2016-09-03 13:16:51   D-serialNr      NEQ0243833
     2016-09-03 20:38:27   PairedTo        0x1DA462
     2016-08-29 20:24:08   R-devRepeatCntMax 0
     2016-08-29 20:24:08   R-pairCentral   0x1DA462
     2016-09-03 20:38:27   RegL_00.          02:01 0A:1D 0B:A4 0C:62 16:00 1F:00 00:00
     2016-09-03 14:52:24   alarmTest       ok
     2016-09-03 14:52:24   battery         ok
     2016-09-03 14:52:24   level           0
     2016-09-03 20:38:27   peerList        Rauchmelder.RM2.grp,
     2016-09-03 14:52:24   recentStateType info
     2016-09-03 20:38:27   sdRepeat        off
     2016-09-03 14:52:24   smokeChamber    ok
     2016-09-03 13:19:58   smoke_detect    none
     2016-09-03 14:52:24   state           off
     2016-09-03 20:02:47   teamCall        from TeamDevSD2:7
     2016-09-03 13:19:58   trigLast        Rauchmelder.RM2.grp:0
     2016-09-03 13:19:58   trig_Rauchmelder.RM2.grp 0
   Helper:
     HM_CMDNR   4
     cSnd       011DA46248F0F800040000000000,011DA46248F0F80103
     mId        00AA
     peerIDsRaw ,11111301,00000000
     rxType     6
     Expert:
       def        1
       det        1
       raw        1
       tpl        1
     Io:
       newChn     +48F0F8,00,01,00
       nextSend   1472927907.88581
       rxt        0
       vccu       vccu
       p:
         48F0F8
         00
         01
         00
       prefIO:
         HMLAN1
     Mrssi:
       mNo        04
       Io:
         HMLAN1     -47
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1472927907.81038
       ack:
         HASH(0x164bb90)
         0480021DA46248F0F800
     Rssi:
       Hmlan1:
         avg        -41
         cnt        1
         lst        -41
         max        -41
         min        -41
       At_hmlan1:
         avg        -49
         cnt        6
         lst        -49
         max        -49
         min        -49
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   actCycle   099:00
   actStatus  alive
   alarmDevice Sensor
   alarmSettings alarm7,|EG.bu.Buero.RM2:.*smoke-Alarm.*|Rauch Büro|on
   autoReadReg 5_readMissing
   devStateIcon off:general_ok *:secur_alarm
   event-on-change-reading .*
   expert     251_anything
   firmware   1.0
   group      Rauchmelder EG
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,11111301,
   room       CUL_HM,Rauchmelder
   serialNr   NEQ0243833
   subType    smokeDetector
   webCmd     statusRequest

Hier der TeamLead
Internals:
   DEF        11111301
   HMLAN1_MSGCNT 5
   HMLAN1_RAWMSG E2617F9,0000,0A033B75,FF,FFA0,B9865A2617F9000000A8FE33
   HMLAN1_RSSI -96
   HMLAN1_TIME 2016-09-03 20:02:47
   LASTInputDev HMLAN1
   MSGCNT     5
   NAME       Rauchmelder.RM2.grp
   NR         463
   NTFY_ORDER 50-Rauchmelder.RM2.grp
   STATE      off
   TESTNR     7
   TYPE       CUL_HM
   chanNo     01
   device     TeamDevSD2
   peerList   K.fl.Treppe.RM2,OG.kz.Anna.RM2,OG.kz.Linus.RM2,K.k2.Bastelkeller.RM2,OG.sz.Schlafzimmer.RM2,OG.kz.Maja.RM2,EG.ku.Kueche.RM2,EG.bu.Buero.RM2,EG.wz.Wohnzimmer.RM2,
   sdTeam     sdLead
   Readings:
     2016-09-03 20:01:58   aesCBCCounter   000200
     2016-09-03 13:19:58   eventNo         02
     2016-09-03 13:19:58   level           0
     2016-09-03 14:52:03   peerList        K.fl.Treppe.RM2,OG.kz.Anna.RM2,OG.kz.Linus.RM2,K.k2.Bastelkeller.RM2,OG.sz.Schlafzimmer.RM2,OG.kz.Maja.RM2,EG.ku.Kueche.RM2,EG.bu.Buero.RM2,EG.wz.Wohnzimmer.RM2,
     2016-09-03 13:19:58   smoke_detect    none
     2016-09-03 20:00:19   state           off
     2016-09-03 20:02:47   teamCall        from TeamDevSD2:7
     2016-09-03 13:19:58   trigger_cnt     2
   Helper:
     fkt        sdLead2
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Role:
       chn        1
       vrt        1
     Tmpl:
Attributes:
   alarmDevice Sensor
   alarmSettings |Rauchmelder.RM2.grp:.*smoke-Alarm.*|RauchAlarm2|on
   devStateIcon off:general_ok *:secur_alarm
   group      Rauchmelder Teamleader
   icon       secur_smoke_detector
   model      virtual_1
   peerIDs    47316A01,47343701,487DB901,487EBB01,487F0B01,487F9B01,4882DA01,48F0F801,48FDC801,
   room       Rauchmelder
   webCmd     teamCall:alarmOn:alarmOff

Internals:
   DEF        111113
   HMLAN1_MSGCNT 5
   HMLAN1_RAWMSG E2617F9,0000,0A033B75,FF,FFA0,B9865A2617F9000000A8FE33
   HMLAN1_RSSI -96
   HMLAN1_TIME 2016-09-03 20:02:47
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     5
   NAME       TeamDevSD2
   NR         462
   NTFY_ORDER 50-TeamDevSD2
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Rauchmelder.RM2.grp
   protSnd    7 last_at:2016-09-03 20:02:07
   protState  CMDs_done
   Readings:
     2016-09-03 20:02:47   battery         ok
     2016-09-03 20:02:07   state           CMDs_done
   Helper:
     HM_CMDNR   8
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Io:
       vccu       vccu
       prefIO:
         HMLAN1
     Mrssi:
       mNo
       Io:
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       vrt        1
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   model      virtual_1
   subType    virtual
   webCmd     virtual

Vielleicht kann jemand einen Fehle rentdecken.

Was mich beunruhigt hat ist
Zitat
Ja, er geht nach FFFFFF wieder auf 0. Aber wie die Teamteilnehmer reagieren hat bisher noch niemand probiert. Ich würde aber annehmen, dass dann die Adresse des TeamLead keine gültigen Nachrichten mehr senden kann und man sich eine neue Adresse suchen muss.

... und man sich eine neue Adresse suchen muss-----> was bedeutet das?

Also ich soll jetzt mal von aesCBCCounter 000200 an hochzählen?? 00300 ?? oder 00201 ?

Ach ja, und im Augenblick ändert sich der aesCBCCounter nicht, sollte er nicht bei jeder Message hochzählen??


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 September 2016, 07:42:38
So, habe doch noch ein Backup gefunden und zurückgespielt (Stand: Ende August).

Leider funktioniert es immer noch nicht.
aesCBCCounter ist 000006.
In dieser Zeit ist aber definitiv kein Kommando alarmOn / alarmOff / TeamCall von der Zentrale gesendet worden.

Da ich vermute, dass der Counter nur bei akzeptierten Kommandos hochzählt, sollte es doch damit funktionieren??

Bin etwas ratlos...

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 04 September 2016, 08:13:05
vielleicht bringt ein vergleich mit den werten der anderen rm ein hinweis auf die aktuelle zahl.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 September 2016, 08:53:48
@frank: verstehe ich nicht?
            Welche Werte?
            aesCBCCounter hat nur der TeamLead.
Und da ja der Counter "je Gerät" gezählt wird, bringt mir das auch nichts...


@martin876:  Ich benötige mal einen guten Tipp / Hilfe von Dir...



Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 04 September 2016, 11:37:52
Hallo,

Also ein getConfig auf den Rauchmelder geht.

Ja, nur teamCall und alarmOn/Off benoetigen die CBC-Signatur.

Zitat
Vielleicht kann jemand einen Fehle rentdecken.

So direkt sehen alle Lists gut aus.

Zitat
... und man sich eine neue Adresse suchen muss-----> was bedeutet das?

Dein virtuelles Geraet hat zur Zeit die Adresse 111113. Wenn Du die aenderst ist das fuer die RM ein neues Geraet und der Counter darf wieder bei 0 beginnen. Du musst halt auch das Peering aendern (wofuer nur das normale AES Challenge-Response ohne Counter benoetigt wird).

Zitat
Also ich soll jetzt mal von aesCBCCounter 000200 an hochzählen?? 00300 ?? oder 00201 ?

Probier es aus (also 000300 bzw. 000201). Solange Du das erste Byte auf 00 laesst, hast Du auch noch genug Spielraum nach oben offen.

Zitat
Ach ja, und im Augenblick ändert sich der aesCBCCounter nicht, sollte er nicht bei jeder Message hochzählen??

Der Counter aendert sich bei einem TeamCall nicht? Dann geht etwas anderes schief und CUL_HM kommt gar nicht dazu, die AES-Signatur zu erzeugen.

EDIT: Und die RM kennen auch alle den aktuellen AES-Key? Sonst reagieren sie naemlich einfach nicht...

Viele Gruesse
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 September 2016, 13:03:58
Einen neuen TeamLeader mit neuer ID war auch meine Idee.

Wie mache ich dass jetzt, ohne einen Fehler zu machen?.

1. Die TeamleaderID einfach in FHEM ändern
2. set Rauchmelder_Team2 peerChan 0 EG_Buero_RM2 single set actor

--> Oder muss ich erst unpeeren ??

Zitat
Der Counter aendert sich bei einem TeamCall nicht? Dann geht etwas anderes schief und CUL_HM kommt gar nicht dazu, die AES-Signatur zu erzeugen.
Bedeutet für mich?

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 September 2016, 15:37:56
So,

habe neuen TeamLeader mit anderer ID erstellt.
Alle RMs unset und dann auf neuen TeamLeader set !

Was soll ich sagen, der TeamCall geht immer noch nicht!!!
Dazu ist mir aufgefallen, dass kein Reading aesCBCCounter erstellt wird!

Die RM sind aber im neuen Team angekommen, da auch ein, von einem Rauchmelder ausgelöster TeamCall, funktioniert.

Leider verzeweifel ich gerade, da ist doch was im Argen...

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 September 2016, 19:09:53
OK,

nachdem alle Rauchmelder ein clear und ein getConfig ausgeführt haben, ging nun auch der teamCall!
Komisch.

Danke nochmal!

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 04 September 2016, 19:58:53
Hallo,

nachdem alle Rauchmelder ein clear und ein getConfig ausgeführt haben, ging nun auch der teamCall!

Dann muss Fhem aus irgendeinem Grund gedacht haben, dass das ein Team aus HM-SEC-SD ist (nicht -2). Deshalb wurde auch der CBC-Counter nicht benutzt.

EDIT: Das kann es eigentlich auch nicht sein, da Dein Posting des TeamLeaders ein sdLead2 (fkt) ist. Keine Ahnung was da noch schiefgegangen sein kann.

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: xsasx am 13 September 2016, 09:43:05
So bin gerade mit den 24 durch ;)

Will nun bestellen habe ja seit Beitrag 2 auf die SD-2 gewartet ;)

Ich habe nun volgendes verstanden:

1. SD2 mit FHEM pairen
2. Virtuellen Teamlead erstellen
3. TeamLead peeren
4. alles testen (Alarm, Reichweite etc)

Was mir jetzt noch nicht ganz klar ist ist die AES geschichte. Ich habe einen HMLAN und meines wissens habe ich die letzte HM Komponente mit der orig Software verbunden und dann erst an FHEM dann war das mit AES schon irgendwie ok ? Wie muss ich denn vorgen mit einem HMLAN? Will auf alle Fälle einen eigenen KEy (wie erstell ich den) benutzen da ich hier keine Sicherheitslücke möchte mit einem StandardKey. Da ich die SD2 auch als Alarmgeber haben möchte für mein Alarmanlagen Projekt ;)

Danke vorab! 3 werden bestellt wenn die Fragen zur installation geklärt sind.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Lix am 14 September 2016, 19:58:59
Guten Abend!

Ich spiele mich auch gerade mit der Einrichtung eines SD2 und verfolge diesen Thread schon von Anfang an.

Das Zusammenspiel mit FHEM (Anlernen, TeamLead peeren, Status abfragen) funktioniert soweit.
Ich kann aber mangels Verfügbarkeit des Moduls "Crypt::Rijndael" z.B. keinen Teamcall schicken.

Laut dem Wiki Eintrag zu "AES Encryption" sollte dieses Modul doch nur bei Verwendung eines CULs zum Einsatz kommen
Damit die AES-Kommunikation mit einem CUL genutzt werden kann, muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.
Ich nutze nur einen HMLAN Adapter und bekomme aber die Meldung "need Crypt::Rijndael to generate AES-CBC signature" wenn ich einen Teamcall abschicke.

Da bei mir FHEM auf einem Synology NAS (DS415+) läuft, und ich nach stundenlanger vergeblicher Mühe das Modul nicht installiert bekommen habe, hoffe ich auf eure Unterstützung. Vielleicht findet sich ja jemand der den SD2 ebenfalls auf Synology Equipment betreibt oder mir einen Tipp geben kann.

Viele Grüße
Felix

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 15 September 2016, 07:31:41

Da gibts sogar nen Wikieintrag für. Ich nehme doch mal schwer an, dass du das auf deine Diskstation anwenden bzw. umbasteln kannst.

http://www.fhemwiki.de/w/index.php?title=Synology_Diskstation_DS213%2B&redirect=no (http://www.fhemwiki.de/w/index.php?title=Synology_Diskstation_DS213%2B&redirect=no)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: xsasx am 15 September 2016, 10:12:52
So bin gerade mit den 24 durch ;)

Will nun bestellen habe ja seit Beitrag 2 auf die SD-2 gewartet ;)

Ich habe nun volgendes verstanden:

1. SD2 mit FHEM pairen
2. Virtuellen Teamlead erstellen
3. TeamLead peeren
4. alles testen (Alarm, Reichweite etc)

Was mir jetzt noch nicht ganz klar ist ist die AES geschichte. Ich habe einen HMLAN und meines wissens habe ich die letzte HM Komponente mit der orig Software verbunden und dann erst an FHEM dann war das mit AES schon irgendwie ok ? Wie muss ich denn vorgen mit einem HMLAN? Will auf alle Fälle einen eigenen KEy (wie erstell ich den) benutzen da ich hier keine Sicherheitslücke möchte mit einem StandardKey. Da ich die SD2 auch als Alarmgeber haben möchte für mein Alarmanlagen Projekt ;)

Danke vorab! 3 werden bestellt wenn die Fragen zur installation geklärt sind.

Nochmal ich ! ELV sagt das ich für die die SD2 nur mit der CCU2 gehen nicht mit dem HMLAN (altes rundes ding) stimmt das ? Oder bekomme ich die dennoch in FHEM eingebunden? Dann würde ich bestellen.

Mfg
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 15 September 2016, 10:52:14
Nochmal ich ! ELV sagt das ich für die die SD2 nur mit der CCU2 gehen nicht mit dem HMLAN (altes rundes ding) stimmt das ? Oder bekomme ich die dennoch in FHEM eingebunden? Dann würde ich bestellen.
Nö, das stimmt nicht. Aber ELV bietet nur Support für ihr eigenes Zeug an, FHEM und Konsorten existieren in ihrer Welt nicht, daher die Antwort.

Zitat
Was mir jetzt noch nicht ganz klar ist ist die AES geschichte. Ich habe einen HMLAN und meines wissens habe ich die letzte HM Komponente mit der orig Software verbunden und dann erst an FHEM dann war das mit AES schon irgendwie ok ? Wie muss ich denn vorgen mit einem HMLAN? Will auf alle Fälle einen eigenen KEy (wie erstell ich den) benutzen da ich hier keine Sicherheitslücke möchte mit einem StandardKey.
Die original Software ist mittlerweile nicht mehr nötig. FHEM kann den Key mit dem "assignHmKey" Kommando übertragen.

Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: xsasx am 15 September 2016, 11:49:44
Super DANKE  ! Das wollte ich wissen dann steht der bestellung nichts mehr im Wege!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Lix am 15 September 2016, 11:55:03
Da gibts sogar nen Wikieintrag für. Ich nehme doch mal schwer an, dass du das auf deine Diskstation anwenden bzw. umbasteln kannst.

http://www.fhemwiki.de/w/index.php?title=Synology_Diskstation_DS213%2B&redirect=no (http://www.fhemwiki.de/w/index.php?title=Synology_Diskstation_DS213%2B&redirect=no)

Das wäre der einfachste Weg und auch mein erster Weg gewesen. Der Wiki Eintrag bezieht sich hauptsächlich aufs bootstrapen der Diskstation was ja nicht das Problem wäre.
Leider hat sich in den 2 Jahren einiges getan und meine Diskstation hat eine gänzlich andere Architektur (x86-64bit). Somit schlägt die Installation des besagten Moduls fehl. Und zum selbst Kompilieren fehlt mir das Wissen.
Für das (Synology)-Linux sind derartige Anpassungen immer eine Herausforderung.

Trotzdem danke für Hinweis.

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Lix am 15 September 2016, 11:57:30
Super DANKE  ! Das wollte ich wissen dann steht der bestellung nichts mehr im Wege!

Hey, auf welchem Betriebssystem sollen bei dir die SD2 laufen? Ich nutze auch den HMLAN mit FHEM und zumindest das Einbinden funktioniert problemlos.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 15 September 2016, 12:29:25
Das wäre der einfachste Weg und auch mein erster Weg gewesen. Der Wiki Eintrag bezieht sich hauptsächlich aufs bootstrapen der Diskstation was ja nicht das Problem wäre.
Leider hat sich in den 2 Jahren einiges getan und meine Diskstation hat eine gänzlich andere Architektur (x86-64bit). Somit schlägt die Installation des besagten Moduls fehl. Und zum selbst Kompilieren fehlt mir das Wissen.
Für das (Synology)-Linux sind derartige Anpassungen immer eine Herausforderung.

Trotzdem danke für Hinweis.

Perl läuft ja offensichtlich auf der DS, also brauchst du das ja auch nicht mehr zu compilieren. Dann solltest du auch 'cpan' aufrufen können um dort ein 'install Crypt::Rijndael' absetzen... Dann sollte das Modul installiert werden. Ich hab keine DS, aber nen QNAP NAS, bei dem gehts so.

Es gibt Stimmen, die sagen, dass man keine Perl Module über Cpan installieren soll, da diese - im gegesatz zu welchen die über apt-get installiert werden - nicht mit dem Betriebssystem getestet wurden. Ich selber habe das aber auch schon öfter gemacht und bisher keine Probleme gehabt. Da du das ganze auf einer DS laufen lässt, auf der vermutlich mehr oder weniger wichtige Daten gespeichert werden, solltest du dir der Konsequenzen eines Systemabsturzes im klaren sein bevor du das durchführst.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Lix am 17 September 2016, 11:57:27
Nach ettlichen Versuchen bin ich jetzt endlich weiter gekommen. Für den Fall das jemand ebenfalls Probleme mit der DS und diesem Modul hat ein paar Hinweise.

Möchte man nur die Rauchmelder zum Laufen bekommen, funktioniert das am Besten mit der IPKG Perl Version. Dort klappt auch die Installation des Crypt::Rijndael Moduls.
Leider ist dieser Weg für mich nicht akzeptabel, da mit diesem Perl das DBLog nicht funktioniert. Die dazu benötigten Module lassen sich nicht installieren.

Das DS eigene Perl möchte ich nicht nutzen, da es von der Funktion sehr beschränkt ist und durch ein DSM Update möglicherweise wieder unbrauchbar wird.

Die für mich optimale Variante war bislang ActivePerl. Nur gibt es eben hierbei Probleme mit dem Modul Crypt::Rijndael, dass sich nicht so ohne weiteres installieren lässt.
Grund hierfür dürfte der Unterschied sein, dass das IPKG Perl ohne Threads und das ActivePerl mit der Threads Unterstützung compiliert ist.

Folgende Schritte habe ich ausgeführt bis es endlich geklappt hat.


Nachdem ich selbst das Ganze nur nach langem Try and Error Prinzip hinbekommen, bitte mit Vorsicht genießen und sich zunächst ausführlich in die ganze Thematik einlesen und ggf. das System vorher sichern.

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Lix am 17 September 2016, 12:00:11
Eine kurze Frage hätte ich noch.

Ich lese immer wieder, dass beim Teamcall die Rauchmelder für 10sek leise Piepsen sollen.
Die einzige Reaktion die ich bekomme ist, dass die LED des SD2 eine zeit lang grün blinkt. Aber keine akustische Rückmeldung.
Hat sich hier etwas geändert?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: FFHEM am 17 September 2016, 12:48:24
Ich lese immer wieder, dass beim Teamcall die Rauchmelder für 10sek leise Piepsen sollen.
Die einzige Reaktion die ich bekomme ist, dass die LED des SD2 eine zeit lang grün blinkt. Aber keine akustische Rückmeldung.
Hat sich hier etwas geändert?
Das Gleiche bei mir mit meinen neuen 3 SD2.
Titel: HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 17 September 2016, 12:57:47
Hallo,

wie auch schon weiter oben mal beschrieben, es handelt sich bei dem TeamCall um den sog. Kommunikationstest. In der Anleitung ist dazu nichts von einem piepen beschrieben sondern nur von einem grünen blinken der LED für ich glaube 5 Minuten. Also alles wohl in Ordnung. Das piepen steht wohl bei dem alten SD dann auch so in der Anleitung.


Grüße Christian
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Lix am 19 September 2016, 19:51:22
Alles klar, dann gehört das bei den SD2 so.
Bei soviel Frust beim Einrichten hatte ich wohl zuwenig Nerven für die Anleitung übrig.

Danke für die Erklärung.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Omega am 19 September 2016, 22:29:45
Du bist nicht der Einzige der mit der Einrichtung kämpft.
Mir ist z.B. einiges mit AES nocht nicht klar.

Rijndael-Perl-Modul ist installiert
attr vccu hmKey geheimerSchluessel wurde zugewiesen
neue Rauchmelder wurden in FHEM angelegt
bis dahin scheinbar alles ok, aber dann, mit
set RM_Werkzeugkeller assignHmKey kam keine Kommunikation mehr zustande.
   aesKeyNbr 00 ist allerdings vorhanden
   aesCommToDev steht auf ok

Das Peering hat dann auch nicht mehr funktioniert (wie auch, wenn keine Rückmeldung kommt).

Dann habe ich die RMs auf den Auslieferungsstand zurückgesetzt, die RMs in FHEM gelöscht, Neustart gemacht und von vorne begonnen.

Ausgelassen habe ich dabei die Anweisung
set RM_Werkzeugkeller assignHmKey

Dennoch scheint die Kommunikation zu funktionieren (nachdem missing ack endlich verschwunden ist und nach mehreren getConfig). Peering wurde jetzt auch erfolgreich durchgeführt.
Hier noch ein list eines der Rauchmelder
Internals:
   DEF        4C8157
   HMLAN1_MSGCNT 2
   HMLAN1_RAWMSG R42DA3C48,0001,00362B38,FF,FFD3,03A6104C8157272E570601000024
   HMLAN1_RSSI -45
   HMLAN1_TIME 2016-09-19 16:29:42
   HMLGW_MSGCNT 1
   HMLGW_RAWMSG 0500002103A6104C8157272E570601000024
   HMLGW_RSSI -33
   HMLGW_TIME 2016-09-19 16:29:42
   HMUSB_MSGCNT 1
   HMUSB_RAWMSG E4C8157,0000,48EBC1AD,FF,FFC8,03A6104C8157272E570601000024
   HMUSB_RSSI -56
   HMUSB_TIME 2016-09-19 16:29:42
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     4
   NAME       RM_Werkzeugkeller
   NOTIFYDEV  global
   NR         879
   NTFY_ORDER 50-RM_Werkzeugkeller
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:03 - t:10 s:4C8157 d:272E57 0601000024
   peerList   Rauchmelder_2_Team,
   protCmdDel 3
   protIOerr  1 last_at:2016-09-19 15:29:51
   protLastRcv 2016-09-19 16:29:42
   protResnd  1 last_at:2016-09-19 15:59:20
   protResndFail 1 last_at:2016-09-19 15:59:25
   protSnd    3 last_at:2016-09-19 16:29:42
   protState  CMDs_done
   rssi_HMLAN1 avg:-36 min:-36 max:-36 lst:-36 cnt:1
   rssi_at_HMLAN1 avg:-45 min:-45 max:-45 lst:-45 cnt:2
   rssi_at_HMLGW avg:-33 min:-33 max:-33 lst:-33 cnt:1
   rssi_at_HMUSB avg:-56 min:-56 max:-56 lst:-56 cnt:1
   Readings:
     2016-09-19 15:27:55   Activity        alive
     2016-09-19 14:39:15   CommandAccepted yes
     2016-09-19 14:33:31   D-firmware      1.0
     2016-09-19 14:33:31   D-serialNr      NEQ0446516
     2016-09-19 14:39:16   PairedTo        0x272E57
     2016-09-19 14:33:33   R-devRepeatCntMax 0
     2016-09-19 14:33:33   R-pairCentral   0x272E57
     2016-09-19 14:39:16   RegL_00.        02:01 0A:27 0B:2E 0C:57 16:00 1F:00 00:00
     2016-09-19 14:39:15   aesCommToDev    ok
     2016-09-19 14:39:15   aesKeyNbr       00
     2016-09-19 16:29:42   alarmTest       ok
     2016-09-19 16:29:42   battery         ok
     2016-09-19 16:29:42   level           0
     2016-09-19 15:27:55   peerList        Rauchmelder_2_Team,
     2016-09-19 16:29:42   recentStateType info
     2016-09-19 14:39:16   sdRepeat        off
     2016-09-19 16:29:42   smokeChamber    ok
     2016-09-19 16:29:42   state           off
   Helper:
     HM_CMDNR   3
     cSnd       01272E574C8157010E,01272E574C8157010E
     mId        00AA
     rxType     6
     Ack:
     Expert:
       def        1
       det        1
       raw        1
       tpl        1
     Io:
       newChn     +4C8157,00,01,00
       nextSend   1474295382.63707
       rxt        0
       vccu       vccu
       p:
         4C8157
         00
         01
         00
     Mrssi:
       mNo        03
       Io:
         HMLAN1     -43
         HMLGW      -33
         HMUSB      -56
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLGW
       flg        A
       ts         1474295382.44559
       ack:
         HASH(0x308e028)
         038002272E574C815700
     Rssi:
       Hmlan1:
         avg        -36
         cnt        1
         lst        -36
         max        -36
         min        -36
       At_hmlan1:
         avg        -45
         cnt        2
         lst        -45
         max        -45
         min        -45
       At_hmlgw:
         avg        -33
         cnt        1
         lst        -33
         max        -33
         min        -33
       At_hmusb:
         avg        -56
         cnt        1
         lst        -56
         max        -56
         min        -56
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   devStateIcon off:general_ok *:secur_alarm
   expert     251_anything
   firmware   1.0
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,11000201,
   room       Rauchmelder
   serialNr   NEQ0446516
   subType    smokeDetector
   webCmd     statusRequest

Irgendwelche Tests werde ich jetzt (Uhrzeitbedingt) jetzt nicht mehr durchführen.

Meine eigentlichen Fragen betrifft die AES-Kommunikation:
-   Besteht überhaupt eine AES-Kommunikation?
-   Mit welchem Schlüssel? Meiner oder HM-Standard?
-   Oder bleibt der Schlüssel im RM erhalten trotz Rücksetzen auf den Werkszustand?

Falls schon einer eine Lösung für die Kopplung zweier Rauchmelder_Teams hat – bitte einstellen.

Danke
Holger

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Edi77 am 20 September 2016, 01:40:19
Ich beschäftige mich auch gerade mit dem Thema Rauchmelder.

Ich hatte schon mal einen HM-SEC-SD den ich aber wegen zu vieler Fehlalarme wider stillgelegt habe.
Gibt es beim HM-SEC-SD-2 auch viele Fehlalarme?
Den HM-SEC-SD konnte ich noch mit meinem CUNO ohne AES einfach die Statussignal empfangen, geht das mit dem HM-SEC-SD-2 auch noch? Oder benötige ich dann ein HMLAN?

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: xsasx am 20 September 2016, 14:32:15
Hey, auf welchem Betriebssystem sollen bei dir die SD2 laufen? Ich nutze auch den HMLAN mit FHEM und zumindest das Einbinden funktioniert problemlos.

FHEM Läuft in einer VM unter Ubuntu- sollte ja aber keine Rolle Spielen auf welchem OS Fhem läuft oder ?

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Lix am 20 September 2016, 15:16:11
FHEM Läuft in einer VM unter Ubuntu- sollte ja aber keine Rolle Spielen auf welchem OS Fhem läuft oder ?

Meine Frage zielte eher auf paralellitäten bei der Einrichtung ab. Aber zumindest sollten dich dann nicht die Perl Probleme in Verbindung mit Synology belasten  8)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Lix am 20 September 2016, 15:26:43
Ich bin mir nicht 100%ig sicher, aber soweit ich den Hilfeseiten entnehmen konnte:

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Omega am 20 September 2016, 15:51:16
dann müsste theoretisch bzgl. AES eigentlich alles ok sein.
Ein Teamcall bringt allerdings folgende Meldung im Log:
2016.09.20 15:46:21 3: CUL_HM set Rauchmelder_2_Team teamCall
2016.09.20 15:46:21 1: Adding peer 110002 failed! You have probably forced an unknown aesKey for this device.
Schade, dass die Meldung nicht sagt, welches "this device" denn ist. Hab' ja mehrere. Und lt. den Peerings (und hm configCheck) ist auch alles ok.

Ich versuche jetzt erst noch einmal, den aesKey erneut zuzuweisen. Mal sehen, mit welchem Erfolg.

Nachtrag:
Ein erneutes set <rm> assignHmKey bei allen RM ging diesmal problemlos über die Bühne. Auch der Teamcall und Alarm (meine Ohren klingeln jetzt noch, da alle 3 SD quasi neben mir liegen) funktionieren jetzt.

Fehlt jetzt nur noch die Verbindung zwischen beiden Teams. So langsam bekomme ich meine FHEM-Probleme wieder in den Griff.

LG
Holger
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Edi77 am 20 September 2016, 19:25:20
Wenn ich das richtig verstehe müsste ich dann entweder einen zusätzlichen CUL/CUNO betreiben der im HM Modus läuft und die AES Verschlüsselung läuft dann über Linux, oder ich nehme den HMUSB oder HMLAN der dann die AES Verschlüsselung übernimmt?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Joker am 20 September 2016, 19:55:43
Was nimmt man am besten nun da es den HMLAN ja nicht mehr offiziell gibt?

Der HMUARTLGW kann mit den neuen Rauchmeldern ja nicht reden oder?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Edi77 am 22 September 2016, 01:17:38
Hallo,

Habe noch mal etwas gelesen.
Wenn ich das richtig verstanden habe muss ich trotz HM-LAN AES auf dem FHEM System installieren.
Also könnte ich auch einen RPi1 als FHEM Slave mit einem HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi versehen und hätte somit eine Verbindung zur HomeMatic.
Natürlich muss dort dann auch AES installiert werden, allerdings ist das HM-MOD-RPI-PCB noch käuflich zu erwerben.
Oder habe ich da was falsch verstanden?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 22 September 2016, 07:09:59
Warum geht ein lgw nicht mit sds? Um aes der tramcalls usw. zu betreiben muss fhem aes rechnen, unabhaengig von io.
Hmlan unterstützt aes fuer "normale" kommunikation.das trifft hier eh nicht zu. Wo ist der knackpunkt?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 23 September 2016, 10:38:01
Info: Das im April erworbene 3er-Set ist nunmehr ein 2er-Set. Ein RM hat nun etwa 10 mal bevorzugt zwischen 2-4 Uhr einen Fehlalarm ausgelöst, was sich auch nicht an einem anderen Montageort (Tausch Kellerflur <-> Wohnzimmer) geändert hat. Habe gerade Gewähr bei ELV angefragt.
Wenn man so die anderen Aussagen dazu liest, komme ich auf etwa einen von 8 RM, die nicht rund laufen... Wer kann das bestätigen?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 28 September 2016, 17:19:12
So, der Austauschmelder ist heute hier eingetroffen... Das ging flott, so das ich auch mal was positives zu ELV vermelden kann!

Habe den neuen Melder gerade eingebunden; so weit so gut. Aber ich ahnte schon so was... natürlich geht der vTeamLeader nicht mehr. Also habe ich dort alle peerings gelöscht (und kontrolliert, ob auch alle weg sind) und jeden einzelnen RM erneut mit dem vTL gepeert... Nüscht... Null... nix...
Also offensichtlich ist der Austausch eines defekten RM nicht so trivial wie ich vermutet habe...

Frage ist also, wie ich sinnvoller Weise vorzugehen habe, wenn ich nicht alles komplett von vorne machen möchte; gibt es da eine bestimmte Vorgehensweise, einen Austausch-RM wieder ins Team zu bringen? Könnte nicht mal wer ein WiKi dazu schreiben, welches auch solch ein Thema abhandelt? Ich lese auch gerne Korrektur und solche Sachen...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 29 September 2016, 17:21:20
... da es leider keine Antwort(en) resp. Lösungsansätze gibt und auch ein Löschen aller RM in FHEM, Löschen des TeamLeaders in FHEM, neu Anlernen der RM, erstellen eines neuen TL und peeren mit diesem der vorherige Zustand nicht wieder zu erreichen ist (Alarme werden zwar am TL gemeldet, ein "alarmOn" und/oder "TeamCall" vom TL gesendet bleibt schlicht ohne Reaktion), habe ich den ganzen Kram aus FHEM verbannt. Die RM funktionieren zum Glück auch ohne FHEM in der Vernetzung... Jetzt kann ich mir zwar keine Nachricht mehr zusenden lassen, wenn ein RM ausgelöst hat, aber wenn die Hütte während meiner Abwesenheit in Flammen steht, nutzt mir das eh nix, sollte ich weiter als 5 Minuten weg sein...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: martinp876 am 30 September 2016, 06:24:03
Warum du die funktionierenden geloescht hast ist mir unklar.
Wenn der Key korrekt gesetzt ist sollte erst einmal alles klappen. Ausnahme ist die event Nummer des RM. Diese scheint er sich zu merken und nur zu reagieren, wenn sie passt. Wie dies synchronisiert wird ist bisher nicht erforscht. es stellt ein Problem dar. Ich werde hiermit wohl noch experimentieren müssen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 30 September 2016, 07:56:01
... na, gelöscht habe ich die verbliebenen zwei Funktionierenden, weil der Austausch-RM nicht in die Gruppe zu bringen, alle diesbezüglichen Versuche auch mit Hilfe der Hinweise hier im Forum vergeblich waren und ich keine andere Option mehr sah.
Jetzt ist er zwar in der Gruppe, alle empfangen lt. Logfile den AlarmOn, aber keinen kümmerts... also funktioniert halt der TL nicht mehr. Das ist aber viel eher zu verschmerzen als eine nicht funktionierende Hardware- Gruppe.

Na egal. Hardware alleine funktioniert auch und ist ja auch die Hauptfunktion der RM. Das ist vordringlich und FHEM nur untergeordnet (Überleben vor Spaß)...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: FhemDav am 20 Oktober 2016, 12:21:07
Hallo an alle Forummitglieder,

bin Neuling was fhem angeht und benötige eure Hilfe.
Ist es möglich 8x SD2 in fhem so einzubinden, das jeder einzelne einen Alarm meldet. Ein Beispiel: wenn  4. brennt :-) dann soll 4. und 1. auslösen und mir eine SMS senden 4 brennt. Dies soll für alle anderen gelten 2-8 sollen jeweils einzeln und mit 1. auslösen. Dann benötige ich einen Notfallbefehl der alle gleichzeitig auslöst. Das ganze wäre perfekt wenn ich  alle oder einzeln deaktivieren könnte.

Jemand eine Idee ??
Danke schon mal im vorraus für eure Mühe.
Gruß David

PS: Verzeiht mir wenn ich den falschen Thread dafür ausgewählt habe. ;D
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 25 Oktober 2016, 11:15:50
Hallo,

also dieser Rauchmelder macht mich wahnsinnig!

Er meldet sich immer nach der actCycle Zeit dead!!!

Woran liegt das? Bitte helft mir!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: FhemDav am 31 Oktober 2016, 11:18:23
Bitte um nachsicht sollte ich hier schon beantwortete Fragen stellen, aber ich kann folgende Probleme nicht lösen.
1. Wie kann ich einen am SD ausgelösten Alarm wieder per Fhem stoppen, AarmOff funktioniert nur bei alarmOn über den Teamleader ???
2. Wenn ich den Teamleder auf alarmOn stelle, bekomme ich erst smoke-detected wenn ich danach auf Off stelle angezeigt und das state:off wenn ich wiederholt auf team alarmOff gehe ??

Benötige dringend eure Hilfe ... ansonsten kann ich nächste Woche neue Akkus besorgen  und meine Frau verlangt die Scheidung  ;D
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Pfriemler am 31 Oktober 2016, 23:36:33
Ist es möglich 8x SD2 in fhem so einzubinden, das jeder einzelne einen Alarm meldet. Ein Beispiel: wenn  4. brennt :-) dann soll 4. und 1. auslösen und mir eine SMS senden 4 brennt. Dies soll für alle anderen gelten 2-8 sollen jeweils einzeln und mit 1. auslösen. Dann benötige ich einen Notfallbefehl der alle gleichzeitig auslöst. Das ganze wäre perfekt wenn ich  alle oder einzeln deaktivieren könnte.
Eigentümliches Szenario. Du möchstest also 1. als Generalmelder, der bei allen Ereignissen anspringt, sonst sollen nur die Melder selbst alarmieren... warum? Feuer ist Feuer, da lasse ich lieber alle lärmen. Welcher Melder ausgelöst hat, kann man sich in SMS/Pushover/... ja direkt melden lassen ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Pfriemler am 31 Oktober 2016, 23:43:48
Er meldet sich immer nach der actCycle Zeit dead!!!
Nicht der Rauchmelder meldet sich dead, das macht ActionDetector. actCycle hat dabei nicht unbedingt sinnvolle Vorgaben. Beim alten SD waren die Zeiträume oft zu kurz, so dass es auch dort "dead"-Meldungen gab. Für den SD_2 kenne ich die Meldezeiträume nicht, beim alten SD lagen sie bei 99 Stunden.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: FhemDav am 01 November 2016, 09:32:07
@pfriemler
ungewöhnlich ist das schon .. ich möchte einen Fehlalarm so weit wie möglich ausgrenzen. Also folgenedes hab ich realisiert ... jeder der 8 in ein eigenes Team als Teamleader ... jeder der 7 mit notify mit dem Hauptmelder verkuppelt. Wenn also ein Alarm losgeht werde ich über den Hauptmelder wach, ich geh nachschauen und aktivier über Taster im ernstfall alle. Problem ... wie man es sieht ... ist das deaktivieren des Fehlalarmmelders. Die anderen über Team alarmON bekomme ich deaktiviert. Übrigens liegen die 8 nicht in einer Wohnung sondern jeweils in 4 Etagen je einer im Flur und je 1er in der Etagenwohnung bzw. Keller.

Kannst du mir mit dem Problem weiterhelfen ?

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Pfriemler am 01 November 2016, 23:32:47
Ah ... sowas mit 4 Wohnungen hatte ich mir schon gedacht, bei denen nicht alles gleichzeitig losheulen soll...
Das mit den Fehlalarmen ist so eine Sache, aber im wirklichen Ernstfall ist nix mit mal nachschauen gehen, da kommt es auf jede Sekunde an, die die Bewohner der Hütte eher auf den Beinen sind. Bei mir funktioniert das Deaktivieren des gesamten Teams über einen Rauchmelder jedenfalls einwandfrei, und über Pushover (bei mir ist es die Variante andNotify) lese ich in Sekunden auf dem Handy, welcher der 6 Melder bei mir ausgelöst hat. Das geht schneller als Nachsehen.
Vorteil einer großen Gruppe ist ja gerade, dass sie auch ohne FHEM noch zuverlässig funktioniert. Wenn das Notify nicht ankommt, weil dem Raspi schon der Strom ausgegangen ist, kann das Problem schon unbeherrschbar geworden sein.
Davon ab würde ich aber maximal 7 Teamleader in FHEM definieren, sondern je Wohnung einen mit ggf. mehreren Meldern. Ich steuere meine Rauchmelder jedenfalls über einen in FHEM definierten Teamleader. Die Idee, einen der Melder mit einem separaten Teamleader als Alarmsirene zu missbrauchen, habe ich aus Zuverlässigkeitsüberlegungen wieder verworfen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: dk3572 am 13 November 2016, 12:46:33
Hallo,

könnte mir hierbei einer weiterhelfen?

Rauchmelder_Team
DEF    11111101
NAME Rauchmelder_Team
NOTIFYDEV global
NR 423
NTFY_ORDER 50-Rauchmelder_Team
STATE off
TESTNR 3
TYPE CUL_HM
chanNo 01
device TeamDev
peerList Rauchmelder_EG,Rauchmelder_KG,Rauchmelder_OG
sdTeam sdLead


aesCBCCounter 00000C
eventNo 03
level 0
peerList Rauchmelder_EG,Rauchmelder_KG,Rauchmelder_OG,
smoke_detect none
state off
teamCall from TeamDev:02


Rauchmelder_EG
DEF    4BEF45
HMLAN1_MSGCNT 11
HMLAN1_RAWMSG R5CE55956,0001,00069420,FF,FFD3,86A6104BEF45246BDF0601000027
HMLAN1_RSSI -45
HMLAN1_TIME 2016-11-13 09:54:44
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 11
NAME Rauchmelder_EG
NOTIFYDEV global
NR 416
NTFY_ORDER 50-Rauchmelder_EG
STATE off
TYPE CUL_HM
lastMsg No:86 - t:10 s:4BEF45 d:246BDF 0601000027
peerList Rauchmelder_Team
protCmdDel 2
protIOerr 1 last_at:2016-11-13 09:45:16
protLastRcv 2016-11-13 09:54:44
protNack 1 last_at:2016-11-13 09:53:14
protResnd 1 last_at:2016-11-13 09:54:43
protSnd 4 last_at:2016-11-13 09:54:44
protState CMDs_done
rssi_HMLAN1 avg:-39.5 min:-40 max:-39 lst:-39 cnt:2
rssi_at_HMLAN1 avg:-46.9 min:-48 max:-45 lst:-45 cnt:11


Activity alive
CommandAccepted no
D-firmware 1.0
D-serialNr NEQ0507782
PairedTo 0x246BDF
R-pairCentral 0x246BDF
RegL_00. 02:01 0A:24 0B:6B 0C:DF 16:00 1F:00 00:00
aesCommToDev pending
aesKeyNbr 00
alarmTest ok
battery ok
level 0
peerList Rauchmelder_Team,
recentStateType info
sdRepeat off
smokeChamber ok
smoke_detect none
state off
teamCall from TeamDev:02


Wie bekomme ich das aesCommToDev pending weg?
teamCall funktioniert.

Danke schon mal...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Edi77 am 13 November 2016, 15:42:09
Hallo,

Zuerst möchte ich vorweg schicken das das mein erster Ausflug in die Homematic Welt ist.
Ich habe jetzt ein neues HomeMatic HM-LGW-O-TW-W-EU-2 mit Firmware 1.15 mit meiner FHEM Zentrale verbunden und libcrypt-rijndael-perl installiert.
in fhem.cfg folgende Zeilen eingefügt
# Homematic FunkLan Gateway
define HMLGW HMUARTLGW x.x.x.x
attr HMLGW hmId 123456
attr HMLGW hmKey "geheim;)"
attr HMLGW lgwPw "geheim;)"
attr HMLGW room CUL_HM

Dann habe ich auch einen HM-Sec-SD-2 mit dem FHEM verbinden wollen.
Ich benötige ja, da ich im Moment nur 1x HM-Sec-SD-2 kein Team mit anderen Rauchmeldern, muss ich ihn trotzdem mit sich selbst pairen, oder mit einem VTeamlaeder?

Ist das VTeam so richtig konfiguriert?
define TeamDevSD2 CUL_HM 123456
attr TeamDevSD2 IODev HMLGW
attr TeamDevSD2 modul virtual_1
attr TeamDevSD2 subType virtual
attr TeamDevSD2 webCmd virtual

Ich habe also laut Anleitung den Taster so lange gedrückt gehalten bis die LED orange blinkt, nach eine Weile war der smokeDetector dann sichtbar.

Danach habe ich mit set HM_48CAB6 assignHmKey den AES Key geschickt.

Internals
DEF 48CAB6
HMLGW_MSGCNT 19
HMLGW_RAWMSG 0500002203144148CAB648CAB60103000000007EDC6F17
HMLGW_RSSI -34
HMLGW_TIME 2016-11-13 14:37:25
IODev HMLGW
LASTInputDev HMLGW
MSGCNT 19
NAME HM_48CAB6
NOTIFYDEV global
NR 273
NTFY_ORDER 50-HM_48CAB6
STATE unreachable
TYPE CUL_HM
lastMsg No:03 - t:41 s:48CAB6 d:48CAB6 0103000000007EDC6F17
protCmdDel 28
protLastRcv 2016-11-13 14:37:25
protResnd 26 last_at:2016-11-13 15:26:09
protResndFail 26 last_at:2016-11-13 15:26:14
protSnd 26 last_at:2016-11-13 15:26:06
protState CMDs_done_Errors:1
rssi_at_HMLGW avg:-44.1 cnt:19 min:-53 max:-27 lst:-34

Readings
Activity alive 2016-11-13 14:23:27
D-firmware 1.0 2016-11-13 14:23:27
D-serialNr NEQ0003930 2016-11-13 14:23:27
RegL_00.
state unreachable 2016-11-13 15:26:26
trigger_cnt 3 2016-11-13 14:37:22

Attributes
IODev HMLGW
actCycle 099:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SD-2
msgRepeat 1
room CUL_HM
serialNr NEQ0003930
subType smokeDetector
webCmd statusRequest

Ich hatte auch mal mit etwas Rauch einen Brand simuliert, und den Funktest durchgeführt was auch man auch im Protokoll beobachten konnte, aber mit Activity:alive oder mit Trigger_Cnt: 2 - 3
Aber immer wieder kommt ResndFail, unreachable oder Missing ACK.

2016-11-13_13:24:48 HM_48CAB6 MISSING ACK
2016-11-13_13:25:02 HM_48CAB6 unreachable
2016-11-13_13:55:10 HM_48CAB6 ResndFail
2016-11-13_13:55:10 HM_48CAB6 MISSING ACK
2016-11-13_13:55:23 HM_48CAB6 unreachable
2016-11-13_14:23:27 HM_48CAB6 Activity: alive
2016-11-13_14:23:27 HM_48CAB6 D-firmware: 1.0
2016-11-13_14:23:27 HM_48CAB6 D-serialNr: NEQ0003930
2016-11-13_14:23:30 HM_48CAB6 trigger_cnt: 1
2016-11-13_14:25:33 HM_48CAB6 ResndFail
2016-11-13_14:25:33 HM_48CAB6 MISSING ACK
2016-11-13_14:25:44 HM_48CAB6 unreachable
2016-11-13_14:37:04 HM_48CAB6 trigger_cnt: 2
2016-11-13_14:37:22 HM_48CAB6 trigger_cnt: 3
2016-11-13_14:55:53 HM_48CAB6 ResndFail
2016-11-13_14:55:53 HM_48CAB6 MISSING ACK
2016-11-13_14:56:05 HM_48CAB6 unreachable
2016-11-13_15:12:10 HM_48CAB6 ResndFail
2016-11-13_15:12:10 HM_48CAB6 MISSING ACK

Ich habe mir den wirklich alles durchgelesen, aber gerade der Sonderfall 1x HMLGW und 1x HM-Sec-SD-2 und Verbindung aufbauen ist nicht so gut beschrieben, meist wird ja noch vom alten HM-SEC-SD gesprochen und dem alten HMLAN was man ja wohl nicht vergleichen kann.

Hat jemand eine Idee was ich falsch gemacht habe? :-\
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 13 November 2016, 21:27:18
@Edi77:

der SD2 ist nicht richtig gepairt. Ich bezweifele auch, dass das 'Taster so lange gedrückt halten bis LED orange blinkt' den pairing-Modus auslöst. Ich denke eher, dass das den SD2 resettet - ob das wirklich so ist, steht aber in dessen Bedienungsanleitung. 

Ob du einen HMLAN oder einen HMLGW nutzt sollte unerheblich sein.

Den virtuellen TeamLead kannst du erstellen wie in dem wiki für den alten SD beschrieben.

Die Schritte zum pairen und peeren des SD2 sind hier:
https://forum.fhem.de/index.php/topic,35298.msg460380.html#msg460380
beschrieben.
Bitte nach jedem Schritt überprüfen ob es geklappt hat und erst dann zum nächsten Schritt gehen. Da das pairing schon nicht geklappt hat, funktionieren die danach abgesetzten Befehle natürlich auch nicht.


Gruß
Ingo

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Edi77 am 13 November 2016, 21:44:15
Hallo,

Laut https://files.elv.com/Assets/Produkte/13/1314/131408/Downloads/131408_rauchmelder_um.pdf (https://files.elv.com/Assets/Produkte/13/1314/131408/Downloads/131408_rauchmelder_um.pdf) Seite 13 sollte das Anlernen so funktionieren, oder ist das falsch?

Wenn ich das hier richtig gelesen habe, kann der HMLAN selbst die AES Verschlüsselung zwischen Device und HMLAN regeln, das der HMLGW nicht kann, deswegen muss man ja auf dem Linux libcrypt-rijndael-perl installieren, oder?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 13 November 2016, 21:54:00
@dk3572

das Reading 'aesKeyNbr 00' deutet darauf hin, dass der eigene AES Key noch nicht übertragen wurde.

Wenn der in der vccu oder dem HMlan eingetragene hmKey an das Device übertragen wurde muss bei hmKey das Reading aesKeyNbr auf 02 stehen und bei hmKey02 muss aesKeyNbr auf 04 stehen, usw.




Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 13 November 2016, 22:15:47
für die richtige Funktion des SD2 benötigt man crypt-rijndael auch bei einem HMlan und bei einem HMLGW sowieso.

Da du HM Neuling bist - wie Anlernen/pairing geht weißt du? Du musst den HMLGW auch in den Pairing-Modus versetzen - mit 'set <HMLGW> hmPairForSec 600' und dann die Taste an dem SD2 drücken. Da der Anlernmodus bei jedem HM Gerät unterschiedlich aktiviert wird, sollte das Vorgehen in der Bedienungsanleitung nachgelesen werden. Wenn da also steht 'Drücken bis orange blinkt' dann mach das so.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: dk3572 am 14 November 2016, 07:12:35
aha, das war der entscheidende Hinweis:

Zitat
für die richtige Funktion des SD2 benötigt man crypt-rijndael auch bei einem HMlan und bei einem HMLGW sowieso

Bis jetzt funktioniert alles.

Danke!!!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 14 November 2016, 08:05:46
Hallo,

hab auch riesige Probleme mit meinen HM-SEC-SD2!

Ich verwende einen CUL und wie ich gelesen habe, brauch ich wohl eine VCCU um den Rauchmelder betreiben zu können.

Ich hab das nach der Anleitung im Wiki gemacht, allerdings hänge ich hier:
Definiert man eine VCCU nachdem I/Os (CUL oder HMLAN) für Homematic angelegt sind, sollte die hmId der bereits vorhandene Funkschnittstelle verwenden

Mein CUL hat irgendwie keine hmId! Bekommt er die nicht automatisch beim anlegen? Wenn ich jetzt eine hmId vergebe, bricht die Verbindung zu meinen Sensoren etc. ab!

Ich hoffe ihr könnt mir helfen! Ich dreh noch durch mit dem Ding!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 14 November 2016, 15:22:29
Verstehe ich nicht. Egal was für einen IO du für HM benutzt, eine hmID brauchen die alle. Ich behaupte mal, dass es ohne hmID nicht möglich ist ein HM-Device an FHEM zu pairen. Bei einem HMlan gibt es eine 'HmIdOriginal' die hat das Gerät wie alle HM-Devices von Geburt an und dann gibt es - wenn man möchte - eine 'HmIdAssigned' damit kann man dem HmLan dann eine eigene HmId zuweisen...  Wie das bei einem CUL läuft kann ich dir nicht sagen - habe keinen, zumindest nicht für HM. Eventuell vergibt FHEM automatisch eine zufällige hmID...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: dk3572 am 14 November 2016, 17:40:47
Ich möchte jetzt eine Push Nachricht wenn ein Melder auslöst.
Wie muss hierfür die Bedingung in einem DOIF aussehen?
Mach ich das auf einen Melder, für alle 3 extra oder über den Team Melder?
Und wie kann ich es dann testen? Bin Nichtraucher  ;D

Danke schon mal....
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 14 November 2016, 20:11:36
Hab nur eine FHTID, die is aber nur 4 stellig
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 14 November 2016, 20:42:02
Hallo
Versuchs doch mal mit dem Attribut "hmid"
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 15 November 2016, 08:00:25
Ja, das würde gehen, dann muss ich aber alle Sensoren neu anlernen,oder?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 15 November 2016, 09:04:51
Nicht neu anlernen, sondern überhaupt erst mal anlernen. Schick doch mal ein list von einem der bereits angelernten Devices... und von dem cul...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 15 November 2016, 10:29:40
Ja aber die sind doch schon angelernt, sonst würden sie ja nicht in FHEM funktionieren!
Wie generiere ich so eine Liste?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 15 November 2016, 10:50:34
so lange du nur sensoren hast, fällt dir das evtl. garnicht auf - den funk mithören kann ja jeder. aber wenn du mal nen aktor schalten willst, das geht dann nicht mehr.
mit list <device> , die ausgabe dann in code tags posten.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 15 November 2016, 12:33:15
O.k. mach ich heute Abend mal!
Habe nicht nur Sensoren, hab auch 2 Aktoren!
Du meinst, wenn ich der CUL eine hmId vergebe funktionieren die Sensoren noch, ich muss nur die Aktoren neu anlernen!?


Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 15 November 2016, 13:06:30
Moin
Es ist doch eigentlich gar nicht so schwierig. Gib einfach list <device> ein. Wobei <device> der Name Deines CUL ist. Und beim CUL schaust Du mal was bei dem Attribut "hmid" steht. Wenn es nicht da ist, dann leg es einfach erstmal an, ohne etwas einzutragen! Und dann postest Du uns das list vom CUL, bitte als Code, das geht ueber den "#" ueber den Smilies!
Gruss Christoph
P.S.: Hast Du eigentlich das http://fhem.de/Heimautomatisierung-mit-fhem.pdf hier mal gelesen?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 15 November 2016, 19:56:01
Hier der Code:
Internals:
   CMDS       BCFiAZEkGMKUYRTVWXefltx
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AK059AEV-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AK059AEV-if00-port0@38400
   FD         13
   FHTID      0000
   NAME       nanoCUL
   NR         74
   NR_CMD_LAST_H 10
   PARTIAL
   RAWMSG     A0BE0A2403D64FBF1000001E21F
   RSSI       -58.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.66 nanoCUL868
   initString X21
Ar
   nanoCUL_MSGCNT 1288
   nanoCUL_TIME 2016-11-15 19:46:12
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2016-11-13 16:22:39   cmds             B C F i A Z E k G M K U Y R T V W X e f l t x
     2016-11-15 19:46:12   state           Initialized
   XMIT_TIME:
     1479232268.51606
     1479232793.18985
     1479233069.00947
     1479233127.14187
     1479233756.14253
     1479233842.47409
     1479234721.35053
     1479235123.11533
     1479235484.13591
     1479235572.48406
   Helper:
     3d10cf:
       QUEUE:
     3d64fb:
       QUEUE:
     4c29dc:
       QUEUE:
     4c2a32:
       QUEUE:
     4c2cb3:
       QUEUE:
     4c2cb4:
       QUEUE:
     4c2cb9:
       QUEUE:
     4e4810:
       QUEUE:
     4e4a2a:
       QUEUE:
Attributes:
   rfmode     HomeMatic
   room       Controll
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 15 November 2016, 20:01:44
mach auch mal ein list von einem Device.

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 15 November 2016, 20:05:41
Hier noch ein Sensor:
Internals:
   CHANGED
   DEF        4C29DC
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     53
   NAME       Tuer_Flur_EG
   NOTIFYDEV  global
   NR         95
   NTFY_ORDER 50-Tuer_Flur_EG
   STATE      geschlossen
   TYPE       CUL_HM
   lastMsg    No:F5 - t:10 s:4C29DC d:000000 06010000
   nanoCUL_MSGCNT 53
   nanoCUL_RAWMSG A0DF586104C29DC00000006010000::-62.5:nanoCUL
   nanoCUL_RSSI -62.5
   nanoCUL_TIME 2016-11-15 19:36:50
   protCmdDel 4
   protLastRcv 2016-11-15 19:36:50
   protResnd  3 last_at:2016-11-13 18:56:17
   protResndFail 1 last_at:2016-11-13 19:52:03
   protSnd    4 last_at:2016-11-13 19:51:58
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL avg:-63.79 lst:-62.5 cnt:53 min:-66 max:-60
   Readings:
     2016-11-13 16:22:42   Activity        alive
     2016-09-25 13:23:56   D-firmware      1.0
     2016-09-25 13:23:56   D-serialNr      NEQ0629456
     2016-09-24 19:58:32   R-pairCentral   set_0xF10000
     2016-09-24 20:00:40   aesKeyNbr       00
     2016-11-15 19:36:50   alive           yes
     2016-11-15 19:36:50   battery         ok
     2016-11-15 19:36:50   contact         closed (to broadcast)
     2016-09-24 20:05:35   powerOn         2016-09-24 20:05:35
     2016-11-15 19:36:50   recentStateType info
     2016-11-15 19:36:50   sabotageError   off
     2016-11-15 19:36:50   state           closed
     2016-11-12 11:25:09   trigDst_broadcast noConfig
     2016-11-12 11:25:09   trigger_cnt     172
   Helper:
     HM_CMDNR   245
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4C29DC,00,00,00
       nextSend   1479235010.89801
       prefIO
       rxt        2
       vccu
       p:
         4C29DC
         00
         00
         00
     Mrssi:
       mNo        F5
       Io:
         nanoCUL    -60.5
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul:
         avg        -63.7924528301887
         cnt        53
         lst        -62.5
         max        -60
         min        -66
Attributes:
   IODev      nanoCUL
   actCycle   002:20
   actStatus  alive
   alarmDevice Sensor
   autoReadReg 4_reqStatus
   devStateIcon offen:fts_door_open@red tilted:fts_door tilt@red geschlossen:fts_door@green
   event-min-interval 1
   event-on-change-reading .*
   eventMap   open:offen closed:geschlossen
   expert     2_raw
   firmware   1.0
   fp_EG      202,561,1,Tuer_Flur_EG,
   group      Flur_EG
   model      HM-SEC-SCo
   room       Sensor_EG
   serialNr   NEQ0629456
   subType    threeStateSensor
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 15 November 2016, 20:32:20
Hier noch ein Sensor:
   protState  CMDs_done_Errors:1
   
     2016-09-24 19:58:32   R-pairCentral   set_0xF10000
   

also wie deine Aktoren von FHEM aus gesteuert werden können ist mir rätselhaft!

wie du da oben an den Readings siehst, sind die HM-Devices nicht gepairt. FHEM ist das egal, gepairt wird nur, weil die HM-Devices das brauchen.

Also du solltest deinem CUL per attr eine hmId zuweisen.
Besser wäre wenn du direkt eine vccu einrichtest und die hmId dort zuweist, dann brauchst du beim cul nix weiter machen.

Dann einfach den CUL (oder die vccu falls du dich dafür entscheidest) in den pairing Modus versetzen mit set CUL hmPairForSec 600 und die HM-Devices nochmal in den pairing Modus bringen.

Danach bei jedem Device darauf achten, dass folgende Readings:
PairedTo 0x355867
R-pairCentral 0x355867
(natürlich mit deiner hmId...)
vorhanden sind. Erst dann ist das pairing abgeschlossen. solange davor ein 'set_'steht so wie bei dir, ist das pairing nicht abgeschlossen und die HM-Devices kennen ihre Zentrale nicht.
Falls noch ein 'set_' da steht, ein getConfig durchführen, wenn dann immer noch ein 'set_' da ist, erneut pairen...

Die konfiguration in deinem FHEM kannst du so lassen wie sie ist - die Devices also nicht löschen vor dem erneuten (quasi erstmaligen) anlernen.

EDIT sagt:
Das sind anfürsich Grundkenntnisse...

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 15 November 2016, 21:03:47
Ohhh.....das hört sich ja an als ob alles nur glückssache wäre das überhaupt was funktioniert!

Aber die VCCU muss/soll die die gleiche hmId haben wie die CUL! Also muss ich doch erst der CUL eine hmId vergeben!

Danke schon mal für euere Unterstützung und ein big sorry für meine Unwissenheit!  ...... blondi halt! :-)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: mgernoth am 15 November 2016, 21:47:31
Hallo,

Aber die VCCU muss/soll die die gleiche hmId haben wie die CUL! Also muss ich doch erst der CUL eine hmId vergeben!

Der CUL baut sich eine eigene hmId, wenn keine definiert ist: F1<FHTID>, also hast Du zur Zeit F10000 als hmId. Sollte eigentlich kein Problem sein. Gib die ID einfach der VCCU.

Viele Grüße
  Michael
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 15 November 2016, 23:09:18
Hab es jetzt geschaft eine VCCU anzulegen mit der vom CUL "selbstgebauten" hmId.

Dann hab ich jetzt meinen Rauchmelder mit der VCCU gepair..... jetzt bringt er mir aber nur MISSING ACK!
Hier mal der Code:
Internals:
   CFGFN
   DEF        48CB18
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     15
   NAME       Rauchmelder_Flur_DG
   NOTIFYDEV  global
   NR         555
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:B9 - t:02 s:48CB18 d:F10000 008C5C80F4
   nanoCUL_MSGCNT 15
   nanoCUL_RAWMSG A0EB9800248CB18F10000008C5C80F4::-55.5:nanoCUL
   nanoCUL_RSSI -55.5
   nanoCUL_TIME 2016-11-15 22:52:33
   protCmdDel 6
   protLastRcv 2016-11-15 22:52:33
   protResnd  4 last_at:2016-11-15 23:02:04
   protResndFail 2 last_at:2016-11-15 23:02:09
   protSnd    18 last_at:2016-11-15 23:02:02
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL min:-72 max:-55.5 avg:-61.43 cnt:15 lst:-55.5
   Readings:
     2016-11-15 22:46:10   Activity        alive
     2016-11-15 22:52:33   CommandAccepted yes
     2016-11-15 22:46:06   D-firmware      1.0
     2016-11-15 22:46:06   D-serialNr      NEQ0004029
     2016-11-15 22:48:59   PairedTo        0xF10000
     2016-11-15 22:48:59   R-pairCentral   0xF10000
     2016-11-15 22:48:59   RegL_00.          02:01 0A:F1 0B:00 0C:00 16:00 1F:00 00:00
     2016-11-15 22:52:33   aesCommToDev    ok
     2016-11-15 22:52:33   aesKeyNbr       02
     2016-11-15 22:48:59   sdRepeat        off
     2016-11-15 23:02:09   state           MISSING ACK
   Helper:
     HM_CMDNR   186
     cSnd       01F1000048CB180103,01F1000048CB1801011111110100
     mId        00AA
     peerIDsRaw ,00000000
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +48CB18,00,01,00
       nextSend   1479246753.95243
       prefIO
       rxt        0
       vccu
       p:
         48CB18
         00
         01
         00
     Mrssi:
       mNo        B9
       Io:
         nanoCUL    -53.5
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf   00
       qReqStat   00
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul:
         avg        -61.4333333333333
         cnt        15
         lst        -55.5
         max        -55.5
         min        -72
     Shadowreg:
Attributes:
   IODev      nanoCUL
   IOgrp      VCCU:nanoCUL
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,
   room       Rauchmelder
   serialNr   NEQ0004029
   subType    smokeDetector
   webCmd     statusRequest
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 16 November 2016, 07:13:35
Moin,

hat sich geklärt, nach einem Teamcall war das MISSING ACK weg!

LG Marlen
Titel: HM-SEC-SD-2 neu: Batterie Warnung
Beitrag von: friesenjung am 18 November 2016, 09:55:09
Hallo Zusammen,

auch wenn die Batterien der neuen Rauchmelder wohl noch bei niemanden leer waren, versuch ich es trotzdem mal  mit meiner Frage ;) Vlt. hat ja doch jmd. beim Testen mal die Batterie-Leer-Warnung gehabt.

Nun konkret: Ich überlege gerade mir diese Rauchmelder zuzulegen. Neben dem Sicherheitsaspekt, wünsche ich mir auch einen weiteren Comfort. Ihr kennt das, Rauchmelder piepsen bei leeren Batterien eigentlich immer nachts, also zum ungünstigsten Zeitpunkt.

Im Manual des SD-2 steht, dass er die Warnmeldung zum Einen akustisch (wie alle anderen auch) und zum Anderen per Funk-Nachricht an eine CCU oder eben FHEM sendet.

Nun wäre es ja super, wenn der Rauchmelder schon vor dem akustischen Warnsignal eine leer werdende Batterie "stumm" an FHEM sendet, damit man genug Zeit hat den Melder auszutauschen (oder wie weiter vorn beschrieben) eine neue Batterie zu verbauen.

Gibt es Erfahrungen wie die "Batterie-Leer-Meldung" vor sich geht? Sendet der Melder vielleicht mehrere bzw. unterschiedliche Meldungen, wie "Batterie ok", "Batterie geht zur Neige" und "Batterie ist jetzt leer"?

Über eine Rückmeldung würde ich mich sehr freuen...

Danke...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 18 November 2016, 12:31:25
Gibt es Erfahrungen wie die "Batterie-Leer-Meldung" vor sich geht? Sendet der Melder vielleicht mehrere bzw. unterschiedliche Meldungen, wie "Batterie ok", "Batterie geht zur Neige" und "Batterie ist jetzt leer"?
Also ich habe die alten SD und die senden an die Zentrale und piepsen "zur gleichen Zeit". Allerdings ist es sehr dezent, also kein "Feueralarm".

Aber selbst wenn da noch ein Abstand ist, nach Murphy kommt die Mail Nacht drei und piepsen zwei Stunden später  :D (war bei mir so in der Art)

Kann aber sein das es bei den neuen anders ist. Aber solange hat die noch keiner   ::)

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 18 November 2016, 22:09:25
Gibt es Erfahrungen wie die "Batterie-Leer-Meldung" vor sich geht? Sendet der Melder vielleicht mehrere bzw. unterschiedliche Meldungen, wie "Batterie ok", "Batterie geht zur Neige" und "Batterie ist jetzt leer"
Für Erfahrungen musst vermutlich 8 Jahre warten oder die Batterie ausbauen und mit'm Labor-Netzteil simulieren. Was ich aber definitiv weiss ist dass unterschiedliche Warn-Level nicht vorgesehen sind.

Gruss Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: friesenjung am 20 November 2016, 23:43:35
Nabend und Danke für eure Rückmeldungen. Ich glaube ich bestell mal welche und schau mal in 8 Jahren ;)
PS: falls doch jemand irgendwann mal was genaueres rausfindet, nur raus damit ;)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: dk3572 am 23 November 2016, 14:57:11
Hallo,
evtl. untergegangen, aber ich bekomme es einfach nicht hin.
Könnte mir hierfür bitte einer behilflich sein?

Zitat
Ich möchte jetzt eine Push Nachricht wenn ein Melder auslöst.
Wie muss hierfür die Bedingung in einem DOIF aussehen?
Mach ich das auf einen Melder, für alle 3 extra oder über den Team Melder?
Und wie kann ich es dann testen? Bin Nichtraucher  ;D

Danke schon mal....

So habe ich es unter Anderem versucht:

(["Rauchmelder_Team:^smoke_Alarm"]) (set.....

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 23 November 2016, 15:33:44
Hi,

und das Beispiel aus dem Wiki gefällt Dir nicht?  ::)
  define sd.nf.report notify sdTeam:.*smoke-Alarm.* {\
    <Mail versenden>;;
    fhem("set LichtTreppenhaus on");;
  }\

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 23 November 2016, 15:46:03
https://www.amazon.de/LogiLink-Rauchmelder-Test-Spray-150-RP0011/dp/B00IFBFY8E/ref=sr_1_1?ie=UTF8&qid=1479912227&sr=8-1&keywords=testspray+f%C3%BCr+rauchmelder (https://www.amazon.de/LogiLink-Rauchmelder-Test-Spray-150-RP0011/dp/B00IFBFY8E/ref=sr_1_1?ie=UTF8&qid=1479912227&sr=8-1&keywords=testspray+f%C3%BCr+rauchmelder)
für die Nichtraucher...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: dk3572 am 23 November 2016, 15:52:02
@Otto123
doch, das gefällt mir. Hab ich wohl überlesen.
Hab parallel meine Alexa in Fhem eingebunden. War wohl etwas zu viel  ;)

Um nicht schon wieder unnötig Alarm auszulösen, wäre es für ein DOIF dann so richtig?
([Rauchmelder_Team:.*smoke-Alarm.*]) (set...

@automatisierer
Danke für den Link, jetzt kann ich endlich meinen Grill wieder nach draußen stellen  ;D
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 23 November 2016, 16:19:50

Um nicht schon wieder unnötig Alarm auszulösen, wäre es für ein DOIF dann so richtig?
([Rauchmelder_Team:.*smoke-Alarm.*]) (set...


definitv nein!

wenn du auf ein Event reagieren willst, dann so:
(["Rauchmelder_Team:smoke-Alarm"]) (set...
dann reagiert er auf alles was 'Rauchmelder_Team' im Devicenamen und 'smoke-Alarm' im Event hat.
attr ... do always nicht vergessen, sonst gibts die Meldung nur beim ersten Feuer...

die Commandref zu DOIF solltest du wohl auch noch mal in Ruhe lesen...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 23 November 2016, 16:30:06
Ich würde das mit einem notify machen!
Ich bin bestimmt kein Skeptiker, ich setze auch gerne DOIF ein. Aber bei so etwas simplen und fundamentalem würde ich es auch simpel und einfach halten und ein notify nehmen! DOIF ist ein komfortables IF mit vielen Features, aber hier braucht man kein IF, hier kommt einfach ein klares Event.
DOIF wird quasi stündlich weiterentwickelt und bei so einem simplen Event weiß ich bei einem notify genau warum er triggert und warum nicht.
Eh ich mich da bei DOIF in der dritten Klammerebene und den Anführungszeichen sowie attributen verhakt habe ...  :-X

Aber muss jeder wissen.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: dk3572 am 23 November 2016, 17:01:13
Perfekt, funktioniert, vielen Dank an alle.

@automatisierer
Glaube mir, das habe ich schon wer weiß wie oft gelesen.
Und viele, viele weitere Dokumentationen und Forenbeiträge.
Aber manchmal braucht es einfach mal einen kleinen Anstupser  ;)

Also dann, Danke noch mal....
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Peter_Listig am 30 Dezember 2016, 20:03:22
Hallo in die Runde,

habe seit einigen Tagen zwei HM-SEC-SD-2.
Wurden auch in FHEM erkannt (Pairing erfolgreich)
Einer ist testweise mit sich selbst gepeert, der andere ohne Peering.

ActionDetector ist auch vorhanden
und sagt
alive:2 dead:0 unkn:0 off:0

Soweit meine Lösung ...
Jetzt hätte ich gerne ein Problem von Euch ...

Wie löse ich einen TeamCall oder einen Alarm über FHEM aus?
Was fehlt mir dazu?
Dreht mich bitte mal in die richtige Richtung ...
und gebt mir einen Schubser.

Habt Dank

Greetz
Peter
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 30 Dezember 2016, 21:02:18
Hallo Peter,

steht alles im Wiki. Das peeren mit sich selbst war dazu kontraproduktiv.

-> virtueller Teamlead!

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Peter_Listig am 30 Dezember 2016, 21:51:50
Danke Otto,

peeren mit sich selbst hab ich rückgängig gemacht.

Zum virtuellen TeamLeader noch eine Frage:
Kann man damit gezielt einen einzelnen RM
zum piepen oder tröten bringen?

Gruß
Peter



Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 30 Dezember 2016, 21:58:49
Hallo Peter,

ich würde sagen nö. Das ist nicht Sinn und Zweck der Übung.

Wenn Du das willst solltest Du nicht die Rauchmelder als Alarm missbrauchen wollen.

Die RM lassen sich auch nicht mehrfach peeren.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Peter_Listig am 30 Dezember 2016, 22:50:31
Ok Otto,

das war der Plan ...
ein Rudel RM die bei Feuer losheulen
und ein Einzelner der als Alarm miss-
braucht wird ...
Dann fang ich eben mit dem Rudel (vorerst 2  ;) ) an.

Im Wiki steht:
Zitat
define TeamDev CUL_HM 111111
set TeamDev virtual 1
rename TeamDev_Btn1 Rauchmelder_Team

Da meine beiden RM jeweils mit HM_474xxx angelegt wurden,
würde ich analog dazu HM_474111 verwenden und dann in
"RM_Team_1" umbenennen.
Unklar ist mir was der Befehl "set TeamDev virtual 1"bewirkt.

ein Tipp hierzu wäre nett.

Danke
Peter


Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 30 Dezember 2016, 23:02:10
Hallo Peter,

also Du machst
define HM_474111 CUL_HM 474111
set HM_474111 virtual 1
rename HM_474111_Btn1 RM_Team_1
Das define erzeugt ein virtuelles HM Gerät.
der set Befehl erzeugt einen virtuellen Kanal der ist zum peeren wichtig.
Dieser Kanal wird umbenannt.

Spiel das ruhig durch bis dahin passiert gar nichts  8)

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Klinki am 31 Dezember 2016, 09:56:21
Hi Peter,


habe seit einigen Tagen zwei HM-SEC-SD-2.
...
Wie löse ich einen TeamCall oder einen Alarm über FHEM aus?
...
Dreht mich bitte mal in die richtige Richtung ...
und gebt mir einen Schubser.

Oder nutze doch das Alarm-Modul https://wiki.fhem.de/wiki/Modul_Alarmanlage (https://wiki.fhem.de/wiki/Modul_Alarmanlage). Ist ein wenig hakelig, aber wenn es läuft, kann man sehr flexibel seine Sensoren und Aktoren damit verknüpfen.
Wenn Du aber nur 2 Bewegungsmelder hast, dann bleib auf Otto´s Weg.

Hinweis am Rande: Die Melder erfassen auch Lichtintensität.Lässt sich u.A. für eine Beschattungssteuerung nutzen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 31 Dezember 2016, 10:44:10
Wenn Du aber nur 2 Bewegungsmelder hast, dann bleib auf Otto´s Weg.
Es ging aber um Rauchmelder  :o

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Peter_Listig am 03 Januar 2017, 19:30:40
Hallo  zusammen,

nachdem ich wieder im Lande bin, erstmal allen Mitstreitern -helfern die besten Wünsche fürs neue Jahr !

@Klinki

vielen Dank für Deinen Link "Alarmanlage",
mein Plan ist eher etwas einfacher gestrickt.
Aber dazu später.

@Otto

ich bin nach Deinem Vorschlag vorgegangen:

define HM_474000 CUL_HM 474000
set HM_474000 virtual 1
rename HM_474000_Btn1 RM_Team_1

Hat auch soweit hingehauen.

Als nächstes habe ich nach der Anleitung im wiki
die beiden RM auf den virtuellen Teamleader gepeert

was offensichtlich auch gelungen ist.

Anbei ein Screenshot.

Aber irgendwas passt noch nicht ganz, ein Alarm lässt sich
damit nicht auslösen.

Bin für jeden Hinweis dankbar.

Greetz
Peter
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 03 Januar 2017, 19:56:28
Dir auch ein gesundes Neues jahr!
poste mal bitte ein list HM_47433C
list HM_474372
und bitte nicht als Screenshot, dass kann keiner lesen!

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Peter_Listig am 03 Januar 2017, 23:05:50
Hi Otto,

hat etwas gedauert, da Gattin Plan B hatte ...

1. HM_47433C

Internals:
   CUL868_MSGCNT 5
   CUL868_RAWMSG A0EB5800247433CF0003482FFE9E73F::-53:CUL868
   CUL868_RSSI -53
   CUL868_TIME 2017-01-03 19:20:53
   DEF        47433C
   IODev      CUL868
   LASTInputDev CUL868
   MSGCNT     5
   NAME       HM_47433C
   NOTIFYDEV  global
   NR         803
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:B5 - t:02 s:47433C d:F00034 82FFE9E73F
   protCmdDel 2
   protLastRcv 2017-01-03 19:20:53
   protNack   1 last_at:2017-01-03 19:20:53
   protResnd  1 last_at:2017-01-03 18:57:48
   protResndFail 1 last_at:2017-01-03 18:57:54
   protSnd    6 last_at:2017-01-03 19:20:52
   protState  CMDs_done_Errors:1
   rssi_at_CUL868 avg:-53.1 max:-52.5 lst:-53 min:-54 cnt:5
   Readings:
     2017-01-01 17:40:28   Activity        alive
     2017-01-03 19:20:53   CommandAccepted no
     2016-12-30 16:24:17   D-firmware      1.0
     2016-12-30 16:24:17   D-serialNr      NEQ0000408
     2016-12-30 16:24:18   PairedTo        0xF00034
     2016-12-30 16:24:18   R-pairCentral   0xF00034
     2017-01-03 19:20:53   aesCommToDev    fail
     2017-01-03 19:20:52   aesKeyNbr       00
     2017-01-03 14:23:13   alarmTest       ok
     2017-01-03 14:23:13   battery         ok
     2016-12-30 18:33:19   eventNo         02
     2017-01-03 14:23:13   level           0
     2017-01-03 14:23:13   recentStateType info
     2016-12-30 16:24:18   sdRepeat        off
     2017-01-03 14:23:13   smokeChamber    ok
     2017-01-03 19:29:31   smoke_detect    none
     2017-01-03 19:29:31   state           off
     2017-01-03 19:29:31   teamCall        from HM_474000:00
   Helper:
     HM_CMDNR   181
     cSnd       01F0003447433C01014740000201,01F0003447433C01014740000100
     mId        00AA
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +47433C,00,05,00
       nextSend   1483467653.11301
       prefIO
       rxt        0
       vccu
       p:
         47433C
         00
         05
         00
     Mrssi:
       mNo        B5
       Io:
         CUL868     -51
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_cul868:
         avg        -53.1
         cnt        5
         lst        -53
         max        -52.5
         min        -54
Attributes:
   IODev      CUL868
   actCycle   099:00
   actStatus  alive
   aesKey     5
   autoReadReg 4_reqStatus
   devStateIcon off:general_ok *:secur_alarm@red
   event-on-change-reading .*
   expert     2_raw
   firmware   1.0
   icon       secur_smoke_detector@orange
   model      HM-SEC-SD-2
   msgRepeat  1
   room       SENSOREN
   serialNr   NEQ0000408
   subType    smokeDetector
   webCmd     statusRequest

2. HM_474372

Internals:
   CHANGED
   CUL868_MSGCNT 6
   CUL868_RAWMSG A0D8EA610474372F0003406010000::-50.5:CUL868
   CUL868_RSSI -50.5
   CUL868_TIME 2017-01-03 20:13:58
   DEF        474372
   IODev      CUL868
   LASTInputDev CUL868
   MSGCNT     6
   NAME       HM_474372
   NOTIFYDEV  global
   NR         804
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:8E - t:10 s:474372 d:F00034 06010000
   protCmdDel 2
   protLastRcv 2017-01-03 20:13:57
   protNack   1 last_at:2017-01-03 18:58:35
   protResnd  1 last_at:2017-01-03 19:21:28
   protResndFail 1 last_at:2017-01-03 19:21:33
   protSnd    6 last_at:2017-01-03 20:13:58
   protState  CMDs_done
   rssi_at_CUL868 lst:-50.5 max:-48.5 avg:-49.4 cnt:5 min:-50.5
   Readings:
     2017-01-01 17:40:28   Activity        alive
     2017-01-03 18:58:35   CommandAccepted no
     2016-12-30 16:35:50   D-firmware      1.0
     2016-12-30 16:35:50   D-serialNr      NEQ0000354
     2016-12-30 16:35:50   PairedTo        0xF00034
     2016-12-30 16:35:50   R-pairCentral   0xF00034
     2017-01-03 18:58:35   aesCommToDev    fail
     2017-01-03 18:58:35   aesKeyNbr       00
     2017-01-03 20:13:58   alarmTest       ok
     2017-01-03 20:13:58   battery         ok
     2017-01-03 20:13:58   level           0
     2016-12-30 16:34:55   powerOn         2016-12-30 16:34:55
     2017-01-03 20:13:58   recentStateType info
     2016-12-30 16:35:50   sdRepeat        off
     2017-01-03 20:13:58   smokeChamber    ok
     2017-01-03 19:29:31   smoke_detect    none
     2017-01-03 20:13:58   state           off
     2017-01-03 19:29:31   teamCall        from HM_474000:00
   Helper:
     HM_CMDNR   142
     cSnd       01F0003447437201014740000201,01F0003447437201014740000100
     mId        00AA
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +474372,00,00,00
       nextSend   1483470838.04557
       prefIO
       rxt        0
       vccu
       p:
         474372
         00
         00
         00
     Mrssi:
       mNo        8E
       Io:
         CUL868     -48.5
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         CUL868
       flg        A
       ts         1483470837.95043
       ack:
         HASH(0x19721b0)
         8E8002F0003447437200
     Rssi:
       At_cul868:
         avg        -49.4
         cnt        5
         lst        -50.5
         max        -48.5
         min        -50.5
Attributes:
   IODev      CUL868
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   devStateIcon off:general_ok *:secur_alarm@red
   event-on-change-reading .*
   expert     2_raw
   firmware   1.0
   icon       secur_smoke_detector@orange
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,
   room       SENSOREN
   serialNr   NEQ0000354
   subType    smokeDetector
   webCmd     statusRequest

3. RM_Team_1

Internals:
   CFGFN
   CUL868_MSGCNT 1
   CUL868_RAWMSG A11B5A00247433CF0003404C9D00C57A46400::-53.5:CUL868
   CUL868_RSSI -53.5
   CUL868_TIME 2017-01-03 19:20:52
   DEF        47400001
   LASTInputDev CUL868
   MSGCNT     1
   NAME       RM_Team_1
   NOTIFYDEV  global
   NR         17910
   STATE      set_press long
   TESTNR     0
   TYPE       CUL_HM
   chanNo     01
   device     HM_474000
   peerList   HM_47433C,HM_474372,
   sdTeam     sdLead
   Readings:
     2017-01-03 19:29:50   aesCBCCounter   00000E
     2017-01-03 19:29:31   eventNo         00
     2017-01-03 19:22:38   level           198
     2017-01-03 19:21:26   peerList        HM_47433C,HM_474372,
     2017-01-03 19:29:31   smoke_detect    none
     2017-01-03 19:29:37   state           set_press long
     2017-01-03 19:29:31   teamCall        from HM_474000:00
   Helper:
     count      7
     fkt        sdLead2
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
       vrt        1
Attributes:
   model      virtual_1
   peerIDs    47433C01,47437201,
   room       SENSOREN
   webCmd     press short:press long

4. ActionDetector

Internals:
   CHANGED
   DEF        000000
   IODev      CUL868
   NAME       ActionDetector
   NOTIFYDEV  global
   NR         801
   STATE      alive:2 dead:0 unkn:0 off:0
   TYPE       CUL_HM
   Readings:
     2017-01-03 22:50:30   state           alive:2 dead:0 unkn:0 off:0
     2017-01-03 22:50:30   status_HM_47433C alive
     2017-01-03 22:50:30   status_HM_474372 alive
   Helper:
     HM_CMDNR   1
     actCycle   600
     peers      47433C,474372
     47433c:
       start      2017-01-01 17:40:28
     474372:
       start      2017-01-01 17:40:28
     Io:
       prefIO
       vccu
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
Attributes:
   IODev      CUL868
   event-on-change-reading .*
   icon       secur_smoke_detector
   model      ActionDetector
   room       SENSOREN
   subType    smokeDetector

Ich hoffe man kann dadurch auf meine(n) Fehler schließen.

Danke
Peter
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 03 Januar 2017, 23:34:44
Hi,

das peering ist bei den Meldern nicht angekommen, Internals peerlist und Attribute peerids fehlen.

Der Teamleader hat die Info, die RM aber nicht.
Zitat
Bei jedem Rauchmelder sollte der Name des virtuellen TeamLeaders in der peerList stehen und beim virtuellen TeamLeader jeder Rauchmelder.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Peter_Listig am 04 Januar 2017, 00:10:42
Okay Danke einstweilen,

werde ich mir Morgen mal ansehen.

Gute Nacht
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Klinki am 04 Januar 2017, 06:41:31
Hallo Peter,

Otto hat wohl Recht. Ich kann mich noch an meine erste Gruppe an Rauchmeldern erinnern. Das war auch ein ziemlicher Krampf, bis ich die Geräte untereinander gepeert hatte.
Bin dabei aber komplett über fhem gegangen...

gruß
klinki
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 04 Januar 2017, 07:02:30
Nix Krampf! Es gibt eine Anleitung, wenn man diese schritt für schritt befolgt, dann ist alles wunderbar.

@ Peter:


1. HM_47433C

Internals:

     2017-01-03 19:20:53   aesCommToDev    fail
     2017-01-03 19:20:52   aesKeyNbr       00


2. HM_474372

Internals:

     2017-01-03 18:58:35   aesCommToDev    fail
     2017-01-03 18:58:35   aesKeyNbr       00


Falls du (wie es empfohlen wird) einen eigene AES Key benutzt, dann wurde dieser noch nicht erfolgreich übertragen, da aesKeyNbr noch auf 00 steht. Daher auch aesCommToDev fail.

das Perl Modul cryp-rijndael (oder so änlich) hast du installiert?

Das wichtigste ist, auch wenn man die Anleitung befolgt, das man jeden Schritt durchführt und nach jedem Schritt überprüft , ob auch alles abgearbeitet wurde und im Gerät angekommen ist. Soll heißen: keine CMDs_pending mehr !!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 Januar 2017, 08:02:03
Hallo,

leider muss ich an hier auch nochmal einsteigen, ich dachte ich wäre mit SDs durch...

Ich habe nun mal alle SD2s aufgerufen und nach aesKeyNbr gesucht. Leider hatten nicht alle diesen Eintrag!
Wenn ich es aber richtig lese sind diese trotzdem gepeert und gepairt. Ein getConfig geht auch:
Nur ein assignHmKey verursacht ein MISSING_ACK !!

teamCall funktioniert aber bei diesen Geräten!!

Hier das List:
Internals:
   CUL0_MSGCNT 2
   CUL0_RAWMSG A1205A01048FDC81DA462011111140100000000::-66:CUL0
   CUL0_RSSI  -66
   CUL0_TIME  2017-01-04 07:57:28
   DEF        48FDC8
   HMLAN1_MSGCNT 4
   HMLAN1_RAWMSG R6844ADD9,0001,0CDCEF9D,FF,FFD7,05A01048FDC81DA462011111140100000000
   HMLAN1_RSSI -41
   HMLAN1_TIME 2017-01-04 07:57:28
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     6
   NAME       EG_Wohnzimmer_RM2
   NOTIFYDEV  global
   NR         475
   NTFY_ORDER 50-EG_Wohnzimmer_RM2
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:05 - t:10 s:48FDC8 d:1DA462 011111140100000000
   peerList   Rauchmelder_Team_2,
   protCmdDel 4
   protLastRcv 2017-01-04 07:57:28
   protResnd  2 last_at:2017-01-04 07:46:33
   protResndFail 2 last_at:2017-01-04 07:46:39
   protSnd    7 last_at:2017-01-04 07:57:28
   protState  CMDs_done
   rssi_at_CUL0 cnt:2 max:-66 avg:-66 min:-66 lst:-66
   rssi_at_HMLAN1 lst:-41 min:-41 avg:-41 max:-41 cnt:4
   Readings:
     2017-01-03 22:57:12   Activity        alive
     2016-09-05 18:27:11   D-firmware      1.0
     2016-09-05 18:27:11   D-serialNr      NEQ0246331
     2017-01-04 07:57:28   PairedTo        0x1DA462
     2016-09-04 16:30:46   R-pairCentral   0x1DA462
     2017-01-04 07:57:28   RegL_00.          02:01 0A:1D 0B:A4 0C:62 16:00 1F:00 00:00
     2017-01-03 18:26:34   alarmTest       ok
     2017-01-03 18:26:34   battery         ok
     2017-01-03 18:26:34   level           0
     2017-01-04 07:57:28   peerList        Rauchmelder_Team_2,
     2016-12-20 15:48:37   powerOn         2016-12-20 15:48:37
     2017-01-03 18:26:34   recentStateType info
     2017-01-04 07:57:28   sdRepeat        off
     2017-01-03 18:26:34   smokeChamber    ok
     2016-09-04 21:15:00   smoke_detect    none
     2017-01-04 07:46:39   state           MISSING ACK
     2016-09-04 21:14:48   teamCall        from TeamDevSD_2:02
   Helper:
     HM_CMDNR   5
     cSnd       011DA46248FDC800040000000000,011DA46248FDC80103
     mId        00AA
     peerIDsRaw ,11111401,00000000
     rxType     6
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       lRcTm      508914904
       lstRecType 10
       newChn     +48FDC8,00,01,00
       nextSend   1483513048.54839
       nxtSndMcnt 05
       rxt        0
       tgtDly     120
       vccu       vccu
       p:
         48FDC8
         00
         01
         00
       prefIO:
         HMLAN1
     Mrssi:
       mNo        05
       Io:
         CUL0       -66
         HMLAN1     -39
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1483513048.74381
       ack:
         HASH(0x38b6758)
         0580021DA46248FDC800
     Rssi:
       At_cul0:
         avg        -66
         cnt        2
         lst        -66
         max        -66
         min        -66
       At_hmlan1:
         avg        -41
         cnt        4
         lst        -41
         max        -41
         min        -41
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   actCycle   099:00
   actStatus  alive
   alarmDevice Sensor
   alarmSettings alarm7,|EG_Wohnzimmer_RM2:.*smoke-Alarm.*|Rauch Wohnzimmer|on
   autoReadReg 0_off
   devStateIcon off:general_ok *:secur_alarm
   event-on-change-reading .*
   expert     2_raw
   firmware   1.0
   group      Rauchmelder EG
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,11111401,
   room       CUL_HM,Rauchmelder
   serialNr   NEQ0246331
   subType    smokeDetector
   webCmd     statusRequest

hier ein SD bei dem aes drin steht:
Internals:
   CHANGED
   CUL0_MSGCNT 1
   CUL0_RAWMSG A0D90A61048F0F81DA46206010000::-41.5:CUL0
   CUL0_RSSI  -41.5
   CUL0_TIME  2017-01-04 02:44:19
   DEF        48F0F8
   HMLAN1_MSGCNT 1
   HMLAN1_RAWMSG E48F0F8,0000,0BBE3288,FF,FFCD,90A61048F0F81DA46206010000
   HMLAN1_RSSI -51
   HMLAN1_TIME 2017-01-04 02:44:19
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     2
   NAME       EG_Buero_RM2
   NOTIFYDEV  global
   NR         473
   NTFY_ORDER 50-EG_Buero_RM2
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:90 - t:10 s:48F0F8 d:1DA462 06010000
   peerList   Rauchmelder_Team_2,
   protLastRcv 2017-01-04 02:44:19
   protSnd    1 last_at:2017-01-04 02:44:19
   protState  CMDs_done
   rssi_at_CUL0 min:-41.5 avg:-41.5 lst:-41.5 cnt:1 max:-41.5
   rssi_at_HMLAN1 min:-51 avg:-51 lst:-51 cnt:1 max:-51
   Readings:
     2017-01-03 22:57:12   Activity        alive
     2016-09-04 15:25:57   CommandAccepted yes
     2016-06-08 13:53:01   D-firmware      1.0
     2016-06-08 13:53:01   D-serialNr      NEQ0243833
     2016-09-04 16:28:38   PairedTo        0x1DA462
     2016-06-06 21:59:31   R-devRepeatCntMax 0
     2016-06-06 21:59:31   R-pairCentral   0x1DA462
     2016-09-04 16:28:38   RegL_00.        02:01 0A:1D 0B:A4 0C:62 16:00 1F:00 00:00
     2016-09-04 15:25:57   aesCommToDev    ok
     2016-09-04 15:25:57   aesKeyNbr       02
     2016-06-12 21:35:48   aesReqTo        vccu
     2017-01-04 02:44:19   alarmTest       ok
     2017-01-04 02:44:19   battery         ok
     2017-01-04 02:44:19   level           0
     2017-01-03 22:57:12   peerList        Rauchmelder_Team_2,
     2016-12-23 01:25:03   powerOn         2016-12-23 01:25:03
     2017-01-04 02:44:19   recentStateType info
     2016-09-04 16:28:38   sdRepeat        off
     2017-01-04 02:44:19   smokeChamber    ok
     2017-01-04 08:10:05   smoke_detect    none
     2017-01-04 08:10:05   state           off
     2017-01-04 08:08:51   teamCall        from TeamDevSD_2:02
     2016-08-24 20:08:23   trigLast        Rauchmelder_Team2:2
     2016-08-24 20:08:23   trig_Rauchmelder_Team2 2_1
   Helper:
     HM_CMDNR   144
     mId        00AA
     rxType     6
     Ack:
     Expert:
       def        1
       det        1
       raw        1
       tpl        1
     Io:
       lRcTm      490125488
       lstRecType 10
       newChn     +48F0F8,00,01,00
       nextSend   1483494259.81013
       nxtSndMcnt 90
       rxt        0
       tgtDly     120
       vccu       vccu
       p:
         48F0F8
         00
         01
         00
       prefIO:
         HMLAN1
     Mrssi:
       mNo        90
       Io:
         CUL0       -41.5
         HMLAN1     -49
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         CUL0
       flg        A
       ts         1483494259.89494
       ack:
         HASH(0x37b5348)
         9080021DA46248F0F800
     Rssi:
       At_cul0:
         avg        -41.5
         cnt        1
         lst        -41.5
         max        -41.5
         min        -41.5
       At_hmlan1:
         avg        -51
         cnt        1
         lst        -51
         max        -51
         min        -51
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   actCycle   099:00
   actStatus  alive
   alarmDevice Sensor
   alarmSettings alarm7,|EG_Buero_RM2:.*smoke-Alarm.*|Rauch Büro|on
   autoReadReg 0_off
   devStateIcon off:general_ok *:secur_alarm
   event-on-change-reading .*
   expert     251_anything
   firmware   1.0
   group      Rauchmelder EG
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,11111401,
   room       CUL_HM,Rauchmelder
   serialNr   NEQ0243833
   subType    smokeDetector
   webCmd     statusRequest


Greets
Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 04 Januar 2017, 09:28:49
Nix Krampf! Es gibt eine Anleitung, wenn man diese schritt für schritt befolgt, dann ist alles wunderbar.

@ Peter:

Falls du (wie es empfohlen wird) einen eigene AES Key benutzt, dann wurde dieser noch nicht erfolgreich übertragen, da aesKeyNbr noch auf 00 steht. Daher auch aesCommToDev fail.

das Perl Modul cryp-rijndael (oder so änlich) hast du installiert?

Das wichtigste ist, auch wenn man die Anleitung befolgt, das man jeden Schritt durchführt und nach jedem Schritt überprüft , ob auch alles abgearbeitet wurde und im Gerät angekommen ist. Soll heißen: keine CMDs_pending mehr !!
Steht ganz oben im Wiki!
Zitat
Der HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, er benötigt dafür zwingend das Modul libcrypt-rijndael-perl unabhängig vom IO Device, auch für den HM-CFG-LAN!
Da gibt es dann aber sogar meines Wissen entsprechende Fehlereinträge im Log.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 04 Januar 2017, 10:03:46
und cul's immer mit der ts-firmware aus dem angepinnten thread nutzen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 Januar 2017, 10:16:13
Jepp, derzeit TSCUL_fwcode_00_05_02_FHEM_Modules_00_05_02.zip
und trotzdem gehts nicht
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 04 Januar 2017, 12:10:08
Jepp, derzeit TSCUL_fwcode_00_05_02_FHEM_Modules_00_05_02.zip
und trotzdem gehts nicht
bestens. nach deinem list ist der cul aktuell auch gar nicht an der kommunikation beteiligt.

Zitat
Nur ein assignHmKey verursacht ein MISSING_ACK !!
zufall? öfter probiert?
schon mal mit dem cul probiert, indem du ihn zuvor als prefered io setzt?

hminfo configcheck ist sicherlich sauber.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 Januar 2017, 12:33:09
War mir klar, wollte ihn als Fehlerquelle ausschließen. Nun habe ich auf ihn umgestellt.
2017.01.04 12:31:26.260 4: TSCUL_Parse: CUL0  491443 A FF21 12672960 00 0F 81 865E 3BD2E7 000000 ED49DC00CEA4 -80.5
2017.01.04 12:31:36.889 4: TSCUL_send:  CUL0                         As 19 08 B004 1DA462 48FDC8 2ebf99d85b8bf19c7f249e91565b7429
2017.01.04 12:31:37.507 4: TSCUL_Parse: CUL0  502691 A FF33 12683640 01 19 08 B004 1DA462 48FDC8 2E _bst _CCAdly:4 -138
2017.01.04 12:31:38.032 4: TSCUL_Parse: CUL0  503215 A FF33 12684232 01 19 08 B004 1DA462 48FDC8 2E _bst _CCAdly:4 -138
2017.01.04 12:31:38.558 4: TSCUL_Parse: CUL0  503741 A FF33 12684824 01 19 08 B004 1DA462 48FDC8 2E _bst _CCAdly:4 -138
2017.01.04 12:31:38.813 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 48FDC8/EG_Wohnzimmer_RM2: AFF3000306419001908B0041DA46248FDC82E
2017.01.04 12:31:38.813 4: TSCUL_Parse: CUL0  503996 A FF30 12685412 00 19 08 B004 1DA462 48FDC8 2E _bst _sfail -138
2017.01.04 12:31:40.258 4: TSCUL_send:  CUL0                         As 19 08 B004 1DA462 48FDC8 2ebf99d85b8bf19c7f249e91565b7429
2017.01.04 12:31:40.863 4: TSCUL_Parse: CUL0  506046 A FF33 12687008 01 19 08 B004 1DA462 48FDC8 2E _bst _CCAdly:4 -138
2017.01.04 12:31:41.246 4: TSCUL_Parse: CUL0  506428 A FF33 12687600 01 19 08 B004 1DA462 48FDC8 2E _bst _CCAdly:4 -138
2017.01.04 12:31:41.901 4: TSCUL_Parse: CUL0  507082 A FF43 12688192 01 19 08 B004 1DA462 48FDC8 2E _bst _CCAdly:4 -138
2017.01.04 12:31:42.223 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 48FDC8/EG_Wohnzimmer_RM2: AFF4000306763001908B0041DA46248FDC82E
2017.01.04 12:31:42.223 4: TSCUL_Parse: CUL0  507405 A FF40 12688780 00 19 08 B004 1DA462 48FDC8 2E _bst _sfail -138

Hier das Log. Auch wiederholte Versuche brachten den gleichen Misserfolg!


hier nochmal Log mit HMLAN
2017.01.04 12:36:03.297 0: HMLAN_Send:  HMLAN1 I:K
2017.01.04 12:36:03.301 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0640815 d:2CD8CE O:1DA462 t:00BDD401 IDcnt:001C L:2 %
2017.01.04 12:36:10.651 4: TSCUL_send:  CUL0                         As 19 0A B004 1DA462 48FDC8 1540aac527dc64dc4fe2aa158476e515
2017.01.04 12:36:11.246 4: TSCUL_Parse: CUL0  252141 A FF43 12957412 01 19 0A B004 1DA462 48FDC8 15 _bst _CCAdly:4 -138
2017.01.04 12:36:11.247 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:00BDF228 d:FF r:FFCE     m:0A B004 1DA462 48FDC8 1540AAC527DC64DC4FE2AA158476E515
2017.01.04 12:36:11.787 4: TSCUL_Parse: CUL0  252682 A FF43 12958004 01 19 0A B004 1DA462 48FDC8 15 _bst _CCAdly:4 -138
2017.01.04 12:36:11.788 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:00BDF477 d:FF r:FFCE     m:0A B004 1DA462 48FDC8 1540AAC527DC64DC4FE2AA158476E515
2017.01.04 12:36:12.317 4: TSCUL_Parse: CUL0  253212 A FF43 12958596 01 19 0A B004 1DA462 48FDC8 15 _bst _CCAdly:4 -138
2017.01.04 12:36:12.318 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:00BDF6C7 d:FF r:FFCE     m:0A B004 1DA462 48FDC8 1540AAC527DC64DC4FE2AA158476E515
2017.01.04 12:36:12.576 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 48FDC8/EG_Wohnzimmer_RM2: AFF4000316F7400190AB0041DA46248FDC815
2017.01.04 12:36:12.576 4: TSCUL_Parse: CUL0  253471 A FF40 12959184 00 19 0A B004 1DA462 48FDC8 15 _bst _sfail -138
2017.01.04 12:36:14.028 4: TSCUL_send:  CUL0                         As 19 0A B004 1DA462 48FDC8 1540aac527dc64dc4fe2aa158476e515
2017.01.04 12:36:14.551 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:00BDFF59 d:FF r:FFCE     m:0A B004 1DA462 48FDC8 1540AAC527DC64DC4FE2AA158476E515
2017.01.04 12:36:14.557 4: TSCUL_Parse: CUL0  255452 A FF43 12960788 01 19 0A B004 1DA462 48FDC8 15 _bst _CCAdly:4 -138
2017.01.04 12:36:15.077 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:00BE01A8 d:FF r:FFCE     m:0A B004 1DA462 48FDC8 1540AAC527DC64DC4FE2AA158476E515
2017.01.04 12:36:15.083 4: TSCUL_Parse: CUL0  255978 A FF43 12961380 01 19 0A B004 1DA462 48FDC8 15 _bst _CCAdly:4 -138
2017.01.04 12:36:15.600 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:00BE03F8 d:FF r:FFCE     m:0A B004 1DA462 48FDC8 1540AAC527DC64DC4FE2AA158476E515
2017.01.04 12:36:15.606 4: TSCUL_Parse: CUL0  256501 A FF53 12961972 01 19 0A B004 1DA462 48FDC8 15 _bst _CCAdly:4 -138
2017.01.04 12:36:15.863 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 48FDC8/EG_Wohnzimmer_RM2: AFF50003172C000190AB0041DA46248FDC815
2017.01.04 12:36:15.863 4: TSCUL_Parse: CUL0  256758 A FF50 12962560 00 19 0A B004 1DA462 48FDC8 15 _bst _sfail -138
2017.01.04 12:36:18.513 0: HMLAN_Send:  HMLAN1 I:K
2017.01.04 12:36:18.517 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0640815 d:2CD8CE O:1DA462 t:00BE0F72 IDcnt:001C L:2 %
2017.01.04 12:36:22.596 4: TSCUL_Parse: CUL0  263491 A FF51 12969356 00 0F 83 865E 3BD2E7 000000 ED4B9800CBE8 -79.5
2017.01.04 12:36:22.855 0: HMLAN_Parse: HMLAN1 R:E3BD2E7   stat:0000 t:00BE1F60 d:FF r:FFB9     m:83 865E 3BD2E7 000000 ED4B9800CBE8
2017.01.04 12:36:33.767 0: HMLAN_Send:  HMLAN1 I:K
2017.01.04 12:36:33.771 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0640815 d:2CD8CE O:1DA462 t:00BE4B0C IDcnt:001C L:2 %
Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 04 Januar 2017, 13:15:32
der rauchmelder bleibt einfach stumm. null reaktion. seltsam, als wäre er nicht gepairt, würde tief schlafen oder hätte keine batterien.

ich würde den befehl beim funktionierenden rm probieren, um ein bug in fhem auszuschliessen, falls es hier funktioniert.
und danach wohl ein werkreset mit neukonfiguriereung am anderen rm probieren.

ich musste auch gerade einen fensterkontakt resetten, da dieser auf einmal völlig autonom auf aes gesetzt war und sich nicht mehr mit normalen mitteln umkonfigurieren liess.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 Januar 2017, 13:18:50
Also,

assignHmKey an bereits AES-Key übertragenem RM ging auch nicht, bekomme ebenfalls MISSING ACK!
ABER: überall geht getConfig UND der teamCall geht auch an ALLEN RMs !!!

Sie reagieren also auf bestimmte Befehle, nur der assignHMKey geht nicht !!!
FHEM-Fehler ??


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 04 Januar 2017, 13:37:29
Zitat
FHEM-Fehler ??
keine ahnung.
vielleicht hat der andere ja auch schon den schlüssel und nur das reading ist irgendwie verloren gegangen.

schon mal versucht ein register bei dem problemkind zu ändern? da sollte nach meinem verständnis, nach erfolgreicher änderung, anschliessend der genutzte schlüssel erkennbar sein.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 Januar 2017, 15:02:07
@frank, welches Register ändere ich wie?
Ich bin für jede Hilfe dankbar und versuche es...

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 04 Januar 2017, 15:30:09
@frank, welches Register ändere ich wie?
Ich bin für jede Hilfe dankbar und versuche es...
mögliche register mit wertebereichen siehst du mit get regList.
mit set regSet wird es dann gesetzt.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 04 Januar 2017, 15:59:56
Also da ist nicht viel Spielraum.
Sign geht nicht.
devRepeatCntMax habe ich auf 0 und 1 gesetzt. Kommando geht auch raus und wird mit done akzeptiert. Ändert aber nichts an der Anzeige..
Ich glaube die Kommunikation ist noch nicht ganz ausgereift mit den RMs...


Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 04 Januar 2017, 17:04:46
Ich glaube die Kommunikation ist noch nicht ganz ausgereift mit den RMs...
Ich denke, dass hat nichts mit den RM's zu tun. AES ist generell ein bissl tricky...

Also bei mir läuft die ganze Geschichte einwandfrei. Und bisher nur ein Fehlalarm in etwas über einem halben Jahr - holzklopf!!

Ich hatte das Problem mit dem assignHmKey reproduzierbar bei HM_SEC_SCo - konnte den nur übertragen wenn ich sign off gesetzt hab. (evtl. hätte wie Frank sagt, auch irgend ein anderes Register geholfen - hab ich nicht getestet)

Also ich würd den RM an deiner Stelle mal resetten... Hab gestern bei einem HM_WDS10_TH_O die Register auslesen wollen, danach hat er sich immer 5 Minuten nach dem Batterie einlegen wieder verabschiedet. Resett und nu tut er wieder...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Peter_Listig am 05 Januar 2017, 23:08:18
@Otto

hab alles nochmal rausgehauen und gaaaanz langsam von vorn angefangen.
auf Werkseinstellungen zurück
per autocreate erkennen lassen
gepairt
teamLeader angelegt
gepeert

und geprüft wie Du es empfohlen hast.

Zitat
"Bei jedem Rauchmelder sollte der Name des virtuellen TeamLeaders in der peerList stehen und beim virtuellen TeamLeader jeder Rauchmelder."

beim virtuellen TeamLeader jeder Rauchmelder ...    :-)

Internals:
   CFGFN
   CUL868_MSGCNT 1
   CUL868_RAWMSG A1104A00247433CF0003404AF9FDD5B6A5A00::-56.5:CUL868
   CUL868_RSSI -56.5
   CUL868_TIME 2017-01-05 18:54:39
   DEF        47411101
   LASTInputDev CUL868
   MSGCNT     1
   NAME       Team_01
   NOTIFYDEV  global
   NR         855
   STATE      off
   TESTNR     1
   TYPE       CUL_HM
   chanNo     01
   device     TeamDev
  [b] peerList   RM_01,RM_02, [/b]
   sdTeam     sdLead
   Readings:
     2017-01-05 22:28:39   aesCBCCounter   00000E
     2017-01-05 22:28:39   eventNo         00
     2017-01-05 22:27:48   level           2
     [b]2017-01-05 18:54:38   peerList        RM_01,RM_02, [/b]
     2017-01-05 22:28:39   smoke_detect    none
     2017-01-05 22:28:39   state           off
     2017-01-05 22:28:39   teamCall        from TeamDev:00
     2017-01-05 22:27:48   trigger_cnt     1
   Helper:
     count      4
     fkt        sdLead2
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
       vrt        1
Attributes:
   model      virtual_1
  [b] peerIDs    47433C01,47437201, [/b]
   room       SENSOREN
   webCmd     press short:press long

Bei jedem Rauchmelder sollte der Name des virtuellen TeamLeaders in der  PeerList stehen   ...   :-(

Internals:
   CUL868_MSGCNT 3
   CUL868_RAWMSG A0E05A61047433CF000340601000033::-57.5:CUL868
   CUL868_RSSI -57.5
   CUL868_TIME 2017-01-05 22:26:38
   DEF        47433C
   IODev      CUL868
   LASTInputDev CUL868
   MSGCNT     3
   NAME       RM_01
   NOTIFYDEV  global
   NR         821
   NTFY_ORDER 50-RM_01
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:05 - t:10 s:47433C d:F00034 0601000033
   protCmdDel 2
   protLastRcv 2017-01-05 22:26:38
   protResnd  2 last_at:2017-01-05 18:52:34
   protResndFail 2 last_at:2017-01-05 18:52:39
   protSnd    6 last_at:2017-01-05 22:26:38
   protState  CMDs_done
   rssi_CUL868 avg:-51 max:-51 min:-51 cnt:1 lst:-51
   rssi_at_CUL868 max:-56.5 avg:-56.83 min:-57.5 lst:-57.5 cnt:3
   Readings:
     2017-01-05 18:47:52   Activity        alive
     2017-01-05 18:54:39   CommandAccepted yes
     2017-01-05 18:22:21   D-firmware      1.0
     2017-01-05 18:22:21   D-serialNr      NEQ0000408
     2017-01-05 18:22:21   PairedTo        0xF00034
     2017-01-05 18:22:21   R-pairCentral   0xF00034
     2017-01-05 18:22:21   RegL_00.        02:01 0A:F0 0B:00 0C:34 16:00 1F:00 00:00
     2017-01-05 18:54:39   aesCommToDev    ok
     2017-01-05 18:54:39   aesKeyNbr       00
     2017-01-05 22:26:38   alarmTest       ok
     2017-01-05 22:27:48   battery         ok
     2017-01-05 22:26:38   level           0
     2017-01-05 18:03:54   powerOn         2017-01-05 18:03:54
     2017-01-05 22:26:38   recentStateType info
     2017-01-05 18:22:21   sdRepeat        off
     2017-01-05 22:26:38   smokeChamber    ok
     2017-01-05 22:28:39   smoke_detect    none
     2017-01-05 22:28:39   state           off
     2017-01-05 22:28:39   teamCall        from TeamDev:00
     2017-01-05 22:27:48   trigLast        Team_01:2
     2017-01-05 22:27:48   trig_Team_01    2_1
   Helper:
     HM_CMDNR   5
     alarmNo    01
     cSnd       01F0003447433C01014741110100,01F0003447433C010E
     mId        00AA
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +47433C,00,00,00
       nextSend   1483651598.20466
       prefIO
       rxt        0
       vccu
       p:
         47433C
         00
         00
         00
     Mrssi:
       mNo        05
       Io:
         CUL868     -55.5
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         CUL868
       flg        A
       ts         1483651598.11013
       ack:
         HASH(0x352a438)
         058002F0003447433C00
     Rssi:
       Cul868:
         avg        -51
         cnt        1
         lst        -51
         max        -51
         min        -51
       At_cul868:
         avg        -56.8333333333333
         cnt        3
         lst        -57.5
         max        -56.5
         min        -57.5
Attributes:
   IODev      CUL868
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
  [b] peerIDs    00000000,[/b]
   room       SENSOREN
   serialNr   NEQ0000408
   subType    smokeDetector
   webCmd     statusRequest

Trotz fehlender PeerList bei beiden RM reagieren sie auf einen teamCall und blinken fröhlich vor sich hin.
Ein AlarmOn lässt beide im Wettstreit abwechselnd tröten. AlarmOff beendet die Musik wieder ...

Irgendwie läuft es meinem Empfinden nach aber noch nicht sauber.

Dies nur als Zwischennachricht an Dich und die anderen Mitstreiter
- werde dran bleiben und weiter berichten.

Noch eine Frage zum Schluß:
Spricht etwas gegen einen zweiten TeamLead ?
Also Team_01 für RM_01 und Team_02 für RM_02 ...
verbinden kann man die RM sicher mit einem notify ??

Greetz
Peter


Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Edi77 am 06 Januar 2017, 02:50:43
Hallo,

Ich habe jetzt meinem HM-SEC-SD-2 über die HMUARTLGW mit FHEM verbinden.

Einen Teamlead erzeugt
define TeamDev CUL_HM 111111
set TeamDev virtual 1

set TeamDev_Btn1 peerChan 0 HM_48CAB6 single set actor
save

verbunden.
Im Teamlead also auch im Rauchmelder stehen beide in der peerList also soweit ok, vermute ich.
Jetzt habe ich im set TeamDev_Btn1 alarmOn alarmOff teamCall usw. getestet, keine Reaktion.

Was könnte die Ursache sein?

Ich habe im Moment nur 1x HM-SEC-SD-2 und 1x HMUARTLGW

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 06 Januar 2017, 09:29:59
Moin,

hast Du Einträge im Log?

Zitat
Der HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, er benötigt dafür zwingend das Modul libcrypt-rijndael-perl unabhängig vom IO Device, auch für den HM-CFG-LAN!
Hast Du installiert?

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Edi77 am 06 Januar 2017, 14:56:30
Hallo,

Ja ist installiert, wenn ich den Knopf kurz drücke für einen Test, erscheint das auch in der log Datei vom Rauchmelder.

2017-01-06_02:34:09 HM_48CAB6 ResndFail
2017-01-06_02:34:09 HM_48CAB6 MISSING ACK
2017-01-06_02:34:16 HM_48CAB6 unreachable
2017-01-06_02:34:22 HM_48CAB6 ResndFail
2017-01-06_02:34:22 HM_48CAB6 RESPONSE TIMEOUT:RegisterRead
2017-01-06_02:34:48 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:34:48 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:34:48 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:34:52 HM_48CAB6 sdRepeat: off
2017-01-06_02:36:31 HM_48CAB6 alarmTest: ok
2017-01-06_02:36:31 HM_48CAB6 battery: ok
2017-01-06_02:36:31 HM_48CAB6 level: 0
2017-01-06_02:36:31 HM_48CAB6 smokeChamber: ok
2017-01-06_02:36:31 HM_48CAB6 off

Was mir nicht gefällt ist das missing ack
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 06 Januar 2017, 14:58:53
willkommen im Club!
MISSING ACK ist eines der beliebtesten Antworten meiner RM

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 06 Januar 2017, 14:59:22
Zitat
2017-01-06_02:34:09 HM_48CAB6 ResndFail
2017-01-06_02:34:09 HM_48CAB6 MISSING ACK
2017-01-06_02:34:16 HM_48CAB6 unreachable
2017-01-06_02:34:22 HM_48CAB6 ResndFail
2017-01-06_02:34:22 HM_48CAB6 RESPONSE TIMEOUT:RegisterRead
2017-01-06_02:34:48 HM_48CAB6 aesCommToDev: pending
Ja hier ist eine Datenübertragung nicht abgeschlossen.

Hast Du gerade gemacht? Warum ist die Zeit so  komisch?

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Edi77 am 06 Januar 2017, 15:22:55
Hier mal ein größerer Ausschnitt inkl. der letzten Meldungen.

2017-01-06_02:03:40 HM_48CAB6 Activity: alive
2017-01-06_02:03:40 HM_48CAB6 D-firmware: 1.0
2017-01-06_02:03:40 HM_48CAB6 D-serialNr: NEQ0003930
2017-01-06_02:03:40 HM_48CAB6 sdRepeat: invalid
2017-01-06_02:03:41 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:03:41 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:03:41 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:03:41 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:03:41 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:03:41 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:03:42 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:03:42 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:03:42 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:03:45 HM_48CAB6 sdRepeat: off
2017-01-06_02:03:45 HM_48CAB6 Activity: alive
2017-01-06_02:03:50 HM_48CAB6 alarmTest: ok
2017-01-06_02:03:50 HM_48CAB6 battery: ok
2017-01-06_02:03:50 HM_48CAB6 level: 0
2017-01-06_02:03:50 HM_48CAB6 smokeChamber: ok
2017-01-06_02:03:50 HM_48CAB6 off
2017-01-06_02:03:55 HM_48CAB6 sdRepeat: off
2017-01-06_02:07:39 HM_48CAB6 Activity: alive
2017-01-06_02:07:39 HM_48CAB6 D-firmware: 1.0
2017-01-06_02:07:39 HM_48CAB6 D-serialNr: NEQ0003930
2017-01-06_02:07:54 HM_48CAB6 ResndFail
2017-01-06_02:07:54 HM_48CAB6 MISSING ACK
2017-01-06_02:07:55 HM_48CAB6 sdRepeat: off
2017-01-06_02:08:37 HM_48CAB6 ResndFail
2017-01-06_02:08:37 HM_48CAB6 MISSING ACK
2017-01-06_02:08:41 HM_48CAB6 sdRepeat: off
2017-01-06_02:09:36 HM_48CAB6 ResndFail
2017-01-06_02:09:36 HM_48CAB6 MISSING ACK
2017-01-06_02:09:46 HM_48CAB6 sdRepeat: off
2017-01-06_02:10:55 HM_48CAB6 alarmTest: ok
2017-01-06_02:10:55 HM_48CAB6 battery: ok
2017-01-06_02:10:55 HM_48CAB6 level: 0
2017-01-06_02:10:55 HM_48CAB6 powerOn: 2017-01-06 02:10:55
2017-01-06_02:10:55 HM_48CAB6 smokeChamber: ok
2017-01-06_02:10:55 HM_48CAB6 off
2017-01-06_02:13:18 HM_48CAB6 Activity: alive
2017-01-06_02:13:18 HM_48CAB6 D-firmware: 1.0
2017-01-06_02:13:18 HM_48CAB6 D-serialNr: NEQ0003930
2017-01-06_02:13:18 HM_48CAB6 sdRepeat: invalid
2017-01-06_02:13:19 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:13:19 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:13:19 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:13:20 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:13:20 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:13:20 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:13:20 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:13:20 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:13:20 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:13:23 HM_48CAB6 sdRepeat: off
2017-01-06_02:13:23 HM_48CAB6 Activity: alive
2017-01-06_02:13:34 HM_48CAB6 ResndFail
2017-01-06_02:13:34 HM_48CAB6 MISSING ACK
2017-01-06_02:13:44 HM_48CAB6 unreachable
2017-01-06_02:13:46 HM_48CAB6 ResndFail
2017-01-06_02:13:46 HM_48CAB6 RESPONSE TIMEOUT:RegisterRead
2017-01-06_02:16:42 HM_48CAB6 ResndFail
2017-01-06_02:16:42 HM_48CAB6 MISSING ACK
2017-01-06_02:16:44 HM_48CAB6 sdRepeat: off
2017-01-06_02:17:17 HM_48CAB6 ResndFail
2017-01-06_02:17:17 HM_48CAB6 MISSING ACK
2017-01-06_02:17:29 HM_48CAB6 sdRepeat: off
2017-01-06_02:18:04 HM_48CAB6 ResndFail
2017-01-06_02:18:04 HM_48CAB6 MISSING ACK
2017-01-06_02:18:13 HM_48CAB6 sdRepeat: off
2017-01-06_02:19:08 HM_48CAB6 ResndFail
2017-01-06_02:19:08 HM_48CAB6 MISSING ACK
2017-01-06_02:19:12 HM_48CAB6 sdRepeat: off
2017-01-06_02:20:08 HM_48CAB6 Activity: alive
2017-01-06_02:20:08 HM_48CAB6 D-firmware: 1.0
2017-01-06_02:20:08 HM_48CAB6 D-serialNr: NEQ0003930
2017-01-06_02:20:08 HM_48CAB6 R-pairCentral: set_0x01A284
2017-01-06_02:20:08 HM_48CAB6 sdRepeat: invalid
2017-01-06_02:20:08 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:20:08 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:20:08 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:20:09 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:20:09 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:20:09 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:20:23 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:20:23 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:20:23 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:20:23 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:20:23 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:20:23 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:20:24 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:20:24 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:20:24 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:20:33 HM_48CAB6 ResndFail
2017-01-06_02:20:33 HM_48CAB6 MISSING ACK
2017-01-06_02:20:45 HM_48CAB6 ResndFail
2017-01-06_02:20:45 HM_48CAB6 RESPONSE TIMEOUT:RegisterRead
2017-01-06_02:21:15 HM_48CAB6 ResndFail
2017-01-06_02:21:15 HM_48CAB6 MISSING ACK
2017-01-06_02:21:26 HM_48CAB6 ResndFail
2017-01-06_02:21:26 HM_48CAB6 RESPONSE TIMEOUT:RegisterRead
2017-01-06_02:24:51 HM_48CAB6 Activity: alive
2017-01-06_02:24:51 HM_48CAB6 D-firmware: 1.0
2017-01-06_02:24:51 HM_48CAB6 D-serialNr: NEQ0003930
2017-01-06_02:24:51 HM_48CAB6 sdRepeat: invalid
2017-01-06_02:24:53 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:24:53 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:24:53 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:24:54 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:24:54 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:24:54 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:24:54 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:24:54 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:24:54 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:24:55 HM_48CAB6 sdRepeat: off
2017-01-06_02:24:56 HM_48CAB6 Activity: alive
2017-01-06_02:25:07 HM_48CAB6 ResndFail
2017-01-06_02:25:07 HM_48CAB6 MISSING ACK
2017-01-06_02:25:17 HM_48CAB6 unreachable
2017-01-06_02:25:18 HM_48CAB6 ResndFail
2017-01-06_02:25:18 HM_48CAB6 RESPONSE TIMEOUT:RegisterRead
2017-01-06_02:26:34 HM_48CAB6 Activity: alive
2017-01-06_02:26:34 HM_48CAB6 D-firmware: 1.0
2017-01-06_02:26:34 HM_48CAB6 D-serialNr: NEQ0003930
2017-01-06_02:27:45 HM_48CAB6 alarmTest: ok
2017-01-06_02:27:45 HM_48CAB6 battery: ok
2017-01-06_02:27:45 HM_48CAB6 level: 0
2017-01-06_02:27:45 HM_48CAB6 smokeChamber: ok
2017-01-06_02:27:45 HM_48CAB6 off
2017-01-06_02:30:50 HM_48CAB6 ResndFail
2017-01-06_02:30:50 HM_48CAB6 MISSING ACK
2017-01-06_02:31:01 HM_48CAB6 ResndFail
2017-01-06_02:31:01 HM_48CAB6 RESPONSE TIMEOUT:RegisterRead
2017-01-06_02:32:15 HM_48CAB6 ResndFail
2017-01-06_02:32:15 HM_48CAB6 MISSING ACK
2017-01-06_02:32:54 HM_48CAB6 Activity: alive
2017-01-06_02:34:09 HM_48CAB6 ResndFail
2017-01-06_02:34:09 HM_48CAB6 MISSING ACK
2017-01-06_02:34:16 HM_48CAB6 unreachable
2017-01-06_02:34:22 HM_48CAB6 ResndFail
2017-01-06_02:34:22 HM_48CAB6 RESPONSE TIMEOUT:RegisterRead
2017-01-06_02:34:48 HM_48CAB6 aesCommToDev: pending
2017-01-06_02:34:48 HM_48CAB6 aesKeyNbr: 00
2017-01-06_02:34:48 HM_48CAB6 aesCommToDev: ok
2017-01-06_02:34:52 HM_48CAB6 sdRepeat: off
2017-01-06_02:36:31 HM_48CAB6 alarmTest: ok
2017-01-06_02:36:31 HM_48CAB6 battery: ok
2017-01-06_02:36:31 HM_48CAB6 level: 0
2017-01-06_02:36:31 HM_48CAB6 smokeChamber: ok
2017-01-06_02:36:31 HM_48CAB6 off
2017-01-06_02:37:48 HM_48CAB6 smoke_detect: TeamDev
2017-01-06_02:37:48 HM_48CAB6 smoke-Alarm_02
2017-01-06_02:40:06 HM_48CAB6 smoke_detect: none
2017-01-06_02:40:06 HM_48CAB6 off
2017-01-06_02:40:24 HM_48CAB6 smoke_detect: none
2017-01-06_02:40:24 HM_48CAB6 off
2017-01-06_02:42:47 HM_48CAB6 smoke_detect: none
2017-01-06_02:42:47 HM_48CAB6 off
2017-01-06_02:42:47 HM_48CAB6 teamCall: from TeamDev:05
2017-01-06_02:53:34 HM_48CAB6 ResndFail
2017-01-06_02:53:34 HM_48CAB6 MISSING ACK
2017-01-06_15:03:19 HM_48CAB6 Activity: alive
2017-01-06_15:04:47 HM_48CAB6 Activity: alive
2017-01-06_15:05:17 HM_48CAB6 unreachable
2017-01-06_15:05:32 HM_48CAB6 ResndFail
2017-01-06_15:05:32 HM_48CAB6 MISSING ACK
2017-01-06_15:09:07 HM_48CAB6 Activity: alive
2017-01-06_15:10:20 HM_48CAB6 ResndFail
2017-01-06_15:10:20 HM_48CAB6 MISSING ACK
2017-01-06_15:10:29 HM_48CAB6 unreachable

Reichweite kann es ja nicht sein oder?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marcel85 am 06 Januar 2017, 16:32:01
Ich bekomme meine SD-2 leider auch nicht richtig ans laufen.
Sie werden zwar erkannt, ich kann aber keinen TeamCall absetzen.
So sieht es bei mir aus:
Internals:
   DEF        481656
   IODev      nanoCUL
   NAME       Rauchmelder_WZ
   NOTIFYDEV  global
   NR         100
   NTFY_ORDER 50-HM_481656
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   protCmdDel 16
   protResnd  8 last_at:2017-01-06 13:06:19
   protResndFail 8 last_at:2017-01-06 13:06:24
   protSnd    8 last_at:2017-01-06 13:06:13
   protState  CMDs_done_Errors:1
   Readings:
     2017-01-05 21:54:43   Activity        alive
     2017-01-05 21:40:04   D-firmware      1.0
     2017-01-05 21:40:04   D-serialNr      NBO0018739
     2017-01-06 13:14:07   RegL_00.
     2017-01-05 21:40:04   sdRepeat        invalid
     2017-01-06 13:06:24   state           RESPONSE TIMEOUT:RegisterRead
   Helper:
     HM_CMDNR   15
     cSnd       01AABBCC48165600040000000000,01AABBCC48165600040000000000
     getCfgListNo
     mId        00AA
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +481656,00,01,00
       rxt        0
       vccu       VCCU
       p:
         481656
         00
         01
         00
       prefIO:
         nanoCUL
     Mrssi:
       mNo
       Io:
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Shadowreg:
Attributes:
   IODev      VCCU
   IOgrp      VCCU:nanoCUL
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   room       CUL_HM
   serialNr   NBO0018739
   subType    smokeDetector
   webCmd     statusRequest
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 06 Januar 2017, 16:41:08
Hallo Marcel85,

der ist nicht gepairt!

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marcel85 am 06 Januar 2017, 18:03:51
Danke Otto, du hast recht.
Ich muss leider gerade feststellen das sich FHEM beim pairingversuch aufhängt.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 06 Januar 2017, 22:34:45
Das klingt sehr befremdlich! Wie sollte das gehen?

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marcel85 am 07 Januar 2017, 07:32:51
Es lag scheinbar an der Entfernung. Jetzt wo er knapp 1m neben dem CUL liegt stürzt er nicht mehr ab, aber ich kriege ihn trotzdem nicht gepairt.
Ich bekomme beim getConfig immer nur "RESPONSE TIMEOUT:RegisterRead".
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marcel85 am 07 Januar 2017, 08:21:11
Ich habe aber langsam die Befürchtung das es an meinem nanoCUL liegt. Bekomme meinen HM-PB-6-WM55 auch nicht gepairt.
Werde mir die Tage dann wohl mal den HM-MOD-RPI-PCB bestellen und es damit versuchen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 07 Januar 2017, 11:25:09
Ich habe aber langsam die Befürchtung das es an meinem nanoCUL liegt. Bekomme meinen HM-PB-6-WM55 auch nicht gepairt.
Werde mir die Tage dann wohl mal den HM-MOD-RPI-PCB bestellen und es damit versuchen.
Das ist für Homematic sicher eine gute Entscheidung!

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MadMax-FHEM am 07 Januar 2017, 12:16:34
Hi Marcel85,

wegen:

Ich habe aber langsam die Befürchtung das es an meinem nanoCUL liegt. Bekomme meinen HM-PB-6-WM55 auch nicht gepairt.
Werde mir die Tage dann wohl mal den HM-MOD-RPI-PCB bestellen und es damit versuchen.

vielleicht nicht mehr relevant aber bei:

Es lag scheinbar an der Entfernung. Jetzt wo er knapp 1m neben dem CUL liegt stürzt er nicht mehr ab, aber ich kriege ihn trotzdem nicht gepairt.
Ich bekomme beim getConfig immer nur "RESPONSE TIMEOUT:RegisterRead".

Hilft auch evtl. der Umstieg auf die "Spezial-FW" und "Spezial-Module":

https://forum.fhem.de/index.php/topic,24436.0.html (https://forum.fhem.de/index.php/topic,24436.0.html)

Selbst positiv auf meinem Testsystem (allerdings nicht mit Rauchmelder sondern Klingelsensor) getestet bzw. seither dort auf dem nanoCUL diese problemlos laufen...

Aber es ist trotzdem besser für HM-Geräte "original" HM-IODevs zu nutzen!

Auf meinen Hauptsystemen habe ich HM-CFG-USB (gibt's ja leider nicht mehr) und eben den HM-UART (HM-MOD-RPI-PCB) im Einsatz und würde dafür auch nicht den nanoCUL etc. für HM verwenden...
...auch wenn die Spezial-FW und v.a. die Spezial-Module langsam nicht mehr ganz so spezial sind...

Gruß, Joachim
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marcel85 am 08 Januar 2017, 08:22:30
Guten Morgen,

habe den HM-UART gestern noch auf die schnelle bestellt, ich hoffe das er Mitte nächster Woche ankommt.

Dem Tipp mit der speziellen HM-Firmware bin ich auch mal nachgegangen, leider weiterhin ohne Erfolg.

Habe jetzt die VTS006 drauf (vorher die aktuelle a-culfw), jetzt geht der nanoCUL beim pairing in "Warning-HighLoad" bis hin zum "ERROR-Overload" und es kommt beim HM-SEC-SD-2 wieder "RESPONSE TIMEOUT:RegisterRead".

Vielen Dank für die Tipps und die schnelle Hilfe.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Peter_Listig am 08 Januar 2017, 23:29:29
Hallo Zusammen,

mir ist folgendes Verhalten aufgefallen, das zu einem
korrekten Pairing mit einem CUL868 geführt hat

RM eingeschaltet - mit autocreate erkannt
CUL in Pairing mode -  Pairing am RM ausgeführt
Ergebnis: es werden nur einige Readings angelegt

Insbesondere diese nicht oder unvollständig
PairedTo           0xF00034            2017-01-08 15:16:47
R-pairCentral    set_0xF00034     2017-01-08 21:40:33

Nun habe ich den RM 2 x hintereinander in den Werks-
zustand versetzt und jedes Mal
CUL in Pairing mode -  Pairing am RM ausgeführt

danach waren alle Internals, Readings und sonstige
Einstellungen richtig gesetzt.

Was mir jedoch noch nicht gelungen ist:
RM1 und RM2 jeweils einem separaten TeamLead1 und
TeamLead2 zu peeren.
Vielleicht hat es schon mal irgendwo geklappt, falls es
überhaupt möglich ist.
Am Ende noch eine Frage: Was bedeutet die "0" nach peerChan?

A guts Nächtle

Peter


Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: elfnulleins am 09 Januar 2017, 08:41:19
Moin zusammen,

da wir grad beim Pairing sind:
Ich habe kürzlich auch 4 der neuen RM erworben, bekomme die aber einfach nicht in FHEM integriert.

Folgendes Setup habe ich:
- RPI 3
- CUNX (Direkt an RPI angeschlossen)
- VCCU (für Encryption. Scheint auch zu laufen, wenn ich meinen Fensterkontakten mal glaube ;))

Obwohl ich bereits eine VCCU für Encryption eingerichtet habe und autocreate aktiviert ist, werden in FHEM keine neuen Devices angelegt wenn ich das Pairing starte. In der VCCU wird allerdings für jeden der RM ein Reading angelegt (unknown_<GeräteID>) bzw. der Zeitstempel des Readings aktualisiert, wenn ich hmPairForSec auf der VCCU setze und dann einen der RM in den Anlernmodus versetze.
Hat das schon einmal jemand gehabt?

Danke und Gruß
Mario
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 09 Januar 2017, 13:32:21
wenn du nur mal so fragen wolltest, dann ok.
wenn du Hilfe brauchst, dann mal ein list von der vccu und den IO's
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: elfnulleins am 09 Januar 2017, 17:21:32
Hi,

hier mal die Listings:

VCCU:
Internals:
   CUN1_MSGCNT 41
   CUN1_RAWMSG A0D79A41042AC8536F4810601C800::-90.5:CUN1
   CUN1_RSSI  -90.5
   CUN1_TIME  2017-01-09 06:43:16
   DEF        178ABC
   IODev      CUN1
   LASTInputDev CUN1
   MSGCNT     41
   NAME       VCCU
   NOTIFYDEV  global
   NR         61
   NTFY_ORDER 50-VCCU
   STATE      CUN1:ok,
   TYPE       CUL_HM
   assignedIOs CUN1
   Readings:
     2017-01-08 16:50:29   state           CUN1:ok,
     2017-01-08 16:29:45   unknown_116A94  received
     2017-01-08 15:40:27   unknown_1496AF  received
     2017-01-08 15:48:29   unknown_16ED7D  received
     2017-01-08 20:15:12   unknown_19E346  received
     2017-01-09 06:43:16   unknown_42AC85  received
     2017-01-08 18:26:26   unknown_4313B6  received
     2016-12-31 11:35:52   unknown_4F4814  received
   Helper:
     HM_CMDNR   1
     mId        FFF0
     rxType     1
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       prefIO
       vccu
       ioList:
         CUN1
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       vrt        1
Attributes:
   IODev      CUN1
   IOList     CUN1
   expert     2_raw
   group      Kommunikation
   hmKey      01:[...]
   icon       it_router
   model      CCU-FHEM
   room       CUL_HM
   subType    virtual
   webCmd     virtual:update

CUN1:
Internals:
   CMDS       BbCFikApZGMKUYRTVWXefmltuxEz
   CUN1_MSGCNT 74
   CUN1_TIME  2017-01-09 17:14:50
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/ttyACM0@9600 1034
   DeviceName /dev/ttyACM0@9600
   FD         10
   FHTID      1034
   NAME       CUN1
   NR         51
   NR_CMD_LAST_H 2
   PARTIAL
   RAWMSG     A0D72A6104F4814178ABC0601000005
   RSSI       -71.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 2.67 CUL868
   initString X21
Ar
   owner_CCU  VCCU
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2017-01-08 16:50:28   cmds             B b C F i k A p Z G M K U Y R T V W X e f m l t u x E z
     2017-01-09 17:14:50   state           Initialized
   XMIT_TIME:
     1483975206.39686
     1483978490.67217
   Helper:
     4f0510:
       QUEUE:
     4f4814:
       QUEUE:
Attributes:
   group      Kommunikation
   hmId       [...]
   icon       it_router
   rfmode     HomeMatic
   room       Hausanschluss

LG
Mario
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marcel85 am 10 Januar 2017, 21:07:52
Der HM-UART ist heute angekommen und auch sofort in Betrieb genommen worden.
Soweit sieht erstmal alles gut aus, bis auf das ich noch immer keinen TeamCall auslösen kann.
Pairing scheint jetzt zu funktionieren.
Ich hänge mal meine Lists an:
Internals:
   CFGFN
   DEF        481656
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     37
   NAME       Rauchmelder_WZ
   NOTIFYDEV  global
   NR         123
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:AD - t:10 s:481656 d:AABBCC 0100000000
   myHmUART_MSGCNT 37
   myHmUART_RAWMSG 0500003A80861048164100000006010000
   myHmUART_RSSI -58
   myHmUART_TIME 2017-01-10 20:59:27
   protCmdDel 10
   protEvt_AESCom-ok 5 last_at:2017-01-10 20:08:15
   protLastRcv 2017-01-10 20:08:19
   protResnd  6 last_at:2017-01-10 20:07:18
   protResndFail 6 last_at:2017-01-10 20:07:23
   protSnd    23 last_at:2017-01-10 20:08:19
   protState  CMDs_done
   rssi_at_myHmUART min:-40 lst:-21 cnt:26 avg:-23.23 max:-19
   Readings:
     2017-01-10 20:08:14   Activity        alive
     2017-01-10 20:08:15   CommandAccepted yes
     2017-01-10 20:08:14   D-firmware      1.0
     2017-01-10 20:08:14   D-serialNr      NBO0018739
     2017-01-10 20:08:18   PairedTo        0xAABBCC
     2017-01-10 20:08:18   R-pairCentral   0xAABBCC
     2017-01-10 20:08:18   RegL_00.          02:01 0A:AA 0B:BB 0C:CC 16:00 1F:00 00:00
     2017-01-10 20:08:15   aesCommToDev    ok
     2017-01-10 20:08:15   aesKeyNbr       00
     2017-01-10 20:08:01   alarmTest       ok
     2017-01-10 20:08:01   battery         ok
     2017-01-10 20:08:01   level           0
     2017-01-10 20:08:01   powerOn         2017-01-10 20:08:01
     2017-01-10 20:08:01   recentStateType info
     2017-01-10 20:08:18   sdRepeat        off
     2017-01-10 20:08:01   smokeChamber    ok
     2017-01-10 21:02:10   smoke_detect    none
     2017-01-10 21:02:10   state           off
     2017-01-10 21:01:11   teamCall        from TeamDev:00
   Helper:
     HM_CMDNR   173
     cSnd       01AABBCC48165600040000000000,01AABBCC4816560103
     mId        00AA
     peerIDsRaw ,00000000
     rxType     6
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +481656,00,00,00
       nextSend   1484075299.52144
       prefIO
       rxt        0
       vccu
       p:
         481656
         00
         00
         00
     Mrssi:
       mNo        AD
       Io:
         myHmUART   -19
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         myHmUART
       flg        A
       ts         1484075299.23361
       ack:
         HASH(0x3056c80)
         AD8002AABBCC48165600
     Rssi:
       At_myhmuart:
         avg        -23.2307692307692
         cnt        26
         lst        -21
         max        -19
         min        -40
     Shadowreg:
Attributes:
   IODev      myHmUART
   IOgrp      VCCU:myHmUART
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,
   room       CUL_HM
   serialNr   NBO0018739
   subType    smokeDetector
   webCmd     statusRequest

Ist da beim peering was schiefgelaufen? peerIDs 00000000, sollte da nicht Rauchmelder_Team stehen?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 10 Januar 2017, 22:22:41
Ist da beim peering was schiefgelaufen? peerIDs 00000000, sollte da nicht Rauchmelder_Team stehen?
Hi,

exakt, da sollte die ID vom Team mit stehen. -> Peering nicht angekommen.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marcel85 am 11 Januar 2017, 07:46:34
Nach erneutem peeren und getconfig funktioniert es nun.
Ich bin immer davon ausgegangen das die RM sich per Ton melden, allerdings blinkt die grüne LED nur beim teamCall.
Gruß
Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 11 Januar 2017, 12:13:15
Hallo Marcel,

ich habe die alten, die piepsen ganz leise.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 15 Januar 2017, 13:43:43
Hallo zusammen!
Ich hab schon so ziemlich alles oder zumindest vieles probiert- Es klappt nicht.
Ich habe einen nanoCUL (Selbstbau). Hat es schon einer geschafft, es mit einem solchen Stick zum laufen zu bekommen.
Ich habe die normale FW und TSCul probiert. Mit der normalen Firmware konnte ich zumindest zwei SD2 dazu bringen, nach dem pairen mit grün zu quittieren. Davor immer rote LED.Ohne Änderung. Mal gehts mal mal nicht. Möchte ich dann getConfig machen, kommt immer MISSING ACK oder RESPONSE TIMEOUT:RegisterRead.
Dann hab ich TSCul geflasht und die zugehörigen Dateien kopiert und auch die fhem.cfg umkonfiguriert. Schein zawr alles zu laufen, aber das pairen geht nun gar nicht mehr.
Bevor ich wieter in Detail gehe ein Frage: Gibt es jemanden, bei dem die SD2 mit einem Selbstbau nanoCUL funktionierren? Wenn ja, welche Firmware und gegebenfalls mit welcher board.h kompiliert?
Wie schauen dann die CUL und vccu definitionen aus?

Bei mir (ohne TSCUL) so:
define CUL868_HM CUL /dev/serial/by-path/pci-0000:00:1d.0-usb-0:1.3.5.2:1.0-port0@38400 1980
attr CUL868_HM group CULs
attr CUL868_HM hmId F11980
attr CUL868_HM icon cul_cul
attr CUL868_HM rfmode HomeMatic
attr CUL868_HM room System
attr CUL868_HM verbose 5

define VCCU CUL_HM F11980
attr VCCU IODev CUL868_HM
attr VCCU IOList CUL868_HM
attr VCCU group CULs
attr VCCU hmKey 01:f9d1152547c0bde01830b7e8bd60024c
attr VCCU model CCU-FHEM
attr VCCU room System
attr VCCU subType virtual
attr VCCU webCmd virtual:update


Vieleicht kann mir jemand weiterhelfen .....
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 15 Januar 2017, 15:38:46
aes key unkenntlich machen...

steht was im LOG?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 15 Januar 2017, 19:34:21
Wenn ich z.B statusRequest mache schauts im LOG so aus:
2017.01.15 19:28:03.985 |           CUL868_HM|  5: CUL868_HM sending As0B0BB001F118604BED9C010E
2017.01.15 19:28:03.985 |           CUL868_HM|  4: CUL_send:  CUL868_HMAs 0B 0B B001 F11860 4BED9C 010E
2017.01.15 19:28:06.927 |           CUL868_HM|  5: CUL868_HM sending As0B0BB001F118604BED9C010E
2017.01.15 19:28:06.928 |           CUL868_HM|  4: CUL_send:  CUL868_HMAs 0B 0B B001 F11860 4BED9C 010E
2017.01.15 19:28:36.613 |           CUL868_HM|  5: CUL/RAW: /A1476805E391421F1186000000000000
2017.01.15 19:28:36.620 |           CUL868_HM|  5: CUL/RAW: A1476805E391421F1186000000000000/001CC000000F7

2017.01.15 19:28:36.621 |           CUL868_HM|  4: CUL_Parse: CUL868_HM A 14 76 805E 391421 F11860 00000000000001CC000000F7 -78.5
2017.01.15 19:28:36.621 |           CUL868_HM|  5: CUL868_HM: dispatch A1476805E391421F1186000000000000001CC000000::-78.5:CUL868_HM


wird dann angezeigt als:
state MISSING ACK 2017-01-15 19:28:12

oder
2017.01.15 19:31:53.191 |           CUL868_HM|  5: CUL868_HM sending As100CB001F118604BED9C00040000000000
2017.01.15 19:31:53.192 |           CUL868_HM|  4: CUL_send:  CUL868_HMAs 10 0C B001 F11860 4BED9C 00040000000000
2017.01.15 19:31:54.797 |           CUL868_HM|  5: CUL/RAW: /A180CA0104BED9CF118600202010AF10
2017.01.15 19:31:54.807 |           CUL868_HM|  5: CUL/RAW: A180CA0104BED9CF118600202010AF10/B180C6016001F0000001A

2017.01.15 19:31:54.808 |           CUL868_HM|  4: CUL_Parse: CUL868_HM A 18 0C A010 4BED9C F11860 0202010AF10B180C6016001F0000001A -61
2017.01.15 19:31:54.808 |           CUL868_HM|  5: CUL868_HM: dispatch A180CA0104BED9CF118600202010AF10B180C6016001F000000::-61:CUL868_HM
2017.01.15 19:31:54.814 |           CUL868_HM|  5: CUL868_HM sending As0A0C8002F118604BED9C00
2017.01.15 19:31:54.814 |           CUL868_HM|  5: CUL 4BED9C dly:94ms
2017.01.15 19:31:54.908 |           CUL868_HM|  4: CUL_send:  CUL868_HMAs 0A 0C 8002 F11860 4BED9C 00
2017.01.15 19:31:54.919 |           CUL868_HM|  5: CUL868_HM sending As0B0DA001F118604BED9C0103
2017.01.15 19:31:54.919 |           CUL868_HM|  4: CUL_send:  CUL868_HMAs 0B 0D A001 F11860 4BED9C 0103
2017.01.15 19:32:00.666 |           CUL868_HM|  5: CUL868_HM sending As0B0DB001F118604BED9C0103
2017.01.15 19:32:00.666 |           CUL868_HM|  4: CUL_send:  CUL868_HMAs 0B 0D B001 F11860 4BED9C 0103


RESPONSE TIMEOUT:      PeerList    2017-01-15 19:32:04

PS: Ich hab mein log so geändert, dass das Device mit angezeigt wird in der 2. Spalte. Also nicht wundern deswegen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 15 Januar 2017, 20:12:39
Wenn ich es mit dem TSCUL mach, kommt im LOG nach statusrequest:
2017.01.15 20:10:01.791 |           CUL868_HM|  5: CUL868_HM sending As0B03B001F118604BED9C010E
2017.01.15 20:10:01.801 |           CUL868_HM|  4: TSCUL_send:  CUL868_HM                         As 0B 03 B001 F11860 4BED9C 010E
2017.01.15 20:10:02.172 |           CUL868_HM|  5: TSCUL/RAW: /AFF8300004469020B03B001F118604BE
2017.01.15 20:10:02.179 |           CUL868_HM|  5: TSCUL/RAW: AFF8300004469020B03B001F118604BE/D9C0180

2017.01.15 20:10:02.179 |           CUL868_HM|  4: TSCUL_Parse: CUL868_HM  085945 A FF83 00070052 02 0B 03 B001 F11860 4BED9C 01 _bst _CCAdly:8 -138
2017.01.15 20:10:02.737 |           CUL868_HM|  5: TSCUL/RAW: /AFF83000044F6010B03B001F118604BE
2017.01.15 20:10:02.743 |           CUL868_HM|  5: TSCUL/RAW: AFF83000044F6010B03B001F118604BE/D9C0180

2017.01.15 20:10:02.744 |           CUL868_HM|  4: TSCUL_Parse: CUL868_HM  086509 A FF83 00070616 01 0B 03 B001 F11860 4BED9C 01 _bst _CCAdly:4 -138
2017.01.15 20:10:03.300 |           CUL868_HM|  5: TSCUL/RAW: /AFF8300004583010B03B001F118604BE
2017.01.15 20:10:03.307 |           CUL868_HM|  5: TSCUL/RAW: AFF8300004583010B03B001F118604BE/D9C0180

2017.01.15 20:10:03.307 |           CUL868_HM|  4: TSCUL_Parse: CUL868_HM  087073 A FF83 00071180 01 0B 03 B001 F11860 4BED9C 01 _bst _CCAdly:4 -138
2017.01.15 20:10:03.498 |           CUL868_HM|  5: TSCUL/RAW: /AFF800000460F000B03B001F118604BE
2017.01.15 20:10:03.505 |           CUL868_HM|  5: TSCUL/RAW: AFF800000460F000B03B001F118604BE/D9C0180

2017.01.15 20:10:03.505 |           CUL868_HM|  1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 4BED9C/RM_Buero: AFF800000460F000B03B001F118604BED9C01
2017.01.15 20:10:03.505 |           CUL868_HM|  4: TSCUL_Parse: CUL868_HM  087271 A FF80 00071740 00 0B 03 B001 F11860 4BED9C 01 _bst _sfail -138
2017.01.15 20:10:03.615 |           CUL868_HM|  5: CUL868_HM sending As0B03B001F118604BED9C010E
2017.01.15 20:10:05.126 |           CUL868_HM|  4: TSCUL_send:  CUL868_HM                         As 0B 03 B001 F11860 4BED9C 010E
2017.01.15 20:10:05.497 |           CUL868_HM|  5: TSCUL/RAW: /AFF93000047A9020B03B001F118604BE
2017.01.15 20:10:05.504 |           CUL868_HM|  5: TSCUL/RAW: AFF93000047A9020B03B001F118604BE/D9C0180

2017.01.15 20:10:05.504 |           CUL868_HM|  4: TSCUL_Parse: CUL868_HM  089269 A FF93 00073380 02 0B 03 B001 F11860 4BED9C 01 _bst _CCAdly:8 -138
2017.01.15 20:10:06.061 |           CUL868_HM|  5: TSCUL/RAW: /AFF9300004836010B03B001F118604BE
2017.01.15 20:10:06.067 |           CUL868_HM|  5: TSCUL/RAW: AFF9300004836010B03B001F118604BE/D9C0180

2017.01.15 20:10:06.067 |           CUL868_HM|  4: TSCUL_Parse: CUL868_HM  089833 A FF93 00073944 01 0B 03 B001 F11860 4BED9C 01 _bst _CCAdly:4 -138
2017.01.15 20:10:06.624 |           CUL868_HM|  5: TSCUL/RAW: /AFF93000048C3010B03B001F118604BE
2017.01.15 20:10:06.630 |           CUL868_HM|  5: TSCUL/RAW: AFF93000048C3010B03B001F118604BE/D9C0180

2017.01.15 20:10:06.631 |           CUL868_HM|  4: TSCUL_Parse: CUL868_HM  090396 A FF93 00074508 01 0B 03 B001 F11860 4BED9C 01 _bst _CCAdly:4 -138
2017.01.15 20:10:06.822 |           CUL868_HM|  5: TSCUL/RAW: /AFF900000494F000B03B001F118604BE
2017.01.15 20:10:06.829 |           CUL868_HM|  5: TSCUL/RAW: AFF900000494F000B03B001F118604BE/D9C0180

2017.01.15 20:10:06.829 |           CUL868_HM|  1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 4BED9C/RM_Buero: AFF900000494F000B03B001F118604BED9C01
2017.01.15 20:10:06.829 |           CUL868_HM|  4: TSCUL_Parse: CUL868_HM  090595 A FF90 00075068 00 0B 03 B001 F11860 4BED9C 01 _bst _sfail -138



Wenn ich anlernen will mit dem TSCUL, passiert im LOG gar nichts. Hingegen mit der normalen FW schon????!?!?!?
Ausserdem geht mein HM-Sen-Wa-Od mit TSCUL auch nicht.
Der Lichschlater SW1PBU dagagen schon



Hilfe....

Welche HM Schnittstelle verwendet ihr denn so, bei denen es funktioniert?

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 16 Januar 2017, 10:26:04
grundsätzlich würde ich tscul zum laufen bringen.
poste mal die ausgabe von "version".
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 16 Januar 2017, 20:35:45
Ich hab im Moment drei Homematic Teile. Mit dem TSCUL schauts so aus:
1. SW1PBU --> geht
2. HM SEN WA Od (Wasserstand Zisterne) --> geht nicht
3. Die Racumelder SD2 --> geht nicht. Beim Pairingversuch passiert im LOG gar nichts.

Das List vom TSCUL (sollte eigentlich aktuell sein):
Internals:
   CFGFN      /mnt/2/Daten/fhem-5.6/mycfg/CUL.cfg
   CMDS       ABCGMRVWXefilmtx
   CUL868_HM_MSGCNT 978
   CUL868_HM_TIME 2017-01-16 20:29:40
   Clients    TSSTACKED:STACKABLE_CC:CUL_HM:HMS:CUL_IR
   DEF        /dev/serial/by-path/pci-0000:00:1d.0-usb-0:1.3.5.2:1.0-port0@38400 1860
   DeviceName /dev/serial/by-path/pci-0000:00:1d.0-usb-0:1.3.5.2:1.0-port0@38400
   FD         15
   FHTID      1860
   NAME       CUL868_HM
   NR         67
   PARTIAL
   RAWMSG     AFF21014CA322001431805E391421F1186000000000000001D4000000FF
   RSSI       -74.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.06 nanoCUL868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes
   XmitOpen   1
   initString X21
Ar
   owner_CCU  VCCU
   Matchlist:
     1:TSSTACKED ^\*
     A:CUL_HM   ^A[F?]...................
     B:HMS      ^810e04....(1|5|9).a001
     C:CUL_IR   ^I............
   Readings:
     2017-01-16 20:29:10   Xmit-Events     init:3 ERROR-Overload:33 Warning-HighLoad:3 disconnected:2 ok:35
     2017-01-15 09:02:10   ccconf          freq:868.300MHz bWidth:101kHz rAmpl:33dB sens:8dB drate:9.993kBit/s agcprio:1 agcwait:16 agchyst:2 dcBlockingoff:0 IF:152.34kHz agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0 freq_offs:-20.630kHz CCAmode:3 csRelThr:dis csAbsThr:0dB
     2017-01-15 20:18:13   cmds             A B C G M R V W X e f i l m t x
     2017-01-16 20:29:10   cond            ok
     2017-01-16 20:29:10   prot_ERROR-Overload last
     2017-01-15 20:18:26   prot_Warning-HighLoad last
     2017-01-15 20:18:07   prot_disconnected last
     2017-01-15 20:18:13   prot_init       last
     2017-01-16 20:29:10   prot_ok         last
     2017-01-15 09:03:48   scF             0.998689792862491
     2017-01-16 20:29:10   state           Initialized
     2017-01-15 08:59:18   version         VTS 0.06 nanoCUL868
   Helper:
     hmTSAt1Add
     Devio:
       NDisCon    1
       NRFail     0
       RXfailTS
     Hm:
       FUP        0
       hmCrdts    2
       hmSbusy    0
       Unknwn:
         103914:
           lRcTm      87146764
           lstRecType A0
           nextSend   1484594927.62676
           nxtSndMcnt 64
           tgtDly     120
     Cnd:
       0          35
       2          3
       253        2
       255        3
       4          33
     Hmq:
     Hmqo:
     Q:
       HMcndN     0
       InQueues   0
       answerPend 0
       hmLanQlen  1
       Cap:
         sum        18000
     Ref:
       Sdly       615
       doNbyterate 99
       hmDstDly   120
       ioByteRate 3840
       ioByteRateMeas 3297.74179494208
       lHMt       71042576
       lSys       667643651
       pTTu       1024
       pndAs      0
       pndCUAp    13
       pngLm      14
       pngMax     6
       pngMin     100000000
       pngRef     6
       pngtm      596695828
       pngtmBRs   1484507904.68111
       scF        0.998689792862491
       scFN       2
       scHT       25604
       scST       596156652
Attributes:
   group      CULs
   hmId       F11860
   hmLanQlen  1_min
   icon       cul_cul
   rfmode     HomeMatic
   room       System
   verbose    5

Die Dateien habe ich reinkopiert ins FHEM Vereichnis:
05.01.2017  10:55           175.294 00_TSCUL.pm
27.11.2016  16:48            25.392 10_UNIRoll_TS.pm
12.12.2016  21:14            16.963 13_TSKS300.pm
21.11.2016  14:12             8.386 14_TSCUL_TX.pm
22.11.2016  19:20            24.217 14_TSCUL_WS.pm
03.01.2017  00:09            17.138 16_TSSTACKED.pm
03.01.2017  00:11             2.628 CalcUtil.pm
03.01.2017  00:10             1.663 CUL_Util.pm
03.01.2017  00:11            17.316 DevIoTS.pm

Und die TSCUL Definition sieht so aus:
define CUL868_HM TSCUL /dev/serial/by-path/pci-0000:00:1d.0-usb-0:1.3.5.2:1.0-port0@38400 1860
attr CUL868_HM group CULs
attr CUL868_HM hmId F11860
attr CUL868_HM icon cul_cul
attr CUL868_HM rfmode HomeMatic
attr CUL868_HM room System
attr CUL868_HM verbose 5

define VCCU CUL_HM F11860
attr VCCU IODev CUL868_HM
attr VCCU IOList CUL868_HM
attr VCCU group CULs
attr VCCU hmKey 01:f9d1152547c0bde01830b7e8bd60024c
attr VCCU model CCU-FHEM
attr VCCU room System
attr VCCU subType virtual
attr VCCU webCmd virtual:update

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 16 Januar 2017, 20:40:59
Ich habe 9 neue und 3 alte rm und kann nur sagen, die neuen sind extrem zickig. Auch mit hmlan geht's nicht...

Die Alten Laufen ohne probs

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 16 Januar 2017, 20:51:47
@nccfast

Zitat
poste mal die ausgabe von "version".
das wort version in die eingabezeile tippen und den befehl auslösen.  :)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 16 Januar 2017, 21:03:29
Latest Revision: 13060

File                                 Rev   Last Change

fhem.pl                              13054 2017-01-13 16:08:17Z rudolfkoenig
################################## # $Id: 99_myUtilsTM.pm 2014-8 by Elektrolurch $
96_allowed.pm                        11984 2016-08-19 12:47:50Z rudolfkoenig
90_at.pm                             12717 2016-12-05 21:53:35Z rudolfkoenig
98_autocreate.pm                     11984 2016-08-19 12:47:50Z rudolfkoenig
57_Calendar.pm                       10257 2015-12-24 13:28:14Z borisneubert
57_CALVIEW.pm                         7015 2015-12-23 13:30:00Z chris1284
38_CO20.pm                            9679 2015-10-25 23:10:29Z markus-m
00_CUL.pm                            12983 2017-01-06 13:53:27Z rudolfkoenig
15_CUL_EM.pm                         12712 2016-12-04 10:08:23Z rudolfkoenig
10_CUL_HM.pm                         12943 2017-01-03 08:35:18Z martinp876
14_CUL_WS.pm                         11984 2016-08-19 12:47:50Z rudolfkoenig
95_Dashboard.pm                      12251 2016-10-03 09:45:43Z talkabout
93_DbLog.pm                          13039 2017-01-10 22:19:58Z DS_Starter
No Id found for 71_DENON_AVR.pm
98_dewpoint.pm                        6757 2014-10-12 18:58:57Z joachim09876
98_DOIF.pm                           12961 2017-01-04 22:23:57Z Damian
98_dummy.pm                          12700 2016-12-02 16:49:42Z rudolfkoenig
70_ENIGMA2.pm                        12862 2016-12-22 08:45:22Z loredo
91_eventTypes.pm                     11984 2016-08-19 12:47:50Z rudolfkoenig
72_FB_CALLMONITOR.pm                 12816 2016-12-18 10:57:19Z markusbloch
01_FHEMWEB.pm                        12984 2017-01-06 13:58:42Z rudolfkoenig
11_FHT.pm                            12379 2016-10-18 20:21:29Z rudolfkoenig
92_FileLog.pm                        13027 2017-01-09 16:28:24Z rudolfkoenig
10_FS20.pm                           12688 2016-11-29 20:40:24Z rudolfkoenig
98_HMinfo.pm                         12917 2016-12-31 07:44:34Z martinp876
12_HMS.pm                            11984 2016-08-19 12:47:50Z rudolfkoenig
13_KS300.pm                          12699 2016-12-02 12:15:44Z rudolfkoenig
98_logProxy.pm                       12737 2016-12-11 09:39:37Z justme1968
No Id found for 59_Moon.pm
00_MQTT.pm                           10418 2016-01-08 23:28:27Z ntruchsess
10_MQTT_DEVICE.pm                     6935 2014-11-09 20:35:34Z ntruchsess
91_notify.pm                         11984 2016-08-19 12:47:50Z rudolfkoenig
73_PRESENCE.pm                       12783 2016-12-15 12:06:01Z markusbloch
33_readingsGroup.pm                  12774 2016-12-14 17:16:09Z justme1968
99_SUNRISE_EL.pm                     12485 2016-11-01 15:18:51Z rudolfkoenig
98_SVG.pm                            12482 2016-11-01 09:25:59Z rudolfkoenig
98_telnet.pm                         11984 2016-08-19 12:47:50Z rudolfkoenig
00_TSCUL.pm                              6 2017-01-02 19:41:39Z noansi
10_UNIRoll.pm                        12819 2016-12-18 14:27:48Z C_Herrmann
99_Utils.pm                          11984 2016-08-19 12:47:50Z rudolfkoenig
No Id found for 99_Utils_Konrad.pm
98_version.pm                        11987 2016-08-19 17:13:41Z markusbloch
98_weblink.pm                        11984 2016-08-19 12:47:50Z rudolfkoenig
36_WMBUS.pm                          12532 2016-11-08 19:34:33Z kaihs
98_XmlList.pm                        11984 2016-08-19 12:47:50Z rudolfkoenig

Blocking.pm                          12648 2016-11-24 12:15:25Z rudolfkoenig
Color.pm                             11159 2016-03-30 16:08:06Z justme1968
CUL_Util.pm                              3 2017-01-02 00:14:47Z noansi
DevIo.pm                             12716 2016-12-05 09:11:31Z rudolfkoenig
DevIoTS.pm                               6 2017-01-02 08:51:47Z noansi
FritzBoxUtils.pm                      6574 2014-09-19 17:32:48Z rudolfkoenig
GPUtils.pm                            6653 2014-10-02 11:59:37Z ntruchsess
HMConfig.pm                          12942 2017-01-03 07:42:02Z martinp876
No Id found for HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm
HttpUtils.pm                         12740 2016-12-11 12:57:36Z rudolfkoenig
RTypes.pm                            10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm                     12935 2017-01-02 19:51:46Z rudolfkoenig
TcpServerUtils.pm                    11908 2016-08-06 15:09:55Z rudolfkoenig
WMBus.pm                             12532 2016-11-08 19:34:33Z kaihs
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 16 Januar 2017, 21:49:04
     2017-01-16 20:29:10   Xmit-Events     init:3 ERROR-Overload:33 Warning-HighLoad:3 disconnected:2 ok:35
das ist ein problem. wenn overload, dann geht kein senden.

ausserdem sieht dein letztes log von tscul statusrequest nicht gut aus:
1. wo kommen die pipe-zeichen her?
2. warum fehlt in der unteren roten message das letzte byte (0E)? beide sollten identisch sein.

Zitat
2017.01.15 20:10:01.801 |           CUL868_HM|  4: TSCUL_send:  CUL868_HM                         As 0B 03 B001 F11860 4BED9C 010E
2017.01.15 20:10:02.172 |           CUL868_HM|  5: TSCUL/RAW: /AFF8300004469020B03B001F118604BE
2017.01.15 20:10:02.179 |           CUL868_HM|  5: TSCUL/RAW: AFF8300004469020B03B001F118604BE/D9C0180

2017.01.15 20:10:02.179 |           CUL868_HM|  4: TSCUL_Parse: CUL868_HM  085945 A FF83 00070052 02 0B 03 B001 F11860 4BED9C 01 _bst _CCAdly:8 -138

deine hardware und das hexfile der firmware passen zusammen?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 16 Januar 2017, 22:00:40
USB/seriell chip kaputt? Ich hatte einen Arduino nano, da sah die Kommunikation sehr ähnlich aus. Immer mal ein Zeichen "schräg"

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 16 Januar 2017, 22:11:45
Ich hatte das Logging verändert, deshalb dies pipes ....
Hab jetzt wieder Original, GetConfig sieht nun so aus:
2017.01.16 22:07:23.942 5: CUL868_HM sending As1004B001F118604BED9C00040000000000
2017.01.16 22:07:23.952 4: TSCUL_send:  CUL868_HM                         As 10 04 B001 F11860 4BED9C 00040000000000
2017.01.16 22:07:24.546 5: TSCUL/RAW: /AFF83000125C8011004B001F118604BED9C0080

2017.01.16 22:07:24.547 4: TSCUL_Parse: CUL868_HM  205048 A FF83 00300832 01 10 04 B001 F11860 4BED9C 00 _bst _CCAdly:4 -138
2017.01.16 22:07:24.896 5: TSCUL/RAW: /AFF8300012656011004B001F118604BE
2017.01.16 22:07:24.903 5: TSCUL/RAW: AFF8300012656011004B001F118604BE/D9C0080

2017.01.16 22:07:24.903 4: TSCUL_Parse: CUL868_HM  205405 A FF83 00301400 01 10 04 B001 F11860 4BED9C 00 _bst _CCAdly:4 -138
2017.01.16 22:07:25.464 5: TSCUL/RAW: /AFF83000126E4011004B001F118604BE
2017.01.16 22:07:25.470 5: TSCUL/RAW: AFF83000126E4011004B001F118604BE/D9C0080

2017.01.16 22:07:25.471 4: TSCUL_Parse: CUL868_HM  205972 A FF83 00301968 01 10 04 B001 F11860 4BED9C 00 _bst _CCAdly:4 -138
2017.01.16 22:07:25.662 5: TSCUL/RAW: /AFF8000012771001004B001F118604BE
2017.01.16 22:07:25.668 5: TSCUL/RAW: AFF8000012771001004B001F118604BE/D9C0080

2017.01.16 22:07:25.669 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 4BED9C/RM_Buero: AFF8000012771001004B001F118604BED9C00
2017.01.16 22:07:25.669 4: TSCUL_Parse: CUL868_HM  206170 A FF80 00302532 00 10 04 B001 F11860 4BED9C 00 _bst _sfail -138
2017.01.16 22:07:30.223 5: CUL868_HM sending As1004B001F118604BED9C00040000000000
2017.01.16 22:07:30.233 4: TSCUL_send:  CUL868_HM                         As 10 04 B001 F11860 4BED9C 00040000000000
2017.01.16 22:07:31.498 5: TSCUL/RAW: /AFF8300012BEC011004B001F118604BED9C0080
AFF9300012C7B011004B001F118604BED9C0080

2017.01.16 22:07:31.499 4: TSCUL_Parse: CUL868_HM  212000 A FF83 00307120 01 10 04 B001 F11860 4BED9C 00 _bst _CCAdly:4 -138
2017.01.16 22:07:31.499 4: TSCUL_Parse: CUL868_HM  212001 A FF93 00307692 01 10 04 B001 F11860 4BED9C 00 _bst _CCAdly:4 -138
2017.01.16 22:07:34.974 5: TSCUL/RAW: /AFF9300012D09011004B001F118604BED9C0080
AFF9000012D96001004B001F118604BED9C0080

2017.01.16 22:07:34.975 4: TSCUL_Parse: CUL868_HM  215476 A FF93 00308260 01 10 04 B001 F11860 4BED9C 00 _bst _CCAdly:4 -138
2017.01.16 22:07:34.975 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 4BED9C/RM_Buero: AFF9000012D96001004B001F118604BED9C00
2017.01.16 22:07:34.975 4: TSCUL_Parse: CUL868_HM  215477 A FF90 00308824 00 10 04 B001 F11860 4BED9C 00 _bst _sfail -138
2017.01.16 22:07:41.829 5: TSCUL/RAW: /AFF910001373F001469805E391421F11
2017.01.16 22:07:41.840 5: TSCUL/RAW: AFF910001373F001469805E391421F11/86000000000000001C8000000FB

2017.01.16 22:07:41.841 4: TSCUL_Parse: CUL868_HM  222337 A FF91 00318716 00 14 69 805E 391421 F11860 00000000000001C8000000 -76.5
2017.01.16 22:07:41.841 5: CUL868_HM: dispatch A1469805E391421F1186000000000000001C8000000::-76.5:CUL868_HM


Antwort: RESPONSE TIMEOUT:RegisterRead
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 17 Januar 2017, 11:03:38
das abschneiden der message ist wohl ein feature, also ok.
trotzdem antwortet der rm nicht, kein zucken.

was ist mit overload? hast du mal cul und rm vom strom getrennt, um overload zu löschen?
ist dein log jetzt vollständig, oder hast du zeilen unterschlagen? verbose=4 reicht völlig und ist besser zu lesen.
was ist das genau für ein cul? ein echter busware 868?
funktioniert jetzt der sw1pbu? vielleicht erst mal einfachere devices 100% zum laufen bringen mit der tsculfw.

was ist mit funk? abstand 2-3 meter?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 17 Januar 2017, 17:21:49
Zitat
hast du mal cul und rm vom strom getrennt, um overload zu löschen?
JA

Zitat
ist dein log jetzt vollständig, oder hast du zeilen unterschlagen?
Nix unterschlagen

Zitat
was ist das genau für ein cul? ein echter busware 868?
Kein echter Busware. SelbstbauCUL wie hier https://wiki.fhem.de/wiki/Selbstbau_CUL (https://wiki.fhem.de/wiki/Selbstbau_CUL). Sogar die Signalleitungen mit Levelshifter verbunden.
Zitat
funktioniert jetzt der sw1pbu?
Nur der sw1pbu funktioniert :-)
Zitat
was ist mit funk? abstand 2-3 meter?
1,5m bis 2 m zum RM
Zum sw1pbu ein Stockwerk.


Hab jetzt mal ein kürzeres (1m) USB Kabel genommen. Kein Änderung :-(

Rauchmelder getConfig:
2017.01.17 17:00:15.324 4: TSCUL_send:  CUL868_HM                         As 10 05 B001 F11860 4BED9C 00040000000000
2017.01.17 17:00:15.708 4: TSCUL_Parse: CUL868_HM  018770 A FF83 00037980 01 10 05 B001 F11860 4BED9C 00 _bst _CCAdly:4 -138
2017.01.17 17:00:16.295 4: TSCUL_Parse: CUL868_HM  019357 A FF83 00038548 01 10 05 B001 F11860 4BED9C 00 _bst _CCAdly:4 -138
2017.01.17 17:00:16.842 4: TSCUL_Parse: CUL868_HM  019904 A FF83 00039116 01 10 05 B001 F11860 4BED9C 00 _bst _CCAdly:4 -138
2017.01.17 17:00:17.040 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 4BED9C/RM_Buero: AFF80000026C0001005B001F118604BED9C00
2017.01.17 17:00:17.041 4: TSCUL_Parse: CUL868_HM  020102 A FF80 00039680 00 10 05 B001 F11860 4BED9C 00 _bst _sfail -138
2017.01.17 17:00:21.018 4: TSCUL_send:  CUL868_HM                         As 10 05 B001 F11860 4BED9C 00040000000000
2017.01.17 17:00:21.402 4: TSCUL_Parse: CUL868_HM  024464 A FF83 00043680 01 10 05 B001 F11860 4BED9C 00 _bst _CCAdly:4 -138
2017.01.17 17:00:21.968 4: TSCUL_Parse: CUL868_HM  025029 A FF83 00044248 01 10 05 B001 F11860 4BED9C 00 _bst _CCAdly:4 -138
2017.01.17 17:00:22.535 4: TSCUL_Parse: CUL868_HM  025597 A FF93 00044816 01 10 05 B001 F11860 4BED9C 00 _bst _CCAdly:4 -138
2017.01.17 17:00:22.733 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 4BED9C/RM_Buero: AFF9000002C51001005B001F118604BED9C00
2017.01.17 17:00:22.733 4: TSCUL_Parse: CUL868_HM  025795 A FF90 00045380 00 10 05 B001 F11860 4BED9C 00 _bst _sfail -138
2017.01.17 17:00:50.870 4: TSCUL_Parse: CUL868_HM  053926 A FF81 00073548 00 14 8A 805E 391421 F11860 00000000000001C5000000 -74.5

state timeout


statusRequest:
2017.01.17 17:02:48.674 4: TSCUL_send:  CUL868_HM                         As 0B 06 B001 F11860 4BED9C 010E
2017.01.17 17:02:49.051 4: TSCUL_Parse: CUL868_HM  172113 A FF83 00191528 02 0B 06 B001 F11860 4BED9C 01 _bst _CCAdly:8 -138
2017.01.17 17:02:49.616 4: TSCUL_Parse: CUL868_HM  172678 A FF83 00192092 01 0B 06 B001 F11860 4BED9C 01 _bst _CCAdly:4 -138
2017.01.17 17:02:50.180 4: TSCUL_Parse: CUL868_HM  173241 A FF83 00192656 01 0B 06 B001 F11860 4BED9C 01 _bst _CCAdly:4 -138
2017.01.17 17:02:50.378 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 4BED9C/RM_Buero: AFF800000BCB0000B06B001F118604BED9C01
2017.01.17 17:02:50.378 4: TSCUL_Parse: CUL868_HM  173439 A FF80 00193216 00 0B 06 B001 F11860 4BED9C 01 _bst _sfail -138
2017.01.17 17:02:51.998 4: TSCUL_send:  CUL868_HM                         As 0B 06 B001 F11860 4BED9C 010E
2017.01.17 17:02:52.375 4: TSCUL_Parse: CUL868_HM  175437 A FF93 00194856 02 0B 06 B001 F11860 4BED9C 01 _bst _CCAdly:8 -138
2017.01.17 17:02:52.940 4: TSCUL_Parse: CUL868_HM  176002 A FF93 00195420 01 0B 06 B001 F11860 4BED9C 01 _bst _CCAdly:4 -138
2017.01.17 17:02:53.503 4: TSCUL_Parse: CUL868_HM  176565 A FF93 00195984 01 0B 06 B001 F11860 4BED9C 01 _bst _CCAdly:4 -138
2017.01.17 17:02:53.702 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 4BED9C/RM_Buero: AFF900000BFF0000B06B001F118604BED9C01
2017.01.17 17:02:53.702 4: TSCUL_Parse: CUL868_HM  176763 A FF90 00196544 00 0B 06 B001 F11860 4BED9C 01 _bst _sfail -138
state MISSING ACK

SW1PBU getConfig
2017.01.17 17:04:14.898 4: TSCUL_send:  CUL868_HM                         As 10 92 A001 F11860 391421 00040000000000
2017.01.17 17:04:15.053 4: TSCUL_Parse: CUL868_HM  258115 A FF93 00277864 01 10 92 A001 F11860 391421 00 _CCAdly:4 -138
2017.01.17 17:04:15.054 4: TSCUL_Parse: CUL868_HM  258108 A FF91 00277924 00 18 92 A010 391421 F11860 02020105000AF10B180C6012000000 -71.5
2017.01.17 17:04:15.066 4: TSCUL_send:  CUL868_HM                         As 0A 92 8002 F11860 391421 00
2017.01.17 17:04:15.066 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:23 toms:32
2017.01.17 17:04:15.103 4: TSCUL_send:  CUL868_HM                         As 10 93 A001 F11860 391421 01040000000001
2017.01.17 17:04:15.103 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:104 toms:33
2017.01.17 17:04:15.122 4: TSCUL_Parse: CUL868_HM  258184 A FF93 00278044 01 0A 92 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:04:15.215 4: TSCUL_Parse: CUL868_HM  258276 A FF93 00278132 01 10 93 A001 F11860 391421 01 _CCAdly:4 _dhmSt:208 -138
2017.01.17 17:04:15.446 4: TSCUL_Parse: CUL868_HM  258508 A FF93 00278364 01 10 93 A001 F11860 391421 01 _CCAdly:4 _dhmSt:440 -138
2017.01.17 17:04:15.707 4: TSCUL_Parse: CUL868_HM  258769 A FF93 00278624 08 10 93 A001 F11860 391421 01 _CCAdly:32 _dhmSt:700 -138
2017.01.17 17:04:15.720 4: TSCUL_Parse: CUL868_HM  258778 A FF91 00278652 00 12 93 A010 391421 F11860 020400080009000000 -71
2017.01.17 17:04:15.733 4: TSCUL_send:  CUL868_HM                         As 0A 93 8002 F11860 391421 00
2017.01.17 17:04:15.733 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:84 toms:32
2017.01.17 17:04:15.766 4: TSCUL_send:  CUL868_HM                         As 0B 94 A001 F11860 391421 0103
2017.01.17 17:04:15.766 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:170 toms:32
2017.01.17 17:04:15.849 2: TSCUL_condUpdate: CUL868_HM new condition ERROR-Overload
2017.01.17 17:04:15.856 4: TSCUL_Parse: CUL868_HM  258911 A FFF3 00278772 01 0A 93 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:04:15.938 2: TSCUL_condUpdate: CUL868_HM new condition Warning-HighLoad
2017.01.17 17:04:15.942 4: TSCUL_Parse: CUL868_HM  258999 A FF93 00278860 01 0B 94 A001 F11860 391421 01 _CCAdly:4 _dhmSt:208 -138
2017.01.17 17:04:16.165 4: TSCUL_Parse: CUL868_HM  259227 A FF93 00279088 01 0B 94 A001 F11860 391421 01 _CCAdly:4 _dhmSt:436 -138
2017.01.17 17:04:16.410 4: TSCUL_Parse: CUL868_HM  259472 A FF93 00279320 02 0B 94 A001 F11860 391421 01 _CCAdly:8 _dhmSt:668 -138
2017.01.17 17:04:16.598 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF90000110FF000B94A001F1186039142101
2017.01.17 17:04:16.598 4: TSCUL_Parse: CUL868_HM  259659 A FF90 00279548 00 0B 94 A001 F11860 391421 01 _sfail -138
2017.01.17 17:04:19.910 4: TSCUL_send:  CUL868_HM                         As 0B 94 A001 F11860 391421 0103
2017.01.17 17:04:19.954 4: TSCUL_Parse: CUL868_HM  263015 A FF93 00282880 01 0B 94 A001 F11860 391421 01 _CCAdly:4 -138
2017.01.17 17:04:20.184 4: TSCUL_Parse: CUL868_HM  263246 A FF93 00283112 01 0B 94 A001 F11860 391421 01 _CCAdly:4 -138
2017.01.17 17:04:20.412 4: TSCUL_Parse: CUL868_HM  263474 A FF93 00283340 01 0B 94 A001 F11860 391421 01 _CCAdly:4 -138
2017.01.17 17:04:20.608 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF90000114EB000B94A001F1186039142101
2017.01.17 17:04:20.609 4: TSCUL_Parse: CUL868_HM  263670 A FF90 00283564 00 0B 94 A001 F11860 391421 01 _sfail -138
2017.01.17 17:04:20.964 4: TSCUL_Parse: CUL868_HM  264030 A FF92 00283924 00 01 CC _ping -138
2017.01.17 17:04:24.262 4: TSCUL_send:  CUL868_HM                         As 0B 94 A001 F11860 391421 0103
2017.01.17 17:04:24.306 4: TSCUL_Parse: CUL868_HM  267367 A FF93 00287240 02 0B 94 A001 F11860 391421 01 _CCAdly:8 -138
2017.01.17 17:04:24.335 4: TSCUL_Parse: CUL868_HM  267392 A FF91 00287288 00 12 94 A010 391421 F11860 013914210300000000 -79
2017.01.17 17:04:24.348 4: TSCUL_send:  CUL868_HM                         As 0A 94 8002 F11860 391421 00
2017.01.17 17:04:24.348 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:94 toms:32
2017.01.17 17:04:24.380 4: TSCUL_send:  CUL868_HM                         As 10 95 A001 F11860 391421 02040000000001
2017.01.17 17:04:24.380 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:179 toms:33
2017.01.17 17:04:24.474 2: TSCUL_condUpdate: CUL868_HM new condition ERROR-Overload
2017.01.17 17:04:24.478 4: TSCUL_Parse: CUL868_HM  267535 A FFF3 00287408 01 0A 94 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:04:24.567 2: TSCUL_condUpdate: CUL868_HM new condition Warning-HighLoad
2017.01.17 17:04:24.570 4: TSCUL_Parse: CUL868_HM  267628 A FF93 00287496 01 10 95 A001 F11860 391421 02 _CCAdly:4 _dhmSt:208 -138
2017.01.17 17:04:24.798 4: TSCUL_Parse: CUL868_HM  267860 A FF93 00287728 01 10 95 A001 F11860 391421 02 _CCAdly:4 _dhmSt:440 -138
2017.01.17 17:04:25.030 4: TSCUL_Parse: CUL868_HM  268092 A FF93 00287960 01 10 95 A001 F11860 391421 02 _CCAdly:4 _dhmSt:672 -138
2017.01.17 17:04:25.226 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF900001196F001095A001F1186039142102
2017.01.17 17:04:25.227 4: TSCUL_Parse: CUL868_HM  268288 A FF90 00288188 00 10 95 A001 F11860 391421 02 _sfail -138
2017.01.17 17:04:28.390 4: TSCUL_send:  CUL868_HM                         As 10 95 A001 F11860 391421 02040000000001
2017.01.17 17:04:28.440 4: TSCUL_Parse: CUL868_HM  271502 A FF93 00291376 02 10 95 A001 F11860 391421 02 _CCAdly:8 -138
2017.01.17 17:04:28.470 4: TSCUL_Parse: CUL868_HM  271527 A FF91 00291428 00 12 95 A010 391421 F11860 020400080009000000 -78
2017.01.17 17:04:28.482 4: TSCUL_send:  CUL868_HM                         As 0A 95 8002 F11860 391421 00
2017.01.17 17:04:28.483 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:96 toms:32
2017.01.17 17:04:28.515 4: TSCUL_send:  CUL868_HM                         As 0B 96 A001 F11860 391421 0203
2017.01.17 17:04:28.516 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:182 toms:32
2017.01.17 17:04:28.609 2: TSCUL_condUpdate: CUL868_HM new condition ERROR-Overload
2017.01.17 17:04:28.612 4: TSCUL_Parse: CUL868_HM  271670 A FFF3 00291548 01 0A 95 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:04:28.697 2: TSCUL_condUpdate: CUL868_HM new condition Warning-HighLoad
2017.01.17 17:04:28.701 4: TSCUL_Parse: CUL868_HM  271759 A FF93 00291636 01 0B 96 A001 F11860 391421 02 _CCAdly:4 _dhmSt:208 -138
2017.01.17 17:04:28.925 4: TSCUL_Parse: CUL868_HM  271987 A FF93 00291864 01 0B 96 A001 F11860 391421 02 _CCAdly:4 _dhmSt:436 -138
2017.01.17 17:04:29.153 4: TSCUL_Parse: CUL868_HM  272214 A FF93 00292092 01 0B 96 A001 F11860 391421 02 _CCAdly:4 _dhmSt:664 -138
2017.01.17 17:04:29.349 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF9000011D77000B96A001F1186039142102
2017.01.17 17:04:29.349 4: TSCUL_Parse: CUL868_HM  272411 A FF90 00292316 00 0B 96 A001 F11860 391421 02 _sfail -138
2017.01.17 17:04:29.588 4: TSCUL_Parse: CUL868_HM  272654 A FF92 00292556 00 01 CC _ping -138
2017.01.17 17:04:33.646 4: TSCUL_send:  CUL868_HM                         As 0B 96 A001 F11860 391421 0203
2017.01.17 17:04:33.690 4: TSCUL_Parse: CUL868_HM  276751 A FF93 00296636 02 0B 96 A001 F11860 391421 02 _CCAdly:8 -138
2017.01.17 17:04:33.719 4: TSCUL_Parse: CUL868_HM  276776 A FF91 00296684 00 12 96 A010 391421 F11860 013914210300000000 -74
2017.01.17 17:04:33.731 4: TSCUL_send:  CUL868_HM                         As 0A 96 8002 F11860 391421 00
2017.01.17 17:04:33.732 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:96 toms:32
2017.01.17 17:04:33.764 4: TSCUL_send:  CUL868_HM                         As 10 97 A001 F11860 391421 03040000000001
2017.01.17 17:04:33.764 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:180 toms:33
2017.01.17 17:04:33.858 2: TSCUL_condUpdate: CUL868_HM new condition ERROR-Overload
2017.01.17 17:04:33.862 4: TSCUL_Parse: CUL868_HM  276919 A FFF3 00296804 01 0A 96 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:04:33.950 2: TSCUL_condUpdate: CUL868_HM new condition Warning-HighLoad
2017.01.17 17:04:33.954 4: TSCUL_Parse: CUL868_HM  277012 A FF93 00296892 01 10 97 A001 F11860 391421 03 _CCAdly:4 _dhmSt:208 -138
2017.01.17 17:04:34.182 4: TSCUL_Parse: CUL868_HM  277244 A FF93 00297124 01 10 97 A001 F11860 391421 03 _CCAdly:4 _dhmSt:440 -138
2017.01.17 17:04:34.414 4: TSCUL_Parse: CUL868_HM  277475 A FF93 00297356 01 10 97 A001 F11860 391421 03 _CCAdly:4 _dhmSt:672 -138
2017.01.17 17:04:34.610 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF900001229C001097A001F1186039142103
2017.01.17 17:04:34.610 4: TSCUL_Parse: CUL868_HM  277672 A FF90 00297584 00 10 97 A001 F11860 391421 03 _sfail -138
2017.01.17 17:04:35.110 4: TSCUL_Parse: CUL868_HM  278169 A FF91 00298080 00 0E 97 A010 391421 F11860 0208000000 -75.5
2017.01.17 17:04:35.122 4: TSCUL_send:  CUL868_HM                         As 0A 97 8002 F11860 391421 00
2017.01.17 17:04:35.122 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:98 toms:32
2017.01.17 17:04:35.155 4: TSCUL_send:  CUL868_HM                         As 0B 98 A001 F11860 391421 0303
2017.01.17 17:04:35.155 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:184 toms:32
2017.01.17 17:04:35.252 2: TSCUL_condUpdate: CUL868_HM new condition ERROR-Overload
2017.01.17 17:04:35.256 4: TSCUL_Parse: CUL868_HM  278313 A FFF3 00298200 01 0A 97 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:04:35.341 2: TSCUL_condUpdate: CUL868_HM new condition Warning-HighLoad
2017.01.17 17:04:35.345 4: TSCUL_Parse: CUL868_HM  278402 A FF93 00298288 01 0B 98 A001 F11860 391421 03 _CCAdly:4 _dhmSt:208 -138
2017.01.17 17:04:35.568 4: TSCUL_Parse: CUL868_HM  278630 A FF93 00298516 01 0B 98 A001 F11860 391421 03 _CCAdly:4 _dhmSt:436 -138
2017.01.17 17:04:35.796 4: TSCUL_Parse: CUL868_HM  278857 A FF93 00298744 01 0B 98 A001 F11860 391421 03 _CCAdly:4 _dhmSt:664 -138
2017.01.17 17:04:35.993 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF90000123F6000B98A001F1186039142103
2017.01.17 17:04:35.993 4: TSCUL_Parse: CUL868_HM  279054 A FF90 00298968 00 0B 98 A001 F11860 391421 03 _sfail -138
2017.01.17 17:04:37.210 4: TSCUL_Parse: CUL868_HM  280266 A FF91 00300180 00 14 96 805E 391421 F11860 00000000000001D0000000 -73.5
2017.01.17 17:04:38.972 4: TSCUL_Parse: CUL868_HM  282038 A FF92 00301952 00 01 CC _ping -138
2017.01.17 17:04:41.090 4: TSCUL_send:  CUL868_HM                         As 0B 98 A001 F11860 391421 0303
2017.01.17 17:04:41.134 4: TSCUL_Parse: CUL868_HM  284195 A FF93 00304088 01 0B 98 A001 F11860 391421 03 _CCAdly:4 -138
2017.01.17 17:04:41.169 4: TSCUL_Parse: CUL868_HM  284224 A FF91 00304144 00 16 98 A010 391421 F11860 01391421023914210100000000 -74.5
2017.01.17 17:04:41.181 4: TSCUL_send:  CUL868_HM                         As 0A 98 8002 F11860 391421 00
2017.01.17 17:04:41.181 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:93 toms:32
2017.01.17 17:04:41.214 4: TSCUL_send:  CUL868_HM                         As 10 99 A001 F11860 391421 04040000000001
2017.01.17 17:04:41.214 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:177 toms:33
2017.01.17 17:04:41.308 2: TSCUL_condUpdate: CUL868_HM new condition ERROR-Overload
2017.01.17 17:04:41.312 4: TSCUL_Parse: CUL868_HM  284370 A FFF3 00304264 01 0A 98 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:04:41.401 2: TSCUL_condUpdate: CUL868_HM new condition Warning-HighLoad
2017.01.17 17:04:41.404 4: TSCUL_Parse: CUL868_HM  284462 A FF93 00304352 01 10 99 A001 F11860 391421 04 _CCAdly:4 _dhmSt:208 -138
2017.01.17 17:04:41.632 4: TSCUL_Parse: CUL868_HM  284694 A FF93 00304584 01 10 99 A001 F11860 391421 04 _CCAdly:4 _dhmSt:440 -138
2017.01.17 17:04:41.898 4: TSCUL_Parse: CUL868_HM  284960 A FF93 00304848 09 10 99 A001 F11860 391421 04 _CCAdly:36 _dhmSt:704 -138
2017.01.17 17:04:41.916 4: TSCUL_Parse: CUL868_HM  284969 A FF91 00304880 00 1A 99 A010 391421 F11860 0282008300840085008600870088008900 -75.5
2017.01.17 17:04:41.927 4: TSCUL_send:  CUL868_HM                         As 0A 99 8002 F11860 391421 00
2017.01.17 17:04:41.928 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:82 toms:32
2017.01.17 17:04:42.043 4: TSCUL_Parse: CUL868_HM  285105 A FF93 00305000 01 0A 99 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:04:43.934 4: TSCUL_send:  CUL868_HM                         As 10 99 A001 F11860 391421 04040000000001
2017.01.17 17:04:43.984 4: TSCUL_Parse: CUL868_HM  287046 A FF93 00306940 02 10 99 A001 F11860 391421 04 _CCAdly:8 _dhmSt:2060 -138
2017.01.17 17:04:44.217 4: TSCUL_Parse: CUL868_HM  287279 A FF93 00307172 01 10 99 A001 F11860 391421 04 _CCAdly:4 _dhmSt:2292 -138
2017.01.17 17:04:44.449 4: TSCUL_Parse: CUL868_HM  287510 A FF93 00307404 01 10 99 A001 F11860 391421 04 _CCAdly:4 _dhmSt:2524 -138
2017.01.17 17:04:44.645 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF9000012C6C001099A001F1186039142104
2017.01.17 17:04:44.645 4: TSCUL_Parse: CUL868_HM  287707 A FF90 00307632 00 10 99 A001 F11860 391421 04 _sfail -138
2017.01.17 17:04:46.430 4: TSCUL_Parse: CUL868_HM  289497 A FF92 00309424 00 01 CC _ping -138
2017.01.17 17:04:49.446 4: TSCUL_send:  CUL868_HM                         As 10 99 A001 F11860 391421 04040000000001
2017.01.17 17:04:49.496 4: TSCUL_Parse: CUL868_HM  292558 A FF93 00312456 01 10 99 A001 F11860 391421 04 _CCAdly:4 -138
2017.01.17 17:04:49.536 4: TSCUL_Parse: CUL868_HM  292589 A FF91 00312520 00 1A 99 A010 391421 F11860 0282008300840085008600870088008900 -75
2017.01.17 17:04:49.548 4: TSCUL_send:  CUL868_HM                         As 0A 99 8002 F11860 391421 00
2017.01.17 17:04:49.673 4: TSCUL_Parse: CUL868_HM  292734 A FF93 00312640 01 0A 99 8002 F11860 391421 00 _CCAdly:4 -138
2017.01.17 17:04:50.223 4: TSCUL_Parse: CUL868_HM  293280 A FF91 00313212 00 12 9A A010 391421 F11860 028A008B008C000000 -74.5
2017.01.17 17:04:50.235 4: TSCUL_send:  CUL868_HM                         As 0A 9A 8002 F11860 391421 00
2017.01.17 17:04:50.235 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:96 toms:32
2017.01.17 17:04:50.267 4: TSCUL_send:  CUL868_HM                         As 0B 9B A001 F11860 391421 0403
2017.01.17 17:04:50.267 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:183 toms:32
2017.01.17 17:04:50.364 2: TSCUL_condUpdate: CUL868_HM new condition ERROR-Overload
2017.01.17 17:04:50.368 4: TSCUL_Parse: CUL868_HM  293426 A FFF3 00313332 01 0A 9A 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:04:50.453 2: TSCUL_condUpdate: CUL868_HM new condition Warning-HighLoad
2017.01.17 17:04:50.457 4: TSCUL_Parse: CUL868_HM  293514 A FF93 00313420 01 0B 9B A001 F11860 391421 04 _CCAdly:4 _dhmSt:208 -138
2017.01.17 17:04:50.680 4: TSCUL_Parse: CUL868_HM  293742 A FF93 00313648 01 0B 9B A001 F11860 391421 04 _CCAdly:4 _dhmSt:436 -138
2017.01.17 17:04:50.908 4: TSCUL_Parse: CUL868_HM  293970 A FF93 00313876 01 0B 9B A001 F11860 391421 04 _CCAdly:4 _dhmSt:664 -138
2017.01.17 17:04:51.105 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF90000132BD000B9BA001F1186039142104
2017.01.17 17:04:51.105 4: TSCUL_Parse: CUL868_HM  294166 A FF90 00314100 00 0B 9B A001 F11860 391421 04 _sfail -138
2017.01.17 17:04:55.484 4: TSCUL_Parse: CUL868_HM  298550 A FF92 00318488 00 01 CC _ping -138
2017.01.17 17:04:56.067 4: TSCUL_send:  CUL868_HM                         As 0B 9B A001 F11860 391421 0403
2017.01.17 17:04:56.111 4: TSCUL_Parse: CUL868_HM  299173 A FF93 00319084 01 0B 9B A001 F11860 391421 04 _CCAdly:4 -138
2017.01.17 17:04:56.135 4: TSCUL_Parse: CUL868_HM  299194 A FF91 00319132 00 0E 9B A010 391421 F11860 0100000000 -74
2017.01.17 17:04:56.147 4: TSCUL_send:  CUL868_HM                         As 0A 9B 8002 F11860 391421 00
2017.01.17 17:04:56.147 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:96 toms:32
2017.01.17 17:04:56.180 4: TSCUL_send:  CUL868_HM                         As 10 9C A001 F11860 391421 01043914210304
2017.01.17 17:04:56.180 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:180 toms:33
2017.01.17 17:04:56.276 2: TSCUL_condUpdate: CUL868_HM new condition ERROR-Overload
2017.01.17 17:04:56.280 4: TSCUL_Parse: CUL868_HM  299338 A FFF3 00319252 01 0A 9B 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:04:56.369 2: TSCUL_condUpdate: CUL868_HM new condition Warning-HighLoad
2017.01.17 17:04:56.373 4: TSCUL_Parse: CUL868_HM  299431 A FF93 00319340 01 10 9C A001 F11860 391421 01 _CCAdly:4 _dhmSt:208 -138
2017.01.17 17:04:56.601 4: TSCUL_Parse: CUL868_HM  299662 A FF93 00319572 01 10 9C A001 F11860 391421 01 _CCAdly:4 _dhmSt:440 -138
2017.01.17 17:04:56.833 4: TSCUL_Parse: CUL868_HM  299894 A FF93 00319804 01 10 9C A001 F11860 391421 01 _CCAdly:4 _dhmSt:672 -138
2017.01.17 17:04:57.029 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF900001388800109CA001F1186039142101
2017.01.17 17:04:57.029 4: TSCUL_Parse: CUL868_HM  300091 A FF90 00320032 00 10 9C A001 F11860 391421 01 _sfail -138
2017.01.17 17:04:57.529 4: TSCUL_Parse: CUL868_HM  300589 A FF91 00320528 00 0E 9C A010 391421 F11860 0201010000 -74.5
2017.01.17 17:04:57.542 4: TSCUL_send:  CUL868_HM                         As 0A 9C 8002 F11860 391421 00
2017.01.17 17:04:57.542 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:95 toms:32
2017.01.17 17:04:57.574 4: TSCUL_send:  CUL868_HM                         As 10 9D A001 F11860 391421 02043914210304
2017.01.17 17:04:57.575 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:179 toms:33
2017.01.17 17:04:57.671 2: TSCUL_condUpdate: CUL868_HM new condition ERROR-Overload
2017.01.17 17:04:57.675 4: TSCUL_Parse: CUL868_HM  300732 A FFF3 00320648 01 0A 9C 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:04:57.764 2: TSCUL_condUpdate: CUL868_HM new condition Warning-HighLoad
2017.01.17 17:04:57.768 4: TSCUL_Parse: CUL868_HM  300825 A FF93 00320736 01 10 9D A001 F11860 391421 02 _CCAdly:4 _dhmSt:208 -138
2017.01.17 17:04:57.995 4: TSCUL_Parse: CUL868_HM  301056 A FF93 00320968 01 10 9D A001 F11860 391421 02 _CCAdly:4 _dhmSt:440 -138
2017.01.17 17:04:58.227 4: TSCUL_Parse: CUL868_HM  301288 A FF93 00321200 01 10 9D A001 F11860 391421 02 _CCAdly:4 _dhmSt:672 -138
2017.01.17 17:04:58.423 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF90000139E500109DA001F1186039142102
2017.01.17 17:04:58.423 4: TSCUL_Parse: CUL868_HM  301485 A FF90 00321428 00 10 9D A001 F11860 391421 02 _sfail -138
2017.01.17 17:05:01.418 4: TSCUL_Parse: CUL868_HM  304484 A FF92 00324400 00 01 CC _ping -138
2017.01.17 17:05:03.059 4: TSCUL_send:  CUL868_HM                         As 10 9D A001 F11860 391421 02043914210304
2017.01.17 17:05:03.110 4: TSCUL_Parse: CUL868_HM  306171 A FF93 00326088 01 10 9D A001 F11860 391421 02 _CCAdly:4 -138
2017.01.17 17:05:03.134 4: TSCUL_Parse: CUL868_HM  306193 A FF91 00326140 00 0E 9D A010 391421 F11860 0201010000 -75
2017.01.17 17:05:03.146 4: TSCUL_send:  CUL868_HM                         As 0A 9D 8002 F11860 391421 00
2017.01.17 17:05:03.146 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:96 toms:32
2017.01.17 17:05:03.179 4: TSCUL_send:  CUL868_HM                         As 10 9E A001 F11860 391421 03043914210103
2017.01.17 17:05:03.179 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:180 toms:33
2017.01.17 17:05:03.275 2: TSCUL_condUpdate: CUL868_HM new condition ERROR-Overload
2017.01.17 17:05:03.279 4: TSCUL_Parse: CUL868_HM  306337 A FFF3 00326260 01 0A 9D 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:05:03.368 2: TSCUL_condUpdate: CUL868_HM new condition Warning-HighLoad
2017.01.17 17:05:03.372 4: TSCUL_Parse: CUL868_HM  306430 A FF93 00326348 01 10 9E A001 F11860 391421 03 _CCAdly:4 _dhmSt:208 -138
2017.01.17 17:05:03.600 4: TSCUL_Parse: CUL868_HM  306661 A FF93 00326580 01 10 9E A001 F11860 391421 03 _CCAdly:4 _dhmSt:440 -138
2017.01.17 17:05:03.831 4: TSCUL_Parse: CUL868_HM  306893 A FF93 00326812 01 10 9E A001 F11860 391421 03 _CCAdly:4 _dhmSt:672 -138
2017.01.17 17:05:04.028 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF9000013F6000109EA001F1186039142103
2017.01.17 17:05:04.028 4: TSCUL_Parse: CUL868_HM  307090 A FF90 00327040 00 10 9E A001 F11860 391421 03 _sfail -138
2017.01.17 17:05:08.030 4: TSCUL_Parse: CUL868_HM  311085 A FF91 00331040 00 18 9F A010 391421 F11860 028700880089008A008B008C000000 -74
2017.01.17 17:05:08.046 4: TSCUL_send:  CUL868_HM                         As 0A 9F 8002 F11860 391421 00
2017.01.17 17:05:08.046 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:90 toms:32
2017.01.17 17:05:08.079 4: TSCUL_send:  CUL868_HM                         As 10 A0 A001 F11860 391421 03043914210203
2017.01.17 17:05:08.079 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:174 toms:33
2017.01.17 17:05:08.169 2: TSCUL_condUpdate: CUL868_HM new condition ERROR-Overload
2017.01.17 17:05:08.173 4: TSCUL_Parse: CUL868_HM  311231 A FFF3 00331160 01 0A 9F 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:05:08.262 2: TSCUL_condUpdate: CUL868_HM new condition Warning-HighLoad
2017.01.17 17:05:08.265 4: TSCUL_Parse: CUL868_HM  311323 A FF93 00331248 01 10 A0 A001 F11860 391421 03 _CCAdly:4 _dhmSt:208 -138
2017.01.17 17:05:08.389 4: TSCUL_Parse: CUL868_HM  311455 A FF92 00331408 00 01 CC _ping -138
2017.01.17 17:05:08.493 4: TSCUL_Parse: CUL868_HM  311555 A FF93 00331480 01 10 A0 A001 F11860 391421 03 _CCAdly:4 _dhmSt:440 -138
2017.01.17 17:05:08.758 4: TSCUL_Parse: CUL868_HM  311819 A FF93 00331744 09 10 A0 A001 F11860 391421 03 _CCAdly:36 _dhmSt:704 -138
2017.01.17 17:05:08.775 4: TSCUL_Parse: CUL868_HM  311828 A FF91 00331772 00 1A A0 A010 391421 F11860 020200030004320564060007FF080009FF -72.5
2017.01.17 17:05:08.787 4: TSCUL_send:  CUL868_HM                         As 0A A0 8002 F11860 391421 00
2017.01.17 17:05:08.787 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:80 toms:32
2017.01.17 17:05:08.900 4: TSCUL_Parse: CUL868_HM  311962 A FF93 00331892 01 0A A0 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:05:10.790 4: TSCUL_send:  CUL868_HM                         As 10 A0 A001 F11860 391421 03043914210203
2017.01.17 17:05:10.848 4: TSCUL_Parse: CUL868_HM  313910 A FF93 00333836 03 10 A0 A001 F11860 391421 03 _CCAdly:12 _dhmSt:2064 -138
2017.01.17 17:05:11.082 4: TSCUL_Parse: CUL868_HM  314144 A FF93 00334072 01 10 A0 A001 F11860 391421 03 _CCAdly:4 _dhmSt:2300 -138
2017.01.17 17:05:11.314 4: TSCUL_Parse: CUL868_HM  314375 A FF93 00334304 01 10 A0 A001 F11860 391421 03 _CCAdly:4 _dhmSt:2532 -138
2017.01.17 17:05:11.510 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF90000146B10010A0A001F1186039142103
2017.01.17 17:05:11.510 4: TSCUL_Parse: CUL868_HM  314572 A FF90 00334532 00 10 A0 A001 F11860 391421 03 _sfail -138
2017.01.17 17:05:14.740 4: TSCUL_Parse: CUL868_HM  317796 A FF91 00337760 00 14 98 805E 391421 F11860 00000000000001D0000000 -75.5
2017.01.17 17:05:16.818 4: TSCUL_send:  CUL868_HM                         As 10 A0 A001 F11860 391421 03043914210203
2017.01.17 17:05:16.869 4: TSCUL_Parse: CUL868_HM  319930 A FF93 00339864 01 10 A0 A001 F11860 391421 03 _CCAdly:4 _dhmSt:2104 -138
2017.01.17 17:05:17.102 4: TSCUL_Parse: CUL868_HM  320164 A FF93 00340100 01 10 A0 A001 F11860 391421 03 _CCAdly:4 _dhmSt:2340 -138
2017.01.17 17:05:17.334 4: TSCUL_Parse: CUL868_HM  320395 A FF93 00340332 01 10 A0 A001 F11860 391421 03 _CCAdly:4 _dhmSt:2572 -138
2017.01.17 17:05:17.530 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF9000014C940010A0A001F1186039142103
2017.01.17 17:05:17.530 4: TSCUL_Parse: CUL868_HM  320592 A FF90 00340560 00 10 A0 A001 F11860 391421 03 _sfail -138
2017.01.17 17:05:17.606 4: TSCUL_Parse: CUL868_HM  320659 A FF91 00340624 00 1A A0 A010 391421 F11860 020200030004320564060007FF080009FF -79.5
2017.01.17 17:05:17.618 4: TSCUL_send:  CUL868_HM                         As 0A A0 8002 F11860 391421 00
2017.01.17 17:05:17.618 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:89 toms:32
2017.01.17 17:05:17.741 4: TSCUL_Parse: CUL868_HM  320802 A FF93 00340744 01 0A A0 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:05:19.626 4: TSCUL_send:  CUL868_HM                         As 10 A0 A001 F11860 391421 03043914210203
2017.01.17 17:05:19.676 4: TSCUL_Parse: CUL868_HM  322738 A FF93 00342676 01 10 A0 A001 F11860 391421 03 _CCAdly:4 _dhmSt:2052 -138
2017.01.17 17:05:19.910 4: TSCUL_Parse: CUL868_HM  322972 A FF93 00342912 01 10 A0 A001 F11860 391421 03 _CCAdly:4 _dhmSt:2288 -138
2017.01.17 17:05:20.142 4: TSCUL_Parse: CUL868_HM  323204 A FF93 00343144 01 10 A0 A001 F11860 391421 03 _CCAdly:4 _dhmSt:2520 -138
2017.01.17 17:05:20.339 1: TSCUL_ParseTsHM CUL868_HM HM repeat failed sending to 391421/Licht_Esszimmer: AFF9000014F530010A0A001F1186039142103
2017.01.17 17:05:20.339 4: TSCUL_Parse: CUL868_HM  323400 A FF90 00343372 00 10 A0 A001 F11860 391421 03 _sfail -138
2017.01.17 17:05:20.394 4: TSCUL_Parse: CUL868_HM  323448 A FF91 00343416 00 18 A0 A010 391421 F11860 0287FF880089FF8A218B138C330000 -78.5
2017.01.17 17:05:20.409 4: TSCUL_send:  CUL868_HM                         As 0A A0 8002 F11860 391421 00
2017.01.17 17:05:20.529 4: TSCUL_Parse: CUL868_HM  323590 A FF93 00343536 01 0A A0 8002 F11860 391421 00 _CCAdly:4 _dhmSt:2912 -138
state              CMDs_done 2017-01-17 17:05:20


sw1pbu Licht aus und wieder ein:
2017.01.17 17:07:00.501 4: TSCUL_send:  CUL868_HM                         As 0E 9F A011 F11860 391421 0204000000
2017.01.17 17:07:00.549 4: TSCUL_Parse: CUL868_HM  423610 A FF93 00443684 02 0E 9F A011 F11860 391421 02 _CCAdly:8 -138
2017.01.17 17:07:00.573 4: TSCUL_Parse: CUL868_HM  423632 A FF91 00443732 00 0E 9F 8002 391421 F11860 0104000000 -72.5
2017.01.17 17:07:04.122 4: TSCUL_Parse: CUL868_HM  427181 A FF91 00447288 00 0E A2 A410 391421 F11860 0604000000 -75.5
2017.01.17 17:07:04.134 4: TSCUL_send:  CUL868_HM                         As 0A A2 8002 F11860 391421 00
2017.01.17 17:07:04.134 3: TSCUL_XmitDlyHM:  CUL868_HM  id:391421 dDly:98 toms:32
2017.01.17 17:07:04.265 4: TSCUL_Parse: CUL868_HM  427327 A FF93 00447408 01 0A A2 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:07:06.935 4: TSCUL_send:  CUL868_HM                         As 0E A3 A011 F11860 391421 0204C80000
2017.01.17 17:07:06.983 4: TSCUL_Parse: CUL868_HM  430045 A FF93 00450128 02 0E A3 A011 F11860 391421 02 _CCAdly:8 _dhmSt:2840 -138
2017.01.17 17:07:07.217 4: TSCUL_Parse: CUL868_HM  430278 A FF93 00450360 01 0E A3 A011 F11860 391421 02 _CCAdly:4 -138
2017.01.17 17:07:07.240 4: TSCUL_Parse: CUL868_HM  430300 A FF91 00450408 00 0E A3 8002 391421 F11860 0104C80000 -77.5


evtl wäre die Board.h interessant. Ich hab das hexfile TSnanoCUL.hex aus dem obersten Verzechinis genommen und nicht selbst kompiliert
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 17 Januar 2017, 18:30:02
dein cul hat wohl ein speicherproblem, da overload und highload direkt hintereinander kommt.

2017.01.17 17:04:15.849 2: TSCUL_condUpdate: CUL868_HM new condition ERROR-Overload
2017.01.17 17:04:15.856 4: TSCUL_Parse: CUL868_HM  258911 A FFF3 00278772 01 0A 93 8002 F11860 391421 00 _CCAdly:4 _dhmSt:120 -138
2017.01.17 17:04:15.938 2: TSCUL_condUpdate: CUL868_HM new condition Warning-HighLoad

schau dir mal den tsculfw-thread an ab der stelle, wo es die aktuellen files gibt. da wird irgendwo dieses verhalten besprochen.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marcel85 am 17 Januar 2017, 20:17:03
Ich stand genau vor dem selben Problem mit overload und highload.
Habe mich nun "glücklicherweise" doch für den HM-UART entschieden. Damit funktioniert nun alles wo es soll.
Ich weiß das dir die Antwort bei deinem eigentlichen Problem nicht weiterhilft, aber vielleicht solltest du es auch mit diesem probieren und den nanoCUL einmotten.

Jetzt muss ich nur noch rauskriegen wie ich 2 TeamLeads dazu bekomme miteinander zu kommunizieren.
Meine Situation sieht im Moment wie folgt aus:
Unser Haus (EG,OG) habe ich nun komplett mit den RM ausgestattet und dieses mit dem TeamLead gepeert. So weit, so gut!
Jetzt möchte ich die RM in der Wohnung im Kellergeschoss mit einem separaten TeamLead peeren. Idealerweise sollte dieser dann auch noch dem ersten TeamLead mitteilen wenn es unten brennt.
Andersrum muss das ganze wiederum nicht funktionieren. Ich möchte nicht das unsere Mieterin mal damit belästigt wird, wenn wir mal aus versehen den Ofen zu lange offen lassen und dadurch die RM losgehen.

Ich hoffe das ich es verständlich rüberbringen konnte und hoffe das mir damit jemand weiterhelfen kann.

Gruß
Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 17 Januar 2017, 20:30:19
Kann ich den hm uart an einen linux pc anschließen?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marcel85 am 17 Januar 2017, 20:42:54
Nutzt du keinen Raspberry?
Ich glaube dann nicht.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 17 Januar 2017, 22:32:06
Kann ich den hm uart an einen linux pc anschließen?
Klar, USB/seriell Wandler dran und geht. Oder ESP8266 und über Wlan erreichbar.
Anleitungen findest Du inklusive Bilder hier im Forum

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 18 Januar 2017, 09:16:27
Zitat
Klar, USB/seriell Wandler dran und geht. Oder ESP8266 und über Wlan erreichbar.
Anleitungen findest Du inklusive Bilder hier im Forum
@ Otto: Danke.
Wenn ich das mit dem Cul nicht hinbekomme, mach ich das. Hab eh ein paar Wemos mini D1 rumliegen. Den Link zur Anleitung mit Bildern hats du nicht zufällig parat?

Hätte noch eine Idee:
Ich hab auch einen Busware Cul V3. Hätte ich mit dem eine Chance gegenüber einem nanoCul? Hat jemand ein Board.h, mit der der TSCUL funktiuoniert? oder welche Paraneter wären wichtig (#define ASKSIN_SEND_BUFS       von 3 auf 9 oder was kann man allle rausschmeissen zwecks Speichersparen, ...)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 18 Januar 2017, 10:09:46
Zitat
Hätte noch eine Idee:
Ich hab auch einen Busware Cul V3. Hätte ich mit dem eine Chance gegenüber einem nanoCul? Hat jemand ein Board.h, mit der der TSCUL funktiuoniert? oder welche Paraneter wären wichtig (#define ASKSIN_SEND_BUFS       von 3 auf 9 oder was kann man allle rausschmeissen zwecks Speichersparen, ...)
der culv3 sollte perfekt sein für die tsculfw, meine ich.
schau mal in die zip datei von noansi, da müsste bereits ein passendes hex file zum flashen drin sein.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 18 Januar 2017, 12:49:50
Hi,
klar hab mal kurz gesucht:
Zum einen gibt es dieses Projekt -> https://forum.fhem.de/index.php/topic,62651.msg540843.html#msg540843
ok ohne Bilder aber ist eigentlich simpel https://forum.fhem.de/index.php/topic,63271.0.html
Dann gibt es das Projekt -> https://forum.fhem.de/index.php/topic,56606.0.html
Google findet sogar ein Video https://www.youtube.com/watch?v=RJ8xQvJ5C9Y

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 18 Januar 2017, 18:47:58
Hab jetzt den Busware als TSCUL.
Pairen klappt auf anhieb. Den rest muss ich die Tage mal testen. melde mich dann wieder.
Sieht aber erst mal wesentliuch besser aus als mit nanoCul :-)
@frank: Danke
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 19 Januar 2017, 22:10:25
Hi zusammen,

habe heute bei meinem SD-2 ein kurzes piepen gehört und seitdem finde ich folgendes reading:
smokeChamber degraded
Das gesamte List des device:
Internals:
   CFGFN
   DEF        4C6A1A
   IODev      SYS.gw.HM.lan.01
   LASTInputDev SYS.gw.HM.usb.01
   MSGCNT     11
   NAME       EG.az.RM.Decke
   NOTIFYDEV  global
   NR         744
   NTFY_ORDER 50-EG.az.RM.Decke
   STATE      off
   SYS.gw.HM.lan.01_MSGCNT 6
   SYS.gw.HM.lan.01_RAWMSG E4C6A1A,0000,04834650,FF,FFB5,86A6104C6A1A26E8D606010004
   SYS.gw.HM.lan.01_RSSI -75
   SYS.gw.HM.lan.01_TIME 2017-01-19 19:23:17
   SYS.gw.HM.usb.01_MSGCNT 5
   SYS.gw.HM.usb.01_RAWMSG E4C6A1A,0000,C97E2899,FF,FFCC,86A6104C6A1A26E8D606010004
   SYS.gw.HM.usb.01_RSSI -52
   SYS.gw.HM.usb.01_TIME 2017-01-19 19:23:17
   TYPE       CUL_HM
   lastMsg    No:86 - t:10 s:4C6A1A d:26E8D6 06010004
   peerList   SYS.xx.RM.01_virt_TeamLead,
   protLastRcv 2017-01-19 19:23:17
   protResnd  1 last_at:2017-01-17 20:33:17
   protSnd    6 last_at:2017-01-19 19:23:17
   protState  CMDs_done
   rssi_SYS.gw.HM.lan.01 avg:-69 lst:-69 cnt:1 max:-69 min:-69
   rssi_at_SYS.gw.HM.lan.01 cnt:6 lst:-75 avg:-74.5 min:-76 max:-73
   rssi_at_SYS.gw.HM.usb.01 max:-46 min:-56 cnt:5 lst:-52 avg:-50.8
   Helper:
     Dblog:
       Activity:
         Sys.dblog:
           TIME       1484681589.78608
           VALUE      alive
       Alarmtest:
         Sys.dblog:
           TIME       1484850197.26968
           VALUE      ok
       Battery:
         Sys.dblog:
           TIME       1484850197.26968
           VALUE      ok
       Level:
         Sys.dblog:
           TIME       1484850197.26968
           VALUE      0
       Smokechamber:
         Sys.dblog:
           TIME       1484850197.26968
           VALUE      degraded
       State:
         Sys.dblog:
           TIME       1484850197.26968
           VALUE      off
   Readings:
     2017-01-17 20:33:09   Activity        alive
     2016-07-22 22:30:21   CommandAccepted yes
     2016-07-22 22:30:20   D-firmware      1.0
     2016-07-22 22:30:20   D-serialNr      NEQ0449370
     2016-09-14 12:31:34   PairedTo        0x26E8D6
     2016-07-22 22:23:47   R-devRepeatCntMax 0
     2016-07-22 22:31:38   R-pairCentral   0x26E8D6
     2016-09-14 12:31:34   RegL_00.        02:01 0A:26 0B:E8 0C:D6 16:00 1F:00 00:00
     2016-07-22 22:30:21   aesCommToDev    ok
     2016-07-22 22:30:21   aesKeyNbr       02
     2017-01-19 19:23:17   alarmTest       ok
     2017-01-19 19:23:17   battery         ok
     2017-01-19 19:23:17   level           0
     2017-01-17 20:33:09   peerList        SYS.xx.RM.01_virt_TeamLead,
     2016-10-12 20:29:28   powerOn         2016-10-12 20:29:28
     2017-01-19 19:23:17   recentStateType info
     2016-07-22 22:30:26   sabotageAttackId_ErrIoId_123ABC cnt:4
     2016-07-22 22:30:26   sabotageAttack_ErrIoAttack cnt 4
     2016-09-14 12:31:34   sdRepeat        off
     2017-01-19 19:23:17   smokeChamber    degraded
     2016-07-24 17:24:11   smoke_detect    none
     2017-01-19 19:23:17   state           off
     2016-07-24 17:23:15   teamCall        from SYS.bm.01_virt:07
   Helper:
     HM_CMDNR   134
     cSnd       ,0126E8D64C6A1A010E
     mId        00AA
     rxType     6
     supp_Pair_Rep 0
     Ack:
     Expert:
       def        1
       det        1
       raw        1
       tpl        0
     Io:
       newChn     +4C6A1A,00,01,00
       nextSend   1484850197.3904
       rxt        0
       vccu       SYS.gw.HM.vccu.01
       p:
         4C6A1A
         00
         01
         00
     Mrssi:
       mNo        86
       Io:
         SYS.gw.HM.lan.01 -73
         SYS.gw.HM.usb.01 -52
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         SYS.gw.HM.lan.01
       flg        A
       ts         1484850197.26653
       ack:
         HASH(0x558db9a34978)
         86800226E8D64C6A1A00
     Rssi:
       Sys.gw.hm.lan.01:
         avg        -69
         cnt        1
         lst        -69
         max        -69
         min        -69
       At_sys.gw.hm.lan.01:
         avg        -74.5
         cnt        6
         lst        -75
         max        -73
         min        -76
       At_sys.gw.hm.usb.01:
         avg        -50.8
         cnt        5
         lst        -52
         max        -46
         min        -56
     Shadowreg:
     Tmpl:
Attributes:
   IODev      SYS.gw.HM.lan.01
   IOgrp      SYS.gw.HM.vccu.01
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   devStateIcon off:general_ok *:secur_alarm
   expert     3_allReg+raw
   firmware   1.0
   group      Brandmelder
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,22119001,
   room       Arbeitszimmer,Brandmelder
   serialNr   NEQ0449370
   subType    smokeDetector
   webCmd     statusRequest:getConfig

hat jemand eine Ahnung was das bedeutet?


Grüße Christian
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 20 Januar 2017, 14:01:23
Laut Bedienungsanleitung deutet das auf eine verschmutzte Rauchkammer hin und der BW-Melder soll nicht weiter benutzt werden...

http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD-2_UM_eQ-3_GE_web.pdf (http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD-2_UM_eQ-3_GE_web.pdf)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 21 Januar 2017, 08:17:28
Also hier bin ich wieder: Ich verwende nun den Busware CUL V3
Ich hab alle meine sechs Rauchmelder nun am laufen :-)

Zweil Dinge im Moment, die mich beschäftigen:
1) Um den hmkey zu übertragen, muss ich aber zweimal hintereinander pairen. Sonst geht es nicht. Seltsam.... ist aber wirklich so. Hab x Versuche gemacht, bis sich herauskristallisierte, dass ich zweimal pairen muss, bis das reading aeskeynbr den key annahm.

2) Wenn ich fhem neu starte, geht mein Stick in "CUL868_HM:ERROR-Overload,".
Wahrscheinlich, weil ich sechs Rauchmelder dran hab. Ist das zuviel? oder kann man igendeinen Buffer in der board.h noch vergrößern?
#define ASKSIN_SEND_BUFS       9 ist bereits auf neun...

Die Standard board.h für den CUL sieht so aus:
#ifndef _BOARD_H
#define _BOARD_H

//#define HAS_NO_VERSION_CHANGE_FACTORY_RESET  // define to disable factory reset of EEPROM on version change

// Feature definitions
#define MULTI_FREQ_DEVICE // available in multiple versions: 433MHz,868MHz
#define BOARD_ID_STR            "CUL868"
#define BOARD_ID_USTR           L"CUL868"

#define BOARD_ID_STR433         "CUL433"
#define BOARD_ID_USTR433        L"CUL433"

//#define BOARD_ID_STR915         "CUL915"
//#define BOARD_ID_USTR915        L"CUL915"

#if defined(CUL_V3)
#  define CUL_HW_REVISION "CUL_V3.4"  // adapt to version print on circuit board
#elif defined(CUL_V4)
#  define CUL_HW_REVISION "CUL_V4"  // adapt to version print on circuit board
#elif defined(CUL_V2_HM)
#  define CUL_HW_REVISION "CUL_V2"
#elif defined(CUL_V2_MAX)
#  define CUL_HW_REVISION "CUL_V2"
#elif defined(CUL_V2)
#  define CUL_HW_REVISION "CUL_V2"    // No more mem for this feature
#else //defined(CUL_V1)
#  define CUL_HW_REVISION "CUL_V1"  // adapt to version print on circuit board
#endif

#define HAS_SPI_SEND_INLINE             // SPI single byte send is inlined

#define HAS_PREPARE_BOOTLOADER
//#define HAS_WATCHDOG_TEST

#define HAS_USB                  1
#define USB_BUFSIZE             64      // Must be a supported USB endpoint size
#define USB_MAX_POWER          100
//#define NO_USB_SERIAL_NO                // define to not have any USB serial number, saves Flash memory


// customizable USB serial number in PROGMEM support
#ifndef USB_SERIAL_NO_USTR       // also defineable in makefile
# define USB_SERIAL_NO_USTR      L"868000"  // 6 chars serial number for 868MHz device, change it to customize, undef if feature is not wanted
#endif
#ifndef USB_SERIAL_NO_USTR433
# define USB_SERIAL_NO_USTR433   L"433000"  // 6 chars serial number for 433MHz device, change it to customize
#endif
//#ifndef USB_SERIAL_NO_USTR915
//# define USB_SERIAL_NO_USTR915   L"915000"  // 6 chars serial number for 915MHz device, change it to customize
//#endif

//#define CDCLUFA_RXDISCARDFULL // can be defined to discard incomming data, if rx buffer is full

// 2.5KB Internal SRAM for CUL V3 with atmega32u4
#define TTY_BUFSIZE             128  // 4 buffers, RAM: TTY_BUFSIZE*4
#define CMD_BUFSIZE             (2 + 4 + (2 * 50) + 1)      // maximum length of a command (without \r \n) +1 for terminating 0

#define HAS_CC_INTERRUPT_COUNTER             // cc1101 interrupt counter, read with command CC0, usefull for debbugging

#define HAS_FHT_80b                     // PROGMEM: 1374b, RAM: 90b
#define HAS_FHT_8v                      // PROGMEM:  586b  RAM: 23b
#define HAS_FHT_SEND
#define HAS_FS20_SEND
//#define HAS_RF_ROUTER                   // PROGMEM: 1248b  RAM: 44b
//#define RFR_DEBUG                     // PROGMEM:  354b  RAM: 14b
#define HAS_GET_TIMESTAMP
#define HAS_FULL_RF_ANALYZE
#define HAS_NO_WS2000_V1_1_SUPPORT    // undef to enable WS2000 V1.1 protocol support -> but more wrong receptions possible
#define HAS_RF_RECEIVE_TIMESTAMP
#define HAS_RF_RECEIVE_FILTER_ADAPTION
#define HAS_RF_RECEIVE_KEYING
#define HAS_SLOWRF_RECTO_ACTION
#define HAS_RSSI_DISPLAY_NONLCD
#define HAS_RF_RECEIVE_RECORD_LOWMEM
#define HAS_RF_RECEIVE_RECORD_SYNC          // makes only sense without HAS_RF_RECEIVE_RECORD_OVERIDE_FULL, cause we have only a very shot buffer
#define HAS_RF_RECEIVE_RECORD_OVERIDE_FULL
#define HAS_RF_RECEIVE_RECORD_APPEND_TO_DATA

#define HAS_CC1101_RX
#define HAS_CC1101_TO_STATE
#define HAS_CC1101_RX_PLL_LOCK_CHECK_TASK_WAIT
#define HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX
#define HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX_FUNC
#define HAS_CC1101_FORCE_CAL_MANUAL
#define HAS_CC1101_PLL_LOCK_CHECK_MSG
#define HAS_CC1101_PLL_LOCK_CHECK_MSG_RXTX
#define HAS_CC1101_PLL_LOCK_CHECK_MSG_SW
#define HAS_CC1101_PLL_LOCK_CHECK_MSG_CALSTATE

#define FHTBUF_SIZE          174      //                 RAM: 174b
#define RCV_BUCKETS            4      //                 RAM: 25b * bucket
#define FULL_CC1101_PA                // PROGMEM:  108b
#define HAS_RAWSEND                   //
#define HAS_EM_SEND                   //
#define HAS_KS_SEND                   //
#define HAS_TX3_SEND                  //
#define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
#define HAS_ASKSIN
#define ASKSIN_SEND_BUFS       9      // ASKSIN send buffers, 58b RAM each buffer
#define HAS_MORITZ
#define HAS_RWE
#define HAS_REVOLT   // define to enable REVOLT support
#define HAS_ESA      // define to enable ESA support
#define HAS_TX3
#define HAS_IT       // define to enable IT support
#define HAS_INTERTECHNO     // define to enable IT send support
#define HAS_INTERTECHNO_V3
#define HAS_HOMEEASY
#define HAS_UNIROLL
#define HAS_HOERMANN
#define HAS_SOMFY_RTS
#define HAS_MBUS
#define HAS_MEMFN
#define HAS_MEMORY_TESTMEM              // compiles in mT extension for testing RAM


#if defined(CUL_V3)
// 2.5KB Internal SRAM
//# define TTY_BUFSIZE          128      // 4 buffers, RAM: TTY_BUFSIZE*4
//# define FHTBUF_SIZE          174      //                 RAM: 174b
//# define RCV_BUCKETS            4      //                 RAM: 25b * bucket
//# undef HAS_CC_INTERRUPT_COUNTER             // cc1101 interrupt counter, read with command CC0, usefull for debbugging
//# undef HAS_FHT_80b                     // PROGMEM: 1374b, RAM: 90b
//# undef HAS_FHT_8v                      // PROGMEM:  586b  RAM: 23b
//# undef HAS_FHT_SEND
//# undef HAS_FS20_SEND
# undef HAS_RF_ROUTER                   // PROGMEM: 1248b  RAM: 44b
# undef RFR_DEBUG                     // PROGMEM:  354b  RAM: 14b
//# undef HAS_GET_TIMESTAMP
//# undef HAS_FULL_RF_ANALYZE
//# undef HAS_NO_WS2000_V1_1_SUPPORT    // undef to enable WS2000 V1.1 protocol support -> but more wrong receptions possible
//# undef HAS_RF_RECEIVE_TIMESTAMP
//# undef HAS_RF_RECEIVE_FILTER_ADAPTION
//# undef HAS_RF_RECEIVE_KEYING
//# undef HAS_SLOWRF_RECTO_ACTION
# undef HAS_RSSI_DISPLAY_NONLCD
//# undef HAS_RF_RECEIVE_RECORD_LOWMEM
# undef HAS_RF_RECEIVE_RECORD_SYNC          // makes only sense without HAS_RF_RECEIVE_RECORD_OVERIDE_FULL, cause we have only a very shot buffer
//# undef HAS_RF_RECEIVE_RECORD_OVERIDE_FULL
//# undef HAS_RF_RECEIVE_RECORD_APPEND_TO_DATA
//# undef FULL_CC1101_PA                // PROGMEM:  108b
//# undef HAS_RAWSEND                   //
//# undef HAS_EM_SEND                   //
//# undef HAS_KS_SEND                   //
//# undef HAS_TX3_SEND                  //
# undef HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
//# undef HAS_ASKSIN
//#define ASKSIN_SEND_BUFS       9      // ASKSIN send buffers, 58b RAM each buffer
//# undef HAS_MORITZ
//# undef HAS_RWE
//# undef HAS_REVOLT   // define to enable REVOLT support
//# undef HAS_ESA      // define to enable ESA support
//# undef HAS_TX3
//# undef HAS_IT       // define to enable IT support
//# undef HAS_INTERTECHNO     // define to enable IT send support
//# undef HAS_INTERTECHNO_V3
//# undef HAS_HOMEEASY
//# undef HAS_UNIROLL
//# undef HAS_HOERMANN
//# undef HAS_SOMFY_RTS
# undef HAS_MBUS
//# undef HAS_MEMFN
# undef HAS_MEMORY_TESTMEM              // compiles in mT extension for testing RAM
#endif // CUL_V3


#if defined(CUL_V4)
// 1KB Internal SRAM
# define RFR_SHADOW                    // PROGMEM: 10b    RAM: -(TTY_BUFSIZE+3)
# undef TTY_BUFSIZE
//# undef FHTBUF_SIZE
# undef RCV_BUCKETS
# undef ASKSIN_SEND_BUFS

# define TTY_BUFSIZE           64      // RAM: TTY_BUFSIZE*4
//# define FHTBUF_SIZE          74      //                 RAM: 74b
# define RCV_BUCKETS            2      //                 RAM: 19b * RCV_BUCKETS
# undef HAS_CC_INTERRUPT_COUNTER             // cc1101 interrupt counter, read with command CC0, usefull for debbugging
# undef HAS_FHT_80b                     // PROGMEM: 1374b, RAM: 90b
# undef HAS_FHT_8v                      // PROGMEM:  586b  RAM: 23b
# undef HAS_FHT_SEND
//# undef HAS_FS20_SEND
# undef HAS_RF_ROUTER                   // PROGMEM: 1248b  RAM: 44b
# undef RFR_DEBUG                     // PROGMEM:  354b  RAM: 14b
//# undef HAS_GET_TIMESTAMP
# undef HAS_FULL_RF_ANALYZE
//# undef HAS_NO_WS2000_V1_1_SUPPORT    // undef to enable WS2000 V1.1 protocol support -> but more wrong receptions possible
# undef HAS_RF_RECEIVE_TIMESTAMP
# undef HAS_RF_RECEIVE_FILTER_ADAPTION
# undef HAS_RF_RECEIVE_KEYING
//# undef HAS_SLOWRF_RECTO_ACTION
# undef HAS_RSSI_DISPLAY_NONLCD
# undef HAS_RF_RECEIVE_RECORD_LOWMEM
# undef HAS_RF_RECEIVE_RECORD_SYNC          // makes only sense without HAS_RF_RECEIVE_RECORD_OVERIDE_FULL, cause we have only a very shot buffer
# undef HAS_RF_RECEIVE_RECORD_OVERIDE_FULL
# undef HAS_RF_RECEIVE_RECORD_APPEND_TO_DATA
//# undef FULL_CC1101_PA                // PROGMEM:  108b
//# undef HAS_RAWSEND                   //
//# undef HAS_EM_SEND                   //
//# undef HAS_KS_SEND                   //
//# undef HAS_TX3_SEND                  //
//# undef HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
//# undef HAS_ASKSIN
#define ASKSIN_SEND_BUFS       2      // ASKSIN send buffers, 58b RAM each buffer
//# undef HAS_MORITZ
//# undef HAS_RWE
# undef HAS_REVOLT   // define to enable REVOLT support
# undef HAS_ESA      // define to enable ESA support
# undef HAS_TX3
# undef HAS_IT       // define to enable IT support
//# undef HAS_INTERTECHNO     // define to enable IT send support
//# undef HAS_INTERTECHNO_V3
//# undef HAS_HOMEEASY
//# undef HAS_UNIROLL
# undef HAS_HOERMANN
# undef HAS_SOMFY_RTS
# undef HAS_MBUS
# undef HAS_MEMFN
# undef HAS_MEMORY_TESTMEM              // compiles in mT extension for testing RAM
#endif // CUL_V4


#ifdef CUL_V2
// 512 Bytes Internal SRAM, 12kB Flash available
# define HAS_RF_RECEIVE_NOINLINE         // saves Flash memory, but increases interrupt time for SlowRf
# define RFR_SHADOW                    // PROGMEM: 10b    RAM: -(TTY_BUFSIZE+3)
# undef TTY_BUFSIZE
# undef FHTBUF_SIZE
# undef RCV_BUCKETS
# undef ASKSIN_SEND_BUFS

# define TTY_BUFSIZE           48      // RAM: TTY_BUFSIZE*4
# define FHTBUF_SIZE           74      //                 RAM: 174b
# define RCV_BUCKETS            2      //                 RAM: 19b * RCV_BUCKETS
# undef HAS_CC_INTERRUPT_COUNTER             // cc1101 interrupt counter, read with command CC0, usefull for debbugging
# undef HAS_FHT_80b                     // PROGMEM: 1374b, RAM: 90b
# undef HAS_FHT_8v                      // PROGMEM:  586b  RAM: 23b
# undef HAS_FHT_SEND
//# undef HAS_FS20_SEND
# undef HAS_RF_ROUTER                   // PROGMEM: 1248b  RAM: 44b
# undef RFR_DEBUG                     // PROGMEM:  354b  RAM: 14b
//# undef HAS_GET_TIMESTAMP
# undef HAS_FULL_RF_ANALYZE
//# undef HAS_NO_WS2000_V1_1_SUPPORT    // undef to enable WS2000 V1.1 protocol support -> but more wrong receptions possible
# undef HAS_RF_RECEIVE_TIMESTAMP
//# undef HAS_RF_RECEIVE_FILTER_ADAPTION
//# undef HAS_RF_RECEIVE_KEYING
# undef HAS_SLOWRF_RECTO_ACTION
# undef HAS_RSSI_DISPLAY_NONLCD
# undef HAS_RF_RECEIVE_RECORD_LOWMEM
# undef HAS_RF_RECEIVE_RECORD_SYNC          // makes only sense without HAS_RF_RECEIVE_RECORD_OVERIDE_FULL, cause we have only a very shot buffer
# undef HAS_RF_RECEIVE_RECORD_OVERIDE_FULL
# undef HAS_RF_RECEIVE_RECORD_APPEND_TO_DATA
# undef FULL_CC1101_PA                // PROGMEM:  108b
//# undef HAS_RAWSEND                   //
# undef HAS_EM_SEND                   //
# undef HAS_KS_SEND                   //
# undef HAS_TX3_SEND                  //
# undef HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
# undef HAS_ASKSIN
//#define ASKSIN_SEND_BUFS       2      // ASKSIN send buffers, 58b RAM each buffer
# undef HAS_MORITZ
# undef HAS_RWE
# undef HAS_REVOLT   // define to enable REVOLT support
# undef HAS_ESA      // define to enable ESA support
# undef HAS_TX3
# undef HAS_IT       // define to enable IT support
# undef HAS_INTERTECHNO     // define to enable IT send support
# undef HAS_INTERTECHNO_V3
# undef HAS_HOMEEASY
# undef HAS_UNIROLL
# undef HAS_HOERMANN
# undef HAS_SOMFY_RTS
# undef HAS_MBUS
# undef HAS_MEMFN
# undef HAS_MEMORY_TESTMEM              // compiles in mT extension for testing RAM
#endif // CUL_V2

#ifdef CUL_V2_HM
// 512 Bytes Internal SRAM, 12kB Flash available
#error "no memory to do that"
# define CUL_V2
# define HAS_RF_RECEIVE_NOINLINE         // saves Flash memory, but increases interrupt time for SlowRf
# define RFR_SHADOW                    // PROGMEM: 10b    RAM: -(TTY_BUFSIZE+3)
# undef TTY_BUFSIZE
# undef FHTBUF_SIZE
# undef RCV_BUCKETS
# undef ASKSIN_SEND_BUFS

# define TTY_BUFSIZE           64      // RAM: TTY_BUFSIZE*4
# define FHTBUF_SIZE           74      //                 RAM: 174b
# define RCV_BUCKETS            2      //                 RAM: 19b * RCV_BUCKETS
# undef HAS_CC_INTERRUPT_COUNTER             // cc1101 interrupt counter, read with command CC0, usefull for debbugging
# undef HAS_FHT_80b                     // PROGMEM: 1374b, RAM: 90b
# undef HAS_FHT_8v                      // PROGMEM:  586b  RAM: 23b
# undef HAS_FHT_SEND
# undef HAS_FS20_SEND
# undef HAS_RF_ROUTER                   // PROGMEM: 1248b  RAM: 44b
# undef RFR_DEBUG                     // PROGMEM:  354b  RAM: 14b
//# undef HAS_GET_TIMESTAMP
# undef HAS_FULL_RF_ANALYZE
//# undef HAS_NO_WS2000_V1_1_SUPPORT    // undef to enable WS2000 V1.1 protocol support -> but more wrong receptions possible
# undef HAS_RF_RECEIVE_TIMESTAMP
# undef HAS_RF_RECEIVE_FILTER_ADAPTION
# undef HAS_RF_RECEIVE_KEYING
# undef HAS_SLOWRF_RECTO_ACTION
# undef HAS_RSSI_DISPLAY_NONLCD
# undef HAS_RF_RECEIVE_RECORD_LOWMEM
# undef HAS_RF_RECEIVE_RECORD_SYNC          // makes only sense without HAS_RF_RECEIVE_RECORD_OVERIDE_FULL, cause we have only a very shot buffer
# undef HAS_RF_RECEIVE_RECORD_OVERIDE_FULL
# undef HAS_RF_RECEIVE_RECORD_APPEND_TO_DATA
# undef FULL_CC1101_PA                // PROGMEM:  108b
# undef HAS_RAWSEND                   //
# undef HAS_EM_SEND                   //
# undef HAS_KS_SEND                   //
# undef HAS_TX3_SEND                  //
# undef HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
//# undef HAS_ASKSIN
#define ASKSIN_SEND_BUFS       2      // ASKSIN send buffers, 58b RAM each buffer
# undef HAS_MORITZ
# undef HAS_RWE
# undef HAS_REVOLT   // define to enable REVOLT support
# undef HAS_ESA      // define to enable ESA support
# undef HAS_TX3
# undef HAS_IT       // define to enable IT support
# undef HAS_INTERTECHNO     // define to enable IT send support
# undef HAS_INTERTECHNO_V3
# undef HAS_HOMEEASY
# undef HAS_UNIROLL
# undef HAS_HOERMANN
# undef HAS_SOMFY_RTS
# undef HAS_MBUS
# undef HAS_MEMFN
# undef HAS_MEMORY_TESTMEM              // compiles in mT extension for testing RAM

# undef  BOARD_ID_STR
# define BOARD_ID_STR            "CUL_HM"
# undef  BOARD_ID_USTR
# define BOARD_ID_USTR           L"CUL_HM"
#endif // CUL_V2_HM

#ifdef CUL_V2_MAX
// 512 Bytes Internal SRAM, 12kB Flash available
# define CUL_V2
# define HAS_RF_RECEIVE_NOINLINE         // saves Flash memory, but increases interrupt time for SlowRf
# define RFR_SHADOW                    // PROGMEM: 10b    RAM: -(TTY_BUFSIZE+3)
# undef TTY_BUFSIZE
# undef FHTBUF_SIZE
# undef RCV_BUCKETS
# undef ASKSIN_SEND_BUFS

# define TTY_BUFSIZE           64      // RAM: TTY_BUFSIZE*4
# define FHTBUF_SIZE           74      //                 RAM: 174b
# define RCV_BUCKETS            2      //                 RAM: 19b * RCV_BUCKETS
# undef HAS_CC_INTERRUPT_COUNTER             // cc1101 interrupt counter, read with command CC0, usefull for debbugging
# undef HAS_FHT_80b                     // PROGMEM: 1374b, RAM: 90b
# undef HAS_FHT_8v                      // PROGMEM:  586b  RAM: 23b
# undef HAS_FHT_SEND
# undef HAS_FS20_SEND
# undef HAS_RF_ROUTER                   // PROGMEM: 1248b  RAM: 44b
# undef RFR_DEBUG                     // PROGMEM:  354b  RAM: 14b
//# undef HAS_GET_TIMESTAMP
# undef HAS_FULL_RF_ANALYZE
//# undef HAS_NO_WS2000_V1_1_SUPPORT    // undef to enable WS2000 V1.1 protocol support -> but more wrong receptions possible
# undef HAS_RF_RECEIVE_TIMESTAMP
# undef HAS_RF_RECEIVE_FILTER_ADAPTION
# undef HAS_RF_RECEIVE_KEYING
# undef HAS_SLOWRF_RECTO_ACTION
# undef HAS_RSSI_DISPLAY_NONLCD
# undef HAS_RF_RECEIVE_RECORD_LOWMEM
# undef HAS_RF_RECEIVE_RECORD_SYNC          // makes only sense without HAS_RF_RECEIVE_RECORD_OVERIDE_FULL, cause we have only a very shot buffer
# undef HAS_RF_RECEIVE_RECORD_OVERIDE_FULL
# undef HAS_RF_RECEIVE_RECORD_APPEND_TO_DATA
# undef FULL_CC1101_PA                // PROGMEM:  108b
# undef HAS_RAWSEND                   //
# undef HAS_EM_SEND                   //
# undef HAS_KS_SEND                   //
# undef HAS_TX3_SEND                  //
# undef HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
# undef HAS_ASKSIN
//#define ASKSIN_SEND_BUFS       2      // ASKSIN send buffers, 58b RAM each buffer
//# undef HAS_MORITZ
# undef HAS_RWE
# undef HAS_REVOLT   // define to enable REVOLT support
# undef HAS_ESA      // define to enable ESA support
# undef HAS_TX3
# undef HAS_IT       // define to enable IT support
# undef HAS_INTERTECHNO     // define to enable IT send support
# undef HAS_INTERTECHNO_V3
# undef HAS_HOMEEASY
# undef HAS_UNIROLL
# undef HAS_HOERMANN
# undef HAS_SOMFY_RTS
# undef HAS_MBUS
# undef HAS_MEMFN
# undef HAS_MEMORY_TESTMEM              // compiles in mT extension for testing RAM

# undef  BOARD_ID_STR
# define BOARD_ID_STR            "CUL_MX"
# undef  BOARD_ID_USTR
# define BOARD_ID_USTR           L"CUL_MX"
#endif // CUL_V2_MAX



// No features to define below

//************************************************

#include <avr/eeprom.h>
#ifndef eeprom_update_byte
#define eeprom_update_byte eeprom_write_byte
#pragma message "!!! eeprom_update_byte not available !!! Replacing with eeprom_write_byte !"
#endif

#if !defined(USB_SERIAL_NO_USTR) && !defined(USB_SERIAL_NO_USTR433) && !defined(USB_SERIAL_NO_USTR915)
# ifndef LUFA
#  define LUFA                           // define for the Atmel USB serial number
# endif
#endif

#if defined(NO_USB_SERIAL_NO)
# ifndef NO_INTERNAL_SERIAL
#  define NO_INTERNAL_SERIAL
# endif
# ifdef USB_SERIAL_NO_USTR
#  undef USB_SERIAL_NO_USTR
# endif
# ifdef USB_SERIAL_NO_USTR433
#  undef USB_SERIAL_NO_USTR433
# endif
# ifdef USB_SERIAL_NO_USTR915
#  undef USB_SERIAL_NO_USTR915
# endif
#endif

#if !defined(USB_SERIAL_NO_USTR) && (defined(USB_SERIAL_NO_USTR433) || defined(USB_SERIAL_NO_USTR915))       // also defineable in makefile
# define USB_SERIAL_NO_USTR      L"868000"  // 6 chars serial number for 868MHz device, change it to customize, undef if feature is not wanted
#endif

#ifdef USB_SERIAL_NO_USTR
# ifndef NO_INTERNAL_SERIAL
#  define NO_INTERNAL_SERIAL  // we need to disable LUFA internal serial no, as we have our own
# endif
#endif
#ifdef USB_SERIAL_NO_USTR433
# ifndef NO_INTERNAL_SERIAL
#  define NO_INTERNAL_SERIAL  // we need to disable LUFA internal serial no, as we have our own
# endif
#endif
#ifdef USB_SERIAL_NO_USTR915
# ifndef NO_INTERNAL_SERIAL
#  define NO_INTERNAL_SERIAL  // we need to disable LUFA internal serial no, as we have our own
# endif
#endif

// common Flash savings
#if !defined(HAS_RF_ROUTER)
# ifdef RFR_SHADOW
#  undef RFR_SHADOW
# endif
# ifdef RFR_DEBUG
#  undef RFR_DEBUG
# endif
#endif

#if !defined(HAS_FHT_80b) && !defined(HAS_FHT_8v)
# ifdef FHTBUF_SIZE
#  undef FHTBUF_SIZE
# endif
# define FHTBUF_SIZE            0
#endif

#ifdef HAS_MBUS  // we get in Flash memory limitations...
# undef HAS_RF_RECEIVE_RECORD
# undef HAS_RF_RECEIVE_RECORD_LOWMEM
# undef HAS_RF_RECEIVE_RECORD_SYNC          // makes only sense without HAS_RF_RECEIVE_RECORD_OVERIDE_FULL, cause we have only a very shot buffer
# undef HAS_RF_RECEIVE_RECORD_OVERIDE_FULL
# undef HAS_RF_RECEIVE_RECORD_APPEND_TO_DATA
#endif

// common Flash savings for CUL_V2 types
#if defined(CUL_V2) || defined(CUL_V2_HM) || defined(CUL_V2_MAX)

#  undef  HAS_WATCHDOG_TEST
#  define HAS_SAVE_FLASH_MEM                    // save flash space by using slower but smaller functions and excluding some extra functions
#  undef  HAS_SPI_SEND_INLINE                   // SPI single byte send is inlined
#  define HAS_USE_EEPROM_ERB_EWB_EUB            // saves some bytes Flash
#  define USE_TTYDATA_LINEAR_FN_DECODE
#  undef  HAS_GET_TIMESTAMP
#  undef  HAS_CC_INTERRUPT_COUNTER
#  define CDCLUFA_LOWPROGMEM
#  define HAS_RF_RECEIVE_NOINLINE           // saves Flash memory, but increases interrupt time for SlowRf

#  undef  HAS_CC1101_RX_PLL_LOCK_CHECK_TASK_WAIT
#  undef  HAS_CC1101_RX_PLL_LOCK_CHECK_TASK_WAIT_SIMPLE
#  undef  HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX
#  undef  HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX_FUNC
#  undef  HAS_CC1101_FORCE_CAL_MANUAL
#  undef  HAS_CC1101_PLL_LOCK_CHECK_MSG
#  undef  HAS_CC1101_PLL_LOCK_CHECK_MSG_RXTX
#  undef  HAS_CC1101_PLL_LOCK_CHECK_MSG_SW
#  undef  HAS_CC1101_PLL_LOCK_CHECK_MSG_CALSTATE

#  undef  HAS_FULL_RF_ANALYZE
#  undef  HAS_RF_RECEIVE_TIMESTAMP
#  undef  HAS_RF_RECEIVE_FILTER_ADAPTION
#  undef  HAS_RF_RECEIVE_KEYING
#  undef  HAS_SLOWRF_RECTO_ACTION

//#  undef  HAS_CC1101_TO_STATE
//#  undef  HAS_CC1101_RX
#endif

#include <avr/io.h>
#include <avr/power.h>

#if !defined(clock_prescale_set) && __AVR_LIBC_VERSION__  < 10701UL
#  warning "avr/power.h needs patching for prescaler functions to work."
#  warning "for the m32u4 add __AVR_ATmega32U4__ for cpu types on prescale block"
#  warning "for the m32u2 add __AVR_ATmega32U2__ for cpu types on prescale block"
#endif

#if defined(CUL_V3)
#define CALCTIME_TIMER_TCNTn       TCNT3L
#define CALCTIME_TIMER_TCCRnA      TCCR3A
#define CALCTIME_TIMER_TCCRnB      TCCR3B
#define CALCTIME_TIMER_TCCRnB_CFG  _BV(CS31)
#endif  // CUL_V3

#if defined(CUL_V3)      // not sure why libc is missing those ...
#  define PB0 PORTB0
#  define PB1 PORTB1
#  define PB2 PORTB2
#  define PB3 PORTB3
#  define PB6 PORTB6
#  define PD2 PORTD2
#  define PD3 PORTD3

#  ifndef PRADC
#   define PRADC    0
#  endif

#  ifndef PRTWI
#   define PRTWI    7
#  endif

#  ifndef PRUSART1
#   define PRUSART1 0
#  endif

#  ifndef PRTIM3
#   define PRTIM3   3
#  endif

#  ifndef PRTIM4
#   define PRTIM4   4
#  endif
#endif  // CUL_V3

#define SPI_PORT PORTB
#define SPI_DDR DDRB
#define SPI_PIN PINB
#define SPI_SS PB0
#define SPI_MISO PB3
#define SPI_MOSI PB2
#define SPI_SCLK PB1

#define SPI_CC1101_READ_SPECIAL_PORT  PORTB
#define SPI_CC1101_READ_SPECIAL_DDR   DDRB
#define SPI_CC1101_READ_SPECIAL_PIN   PB4   // we missuse this unused pin as fast signaling bit for special cc1101_read_buf

#if defined(CUL_V4)
#  define CC1101_CS_DDR         SPI_DDR
#  define CC1101_CS_PORT        SPI_PORT
#  define CC1101_CS_PIN         SPI_SS
#  define CC1101_MISO_PORTIN    SPI_PIN
#  define CC1101_MISO_PIN       SPI_MISO
#  define CC1101_OUT_DDR        DDRD
#  define CC1101_OUT_PORT       PORTD
#  define CC1101_OUT_PIN        PD3
#  define CC1101_OUT_IN         PIND
#  define CC1101_IN_DDR         DDRD
#  define CC1101_IN_PORT        PORTD
#  define CC1101_IN_PIN         PD2
#  define CC1101_IN_IN          PIND
#  define CC1101_INT            INT2
#  define CC1101_INTVECT        INT2_vect
#  define CC1101_ISC0           ISC20
#  define CC1101_ISC1           ISC21
#  define CC1101_EICR           EICRA
#  define LED_DDR               DDRC
#  define LED_PORT              PORTC
#  define LED_PIN               PC5
#endif

#if defined(CUL_V3)
#  define CC1101_CS_DDR         SPI_DDR
#  define CC1101_CS_PORT        SPI_PORT
#  define CC1101_CS_PIN         SPI_SS
#  define CC1101_MISO_PORTIN    SPI_PIN
#  define CC1101_MISO_PIN       SPI_MISO
#  define CC1101_OUT_DDR        DDRD
#  define CC1101_OUT_PORT       PORTD
#  define CC1101_OUT_PIN        PD3
#  define CC1101_OUT_IN         PIND
#  define CC1101_IN_DDR         DDRD
#  define CC1101_IN_PORT        PORTD
#  define CC1101_IN_PIN         PD2
#  define CC1101_IN_IN          PIND
#  define CC1101_INT            INT2
#  define CC1101_INTVECT        INT2_vect
#  define CC1101_ISC0           ISC20
#  define CC1101_ISC1           ISC21
#  define CC1101_EICR           EICRA
#  define LED_DDR               DDRE
#  define LED_PORT              PORTE
#  define LED_PIN               6
#endif

#if defined(CUL_V2)
#  define CC1101_CS_DDR         DDRC
#  define CC1101_CS_PORT        PORTC
#  define CC1101_CS_PIN         PC5
#  define CC1101_MISO_PORTIN    SPI_PIN
#  define CC1101_MISO_PIN       SPI_MISO
#  define CC1101_IN_DDR         DDRC
#  define CC1101_IN_PORT        PORTC
#  define CC1101_IN_PIN         PC7
#  define CC1101_IN_IN          PINC
#  define CC1101_OUT_DDR        DDRC
#  define CC1101_OUT_PORT       PORTC
#  define CC1101_OUT_PIN        PC6
#  define CC1101_OUT_IN         PINC
#  define CC1101_INT            INT4
#  define CC1101_INTVECT        INT4_vect
#  define CC1101_ISC0           ISC40
#  define CC1101_ISC1           ISC41
#  define CC1101_EICR           EICRB
#  define LED_DDR               DDRC
#  define LED_PORT              PORTC
#  define LED_PIN               PC4
#endif

#define MARK433_PORT            PORTB
#define MARK433_PIN             PINB
#define MARK433_BIT             PB6

#define MARK915_PORT            PORTB
#define MARK915_PIN             PINB
#define MARK915_BIT             PB5

#endif // __BOARD_H__


Evtl. kann man hier was optimieren?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 21 Januar 2017, 08:43:50
Hi,

ich hatte das gleiche Problem bei 12 Rauchmeldern. Habe es mit
autoReadReg 0_off
gelöst.

Interessant, es ist auch bei mir so, dass nach dem 2. Peeren die AES Keys übertragen wurden.

Frage noch an die Experten, können die SD (also die Alten) auch mit AES kommunizieren? Ich habe es hier nicht hinbekommen, einen Key zu übertragen.

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 21 Januar 2017, 09:36:24
nicht nach dem zweiten peeren, sondern nach dem zweiten pairen ....
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 21 Januar 2017, 10:12:40
Bei mir nach dem peeren.
Komisch.

Greets

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 21 Januar 2017, 11:33:43
Beide Vorgänge (pairen und peeren) lösen Datenübertragung aus. Wahrscheinlich hätte getConfig auch gereicht.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 21 Januar 2017, 12:17:08
Nein, getConfig reicht bei mir nicht.

Was anderes:
Wenn ich einen RM mit Zigarettenqualm teste, schreine alle los. Aber nach dreimla Schreine sind alle wieder ruhig. Ist das normal. Weil, evtl der Qualm auch weg ist?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 21 Januar 2017, 12:17:49
Nein, getConfig reicht bei mir nicht.

Was anderes:
Wenn ich einen RM mit Zigarettenqualm teste, schreien alle los. Aber nach dreimal Schreien sind alle wieder ruhig. Ist das normal. Weil, evtl der Qualm auch weg ist?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Bytechanger am 21 Januar 2017, 12:33:03
Kann ich bestätigen. Habe gefühlte 100 mal getConfig ohne Erfolg durchgeführt. AssignHM brachte missing ack.
Durch peeren geht's jetzt.

Greetz

Byte
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 24 Januar 2017, 18:10:51
Laut Bedienungsanleitung deutet das auf eine verschmutzte Rauchkammer hin und der BW-Melder soll nicht weiter benutzt werden...

http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD-2_UM_eQ-3_GE_web.pdf (http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD-2_UM_eQ-3_GE_web.pdf)

Alles klar, hatte nur die deutsche Anleitung durchsucht ... keine Ahnung woher ich die hatte.
Der Melder ist erst ein 3/4 Jahr in Betrieb, das finde ich in einem normalen Zimmer (Arbeitszimmer, nur PC's zum arbeiten) recht früh.
Wenn jemand anderes auch so ein Problem hat bitte mal melden, damit wir ggf. eine Fehlfunktion feststellen können.

Habe den Melder nun abgenommen, ein paar mal fest reingepustet und dann ein clear all gemacht.
Danach mit einem getConfig war der Wert dann wieder auf:
smokeChamber ok

Bin mal gespannt, was da noch kommt.


Grüße

Christian
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: nccfast am 26 Januar 2017, 18:26:31
Als meine RM laufen im Moment so gut, dass ich mir gleich noch drei gekauft habe und nun mein Haus voll ausgestattet ist.
Zusammenfassend kann ich sagen:
nanoCUL(2 kB RAM) + FW 1.66 läuft so gut wie nicht.
nanoCUL(2 kB RAM) + FW TSCUL läuft  nicht.
Evtl. müsste man hier die Board.h anpassen.
Busware(2,5 kB RAM) CUL und FW TSCUL laufen sehr gut.
Wahrscheinlich liegts am RAM.



Zum vorgehen (bei mir ist es so):
1. Erst Pairen
2. set assignHMkey
3. Wieder Pairen
4. set assignHMkey

Und noch was:
attr RM_00_Buero autoReadReg 4_reqStatus ist Standard beim autocreate. Dies kann aber bei einem fhem Neustart und mehreren RM bald zu einem overload kommen. attr RM_00_Buero autoReadReg off wird hier mancherposts empfohlen

Erst dann wird der aesKeyNbr (bei mir 02) übernommen.

Der Rest wie im Wiki
Danke an alle, die mich unterstüzt haben

:-) :-)

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 27 Januar 2017, 14:05:16
Bin mal gespannt, was da noch kommt.

Gestern Abend war es dann schon wieder so weit:
smokeChamber degraded

Der sitzt bei mir im Arbeitszimmer, keine besondere Belastung, einfach ein PC Arbeitsplatz und das war es.
Ist das dann ein Garantiefall oder was mache ich da am besten?


Grüße
Christian
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 27 Januar 2017, 14:14:39
Hallo Christian,

nur als Idee, die Spinne will in ihr Haus zurück?

Wenn das nicht ist, dann würde ich reklamieren.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 27 Januar 2017, 18:50:51
1) Um den hmkey zu übertragen, muss ich aber zweimal hintereinander pairen. Sonst geht es nicht. Seltsam.... ist aber wirklich so. Hab x Versuche gemacht, bis sich herauskristallisierte, dass ich zweimal pairen muss, bis das reading aeskeynbr den key annahm.
Das AesKeyNbr Reading wird erst nach einer erfolgreichen Challenge/Response aktualisiert, auch wenn der Key schon erfolgreich übertragen wurde. Eine Aktion die das auslösen kann ist z.B. das Peering mit dem Team oder ein Register zu ändern.

Gruß Marcel
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: RomanticBoy83 am 03 Februar 2017, 21:59:54
Hallo an alle:
ich verzweifel am Einrichten der Rauchmelder. Ich habe mir einen HMsecSD2 genommen und diesen an einer vccu als virtuelenLeader binden wollen.
Ausgangssituation:
1) vccu hat die originale HmId des HMusbCFG2
2) [vcco_Btn1 == vccu_ack] der vccu ist bereits in Benutzung
3) [vccu_Btn2 == Rauchmelder_Team] der vccu soll als virtuellerLederdienen
Bereits durchgeführt:
1) das pairing scheint erfolgreich von statten gegangen zu sein - nach dem zweiten Versuch
2) ein [set Rauchmelder_Team peerChan 0 wz_rauchmelder single set actor] ausgeführt
3) der Leader kann sowohl teamCall, alarmOn als auch alarmOff ausführen und der Rauchmelder reagiert
4) Rauchmelder_Team zeigt nun das REading [peerList == wz_rauchmelder,]
5) wz_rauchmelder zeigt aber das Reading [peerList == vccu_ack,]

Frage:
der Leader steht noch immer auf state=??? und reagiert nicht. Die Vermutung liegt nahe, dass es an dem falschen Reading im wz_rauchmelder liegt. Da sollte eigentlich der Leader mit dem Namen Rauchmelder_Team angezeigt werden.

Es scheint alles zu funktionieren bis auf die Anzeige im Leader - Ich bekomme es aber einfach nicht hin. Was ist denn an [set Rauchmelder_Team peerChan 0 wz_rauchmelder single set actor] falsch?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 03 Februar 2017, 22:07:19
Hi,

ich weiß nicht warum Du was anderes machen musstest als in der Anleitung (Wiki) steht. Ich bin auch nicht sicher ob es wirklich das Problem ist aber:
Ein virtueller Button der VCCU hat als Channel eine 8 stellige ID
Ein virtueller Aktor (wie im Wiki beschrieben) hat eine 6 stellige ID.

Warum machst Du nicht so wie in der Anleitung und erfindest etwas eigenes?

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: RomanticBoy83 am 03 Februar 2017, 22:18:29
...
Ein virtueller Button der VCCU hat als Channel eine 8 stellige ID
Ein virtueller Aktor (wie im Wiki beschrieben) hat eine 6 stellige ID.
Warum machst Du nicht so wie in der Anleitung und erfindest etwas eigenes?
Dem kann ich nicht ganz folgen - von welchen Id's reden wir denn hier - ich habe lediglich die Namen geändert mit [rename vccu_Btn2 Rauchmelder_Team].
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 03 Februar 2017, 22:38:37
Die ID steht beim HM Device im DEF.

Und wir reden davon
Zitat
virtueller TeamLead
Nutzt man nur einen einzelnen SD, kann/sollte man diesen mit sich selbst teamen (peerChan). In allen andere Fällen braucht man einen TeamLead um eine team-ID zu erhalten. Man kann hierzu einen der SDs nutzen. Wird dieser einmal ausgewechselt, hat man allerdings seine team-ID verloren.
Wenn man mit Zentrale (FHEM) arbeitet, gibt es eigentlich keinen vernünftigen Grund (ausser 1-SD-Teams), einen der SDs als lead zu nutzen. Man kann genauso gut einen virtuellen Aktor bauen und diesen zum Lead machen. Das ergibt eine sauberere Struktur.
Erzeugen eines virtuellen TeamLeads könnte so aussehen:
define TeamDev CUL_HM 111111
set TeamDev virtual 1
rename TeamDev_Btn1 Rauchmelder_Team
Bitte beachten: die HMID muss für die gesamte Installation einmalig sein.

Wie gesagt ich weiß nicht ob daher das Problem rührt. Aber ich wäre an Deiner Stelle nach Wiki  vorgegangen.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: RomanticBoy83 am 03 Februar 2017, 22:52:32
Ok - jetzt verstehe ich den Ansatz.
Der Denkfehler ist aber zu meinem Bedauern doch bei dir. Natürlich habe ich ja das WiKi befolgt und war jetzt doch verdutst - noch einmal alles gelöscht und paste-copy aus dem WiKi gemacht.
Aber mit dem paste-copy habe ich nichteinmal mehr den teamCall, oder auch den Alarm ausrufen können.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 03 Februar 2017, 23:00:09
Ok - jetzt verstehe ich den Ansatz.
Der Denkfehler ist aber zu meinem Bedauern doch bei dir. Natürlich habe ich ja das WiKi befolgt und war jetzt doch verdutst - noch einmal alles gelöscht und paste-copy aus dem WiKi gemacht.
  • TeamDev CUL_HM 111111 - hat eine 6stellige Id wie bei mir auch(vom HMusbCFG2)
  • TeamDev virtual 1 - erhält demnach die achtstellige 11111101 - wie auch bei mir nur eben die 02
Aber mit dem paste-copy habe ich nicht einmal mehr den teamCall, oder auch den Alarm ausrufen können.
Ja, ok da hast Du recht. Ich habe nur irgendwann mal gelernt, dass der Button einer VCCU anders ist als ein virtueller Aktor.
Du hast auch das befolgt?
Zitat
Der HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, er benötigt dafür zwingend das Modul libcrypt-rijndael-perl unabhängig vom IO Device, auch für den HM-CFG-LAN!

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: RomanticBoy83 am 03 Februar 2017, 23:33:09
jo - habe ich auch installiert - immerhin geht ja die Kommunikation über AEs (TeamCall,AlarmOn und AlarmOff).
Es liegt an Fhem und dem peering - ich bekomme immer die xxxxxx01 als peerId gesetzt trotzdem ich den Befehl von jemanden ganz anderes aufrufe. Ich möchte den xxxxxx02 haben!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 03 Februar 2017, 23:45:43
Könnte ne Macke sein. Muss aber eigentlich gehen.
Mach es doch nochmal mit dem einzelnen virtuellen Aktor, das peering musst Du vorher auflösen/entfernen.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 04 Februar 2017, 21:47:40
Es liegt an Fhem und dem peering - ich bekomme immer die xxxxxx01 als peerId gesetzt trotzdem ich den Befehl von jemanden ganz anderes aufrufe. Ich möchte den xxxxxx02 haben!
Du kannst nicht einen x-beliebigen Kanal als Leader verwenden. Ein "virtueller Leader" ist ein reines FHEM Konzept, das gibt's normal nicht. Was auch heisst dass der virtuelle Leader für die Peers aussehen muss wie ein echter Rauchmelder. Und echte Melder haben nur einen Kanal, nämlich die Nummer 1.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 04 Februar 2017, 22:22:35
Du kannst nicht einen x-beliebigen Kanal als Leader verwenden. Ein "virtueller Leader" ist ein reines FHEM Konzept, das gibt's normal nicht. Was auch heisst dass der virtuelle Leader für die Peers aussehen muss wie ein echter Rauchmelder. Und echte Melder haben nur einen Kanal, nämlich die Nummer 1.
Klingt überzeugend. Ich verstehe auch nicht, warum man was anderes versuchen muss als im Konzept.  :o
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: steffen83 am 11 Februar 2017, 21:56:48
Hallo,

für Diejenigen, welche noch Probleme mit dem SD2 haben ich habe hier eine gute Anleitung gefunden womit es super läuft.

Der Schlüssel muss natürlich auch noch gemacht werden. Das fehlt da drin.
Zitat
attr VCCU hmKey geheimerSchluessel

https://forum.fhem.de/index.php/topic,9934.msg121442.html#msg121442 (https://forum.fhem.de/index.php/topic,9934.msg121442.html#msg121442)

Sofern ihr Hilfe braucht könnt ihr euch gerne melden.
Gruß
Steffen

ps: Hatte jetzt noch mal das Problem, dass das "TeamDev" das IODev verloren hat. Dies muss natürlich auf die Hardware verlinkt sein.
Zitat WIKI:
Nach der Definition bitte unbedingt überprüfen, dass TeamDev das Attribut (attr) IODev bzw. IOgrp gesetzt hat (das sollte normalerweise automatisch passieren)! Am Besten die Konfiguration mit HMinfo configCheck prüfen, die ordnungsgemäße Funktion des TeamDev ist wichtig für den Erfolg des folgenden Peerings der Rauchmelder.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 11 Februar 2017, 22:01:48
Du findest die Anleitung im Wiki ist anders?
https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder#virtueller_TeamLead

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: friesenjung am 11 Februar 2017, 22:44:17
Du kannst nicht einen x-beliebigen Kanal als Leader verwenden. Ein "virtueller Leader" ist ein reines FHEM Konzept, das gibt's normal nicht. Was auch heisst dass der virtuelle Leader für die Peers aussehen muss wie ein echter Rauchmelder. Und echte Melder haben nur einen Kanal, nämlich die Nummer 1.

Hi,
ich hab meine ersten 3 SD2 erfolgreich angelernt. Soweit scheint alles zu funktionieren. Übrigens mit einem nanoCUL (V 1.66 nanoCUL868)!

Nun noch eine Frage: Deine obige Erklärung klingt logisch. Bedeutet das also, dass ich bei mehreren Teams je Team einen virtuellen Teamlead (z.B. define TeamDev CUL_HM 111111) mit eben GENAU EINEN Channel (z.B. TeamDev_Btn1) haben DARF?
bzw. anders ausgedrückt: Ich kann meine verschiedenen (zukünftigen) Teams nicht über mehrere Channels (z.B. TeamDev_Btn2) des selben Teamleads verwalten?

Danke schonmal für Eure Mühe
VG...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MarcelK am 12 Februar 2017, 08:54:48
Nun noch eine Frage: Deine obige Erklärung klingt logisch. Bedeutet das also, dass ich bei mehreren Teams je Team einen virtuellen Teamlead (z.B. define TeamDev CUL_HM 111111) mit eben GENAU EINEN Channel (z.B. TeamDev_Btn1) haben DARF?
bzw. anders ausgedrückt: Ich kann meine verschiedenen (zukünftigen) Teams nicht über mehrere Channels (z.B. TeamDev_Btn2) des selben Teamleads verwalten?
Ohne den Quellcode der Firmware kann man das natürlich nie mit 100%iger Sicherheit sagen. Aber rein vom Prinzip her ist es so wie ich geschrieben habe, TeamLeads im HM System machen nichts weiter als ihre HM-Adresse den anderen als gemeinsame Team-Adresse zur Verfügung zu stellen. FHEM und die virtuelle Leads entkoppeln das von einem physikalischen Leader und nehmen eine beliebig gewählte Adresse dafür, aber anonsten ist das Prinzip gleich. Die Kanal-Info wird vermutlich von den Meldern komplett ignoriert.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Gunther am 06 April 2017, 21:17:14
Ich habe immer noch extreme Probleme mit meinen (bisher) 5 Rauchmeldern.

Ich hatte jetzt einige Tage 2, die sauber eingebunden waren. Die anderen 3 mit unreachable.
Nun habe ich eben einen versucht mit einem virtuellen Kanal zu Pairen. Dieser Rauchmelder ist jetzt auf IOerr gegangen.
Der andere ebenfalls auf unreachable.

Ich brauche da Eure Hilfe.  :-\
Was kann ich tun? Welche Infos braucht Ihr, um mir zu helfen?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 07 April 2017, 09:39:56
Hi Gunther,

Wenn die SD unreachable sind, welchen Sinn macht es dann zu versuchen sie mit einem virtuellen Kanal zu PEEREN?

Basis ist: Sie müssen alle sauber in FHEM eingebunden und gepairt sein. Sonst machen weitere Aktionen keine Sinn.

Mit hmInfo configCheck kannst Du prüfen ob alles in Ordnung ist.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Gunther am 07 April 2017, 23:49:28
Hallo Otto,

das Peeren habe ich mit den bis dato funktionierenden RM versucht. Danach sind die in die beschriebenen Fehlzustände gegangen.

Ich habe vermutlich aufgrund der RM ständig Disconnects / Overloads an meinen beiden HMLAN (laufen über VCCU). Außerdem ist mein FHEM sehr langsam: z. B. Öffnen von Devices über die Oberfläche dauert extrem lange.
Wie kann ich die RM aus FHEM rausnehmen um zu prüfen, ob die Fehler dadurch verursacht werden?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 07 April 2017, 23:55:00
Hallo Gunther,

aber dann stimmt etwas anderes nicht. Dann musst Du suchen warum dein FHEM nicht reagiert, vermutlich hast Du irgendwelche Endlosschleifen laufen die das System belasten.
Mit apptime würde ich als erstes suchen -> https://fhem.de/commandref.html#apptime

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Gernott am 08 April 2017, 23:01:55
Hallo an alle Geplagten
Habe seit heute zwei von den Bosch-SD2 und bin beim pairing leicht verzweifelt. Die Dinger sind echt zickig. Mit dem hmusb neben meinem Schreibtisch ging gar nichts. Der SD2 hat einfach vor sich hin geblinkt. Variation des Abstandes bis zu einigen Metern hat auch nicht geholfen. Habe dann die Teile in den Keller zum hmlan getragen und dort ging es sofort. So etwas hatte ich bisher mit keinem Homematic-Gerät.
Die weitere Kommunikation war dann unauffällig. - Vielleicht hilft es ja jemandem.

Gruß
G.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Gunther am 09 April 2017, 12:12:22
Hallo Gunther,

aber dann stimmt etwas anderes nicht. Dann musst Du suchen warum dein FHEM nicht reagiert, vermutlich hast Du irgendwelche Endlosschleifen laufen die das System belasten.
Mit apptime würde ich als erstes suchen -> https://fhem.de/commandref.html#apptime

Gruß Otto

FHEM läuft wieder schnell. Trotzdem habe ich diese Disconnects. Schiebe die ja immer noch auf die HM-SEC-SD-2.
Um den Thread hier nicht aufzublähen mit Dingen, die ggf. nicht hierher führen, habe ich das Thema ausgelagert:
https://forum.fhem.de/index.php/topic,70314.0.html (https://forum.fhem.de/index.php/topic,70314.0.html)

Freue mich da natürlich auch über Hilfe.  ;)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 09 April 2017, 13:04:01
Hallo an alle Geplagten
Habe seit heute zwei von den Bosch-SD2 und bin beim pairing leicht verzweifelt. Die Dinger sind echt zickig. Mit dem hmusb neben meinem Schreibtisch ging gar nichts. Der SD2 hat einfach vor sich hin geblinkt. Variation des Abstandes bis zu einigen Metern hat auch nicht geholfen. Habe dann die Teile in den Keller zum hmlan getragen und dort ging es sofort. So etwas hatte ich bisher mit keinem Homematic-Gerät.
Die weitere Kommunikation war dann unauffällig. - Vielleicht hilft es ja jemandem.

Gruß
G.
Hallo Gernott
Was sind denn bitte Bosch-SD2? Ich finde FERION 5000 OW, die nicht kompatibel mit den FERION 3000 OW sind, die wiederum den Homematic-SD aehneln!
Fuer mich deshalb interessant, da ich eventuell einen Draht zu Bosch habe!
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Gernott am 09 April 2017, 13:17:09
Was sind denn bitte Bosch-SD2? Ich finde FERION 5000 OW
Genau diese.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Gernott am 11 April 2017, 21:13:48
Ist das normal, daß configCheck für den virtuellen Teamlead meldet:
PairedTo missing/unknown
    RM.TeamDev
?
RM.TeamDev isd das Device. Im Channel sind die Peers korrekt eingetragen.
Sonst funktioniert soweit alles.

Gruß
G.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 11 April 2017, 21:31:02
Hi,

definitiv nicht "normal" zumindest meldet er das bei mir nicht.
Zeig mal ein list RM.TeamDev

Meiner hat nur vier readings.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Gernott am 11 April 2017, 22:06:26
Zeig mal ein list RM.TeamDev
Gruß Otto

Sieht so aus:
Internals:
   CFGFN
   DEF        111111
   HMLAN1_MSGCNT 46
   HMLAN1_RAWMSG E111111,0000,03D99D8D,FF,FFAC,D9144111111111111101009600000087B22B47
   HMLAN1_RSSI -84
   HMLAN1_TIME 2017-04-09 14:11:10
   IODev      hmusb
   LASTInputDev HMLAN1
   MSGCNT     54
   NAME       RM.TeamDev
   NOTIFYDEV  global
   NR         846
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 RM_Team
   hmusb_MSGCNT 8
   hmusb_RAWMSG E111111,0000,CBFBBB76,FF,FFA8,D880021111111EA24B00
   hmusb_RSSI -88
   hmusb_TIME 2017-04-09 14:03:27
   lastMsg    No:D9 - t:41 s:111111 d:111111 01009600000087B22B47
   protCmdDel 4
   protLastRcv 2017-04-09 14:11:10
   protResnd  12 last_at:2017-04-09 14:03:26
   protResndFail 4 last_at:2017-04-09 14:03:32
   protSnd    60 last_at:2017-04-09 14:11:07
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-84.95 min:-95 max:-80 lst:-84 cnt:46
   rssi_at_hmusb avg:-86.87 min:-88 max:-85 lst:-88 cnt:8
   Readings:
     2017-04-09 14:03:12   CommandAccepted yes
     2017-04-09 14:09:20   RegL_00.
     2017-04-09 14:00:25   battery         ok
     2017-04-09 14:11:07   state           CMDs_done
   Helper:
     HM_CMDNR   217
     alarmNo    00
     cSnd       011EA24B11111100040000000000,011EA24B11111100040000000000
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +111111,00,00,00
       nextSend   1491739870.38796
       rxt        0
       vccu       vccu
       p:
         111111
         00
         00
         00
     Mrssi:
       mNo        D9
       Io:
         HMLAN1     -84
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rssi:
       At_hmlan1:
         avg        -84.9565217391304
         cnt        46
         lst        -84
         max        -80
         min        -95
       At_hmusb:
         avg        -86.875
         cnt        8
         lst        -88
         max        -85
         min        -88
     Shadowreg:
     Tmpl:
Attributes:
   IODev      hmusb
   IOgrp      vccu
   autoReadReg 4_reqStatus
   expert     2_raw
   model      virtual_1
   room       Alarm,CUL_HM
   subType    virtual

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 11 April 2017, 22:27:32
hmm, meiner sieht etwas anders aus. Aber nicht das ich jetzt sagen könnte: da ist was völlig falsch. Vielleicht sieht Martin da was?

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 12 April 2017, 09:40:19
lösch mal die attribute autoreadreg und expert.
dann ein set clear readings.
anschliessend erneut hminfo configcheck. eventuell davor noch ein set hminfo update.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Gernott am 17 April 2017, 13:05:32
lösch mal die attribute autoreadreg und expert.
dann ein set clear readings.
anschliessend erneut hminfo configcheck. eventuell davor noch ein set hminfo update.
Hatte ich gemacht. Danach war die Fehlermeldung noch da. Nach einem Neustart von FHEM war sie dann weg. Danke für die Lösung.

Gruß
G.

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: misave am 02 Mai 2017, 22:13:53
…das einzige was nicht funktioniert ist tatsächlich, einen Alarm über den virtuellen TeamLead auszulösen. Das geht erst nachdem ich einen TeamCall über den TeamLead abgesetzt habe. Anschließend lässt sich ein Alarm auslösen - und auch wieder beenden.

Gruß,
Stephan

Hallo Stephan,

und wie genau löst Du den Alarm dann aus? Ein teamcall funktioniert, danach am virtuellen Teamleader ein alarmON bringt nix, oder meinst Du einen der echten SD-2 per Hand aufheulen lassen?

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Gernott am 14 Mai 2017, 15:04:14
Ich bin's noch mal. - Nachdem es mit den ersten zwei SD2 (Bosch) lief, habe ich einen Weiteren bestellt. Habe vor dem Anlernen die bestehende Konfiguration getestet und feststellen müssen, daß die zwei Melder nicht mehr auf den virtuellen teamLead reagieren (teamCall). Auffälligkeiten gibt es keine, auch hmInfo zeigt keine Probleme an.

Ich hänge mal die Listings an (mit dem dritten RM).
TeamLead:
Internals:
   DEF        11111101
   NAME       RM_Team
   NOTIFYDEV  global
   NR         570
   NTFY_ORDER 50-RM_Team
   STATE      off
   TESTNR     0
   TYPE       CUL_HM
   chanNo     01
   device     RM.TeamDev
   peerList   hm.RM.WoZi,HM_4B94A9,hm.RM.OGStudio,
   sdTeam     sdLead
   Readings:
     2017-05-14 14:38:10   aesCBCCounter   0000AB
     2017-05-14 14:21:25   eventNo         00
     2017-05-14 13:24:15   level           0
     2017-05-14 14:20:09   peerList        hm.RM.WoZi,HM_4B94A9,hm.RM.OGStudio,
     2017-05-14 14:21:25   smoke_detect    none
     2017-05-14 14:21:25   state           off
     2017-05-14 14:21:25   teamCall        from RM.TeamDev:00
     2017-05-14 14:38:11   trigger_cnt     0
   Helper:
     fkt        sdLead2
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Role:
       chn        1
       vrt        1
     Tmpl:
Attributes:
   model      virtual_1
   peerIDs    4B350A01,4B94A901,4B97EB01,
   room       Alarm
   webCmd     press short:press long

Einer der RM:
Internals:
   DEF        4B97EB
   HMLAN1_MSGCNT 2
   HMLAN1_RAWMSG R06D7599D,0001,035A3116,FF,FFB9,F7A6104B97EB1EA24B0601000043
   HMLAN1_RSSI -71
   HMLAN1_TIME 2017-05-14 14:03:18
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     3
   NAME       hm.RM.OGStudio
   NOTIFYDEV  global
   NR         571
   NTFY_ORDER 50-hm.RM.OGStudio
   STATE      off
   TYPE       CUL_HM
   hmusb_MSGCNT 1
   hmusb_RAWMSG E4B97EB,0000,8039A210,FF,FFDB,F7A6104B97EB1EA24B0601000043
   hmusb_RSSI -37
   hmusb_TIME 2017-05-14 14:03:17
   lastMsg    No:F7 - t:10 s:4B97EB d:1EA24B 0601000043
   peerList   RM_Team,
   protLastRcv 2017-05-14 14:03:18
   protSnd    2 last_at:2017-05-14 14:03:17
   protState  CMDs_done
   rssi_HMLAN1 avg:-67 min:-67 max:-67 lst:-67 cnt:1
   rssi_at_HMLAN1 avg:-71 min:-71 max:-71 lst:-71 cnt:2
   rssi_at_hmusb avg:-37 min:-37 max:-37 lst:-37 cnt:1
   Readings:
     2017-05-14 14:02:22   Activity        alive
     2017-04-09 13:59:37   CommandAccepted yes
     2017-04-09 13:43:33   D-firmware      1.0
     2017-04-09 13:43:33   D-serialNr      NBO0083923
     2017-05-14 13:42:31   PairedTo        0x1EA24B
     2017-04-09 13:43:42   R-devRepeatCntMax 0
     2017-04-09 13:43:42   R-pairCentral   0x1EA24B
     2017-05-14 13:42:31   RegL_00.        02:01 0A:1E 0B:A2 0C:4B 16:00 1F:00 00:00
     2017-04-09 13:59:37   aesCommToDev    ok
     2017-04-09 13:59:36   aesKeyNbr       02
     2017-05-14 14:03:17   alarmTest       ok
     2017-05-14 14:03:17   battery         ok
     2017-05-14 14:03:17   level           0
     2017-05-14 14:02:21   peerList        RM_Team,
     2017-05-13 13:57:47   powerOn         2017-05-13 13:57:46
     2017-05-14 14:03:17   recentStateType info
     2017-05-14 13:42:31   sdRepeat        off
     2017-05-14 14:03:17   smokeChamber    ok
     2017-05-14 14:21:25   smoke_detect    none
     2017-05-14 14:21:25   state           off
     2017-05-14 14:21:25   teamCall        from RM.TeamDev:00
   Helper:
     HM_CMDNR   247
     cSnd       ,011EA24B4B97EB010E
     cfgChkResult No regs found for:

hm.RM.OGStudio type:smokeDetector -
list:peer register         :value
   0:      devRepeatCntMax  :0
   0:      pairCentral      :0x1EA24B



     mId        00AA
     rxType     6
     supp_Pair_Rep 0
     Ack:
     Expert:
       def        1
       det        1
       raw        1
       tpl        0
     Io:
       newChn     +4B97EB,00,01,00
       nextSend   1494763398.7392
       rxt        0
       vccu       vccu
       p:
         4B97EB
         00
         01
         00
     Mrssi:
       mNo        F7
       Io:
         HMLAN1     -69
         hmusb      -37
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         hmusb
       flg        A
       ts         1494763397.48228
       ack:
         HASH(0x2cbee68)
         F780021EA24B4B97EB00
     Rssi:
       Hmlan1:
         avg        -67
         cnt        1
         lst        -67
         max        -67
         min        -67
       At_hmlan1:
         avg        -71
         cnt        2
         lst        -71
         max        -71
         min        -71
       At_hmusb:
         avg        -37
         cnt        1
         lst        -37
         max        -37
         min        -37
     Tmpl:
   Nb:
     cnt        3
Attributes:
   IODev      HMLAN1
   IOgrp      vccu
   actCycle   099:00
   actStatus  alive
   autoReadReg 5_readMissing
   devStateIcon off:general_ok *:secur_alarm
   expert     3_allReg+raw
   firmware   1.0
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,11111101,
   room       Alarm,CUL_HM,OberGeschoss
   serialNr   NBO0083923
   subType    smokeDetector
   webCmd     statusRequest

Für mich sieht das nach dem Studium der Seiten hier normal aus. Vielleicht sieht jemand von Euch ein Problem?

Update
Habe mal alle entpeert und den TeamLead gelöscht und neu angelegt. Danach den ersten RM wieder gepeert. Der hat dann auf einen TeamCall reagiert. Ich habe dann den zweiten RM gepeert. Während der erste auf die TeamCalls reagiert, tut der zweite nichts. Beim Vergleich der Readings und der Meldungen gibt es keinen Unterschied zwischen beiden RM. Die Teile verhalten sich kompliziert, gelinde gesagt.

Update 2
Wenn ich den TeamCall an einem der drei RM auslöse, blinken überraschenderweise doch alle drei, d.h. die Vernetzung über den virtuellen TeamLead funktioniert wohl. Das ist zumindest mal für den Brandfall beruhigend.

Gruß
G.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: chunter1 am 05 Juni 2017, 00:28:04
Mich würde interessieren, wie ihr die Daten eurer Rauchmelder darstellt.
ReadingsGroup, readingsProxy, Floorplan...?
Ein Screenshot zur Inspiration wäre super  ;)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: chunter1 am 05 Juni 2017, 20:17:28
Ist es eigentlich möglich über FHEM den Alarm bei einem bestimmten Rauchmelder in einem Team auszulösen?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 05 Juni 2017, 22:38:21
Also ich denke, es ist nur möglich den Alarm im Team aus zu lösen. Das ist ja der Sinn eines Teams, einer merkt es und alle signalisieren.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: chunter1 am 05 Juni 2017, 23:01:51
ok, und ist es möglich bestimmte Rauchmelder im Team stumm zu schalten - also dass diese nicht laut pfeifen sondern nur die restlichen teammitglieder?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 06 Juni 2017, 10:17:27
Ich weiß es nicht, aber der Sinn erschließt sich mir auch nicht. Ich wiederhole mich: Der Sinn eines Teams ist ja gerade, dass alle signalisieren wenn es an einer Ecke brennt. Oder ich verstehe Deine Frage nicht ...  :'(
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: chunter1 am 06 Juni 2017, 10:58:01
Ich habe 3 RM installiert (Bosch Ferion 5000 OW).
Einen in der Küche, einen im Kinderzimmer und einem im Schlafzimmer.
Dabei würde ich eben gerne den RM im Kinderzimmer stumm schalten, sodass bei einem Fehlalarm irgendeines Sensors nie das Baby bis zum Herzinfarkt erschreckt wird ;)
Es soll aber sehr wohl ein Alarm des RM im Kinderzimmer an die anderen Geräte gemeldet werden.

(...und wenn gar nix hilft, muss ich eben den Lautsprecher abklemmen oder zukleben :) )
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 06 Juni 2017, 14:29:52
Mir fällt dabei spontan ein, dass meine damals irgendwie zwischen ein und zweijährige Tochter eingeschlafen ist, während ich ihre Kinderzimmertür mit einem beherzten Kreissägeschnitt in wenigen Metern Entfernung um einen cm kürze musste.
-> Kleinstkinder haben ein anderes Schreckverhalten als wir Erwachsenen uns das vorstellen  ;)

Alle meine (Fehl)Alarme waren bisher selbst produziert, einer pro Jahr ...

Aber vielmehr fällt mir dazu auch nicht ein.  8)

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 06 Juni 2017, 16:36:44
Wir hatten neulich auch einen Fehlalarm von einem defekten RM im Arbeitszimmer. Kinder haben einfach weiter gepennt 1 & 3 Jahre alt.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 26 Juli 2017, 22:28:27
Moin
Ich wollte nur Erfolg melden! Habe jetzt 6 von 8 Bosch RMs, die ich bei digitalo fuer €22,- erstanden habe, in Gang gebracht. Das schwierigste war doch noch mal nach dem Crypt Modul zu gucken, da ich mir sicher war, dass ich das schon installiert hatte. Danach lief dann alles wie am Schnuerchen!
Gruss und Danke Christoph

P.S.: Hat sich das Sponsoring doch gelohnt!  :D
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Motivierte linke Hände am 16 September 2017, 15:37:00
Hi, ich verzeifele hier gerade beim Versuch, einen SD2 in ein Team zu bringen. Vorgegangen bin ich genau nach Wiki.

Problem: Beim Peering geht der Rauchmelder immer in den Status MISSING ACK.

Was habe ich gemacht:

Rauchmelder mit fhem gepaired. Da ist er:

Internals:
   CFGFN
   DEF        5E8403
   HMLAN1_MSGCNT 64
   HMLAN1_RAWMSG E5E8403,0000,0552FB73,FF,FFC0,B0A0105E8403AB12340100000000
   HMLAN1_RSSI -64
   HMLAN1_TIME 2017-09-16 15:11:47
   HMLAN2_MSGCNT 66
   HMLAN2_RAWMSG E5E8403,0000,0A54E421,FF,FFDA,B0A0105E8403AB12340100000000
   HMLAN2_RSSI -38
   HMLAN2_TIME 2017-09-16 15:11:47
   HMLGW1_MSGCNT 56
   HMLGW1_RAWMSG 05010035B0A0105E8403AB12340100000000
   HMLGW1_RSSI -53
   HMLGW1_TIME 2017-09-16 15:11:47
   HMUSB_MSGCNT 64
   HMUSB_RAWMSG E5E8403,0000,0C9C9A53,FF,FFC2,B0A0105E8403AB12340100000000
   HMUSB_RSSI -62
   HMUSB_TIME 2017-09-16 15:11:47
   IODev      HMLGW1
   LASTInputDev HMUSB
   MSGCNT     250
   NAME       Smoke_Flur_EG
   NOTIFYDEV  global
   NR         5305
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:B0 - t:10 s:5E8403 d:AB1234 0100000000
   protCmdDel 3
   protErrIoId_F10000 54 last_at:2017-09-16 15:11:42
   protEvt_AESCom-ok 9 last_at:2017-09-16 15:10:26
   protLastRcv 2017-09-16 15:11:47
   protResnd  4 last_at:2017-09-16 15:11:39
   protResndFail 3 last_at:2017-09-16 15:11:44
   protSnd    57 last_at:2017-09-16 15:11:47
   protState  CMDs_done
   rssi_HMLGW1 avg:-50.33 max:-46 lst:-55 min:-55 cnt:3
   rssi_at_HMLAN1 min:-83 lst:-64 avg:-69.89 max:-58 cnt:46
   rssi_at_HMLAN2 cnt:48 max:-38 avg:-47.27 lst:-38 min:-56
   rssi_at_HMLGW1 min:-64 max:-49 avg:-55.5 lst:-53 cnt:38
   rssi_at_HMUSB cnt:46 min:-81 avg:-68.97 max:-57 lst:-62
   READINGS:
     2017-09-16 15:10:24   Activity        alive
     2017-09-16 15:10:26   CommandAccepted yes
     2017-09-16 15:10:24   D-firmware      1.0
     2017-09-16 15:10:24   D-serialNr      OEQ0957337
     2017-09-16 15:11:47   PairedTo        0xAB1234
     2017-09-16 15:10:28   R-pairCentral   0xAB1234
     2017-09-16 15:11:47   RegL_00.          02:01 0A:CD 0B:20 0C:07 16:00 1F:00 00:00
     2017-09-16 15:10:26   aesCommToDev    ok
     2017-09-16 15:10:26   aesKeyNbr       00
     2017-09-16 15:09:59   alarmTest       ok
     2017-09-16 15:09:59   battery         ok
     2017-09-16 15:09:59   level           0
     2017-09-16 15:09:59   powerOn         2017-09-16 15:09:59
     2017-09-16 15:09:59   recentStateType info
     2017-09-16 15:11:42   sabotageAttackId_ErrIoId_F10000  cnt:54
     2017-09-16 15:11:47   sdRepeat        off
     2017-09-16 15:09:59   smokeChamber    ok
     2017-09-16 14:41:37   smoke_detect    none
     2017-09-16 15:11:44   state           MISSING ACK
     2017-09-16 14:41:37   teamCall        from SmokeTeam:05
   helper:
     HM_CMDNR   176
     cSnd       01AB12345E840300040000000000,01AB12345E84030103
     mId        00AA
     peerIDsRaw ,00000000
     rxType     6
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5E8403,00,02,00
       nextSend   1505567507.92172
       prefIO
       rxt        0
       vccu
       p:
         5E8403
         00
         02
         00
     mRssi:
       mNo        B0
       io:
         HMLAN1     -64
         HMLAN2     -38
         HMLGW1     -51
         HMUSB      -62
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       chn        1
       dev        1
     rpt:
       IO         HMLAN2
       flg        A
       ts         1505567507.8185
       ack:
         HASH(0x80d01e0)
         B08002AB12345E840300
     rssi:
       HMLGW1:
         avg        -50.3333333333333
         cnt        3
         lst        -55
         max        -46
         min        -55
       at_HMLAN1:
         avg        -69.8913043478261
         cnt        46
         lst        -64
         max        -58
         min        -83
       at_HMLAN2:
         avg        -47.2708333333333
         cnt        48
         lst        -38
         max        -38
         min        -56
       at_HMLGW1:
         avg        -55.5
         cnt        38
         lst        -53
         max        -49
         min        -64
       at_HMUSB:
         avg        -68.9782608695652
         cnt        46
         lst        -62
         max        -57
         min        -81
     shadowReg:
     tmpl:
Attributes:
   IODev      HMLGW1
   IOgrp      vccu:HMLGW1
   actCycle   099:00
   actStatus  alive
   autoReadReg 5_readMissing
   devStateIcon off:general_ok .*:secur_smoke_detector@red
   event-on-change-reading .*
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,
   room       Cfg_HM
   serialNr   OEQ0957337
   subType    smokeDetector
   webCmd     statusRequest

Virtueller Teamlead:

Internals:
   CFGFN
   DEF        132132
   IODev      HMLGW1:keepAlive
   NAME       SmokeTeam
   NOTIFYDEV  global
   NR         5265
   STATE      Info_Cleared
   TYPE       CUL_HM
   channel_01 Rauchmelder_Team
   protState  Info_Cleared
   READINGS:
     2017-09-16 14:41:37   battery         ok
     2017-09-16 15:02:54   state           Info_Cleared
   helper:
     HM_CMDNR   99
     alarmNo    05
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +132132,00,00,00
       prefIO
       rxt        0
       vccu
       p:
         132132
         00
         00
         00
     mRssi:
       mNo
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       dev        1
     rssi:
     shadowReg:
     tmpl:
Attributes:
   IODev      HMLGW1:keepAlive
   autoReadReg 4_reqStatus
   expert     2_raw
   model      virtual_1
   room       Cfg_HM
   subType    virtual

Channel 01 des Teamleads:

Internals:
   CFGFN
   DEF        13213201
   NAME       Rauchmelder_Team
   NOTIFYDEV  global
   NR         5267
   STATE      off
   TESTNR     5
   TYPE       CUL_HM
   chanNo     01
   device     SmokeTeam
   peerList   Smoke_Flur_EG,
   sdTeam     sdLead
   READINGS:
     2017-09-16 14:41:34   aesCBCCounter   000063
     2017-09-16 14:41:37   eventNo         05
     2017-09-16 14:40:41   level           0
     2017-09-16 15:11:34   peerList        Smoke_Flur_EG,
     2017-09-16 14:41:37   smoke_detect    none
     2017-09-16 15:11:34   state           off
     2017-09-16 14:41:37   teamCall        from SmokeTeam:05
   helper:
     fkt        sdLead2
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
       vrt        1
     shadowReg:
     tmpl:
Attributes:
   model      virtual_1
   peerIDs    5E840301,
   webCmd     press short:press long

Peering mittels:

set Rauchmelder_Team peerChan 0 Smoke_Flur_EG single set actor
Und dann kommt der MISSING ACK, und hminfo mein beim Config Check, dass das Peering wohl nicht funktioniert habe.

Habe den Rauchmelder inzwischen auch schonmal auf Werkseinstellungen zurückgesetzt und von vorne angefangen. Ich komme wieder genau bis zum MISSING ACK beim Peering-Versuch. Irgendwas muss ich überlesen haben und daher regelmäßig falsch machen.

Ach ja:

#apt install libcrypt-rijndael-perl
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
»libcrypt-rijndael-perl« ist bereits die neuste Version (1.13-1build1).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 6 nicht aktualisiert.

Für hilfreiche Tipps dankbar,
Christian
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Motivierte linke Hände am 16 September 2017, 15:53:54
Hm, ok, Versuch #4 von vorne mit Werksreset hat mich jetzt über das Peering gebracht. Allerdings passiert bei einem set ... teamCall oder auch set ... alarmOn außerhalb von fhem nichts. Der Rauchmelder schweigt eisern.

Internals:
   CFGFN
   DEF        5E8403
   HMLAN1_MSGCNT 17
   HMLAN1_RAWMSG E5E8403,0000,05736E94,FF,FFC3,B5A0105E8403AB1234011321320100000000
   HMLAN1_RSSI -61
   HMLAN1_TIME 2017-09-16 15:47:14
   HMLAN2_MSGCNT 32
   HMLAN2_RAWMSG R8AF176E8,0001,0A755744,FF,FFD2,B5A0105E8403AB1234011321320100000000
   HMLAN2_RSSI -46
   HMLAN2_TIME 2017-09-16 15:47:14
   HMLGW1_MSGCNT 17
   HMLGW1_RAWMSG 0501003CB5A0105E8403AB1234011321320100000000
   HMLGW1_RSSI -60
   HMLGW1_TIME 2017-09-16 15:47:14
   HMUSB_MSGCNT 19
   HMUSB_RAWMSG E5E8403,0000,0CBD0BF0,FF,FFBD,B5A0105E8403AB1234011321320100000000
   HMUSB_RSSI -67
   HMUSB_TIME 2017-09-16 15:47:14
   IODev      HMLAN2
   LASTInputDev HMLAN2
   MSGCNT     85
   NAME       HM_5E8403
   NOTIFYDEV  global
   NR         1103
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:B5 - t:10 s:5E8403 d:AB1234 011321320100000000
   peerList   Rauchmelder_Team,
   protEvt_AESCom-ok 4 last_at:2017-09-16 15:47:09
   protLastRcv 2017-09-16 15:47:14
   protSnd    28 last_at:2017-09-16 15:47:14
   protState  CMDs_done
   rssi_HMLAN2 max:-38 lst:-38 cnt:1 min:-38 avg:-38
   rssi_at_HMLAN1 cnt:17 min:-69 lst:-61 max:-61 avg:-64.11
   rssi_at_HMLAN2 avg:-47.58 min:-50 cnt:24 lst:-46 max:-45
   rssi_at_HMLGW1 min:-60 cnt:17 lst:-60 max:-53 avg:-55.64
   rssi_at_HMUSB lst:-67 max:-67 cnt:19 min:-78 avg:-71.84
   READINGS:
     2017-09-16 15:45:10   Activity        alive
     2017-09-16 15:47:09   CommandAccepted yes
     2017-09-16 15:45:05   D-firmware      1.0
     2017-09-16 15:45:05   D-serialNr      OEQ0957337
     2017-09-16 15:47:13   PairedTo        0xAB1234
     2017-09-16 15:45:07   R-pairCentral   0xAB1234
     2017-09-16 15:47:13   RegL_00.          02:01 0A:CD 0B:20 0C:07 16:00 1F:00 00:00
     2017-09-16 15:47:09   aesCommToDev    ok
     2017-09-16 15:47:09   aesKeyNbr       00
     2017-09-16 15:45:12   alarmTest       ok
     2017-09-16 15:45:12   battery         ok
     2017-09-16 15:45:12   level           0
     2017-09-16 15:47:14   peerList        Rauchmelder_Team,
     2017-09-16 15:45:12   recentStateType info
     2017-09-16 15:47:13   sdRepeat        off
     2017-09-16 15:45:12   smokeChamber    ok
     2017-09-16 15:49:59   smoke_detect    none
     2017-09-16 15:49:59   state           off
     2017-09-16 15:48:01   teamCall        from SmokeTeam:02
   helper:
     HM_CMDNR   181
     cSnd       01AB12345E840300040000000000,01AB12345E84030103
     mId        00AA
     peerIDsRaw ,13213201,00000000
     rxType     6
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5E8403,00,02,00
       nextSend   1505569634.29637
       prefIO
       rxt        0
       vccu
       p:
         5E8403
         00
         02
         00
     mRssi:
       mNo        B5
       io:
         HMLAN1     -61
         HMLAN2     -44
         HMLGW1     -60
         HMUSB      -67
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       chn        1
       dev        1
     rpt:
       IO         HMLGW1
       flg        A
       ts         1505569634.07806
       ack:
         HASH(0x83bb7e0)
         B58002AB12345E840300
     rssi:
       HMLAN2:
         avg        -38
         cnt        1
         lst        -38
         max        -38
         min        -38
       at_HMLAN1:
         avg        -64.1176470588235
         cnt        17
         lst        -61
         max        -61
         min        -69
       at_HMLAN2:
         avg        -47.5833333333333
         cnt        24
         lst        -46
         max        -45
         min        -50
       at_HMLGW1:
         avg        -55.6470588235294
         cnt        17
         lst        -60
         max        -53
         min        -60
       at_HMUSB:
         avg        -71.8421052631579
         cnt        19
         lst        -67
         max        -67
         min        -78
     shadowReg:
     tmpl:
Attributes:
   IODev      HMLAN2
   IOgrp      vccu:HMLAN2
   actCycle   099:00
   actStatus  alive
   autoReadReg 5_readMissing
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,13213201,
   room       CUL_HM
   serialNr   OEQ0957337
   subType    smokeDetector
   webCmd     statusRequest
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 16 September 2017, 18:23:57
Hallo Christian
Wenn Du erwartest, dass es beim Teamcall laut wird, dann irrst Du Dich! Es werden lediglich die LEDs zum Blinken gebracht. Habe auch erst gedacht, dass gar nichts geht. Dann auf einmal gesehen, dass die LED blinkt. Ist aber auch gut, dann kann man spielen, ohne dass man welche auf die Muetze bekommt!
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Motivierte linke Hände am 17 September 2017, 11:08:46
Ok, nochmal zum Status Quo:


Wenn Du erwartest, dass es beim Teamcall laut wird, dann irrst Du Dich! Es werden lediglich die LEDs zum Blinken gebracht. Habe auch erst gedacht, dass gar nichts geht. Dann auf einmal gesehen, dass die LED blinkt.

Danke, Christoph. Im Wiki steht was von 10 leisen Piepsern. Allerdings wäre ich auch schon mit einer Reaktion der LEDs zufrieden. Doch hier tut sich nix: teamCall führt nur Änderungen in den Readings bei fhem, aber ansonsten tut sich gar nichts. Keine LEDs leuchten, kein Piepsen, nix. Auch "alarmOn" ändert nur Readings in fhem. Weder der TeamLead noch die anderen Rauchmelder geben irgendwas von sich, und Readings werden auch nur beim TeamLead auf alarm geändert. Die anderen Melder zeigen nicht mal in den Readings eine Reaktion.

fhem ist auf aktuellem Stand, letztes Update gestern.

Grüße, Christian
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Gernott am 17 September 2017, 12:10:06
Doch hier tut sich nix: teamCall führt nur Änderungen in den Readings bei fhem, aber ansonsten tut sich gar nichts.
Dieses Verhalten ist wohl normal, siehe z.B. meine Beobachtungen mit den Bosch-Dingern (bei mir blinkt wenigstens einer von 3 im Team). Da der Teamcall aber zwischen den Meldern funktioniert, wenn ich ihn an einem der SD2 auslöse, gehe ich im Brandfall von einer korrekten Funktion aus.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 17 September 2017, 13:14:07
Moin
Also ich habe gerade einen Teamcall ausgeloest, und alle 8 haben gruen geblinkt! (Bosch)
Ich bin da wirklich nach dem Wiki Beitrag vorgegangen. Virtuellen Teamlead angelegt, RM mit VCCU gepairt, alle CMDs pending weg, und dann mit dem Teamleader gepeert! Bei mir hatte es nur laenger gedauert, da ich das crypt nicht installiert hatte, aber der Meinung war, dass ich das haette!
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Motivierte linke Hände am 17 September 2017, 13:21:26
Hi Christoph,

was passiert bei Dir bei einem "alarmOn"?

Und wie genau schickst Du den TeamCall Befehl weg? Da kann man ja nach "TeamCall" noch Parameter angeben.

Danke, Christian
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 18 September 2017, 07:52:50
Hallo Christian
Bei Teamcall setze ich keine Parameter, das Feld ist glaube ich ein Soda Feld, in diesem Fall.
AlarmOn habe ich noch nicht probiert. Das koennte auch Probleme mit der Regierung und dem 4-Beiner geben. Ausserdem geben die ja beim Probealarm alles, so dass auch gleich die Nachbarn auf dem Plan stehen, bei 8 Stueck. Da waren meine Gira besser, beim Test haben die mit reduzierter Lautstaerke gepiept!
Mal sehen, wenn ich mal sturmfrei habe, dann probiere ich das mal.
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Gunther am 06 November 2017, 16:31:06
Ich habe nochmal eine Frage zum "virtuellen Teamlead" gemäß Wiki.

Dort steht
Zitat
Bitte beachten: die HMID muss für die gesamte Installation einmalig sein.

1. Frage: Heißt das nun, wenn meine HMLANs bzw. meine vccu A12345 hat, dass diese HMID einmalig sein muss oder die HMID speziell für den virtuellen Kanal?

Welche Version ist nun richtig?
A: HMID wie vccu
define TeamDev CUL_HM A12345
set TeamDev virtual 1
rename TeamDev_Btn1 Rauchmelder_Team

B: HMID für Teamlead
define TeamDev CUL_HM 111111
set TeamDev virtual 1
rename TeamDev_Btn1 Rauchmelder_Team

2. Frage:
gilt die Antwort auf Frage 1 auch für die virtuellen Devices zum peeren von Tastern (Anzeige rote/ grüne LED bei Erfolg/Misserfolg des Befehls)? Wenn ja, kann ich mir in diesem Device dann einfach einen 2. Button anlegen und diesen als Teamlead nutzen?

Edit:
3. Frage: Sehe ich die alarmOn und alarmOff erst nachdem ich das Teamlead-Peeren vorgenommen habe? FHEM kennt die Befehle nicht für meine Rauchmelder
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Pfriemler am 06 November 2017, 18:26:55
zu 1. Heißt: eine HMID darf für jedes Gerät nur einmal verwendet werden. Die HMID der vccu (bzw. der Homematic-Interfaces in Gruppe) ist tabu.
In dem Moment, wo Du wie beschrieben einen HM-Dummy TeamDev mit HMID der vccu definierst, beginnt das Chaos in Deiner Installation.

B ist also richtig.

Für das peeren von Tastern zwecks ACK-Erzeugung eignen sich virtuelle Buttuns in einer vccu bestens. Ob sie sich auch als Teamlead eignen, entzieht sich meiner Kenntnis. Der Teamlead meiner Rauchmelder ist der einzige virtuelle Button außerhalb der vccu bei mir.

3. alarmOn und alarmOff sind (wie logischerweise teamCall) nur beim Teamlead verfügbar, nicht bei den Rauchmeldern selbst.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 06 November 2017, 23:19:10
Zu Frage 2: Nein Nein 
;D

Warum wird eigentlich an dem Begriff einmalig gerätselt - das ist irgendwie nicht das erste Mal.
Ist das wirklich missverständlich?  :o

Wenn man einer VCCU eine HMID gibt und einem zweiten Gerät die Gleiche HMID geben will - dann ist diese ID doch nicht mehr einmalig sondern zweimal vorhanden!?

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: TottiToad am 11 November 2017, 21:06:18
Hallo,

"und täglich grüßt das Murmeltier" :) :)

Ich verzweifel so langsam

Bekomme meine Rauchmelder nicht miteinander gepeert !

Ich bin wie in der WIKi alles durchgegangen, habe einen Virtuellen TeamLead angelegt mit neuer HMId.

- Habe als erstes virtuelles TeamDev angelegt
- Dann btn1 als Rauchmelder_Team
- Dann sicherheitshalber SD reset
- SD mit FHEM gepaired
- Nach get-Config und 4sek Knopf drücken hat dann alles geklappt
-Rauchmelder umbenannt
- Jetzt per: set Rauchmelder_Team peerChan 0  RM_Flur single set actor  versucht zu peeren.

Ergebnis:
- Im Rauchmelder_Team wird mir bei peerList in den Iternals und Readings meine SD angezeigt - also RM_Flur
- Beim Rauchmelder wird jedoch erst garkein peerList angezeigt
- Lediglich beim Attribut peerIDs wird mir 000000 angezeigt

Bin alles mehrmals durchgehangen und habe x_Mal von vorne begonnen, anderen Rauchmelder genutzt, mehrere Rauchmelder gepaired, .....
Leider alles ohneErfolg.


HM Info zeigt folgendes:
configCheck done:

 peer not verified. Check that peer is set on both sides
    Rauchmelder_Team p:RM_Flur

 peering strange - likely not suitable
    RM_Flur not peered!! add SD to any team !!

peerXref zeigt folgendes (sollte ja so richtig sein):

peerXref done:
 x-ref list
    HM_4BB9C6_Led => HM_KlingelSender
    HM_4BB9C6_Mp3 => HM_KlingelSender
    HM_5140D8_Btn_01 => HM_Flusicherung VCCU_Btn1
    HM_5140D8_Btn_02 => HM_Flusicherung VCCU_Btn2
    HM_Flusicherung => HM_5140D8_Btn_01 HM_5140D8_Btn_02
    HM_KlingelSender => HM_4BB9C6_Led HM_4BB9C6_Mp3
    Rauchmelder_Team => RM_Flur
    VCCU_Btn1 => HM_5140D8_Btn_01
    VCCU_Btn2 => HM_5140D8_Btn_02

Was mache ich falsch ?
Woran könnte es liegen ?

Ich hoffe ihr könnt mir wie so oft weiter helfen ?!

Grüße & Danke
Totti
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: TottiToad am 11 November 2017, 21:57:34
Hi,

habe gerade nochmals den Befehl durchgeführt.

set Rauchmelder_Team peerChan 0 RM_Flur single set actor

Darauf kommt folgende Fehler Meldung im Log:

2017-11-11 21:53:21 CUL_HM Rauchmelder_Team MISSING ACK
2017.11.11 21:53:21 3 : CUL_HM set Rauchmelder_Team peerChan 0 RM_Flur single set actor2017-11-11 21:53:30 CUL_HM RM_Flur ResndFail
2017-11-11 21:53:30 CUL_HM RM_Flur MISSING ACK
2017.11.11 21:53:33 3 : CUL_HM set RM_Flur getConfig
2017-11-11 21:53:45 CUL_HM RM_Flur ResndFail
2017-11-11 21:53:46 CUL_HM RM_Flur RESPONSE TIMEOUT:RegisterRead

Dann nochmals ein getConfig:
2017.11.11 21:54:04 3 : CUL_HM set RM_Flur getConfig
2017-11-11 21:54:11 CUL_HM RM_Flur sdRepeat: off


Alles sehr werkwürdig wie ich finde ?!

Grüße
Totti
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 12 November 2017, 20:19:03
Hallo Totti,

für den SD-2 brauchst Du libcrypt-rijndael-perl - hast Duinstalliert?

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: TottiToad am 12 November 2017, 20:28:51

für den SD-2 brauchst Du libcrypt-rijndael-perl - hast Duinstalliert?


Hi,

ja ist installiert !

Habe gestern nacht noch ewig probiert und heute auch noch den halben Tag. Leider nix :(

Und natürlich noch mehrmals die Wiki gelesen und die allg. Einführung.

Dabei ist mit in der Wiki des Rauchmelders ein Satz nicht ganz klar:

" Anschließend muss man noch einen Homematic-Kanal für das Peering definieren. "


Was genau ist damit gemeint ?

Und den TeamDev muss ich nicht mit sich selbst peeren, oder ?

Ich habe wie gesagt, den Rauchmelder mit VCCU gepairt und dann versucht mittels:

set Rauchmelder_Team peerChan 0 RM_Flur single set actor

versucht zu peeren.

Dies gelingt jedoch nur einseitig.


Überlege schon alles von HM nochmals runter zu schmeißen und neu zu machen. Kann es sein das beim VCCU was nicht richtig läuft ?



EDIT: Sehe gerade, sobald ich den peerChan Befehl sende, kommt beim Rauchmelder state RESPONSE TIMEOUT:RegisterRead

Erst nach getconfig kommt dann MissinACK
nach dem nächsten getconfig dann alles wieder gut ... nur halt nicht gepeert.

2017.11.12 20:31:35 3 : CUL_HM set Rauchmelder_Team peerChan 0 RM_Flur single set actor2017-11-12 20:31:45 CUL_HM RM_Flur ResndFail
2017-11-12 20:31:45 CUL_HM RM_Flur MISSING ACK
2017.11.12 20:31:47 3 : CUL_HM set RM_Flur getConfig
2017-11-12 20:31:59 CUL_HM RM_Flur ResndFail
2017-11-12 20:31:59 CUL_HM RM_Flur RESPONSE TIMEOUT:RegisterRead
2017.11.12 20:32:00 3 : Device RM_Flur added to ActionDetector with 099:00 time
2017.11.12 20:32:13 3 : CUL_HM set RM_Flur getConfig

Grüße
Totti
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 12 November 2017, 20:45:35
mach uns doch mal ein list von dem SD2
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: TottiToad am 12 November 2017, 20:47:30
Hier das Ergebnis von List RM_Flur

nternals:
   DEF        4C3B0D
   HMLAN_MSGCNT 23
   HMLAN_RAWMSG 0403003005A0104C3B0D4731510100000000
   HMLAN_RSSI -48
   HMLAN_TIME 2017-11-12 20:40:28
   IODev      HMLAN
   LASTInputDev HMLAN
   MSGCNT     23
   NAME       RM_Flur
   NOTIFYDEV  global
   NR         129
   NTFY_ORDER 50-RM_Flur
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:05 - t:10 s:4C3B0D d:473151 0100000000
   protCmdDel 8
   protLastRcv 2017-11-12 20:40:28
   protResnd  8 last_at:2017-11-12 20:38:14
   protResndFail 6 last_at:2017-11-12 20:38:18
   protSnd    34 last_at:2017-11-12 20:40:28
   protState  CMDs_done
   rssi_HMLAN min:-33 cnt:1 lst:-33 max:-33 avg:-33
   rssi_at_HMLAN avg:-48.43 max:-38 cnt:23 lst:-48 min:-56
   Helper:
     DBLOG:
       alarmTest:
         DBLogging:
           TIME       1510446540.4319
           VALUE      ok
       battery:
         DBLogging:
           TIME       1510446540.4319
           VALUE      ok
       level:
         DBLogging:
           TIME       1510446540.4319
           VALUE      0
       smokeChamber:
         DBLogging:
           TIME       1510446540.4319
           VALUE      ok
       state:
         DBLogging:
           TIME       1510515498.90916
           VALUE      MISSING ACK
   READINGS:
     2017-11-12 20:40:25   Activity        alive
     2017-11-12 20:40:25   D-firmware      1.0
     2017-11-12 20:40:25   D-serialNr      NBO0078885
     2017-11-12 20:40:27   PairedTo        0x473151
     2017-11-12 01:02:17   R-pairCentral   0x473151
     2017-11-12 20:40:27   RegL_00.          02:01 0A:47 0B:31 0C:51 16:00 1F:00 00:00
     2017-11-12 07:31:42   alarmTest       ok
     2017-11-12 07:31:42   battery         ok
     2017-11-12 07:31:42   level           0
     2017-11-12 07:31:42   recentStateType info
     2017-11-12 20:40:27   sdRepeat        off
     2017-11-12 07:31:42   smokeChamber    ok
     2017-11-12 20:38:18   state           MISSING ACK
   helper:
     HM_CMDNR   5
     cSnd       014731514C3B0D00040000000000,014731514C3B0D0103
     mId        00AA
     peerIDsRaw ,00000000
     rxType     6
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +4C3B0D,00,00,00
       nextSend   1510515628.50785
       rxt        0
       vccu       VCCU
       p:
         4C3B0D
         00
         00
         00
     mRssi:
       mNo        05
       io:
         HMLAN      -46
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       chn        1
       dev        1
     rpt:
       IO         HMLAN
       flg        A
       ts         1510515628.21693
       ack:
         HASH(0x562fbb374488)
         0580024731514C3B0D00
     rssi:
       HMLAN:
         avg        -33
         cnt        1
         lst        -33
         max        -33
         min        -33
       at_HMLAN:
         avg        -48.4347826086956
         cnt        23
         lst        -48
         max        -38
         min        -56
     shadowReg:
     tmpl:
Attributes:
   IODev      HMLAN
   IOgrp      VCCU
   actCycle   099:00
   actStatus  alive
   autoReadReg 5_readMissing
   event-on-change-reading .*
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,
   room       CUL_HM,HM
   serialNr   NBO0078885
   subType    smokeDetector
   verbose    5
   webCmd     statusRequest
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 12 November 2017, 20:58:13
das pairing sollte mal gut sein...
mach mal noch ein list von Rauchmelder_Team


Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: TottiToad am 12 November 2017, 21:05:18
List Rauchmelder_Team:

Internals:
   DEF        11111101
   NAME       Rauchmelder_Team
   NOTIFYDEV  global
   NR         132
   NTFY_ORDER 50-Rauchmelder_Team
   STATE      MISSING ACK
   TESTNR     1
   TYPE       CUL_HM
   chanNo     01
   device     TeamDev
   peerList   RM_Flur,
   sdTeam     sdLead
   Helper:
     DBLOG:
       state:
         DBLogging:
           TIME       1510516964.39289
           VALUE      MISSING ACK
   READINGS:
     2017-11-12 21:02:44   peerList        RM_Flur,
     2017-11-12 21:02:44   state           MISSING ACK
   helper:
     fkt        sdLead2
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
       vrt        1
     shadowReg:
     tmpl:
Attributes:
   model      virtual_1
   peerIDs    4C3B0D01,
   room       HM
   verbose    5
   webCmd     press short:press long

List direkt nachdem ich peerChan gesetzt habe, daher auch bei State wohl das Missing ACK

und hier noch direkt List TeamDev:

Internals:
   DEF        111111
   IODev      HMLAN
   NAME       TeamDev
   NOTIFYDEV  global
   NR         131
   NTFY_ORDER 50-TeamDev
   STATE      Info_Cleared
   TYPE       CUL_HM
   channel_01 Rauchmelder_Team
   protState  Info_Cleared
   Helper:
     DBLOG:
       state:
         DBLogging:
           TIME       1510515568.47725
           VALUE      Info_Cleared
   READINGS:
     2017-11-12 20:39:28   state           Info_Cleared
   helper:
     HM_CMDNR   172
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO
       vccu
     mRssi:
       mNo
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       dev        1
       vrt        1
     rssi:
     shadowReg:
     tmpl:
Attributes:
   IODev      HMLAN
   expert     2_raw
   model      virtual_1
   room       HM
   subType    virtual
   verbose    5
   webCmd     virtual

Danke & Grüße
Totti
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 13 November 2017, 07:20:19
Ich hab die Anleitung zum pairen und peeren nochmal aus einem alten Post hoch geholt.
Die list's von den Devices sehen soweit gut aus. Solltest du einen eigenen HmKey nutzen, hast du diesen wohl noch nicht übertragen.


Also zum richtigen Vorgehen:

- SD2 mit FHEM pairen
- dem SD2 den aktuelle AES-Key zuweisen mit:
set <SD2> assignHmKey
- einen virtuellenTeamLead für die SD2 erstellen (wie im FHEM-WiKi zu HM-SEC-SD beschrieben)(einen VirtuellenTeamLead für den alten SD und den neuen SD2 gemeinsam verwenden funktioniert nicht)
- den VirtuellenTeamLead mit dem SD2 peeren, mit:
set <virtTeamLead> peerChan 0 <SD2> single set actor

das wars.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 13 November 2017, 08:15:25
Guten Morgen,

mal eine kurze Zwischenfrage:

Gibt es eine Möglichkeit, nur das Orientierungslicht am RM ein zu schalten?

LG
  Marlen
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 14 November 2017, 19:13:32
Hallo Marlen

Damit Du dich nicht wieder beschwerst, dass Deine Beitraege ignoriert werden. Soweit ich gesehen habe, geht da nichts! Was war denn Dein Ansinnen, nachts als Orientierungslicht? Dann ist aber schnell die fest eingebaute 10-jahres-Batterie leer. Und dann musst Du die austauschen.
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 15 November 2017, 22:37:06
Hi,
nein ich dachte, man könnte das Licht bei Stromausfall nutzen.

LG
 Marlen
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 16 November 2017, 07:20:38
Hm
Ok, ich hatte jetzt keinen richtigen Stromausfall mehr, seit gefuehlt 10 Jahren! Ok manchmal muss man die Uhr der Mikrowelle stellen, und das NAS hat Eintraege der USV, aber das ich Licht braeuchte, nee. Zudem muesstest du ja wissen, wann der Strom ausfaellt, damit Du vorher einschalten koenntest, oder ist Dein fhem an einer USV?
Gruss Christoph
P.S.: Immer noch nicht zu vergessen, dass die Lebensdauer beeintraechtigt wird!
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 16 November 2017, 21:24:19
Ja, FHEM is an einer USV.
Ja, natürlich is nicht oft Stromausfall, aber wenn dann wäre es halt schön bzw. smart.
Wäre ja nur ein notify!
Lebensdauern.... naja, ersten's ist ja nicht oft Stromausfall und 2. schätze ich, dass ich da schon einen neuen 9V Block rein bekomme.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Pfriemler am 16 November 2017, 21:39:47
Wir reden vom SD-2? Da ist nix mit 9-V-Block. Auch die ohne -2 haben keinen 9-V-Block, sondern 3 AA-Batterien.

Zitat Artikelbeschreibung:
Zitat
Wartungsarm durch fest eingebaute Lithium-Batterie (3 V), Batterielebensdauer ca. 10 Jahre
Viel Spaß beim Löten!  ;D
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 16 November 2017, 21:54:31
Naja, 3 AA is doch auch nicht schlim!
Aber 1. kann man ja das Licht nicht separat schalten und wenn dann is ja auch net sooft Stromausfall ( Nacht's wenn man daheim ist)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Pfriemler am 16 November 2017, 22:19:17
Die 3 AA am alten Rauchmelder kann man ganz oldfashioned wechseln, dafür haben die ein Batteriefach. Die SD-2 haben die fest verlötete Lithium. Gibt es auch zu kaufen sicher, aber einlöten muss man sie dann auch können.
Aber trotzdestonichts: die Lampen gehen nicht extra zu schalten. Hätte mich bei meinen alten auch gefreut. Die neuen kommen mir nicht ins Haus ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Marlen am 16 November 2017, 22:22:20
Warum?
Was hast denn gegen die neuen?
Welche hast du dann?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Pfriemler am 16 November 2017, 22:32:37
Na HM-SEC-SD, sechs Stück und vier in Reserve vom Magenta Ausverkauf im September. Laufen astrein, wenn man sie gelegentlich rekalibriert, melden rechtzeitig leere Batterien und sind in weniger als 30 Sekunden wieder einsatzbereit. 3 Batteriesätze für 2 Euro beim schwedischen Möbelhaus und aus. Können "bespielt" werden (teamCall etc), Amok laufen, Bursts etc. - ich wette, die meisten der Geräte werden bei regelmäßiger Bespielung durch eine Zentrale wie FHEM nach fünf Jahren alle sein. Langzeiterfahrungen haben wir ja noch nicht. Und dann wegschmeißen, wie vom Hersteller vorgesehen? Nicht mein Ding. Was noch geht, wird wieder gangbar gemacht. Wie der 19 Jahre alte Trockner - neuer Riemen für 15 Euro, rennt wieder.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: elmer am 10 Dezember 2017, 11:21:28
Bei meinen Meldern ist heute der Alarm angegangen, wo kann man sehen von welchem Melder dieser ausgegangen ist?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: CoolTux am 10 Dezember 2017, 11:34:57
Auf Basis Deiner exakten Beschreibung würde ich mal ins Log schauen.
Hättest Du erwähnt das Du ein Team hast würde ich jedoch sagen schau beim Teamleader ins Reading.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: elmer am 10 Dezember 2017, 12:36:19
Im Log habe ich zuerst nachgesehen, aber da war nichts zu sehen.

Im Team Leader gibt es nur einen Eintrag der von der Zeit passt: trigger_cnt 2

Sagt dieser Eintrag etwas aus, welcher Melder es war?
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: CoolTux am 10 Dezember 2017, 12:46:01
Zeig doch mal ein list vom Teamleader. Bei mir steht sowas wie

recentAlarm als Reading. Habe aber auch keine Lust hier zu raten was du genau hast.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: elmer am 10 Dezember 2017, 15:18:01
Internals:
   CUL_0_MSGCNT 1
   CUL_0_RAWMSG A0E01A6104937FA7319730601000023::-60:CUL_0
   CUL_0_RSSI -60
   CUL_0_TIME 2017-12-10 12:42:20
   DEF        4937FA
   IODev      meinLGW
   LASTInputDev meinLGW
   MSGCNT     2
   NAME       HM_4937FA
   NOTIFYDEV  global
   NR         288
   NTFY_ORDER 50-HM_4937FA
   STATE      off
   TESTNR     1
   TYPE       CUL_HM
   lastMsg    No:01 - t:10 s:4937FA d:731973 0601000023
   meinLGW_MSGCNT 1
   meinLGW_RAWMSG 0501002701A6104937FA7319730601000023
   meinLGW_RSSI -39
   meinLGW_TIME 2017-12-10 12:42:20
   peerList   self01,
   protCmdDel 1
   protLastRcv 2017-12-10 12:42:20
   protResnd  1 last_at:2017-12-10 12:42:13
   protResndFail 1 last_at:2017-12-10 12:42:19
   protSnd    2 last_at:2017-12-10 12:42:20
   protState  CMDs_done
   rssi_at_CUL_0 min:-60 lst:-60 max:-60 avg:-60 cnt:1
   rssi_at_meinLGW lst:-39 min:-39 avg:-39 cnt:1 max:-39
   rssi_meinLGW lst:-35 min:-35 max:-35 cnt:1 avg:-35
   sdTeam     sdLead
   READINGS:
     2017-06-29 18:35:04   .D-devInfo      000100
     2017-06-29 18:35:04   .D-stc          CE
     2017-06-29 18:35:14   .R-devRepeatCntMax 0
     2017-10-21 16:35:53   .peerListRDate  2017-10-21 16:35:53
     2017-12-10 12:42:20   .protLastRcv    2017-12-10 12:42:20
     2017-12-10 12:40:58   Activity        alive
     2017-06-30 17:38:20   CommandAccepted yes
     2017-06-29 18:35:04   D-firmware      1.0
     2017-06-29 18:35:04   D-serialNr      NBO0016402
     2017-10-21 16:35:53   PairedTo        0x731973
     2017-06-29 18:35:14   R-pairCentral   0x731973
     2017-10-21 16:35:53   RegL_00.        02:01 0A:73 0B:19 0C:73 16:00 1F:00 00:00
     2017-07-01 14:22:18   aesCBCCounter   0000FC
     2017-06-30 17:38:20   aesCommToDev    ok
     2017-06-30 17:38:20   aesKeyNbr       02
     2017-12-10 12:42:20   alarmTest       ok
     2017-12-10 12:42:20   battery         ok
     2017-12-10 12:42:20   eventNo         01
     2017-12-10 12:42:20   level           0
     2017-12-10 12:40:58   peerList        self01,
     2017-10-24 23:50:25   powerOn         2017-10-24 23:50:25
     2017-12-10 12:42:20   recentStateType info
     2017-10-21 16:35:53   sdRepeat        off
     2017-12-10 12:42:20   smokeChamber    ok
     2017-12-10 12:42:20   smoke_detect    none
     2017-12-10 12:42:20   state           off
     2017-07-01 11:11:12   teamCall        from VCCU:05
     2017-12-10 10:36:06   trigger_cnt     2
   helper:
     HM_CMDNR   1
     cSnd       ,017319734937FA010E
     fkt        sdLead2
     mId        00AA
     rxType     6
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +4937FA,00,01,00
       nextSend   1512906141.24551
       rxt        0
       vccu       VCCU
       p:
         4937FA
         00
         01
         00
       prefIO:
         meinLGW
     mRssi:
       mNo        01
       io:
         CUL_0      -60
         meinLGW    -37
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         CUL_0
       flg        A
       ts         1512906140.92009
       ack:
         HASH(0x40108e8)
         0180027319734937FA00
     rssi:
       at_CUL_0:
         avg        -60
         cnt        1
         lst        -60
         max        -60
         min        -60
       at_meinLGW:
         avg        -39
         cnt        1
         lst        -39
         max        -39
         min        -39
       meinLGW:
         avg        -35
         cnt        1
         lst        -35
         max        -35
         min        -35
     tmpl:
Attributes:
   IODev      meinLGW
   IOgrp      VCCU:meinLGW
   actCycle   099:00
   actStatus  alive
   alias      Rauchmelder Flur
   autoReadReg 4_reqStatus
   devStateIcon .*off:secur_smoke_detector@green .*on:secur_smoke_detector@red
   event-on-change-reading .*
   expert     2_raw
   firmware   1.0
   fp_Wohnung 211,1328,1,Flur,
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,4937FA01,
   room       System Geräte
   serialNr   NBO0016402
   subType    smokeDetector
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: CoolTux am 10 Dezember 2017, 15:26:50
Ich sehe da nur einen Rauchmelder der mit sich selbst gepeert ist und somit Teamleader. Mitglieder im Team sehe ich keine weiteren.

Deine Frage kann ich leider nicht beantworten.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: elmer am 10 Dezember 2017, 23:55:11
Hab ich mir schon gedacht das ich das damals beim einrichten nicht richtig gemacht habe, bei allen anderen Rauchmeldern steht bei peer list der HM_4937FA drin.

Nur beim eigentlichen TeamLeader steht self1, keine Ahnung wieso, im Erdgeschoss wurde einmal durch starke Rauchentwicklung beim Kochen Alarm ausgelöst und der TeamLeader ist im ersten Stock.

Obwohl im TeamLeader self1 steht kam sofort per Pushover die Meldung das die Feuermelder Alarm ausgelöst haben.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 11 Dezember 2017, 09:47:34
Moin,

für erfolgreiches peering muss in beiden Geräten der jeweils andere als Peer drin stehen.
hmInfo configCheck hilft relativ einfach solche Fehler aufzuspüren.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: elmer am 11 Dezember 2017, 11:30:23
Ok, bei config Check bekomme ich nichts angezeigt, wenn ich aber peerXref mache bekomme ich folgendes angezeigt.

peerXref done:
 x-ref list
    HM_4711B0 => HM_4937FA
    HM_4937FA => self01
    HM_4937FD => HM_4937FA
    HM_493885 => HM_4937FA
   
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 11 Dezember 2017, 19:25:08
Und so sollte das bei Rauchmeldern richtig aussehen.
Meine Umgebung:
    Rauchmelder_Team => RmAZ RmFlur RmSZ
    RmAZ => Rauchmelder_Team
    RmFlur => Rauchmelder_Team
    RmSZ => Rauchmelder_Team

Dein list bedeutet: Kein Fehler ( hatte configCheck gemeldet)
xref:
Du hast einfach nur einseitig gepeert.  Du hast  nur den Team mit sich gepeert, die anderen zwar mit dem Team aber den Team nicht mit den anderen.

Gruß Otto

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Christian Uhlmann am 11 Dezember 2017, 20:05:52
Ich glaube es ist noch anders. Wieviele RM hast du? 3 oder 4? Was ist HM_4937FA für ein Gerät, ist das ein RM oder ein virtueller Teamlead? Wenn es ein RM ist, dann ist da in FHEM nicht viel mit Steuerung, außer halt die Events die du mitbekommst.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 11 Dezember 2017, 20:14:07
Es ist ein Rauchmelder als Teamleader. Ein virtueller hätte eine 8 stellige HMID.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 11 Dezember 2017, 21:33:41
Das ist einfach nur das ganz normale aneinander anlernen ohne FHEM. So steht es in der Bedienungsanleitung.

Zitat
6.1.1
Funk-Rauchwarnmelder aneinander anlernen
Die ersten beiden Rauchwarnmelder im System definieren eine Gruppenadresse.
Jeder weitere Rauchwarnmelder kann an einen beliebigen
bereits im System befindlichen Rauchwarnmelder angelernt werden und
erhält automatisch die vorab definierte Gruppenadresse.

Das Auswerten eines Alarms sollte ja kein Problem sein, nur steuern (alarm_off oder ähnlich) geht nicht.

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 16 Dezember 2017, 18:04:20
... kleiner Zwischenwurf / Bericht:

Der Erste der drei RM ist inzwischen gestorben... Der meldet zwar noch Rauch (testet meine Frau gelegentlich bei Ofen anmachen ^^), ansonsten aber ist der aus Sicht von FHEM tot...
Von jetzt auf gleich steht das Ding auf MISSING ACK und ist nicht mehr zur Zusammenarbeit zu bewegen, auch nicht durch Ausschalten, eine Nacht liegen lassen und Einschalten, auch nicht durch neues Anlernen und andere Sachen, die man so versucht...

Manchmal kommt er zurück direkt nach dem Einschalten, aber bereits ein getConfig scheitert mit MISSING ACK oder RESPONSE TIMEOUT:RegisterRead. Sieht dann z.B. wie u.s. aus...

Jemand eine Idee, ob man den noch retten kann oder Tonne?!?

Internals:
   .triggerUsed 1
   CFGFN      /opt/fhem/_HW/HM.sensoren.cfg
   DEF        48F213
   IODev      SCC2
   LASTInputDev SCC2
   MSGCNT     18
   NAME       HM1RM2
   NOTIFYDEV  global
   NR         65
   NTFY_ORDER 50-HM1RM2
   SCC2_MSGCNT 11
   SCC2_RAWMSG A1301144148F21348F2130101960000061F6B73F9::-64.5:SCC2
   SCC2_RSSI  -64.5
   SCC2_TIME  2017-12-16 18:00:38
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   UFO1_MSGCNT 7
   UFO1_RAWMSG E48F213,0000,001CF638,FF,FF98,01144148F21348F2130101960000061F6B73F9
   UFO1_RSSI  -104
   UFO1_TIME  2017-12-16 18:00:38
   lastMsg    No:01 - t:41 s:48F213 d:48F213 0101960000061F6B73F9
   peerList   Team_RM,
   protCmdDel 5
   protLastRcv 2017-12-16 18:00:38
   protResnd  6 last_at:2017-12-16 18:00:34
   protResndFail 3 last_at:2017-12-16 18:00:40
   protSnd    3 last_at:2017-12-16 18:00:24
   protState  CMDs_done_Errors:1
   rssi_at_SCC2 min:-68.5 max:-53.5 cnt:8 lst:-64.5 avg:-62.62
   rssi_at_UFO1 cnt:5 lst:-104 avg:-99 min:-104 max:-96
   READINGS:
     2017-12-16 18:00:33   .D-devInfo      000100
     2017-12-16 18:00:33   .D-stc          CE
     2017-12-16 18:00:38   .protLastRcv    2017-12-16 18:00:38
     2017-12-16 18:00:33   Activity        alive
     2017-12-16 18:00:33   D-firmware      1.0
     2017-12-16 18:00:33   D-serialNr      NEQ0244324
     2017-12-16 17:55:28   alarmTest       ok
     2017-12-16 17:55:28   battery         ok
     2017-12-16 17:55:28   level           0
     2017-12-16 17:55:28   powerOn         2017-12-16 17:55:28
     2017-12-16 17:55:28   recentStateType info
     2017-12-16 17:55:28   smokeChamber    ok
     2017-12-16 18:00:40   state           RESPONSE TIMEOUT:RegisterRead
     2017-12-16 18:00:35   trigger_cnt     1
     RegL_00.:
       VAL       
   helper:
     HM_CMDNR   1
     PONtest    1
     cSnd       01F1000048F213010E,01F1000048F21300040000000000
     getCfgListNo
     mId        00AA
     rxType     6
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +48F213,00,00,00
       nextSend   1513443638.98199
       rxt        0
       vccu       VCCU
       p:
         48F213
         00
         00
         00
     mRssi:
       mNo        01
       io:
         SCC2       -62.5
         UFO1       -104
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_SCC2:
         avg        -62.625
         cnt        8
         lst        -64.5
         max        -53.5
         min        -68.5
       at_UFO1:
         avg        -99
         cnt        5
         lst        -104
         max        -96
         min        -104
     tmpl:
Attributes:
   IODev      UFO1
   IOgrp      VCCU
   actCycle   099:00
   actStatus  alive
   alias      Rauchmelder
   autoReadReg 4_reqStatus
   devStateIcon off:secur_smoke_detector@gray on:secur_smoke_detector@red smoke-Alarm.*:secur_smoke_detector@red
   expert     2_raw
   firmware   1.0
   group      _90 HW - HM.RM
   model      HM-SEC-SD-2
   msgRepeat  2
   peerIDs    00000000,00001101,
   room       311 - Wohnzimmer,313 - Esszimmer
   serialNr   NEQ0244324
   subType    smokeDetector
   webCmd     :
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 17 Dezember 2017, 11:16:31
Moin Micha
Wieso Tonne, der ist doch noch gar nicht so alt. Und eq3 kann ruhig mal bluten!
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 17 Dezember 2017, 11:17:36
Hi Micha,

das Verhalten, was Du beschreibst ist eigentlich zu erwarten. Der ist nicht tot, der ist nur nicht gepairt.
Also pairen und er sollte auf Deine Befehle reagieren.  ;)

Beim Einschalten werden einige Readings aktualisiert, das ist typisches Verhalten.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 17 Dezember 2017, 13:29:58
@Christoph:
Ne, eine Rückgabe geht nicht. Die sind modifiziert (Schalter-MOD) und somit raus aus der Garantie. Zudem bin ich seit einiger Zeit kein Kunde mehr bei ELV/eQ3 und will mit dem Laden auch nichts mehr zu tun haben; die haben mich ein mal zu oft verar***t...

@Otto:
Doch, die waren und sind gepairt. Gestern Nacht noch alle mehrfach auf Werkszustand gesetzt, neu gepairt und einem Leader zugewiesen. Das hat auch nach unzähligen Versuchen nur teilweise geklappt. Z.B. war es nicht möglich, alle RM dem Leader zuzuweisen, oder aber auch ein "getConfig" scheitert mit den genannten Problemen... Mal der eine, mal der andere, mal mehrere... Dann mal wieder "ohhh, alle sauber gepairt!" und dann funktionieren die Zuweisungen an den Leadre nicht oder nur teilweise... Und das kann keinesfalls ein Reichweitenproblemen sein, denn umzu -50dbi ist ein einwandfreier Wert...

Also egal wie man das sieht... Ich für meine Teil habe die in die Gruppe des üblichen eQ3- Murkses eingeordnet und werde mich im neuen Jahr nach einer Alternative umschauen. Die sind mir einfach viel zu unzuverlässig... und gerade auf sicherheitstechnische Einrichtungen sollte man sich verlassen können...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 17 Dezember 2017, 13:37:15
Zitat
Und das kann keinesfalls ein Reichweitenproblemen sein, denn umzu -50dbi ist ein einwandfreier Wert...
Zitat
   rssi_at_UFO1 cnt:5 lst:-104 avg:-99 min:-104 max:-96
Zitat
   IODev      UFO1
   IOgrp      VCCU
:o ??? :-X

Was soll ich dazu sagen?
Und der SD-2 in deinem List ist definitiv nicht gepairt.
Und ein SCC ist kein guter HM IO

Aber ich bin nicht Schuld  :-*
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 17 Dezember 2017, 13:41:43
... na, stützt Dich nicht nur auf das List von gestern... Das war nur ein SnapShot. Nach dem ich die hier alle auf dem Tisch hatte, waren die umzu -50db; kein Wunder... der entsprechende SCC ist mal gearde 4m entfernt... UFO1 hängt im Keller und zum Zeitpunkt des List hatte derjenige noch immer versucht, im Keller anzurufen... Also reiner Zufall...

Und ein SCC ist kein guter HM IOWie man es nimmt... Alle anderen HM- Geräte (und davon habe ich nicht wenige) laufen damit vollkommen problemlos ... Dsa UFO hat mehr Probleme als der SCC ...
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 17 Dezember 2017, 13:50:02
... na, stützt Dich nicht nur auf das List von gestern...
Das ist doch aber das einzige was ich sehen kann :) ohne VPN Glaskugel Tunnel zu Dir.  ;D

Ich meine Du hattest zwar Bericht drüber geschrieben - aber am Ende eine Frage gestellt.  ;)
Wenn Du keine Antwort erwartest und nur deinen Frust über die Technik ablassen willst musst Du das genauer kennzeichnen. Wir können doch hier alle nix dafür  ;D und wollen nur helfen.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 17 Dezember 2017, 14:19:15
... ja ok, hast Du natürlich Recht ... Das passiert mir immer, wenn ich eine Frage stelle und nach dem Stellen weitermache, um vielleicht doch noch auf die Lösung zu kommen. Dann ist in meiner GRütze schon was ganz anderes vorhanden, als hier noch ist...
Ok, dann bügel ich Dich und Andere mal auf den neusten Stand...

Ähem... Wie ich gerade beim Kopieren der Listings sehe, scheint sich das Peering mit dem Leader heute Nacht alleine geregelt zu haben?!? Wie geht denn so was? Im Moment (und für den Moment vermutlich) scheint wieder alles so zu sein, wie es vorher war und wie es sein soll... (wo ist der FHEM Exorzist ?)

HM1RM1 (Wohnzimmer):
Internals:
   CFGFN      /opt/fhem/_HW/HM.sensoren.cfg
   DEF        48F213
   IODev      SCC3
   LASTInputDev UFO1
   MSGCNT     3
   NAME       HM1RM1
   NOTIFYDEV  global
   NR         69
   SCC3_MSGCNT 1
   SCC3_RAWMSG A0E8AA61048F213F100000601000054::-48.5:SCC3
   SCC3_RSSI  -48.5
   SCC3_TIME  2017-12-17 13:43:54
   STATE      off
   TYPE       CUL_HM
   UFO1_MSGCNT 2
   UFO1_RAWMSG R64808687,0001,011E2542,FF,FFA2,8AA61048F213F100000601000054
   UFO1_RSSI  -94
   UFO1_TIME  2017-12-17 13:43:54
   lastMsg    No:8A - t:10 s:48F213 d:F10000 0601000054
   peerList   HM1RM_Team,
   protLastRcv 2017-12-17 13:43:54
   protResnd  2 last_at:2017-12-17 13:43:52
   protSnd    2 last_at:2017-12-17 13:43:54
   protState  CMDs_done
   rssi_UFO1  max:-84 min:-84 avg:-84 cnt:1 lst:-84
   rssi_at_SCC3 min:-48.5 max:-48.5 cnt:1 lst:-48.5 avg:-48.5
   rssi_at_UFO1 max:-94 min:-94 avg:-94 cnt:2 lst:-94
   READINGS:
     2017-12-16 20:06:26   .D-devInfo      000100
     2017-12-16 20:06:26   .D-stc          CE
     2017-12-16 19:48:57   .R-devRepeatCntMax 0
     2017-12-16 20:26:20   .peerListRDate  2017-12-16 20:26:20
     2017-12-17 13:43:54   .protLastRcv    2017-12-17 13:43:54
     2017-12-17 13:43:37   Activity        alive
     2017-12-16 20:14:44   CommandAccepted yes
     2017-12-16 20:06:26   D-firmware      1.0
     2017-12-16 20:06:26   D-serialNr      NEQ0244324
     2017-12-16 20:26:20   PairedTo        0xF10000
     2017-12-16 20:09:30   R-pairCentral   0xF10000
     2017-12-16 20:26:20   RegL_00.        02:01 0A:F1 0B:00 0C:00 16:00 1F:00 00:00
     2017-12-16 20:14:44   aesCommToDev    ok
     2017-12-16 20:14:44   aesKeyNbr       00
     2017-12-17 13:43:54   alarmTest       ok
     2017-12-17 13:43:54   battery         ok
     2017-12-17 13:43:54   level           0
     2017-12-17 13:43:37   peerList        HM1RM_Team,
     2017-12-16 20:16:12   powerOn         2017-12-16 20:16:12
     2017-12-17 13:43:54   recentStateType info
     2017-12-16 20:26:20   sdRepeat        off
     2017-12-17 13:43:54   smokeChamber    ok
     2017-12-16 20:21:00   smoke_detect    none
     2017-12-17 13:43:54   state           off
     2017-12-16 20:19:40   teamCall        from HM1RM_DEV:02
   helper:
     HM_CMDNR   138
     cSnd       ,01F1000048F213010E
     mId        00AA
     rxType     6
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +48F213,00,00,00
       nextSend   1513514634.42545
       rxt        0
       vccu       VCCU
       p:
         48F213
         00
         00
         00
       prefIO:
         SCC3:UFO1
     mRssi:
       mNo        8A
       io:
         SCC3       -48.5
         UFO1       -94
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         UFO1
       flg        A
       ts         1513514634.21082
       ack:
         HASH(0x887b298)
         8A8002F1000048F21300
     rssi:
       UFO1:
         avg        -84
         cnt        1
         lst        -84
         max        -84
         min        -84
       at_SCC3:
         avg        -48.5
         cnt        1
         lst        -48.5
         max        -48.5
         min        -48.5
       at_UFO1:
         avg        -94
         cnt        2
         lst        -94
         max        -94
         min        -94
     tmpl:
Attributes:
   IODev      UFO1
   IOgrp      VCCU:SCC3:UFO1
   actCycle   099:00
   actStatus  alive
   alias      Rauchmelder WZ
   autoReadReg 4_reqStatus
   devStateIcon off:secur_smoke_detector@gray on:secur_smoke_detector@red smoke-Alarm.*:secur_smoke_detector@red
   expert     2_raw
   firmware   1.0
   group      _90 HW - HM.RM
   model      HM-SEC-SD-2
   msgRepeat  2
   peerIDs    00000000,00110101,
   room       311 - Wohnzimmer,313 - Esszimmer
   serialNr   NEQ0244324
   subType    smokeDetector
   webCmd     :

HM1RM2 (Schlaftrakt):
Internals:
   CFGFN      /opt/fhem/_HW/HM.sensoren.cfg
   DEF        48F15F
   IODev      SCC3
   LASTInputDev SCC3
   MSGCNT     4
   NAME       HM1RM2
   NOTIFYDEV  global
   NR         72
   SCC3_MSGCNT 2
   SCC3_RAWMSG A126AA01048F15FF10000010011010100000000::-57.5:SCC3
   SCC3_RSSI  -57.5
   SCC3_TIME  2017-12-17 13:43:33
   STATE      off
   TYPE       CUL_HM
   UFO1_MSGCNT 2
   UFO1_RAWMSG E48F15F,0000,011DD5F6,FF,FFC6,6AA01048F15FF10000010011010100000000
   UFO1_RSSI  -58
   UFO1_TIME  2017-12-17 13:43:33
   lastMsg    No:6A - t:10 s:48F15F d:F10000 010011010100000000
   peerList   HM1RM_Team,
   protLastRcv 2017-12-17 13:43:33
   protSnd    4 last_at:2017-12-17 13:43:33
   protState  CMDs_done
   rssi_at_SCC3 avg:-57.5 lst:-57.5 cnt:2 max:-57.5 min:-57.5
   rssi_at_UFO1 max:-58 min:-58 avg:-58 lst:-58 cnt:2
   READINGS:
     2017-12-16 20:06:12   .D-devInfo      000100
     2017-12-16 20:06:12   .D-stc          CE
     2017-12-16 19:44:42   .R-devRepeatCntMax 0
     2017-12-17 13:43:33   .peerListRDate  2017-12-17 13:43:33
     2017-12-17 13:43:33   .protLastRcv    2017-12-17 13:43:33
     2017-12-17 13:43:37   Activity        alive
     2017-12-16 20:14:53   CommandAccepted yes
     2017-12-16 20:06:12   D-firmware      1.0
     2017-12-16 20:06:12   D-serialNr      NEQ0244218
     2017-12-17 13:43:33   PairedTo        0xF10000
     2017-12-16 20:09:59   R-pairCentral   0xF10000
     2017-12-17 13:43:33   RegL_00.          02:01 0A:F1 0B:00 0C:00 16:00 1F:00 00:00
     2017-12-16 20:14:53   aesCommToDev    ok
     2017-12-16 20:14:53   aesKeyNbr       00
     2017-12-17 00:55:29   alarmTest       ok
     2017-12-17 00:55:29   battery         ok
     2017-12-17 00:55:29   level           0
     2017-12-17 13:43:37   peerList        HM1RM_Team,
     2017-12-16 20:17:10   powerOn         2017-12-16 20:17:10
     2017-12-17 00:55:29   recentStateType info
     2017-12-17 00:30:19   sabotageAttackId_ErrIoId_F10000 cnt:4
     2017-12-17 13:43:33   sdRepeat        off
     2017-12-17 00:55:29   smokeChamber    ok
     2017-12-16 20:21:00   smoke_detect    none
     2017-12-17 00:55:29   state           off
     2017-12-16 20:19:40   teamCall        from HM1RM_DEV:02
   helper:
     HM_CMDNR   106
     cSnd       01F1000048F15F00040000000000,01F1000048F15F0103
     mId        00AA
     peerIDsRaw ,00110101,00000000
     rxType     6
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +48F15F,00,00,00
       nextSend   1513514614.04915
       rxt        0
       vccu       VCCU
       p:
         48F15F
         00
         00
         00
       prefIO:
         SCC3:UFO1
     mRssi:
       mNo        6A
       io:
         SCC3       -55.5
         UFO1       -58
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   00
     role:
       chn        1
       dev        1
     rpt:
       IO         UFO1
       flg        A
       ts         1513514613.93083
       ack:
         HASH(0x807f338)
         6A8002F1000048F15F00
     rssi:
       at_SCC3:
         avg        -57.5
         cnt        2
         lst        -57.5
         max        -57.5
         min        -57.5
       at_UFO1:
         avg        -58
         cnt        2
         lst        -58
         max        -58
         min        -58
     shadowReg:
     tmpl:
Attributes:
   IODev      SCC3
   IOgrp      VCCU:SCC3:UFO1
   actCycle   099:00
   actStatus  alive
   alias      Rauchmelder SZ
   autoReadReg 4_reqStatus
   devStateIcon off:secur_smoke_detector@gray on:secur_smoke_detector@red smoke-Alarm.*:secur_smoke_detector@red
   expert     2_raw
   firmware   1.0
   group      _90 HW - HM.RM
   model      HM-SEC-SD-2
   msgRepeat  2
   peerIDs    00000000,00110101,
   room       391 - Wohnflur,393 - Schlafflur
   serialNr   NEQ0244218
   subType    smokeDetector
   webCmd     :

HM1RM3 (Kellergang):
Internals:
   CFGFN      /opt/fhem/_HW/HM.sensoren.cfg
   DEF        44E3BB
   IODev      UFO1
   LASTInputDev SCC3
   MSGCNT     6
   NAME       HM1RM3
   NOTIFYDEV  global
   NR         75
   SCC3_MSGCNT 3
   SCC3_RAWMSG A1266A01044E3BBF10000010011010100000000::-60:SCC3
   SCC3_RSSI  -60
   SCC3_TIME  2017-12-17 13:43:42
   STATE      off
   TYPE       CUL_HM
   UFO1_MSGCNT 3
   UFO1_RAWMSG E44E3BB,0000,011DF668,FF,FFB8,66A01044E3BBF10000010011010100000000
   UFO1_RSSI  -72
   UFO1_TIME  2017-12-17 13:43:42
   lastMsg    No:66 - t:10 s:44E3BB d:F10000 010011010100000000
   peerList   HM1RM_Team,
   protLastRcv 2017-12-17 13:43:42
   protResnd  1 last_at:2017-12-17 13:43:39
   protSnd    5 last_at:2017-12-17 13:43:42
   protState  CMDs_done
   rssi_at_SCC3 min:-60.5 max:-60 lst:-60 cnt:3 avg:-60.33
   rssi_at_UFO1 max:-72 min:-72 avg:-72 cnt:3 lst:-72
   READINGS:
     2017-12-16 20:05:57   .D-devInfo      000100
     2017-12-16 20:05:57   .D-stc          CE
     2017-12-16 19:45:46   .R-devRepeatCntMax 0
     2017-12-17 13:43:42   .peerListRDate  2017-12-17 13:43:42
     2017-12-17 13:43:42   .protLastRcv    2017-12-17 13:43:42
     2017-12-17 13:43:37   Activity        alive
     2017-12-17 00:35:19   CommandAccepted yes
     2017-12-16 20:05:57   D-firmware      1.0
     2017-12-16 20:05:57   D-serialNr      NEQ0004972
     2017-12-17 13:43:40   PairedTo        0xF10000
     2017-12-16 20:10:25   R-pairCentral   0xF10000
     2017-12-17 13:43:40   RegL_00.          02:01 0A:F1 0B:00 0C:00 16:00 1F:00 00:00
     2017-12-17 00:35:19   aesCommToDev    ok
     2017-12-17 00:35:19   aesKeyNbr       00
     2017-12-17 09:19:14   alarmTest       ok
     2017-12-17 09:19:14   battery         ok
     2017-12-17 09:19:14   level           0
     2017-12-17 13:43:42   peerList        HM1RM_Team,
     2017-12-16 20:09:00   powerOn         2017-12-16 20:09:00
     2017-12-17 09:19:14   recentStateType info
     2017-12-17 00:10:54   sabotageAttackId_ErrIoId_F10000 cnt:4
     2017-12-17 13:43:40   sdRepeat        off
     2017-12-17 09:19:14   smokeChamber    ok
     2017-12-16 20:21:00   smoke_detect    none
     2017-12-17 09:19:14   state           off
     2017-12-16 20:19:40   teamCall        from HM1RM_DEV:02
   helper:
     HM_CMDNR   102
     cSnd       01F1000044E3BB00040000000000,01F1000044E3BB0103
     mId        00AA
     peerIDsRaw ,00110101,00000000
     rxType     6
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +44E3BB,00,00,00
       nextSend   1513514622.35196
       rxt        0
       vccu       VCCU
       p:
         44E3BB
         00
         00
         00
       prefIO:
         SCC3:UFO1
     mRssi:
       mNo        66
       io:
         SCC3       -60
         UFO1       -72
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   00
       qReqStat   00
     role:
       chn        1
       dev        1
     rpt:
       IO         UFO1
       flg        A
       ts         1513514622.22351
       ack:
         HASH(0x8311e30)
         668002F1000044E3BB00
     rssi:
       at_SCC3:
         avg        -60.3333333333333
         cnt        3
         lst        -60
         max        -60
         min        -60.5
       at_UFO1:
         avg        -72
         cnt        3
         lst        -72
         max        -72
         min        -72
     shadowReg:
     tmpl:
Attributes:
   IODev      UFO1
   IOgrp      VCCU:SCC3:UFO1
   actCycle   099:00
   actStatus  alive
   alias      Rauchmelder KG
   autoReadReg 4_reqStatus
   devStateIcon off:secur_smoke_detector@gray on:secur_smoke_detector@red smoke-Alarm.*:secur_smoke_detector@red
   expert     2_raw
   firmware   1.0
   group      _90 HW - HM.RM
   model      HM-SEC-SD-2
   msgRepeat  2
   peerIDs    00000000,00110101,
   room       210 - Flur
   serialNr   NEQ0004972
   subType    smokeDetector
   webCmd     :

HM1RM_Team (Leader):
Internals:
   CFGFN      /opt/fhem/_INC/900_Global.cfg
   DEF        00110101
   NAME       HM1RM_Team
   NOTIFYDEV  global
   NR         1130
   STATE      off
   TESTNR     1
   TYPE       CUL_HM
   chanNo     01
   device     HM1RM_DEV
   peerList   HM1RM3,HM1RM2,HM1RM1,
   sdTeam     sdLead
   READINGS:
     2017-12-16 20:20:59   aesCBCCounter   0000ED
     2017-12-16 20:21:00   eventNo         04
     2017-12-16 20:21:00   level           0
     2017-12-17 13:43:37   peerList        HM1RM3,HM1RM2,HM1RM1,
     2017-12-16 20:21:00   smoke_detect    none
     2017-12-17 13:43:54   state           off
     2017-12-16 20:19:40   teamCall        from HM1RM_DEV:02
     2017-12-16 20:21:00   trigger_cnt     4
   helper:
     fkt        sdLead2
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     role:
       chn        1
       vrt        1
     tmpl:
Attributes:
   model      virtual_1
   peerIDs    44E3BB01,48F15F01,48F21301,
   webCmd     press short:press long

HM-Info peerXref
peerXref done:
 x-ref list
    HM1RM1 => HM1RM_Team
    HM1RM2 => HM1RM_Team
    HM1RM3 => HM1RM_Team
    HM1RM_Team => HM1RM1 HM1RM2 HM1RM3
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: frank am 17 Dezember 2017, 14:29:03
attr iogrp ist falsch. der zweite doppelpunkt muss ein komma sein.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 17 Dezember 2017, 14:43:32
Datenübertragung bei Homematic braucht etwas Zeit und Geduld  ;D
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 17 Dezember 2017, 14:46:00
attr iogrp ist falsch. der zweite doppelpunkt muss ein komma sein.
Au ja! Hattu vollkommen recht! War wohl zu "früh" heute Nacht ^^ Super das Dir das aufgefallen ist; ich hätte bestimmt noch 1000 mal und mehr drüber gelesen, ohne es zu sehen  ???
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: M_I_B am 17 Dezember 2017, 14:52:56
Datenübertragung bei Homematic braucht etwas Zeit und Geduld  ;D
... wenn ich das in bar bekommen könnte, was ich bei dem Zeugs schon an Zeit und Geduld investiert habe, bräuchte ich nie wieder arbeiten  ::)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 18 Dezember 2017, 08:31:58
@Christoph:
Ne, eine Rückgabe geht nicht. Die sind modifiziert (Schalter-MOD) und somit raus aus der Garantie. Zudem bin ich seit einiger Zeit kein Kunde mehr bei ELV/eQ3 und will mit dem Laden auch nichts mehr zu tun haben; die haben mich ein mal zu oft verar***t...
...
Also egal wie man das sieht... Ich für meine Teil habe die in die Gruppe des üblichen eQ3- Murkses eingeordnet und werde mich im neuen Jahr nach einer Alternative umschauen. Die sind mir einfach viel zu unzuverlässig... und gerade auf sicherheitstechnische Einrichtungen sollte man sich verlassen können...
Moin Michael
Stimmt da war ja mal was! Sowohl der Schalter, als auch die EQ3-Nummer.
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: dokle am 30 Dezember 2017, 06:43:23
Hallo zusammen,

gibt es eine Möglichkeit, den auslösenden Melder per Fhem zu deaktivieren?

Hintergrund ist folgender;
Mein Vater ist behindert und sehr wacklig auf den Beinen. Ab und zu kocht er aber noch selbst, oder brät sich nen Ei. Hin und wieder löst er auch den Melder aus, wenn der Dunst von der Küche ins Wohnzimmer zieht, mit der Folge, dass er auf nen Stuhl steigt, um den Melder zu quittieren.

Jetzt hab ich ne HM-RC-4-3 eingebunden und wollte eine Taste als Quittungstaste programmieren, geht aber nicht.

Der HM-SEC-SD2 ist in einer virtuellen Gruppe in fhem. TeamCall + AlarmOn kann ich per Fhem auslösen. Wenn ich einen Alarm mit AlarmOn sende, geht der Melder an und lässt sich per AlarmOff auch wieder ausschalten. Erkennt der Melder Rauch und löst deshalb aus, bringt AlarmOff nichts und er lässt sich nur am Melder direkt quittieren.

Gibts irgend ne Möglichkeit den echten Alarm per Fhem zu deaktivieren/quittieren, oder muss ich wirklich den Hardware-Taster im Melder angreifen?

VG
dokle
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: FranzB94 am 30 Dezember 2017, 09:36:17
Hi!
...dass er auf nen Stuhl steigt, um den Melder zu quittieren.

Den Taster erreicht man auch völlig ohne Elektronik vom Boden aus mit einen Besen-/Schrubberstiel!  8)

Gruß Franz
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: automatisierer am 30 Dezember 2017, 10:01:59
Bedienungsanleitung lesen...
Ich meine, man kann den Alarm nur an dem Melder abschalten der ausgelöst hat. Was ja auch durchaus sinn macht. Der virtuelle TeamLeader simuliert ja letztlich nur einen SD2.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Gunther am 30 Dezember 2017, 10:20:09
Zumindest steht folgendes im Wiki:
Zitat
Bei Alarm alle SDs des Teams stumm schalten durch Stummschalten eines einzelnen
define sd.nf.quiet notify sdTeam:.*level:.199 set sdTeam alarmOff

Ob man das auch per virtuellem Button machen kann ist einen Test wert.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Pfriemler am 30 Dezember 2017, 10:36:23
dokle schreibt ja, dass er alarmOff und alarmOn erfolgreich benutzt, was aber nicht bei einem lokalen echten Alarm funktioniert. Das Notify im Wiki wird sich da nicht anders verhalten - üblicherweise schaltet man ja den auslösenden Melder stumm und mit dem Notify alle übrigen (fernausgelösten) mit.

Die Funkferndeaktivierung eines lokalen Alarms dürfte die VdS-Zulassung aber genauso verhageln, insofern hätte ich im konkreten Anwendungsfall auch zu der Besenstielmethode geraten - das Handling kann man ja beim monatlichen Check gleich mit üben. Der SD-2 hat ja eine durchaus besenstielfreundliche Taste.
Beim alten SD müsste man das Ende mit einer kleinen Kuhle versehen.

Noch besser wäre allerdings, die Ausbreitung der Küchendünste zu minimieren  8)
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 30 Dezember 2017, 10:38:51
Ich glaube das Problem beim echten Alarm ist: Das Quittieren mit der Taste löscht nicht den Alarm sondern solange Rauch in der Kammer ist wird nur für einen definierten Zeitraum der Ton abgestellt. Der Alarm bleibt bestehen, bis kein Rauch mehr erkannt wird.

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: dokle am 30 Dezember 2017, 17:24:41
Erstmal Dankeschön für die rege Beteiligung an meiner Herausforderung.  ;D

Also vorweg, mir ist durchaus klar, dass es zu 99% Sinnvoll ist, einen echten Alarm nur am auslösenden Melder quittieren zu können.
Dennoch hatte ich die Hoffnung, dass es per Funk doch irgendwie möglich ist - notfalls werde ich den Taster am Melder halt Hardwareseitig angreifen müssen.

Die Lösung mit dem Besenstiel ist mir auch schon eingefallen, weshalb ich das meinem Vater erstmal als Übergangslösung angeraten hatte.
Eine weitere Minimierung des Dunstes scheidet aufgrund der baulichen Begebenheiten leider aus.

Vielleicht steckt ja jemand von Euch so tief im Funkprotokoll drin, dass es über ein modifiziertes Paket / raw message, o.ä. doch noch möglich wäre, eine Quittierung per Funk zu setzen?!

Die VDS Zertifizierung ist mir pers. egal. Der RM wäre an dem Ort ohnehin nicht gesetzl. vorgeschrieben, da kein Schlafraum o. Fluchtweg. Weil er trotzdem Sinnvoll ist, hängt er ja auch da. Als Feuerwehrmann hab ich jede Woche mind. zwei Einsätze aufgrund von RM-Fehlalarmen im privaten Bereich, so ganz vermeiden lassen sich die scheinbar Herstellerübergreifend also nicht - egal ob Baumarktmelder nach DIN EN 14604, oder Premiummelder mit zusätzlicher VDS, Kriwan, etc. Zertifizierung.
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MCh76 am 16 Januar 2018, 19:37:42
Hallo zusammen,

ich verzweifle an der Einrichtung meiner drei HM-SEC-SD-2 in FHEM.
Ich bin den kompletten Thread durchgegangen, habe die verschiedenen WiKi Artikel studiert (auch zu VCUL) und scheitere immer nach dem pairen der SD mit der VCCU. Zunächst sieht es mit dem Pairing beim ersten SD gut aus, sobald ich allerdings statusRequest beim SD anfordere resultiert das ganze in MISSING ACK. Beim zweiten SD dagegen scheint nicht mal das initale Pairing an VCCU zu klappen.
Ich bin über jede Hilfe dankbar.

List auf CUL:
Internals:
   CMDS       BbCFiAZNkGMKUYRTVWXefmLltux
   CUL1_MSGCNT 36
   CUL1_TIME  2018-01-16 19:23:07
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM0@38400 1234
   DeviceName /dev/ttyACM0@38400
   FD         10
   FHTID      1234
   NAME       CUL1
   NR         24
   NR_CMD_LAST_H 29
   PARTIAL   
   RAWMSG     A0DD8A61065ABDD123456060100002D
   RSSI       -51.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.66 CUL868
   initString X21
Ar
   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:
     2017-11-20 22:02:10   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2018-01-16 17:52:38   cmds             B b C F i A Z N k G M K U Y R T V W X e f m L l t u x
     2018-01-16 19:13:03   raw             is000FFFFF0FF0
     2018-01-16 19:23:07   state           Initialized
   XMIT_TIME:
     1516124080.06869
     1516124086.04581
     1516124086.573
     1516124086.66725
     1516124086.85075
     1516124765.36176
     1516124771.25142
     1516124771.76676
     1516124925.7172
     1516124926.08047
     1516124926.25627
     1516124926.52065
     1516124926.77993
     1516124927.04118
     1516126680.35391
     1516126685.75902
     1516126918.12676
     1516126918.37897
     1516126918.63995
     1516126918.9019
     1516126919.16226
     1516126919.42329
     1516126987.44391
     1516127220.68055
     1516127223.73714
     1516127230.1936
     1516127233.98853
     1516127282.81266
     1516127288.66573
   helper:
     64C6DD:
       QUEUE:
     65ABDD:
       QUEUE:
Attributes:
   hmId       123456
   icon       cul_cul
   rfmode     HomeMatic
   room       90_Homematic,99_Geraete

List auf VCCU:
Internals:
   CUL1_MSGCNT 5
   CUL1_RAWMSG A0C89867020DCB7000000002858::-101:CUL1
   CUL1_RSSI  -101
   CUL1_TIME  2018-01-16 18:42:15
   DEF        123456
   IODev      CUL1
   LASTInputDev CUL1
   MSGCNT     5
   NAME       VCCU
   NOTIFYDEV  global
   NR         59
   NTFY_ORDER 50-VCCU
   STATE      CUL1:ok,
   TYPE       CUL_HM
   assignedIOs CUL1
   protState  Info_Cleared
   READINGS:
     2018-01-16 18:42:15   unknown_20DCB7  received
   helper:
     HM_CMDNR   34
     mId        FFF0
     regLst     ,0
     rxType     1
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       
       ioList:
         CUL1
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
Attributes:
   IODev      CUL1
   IOList     CUL1
   expert     2_defReg+raw
   model      CCU-FHEM
   room       90_Homematic
   subType    virtual
   webCmd     virtual:update

List auf SD:
Internals:
   CFGFN     
   CUL1_MSGCNT 15
   CUL1_RAWMSG A0EB6A61064C6DD123456060100002A::-49.5:CUL1
   CUL1_RSSI  -49.5
   CUL1_TIME  2018-01-16 18:46:11
   DEF        64C6DD
   IODev      CUL1
   LASTInputDev CUL1
   MSGCNT     15
   NAME       HM_64C6DD
   NOTIFYDEV  global
   NR         128
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:B6 - t:10 s:64C6DD d:123456 060100002A
   protCmdDel 6
   protLastRcv 2018-01-16 18:46:11
   protResnd  8 last_at:2018-01-16 19:28:08
   protResndFail 6 last_at:2018-01-16 19:28:13
   protSnd    25 last_at:2018-01-16 19:28:02
   protState  CMDs_done_Errors:1
   rssi_CUL1  cnt:1 lst:-42 min:-42 avg:-42 max:-42
   rssi_at_CUL1 cnt:15 lst:-49.5 avg:-47.6 min:-53 max:-44
   READINGS:
     2018-01-16 18:05:48   Activity        alive
     2018-01-16 18:05:44   CommandAccepted yes
     2018-01-16 18:05:43   D-firmware      1.0
     2018-01-16 18:05:43   D-serialNr      OEQ2013449
     2018-01-16 18:34:46   PairedTo        0x123456
     2018-01-16 18:05:47   R-pairCentral   0x123456
     2018-01-16 18:34:46   RegL_00.          02:01 0A:99 0B:18 0C:93 16:00 1F:00 00:00
     2018-01-16 18:05:44   aesCommToDev    ok
     2018-01-16 18:05:44   aesKeyNbr       00
     2018-01-16 18:46:11   alarmTest       ok
     2018-01-16 18:46:11   battery         ok
     2018-01-16 18:46:11   level           0
     2018-01-16 18:46:11   recentStateType info
     2018-01-16 18:34:46   sdRepeat        off
     2018-01-16 18:46:11   smokeChamber    ok
     2018-01-16 19:28:13   state           MISSING ACK
   helper:
     HM_CMDNR   184
     cSnd       0112345664C6DD010E,0112345664C6DD010E
     mId        00AA
     peerIDsRaw ,00000000
     regLst     ,0
     rxType     6
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +64C6DD,00,00,00
       nextSend   1516124771.86082
       prefIO     
       rxt        0
       vccu       
       p:
         64C6DD
         00
         00
         00
     mRssi:
       mNo        B6
       io:
         CUL1       -47.5
     prt:
       bErr       0
       sProc      0
       helper:
         prt:
           rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         CUL1
       flg        A
       ts         1516124771.76631
       ack:
         HASH(0x26023b8)
         B6800212345664C6DD00
     rssi:
       CUL1:
         avg        -42
         cnt        1
         lst        -42
         max        -42
         min        -42
       at_CUL1:
         avg        -47.6
         cnt        15
         lst        -49.5
         max        -44
         min        -53
     shadowReg:
Attributes:
   IODev      CUL1
   IOgrp      VCCU:CUL1
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,
   room       CUL_HM
   serialNr   OEQ2013449
   subType    smokeDetector
   webCmd     statusRequest

List auf SD2:
Internals:
   CFGFN     
   CUL1_MSGCNT 16
   CUL1_RAWMSG A0DD8A61065ABDD12345606010000::-51.5:CUL1
   CUL1_RSSI  -51.5
   CUL1_TIME  2018-01-16 19:23:07
   DEF        65ABDD
   IODev      CUL1
   LASTInputDev CUL1
   MSGCNT     16
   NAME       HM_65ABDD
   NOTIFYDEV  global
   NR         237
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:D8 - t:10 s:65ABDD d:123456 06010000
   protCmdDel 3
   protLastRcv 2018-01-16 19:23:07
   protResnd  3 last_at:2018-01-16 19:42:10
   protResndFail 3 last_at:2018-01-16 19:42:14
   protSnd    16 last_at:2018-01-16 19:42:04
   protState  CMDs_done_Errors:1
   rssi_at_CUL1 cnt:16 lst:-51.5 avg:-50.03 min:-53.5 max:-43.5
   READINGS:
     2018-01-16 19:21:58   Activity        alive
     2018-01-16 19:21:59   CommandAccepted yes
     2018-01-16 19:21:58   D-firmware      1.0
     2018-01-16 19:21:58   D-serialNr      OEQ2014225
     2018-01-16 18:48:45   R-pairCentral   set_0x123456
     2018-01-16 19:21:59   aesCommToDev    ok
     2018-01-16 19:21:59   aesKeyNbr       00
     2018-01-16 19:23:07   alarmTest       ok
     2018-01-16 19:23:07   battery         ok
     2018-01-16 19:23:07   level           0
     2018-01-16 19:23:07   recentStateType info
     2018-01-16 19:21:58   sdRepeat        invalid
     2018-01-16 19:23:07   smokeChamber    ok
     2018-01-16 19:42:14   state           MISSING ACK
   helper:
     HM_CMDNR   218
     cSnd       0112345665ABDD010E,0112345665ABDD010E
     mId        00AA
     regLst     ,0
     rxType     6
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +65ABDD,00,00,00
       nextSend   1516126987.53835
       prefIO     
       rxt        0
       vccu       
       p:
         65ABDD
         00
         00
         00
     mRssi:
       mNo        D8
       io:
         CUL1       -49.5
     prt:
       bErr       0
       sProc      0
       helper:
         prt:
           rspWait:
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         CUL1
       flg        A
       ts         1516126987.44331
       ack:
         HASH(0x36ca748)
         D8800212345665ABDD00
     rssi:
       at_CUL1:
         avg        -50.03125
         cnt        16
         lst        -51.5
         max        -43.5
         min        -53.5
     shadowReg:
       RegL_00.    02:01 0A:99 0B:18 0C:93
Attributes:
   IODev      CUL1
   IOgrp      VCCU:CUL1
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   room       CUL_HM
   serialNr   OEQ2014225
   subType    smokeDetector
   webCmd     statusRequest

Und noch eine Frage:
In welchem Abstand kommunizieren die SD denn wenn alles klappt mit der VCCU? Werden da ab und an die Readings der SD aktualisiert, auch wenn kein "Alarm" herrscht?

Danke,
Chris

Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: Otto123 am 16 Januar 2018, 21:53:48
Hallo Chris,

ich würde zunächst den CUL als Ursache vermuten. Muss aber nicht richtig sein.
https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale

Hast Du den CUL exklusiv für Homematic?

Gruß Otto
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MCh76 am 16 Januar 2018, 22:19:57
Hallo Otto,
danke für deine Idee und den Link.

Was genau meinst du mit "Hast du den CUL exclusiv für Homematic"?
Ich steuere damit halt noch diverse Funksteckdosen, hab eine HomeKit Integration gemacht im FHEM etc...

Ich bin wirklich verzweifelt. Das initiale Pairing funktioniert, das weist auch das entsprechende Reading aus.
Ich habe nun auch noch der VCCU einen hmKey verpasst und den drei SD's diesen Key assigned.

Sobald ich einen status Request auf die SD ausführe zeigt es in den Readings das Pairing nicht mehr an.

Das HMInfo liefert in der Config Check noch folgendes:
configCheck done:

 missing register list
    HM_64C6DD: RegL_00.
    HM_65ABDD: RegL_00.
    HM_65AEBC: RegL_00.

 Register changes pending
    HM_64C6DD
    HM_65ABDD
    HM_65AEBC

 peer list incomplete. Use getConfig to read it.
    incomplete: HM_64C6DD:
    incomplete: HM_65AEBC:

 peering strange - likely not suitable
    HM_65ABDD not peered!! add SD to any team !!



Die weiteren geplanten Schritte wie virtueller Team Lead brauche ich ja dann sicher erst gar nicht anzugehen.

Gibt es noch irgendwelche Tipps zur Fehlersuche? Leider ist das ganze VCCU/Homematic Thema noch relatives Neuland für mich.

VG,
Chris
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 17 Januar 2018, 07:45:16
Moin Chris
Was Otto meint, ist ob Du den CUL noch fuer etwas anderes benutzt. Ein CUL ist wohl mit manchen Homematic Geraeten problematisch, und der SD2 gehoert dazu. Das Umschalten tut dann sein uebriges, wenn man Ihn fuer mehrere Protokolle nutzt.
Entscheidend ist aber auch Geduld beim Pairen, das "set_0x123456" weist darauf hin, dass Du nicht ordentlich gepairt hast. Wenn Du dann auch noch anfaengst weitere Schritte zu machen, wie Keys zu vergeben wirst du irgendwann verzweifeln!
Also mach in Ruhe Eins nach dem Anderen, und denke mal ueber eine andere FW fuer den CUL nach. Es gibt wohl inzwischen mehrere Alternativen!
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MCh76 am 17 Januar 2018, 11:32:17
Bzgl. Verwendung der CUL für was anderes:
Ich steuere eben ein paar IT-Funksteckdosen, HUE, Harmony-Hub und meine Somfy Markise mit der CUL.

Dazu noch folgende Fragen:
1. )So wie ich Otto und Christoph nun aber verstanden habe, wäre statt der jetzigen CUL für die ganze Homematic Steuerung besser noch
ein "HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry_Pi" auf den Raspi aufzustecken und dann alle HM Komponenten auf dieses Device anzulernen?
Liege ich da richtig?

2.) wenn ich das "HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry_Pi" eingerichet habe, sollte dann meine bisherige CUL1 auf einen anderen Modus gestellt werden, oder
kann die die im HM bleiben?

3.) wenn ich jetzt einen GetConfig auf die SD durchführe, dann zeigt es mir in den Readings für alle 3 SD ein "paired to" an. Allerdings führt dann scheinbar jeder anschließende
"statusRequest" zu einem Zufallsergebnis...In 60% der Fälle endet der Request allerdings in einem "MISSING ACK". Irgendwie ist das doch seltsam, an der Entfernung der SD zur CUL kann es eigentlich nicht liegen, "bastele" momentan innerhalb eines Raumes und auf einem Abstand von ca. 2,5 metern zwischen SD auf Schreibtisch und CUL.

4.) noch eine Frage zum virtuellen Team und der WiKi Beschreibung:
Erzeugen eines virtuellen TeamLeads könnte so aussehen:

define TeamDev CUL_HM 111111
set TeamDev virtual 1
rename TeamDev_Btn1 Rauchmelder_Team

Bitte beachten: die HMID muss für die gesamte Installation einmalig sein.

a ) Die "111111" als HMID ist abweichend zu der der VCCU zu wählen nehme ich an?
b) Wofür steht "TeamDev_Btn1" bzw. gibt es auch ein "TeamDev_Btn2" für neue Teams? oder legt man dann ein neues TeamDEV an?

Nochmals vielen Dank für Eure Antworten/Ideen!
VG,
Chris



Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: pc1246 am 17 Januar 2018, 12:26:42
Wow
So viele Fragen und so viele interessante Sachen.
Du kannst mit Deinem CUL HUE und Harmony Hub steuern? Schau dir mal IODev an, dann siehst du wer der jeweilige "Chef" ist!
1: Grundsaetzlich koennte man das mit einem ja beantworten. Mache ich aber nicht, da Du Dich so auf einenRPI festlegst. Mit einem Wemos-D1 oder NodeMCU und dem selben Modul bist du flexibler und kannst es auch noch guenstiger positionieren!
2: Ja. Ok war eine Oder Frage, laesst sich aber trotzdem mit Ja beantworten. Da Du ja eine VCCU hast, koennte der CUL so bleiben, Du muesstest dann nur die RM fest ((preferred IO) dem HM-MOD zuordnen. Da es noch andere Devices gibt, die Probleme haben, ist es fraglich ob es Sinn macht. Zudem willst Du ja Somfy und IT mit fdem CUL machen.
3: Du kannst die CUL Problematik nicht wegdiskutieren. Und ich weiss jetzt gar nicht ob meine da nicht auch ab und an mal rummuckeln. Ich werde das Gefuehl nicht los, das die RM sehr gespraechig sind, und irgendwann Ihre Sendegrenze erreicht haben. Insbesondere wenn Du jetzt die ganze Zeit mit denen rummachst.
4:
a: Das ist richtig. Du musst dem Teamlead eine eindeutige HM-ID in Deiner Umgebung verpassen, da es fuer HM ein echtes Mitglied ist!
b: Virtuelle Devices haben mehrere (40?) BTNs. Ist bei der VCCU ganz gut erklaert, wenn ich mich recht erinnere!
Gruss Christoph
Titel: Antw:HM-SEC-SD-2 neu
Beitrag von: MCh76 am 17 Januar 2018, 14:24:09
Vielen Dank f