HM-SEC-SD - 3 Rauchmelder im Netzwerk

[Groby]

Hallo Zusammen,

Da ich meine 3 Rauchmelder nicht via CUL_HM zu einem Netzwerktest motivieren konnte, habe ich mir noch ein HMLAN besorgt.  

folgendes Setup:
3 x HM-SEC-SD
1 x CUL_HM
1 x HMLAN

Alle 3 RM an mit CUL_HM gepaired und über den config Button in eine Gruppe aufgenommen. BatteryStatus usw. mit CUL kein Problem. Netzwerk Test Fehlanzeige, ausser über den Geräte-Button.

Also warten auf HMLAN, konfiguriert, AES aus. Alle RM nachträglich mit HMLAN gepaired. Gruppe bereits aufgesetzt ohne zusätzliche Konfiguration, sogar den Master richtig gewählt :) Ergo weiter im Test:

Master & Team mit IODev CUL_HM
Test via web GUI an Master
Ergebnis: keine Reaktion

Master IODev HMLAN / Team IODev CUL_HM
Test via web GUI an Master
Netzwerktest OK

Master & Team IODev HMLAN
test via web GUI und CUL_HM an Master
Ergebnis: wieder keine Reaktion
 
Hat Irgendjemand einen Tipp wie das richtig konfiguriert werden muss???

Muss ich etwa die Slave RM aus der CFG entfernen damit der Netzwerk Test usw. richtig funktioniert???

Danke & Gruss Groby

[martinp876]

Hi Groby,

was ist ein CUL_HM?
Du beschreibst einiges, auch mit CUL_HM (eine CUL in HM mode?). Lasse die doch erst einmal weg.

Dann (immer erste Aktion) nachsehen ob alles gepairt ist, RM mit FHEM/HMLAN:
set <rm> getConfig
-> anlernen
=> check pairedTo muss gleich HMID des HMLAN sein

Muss ich etwa die Slave RM aus der CFG entfernen damit der Netzwerk Test usw. richtig funktioniert???

welche CFG? fhem.cfg? nein.

Nach dem Auslesen solltest du die peers der RMs sehen. Alle sollten mir einer Master gepeert sein.
In FHEM hat sich als guenstig erwiesen, eine virtual entity zu definieren, die als master aggiert. Der Master-RM hat keine nachgewiesene Sonderaufgabe ausser die Bereitstellung seiner Adresse. Macht die Sache symetrischer, muss man aber nicht!

So, dann zum Problem: 'test' funktioniert nicht? schon lange her, dass wir des angesehen haben. Kannst du noch einmal logs schicken"

attr global verbose 1
attr mseclog 1
attr <hmlan> loglevel 1

dann eine "test" von GUI anstossen.

traces im Logfile schicken.

Gruss
Martin

[Groby]

Hallo Martin,

Schonmal vielen Dank für Deine Hilfe...

Ja Du liegst richtig, ich habe einen CUL im HomeMatic Betrieb - der underscore war natürlich irreführend - sorry.

Mit dem CUL habe ich die 3 Verbrecher mit fhem in Betrieb genommen. Der Hardwaretest über den Configbutton am Gerät lief auch - aber nicht mit dem CUL über die GUI bzw cmd line. Jedoch haben alle 3 RM mit dem CUL kommuniziert lt List RM und die HMID war die vom CUL...

Weil das allerdings nicht zufriedenstellend war, habe ich es noch mit dem HMLan probiert. Gestern war es dann soweit. HMLan angestöpselt, Windows Soft installiert und in der WinConfig mit HMLAN gepairt. Alle drei RM waren bereits in einer Gruppe und einem Master zugeordnet lt Win Soft.

Ich habe dann nur noch das IODev über attr auf HMLan geändert. Natürlich dummerweise nicht geprüft, ab das auch alle akzeptiert haben.

Ich werde mich nachher mal daran machen und die HMIDs prüfen und berichten.

Trotzdem schonmal Danke.
Gruss, Groby

[martinp876]

der SD arbeitet im burst mode. Das geht nur manchmal mit CUL. HMLAN schickt einen Burst (wakeup) und die SDs antworten. CUL und CUNO koennen das nicht, geht also nicht zuverlaessig.

Achte darauf, dass die CUL nichts sendet. Sollte so sein.. das timing wird etwas veraendert, das sowohl CUL alsauch HMLAN die Nachrichten Melden werden. schaun wir einmal:

Wenn du loggst will ich alle messages, die Verarbeitet werden. Also auch die der CUL:
attr cul loglevel 1

[Groby]

Hallo Martin,

gute Nachrichten. Es funktioniert!!!

Das einzige was ich geändert habe war für jeden <RM>:

Code Auswählen Erweitern


attr <RM> IODev <HMLAN>
set <RM> getConfig


Danach meldeten sich alle <RM> beim Test wie gewünscht - zumindest bei Verwendung des HMLAN. Somit hat meine manuelle Konfiguration nach folgendem Schema funktioniert:

1. alle <RM> mit CUL pairen
2. eine Gruppe über den ConfigButton innerhalb der vorgegebenen sek mit allen <RM> erstellen
3. Mit attr <RM> peerIDs <device_id>01 für alle <RM> den Master (auch den Master selbst) manuell gesetzt

Ich habe mir den ausgewählt der meinem CUL am nächsten ist. Der BatteryStatus als auch der Netzwerktest über den ConfigButton am Gerät funktionierte. Die <RM> waren nur nicht über die FHEM GUI mit dem CUL zu einem Test zu bewegen...

Aber als ich den HMLAN in Betrieb genommen habe, hat dieser meine Gruppe bzw. das Setup direkt richtig interpretiert/erkannt.

Was also nach dem Setzen des IODev für alle <RM> fehlte, war das Auslesen der Config für jeden <RM> mit

Code Auswählen Erweitern


set <RM> getConfig


Jetzt habe ich nur noch eine Frage:

Bekomme ich das mit dem CUL im HM Modus überhaupt vernünftig zum Laufen oder sollte ich besser den HMLAN weiterverwenden und meine anderen HM Devices darauf pairen?  

Wie auch immer.

Besten Dank für die prompte Hilfe...

Mfg Groby

[martinp876]

Hi Groby,

1) CUL funktioniert gut, kann aber kein AES und sollte nicht fuer Burst devices verwendet werden.
=> alle Burst und AES devices unbegingt mit HMLAN betreiben
Du kannst auch Mischbetrieb, CUL und HMLAN. Da solltest du dir aber überlegen warum: Reichweite waere ein Argument, aber sonst??? Das es ein Lastproblem loesen wuerde kann nicht erkennen, es benutzt die gleiche Traegerfrequenz...
FHEM-maessig erzeugt der Betrieb von 2 IOs die noch dazu messages doppelt melden nur Last.

2) RM
schön,dass es funktioniert. Dennoch werde ich es so nicht empfehlen.
Vorgehen von mir:
a)Alle RMs pairen
b)virtuellen RM als teamleader einrichten
c)alle RMs mit dem Teamleader mit peerChan "teamen"

Vorteil:
- peerChan geht immer, direkt peeren nicht immer
- Austausch auch des Teamleaders ohne Probleme moeglich,alle RMs sind gleich (leader ist virtuel, geht nicht kaputt)
- saubere ordnung zwischen RM und Team messages

Deins ist nicht Falsch, ganz klar!

Gruss
Martin

[Groby]

Martin,

super vielen Danke. Den virtuellen TL werde ich am WE einrichten. Aber zuerst muss ich noch mein APL neu verkabeln - die Arbeit reisst nicht ab :)

Das Last Problem kann ich bereits erkennen, da jede Message 2 x verarbeitet wird (CUL / HMLAN).

Ergo werde ich meine anderen HM devices vom CUL unpairen und mit dem HMLAN pairen.

Allerdings geht das pairen per Eingabe der device_ID über das HMLAN WindowsConfig nicht. Fehlermeldung: Anlernen Fehlgeschlagen. Überprüfen Sie die Seriennummer...

Kann ich das irgendwie elegant lösen (unpair, pair und edit der fhem.cfg), oder muss ich bei den Rolladenschalter die Blenden abziehen um den ConfigButton zu drücken bzw. die Anleitungen füt den Rest der Geräte durchlesen um diese Zuerst in den Auslieferungszustand zu versetzten?

Danke & Gruss Groby

[martinp876]

Hi Groby,

zum pairen brauchst du die Windows SW nicht, kann FHEM.
hmPairForSec, hmPairSerial oder einfach pair.

Pairen sollte einfach noch einmal funktionieren.
Ich wuerde
CUL aus fhem.cfg loeschen. ggf. IOdevice auf HMLAN setzen (oder offen lassen)
FHEM wird fuer alle devices HMLAN als IO nehmen.
dann probieren
set <dev> pair

wenns nicht klappt:
set <hmlan> hmPairSerial <dev-seriennummer>
set <hmlan> hmPairForSec 300
+ anlernen.

Probier mal

[Groby]

Hallo Martin,

Ich habe auf ganzer Linie versagt...

Ich habe versucht 4 verschiedene Aktoren an HMLan anzulernen (nach Deiner Anleitung, CUL entfernen usw). Es schien auch irgendwie erst zu funktionieren, bis plötzlich 2 Aktoren gar nicht mehr schalteten. Also Anleitung raus, hardreset anlernen an HMLan, gleiches Problem. Pending cmds...

Nach etlichen Versuchen habe ich es zumindest geschafft die Geräte auf den CUL zurückzusetzen. Ausser den RolladenAktor, der ständig Missing Ack sendet und null Reaktion über die GUI zeigt...

Gleiches Problem hatte ich vorher schon mit dem HMLan. Gepairt, test cmd - alles ok - Plötzlich Missing Ack und danach ging wieder nichts mehr. Ich habe erst gedacht vielleicht ein Reichweiten Problem, und deshalb mit dem HMLan die Etagen gewechselt - leider Fehlanzeige...

Zum Glück habe ich die Aussenbeleuchtung und das Flurlicht mit dem CUL wieder am Start.

Der Rolladen Aktor verweigert strikt den Dienst. Pending cmds. Zurücksetzen, autocreate, manuelles pairen schafft leider alles keine Abhilfe...

Wie kann ich das widerspenstige Teil wieder zum Leben erwecken?

Edith:
Nach diversen resets, unpair, clear usw. habe ich auch meinen Rolladenaktor wieder zum laufen bekommen. Wenigstens etwas. Also werde ich heute das ganze mal strategisch angehen und zuerst einen unbenutzten HM-LC-SW1-FM gepflegt vom CUL auf den HMLan umsetzen und fleissig mitschreiben, damit ich dann die anderen Devices "easy" umsetzen kann.

Fortsetzung folgt...

Komischerweise haben sich die 3 Rauchmelder überhaupt nicht beschwert. Vor lauter Frust (schlimmer geht's immer) habe ich einen davon auch auf ein virtuelles Device gepairt (Danke Martin) mal ganz ohne Probleme...

Die Frage die es noch zu klären gilt: Wie setzt man die cmd's "test, alarmOff, alarmOn" in der GUI um?

Ich hab gelesen das geht nur über den Rauchmelder-Teamleader, der ja jetzt virtuell ist...

Gruss, Groby

[martinp876]

Hi Groby,

da hast du ja einige Baustellen angerissen. Leider ist mir bei keiner klar, was das Problem ist.

1) CUL versus HMLAN:
- Die kommunitaion mit den Devices ist in beiden ziemlich gleich. Die Besonderheiten von HMLAN solltest du nicht merken.
- warum must du umsetzen? Hast du eine andere HMID in CUL und HMLAN? Wenn du die selbe benutzt kannst du die Geraete (CUL<-> HMLAN) tauschen wie du willst. Erneutes pairen ist nicht notwendig. folgende Dingen sind zu beachten fuer den 'normal-user'
-> setze dein IOdev nicht. FHEM wird es anpassen
-> starte nur eines deiner IOs, mache ggf alle andere stromlos und mache eine FHEM reboot wenn du umschaltest
-> nutze IMMER die gleiche HMID fuer die Zentrale, egal ob CUL oder HMLAN
-> paire alle Devices mit der Zentrale. Falls es nicht klappt probiere ein set unpair von der alten Zentrale aus und paire dann neu. Gut moeglich dass ein device die Aenderung der 'Zentrale', also des pairings nur von der Aktuellen erlaubt. Daher erst einmal loeschen (unpair) oder reseten.

Anderes ist auch moeglich aber nur in ausnahmen sinnvoll. Wenn du erst einmal auf die Fuesse kommen willst, mache es einfach!

Wenn du alles an HMLAN gepairt hast - und geprueft! - kommt der naechste Schritt. Falls sich etwas nicht pairen laesst, zeichne die Logs auf und schicke diese. Roh-messages sind sinnvoll.

Gruss
Martin

[Groby]

Hallo Martin,

das pairing Problem ist gelöst!!!

Die Idee mit der gleichen hmid hatte ich auch schon, aber Aufgrund der Probleme die aufgetreten sind wollte kein weiteres Risiko eingehen und der Sache lieber auf den Grund gehen.

Also habe ich mir ein unbenutzten HM-LC-SW1-FM geschnappt und folgendes Test Setup vorbereitet:

1. Versuch
fhem1 - CUL
fhem2 - HMLAN

fhem1: Schalter gepairt mit CUL
fhem1: unpair <device> - processing - done
fhem2: HMLan hmPairSerial <device id> - done
fhem2:Schalter gepairt mit HMLan
fhem2: unpair <device> - processing - done
fhem1: CUL hmPairSerial <device id> - done

Na also ich kann es doch...

2. Versuch
fhem1: CUL & HMLan
fhem1: Schalter gepairt mit CUL
fhem1:unpair <device> - processing - F5 - done
HMLan hmPairSerial <device id> - irgendwie verschluckt - pending cmds - Mist HW reset

Schalter wieder gepairt mit CUL

attr IODevice <device> CUL
unpair <device> - processing - F5 - done
attr IODevice <device> HMLan
fhem2: HMLAN hmPairSerial <device id> - done

Na also. Geht doch!!!

Und nach gleichem Schema wieder gepairt mit CUL...

Jetzt kann ich mich in Ruhe dem eigentlichen Problem widmen, wie ich die Rauchmelder über das virtuelle device steuern kann. Ansonsten bin ich bei einem Fehlalarm taub, bis ich die Leiter geholt habe ;)

qmartinp876: Danke für Deine Hilfe & Geduld!!!!

MfGroby

[Martin Thomas Schrott]

Hi Groby,

die Melder sind jetzt schon eine Weile her und ich bin nicht mehr ganz sicher ... aber ich hoffe für dich, dass sich der echte (Fehl)Alarm auch via fhem abstellen lässt.:-)

ungetestet hier eine Idee:

SD_alarm_off notify virtual_sd_button.* set sd_master alarmOff


wenn du einen virtual_sd_button anlegst sollte das so gehen.Hoffe das ist was du wolltest.:-)
Test es deinen Ohren zu liebe mal lieber mit
set sd_master test
dann sollten alle leise zu piepsen beginnen. 10x. danach wieder Ruhe.
;-)

lG
Martin

[Groby]

Hallo Martin,

ja das ist genau das was ich versuchen wollte bzw. wie ich es auch vemutet habe. Aber entweder ich bin falsch abgebogen (scheiss Navi:) oder ich peil das System noch nicht...

Also ich habe ein virtual Device mit einem Kanal angelegt. Das habe ich HMControl genannt. Dann wurde automatisch oder zu Fuss (ich weiss es nicht mehr) der Btn1 angelegt. Diesen habe ich mit den 3 Rauchmeldern ge-peerChan-ed. Die tauchen auch alle brav in der peerlist auf.

Der Haken ist Btn1 oder in meinem Fall umbenannt sdTeam unterstützt nur:

peerChan
press
valvePos

Da komme ich irgendwie nicht weiter...

MfGroby

[martinp876]

Hi Groby,

da hast du recht. einen virtuellen master musst du händisch bauen. Der Virtuelle Aktor gibt das nicht her.
Also mache einen
define SDmaster CUL_HM BEEF01 # eigenen Nummer deiner Wahl
attr SDmaster model HM-SEC-SD
attr SDmaster subType smokeDetector

Der sollte dann gehen.
Wenn du als HMID die deines virtuellen Aktors nimmst (den vorher löschst) musst du die SDs nicht mehr peeren und kannst die peers im Attribut nachtragen.
attr peerIDs <SD1>,<SD2> # also die IDs, nicht die Namen. Die IDs 8-stellig, enden IMMER mit "01" (channel 1)


Gruss
Martin

[Groby]

Noch eine Anmerkung meinerseits für alle die mitlesen.

Bei Batterie betriebenen devices bewirkt ein entnehmen und wieder einlegen der Batterien echte Wunder.

Ich habe das am Bewegungsmelder gelernte  
(siehe anderer post: Link)
gleich bei einem Rauchmelder überprüft.

Unpair, pair, Batterien raus (auch die einzelne) - damit der Rauchmelder initialisiert (Farbwechsel der Status LED), und siehe da -es wird der pairing status & readings richtig an das entsprechende device gemeldet, auch wenn fhem selber pending cmds zeigt...

Das Gleiche gilt beim Reset am Device, pairen, zwischendurch einfach mal die Batterien entfernen und wieder einlegen, damit die readings upgedatet werden.

Dank an martin876 für die scheinbar endlose Geduld!!!

MfGroby

[crissiloop]

Darf ich diesen Thread mal missbrauchen, um Euch nach Euren Erfahrungen mit Fehlalarmen mit den Homematic-SD´s zu fragen?
Oder seid Ihr im Moment alle noch am Testen und könnt dazu noch keine Aussagen treffen?

Ich liebäugle schon mit den Meldern, um Sie in mein System einzubinden. Aber die Einträge bei ELV zu Fehlalarmen halten mich noch davon ab.

Gruß
Christian

[Martin Thomas Schrott]

Hi!

also die Melder laufen bei mir jetzt seit über vier Monaten und es gab keinen einzigen Fehlalarm! Auch sonst keine Probleme  abgesehen von der noch nicht fertigen Einbindung in FHEM die aber jetzt wirklich bald behoben sein dürfte ;-)
Fehlalarme kann ich mir hier nur durch falsches Aufstellen/Montieren vorstellen. Die Melder reagieren nicht auf irgendwelchen Dampf oder ähnliches ich habe stundenlang versucht sie in der Küche zum Auslösen zu bewegen sogar im Topf mit kochendem Wasser - über Dampf. Nichts! Einzig und alleine echter Rauch bringt sie zum piepsen! siehe unsere Test im Feueralarm Topic wo jetzt schon zumindest zwei Wege beschrieben sind wie man einen ausreichenden Rauch simulieren kann - was garnicht so einfach ist.

Also ich kann die Melder bedenkenlos empfehlen.
LG
Martin

[Groby]

Hallo Christian,

Fehlalarm kenne ich bisher auch nicht. Ich habe die RMs aber auch erst ein paar Wochen im Betrieb, deswegen nicht gerade repräsentativ.

Hier mein bisheriges Fazit:

+ vernetzten mehrer RM's - gerade bei gesegnetem Schlaf
+ Team Test am Gerät (auch ohne Zentrale)
+ Battery Status & andere Infos an Zentrale (Protokoll für Test, Alarm)
+ Ausschalten über die Zentrale (wenn ich's denn wieder hinbekomme :)

- Preis im vergleich zu "normalen" Geräten...

Und um Dich nicht abzuschrecken - die Erstinstallation mit Pairen / Teamen nach beiliegender Anleitung verlief ohne Probleme.

Beim Fehlalarm ist die Frage ob die Geräte richtig bzw. auch an der richtigen Stelle angebracht sind.
Im Urlaub hatten wir mal einen in der Küche, da hatten alle Urlaubsgäste "Spass" wenn der Toast ankokelte...

MfGroby