mal wieder: WindowRec mit HM-RT und HM-Fensterkontakt

[theophilou85]

Ich habe mich gestern Abend noch einmal an die Sache rangesetzt, aber ich glaube bei mir liegt der Hund irgendwo anders begraben.
Gestern Abend waren die CMD's irgendwann endlich einmal "done", aber der Configcheck zeigte das gleiche Bild wie bereits gepostet. Daraufhin habe ich an einen Stellantrieb ein getConfig geschickt und dort die Configtaste für 4s gedrückt. Der meldete sich mit einem ResponseTimeOut nach wenigen Sekunden.
Das gleiche habe ich mit einem der Stellantriebe versucht, der auch auf CMD's done stand. Bei dem kam CMD's pending, processing, pending und der verblieb dort mind. 15min. Habe nach ca. 5min abermals die Configtaste für 4s gedrückt, keine Änderung.
Aus irgend einem Grund bekomme ich nicht einmal alle Register korrekt ausgelesen, geschweige den, könnte ich mit dem Peering beginnen.
Die ganze Sache ist ja vom logischen Aufbau nicht schwer zu kapieren und die Geduld habe ich mittlerweile.

Ich habe mir jetzt einmal die HMInfo im wiki durchgelesen, da fiel mir auf: "set dev01Ch01 getConfig". Ist es notwendig die Config channelweise und nicht geräteweise abzuarbeiten?
Des weiteren bin ich über das "Expert" Attribut gestolpert. Sollte ich dieses vielleicht einmal auf einen anderen Wert setzen?

[MadMax-FHEM]

Kanalweise macht die zu übertragenden Pakete kleiner...
Kann helfen...

Aber evtl. brauchst du dann doch die Spezial-FW, wenn du immer noch Timeout RegisterRead bekommst...

War beu mir auch so als ich den Klingelsensor verwenden wollte...

Zuvor war alles ok mit dem CUL...

Gänzlich Abhilfe schafft wohl bei Homematic nur die Verwendung eines echten HM IODev...

Expert ist nur die Anzeige wieviel Information/Register du sehen willst.

Das attr autoreadreg sagt wann und wie Register gelesen werden sollen...

Aber das wirkt erst, wenn der getConfig (Gerät bzw. alle Kanäle) abgeschlossen ist...

Also wirken nur bildlich, weil nat ein "gar nicht lesen" natürlich das Auslesen unterbindet dich aber nicht weiter bringt, da ja erst mal alles gelesen sein muss...

Eventuell hilft Geduld und Auslesen der einzelnen Kanäle nacheinander...

Wenn nicht, dann wohl nur "Spezial-FW" oder "echtes" HM IODev...

Viel Erfolg, Joachim

[theophilou85]

Um welche Spezial-FW geht es da? Ich habe das Problem dass ich auch Intertechno im Einsatz habe und der SlowRF-Mode funktioniert dort super. Auf den möchte ich mit dieser SpezialFW nicht verzichten.

Bzgl der Commands: Die Wandthermostate melden CMD's done mit 1 Error. Ich weiß nicht ob mit diesem Error der RESPONSE TIMEOUT:RegisterRead gemeint ist, oder irgend ein anderer Error. Kann man diesen Error irgendwie auslesen?
Die Stellantriebe arbeiten ihre Commands bis auf 4 CMD's ab und kommen dann mit einem: motorErr: communicationERR // state: MISSING ACK.

Mir fällt ein, dass ich als ich die Geräte gepaired habe und ein "rename" gemacht habe, die Kanäle nicht umbenannt wurden. Das habe ich dann manuell in der fhem.cfg gemacht --> save.
Kann es womöglich damit zusammenhängen?

[MadMax-FHEM]

Hi,

die Spezial-FW und Module in diesem Thread:

https://forum.fhem.de/index.php/topic,24436.msg175466.html

Hast du nur einen CUL für slowrf und HM?
(Geht das? Ich weiß dass man zu "irgendwas" umschalten kann und so quasi "Parallelbetrieb" fahren kann)

Das ist eh ganz schlecht!
Wenn der CUL slowrf (oder etwas anderes) sendet (empfängt) dann ist er ja für HM "gesperrt" d.h. es gehen Telegramme verloren!

Immer mind. ein IODev pro Protokoll(familie)!

Fehler stehen entweder im Log oder meist auch im STATE/state eventuell auch über hminfo protostate (oder so ähnlich).

Rename sollte (wenn richtig gemacht) keinen Einfluss haben die Zuordnung geht über die IDs.

Es gibt (bei HM) auch ein set-commando beim Gerät/Device für rename, da werden die Kanäle und Logfiles umbenannt...

Gruß, Joachim

[theophilou85]

Ich nutze meinen 868er CUL für beides und das mit dem SlowRF funktioniert wirklich gut, da ich ja nur sende und nicht empfange.
Jetzt aber einmal eine andere Frage: Ich habe meinen CUL kürzlich auf die 1.67iger geflashed, um ein AC Protokoll, als IT String abzusenden. Muss ich bei einem Firmwareupdate des CUL's auch irgendwas im FHEM machen? da gibt es ja gewisse CULxxx.pm Dateien. Vielleicht ist dort der Hund begraben. Langsam glaube ich nämlich nicht mehr an Problem des Peerings/Pairings.

[MadMax-FHEM]

Normalerweise nur ganz normal per update auf den neuesten Stand bringen/halten.

Aber nochmal: es sieht so aus als würde Parallelbetrieb funktionieren aber während du sendest gehen evtl. Telegramme von HM verloren.

Ein Parallelbetrieb ist nicht ratsam (gibt es tausend Threads zu dem Thema)...

Und wie ebenfalls mehrfach gesagt/geschrieben: bei mir (und auch bei anderen wenn du den verlinkten Thread mal überfliegst [gerade gegen "Ende"]) war alles gut dachte ich, bis ich mit dem Klingelsensor losgelegt habe.

Erst ein Umstieg auf die genannte FW brachte Abhilfe.

Noch besser ist die Verwendung eines "echten" HM-IODev...

Gruß, Joachim

[theophilou85]

Ich habe mir den Thread jetzt einmal durchgelesen.
Du meinst all meine Peeringprobleme können mit dem felenden Timestamp zusammenhängen? Das MissingACK kann ich mir dadurch schon erklären.
Ich müsste also die Firmware des Threads flashen, den CUL neu als TSCUL anlegen und die IODevices-Attribute bei allen Sensoren/Aktoren ändern. Wie das mit den *.pm abläuft hab ich noch nicht ganz überlauert, aber ich lese mir das Sonntag oder Montag nochmal in Ruhe durch. Einen guten Rutsch darf ich wünschen und danke für dein Engagement.

[MadMax-FHEM]

Ich habe mir den Thread jetzt einmal durchgelesen.
Du meinst all meine Peeringprobleme können mit dem felenden Timestamp zusammenhängen? Das MissingACK kann ich mir dadurch schon erklären.

War zumindest bei mir (und vielen anderen) so.

Aber trotzdem nochmal der Hinweis: Parallelbetrieb ist nicht gut!!!

Ich müsste also die Firmware des Threads flashen, den CUL neu als TSCUL anlegen und die IODevices-Attribute bei allen Sensoren/Aktoren ändern.

Ja, aber halt die passende für deine HW!

Ja, einfach aus dem CUL ein TSCUL in der Config machen.

NEIN: an den IODevices-Attributen musst du nichts ändern, da sollte ja der Name des IODev stehen und der bleibt ja!

also aus:

define meinCUL CUL /dev/...

wird:

define meinCUL TSCUL /dev/...

und bei den Geräten steht ja (also bei mir):

attr HM_GERÄT IODev meinCUL

Wie das mit den *.pm abläuft hab ich noch nicht ganz überlauert, aber ich lese mir das Sonntag oder Montag nochmal in Ruhe durch.

Einfach die *.pm Dateien (zumindest die relevanten, dazu musst du wissen was du nutzt und welche Datei für was ist / daher einfacher: alle) nach /opt/fhem/FHEM/ kopieren (vors. deine Installation von fhem ist unter /opt/fhem/).

Nicht vergessen den "exclude from update" Eintrag zu machen, sonst werden die *.pm Dateien aus dem ZIP wieder überschrieben!!

Das ist der (noch) nicht schöne Teil an der Geschichte...
...da einiges vom Update "ausgeschlossen" wird und (falls es etwas neues gibt) von Hand neu eingespielt werden muss...

Ansgar ist da dran aber bislang leider ohne Erfolg...

Daher bleibt das (selbstbau)CUL für HM nur auf meinem Testsystem.
Auf meinem "echten" System kommen mir nur "echte" HM-IODevs zum Einsatz!

Einen guten Rutsch darf ich wünschen und danke für dein Engagement.

Danke!
Gerne!

Ebenso!

Und viel Erfolg!

[theophilou85]

Und weiter geht's im neuen Jahr. Da im alten in meinem Kellerabteil eingebrochen wurde (und diese verrückten meine alten Sommerreifen+Felgen geklaut haben, Wert: 20€, bin aber versichert) benötige ich jetzt für das Kellerabteil einen weiteren Fensterkontakt. Bevor ich mich ans CUL-update mache noch ein paar Fragen:
2 optische Fensterkontakte, 1 Stellantrieb, 1 Wandthermostat: Fensterkontakt mit Wandthermostat richtig?

Ist es eigentlich korrekt dass die Fensterkontakte, wenn Sie beide mit einem Wandthermostat gepeert werden, sich gegenseitig zweimal in der Peerlist haben? kon00: 00000000,359B3E00,359B3E01; kon01: 00000000,359B0200,359B0201. Einem Kontakt kann doch egal sein, was das andere macht. Ich habe auch nie ein peer zwischen den beiden "befohlen".

[MadMax-FHEM]

Und weiter geht's im neuen Jahr. Da im alten in meinem Kellerabteil eingebrochen wurde (und diese verrückten meine alten Sommerreifen+Felgen geklaut haben, Wert: 20€, bin aber versichert) benötige ich jetzt für das Kellerabteil einen weiteren Fensterkontakt.

Wie weit ist denn der Keller weg?
Nicht dass dann neben den Timing-Problemen auch noch Probleme mit der Entfernung (schlechte Funkverbindung) dazukommen...

Bevor ich mich ans CUL-update mache noch ein paar Fragen:
2 optische Fensterkontakte, 1 Stellantrieb, 1 Wandthermostat: Fensterkontakt mit Wandthermostat richtig?

Ist es eigentlich korrekt dass die Fensterkontakte, wenn Sie beide mit einem Wandthermostat gepeert werden, sich gegenseitig zweimal in der Peerlist haben? kon00: 00000000,359B3E00,359B3E01; kon01: 00000000,359B0200,359B0201. Einem Kontakt kann doch egal sein, was das andere macht. Ich habe auch nie ein peer zwischen den beiden "befohlen".

Da ich jetzt die IDs deiner einzelnen Geräte nicht kenne (vielleicht mal ein list von allen beteiligten Geräten posten), kann ich nicht sagen, ob das so stimmt.

Allerdings sollte in den Peer-Lists (neben der 00000000) halt immer der jeweilige Kanal des Gerätes stehen, mit dem gepeert ist.

Vielleicht ist es passiert, weil du "gleichzeitig" (oder ausreichend schnell hintereinander) beide Fensterkontakte in "peering/pairing" Modus versetzt hast.
Die Geräte/Kanäle lassen sich ja auch ohne "Befehle" von fhem (Zentrale) peeren, sofern sie noch nicht an eine Zentrale angelernt sind: dann durch entsprechendes Drücken von den Anlern/Config-Knöpfen...



Wenn ich Wandthermostat und Heizkörperthermostat (nur mal zur Sicherheit: es sind schon die "normalen" Homematic, nicht die mit IP im Namen!? Zumindest laut den Auszügen die hier gepostet wurden scheint es so zu sein) und Fensterkontakt einsetze, dann mache ich folgendes (nach erfolgreichem PAIREN von ALLEN Geräten):

Peering von Wandthermostat_Weather mit Heizkörperthermostat_Weather und Wandthermostat_Climate und Heizkörperthermostat_Climate

https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Channel_.28Kanal.29_01_Weather

Dadurch steuert der Wandthermostat den Heizkörperthermostaten, d.h. er gibt die Soll- und die Ist-Temperatur vor.
Der Heizkörperthermostat übernimmt dann die Regelung...

Den Fensterkontakt peere ich daher auch mit dem Wandthermostaten:

https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Channel_.28Kanal.29_03_WindowRec

D.h. beim Wandthermostat_Climate steht unter Peerlist der Heizkörperthermostat_Climate und andersrum.
Genauso bei Weather.

Bei WindowRec steht dann der Fensterkontakt und beim Fensterkontakt (hat nur einen Kanal bzw. nur "sich selbst") steht dann der Wandthermostat_WindowRec drin...
...und andersrum.

Alles andere ist nicht richtig/unnötig!
(Also abgesehen von 00000000)

Wenn die Peers so (falsch) in den Geräten (Registern) stehen, dann wirst du wohl über ein Zurücksetzen nicht rumkommen...

Aber vielleicht ist es ein guter Anfang im neuen Jahr:

Alle Geräte in fhem löschen, die Geräte "hart" zurücksetzen (also mittels Rücksetzprozedur laut Anleitung) und dann noch mal langsam von vorne.

Also wirklich ein Gerät nach dem anderen VOLLSTÄNDIG PAIREN (bis hminfo zufrieden ist und keine cmds_pending und keine MissingAcks etc und bei R-PairCentral /PairedTo die HMID steht und diese darf NICHT 000000 sein!).

Nachdem alle sauber gepaired sind halt ums PEERING kümmern.

Sowohl beim PAIREN also auch beim PEEREN zumindest bei den Heizkörperthermostaten und Fensterkontakten unter Zuhilfenahme des Anlern/Config-Knopfs.

Also pairForSecs absetzen, Anlernknopf wie laut Anleitung Beschrieben.
Dann sollten cmds_pending sein (oder processing).
Beim Wandthermostaten kommt meist sofort processing bei den anderen beiden Heizkörperthermostat/Fensterkontakt bleibt meist cmds_pending.
Dann erneut den Anlern-/Configtaster drücken (beim Fensterkontakt kurz und beim Heizkörperthermostat lang, bis die 30 runterzählen anfängt, ist manchmal auch ganz schnell wieder weg, dann sollte cmds_processing erscheinen / drum mach ich das immer mit Laptop neben dem Gerät).

Wie schon vielfach gesagt: immer langsam, ein Gerät nach dem anderen und immer wieder pro Gerät-Pairing-Vorgang das pairForSecs setzen (es geht nur einmal pro set, egal wie lange du die Zeit einstellst).

EDIT: und ab und an (wenn das Fragezeichen kommt) die config speichern...

Viel Erfolg im neuen Jahr!

Gruß, Joachim

[theophilou85]

Es sind keine HM IP Geräte, sondern normale. Bisher habe ich immer zuerst Gepaired und dann über FHEM gepeert. Das klappte bei Wandthermostat und Stellantrieb auch problemlos, für Weather und Climate. Nur die Fensterkontakte liesen sich bisher nicht durch den FHEM-Befehl peeren.

Ich habe das Problem jetzt anders gelöst, vl hilft es wem:

Fhem runtergefahren, stromlos.
Hardreset auf allen Devices (Kontakt 1,2 Wandthermostat, Funkstellantrieb)
Ohne Fhem: Stellantrieb mit Wandthermostat gepeert - Beide Fensterkontakte mit Wandthermostat - Beide Fensterkontakte mit Stellantrieb. Getestet.

Interessanterweise wurde das Fenstersymbol dann bei Stellantrieb und Wandthermostat korrekt angezeigt und der Stellantrieb hat auch heruntergeregelt, aber bei verschwinden des Fenstersymbols nicht mehr hinauf und blieb bei 12°C. Habe daraufhin manuell auf 24°C gestellt und seit dem hat er korrekt hochgestellt, als ob man eine "Hochstelltemperatur" vorgeben müsste. Als er bei Kontakt 1 dann korrekt zwischen 12 und 24 rauf und runtersprang, hatte ich beim zweiten auch noch das Problem, dass er korrekt auf 12 runter aber nicht mehr hochregelgt. Hier also auch einmal die 24 eingestellt und dann klappte das auch. Inzwischen ist die Vorgabe vom Wandthermostat 20 und er springt korrekt zwischen 12 und 20 . Für dieses Phänomen habe ich gar keine Erklärung.

Dann FHEM wieder gebootet und Stellantrieb und Wandthermostat gepaired. Die Fensterkontakte musste ich interessanterweise danach gar nicht mit FHEM pairen, als ob das Wandthermostat oder der Stellantrieb das "miterledigt" hätten. Phänomen oder normal?

Was ich aus der Sache mitgenommen habe:
- IODev besser ein echtes HM Gerät (deine Worte)
- hat man keines: am besten alles was außerhalb von FHEM gepeert werden kann, auch machen, weil dann FHEM+IODev als Fehlerquelle nicht involviert sein können
- Zeit lassen (deine Worte)
- StepByStep (deine Worte)
- alles nah zusammenstellen, damit man Funkprobleme ausschließen kann --> (Alle Device nahe zum Stellantrieb)
- bei mir laufen die Geräte mit Eneloopakkus, würde beim Einrichten aber frische Batterien nehmen

Ich lasse jetzt einmal alles ruhen und abarbeiten. 

Was noch an "Unschönheit" übergeblieben ist: Öffne ich das Fenster leuchtet der Fensterkontakt erst Orange und blinkt dann am Ende rot. Korrekt ist, glaube ich: Orange dann grün und beim Schließen das gleiche. Irgend eine Idee woran das liegt?
Das Kellerabteil erreiche ich bei weitem nicht. Nach der Wohnungstüre habe ich vl 5m, dann ist Schluss. Diese Position hat Luftlinie zum CUL max 10m.
Gibt es irgendwelche Kontakte (devolo Wifi oder was ganz anderes) die eine extrem hohe Reichweite haben? Wifi mit dem Handy bekomme ich mit ach und krach rein.

Wenn das alles funktioniert, spiele ich einmal die anders CUL-Firmware drauf, befürchte aber, dass ich damit die AC-Telegramme ("Intertechno") zu meiner Lampe nicht mehr hinausbekomme. Das klappte erst mit der 1.67iger vom König und mit den Versionen davor nicht.

[MadMax-FHEM]

Na dann erst mal: Gratulation!

Hier noch ein paar Erläuterungen:

jep, wie bereits geschrieben und in der Doku: die Sensoren/Aktoren lassen sich auch direkt peeren. Allerdings (soweit ich weiß und meist auch laut Doku) nur, wenn sie noch nicht mit einer Zentrale verbunden (gepaired) sind...
Dadurch spart man sich die Peering-Aufrufe und da sich das ja auch ohne fhem (Zentrale) verwenden lässt muss es ja auch so gehen...

Hmmm, eigentlich hättest du die Fensterkontakte mit dem Stellantrieb gar nicht mehr verbinden müssen, da das ja bereits durch den Wandthermostaten erledigt sein sollte.
Durch das Verbinden von Wandthermostat und Stellantrieb werden die Tempvorgaben ja vom Wandthermostaten vorgegeben...
Evtl. ist jetzt dadurch der Stellantrieb auf "burst umgeschaltet" worden.
Kann zu (etwas) höherem Batterieverbrauch führen.

Ich habe es bei einigen Stellantrieben auch gemacht (andere Gründe) und bislang noch keine gravierenden Unterschiede bzgl. Batterieverbrauch bemerkt (im Vergleich zu welchen ohne burst-Aktivierung / allerdings laufen die alle erst ein knappes Jahr).

Interessanterweise wurde das Fenstersymbol dann bei Stellantrieb und Wandthermostat korrekt angezeigt und der Stellantrieb hat auch heruntergeregelt, aber bei verschwinden des Fenstersymbols nicht mehr hinauf und blieb bei 12°C. Habe daraufhin manuell auf 24°C gestellt und seit dem hat er korrekt hochgestellt, als ob man eine "Hochstelltemperatur" vorgeben müsste. Als er bei Kontakt 1 dann korrekt zwischen 12 und 24 rauf und runtersprang, hatte ich beim zweiten auch noch das Problem, dass er korrekt auf 12 runter aber nicht mehr hochregelgt. Hier also auch einmal die 24 eingestellt und dann klappte das auch. Inzwischen ist die Vorgabe vom Wandthermostat 20 und er springt korrekt zwischen 12 und 20 . Für dieses Phänomen habe ich gar keine Erklärung.

Dafür habe ich auch keine Erklärung. Sollte eigentlich nicht so sein.
Bzw.: der Heizkörperthermostat ist kein "Burst-Device", d.h. er schläft richtig tief und wacht nur zu bestimmten Zeiten auf (ca. alle 3min). Nur dann nimmt er neue Werte/Kommandos etc. an (daher dauert ein Pairing/Peering etc. hier auch "länger" bzw. ist nicht so einfach).
Der Wandthermostat sollte eigentlich sofort das Fenstersymbol haben und auch die Temp wieder hochregeln und dann beim Aufwachen an den Heizkörperthermostaten weitergeben...

Dann FHEM wieder gebootet und Stellantrieb und Wandthermostat gepaired. Die Fensterkontakte musste ich interessanterweise danach gar nicht mit FHEM pairen, als ob das Wandthermostat oder der Stellantrieb das "miterledigt" hätten. Phänomen oder normal?

...


Was noch an "Unschönheit" übergeblieben ist: Öffne ich das Fenster leuchtet der Fensterkontakt erst Orange und blinkt dann am Ende rot. Korrekt ist, glaube ich: Orange dann grün und beim Schließen das gleiche. Irgend eine Idee woran das liegt?

Das mit automatisch übernommen etc. sieht nur so aus, daher evtl. auch die Leuchtorgie des Fensterkontaktes.
fhem empfängt die Funksignale/Meldungen des Fensterkontaktes und legt diesen auch an (autocreate aktiv) und bekommt auch die Aktivitäten (auf/zu) mit und trägt sie entsprechend beim angelegten Gerät ein.
Allerdings ist der Fensterkontakt nicht gepaired und bekommt kein ACK bzw. versteht das ACK von fhem evtl. nicht (weil er ja keines erwartet).

Allerdings denke ich eher es hat mit AES zu tun.
Der Fensterkontakt ist ein "sicherheitsrelevantes" Gerät, da für Alarmanlagen verwendbar und daher automatisch mit Signatur/AES ausgeliefert.
Die Wand/Heizkörperthermostate haben das nicht aktiviert.
Fensterkontakt erwartet nun ein AES-signiertes ACK was aber nicht kommt: rot.

Schau mal hier:

https://wiki.fhem.de/wiki/HM-SEC-SC_T%C3%BCr-Fensterkontakt

und hier:

https://wiki.fhem.de/wiki/HM-Sec-SCo_T%C3%BCr-Fensterkontakt,_optisch

Der magnetische ist etwas ausführlicher beschrieben, im Prinzip (aus fhem) sind sie aber gleich...

AES macht eigentlich bei einem Sensor keinen (großen) Sinn, da man da ja keine Aktion auslösen kann...
...was anderes wäre es bei einem Aktor, da macht es durchaus Sinn AES zu aktivieren, da sonst der Nachbar oder jemand anders eingreifen und verstellen kann.
Er braucht dazu nur die HMID wissen...
Denn die Funksignale kannst du nicht verhindern die jemand anders rausschickt und wenn die Geräte darauf "hören" weil sie glauben sie kommen von "ihrer" Zentrale (HMID) dann machen die auch brav was "gesagt" wird...

Das Kellerabteil erreiche ich bei weitem nicht. Nach der Wohnungstüre habe ich vl 5m, dann ist Schluss. Diese Position hat Luftlinie zum CUL max 10m.
Gibt es irgendwelche Kontakte (devolo Wifi oder was ganz anderes) die eine extrem hohe Reichweite haben? Wifi mit dem Handy bekomme ich mit ach und krach rein.

Wenn dort Strom vorhanden ist, kannst du mal bzgl. ESP8266 im Forum oder Internet kucken.
Das ist ein WLAN-Käfer a la Arduino, damit kann man alles mögliche machen.
Ich habe einen für die Füllstandsmessung meines Wassertanks auf dem Balkon.

Allerdings ist der Käfer nichts für Batteriebetrieb.
Es wurde viel versucht (ich selbst auch) aber so richtig weit gekommen ist noch keiner (soweit ich weiß).
Da ich Strom auf dem Balkon habe ist das kein Problem...

Gruß und weiterhin viel Erfolg! Joachim

[theophilou85]

Danke für die ausführliche Erklärung. Einige Fragen hätte ich dazu noch:

Durch das Verbinden von Wandthermostat und Stellantrieb werden die Tempvorgaben ja vom Wandthermostaten vorgegeben...
Evtl. ist jetzt dadurch der Stellantrieb auf "burst umgeschaltet" worden.

Wie soll denn die Fensterauferkennung ohne Burst funktionieren. Wäre ja total unbrauchbar, wenn ich 5 Minuten Stoßlüfte und das Ding erst nach 3 Minuten die Temperatur runterregelt.

Allerdings ist der Fensterkontakt nicht gepaired und bekommt kein ACK bzw. versteht das ACK von fhem evtl. nicht (weil er ja keines erwartet).

Das scheint definitiv so zu sein. Ich habe den Code der Fensterkontakte im FHEM dringelassen und die States (offen/zu) wurden richtig übergeben, obwohl ich noch nicht gepaired habe. Allerdings (wobei ich es heute nochmal versuche) liesen sich die Fensterkontakte nach dem peering nicht mehr mit dem CUL/FHEM pairen. Das erscheint mir ein wenig unlogisch. Welche/r Kanal/äle auch immer fürs peering benutzt worden sind, können doch keinen Einfluss auf den Kanal für das Pairing mit einer Zentrale haben, oder?

Wikiquote:

Mindestens bei Benutzung mit einem CUL (vermutlich auch via HM-CFG-USB und HM-CFG-LAN) muss FHEM auf das Perl-Modul Crypt::Rijndael zugreifen können. Wenn es nicht zur Verfügung steht, bleibt das Pairing unvollständig. Siehe auch den Abschnitt über AES-Encryption zwischen IO-Device und Gerät.

Wäre vermutlich nicht schlecht, wenn ich das installiere?!

Kann ich irgendwo überprüfen ob AES bei den Geräten aktiviert ist und bei Bedarf rausnehmen? Mein Nachbar kann ruhig wissen, wann bei mir ein Fenster offen ist, er hört mich sowieso fluchen, wenn es offen ist.

Strom im Keller ist problematisch, deshalb bräuchte ich irgend ein Wifi Device. Dachte schon an einen Mod. des Dashbutton, aber die ARP-Telegramme sind nicht besonders zuverlässig und es wäre selbst für ein Kellerabteil, keine "schöne" Lösung.

[MadMax-FHEM]

Wie soll denn die Fensterauferkennung ohne Burst funktionieren. Wäre ja total unbrauchbar, wenn ich 5 Minuten Stoßlüfte und das Ding erst nach 3 Minuten die Temperatur runterregelt.

Bei nur Peering mit dem Wandthermostaten ist das definitiv so.

Fenster-auf geht an den Wandthermostaten (burst device), dieser erkennt das sofort und gibt dann bei der nächsten Kommunikation zum Heizkörperthermostaten die Fenster-auf-Temp als desired-temp vor...

Ist bei mir so und kein Problem, auch Stoßlüften nicht.
Vorteil (gegenüber dem Nachteil   ): es wird die Temp auch verzögert wieder hoch gedreht, somit hat sich der Raum wieder etwas "erholt" nach dem Öffnen und der Heizkörper dreht nicht sofort (unnötigerweise) auf.

Bei direktem Peering auch mit dem Heizkörperthermostat wird bei diesem (denke ich) burst aktiviert, sonst würde er nicht sofort reagieren...

Das scheint definitiv so zu sein. Ich habe den Code der Fensterkontakte im FHEM dringelassen und die States (offen/zu) wurden richtig übergeben, obwohl ich noch nicht gepaired habe. Allerdings (wobei ich es heute nochmal versuche) liesen sich die Fensterkontakte nach dem peering nicht mehr mit dem CUL/FHEM pairen. Das erscheint mir ein wenig unlogisch. Welche/r Kanal/äle auch immer fürs peering benutzt worden sind, können doch keinen Einfluss auf den Kanal für das Pairing mit einer Zentrale haben, oder?

Bei Sensoren geht es wohl auch ohne Pairing, allerdings lassen sich dann keine Register (Einstellungen) verändern!
Der Status wird natürlich nachverfolgt, die Telegramme werden ja unweigerlich empfangen...
...und ausgewertet.

Bei einem Aktor geht ohne Pairing auch nur die Statusverfolgung, ein Steuern ist nicht möglich!

Wäre vermutlich nicht schlecht, wenn ich das installiere?!

Kann ich irgendwo überprüfen ob AES bei den Geräten aktiviert ist und bei Bedarf rausnehmen? Mein Nachbar kann ruhig wissen, wann bei mir ein Fenster offen ist, er hört mich sowieso fluchen, wenn es offen ist.

Wenn es fehlen würde, sollte eine Meldung im Log zu finden sein.

Zu sehen ist es an den entsprechenden Registern bei den Geräten, z.B. beim Fensterkontakt:

R-sign          off/on

https://wiki.fhem.de/wiki/AES_Encryption

Strom im Keller ist problematisch, deshalb bräuchte ich irgend ein Wifi Device. Dachte schon an einen Mod. des Dashbutton, aber die ARP-Telegramme sind nicht besonders zuverlässig und es wäre selbst für ein Kellerabteil, keine "schöne" Lösung.

Was wie gesagt ginge: ESP8266 selbst einen "Fensterkontakt" basteln und per WLAN (onboard beim ESP) in fhem integrieren (z.B. per HTTP-GET ein setreading auszulösen: http://<IP-von-fhem>:8083/fhem?cmd=setreading%20DUMMY_NAME%20READING_NAME%20VALUE und in fhem einen entsprechenden dummy DUMMY_NAME anlegen)

Oder: ESP8266 und HMUART-Modul (lässt sich im Forum finden) und damit sozusagen einen WLAN-HM-IODev zu haben. Der kommuniziert dann mit einem normalen HM-Fensterkontakt im Keller per HM-UART-Modul und ist dann per WLAN als weiteres HM-IODev in fhem eingebunden. Dazu bietet sich die Nutzung einer vccu an.

https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU

Gruß, Joachim

[theophilou85]

Hallo Joachim

Hier mal ein wenig weiter:

Code Auswählen Erweitern

Internals:
   DEF        359B02
   IODev      wz0_cul00
   LASTInputDev wz0_cul00
   MSGCNT     105
   NAME       wz0_kon00
   NOTIFYDEV  global
   NR         160
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:7D - t:10 s:359B02 d:000001 06010000
   protCmdPend 4 CMDs pending
   protLastRcv 2017-01-06 00:51:57
   protSnd    12 last_at:2017-01-06 00:51:57
   protState  CMDs_pending
   rssi_at_wz0_cul00 min:-72 max:-58 lst:-58 cnt:105 avg:-61.05
   wz0_cul00_MSGCNT 105
   wz0_cul00_RAWMSG A0D7DA610359B0200000106010000::-58:wz0_cul00
   wz0_cul00_RSSI -58
   wz0_cul00_TIME 2017-01-06 00:51:57
   Readings:
     2017-01-05 01:06:53   CommandAccepted yes
     2017-01-05 01:06:51   D-firmware      1.0
     2017-01-05 01:06:51   D-serialNr      LEQ1510020
     2017-01-05 00:51:02   PairedTo        0x000001
     2016-12-30 02:32:04   R-cyclicInfoMsg on
     2016-12-30 02:32:05   R-eventDlyTime  0 s
     2017-01-05 01:06:51   R-pairCentral   set_0x000001
     2016-12-30 02:32:04   R-sabotageMsg   on
     2016-12-30 02:32:05   R-sign          on
     2016-12-30 03:07:35   R-wz0_kon01-expectAES on
     2016-12-30 03:07:35   R-wz0_kon01-peerNeedsBurst off
     2017-01-01 12:35:29   R-wz0_kon01_chn-01-expectAES on
     2017-01-01 12:35:29   R-wz0_kon01_chn-01-peerNeedsBurst off
     2017-01-05 19:48:12   R-wz0_sta00_WindowRec-expectAES set_off
     2017-01-05 19:48:12   R-wz0_sta00_WindowRec-peerNeedsBurst set_on
     2017-01-05 00:50:38   R-wz0_the00_WindowRec-expectAES set_off
     2017-01-05 00:50:38   R-wz0_the00_WindowRec-peerNeedsBurst set_on
     2017-01-05 01:06:53   aesKeyNbr       00
     2017-01-06 00:51:57   alive           yes
     2017-01-06 00:51:57   battery         ok
     2017-01-06 00:51:57   contact         closed (to ActionDetector)
     2017-01-05 01:01:54   powerOn         2017-01-05 01:01:54
     2017-01-06 00:51:57   recentStateType info
     2017-01-06 00:51:57   sabotageError   off
     2017-01-06 00:51:57   state           closed
     2017-01-05 19:49:03   trigDst_ActionDetector noConfig
     2017-01-05 19:49:17   trigDst_wz0_kon01 noConfig
     2017-01-05 19:49:03   trigDst_wz0_sta00 noConfig
     2017-01-05 19:49:03   trigDst_wz0_the00 noConfig
     2017-01-05 19:49:17   trigger_cnt     15
   cmdStack:
     ++A001000001359B020101269BFF0300
     ++A001000001359B020105269BFF0304
     ++A001000001359B0201080101
     ++A001000001359B020106
   Helper:
     HM_CMDNR   125
     mId        00C7
     rxType     28
     supp_Pair_Rep 0
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       dwoCAA     116
       lRcTm      93427304
       lstRecType 10
       lstSnd     1483660317.08425
       lstSndTgd  120
       newChn     +359B02,02,00,00
       nextSend   1483660317.08425
       nxtSndMcnt 7D
       prefIO
       rxt        2
       tgtDly     120
       vccu
       p:
         359B02
         00
         00
         00
     Mrssi:
       mNo        7D
       Io:
         wz0_cul00  -56
     Prt:
       bErr       0
       sProc      2
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         wz0_cul00
       flg        A
       ts         1483660317.01192
       ack:
         HASH(0x3db2dec)
         7D8002000001359B0200
     Rssi:
       At_wz0_cul00:
         avg        -61.052380952381
         cnt        105
         lst        -58
         max        -58
         min        -72
     Shadowreg:
     Tmpl:
Attributes:
   IODev      wz0_cul00
   actCycle   002:50
   actStatus
   alias      Fensterkontakt Wohnzimmer links
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   group      [Homematic] Kontakte
   model      HM-SEC-SCo
   peerIDs
   room       X_Geräte,Kontakte
   serialNr   LEQ1510020
   subType    threeStateSensor

Fensterkontakt sieht jetzt weit besser aus, dank neuer FW und schaltet auch alles soweit richtig. Aber das Blinkkonzert ist mittlerweile auf "öffnen" -->Dauerorange fast 30s, dann kurz rot.
PeerID's immer noch leer, aber:

Code Auswählen Erweitern

     2016-12-30 03:07:35   R-wz0_kon01-expectAES on
     2016-12-30 03:07:35   R-wz0_kon01-peerNeedsBurst off
     2017-01-01 12:35:29   R-wz0_kon01_chn-01-expectAES on
     2017-01-01 12:35:29   R-wz0_kon01_chn-01-peerNeedsBurst off
     2017-01-05 19:48:12   R-wz0_sta00_WindowRec-expectAES set_off
     2017-01-05 19:48:12   R-wz0_sta00_WindowRec-peerNeedsBurst set_on
     2017-01-05 00:50:38   R-wz0_the00_WindowRec-expectAES set_off
     2017-01-05 00:50:38   R-wz0_the00_WindowRec-peerNeedsBurst set_on

irgendwie anscheinend doch gepeert?! Interessanterweise wiedereinmal auch mit dem anderen Kontakt (kon01). Ich würde Ansgar gerne ein Bisschen Feedback zum HM geben und habe mir dafür einen neuen Fensterkontakt bestellt, den ich frisch aufbaue und blanko nach Wiki, StepbyStep anlerne. Ich lasse mir ja einreden, dass einer meiner beiden Fensterkontakt irgendwie aus der Reihe tanzt, aber nicht beide mit dem gleichen Verhalten.

Sie liesen sich pairen und peeren, aber die LED leuchtet meiner Meinung nach falsch und die peerID's sind leer. Nach dem Update auf die neue FW und der *.pm-Files funktioniert auch der HMInfo Configcheck nicht mehr.
get hm configcheck lässt mein komplettes FHEM abschmieren...