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
Bin grad auf der Suche nach Rauchmeldern nur erschreckt mich die Info im Netz der Fehlalarme. Wann kommen die V2 denn ?
Ausser dem Vermerk in der CCU2 Software ist soweit nichts über v2 bekannt.
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).
Zitat 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).
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 ;)
Hallo Zusammen,
ich werde auch auf die Rauchmelder warten.
was bedeutet eigenlich
ZitatDenke 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.
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
Würd mich auch interessieren- gibts den nun schon ?
Mich würde auch freuen wenn der Rauchmelder nicht nur Optisch Arbeiten würde.
Scheint noch immer nicht im Shop zu sein ???...
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
Interessante Info, allerdings finde ich die Teile nirgendwo auf der Seite.
Gruß Marcel
Hi Marcel,
das kam im RSS-Feed von ehomeportal auf dem Handy. Webseiten schaue ich so selten an...
Ciao, -MN
Zitat 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
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. ;)
Zitat von: Thomas X am 14 Februar 2016, 09:13:47Zumal 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ß!
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
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!
Zitat 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!
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
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
ZitatDie 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?
Zitat von: frank am 15 Februar 2016, 12:27:04
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
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
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
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
Zitat 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
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
Zitat von: no_Legend am 15 Februar 2016, 21:24:09
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.
ZitatIch 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
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??
Zitat von: Joker am 20 März 2016, 13:55:37
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ß!
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
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
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
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 ;)
ZitatDer 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
ZitatDie 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
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.
Zitat von: Prof. Dr. Peter Henning am 24 März 2016, 22:23:13
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:
ZitatVdS ü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?
Zitat von: Prof. Dr. Peter Henning am 24 März 2016, 22:23:13
ZitatDer 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
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
Zitat von: Prof. Dr. Peter Henning am 25 März 2016, 04:35:19
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
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?
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
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.
Zitat von: DerFrickler am 22 März 2016, 12:44:22
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?
Zitat von: brmpfl am 30 März 2016, 15:01:59
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
Schon mal geloggt?
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 ;-)
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.
so ganz nebenbei, R-pairCentral steht dauerhaft auf set_0x123456... Readings sind keine mehr da... irgendwie hat der RM keine Lust mehr auf FHEM
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
soweit nichts neues im Westen!
state = RESPONSE TIMEOUT:RegisterRead
activity = unknown
Ist er den gepairt? Logge das pairing.
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
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!
Zitathabe 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.
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.
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
Zitat von: DerFrickler am 06 April 2016, 22:17:14state = 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
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
Zitat von: christian.uhlmann am 10 April 2016, 13:32:00... 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 ...
Zitat von: christian.uhlmann am 10 April 2016, 13:32:00man 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...
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 ...
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?!
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.
@DerFrickler
Zitat2016.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.
Zitat von: fhem-hm-knecht am 11 April 2016, 12:53:16
@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ß!
Zitat von: pc1246 am 11 April 2016, 12:21:38... 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 ...
Zitat von: pc1246 am 11 April 2016, 12:21:38Das 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.
Zitat von: pc1246 am 11 April 2016, 12:21:38P.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 ...
Zitat von: DerFrickler am 11 April 2016, 21:35:40Aber 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?
Zitat von: DerFrickler am 11 April 2016, 21:35:40... 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...
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 ;)
... ähhh ... Sorry Hary, aber ich hab keinen blassen Schimmer, was Du mir damit sagen möchtest ?!?
Zitat von: M_I_B am 12 April 2016, 00:14:18
welches Modul wo resp. wie installieren?
das Perl-Modul meinte ich...
... 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...
Zitat 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...
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ß!
Zitat von: DerFrickler am 12 April 2016, 10:23:51Ja, 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:
- Das PERL- Modul ist/war schon da, bevor ich die SD-2 hier hatte. Die Ergebnisse sind also darauf bezogen.
- Die SCC akzeptieren das ATTR "hmKey" nicht, so das ich keinen Key festlegen kann.
Also stehe ich erneut vor der Frage, was bei mir denn anders ist, das ich zu keinem akzeptablem Ergebnis komme.
ZitatDie 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.
Zitat von: fhem-hm-knecht am 12 April 2016, 11:25:53
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
Zitat von: fhem-hm-knecht am 12 April 2016, 11:25:53deswegen 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) )
Moin
Kurze Frage, was bewirkt der Reedkontakt? Ich haette erwartet, dass er den Melder stummschaltet, und man so die Konfiguration vornehmen kann!?
Gruss Christoph
Zitat von: pc1246 am 12 April 2016, 11:40:53was bewirkt der Reedkontakt?
Nöö, der schaltet das komplette Teil aus. Der sitzt direkt in der + Zuleitung von den Batterien zum Sensor ...
Zitat von: M_I_B am 12 April 2016, 11:42:41
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
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 :-\
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
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
Zitat von: pc1246 am 12 April 2016, 12:57:28
...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ß!
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
Zitat von: pc1246 am 13 April 2016, 08:45:38
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...
Zitat von: DerFrickler am 13 April 2016, 09:02:15nur 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:
ZitatRauchwarnmelders 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 ...
Zitat von: pc1246 am 12 April 2016, 12:13:56Na toll! So langsam entferne ich mich dann doch von den RM's!
... wieso? Erkläre mal bitte ...
Zitat von: M_I_B am 12 April 2016, 11:33:24... 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.
Zitat von: M_I_B am 13 April 2016, 10:21:47
... 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
... 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 ;)
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
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
Mache ein getconfig. Klappt es und was steht dann drin?
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
Zitat von: Mirak am 18 April 2016, 20:54:00... alle drei peerIDs im virtuellen TeamLead ... / ... im RM bei peerID auch die des TeamLead ... / ... dass TeamCall usw. nicht funktioniert.
*zustimm*
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.
Zitat von: pc1246 am 11 April 2016, 12:21:38
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
Zitat von: pc1246 am 20 April 2016, 07:18:25
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.
Zitat von: pc1246 am 20 April 2016, 07:18:25
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!
... dann sind's schon 4, oder habe ich mich verzählt?
Zitat von: M_I_B am 20 April 2016, 08:31:44
... dann sind's schon 4, oder habe ich mich verzählt?
ich auch !... fünf ;)
Zitat von: kvo1 am 20 April 2016, 08:55:13
ich auch !... fünf ;)
das hängt davon ab wer schon mitgezählt wurde... ansonsten 6
Zitat von: DerFrickler am 20 April 2016, 12:48:42
das hängt davon ab wer schon mitgezählt wurde... ansonsten 6
Zähle ich doch mal:
- pc1246
- christian.uhlmann
- mele
- kvo1
- DerFrickler
- ...ike ...
--> 50 / 8,33 Euronen derzeit pro Person
Ich habe eine ELV-Card, bringt noch mal 3% und keine Versandkosten!
Gruss Christoph
... pffft ... Wer hat die nicht? ;D
Ich hätte demnächst einiges zu bestellen, aber wenn wer näher dran ist, ...
Zitat von: M_I_B am 20 April 2016, 13:05:20
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
... 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...
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
Ich würd mich auch als Sponsor beteiligen 8)
Ich schließe mich als Sponsor an.
Zitat 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.
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:
- pc1246 - Geld erhalten
- christian.uhlmann - Geld bezahlt
- mele - Geld erhalten
- kvo1 - Geld erhalten
- DerFrickler - Geld erhalten
- gompf - Geld erhalten
- grappa24 - Geld erhalten
- brmpfl - Geld erhalten
- M_I_B - Geld erhalten
- Mirak - Geld erhalten
- jschmitt - Geld erhalten
- MadMax-FHEM - Geld erhalten
- Bytechanger - Geld erhalten
- Morgennebel - Geld erhalten
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
;)
Zitat von: christian.uhlmann am 21 April 2016, 14:21:47Bisher 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 ...
Hi, ich beteilige mich auch gerne am Kauf
Gruß
Rainer
Also zum Team/Peering einrichten und testen braucht man ja eigentlich zwei :P
Zitat von: MarcelK am 21 April 2016, 22:01:59
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 :)
Zitat von: M_I_B am 21 April 2016, 19:10:27
... 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.
... 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)
Zitat von: kvo1 am 21 April 2016, 23:53:02wenn 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 ...
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
Wenn ich welche habe werde ich es testen. Logisch.
gut denn, christian.uhlmann will das alles organisieren... wie stellst Du Dir das mit dem Geld einsammeln vor? Überweisung, PayPal?
Gruß!
Zitat von: DerFrickler am 22 April 2016, 22:53:28wie 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 ...
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
Hab's schon einige bestellt.
Daher bin ich auch an einer schnellen Umsetzung interessiert und wäre dabei.
Gruß
Byte
@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
... ich habe es gerade noch mal für Christian zusammen gefasst:
- pc1246
- christian.uhlmann
- mele
- kvo1
- DerFrickler
- gompf
- grappa24
- brmpfl
- M_I_B
- Mirak
- jschmitt
- MadMax-FHEM
- Bytechanger
- Morgennebel
Wenn wer übersehen wurde, einfach laut "HIER" schreiben ;)
Ich beteilige mich auch gerne.
Ciao, -MN
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
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
Zitat von: Morgennebel am 23 April 2016, 10:39:36Daher 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...
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?
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.
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?
... 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).
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.
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
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.
Danke fuer die Antwort oben
Dann machts wohl Sinn gleich die neuen zu kaufen ..
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
Danke - war nur generell gedacht, ganz so billig sind die Dinger ja auch nicht das ich mir da gleich 10 kaufe.. :)
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
Hi martinp876,
vielen Dank schon mal!
Bin gespannt!
Will demnächst auch meine Wohnung ausrüsten...
Gruß, Joachim
Zitat von: martinp876 am 27 April 2016, 21:47:10
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?
Zitat von: MarcelK am 27 April 2016, 21:55:42
Fehlt in Deiner Anleitung Kapitel 7.5?
Hallo Martin,
die Repeaterfunktion wird doch überall erwähnt ! das sollte schon funktionieren!
Gruß Klaus
Zitat von: kvo1 am 27 April 2016, 22:24:00... 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...
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
Ok, kann er wohl doch. Seltsamer Kommentar.
Das Register zum Einschalten des repeater ist klar, werde ich am Wochenende einbauen.
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
wie erkenne ich, ob ich "alte" rauchmelder bekommen habe oder "neue"?
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
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.
Hallo Martin,
Lässt sich den AES nicht abschalten ?
Gruß Klaus
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
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.
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
Zitat von: Bytechanger am 01 Mai 2016, 11:46:49
Der Batteriestatus wird aber doch übertragen, oder?
zwar nur in dieser Form, aber ja..
battery ok 2016-05-01 10:38:57
Alles richtig.
AES fuer Alarme ist nicht abschaltbar.
Batteriestatus wird angezeigt.
Burst erkennt fhem automatisch
Offen ist also das AES.
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
ZitatMuss 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.
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
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
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
Zitat von: martinp876 am 01 Mai 2016, 19:59:40
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?
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.
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.
Zitat von: christian.uhlmann am 02 Mai 2016, 11:12:29... 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 ...
Zitat von: christian.uhlmann am 02 Mai 2016, 11:12:29Was 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...
Zitat von: christian.uhlmann am 02 Mai 2016, 11:12:29P.S. Vielen Dank Martin für deine Arbeit.
*zustimm*
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.
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
Zitat von: martinp876 am 02 Mai 2016, 21:04:21Von 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 ...
Zitat von: martinp876 am 02 Mai 2016, 21:04:21Wer 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...
Zitat von: Bytechanger am 03 Mai 2016, 07:02:24Ich 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.
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.
Zitat von: martinp876 am 03 Mai 2016, 20:18:43Bei 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?
Zitat von: martinp876 am 03 Mai 2016, 20:18:43... 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.
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
... 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 ...
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?
Zitat von: martinp876 am 04 Mai 2016, 06:24:22Hast 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.
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).
... 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 ...
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
Zitat von: martinp876 am 02 Mai 2016, 06:29:41
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.
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
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
Hallo Marcel,
Zitat von: MarcelK am 06 Mai 2016, 10:36:28
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
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
Sollte gleich sein. Du zeigst das device. Der lead ist der channel.
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
Zitat von: mgernoth am 05 Mai 2016, 23:00:02
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
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.
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
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?
OK, dass wars!
Kommunikationstest durchgeführt, jetzt steht da auch smokeDetect!
Ist etwas verwirrend.
Danke!
Greets
Byte
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
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.
Zitat von: mgernoth am 05 Mai 2016, 23:00:02
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
Hi Marcel,
Zitat von: MarcelK am 09 Mai 2016, 21:26:04
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
Zitat von: mgernoth am 09 Mai 2016, 22:52:19
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
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
Hallo Marcel,
Zitat von: MarcelK am 10 Mai 2016, 01:36:30
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
Zitat von: mgernoth am 10 Mai 2016, 10:12:34
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
Hi,
Zitat von: MarcelK am 10 Mai 2016, 10:38:30
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
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
Hi,
Zitat von: mgernoth am 10 Mai 2016, 12:12:52
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
Zitat von: mgernoth am 10 Mai 2016, 13:52:07
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)
ZitatAnscheinend 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.
ZitatEDIT: 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
Hi,
Zitat von: MarcelK am 10 Mai 2016, 20:06:01
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
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.
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
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
Zitat von: mgernoth am 15 Mai 2016, 13:51:15
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
Wird es bald eine über UPDATE abrufbare Version für den SD2 geben?
Greets
Byte
Ja. Habe schon einmal getestet. Noch ein paar Kleinigkeiten.
ist eingecheckt - testet einmal
Hallo Martin,
Zitat von: martinp876 am 20 Mai 2016, 18:59:26
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
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
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
Hallo Martin,
Zitat von: martinp876 am 20 Mai 2016, 22:38:27
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
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
Zitat 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.
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
Trotzdem sollte die Gefahr eines nicht weitergegebenen Alarms beachtet werden!
Es gibt bestimmt noch mehr,die einen physischen lead haben, entgegen der Empfehlung.
ZitatTrotzdem 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
Lässt sich der counter nicht persistent speichern? Attribut oder so?
Sonst ist nach einem Update Essig...
Wann wird es als normales update hochgeladen?
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.
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 :)
Hallo Martin,
Zitat von: martinp876 am 21 Mai 2016, 16:35:01
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
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
2 Stück CR17450E ca. 12€ und ein Lötkolben ;D
autoreadreg abschalten.
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
... 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
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.
Hallo Martin,
Zitat von: martinp876 am 22 Mai 2016, 17:58:13
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
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 :)
... ö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 ...
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.
... 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
Teamcall steht in der Anleitung . Lang und kurz druecken oder so.
Wen. Alles klappt ist es die reichweite
Zitat von: M_I_B am 23 Mai 2016, 21:18:09
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
Zitat von: martinp876 am 23 Mai 2016, 21:36:09
Teamcall steht in der Anleitung . Lang und kurz druecken oder so.
In der Anleitung ist der TeamCall als "Kommunikationstest" beschrieben.
Zitat von: Christian Uhlmann am 24 Mai 2016, 14:17:38In 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:
@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
Hallo MIB,
wozu ist der einbau des Schalters notwendig?
Gruß
Ingo
... 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.
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?
smoke-Alarm.*
zum Beispiel
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?
Update: Geschafft ::)
Bei mir bekomme ich alle drei RM nur sauber ins FHEM, nachdem ich heute noch mal folgendes gemacht habe:
- Alle Peerings und Pairings bezgl der RM und Leader gelöscht.
- Zusätzlich in den CFG kontrolliert, ob auch alle weg sind
- Configuration neu geladen
- Alle RM FactoryReset und alle ausgeschaltet (mit dem "Schalter")
- FHEM in Pairingmode, ersten RM ON, Pairing, > RM BlinkOrange > getConfig
- im Leader peerChan für diesen RM eingerichtet und getestet (Alarm und TeamCall)
- Den RM mit Schalter ausgeschaltet
- Nächsten RM eingeschaltet und dann weiter bei 5
- Letzten RM eingeschaltet und dann weiter bei 5
- Alle RM eingeschaltet und Test (Alarm und TeamCall)
- RM 2 als Repeater gesetzt und wieder Test
... nu gait dat ...
Die bisherige Vorgehensweise, also erst alle RM pairen und danach jeweils den Peer zum Leader klappt bei mir nicht ...
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 ! ;)
Zitat von: kvo1 am 25 Mai 2016, 23:35:59auch 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 ...
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).
... 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 ...
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
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
Hallo,
Zitat von: automatisierer am 28 Mai 2016, 18:34:52
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
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
Hi,
Zitat von: automatisierer am 28 Mai 2016, 20:33:11
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
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ß
Zitat 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ß
das klappt!
super, dann steht der Bestellung ja nichts im Wege 8)
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
Zitat 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?
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
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
Hast du ein
set <SD2> assignHmKey
gemacht?
Hallo,
Zitat von: Bytechanger am 04 Juni 2016, 08:04:31
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
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
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?
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
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...
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
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
Wenn fhem aktuell ist kann es nur an den AES keys liegen.
Zitat von: martinp876 am 09 Juni 2016, 21:12:59
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
Zitat 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
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 actordas wars.
Zitat von: Depechem am 09 Juni 2016, 21:28:25
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
Zitat von: automatisierer am 09 Juni 2016, 21:36:17
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_Bueround 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:02Der 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
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.
Zitat 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.
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!?
dann musst du uns mal mehr Infos geben.
Einträge im LogFile - list vom Device.
@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
Zitat von: automatisierer am 12 Juni 2016, 08:29:46
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
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 :-(
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
Zitat 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
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)
Zitat 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
Oh man genau daran lag es.
Vielen Dank nun geht alles!
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
Zitat von: michaelapp am 14 Juni 2016, 16:36:13
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.
ZitatSagt State = off das er Offline ist oder wie muss ich das verstehen?
Das heißt dass aktuell kein Alarm ist.
Gruß Marcel
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
Zitat 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
neu anlernen: nein
dein notify reagiert auf ein 'OK' im Reading steht aber 'ok' und das klappt dann von wegen case sensitive nicht
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
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.
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
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
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
Zitat von: automatisierer am 09 Juni 2016, 21:36:17
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.
Zitat 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
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...
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
@Cerberus
ZitatHallo, 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)
@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
@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
Zitat 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
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.
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
Nachdem ich meine alten Rauchmelder nun gegen Homematic tauschen will, hier meine Frage:
Welche sollte man denn nehmen, die SD oder die SD-2 ?
ZitatWelche sollte man denn nehmen, die SD oder die SD-2
Warum noch die alten nehmen?
Die SD-2 laufen doch.
...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
...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 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
2016-07-08 15:57:28 R-pairCentral 0x000000
zumindestens hier war er nicht gepairt.
Zitat von: automatisierer am 14 Juni 2016, 23:10:06
Wo definiere ich den AESkey im virtuellen TeamLeader oder in der VCCU?
Grüße
cerberus
in der VCCU.
... 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
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.....
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.
@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 ...
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
Zitat von: Bytechanger am 26 Juli 2016, 08:09:42Der 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 ...
Tja, habe 9 sd2 und 3 sd.
Mal sehen, wann es mich erwischt..
Greets
Byte
Hallo zusammen,
meine 6 SD-2 hängen seit dem Wochenende. Davor waren zwei für mehre Wochen im Testbetrieb. Bisher keine Fehlalarme.
Christian
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.
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.
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
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
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.
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
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
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
Kein Wunder, das geht auch nicht.
Sd und sd2 sind nicht kompatibel!
;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
Zitat 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.
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".
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
Ja, sieben statt 6 stellen in der hmid vom Teamlead: 113311301
113311 + 01 für den Channel würde gehen
Lg Christian
Hi, danke, wo hast du denn diese komische hmID gefunden? Ich finde überall nur 113113 + 01
Viele Grüße
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
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
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
Dein pairing ist nicht abgeschlossen! => R-pairCentral set_0x123400
Gruss Christoph
Und wie genau kann ich das beheben ? Der Melder ist ja ab dem Pairing-Versuch nichtmehr erreichbar.
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.
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
setze doch mal, zumindestens zum testen => attr IOgrp vccu:hmusb
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
genau, und deshalb tauschen, weil der cul schlechteres timing hat.
Hallo,
Zitat von: raspklaus am 31 August 2016, 11:08:16
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
Was zB könnte ich an der Konfiguration des betroffenen SD ändern um es zu testen ?
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
korrekt: Reading aesCBCCounter
Also im TeamLead einen hohen wert einstellen?
Oder wie gehe ich am schlauesten vor?
Ist ein hex wert...
Hi,
Zitat 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...
Setze mal die Generation eins hoch (das sind die ersten zwei Bytes), also wahrscheinlich auf 000100.
Viele Grüße
Michael
Stellt FHEM sich evtl. nach, wenn du einen TeamCall von einem anderen Rauchmelder aus sendest?
Hallo,
Zitat von: automatisierer am 03 September 2016, 19:23:33
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
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
Hallo,
Zitat von: Bytechanger am 03 September 2016, 20:05:13
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
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
ZitatJa, 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
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
vielleicht bringt ein vergleich mit den werten der anderen rm ein hinweis auf die aktuelle zahl.
@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
Hallo,
Zitat von: Bytechanger am 03 September 2016, 20:42:42
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
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 ??
ZitatDer 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
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
OK,
nachdem alle Rauchmelder ein clear und ein getConfig ausgeführt haben, ging nun auch der teamCall!
Komisch.
Danke nochmal!
Greets
Byte
Hallo,
Zitat von: Bytechanger am 04 September 2016, 19:09:53
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
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.
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
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)
Zitat 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.
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
Zitat von: xsasx am 15 September 2016, 10:12:52
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.
ZitatWas 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
Super DANKE ! Das wollte ich wissen dann steht der bestellung nichts mehr im Wege!
Zitat 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)
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.
Zitat von: xsasx am 15 September 2016, 11:49:44
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.
Zitat von: Lix am 15 September 2016, 11:55:03
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.
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.
ActivePerl herunterladen und per install.sh installieren
Folgende Module per IPKG installiert: ipkg install make gcc coreutils patch
Folgende Symlinks müssen gesetzt werden (und auch nach einem DSM Update wieder erneuert werden)
cd /lib
ln -s libm.so.6 libm.so
ln -s libcrypt.so.1 libcrypt.so
ln -s libdl.so.2 libdl.so
cd /opt/i686-linux-gnu/lib
ln -s /lib/libdl.so.2 libdl.so
Folgende Module per CPAN installiert werden: Bundle::CPAN inc::latest Crypt::Rijndael
Bei letzterem muss das MAKEFILE editiert werden, da sonst das make test fehlschlägt
CCFLAGS=-fstack-protector ==> CCFLAGS=-fno-stack-protector
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.
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?
Zitat von: Lix am 17 September 2016, 12:00:11
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.
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
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.
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
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?
Zitat von: Lix am 15 September 2016, 11:57:30
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 ?
Zitat von: xsasx am 20 September 2016, 14:32:15
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)
Ich bin mir nicht 100%ig sicher, aber soweit ich den Hilfeseiten entnehmen konnte:
- - empfangen die SD2 ausschließlich AES verschlüsselte Befehle. (Alarm on/off teamcall) und das unterstützen derzeit HMLAN und CUL
- - der System Sicherheits KEY kann durch einen Werksreset nicht gelöscht werden.
- - es wird die höchste Version des in der VCCU eingetragenen Schlüssels verwendet. wenn du einen Befehl an den SD2 schicken kannst und
dieser ausgeführt wird, dann hat dein erster Schlüsselaustausch funktioniert - - ich hatte beim 1. Anlernen auch das Problem mit MISSING ACK nach getConfig beim 2. Mal nach Reset hats dann aber geklappt
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
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?
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?
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?
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?
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?
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...
... 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...
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.
... 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ß)...
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
Hallo,
also dieser Rauchmelder macht mich wahnsinnig!
Er meldet sich immer nach der actCycle Zeit dead!!!
Woran liegt das? Bitte helft mir!
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
Zitat von: FhemDav am 20 Oktober 2016, 12:21:07
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 ...
Zitat von: Marlen am 25 Oktober 2016, 11:15:50
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.
@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 ?
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.
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...
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? :-\
@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
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?
@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.
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.
aha, das war der entscheidende Hinweis:
Zitatfü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!!!
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!
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...
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....
Hab nur eine FHTID, die is aber nur 4 stellig
Hallo
Versuchs doch mal mit dem Attribut "hmid"
Gruss Christoph
Ja, das würde gehen, dann muss ich aber alle Sensoren neu anlernen,oder?
Nicht neu anlernen, sondern überhaupt erst mal anlernen. Schick doch mal ein list von einem der bereits angelernten Devices... und von dem cul...
Ja aber die sind doch schon angelernt, sonst würden sie ja nicht in FHEM funktionieren!
Wie generiere ich so eine Liste?
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.
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!?
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?
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
mach auch mal ein list von einem Device.
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
Zitat von: Marlen am 15 November 2016, 20:05:41
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...
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! :-)
Hallo,
Zitat von: Marlen am 15 November 2016, 21:03:47
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
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
Moin,
hat sich geklärt, nach einem Teamcall war das MISSING ACK weg!
LG Marlen
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...
Zitat von: friesenjung am 18 November 2016, 09:55:09
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
Zitat von: friesenjung am 18 November 2016, 09:55:09Gibt 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
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 ;)
Hallo,
evtl. untergegangen, aber ich bekomme es einfach nicht hin.
Könnte mir hierfür bitte einer behilflich sein?
ZitatIch 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.....
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
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...
@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
Zitat von: dk3572 am 23 November 2016, 15:52:02
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...
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
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....
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
Hallo Peter,
steht alles im Wiki. Das peeren mit sich selbst war dazu kontraproduktiv.
-> virtueller Teamlead!
Gruß Otto
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
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
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
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
Hi Peter,
Zitat von: Peter_Listig am 30 Dezember 2016, 20:03:22
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.
Zitat von: Klinki am 31 Dezember 2016, 09:56:21
Wenn Du aber nur 2 Bewegungsmelder hast, dann bleib auf Otto´s Weg.
Es ging aber um Rauchmelder :o
Gruß Otto
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
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
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
Hi,
das peering ist bei den Meldern nicht angekommen, Internals peerlist und Attribute peerids fehlen.
Der Teamleader hat die Info, die RM aber nicht.
ZitatBei jedem Rauchmelder sollte der Name des virtuellen TeamLeaders in der peerList stehen und beim virtuellen TeamLeader jeder Rauchmelder.
Gruß Otto
Okay Danke einstweilen,
werde ich mir Morgen mal ansehen.
Gute Nacht
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
Nix Krampf! Es gibt eine Anleitung, wenn man diese schritt für schritt befolgt, dann ist alles wunderbar.
@ Peter:
Zitat von: Peter_Listig am 03 Januar 2017, 23:05:50
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 !!
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
Zitat 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:
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!
ZitatDer 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
und cul's immer mit der ts-firmware aus dem angepinnten thread nutzen.
Jepp, derzeit TSCUL_fwcode_00_05_02_FHEM_Modules_00_05_02.zip
und trotzdem gehts nicht
Zitat 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
bestens. nach deinem list ist der cul aktuell auch gar nicht an der kommunikation beteiligt.
ZitatNur 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.
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
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.
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
ZitatFHEM-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.
@frank, welches Register ändere ich wie?
Ich bin für jede Hilfe dankbar und versuche es...
Greets
Byte
Zitat 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...
mögliche register mit wertebereichen siehst du mit get regList.
mit set regSet wird es dann gesetzt.
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
Zitat von: Bytechanger am 04 Januar 2017, 15:59:56
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...
@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
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
Moin,
hast Du Einträge im Log?
ZitatDer 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
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
willkommen im Club!
MISSING ACK ist eines der beliebtesten Antworten meiner RM
Greets
Byte
Zitat2017-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
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?
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
Hallo Marcel85,
der ist nicht gepairt!
Gruß Otto
Danke Otto, du hast recht.
Ich muss leider gerade feststellen das sich FHEM beim pairingversuch aufhängt.
Das klingt sehr befremdlich! Wie sollte das gehen?
Gruß Otto
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".
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.
Zitat 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.
Das ist für Homematic sicher eine gute Entscheidung!
Gruß Otto
Hi Marcel85,
wegen:
Zitat 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.
vielleicht nicht mehr relevant aber bei:
Zitat 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".
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
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.
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
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
wenn du nur mal so fragen wolltest, dann ok.
wenn du Hilfe brauchst, dann mal ein list von der vccu und den IO's
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
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?
Zitat von: Marcel85 am 10 Januar 2017, 21:07:52
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
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
Hallo Marcel,
ich habe die alten, die piepsen ganz leise.
Gruß Otto
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 .....
aes key unkenntlich machen...
steht was im LOG?
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.
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?
grundsätzlich würde ich tscul zum laufen bringen.
poste mal die ausgabe von "version".
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
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
@nccfast
Zitatposte mal die ausgabe von "version".
das wort version in die eingabezeile tippen und den befehl auslösen. :)
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
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.
Zitat2017.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?
USB/seriell chip kaputt? Ich hatte einen Arduino nano, da sah die Kommunikation sehr ähnlich aus. Immer mal ein Zeichen "schräg"
Gruß Otto
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
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?
Zitathast du mal cul und rm vom strom getrennt, um overload zu löschen?
JA
Zitatist dein log jetzt vollständig, oder hast du zeilen unterschlagen?
Nix unterschlagen
Zitatwas 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.
Zitatfunktioniert jetzt der sw1pbu?
Nur der sw1pbu funktioniert :-)
Zitatwas 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
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.
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
Kann ich den hm uart an einen linux pc anschließen?
Nutzt du keinen Raspberry?
Ich glaube dann nicht.
Zitat von: nccfast am 17 Januar 2017, 20:30:19
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
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, ...)
ZitatHä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.
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
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
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
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)
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?
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
nicht nach dem zweiten peeren, sondern nach dem zweiten pairen ....
Bei mir nach dem peeren.
Komisch.
Greets
Byte
Beide Vorgänge (pairen und peeren) lösen Datenübertragung aus. Wahrscheinlich hätte getConfig auch gereicht.
Gruß Otto
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?
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?
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
Zitat 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)
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
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
:-) :-)
Zitat von: Christian Uhlmann am 24 Januar 2017, 18:10:51
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
Hallo Christian,
nur als Idee, die Spinne will in ihr Haus zurück?
Wenn das nicht ist, dann würde ich reklamieren.
Gruß Otto
Zitat von: nccfast am 21 Januar 2017, 08:17:28
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
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?
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
Zitat von: Otto123 am 03 Februar 2017, 22:07:19
...
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].
Die ID steht beim HM Device im DEF.
Und wir reden davon
Zitatvirtueller 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
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 nichteinmal mehr den teamCall, oder auch den Alarm ausrufen können.
Zitat 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.
- 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?
ZitatDer 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
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!
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
Zitat von: RomanticBoy83 am 03 Februar 2017, 23:33:09Es 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.
Zitat von: MarcelK am 04 Februar 2017, 21:47:40
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
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.
Zitatattr 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.
Du findest die Anleitung im Wiki ist anders?
https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder#virtueller_TeamLead
Gruß Otto
Zitat von: MarcelK am 04 Februar 2017, 21:47:40
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...
Zitat von: friesenjung am 11 Februar 2017, 22:44:17Nun 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.
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?
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
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?
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
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.
Zitat 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
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. ;)
Zitat 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.
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
Zitat von: pc1246 am 09 April 2017, 13:04:01
Was sind denn bitte Bosch-SD2? Ich finde FERION 5000 OW
Genau diese.
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.
Hi,
definitiv nicht "normal" zumindest meldet er das bei mir nicht.
Zeig mal ein list RM.TeamDev
Meiner hat nur vier readings.
Gruß Otto
Zitat von: Otto123 am 11 April 2017, 21:31:02
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
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
lösch mal die attribute autoreadreg und expert.
dann ein set clear readings.
anschliessend erneut hminfo configcheck. eventuell davor noch ein set hminfo update.
Zitat 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.
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.
Zitat 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
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?
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.
Mich würde interessieren, wie ihr die Daten eurer Rauchmelder darstellt.
ReadingsGroup, readingsProxy, Floorplan...?
Ein Screenshot zur Inspiration wäre super ;)
Ist es eigentlich möglich über FHEM den Alarm bei einem bestimmten Rauchmelder in einem Team auszulösen?
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
ok, und ist es möglich bestimmte Rauchmelder im Team stumm zu schalten - also dass diese nicht laut pfeifen sondern nur die restlichen teammitglieder?
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 ... :'(
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 :) )
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
Wir hatten neulich auch einen Fehlalarm von einem defekten RM im Arbeitszimmer. Kinder haben einfach weiter gepennt 1 & 3 Jahre alt.
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
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
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
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
Ok, nochmal zum Status Quo:
- Peering innerhalb von fhem klappt nicht. Ich habe die Rauchmelder jetzt erst miteinander gepeered und dann mit der fhem vccu gepaired.
- Die Rauchmelder an sich funktionieren: Tests über den Knopf (Alarmtest, Kommunikationstest in der Gruppe) klappen.
- In fhem scheinen die Rauchmelder richtig angelegt zu sein. Jedenfalls sehen die Readings für mich ok aus, auch die Peer-Einträge sehen für mich gut aus. hminfo configCheck zeigt auch keine Fehler.
- statusRequest aus fhem heraus scheint zu funktionieren.
Zitat von: pc1246 am 16 September 2017, 18:23:57
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
Zitat von: Motivierte linke Hände am 17 September 2017, 11:08:46
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.
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
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
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
Ich habe nochmal eine Frage zum "virtuellen Teamlead" gemäß Wiki.
Dort steht
ZitatBitte 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_TeamB: HMID für Teamleaddefine TeamDev CUL_HM 111111
set TeamDev virtual 1
rename TeamDev_Btn1 Rauchmelder_Team2. 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
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.
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
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
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
Hallo Totti,
für den SD-2 brauchst Du libcrypt-rijndael-perl - hast Duinstalliert?
Gruß Otto
Zitat von: Otto123 am 12 November 2017, 20:19:03
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
mach uns doch mal ein list von dem SD2
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
das pairing sollte mal gut sein...
mach mal noch ein list von Rauchmelder_Team
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
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.
Guten Morgen,
mal eine kurze Zwischenfrage:
Gibt es eine Möglichkeit, nur das Orientierungslicht am RM ein zu schalten?
LG
Marlen
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
Hi,
nein ich dachte, man könnte das Licht bei Stromausfall nutzen.
LG
Marlen
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!
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.
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:
ZitatWartungsarm durch fest eingebaute Lithium-Batterie (3 V), Batterielebensdauer ca. 10 Jahre
Viel Spaß beim Löten! ;D
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)
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 ...
Warum?
Was hast denn gegen die neuen?
Welche hast du dann?
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.
Bei meinen Meldern ist heute der Alarm angegangen, wo kann man sehen von welchem Melder dieser ausgegangen ist?
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.
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?
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.
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
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.
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.
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
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
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
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.
Es ist ein Rauchmelder als Teamleader. Ein virtueller hätte eine 8 stellige HMID.
Gruß Otto
Das ist einfach nur das ganz normale aneinander anlernen ohne FHEM. So steht es in der Bedienungsanleitung.
Zitat6.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.
... 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 :
Moin Micha
Wieso Tonne, der ist doch noch gar nicht so alt. Und eq3 kann ruhig mal bluten!
Gruss Christoph
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
@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...
ZitatUnd das kann keinesfalls ein Reichweitenproblemen sein, denn umzu -50dbi ist ein einwandfreier Wert...
Zitatrssi_at_UFO1 cnt:5 lst:-104 avg:-99 min:-104 max:-96
ZitatIODev 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 :-*
... 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 IO
Wie 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 ...
Zitat von: M_I_B am 17 Dezember 2017, 13:41:43
... 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
... 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
attr iogrp ist falsch. der zweite doppelpunkt muss ein komma sein.
Datenübertragung bei Homematic braucht etwas Zeit und Geduld ;D
Zitat von: frank am 17 Dezember 2017, 14:29:03attr 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 ???
Zitat von: Otto123 am 17 Dezember 2017, 14:43:32Datenü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 ::)
Zitat 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...
...
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
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
Hi!
Zitat von: dokle am 30 Dezember 2017, 06:43:23
...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
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.
Zumindest steht folgendes im Wiki:
ZitatBei 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.
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)
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
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.
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
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
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
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
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
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
Vielen Dank für die ausführlichen Erklärungen, Namensvetter ;-)
zu Punkt 3.)
ich bin aktuell einfach unsicher was ich machen soll (alles über CUL oder doch zusätzliches HM-MOD-RPI-PCB).
Die RM sind eigentlich mein Homematic-"Pilot", habe evtl. vor noch weitere HM Komponenten in FHEM einzubinden und möchte dabei herausfinden
ob alles so tut wie es soll. aktuell fällt es mir als Newbie extrem schwer einzuschätzen, ob jetzt alles so tut wie es soll.
Wann hast du denn für dich entschieden, dass die Anbindung der RM passt? wenn ein Test-Alarm korrekt ankommt im FHEM?
... also aus meiner Erfahrung sind die RM von Haus aus zickig. Ich will mich aber auch nicht so weit aus dem Fenster lehnen, da ich mich auch noch zu den Anfängern zähle. Aber eines ist gewiss: Einen einzigen Transceiver für verschieden Protokolle und zudem auf verschiedenen Frequenzbereichen zu nutzen, ist eine doofe Idee... Zum einen empfängt der ja i.d.R. nur das Protokoll, auf das er im Define festgelegt wurde, zum anderen sind die Antennen von CUL & Co nicht dafür ausgelegt, auf 433MHz UND 868MHz zu arbeiten. Das geht zwar, wenn man die Antennen selber baut (1/4 Lambda Groundplane für 433MHz passt fast genau als 1/2 Lambda für 868MHZ), aber nur dann.
Ich habe hier 3 SCC (IT=433, HM=868, MAX=868) und zusätzlich noch ein HM-LAN-Gateway (das alte "UFO"). Und obwohl hier alles sauber nach Frequenzen und Proto getrennt ist, tauchen noch genug "Merkwürdigkeiten" auf.
... aber das ist nur meine unmaßgebliche Einschätzung ...
Zitat von: MCh76 am 17 Januar 2018, 11:32:17
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?
Hallo Chris,
ich glaube das andere ist alles beantwortet.
Der TeamDev Lead muss die Nummer 01 haben!!! Also wenn Du mehrere haben willst musst Du noch einen TeamDev anlegen, Btn2 geht nicht!
Gruß Otto
Zitat von: M_I_B am 17 Januar 2018, 15:00:54
... also aus meiner Erfahrung sind die RM von Haus aus zickig. Ich will mich aber auch nicht so weit aus dem Fenster lehnen, da ich mich auch noch zu den Anfängern zähle. Aber eines ist gewiss: Einen einzigen Transceiver für verschieden Protokolle und zudem auf verschiedenen Frequenzbereichen zu nutzen, ist eine doofe Idee... Zum einen empfängt der ja i.d.R. nur das Protokoll, auf das er im Define festgelegt wurde, zum anderen sind die Antennen von CUL & Co nicht dafür ausgelegt, auf 433MHz UND 868MHz zu arbeiten. Das geht zwar, wenn man die Antennen selber baut (1/4 Lambda Groundplane für 433MHz passt fast genau als 1/2 Lambda für 868MHZ), aber nur dann.
Ich habe hier 3 SCC (IT=433, HM=868, MAX=868) und zusätzlich noch ein HM-LAN-Gateway (das alte "UFO"). Und obwohl hier alles sauber nach Frequenzen und Proto getrennt ist, tauchen noch genug "Merkwürdigkeiten" auf.
... aber das ist nur meine unmaßgebliche Einschätzung ...
vielen Dank für die Infos Micha.
Wie hast du denn deine 3 SCC hardwaretechnisch verteilt? gerade bei allem was extern vom Raspi ist (wie bei Wemos-D1 oder NodeMCU) frage ich mich auch immer, wo das an sinnvollsten über die Wohnung/Haus hinweg platziert wird, in welchem Gehäuse untergebracht und über welche Quelle die USB-Stromversorgung erfolgt. Bin hier am Ideen sammeln.
... die drei SCC's sitzen alle auf einem alten PI2, der lediglich eine Minimalversion von Debian Lite drauf hat. Der hat nis weiter zu tun, als per WLAN die Kommandos von meiner FHEM Hauptinstanz entgegenzunehmen, es über den entsprechenden SCC in die Welt zu funken und natürlich den umgekehrten Weg zu verarbeiten. Fhem läuft bei mir also nicht auf dem System, welches auch den Funk macht...
Technisch hängt der recht zentral im Hausflur. Die SCC sind allerdings modifiziert und haben U.FL Buchsen erhalten, um per PigTail Antennen absetzen zu können. Ist noch nicht ganz WAF- Konform, aber ich arbeite daran ;)
Stromversorgung erfolgt aus einer Abzweigdose; da passte noch ein entkerntes SmartPhone, Steckernetzteil rein. Soll aber mal PoE werden ...
Hallo zusammen,
hier auch mal meine Erfahrung bzgl. CUL vs. HM-MOD-RPI-PCB in Verbindung mit SD2.
Also ich kann nur raten sich vom CUL zu verabschieden (jedenfalls im Hinblick auf HM). Ich hatte einen nanoCUL (selbstbau), der auch (für mein anfängliches Empfinden) sehr gut lief.
Die SD2 (habe 9 Stück) hatte ich noch am CUL in Betrieb genommen. Ich habs auch irgendwie hinbekommen, aber ich hatte immer das Problem, dass die Zeit der Kommunikation während des Anlernens zwischen CUL und SD2 zu kurz schien. Also: Pairing gestartet > kurze Zeit später hörte der SD2 auf zu blinken, in Fhem hingen aber noch Befehle fest. Also die Pairing-Taste am SD2 ein weiteres mal drücken und dann wurden die restlichen Befehle abgearbeitet. Es kam auch vor, dass ich ein 3. mal die Pairingtaste am SD2 drücken musste.
OK, irgendwann hatte ich alle SDs sauber drin, aber die Kommunikation schien mir hin und wieder nicht sauber zu sein (wohl eine Auswirkung des timing-Problems).
Irgendwann bin ich auf die Variante HM-MOD-RPI-PCB gestoßen. Den kann man ja vielfach verwenden - direkt am Raspi, an USB löten oder als WLAN-Gateway mit nem WeMos. Einfach flexibel. Preislich kann das allemal mit meinem selbstbau-NanoCUL mithalten.
Das beste an der Sache ist aber, dass die HM-MOD Lösungen bestens läuft, was die Kommunikation anbelangt und obendrein war es bei mir so, dass auch die Funkreichweite deutlich gestiegen ist. Für mich war das die beste Entscheidung.
BTW: mit den SD2 sich in die Homatic-Materie einzuarbeiten ist schon hart. Ich habe mit nem Türkontakt angefangen...
VG...
Zitat von: friesenjung am 17 Januar 2018, 16:24:34... als WLAN-Gateway mit nem WeMos.
Zwichenfrage: WeMOS mit ESPeasy geflasht und dann per 232TTL dran oder wie? Gibt es dazu was zu lesen?
Zitat von: M_I_B am 17 Januar 2018, 16:28:40
Zwichenfrage: WeMOS mit ESPeasy geflasht und dann per 232TTL dran oder wie? Gibt es dazu was zu lesen?
klar, schau mal:
so bin ich drauf gekommen...
https://forum.fhem.de/index.php/topic,69042.0.html
bzw.
https://forum.fhem.de/index.php?topic=70564.0
Im Anhang noch ein Bildchen (was aus dem ersten Thread stammt)
VG...
Update: zweiter Link war falsch
Zitat von: M_I_B am 17 Januar 2018, 16:28:40
Zwichenfrage: WeMOS mit ESPeasy geflasht und dann per 232TTL dran oder wie? Gibt es dazu was zu lesen?
friesenjung hat schon alles beantwortet. Aber die Reichweite von dem ding ist unglaublich! Bei mir draengelt der sich sehr gerne vom Dachboden aus vor, um im Keller zu empfangen, und unterwegs ist noch ein USB-2 im EG! Und die vier Draehte an den Wemos bekommt jeder hin!
Gruss Christoph
Zitat von: pc1246 am 17 Januar 2018, 21:44:49
... Aber die Reichweite von dem ding ist unglaublich! ...
Das kann ich nur bestätigen. Ich wollte für div. Aktoren/Sensoren im Außenbereich, die der CUL nie erreicht hat, schon einen weiteren bauen und mit nem 2. Raspi an weiterem Standpunkt platzieren. Mit dem HM-MOD-RPI-PCB erreiche ich nun alle bis in den Außenbereich mit RSSi <80!
Gerade bei den SD2 hat man genug "um die Ohren". Da paired es sich beruhigter, wenn man weiß, dass das IO-Device keine Probleme macht...
Mit den Erfahrungsberichten und dem Mutmacher ,,bekommt jeder hin" bin ich nun überzeugt das basteln zu wagen. Leider finde ich die verlinkten Threads zu dem Thema sehr unübersichtlich, gerade in dem Platinenbestell-Thread ist alles verwirrend. Gibt es irgendwo eine für Anfänger verständliche Schritt für Schrittanleitumg für den Zusammenbau des HM-Mod-RPI-PCB / Wemos, das anschließende Flashen und Anlernen im FHEM?
Wenn ich das bisher gelesene richtig verstehe müsse fas HM Modul mit diesem Bauteil verbunden werden oder?
https://paradisetronic.com/de/nodemcu/nodemcu-dev-kit-esp8266-wlan-aktuellem-lua-interpreter
Zitat von: M_I_B am 17 Januar 2018, 16:28:40
Zwichenfrage: WeMOS mit ESPeasy geflasht und dann per 232TTL dran oder wie? Gibt es dazu was zu lesen?
Ich habe das mit ESP-Link am Laufen, war irgendwie einfacher als mit ESPeasy. Aber sicher hat sich die Software da auch weiter gedreht.
Und wenn das Wlan nicht gerade von einer Amoklaufenden Fritzbox kommt, läuft das super stabil.
Gruß Otto
Zitat von: Otto123 am 18 Januar 2018, 09:30:32... gerade von einer Amoklaufenden Fritzbox kommt ...
;D ;D ;D Was hast Du denn für Hardware da rumstehen? Meine FB's waren immer lieb zu mir ;)
Also ESPeasy in der aktuellen 2er Version ist m.E. ziemlich gut und sehr flexibel. Ich habe jetzt auf allen ESP's ESPeasy drauf und bin sehr zufrieden, das ich DAU damit um kann ;)
Bezgl. enorme Reichweite... Mit der okkinolen Drahtantenne? Echt? Dann sollte ja ne "richtige" Antenne erst recht Umkreis machen...
Ok, ich bin überzeugt! Das werde ich auch mal angehen und testen, so bald ich mal Zeit finde ...
Naja das wird jetzt OT. Die FB wechselt in der Standardeinstellung laufend den Funkkanal. Und ich behaupte sie tut das manchmal auch wenn man ihn fest einstellt. Dann musst Du mal bei einem Linux System ins syslog schauen was da abgeht. Der Treiber des Onboard Wlan des Pi 3 oder Pi Zero W kommt damit nicht zurecht und verabschiedet sich dann nach einem halben Tag. ESP-Link hatte damit regelmäßig Abbrüche (mehrmals täglich).
Jetzt steht da erst einmal eine olle Easybox umgeflasht mit OpenWrt da und alles läuft entspannt. Die FB wird gerade zum DSL Modem und Telefonanlage zurück gebaut.
OT aus
Es war doch aber so, dass der Serial Server in ESP Easy nicht für diese Anbindung tauglich war und man extra eine Version kompilieren musste?! Ist das nicht mehr so und geht jetzt OutOfTheBox?
Gruß Otto
[OT] Also meine 7580 wechselt den Kanal des öfteren, aber ich habe weder mit den PI's (2er und 3er) noch mit den inzwischen in Betrieb befindlichen WeMOS damit irgend welche Probleme bemerken können; komisch das Du damit Probleme hast...[/OT]
Zitatdass der Serial Server in ESP Easy nicht für diese Anbindung tauglich war
Das kann ich Dir (noch nicht) sagen. An einem WeMOS mit ESPeasy habe ich aktuell meine Wechselrichter per RS485 dran. Das zumindest funktioniert problemlos. Wie sich das aber mit den eQ3- Transceivern verhält, muss ich erst mal heraus finden. Aber da in den hier kursierenden Anleitungen auch diese Option dargestellt ist, gehe ich mal davon aus, das es so tut wie erwartet...
Zitat von: MCh76 am 18 Januar 2018, 09:19:10
Mit den Erfahrungsberichten und dem Mutmacher ,,bekommt jeder hin" bin ich nun überzeugt das basteln zu wagen. Leider finde ich die verlinkten Threads zu dem Thema sehr unübersichtlich, gerade in dem Platinenbestell-Thread ist alles verwirrend. Gibt es irgendwo eine für Anfänger verständliche Schritt für Schrittanleitumg für den Zusammenbau des HM-Mod-RPI-PCB / Wemos, das anschließende Flashen und Anlernen im FHEM?
Wenn ich das bisher gelesene richtig verstehe müsse fas HM Modul mit diesem Bauteil verbunden werden oder?
https://paradisetronic.com/de/nodemcu/nodemcu-dev-kit-esp8266-wlan-aktuellem-lua-interpreter
Hallo Chris
Ein Wemos, ein HM-Mod-RPI-PCB vier Draehte und ein USB-Netzteil. Platine ist Luxus! Gibt es aber.
Hier mal ein paar ausgewaehlte links:
https://forum.fhem.de/index.php/topic,69042.msg605241.html#msg605241
https://forum.fhem.de/index.php/topic,56606.msg481618.html#msg481618
http://heinz-otto.blogspot.fr/2016/07/raspberry-pi-homematic-modul.html
In dem zweiten ist eine Anleitung verlinkt, mit der sogar deine Oma das hinbekommt! ;)
Gruss Christoph
... ok ... Die Sache ist erst mal hinten an gestellt >:( Der HM-MOD-RPI-PCB ist derzeit nirgendwo lieferbar; typisch eQ3/ELV ...
die verfügbarbarkeit bei elv kann sich aber auch binnen minuten von "lieferbar in 12 wochen" auf "auf lager, sofort lieferbar" ändern.
Zitat von: M_I_B am 18 Januar 2018, 11:42:52
... ok ... Die Sache ist erst mal hinten an gestellt >:( Der HM-MOD-RPI-PCB ist derzeit nirgendwo lieferbar; typisch eQ3/ELV ...
Du kaufst doch da gar nicht mehr!?
... stimmt, direkt bei ELV kaufe ich nie wieder, aber auch andere Quellen haben im Moment nichts ...
Zitat von: pc1246 am 18 Januar 2018, 11:16:03
Hallo Chris
Ein Wemos, ein HM-Mod-RPI-PCB vier Draehte und ein USB-Netzteil. Platine ist Luxus! Gibt es aber.
Hier mal ein paar ausgewaehlte links:
https://forum.fhem.de/index.php/topic,69042.msg605241.html#msg605241
https://forum.fhem.de/index.php/topic,56606.msg481618.html#msg481618
http://heinz-otto.blogspot.fr/2016/07/raspberry-pi-homematic-modul.html
In dem zweiten ist eine Anleitung verlinkt, mit der sogar deine Oma das hinbekommt! ;)
Gruss Christoph
nochmals vielen lieben dank! jetzt war ich so motiviert und dann ist das HM modul leider ausverkauft.
bzgl. des flashens noch ne frage: ist es egal für die spätere verwendung im fhem von welchem system (windows oder linux) das aufspielen der firmware erfolgt?
Hallo
Das ist voellig egal, wie soll das auch einen Unterschied machen?
Mit dem Modul ist bloed! Evtl. finden sich ja ein paar Leute, die das leihweise tauschen. Sprich jemand hat ein paar gehortet, und kann die 16 Wochen gut ueberleben? Dann kaemen nur zusaetzliche Versandkosten dazu.
Ich habe nur mein eines, wollte aber letztens schon mal eins auf Reserve kaufen!
Gruss Christoph
Ich sehe gerade dass das Modul bei ELV wieder bestellbar ist.
... na, dann wird es hoffentlich bald auch bei den anderen Anbietern wieder auftauchen... Danke für die Info
Zitat von: MCh76 am 22 Januar 2018, 12:12:38
Ich sehe gerade dass das Modul bei ELV wieder bestellbar ist.
Na dann nix wie los!
Danke und Gruss Christoph
Das Thema rückt immer weiter von den Rauchmeldern ab... Dennoch: Hat dieses Modul im Hinblick auf die Kernfunktionalität (also nicht Preis, Bastelspaß, ...) einen Vorteil gegenüber den aktuellen LAN-Gateways?
Naja
Ist halt ein HMUARTLGW auf WLAN-Basis!
Aber jetzt genug OT! Dazu gibt es genug threads!
Gruss Christoph
Guten Morgen.
ich hab ne Verständnisfrage ;)
Die SD2 sollen sich laut Wiki ja alle paar Tage melden. Tun Sie auch.
Wenn ich aber nun, zB. nach einem Update, Fhem neu starte, wird an alle HM-Devices ein "statusRequest" gesendet.
1. Frage: bei mir melden sich die SD2 innerhalb "sofort bis ca. ne Stunde". Ich dachte man kann sie nur durch ein "Burst" aufwecken. Dann müsste es aber hin und wieder mal mehr als ein Tag dauern bis ich eine Antwort bekomme, oder?
2. das geht ja auch auf die Batterie. Sollte man die SD2 nicht bei so einem "statusRequest" durch Neustart außen vor lassen, um die Batterie zu schonen? Wenn ja, kann das ein "normaler User" einstellen?
was meint Ihr?
VG...
... also das mit dem Neustart ist mir noch gar nicht aufgefallen, daher kann ich zumindest dazu nix sagen ...
Was den Batterieverbrauch betrifft aber schon... Die 10 Jahre sind m.E. utopisch. Nach meinen Langzeitmessungen an einem SD dürften die Batterien (es sind zwei verbaut) in spätestens 7 Jahren platt sein, eher früher. Das mag natürlich stark streuen, aber so in etwa.
Ist aber im Grunde nicht wirklich ein Problem. Die Batterien lassen sich recht einfach austauschen (gelötet) und sind auch z.Z. bei den üblich Verdächtigen zu erhalten. Wer natürlich die Zertifizierung erhalten will, muss dann die im Grunde einwandfreien RM in die Tonne hauen und neue kaufen ...
mit attr autoreadreg lässt sich das abschalten.
damit es zb kein overload gibt, werden die devices verzögert angesprochen und die aktuelle load muss unter dem batchlevel liegen.
Zitat von: frank am 23 Januar 2018, 09:49:36
mit attr autoreadreg lässt sich das abschalten.
damit es zb kein overload gibt, werden die devices verzögert angesprochen und die aktuelle load muss unter dem batchlevel liegen.
ah ok, danke für den Hinweis.
Hab das mal bei mir gecheckt und da stand autoreadreg schon auf 5. Trotzdem fordert er bei jedem Start den statusRequest. Laut commandRef sollte doch bei autoreadreg=5 nur ein update angefordert werden, wenn Registerlisten oder peerlisten nicht komplett sind. Sind sie bei mir aber.
Oder interpretiere ich das falsch? Laut commandref baut autoreadreg doch nur von 1-4 aufeinander auf!?
nach meiner erfahrung mindestens 1-5.
So, den ELV Bausatz zusammenlöten hab ich gepackt. Jetzt noch ne doofe Verständnisfrage bzgl. der Abbildung aus der guten Anleitung. Wie wird der Wemos am HM Modul angeschlossen? Sind das spezielle Jumperkabel in die Buchsen des HM oder Litzenkabel dranlöten? Diese Buchsen am HM Modul haben ja sicher ihren Sinn...
Danke für eine Info. VG, Chris
Moin MCh76
OT On
Ich hatte hier https://forum.fhem.de/index.php/topic,35298.msg751093.html#msg751093 schon mal ein paar links gepostet. Gleich der erste erklaert alles, hier speziell https://forum.fhem.de/index.php?action=dlattach;topic=69042.0;attach=74300 . Welche Art von Verbindung Du herstellst, ist Dir ueberlassen!
Ansonsten bitte im passenden thread fragen, oder einen neuen aufmachen!
OT Off
Gruss Christoph
Grüß euch
Hätte ein paar allgemeine Fragen zum HM-SEC-SD-2.
1.) Habe schon einiges hier im Forum über ihn gelesen und eine Möglichkeit der "Stummschaltung" (wenn man wach und zu Hause ist) gibt es nicht? Vielleicht ein Firmware/Hardwarehack? (Risiko und VDSlosigkeit sind mir bewusst)
2.) Habe ihn gestern einmal beim Steakbraten getestet ( ;D ) , er ging auch ab und wollte nun wissen, wie lange er bei Rauchentwicklung herumlärmt? Bis der Rauch wieder weg ist, oder bis man ihn quitiert, eine gewisse Dauer...?
3.) Wenn Rauch in der Kammer ist und man sendet ein: "alarmOff" wirkt es dann überhaupt?
4.) Wenn es wirkt... wie lange hält die Wirkung, bis er wieder von vorne anfängt, oder gibt er dann ne Ruhe?
5.) Gibt es generell eine Minimalklingeldauer wenn er selbst auslöst bis man den Alarm quittieren kann?
6.) Gibt es eine Minimalklingeldauer, wenn man ein "alarmOn" rausschickt?
Vielen Dank schon einmal.
Hi,
ich habe die SD (nicht SD-2) und kann deren Verhalten bei Rauch verbal (aus der Erinnerung) beschreiben:
Er meldet Rauch, mit der Verzögerung von einer "Alarm Salve" reagieren meine beiden anderen RM.
Dann suche ich schnell den Stock und drücke den Knopf (was beim SD ein künstlerischer Akt ist)
Dann geht er (ich würde sagen am Ende der Salve) aus.
Dann gehen die anderen wieder mit der Verzögerung einer Alarmsalve aus.
Wenn man jetzt das Glück hat und der Rauch ist aus der Kammer raus (gewedelt) bleibt er aus. Ist noch Rauch in der Kammer oder strömt er nach, geht er wieder an und das Spiel beginnt von vorn.
Ob man in dem Momemt irgendetwas von FHEM senden kann, habe ich mir nicht getraut. In dem Fall war immer handeln und nicht am Computer spielen angesagt.
Meines Wissen gibt es immer so eine Art Salve, gemessen habe ich die Zeit nicht.
Hier habe ich mal einen echten Alarm als Log gepostet. Der war minimal kurz, ich war in unmittelbarer Nähe.
Gruß Otto
Hallo Otto
Danke für die Info. Da ich meinen inzwischen aufgehängt habe und kein "Rauchspray" zum Testen hab, kann ich es leider nicht selbst testen. Vielleicht tut sich ja jemand die Arbeit an, oder weiß es.
Grund meiner Frage ist der, dass ich, wenn ich das Gerät schon nicht "muten" kann, es zumin. sofern ich zu Hause bin und es Tag ist, möglichst schnell automatisch abbrechen möchte. Oder hat inzwischen schon jemand ne "Mute"-Lösung.
Lg
ZitatDann suche ich schnell den Stock
Fernbedienung.
Mein Tipp: Die Rauchmelder sind bei mir mittels Alarm-Modul als Aktoren der Alarmanlage definiert. Sie gehen auch bei anderen echten Gefahrensituationen an, wenn z.B. irgendwo ein Wassereinbruch stattfindet (wir haben da so eine Kellertür, und bei Starkregen kam das auch schon mal im Sommer vor). Gleichzeitig gibt es einen anderen (virtuellen) Aktor, der nach spätestens 30 Sekunden diesen Alarm wieder cancelt. Und natürlich einen bestimmten Lichtschalter, der nach Betätigung auch den Alarm wieder stoppt - worst case also nach 2 "Salven".
Das kann man auch ohne Alarm-Modul realisieren, allerdings weniger komfortabel.
LG
pah
Alarm off sollte einfach per alarmoff vom teamlead gehen. Geht über ein notify von jedem event getriggert.
Der echte rauchalarm lässt sich nur temporär abschalten. Erst wenn Rauch weg oder bat alle ist, ist Schluss.
Manuell getriggerte alarme, auch vom alarmhändler, lassen sich auch manuell abschalten.
Ein einfaches räucherstäbchen sollte auch zum testen reichen, wenn keine zigarre zur Hand.
Könnt ihr mir mal kurz helfen. Seit einigen Wochen ist der Rauchmelder stumm. Wenn ich ihm ein "set smo00 alamOn" rausschicke und warte bis ich "CMD's done" bekomme, empfängt er es scheinbar, beginnt aber nicht zu plärren.
2018-04-25_00:14:06 smo00 aesCBCCounter: 000094
2018-04-25_00:14:15 smo00 aesCBCCounter: 000095
2018-04-25_00:14:15 smo00 eventNo: 02
2018-04-25_00:14:15 smo00 level: 198
2018-04-25_00:14:15 smo00 smoke_detect: -
2018-04-25_00:14:15 smo00 smoke-Alarm_02
2018-04-25_00:14:48 smo00 Activity: alive
2018-04-25_00:14:59 smo00 alarmTest: ok
2018-04-25_00:14:59 smo00 battery: ok
2018-04-25_00:14:59 smo00 eventNo: 01
2018-04-25_00:14:59 smo00 level: 0
2018-04-25_00:14:59 smo00 smokeChamber: ok
2018-04-25_00:14:59 smo00 smoke_detect: none
2018-04-25_00:14:59 smo00 off
2018-04-25_00:15:22 smo00 aesCBCCounter: 000096
2018-04-25_00:15:30 smo00 aesCBCCounter: 000097
2018-04-25_00:15:30 smo00 eventNo: 02
2018-04-25_00:15:30 smo00 level: 198
2018-04-25_00:15:30 smo00 smoke_detect: -
2018-04-25_00:15:30 smo00 smoke-Alarm_02
2018-04-25_00:15:33 smo00 eventNo: 03
2018-04-25_00:15:33 smo00 level: 0
2018-04-25_00:15:33 smo00 smoke_detect: none
2018-04-25_00:15:33 smo00 off
Internals:
DEF 4BAA74
IODev scc00
LASTInputDev scc00
MSGCNT 1
NAME smo00
NOTIFYDEV global
NR 284
STATE smoke-Alarm_04
TESTNR 4
TYPE CUL_HM
lastMsg No:3F - t:10 s:4BAA74 d:000001 0601000024
peerList self01,
protLastRcv 2018-04-25 00:14:59
protResnd 1 last_at:2018-04-25 00:14:57
protSnd 20 last_at:2018-04-25 00:18:21
protState CMDs_done
rssi_at_scc00 cnt:1 min:-44.5 max:-44.5 avg:-44.5 lst:-44.5
scc00_MSGCNT 1
scc00_RAWMSG A0E3FA6104BAA740000010601000024::-44.5:scc00:
scc00_RSSI -44.5
scc00_TIME 2018-04-25 00:14:59
sdTeam sdLead
READINGS:
2018-04-25 00:14:48 Activity alive
2018-04-15 21:37:46 D-firmware 1.0
2018-04-15 21:37:46 D-serialNr NEQ0442322
2018-04-15 21:35:19 PairedTo 0x000001
2018-04-14 15:28:24 R-pairCentral 0x000001
2018-04-15 21:35:19 RegL_00. 02:01 0A:00 0B:00 0C:01 16:00 1F:00 00:00
2018-04-25 00:18:20 aesCBCCounter 000098
2018-04-25 00:14:59 alarmTest ok
2018-04-25 00:14:59 battery ok
2018-04-25 00:18:31 eventNo 04
2018-04-25 00:18:31 level 198
2018-04-25 00:14:48 peerList self01,
2018-04-25 00:14:59 recentStateType info
2018-04-15 21:35:19 sdRepeat off
2018-04-25 00:14:59 smokeChamber ok
2018-04-25 00:18:31 smoke_detect -
2018-04-25 00:18:31 state smoke-Alarm_04
2018-04-15 21:35:59 teamCall from :0D
helper:
HM_CMDNR 152
cSnd ,010000014BAA74010E
fkt sdLead2
mId 00AA
regLst ,0
rxType 6
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
lstRecType 10
newChn +4BAA74,00,00,00
nextSend 1524608099.26771
nxtSndMcnt 3F
prefIO
restoredIO scc00
rxt 0
tgtDly 88
vccu
lRcTm:
scc00 689047280
tnms 968450927
p:
4BAA74
00
00
00
mRssi:
mNo 3F
io:
scc00:
-36.5
-36.5
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO scc00
flg A
ts 1524608099.1982
ack:
HASH(0x2fe0e78)
3F80020000014BAA7400
rssi:
at_scc00:
avg -44.5
cnt 1
lst -44.5
max -44.5
min -44.5
Attributes:
IODev scc00
actCycle 099:00
actStatus alive
alias Smoke Detector
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
group [Homematic] Smoke Detectors
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,4BAA7401,
room Sensors
serialNr NEQ0442322
subType smokeDetector
verbose 5
webCmd statusRequest
Ich tippe einmal auf irgendwas mit dem aesCBCCounter. Als es noch lief war ich bei:
2018-02-02_18:38:22 smo00 aesCBCCounter: 0002E1
2018-02-02_18:38:37 smo00 aesCBCCounter: 0002E2
2018-02-02_18:39:55 smo00 aesCBCCounter: 0002E3
2018-02-02_18:40:11 smo00 aesCBCCounter: 0002E4
Als es dann nicht mehr ging (bis dahin ohne meine Einwirkung (denke ich zumin.)), habe ich den Counter nach ner Anleitung manuell zurückgesetzt. Womöglich ist dort der Hund begraben.
hier sind ein paar hinweise zum aesCBCCounter
https://forum.fhem.de/index.php/topic,85444.msg782993.html#msg782993 (https://forum.fhem.de/index.php/topic,85444.msg782993.html#msg782993)
Hallo Frank
Genau das habe ich gemacht setreading TeamLead aesCBCCounter 000100, nachdem der Feuermelder das erste Mal keinen Ton mehr von sich gegeben hat. Ich weiß leider nicht mehr welchen Wert.
Ist mit Generationenzähler gemeint?
Die höchste Message die ich fand war: 0003A5
also: setreading TeamLead aesCBCCounter 0003AF damit ich >5 Inkremente Reserver in Hex gelassen habe, oder muss 0003A6 kommen?
lese noch mal genau nach.
genarationenzähler => 4 stellen von links.
ZitatDie höchste Message die ich fand war: 0003A5
ich hätte dann zuerst 000400 versucht. danach noch einen mehr 000500.
Danke schön, er schreit wieder.
Moin,
Anfängerfrage: Ich habe zwei SD-2 und einen virtuellen Teamlead. Peers scheinen i.O. zu sein. Teamlead set alarmOn setzt auch bei beiden SDs den alarm. Jedoch springt bei keinem von beiden eine Sirene an! Ist das Verhalten korrekt? Müssten nicht beide "heulen"? In der Anleitung steht level 200 bedeutet Alarmsirene an. Setzte ich den Teamlead auf alarmOn zeigen beide SDs level 198 !?
Wie kann mal also die Sirene testen?
Gruß, Hubi
ja, die Sirenen sollten heulen. Wenn nicht hast du ein Problem. Typisch ein AES problem.
Hier haben die Sirenen noch nicht bei einem Test geheult...? Ich meinte auch gelesen zu haben, dass das normal sei...?
Ich glaube hier ist der Begriff Test etwas verwirrend :)
Also beim TeamCall blinken die nur. Kein Ton
Wird AlarmOn gesetzt verhalten die Rauchmelder sich als wenn Rauch detektiert wurde. Also Ton.
Gruß
Also bei "AlarmOn" melden die Melder alle "Smoke", aber es piepst nicht einer.
Fehlermeldungen im Log habe ich keine. Wie sollte ich jetzt ein AES-Problem erkennen/fixen?
Sofern du Debian verwendest:
Bei mir fehlte das libcrypt-cbc-perl Paket.
https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder#Probleme_beim_SD-2
Zitat von: darkness am 08 Oktober 2018, 11:40:27
Sofern du Debian verwendest:
Bei mir fehlte das libcrypt-cbc-perl Paket.
https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder#Probleme_beim_SD-2
AES bei Homematic an sich funktioniert bei mir, und libcrypt-rijndael-perl ist installiert. Meintest Du das Paket? Das ist auch im Wiki erwähnt. libcrypt-cbc-perl hingegen ist in der Tat nicht installiert, aber auch nirgendwo zu Homematic erwähnt; lediglich in der commandref zu Broadlink finde ich einen Verweis auf das Paket...?
Wie gesagt, bisher hatte ich auch gedacht, die Rauchmelder funktionieren, da sie ja auf den Alarmtest reagieren, wenn auch nur mit einer Status-Änderung und nicht mit Piepen...
Wenn es raucht funktionieren die auch :) Nur halt manuell nicht. Wir hatten dazu mal was im Forum. Kann ich nachher mal schauen. Die Problematik ist aber im Link beschrieben.
libcrypt-cbc-perl meinte ich
Ok, die Rauchmelder melden sich bei AlarmOn im iPhone. Die interne Sirene funktioniert ebenfalls im manuellen Test wie in der Anleitung beschrieben. AES Probleme habe ich ebenfalls nicht. Ich gehe mal davon aus, dass alles so wie es ist i.O. ist ;) Danke für die Infos. Gruß, Hubi :D
Grüß euch
Ich habe ein kleines Problem mit meinem Rauchmelder. Er fungiert auch als Sirene/Alarmanlage. Jetzt ist es so, dass jedes Mal wenn ich ein "set smo00 alarmOn" absetze, weil der Alarm eines Fensterkontakts abgeht, auch mein notify für den Rauchalarm abgeht und ich finde den Fehler nicht.
define smo00_n0 notify smo00:.*smoke-Alarm.* {if(ReadingsVal("surve","smo00","") eq "armed") {fhem("set surve smo00 raised")}}
Habe es so aus dem Wiki. Wäre so vielleicht richtig(er):
define smo00_n0 notify smo00:smoke-Alarm.* {if(ReadingsVal("surve","smo00","") eq "armed") {fhem("set surve smo00 raised")}}
Keiner im Haus, deswegen mal getestet. Das passiert wenn ich am Rauchmelder_Team alarmOn drücke:
2020-02-06 10:04:14 CUL_HM RmAZ smoke_detect: TeamDev1
2020-02-06 10:04:14 CUL_HM RmAZ smoke-Alarm_0B
2020-02-06 10:04:14 CUL_HM RmFlur smoke_detect: TeamDev1
2020-02-06 10:04:14 CUL_HM RmFlur smoke-Alarm_0B
2020-02-06 10:04:14 CUL_HM RmSZ smoke_detect: TeamDev1
2020-02-06 10:04:14 CUL_HM RmSZ smoke-Alarm_0B
Dein notify triggert auf das Wort smoke-Alarm mittendrin (egal) damit kannst Du nicht vom normalen Alarm unterscheiden.
Alarm ist Alarm ;)
Du könntest auf smoke_detect: TeamDev1 triggern und das TeamDev1 aus deinem Smoke Alarm ausklammern-also nur die echten Melder einschließen.
Musst Du Dir selbst im Event Monitor anschauen, ich habe SD und keine SD2 - kann also da anders sein!
Gruß Otto
Meine Freundin liegt gerade blöderweise mit Fieber im Bett und ich möchte ihr das ersparen ;)
2018-02-12_23:34:03 smo00 smoke_detect: smo00
2018-02-12_23:34:03 smo00 smoke-Alarm_02
2018-02-12_23:34:03 smo00 trigLast: smo00:198
2018-02-12_23:34:03 smo00 trig_smo00: 198_2
2018-02-12_23:34:03 smo00 trigger_cnt: 2
2018-02-12_23:34:07 smo00 alarmTest: ok
2018-02-12_23:34:07 smo00 battery: ok
2018-02-12_23:34:07 smo00 level: 0
Bin mal 3 Jahre Logs durchwühlen gegangen. Könnte das ein Test von damals sein?! @Irgendjemand da draußen der den SD-2 hat :D (und am besten nur einen)
Habe es gerade mit alarmOn getestet:
READINGS:
2020-02-05 23:32:16 Activity alive
2018-04-15 21:37:46 D-firmware 1.0
2018-04-15 21:37:46 D-serialNr NEQ0442322
2018-10-14 05:16:01 PairedTo 0x000001
2018-04-14 15:28:24 R-pairCentral 0x000001
2018-10-14 05:16:01 RegL_00. 02:01 0A:00 0B:00 0C:01 16:00 1F:00 00:00
2020-02-07 23:02:53 aesCBCCounter 0004EE
2020-02-07 08:22:05 alarmTest ok
2020-02-07 08:22:05 battery ok
2020-02-07 23:02:58 eventNo 03
2020-02-07 23:02:58 level 198
2020-02-06 21:31:30 peerList self01,
2019-11-05 22:49:35 powerOn 2019-11-05 22:49:35
2020-02-07 08:22:05 recentStateType info
2018-10-14 05:16:01 sdRepeat off
2020-02-07 08:22:05 smokeChamber ok
2020-02-07 23:02:58 smoke_detect -
2020-02-07 23:02:58 state smoke-Alarm_03
2018-04-15 21:35:59 teamCall from :0D
2018-10-13 23:00:11 trigLast smo00:0
2018-10-13 23:00:11 trig_smo00 0_2
2018-10-13 23:00:11 trigger_cnt 2
Erklärt zumindestens einmal warum ich die Meldung bekam. Der Käse ist, dass ich auf "state" nicht triggern kann, also muss ich mir was anderes suchen. smokeChamber, smoke_detect? Irgendwer damit Erfahrung/Was da dann kommt?
Mein nächstes Problem: Der Alarm war lautlos. Also wieder Tipp von Frank und aesCBCCounter von 0004xx auf 0005xx und dann auf 000600 erhöht. Keine Veränderung.
Internals:
DEF 4BAA74
FUUID 5e348e96-f33f-bd58-3790-5c49c3d5564b2896
IODev scc00
LASTInputDev scc00
MSGCNT 2
NAME smo00
NOTIFYDEV global
NR 287
STATE smoke-Alarm_08
TESTNR 9
TYPE CUL_HM
chanNo 01
lastMsg No:1F - t:10 s:4BAA74 d:000001 06010000
peerList self01,
protLastRcv 2020-02-07 08:22:05
protRcv 2 last_at:2020-02-07 08:22:05
protSnd 51 last_at:2020-02-07 23:22:12
protSndB 49 last_at:2020-02-07 23:22:12
protState CMDs_done
rssi_at_scc00 cnt:2 min:-67 max:-62.5 avg:-64.75 lst:-62.5
rssi_scc00 cnt:1 min:-66 max:-66 avg:-66 lst:-66
scc00_MSGCNT 2
scc00_RAWMSG A0D1FA6104BAA7400000106010000::-62.5:scc00:
scc00_RSSI -62.5
scc00_TIME 2020-02-07 08:22:05
sdTeam sdLead
READINGS:
2020-02-05 23:32:16 Activity alive
2018-04-15 21:37:46 D-firmware 1.0
2018-04-15 21:37:46 D-serialNr NEQ0442322
2018-10-14 05:16:01 PairedTo 0x000001
2018-04-14 15:28:24 R-pairCentral 0x000001
2018-10-14 05:16:01 RegL_00. 02:01 0A:00 0B:00 0C:01 16:00 1F:00 00:00
2020-02-07 23:22:12 aesCBCCounter 0006F4
2020-02-07 08:22:05 alarmTest ok
2020-02-07 08:22:05 battery ok
2020-02-07 23:22:04 eventNo 08
2020-02-07 23:22:04 level 198
2020-02-06 21:31:30 peerList self01,
2019-11-05 22:49:35 powerOn 2019-11-05 22:49:35
2020-02-07 08:22:05 recentStateType info
2018-10-14 05:16:01 sdRepeat off
2020-02-07 08:22:05 smokeChamber ok
2020-02-07 23:22:04 smoke_detect -
2020-02-07 23:22:04 state smoke-Alarm_08
2018-04-15 21:35:59 teamCall from :0D
2018-10-13 23:00:11 trigLast smo00:0
2018-10-13 23:00:11 trig_smo00 0_2
2018-10-13 23:00:11 trigger_cnt 2
helper:
HM_CMDNR 244
cSnd ,010000014BAA74010E
fkt sdLead2
mId 00AA
peerFriend peerSD
peerOpt p:smokeDetector
regLst 0
rxType 6
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
lstRecType 10
newChn +4BAA74,00,00,00
nextSend 1581060125.88655
nxtSndMcnt 1F
prefIO
restoredIO scc00
rxt 0
tgtDly 88
vccu
lRcTm:
scc00 117909900
tnms 512160873
p:
4BAA74
00
00
00
mRssi:
mNo 1F
io:
scc00:
-58.5
-58.5
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO scc00
flg A
ts 1581060125.81725
ack:
HASH(0x39fd478)
1F80020000014BAA7400
rssi:
at_scc00:
avg -64.75
cnt 2
lst -62.5
max -62.5
min -67
scc00:
avg -66
cnt 1
lst -66
max -66
min -66
tmpl:
Attributes:
IODev scc00
actCycle 099:00
actStatus alive
alias Smoke Detector
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
group [Homematic] Smoke Detectors
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,4BAA7401,
room Sensors
serialNr NEQ0442322
subType smokeDetector
webCmd statusRequest
Da ich nur einen alleine verwende glaube ich dass das Peering stimmt. Sicher bin ich mir aber nicht. Danke für jede Hilfe.
Zitat von: theophilou85 am 07 Februar 2020, 23:28:54
Der Käse ist, dass ich auf "state" nicht triggern kann, also muss ich mir was anderes suchen.
Wer sagt das? Die Holländer? :)
2018-02-12_23:34:03 smo00 smoke-Alarm_02
Machst Du smo00:smoke-Alarm_.* oder?
Gruß Otto
Ich kann mich ja täuschen, aber wenn ich ein "alarmOn" rausschicke (was ich tu, wenn ein Fensterkontakt auslöst) UND wenn die SmokeChamber einen Alarm auslöst bekomme ich ein "smoke-Alarm_xx" als state. Sprich: Da kann ich keine Unterscheidung zwischen echtem Rauchalarm und dem Fensterkontakt machen. Aus dem Grund muss ich z.B auf die Rauchkammer triggern. Oder sehe ich das falsch? Gibt es da noch irgend ein Unterscheidungsmerkmal?
Ich habe Deine Aussage wahrscheinlich falsch verstanden: Du hast gesagt Du kannst auf state nicht triggern. Ich weiß nicht genau was Du damit meintest, aber dieser Event
2020-02-06 10:04:14 CUL_HM RmAZ smoke-Alarm_0B
Ist der state Event. Da steht nur (per default) bei keinem Gerät der Begriff state mit im Event.
Das Du es am Event nicht unterscheiden kannst habe ich ja schon gesagt, Du könntest es, wenn Du wie in meinem Beispiel, den Auslöser des Events mit einbeziehst. Da Du aber nur einen RM hast und den dummerweise mit sich selbst gepeert hast, wird das nicht gehen.
Du könntest einen virtuellen TeamLead einrichten, dann könntest Du es. Siehe mein Beispiel...
Vielleicht ist das auch genau der Sinn, dass man auch bei nur einem Rauchmelder einen virtuellen TeamLead einrichtet.
Gruß Otto
Erstmal danke für den Support.
Die Idee ihn mit sich selbst zu peeren, stammt aus dem Wiki: "Nutzt man nur einen SD sollte man diesen mit sich selbst peeren."
Gut, also auf "smoke detect" triggern:
define smo00_n0 notify smo00:smoke_detect:.smo00
Was meinst du?
Ich habe außerdem noch das Problem, dass ich trotz manuellem inkrementieren des aesCBCCounter von 0004xx auf 0006F4 keinen Ton mehr aus dem Gerät rausbekomme. Das Probleme hatte ich schon mal und es trat leider wieder auf und ich habe keine Ahnung weshalb.
Die Demokratie des Lesens :)
ZitatNutzt 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 bessere Struktur, da dieser virtuelle Aktor nicht verloren gehen kann.
Diese Idee wird nicht funktionieren, sagte ich ja schon.
ZitatGut, also auf "smoke detect" triggern:
Dein Teamlead hat den gleichen Namen wie der Melder selbst.
Oder hast Du da andere Erkenntnisse?
Mit dem aesCBCCounter kann ich Dir nicht helfen, ich habe keinen SD2. Außer ich meine gelesen zu haben man soll den Counter nur in kleinen (Einzel?) Schritten erhöhen?
Zitat von: theophilou85 am 13 Februar 2020, 22:38:59
Gut, also auf "smoke detect" triggern:
define smo00_n0 notify smo00:smoke_detect:.smo00
Wenn du dir einen virtuellen Teamlead gebaut hast kannst du auch das Beispiel aus dem Wiki abwandeln und auf deine Bedürfnisse anpassen
define sd.nf.report notify Rauchmelder_Team:.*smoke-Alarm.* {\
<Mail versenden>;;
fhem("set LichtTreppenhaus on");;
}\Alternativ dein Szenario durchspielen und den Eventmonitor mitlaufen lassen. Da kannst dir das Notify evt. raus ziehen.
Hallo zusammen,
ich habe im ganzen Haus insgesamt 8 Rauchmelder installiert und über ein virt. Team verknüpft. Das ganze funktioniert auch, wie der heutige(Fehl-) Alarm gezeigt hat. ;)
Meine Frage nun: Kann ich irgendwie auf die schnelle Erkennen welcher Rauchmelder die Ursache des Alarms war, z. B. in einer Email o. ä.?
Danke und viele Grüße
Volker
das sollte im Reading "smoke_detect" zu finden sein
im Teamlead
Ich habe auch einige HM-SEC-SD-2 sowie Bosch Ferion 5000OW bei mir am laufen, bisher ohne Fehlalarm. Ich wollte jetzt noch zwei nachrüsten, aber man bekommt aktuell nirgends Homematic-Modelle ohne IP. Kennt jemand eine Alternative? Ansonsten wäre wohl die Anschaffung einer Homematic IP Zentrale notwendig, diese in FHEM einbinden und dann halt Schritt für Schritt alle Homematic-Geräte und -Sensoren auf die Zentrale übertragen, oder?
auf die letzte Frage: Ja, also genauer eine CCU2 / CCU3 oder eine der Alternativen piVCCU, Raspberrymatic. Man kann auch die CUL_HM Welt weiter betreiben, nur sind es eben immer zwei Welten. Es gibt hier viele Threads zu dem Thema...
Zitat von: achim-e am 22 Januar 2023, 12:03:00
... Ich wollte jetzt noch zwei nachrüsten, aber man bekommt aktuell nirgends Homematic-Modelle ohne IP. Kennt jemand eine Alternative? ...
Moin achim-e,
ich habe gerade meine HM-Sec-SD-2 abgebaut und durch vernetzbare Ei Electronics-Geräte ersetzt. Die Homematic-Melder sind max. 5 Jahre alt. Falls du Interesse an gebrauchten Geräten hast, schreib mir eine PM.
VG Thomas
Ich habe meine insgesamt 6 HM-SEC-SD-2 schon seit Jahren in Betrieb, aber auch immer wieder Fehlalarme. 2-3 mal pro Jahr löst immer mal wieder ein anderer RM aus. Was mir aufgefallen ist:
- der Fehlalarm tritt immer nachts auf, meistens zwischen 4Uhr und 6Uhr
- der gemeldete Level ist immer 198 (d.h. != 200)
- die Rauchkammer ist blitzeblank
- manchmal geht der Alarm bereits wieder aus, bevor ich am RM angekommen bin
- der einzige RM der noch nie ausgelöst hat, ist im staubigen und zugigen Speicher. Direkt neben der Gastherme. :o
Für den level dachte ich bisher, dass nur Level 200 einen echten Alarm anzeigt. Ein Test mit einem Prüfspray brachte jetzt aber auch nur den Level 198. Kann das jemand bestätigen, dass es keinen Level über 198 gibt? Wäre auch wichtig für die, die auf level: 200 triggern, um eine Benachrichtigung auszulösen (so wie ich bisher ...)
Noch ein Hinweis: Ich hatte meine RM zunächst im Team, aber durch die Fehlalarme habe ich vor Jahren alle einzeln aufgesetzt. Der Krach im ganzen Haus war nicht auszuhalten.
Die RM plappern regelmäßig, alarmOn und alarmOff funktionieren. Einen Konfig-Fehler schließe daher eigentlich aus.
Jemand einen Tipp für mich? Sonst fliegen die Dinger schon vor den 10Jahren Batt-Life raus.
Nebenbei: Ich habe auch noch nicht vernetzte RM (Pyrexx und ABUS) – noch nie ein Fehlalarm.
Zitat von: MK am 14 Januar 2024, 11:48:43Für den level dachte ich bisher, dass nur Level 200 einen echten Alarm anzeigt. Ein Test mit einem Prüfspray brachte jetzt aber auch nur den Level 198. Kann das jemand bestätigen, dass es keinen Level über 198 gibt? Wäre auch wichtig für die, die auf level: 200 triggern, um eine Benachrichtigung auszulösen (so wie ich bisher ...)
das hat mich jetzt auch mal interessiert.
ich habe allerdings nur die älteren sec-sd. diese senden bei mir immer level=200, sowohl bei manuellem "set alarmOn", als auch beim auslösen durch rauch.
wenn ich im forum nach "level 200" suche, habe ich nur hinweise auf sec-sd gefunden.
eine suche nach "level 198" zeigte nur threads mit sec-sd-2.
scheint also "normal" zu sein.
Zitat von: MK am 14 Januar 2024, 11:48:43der Fehlalarm tritt immer nachts auf, meistens zwischen 4Uhr und 6Uhr
der lowbat alarm ist scheinbar auch immer nachts.
vielleicht meint der fw entwickler, dass dann die meisten bewohner anwesend sind. ;)
Zitat von: MK am 14 Januar 2024, 11:48:43der einzige RM der noch nie ausgelöst hat, ist im staubigen und zugigen Speicher. Direkt neben der Gastherme.
diesen rm hätte ich ja zb mal mit dem rm getauscht, der die meisten "fehlalarme" produziert.
haben alle die selbe fw?
Zitat von: MK am 14 Januar 2024, 11:48:43Die RM plappern regelmäßig, alarmOn und alarmOff funktionieren.
nutzt du alarmOn für deine automatisierung oder nur manuell zum testen?
Zitat von: MK am 14 Januar 2024, 11:48:43Ich hatte meine RM zunächst im Team, aber durch die Fehlalarme habe ich vor Jahren alle einzeln aufgesetzt.
ist nun jeder mit sich selbst gepeert, oder wie sieht es genau aus?
Hi frank,danke für deine Antowort / Beobachtungen!
Zitatwenn ich im forum nach "level 200" suche, habe ich nur hinweise auf sec-sd gefunden.
eine suche nach "level 198" zeigte nur threads mit sec-sd-2.
scheint also "normal" zu sein.
Ich habe es inzwischen auch mit einem Papierstreifen probiert, den ich in die Rauchkammer geschoben habe: level: 198. Ich triggere inzwischen auf
Smoke.*smoke_detect.* {
if($EVENT !~ m/none/) {Also level: 198 (beim SD-2) scheint bei echten Alarm normal zu sein, genauso wie bei einem über alarmOn.
Zitatdiesen rm hätte ich ja zb mal mit dem rm getauscht, der die meisten "fehlalarme" produziert.
haben alle die selbe fw?
Gute Idee, werde ich mal machen!
Firmware habe ich jetzt mal gecheckt, beim SD-2 scheint es aber nur die 1.0 zu geben.
Zitatnutzt du alarmOn für deine automatisierung oder nur manuell zum testen?
Ich wollte die RM auch als Signalgeber für die Alarmanlage nutzen, wie so einige hier im Forum. Habe ich aber dann doch nicht gemacht. Im Moment brauche ich es nur zum Testen.
Zitatist nun jeder mit sich selbst gepeert, oder wie sieht es genau aus?
Ja, richtig. Aber ich kann dir nicht mehr sagen, wie ich es gemacht habe. Zu lange her. War aber nach einer Anleitung irgendwo hier im Forum. Wenn du möchtest, würde ich mich mal auf die Suche machen.
Die Lösung bei mir ist jetzt eine kleine Fernbedienung im Schlafzimmer. Dann ist erstmal Ruhe und ich kann mich ohne Ohrenschutz auf die Suche nach dem auslösenden RM machen. Die Auslösung mit meinem Papierstreifen, konnte ich eh nicht deaktivieren, solange der Streifen noch in der Kammer war. Das wäre ja dann bei einem echten Brand auch OK!