Homematic krieg ich nicht hin

[Samsi]

>>Also alle Geräte resetten und aus fhem löschen,
Nein bloß nicht, das wäre völlig unnötig.

Du installierst die Windows Software (wenn Sie sie schon installiert ist, auch gut)
Dann schaust Du im Ordner C:\Users\All Users\Bidcos-Service\ids.   Datei ids enthält die HMID in dezimaler schreibweise. Dort muss den HMID von FHEM rein.

Also wenn Du in FHEM Deine ID auf z.B. 0000CC für den HMLAN adapter gestzt hast, dann nimmst Du den Windows Taschenrechner, stellst den auf Wissenschaftlich um und dann HEX->DEC umrechnen. Das dezimale schreibst Du dann in die Datei ids.

Jetzt lernst Du die Komponenten die Du mit Windows bearbeiten willst einfach dort an. Wenn in FHEM und Windows die gleiche HMID verwendet wird passiert nichts weiter als dass das Gerät in die Windows Software eingetragen wird.

Bsp:

Du haste einen Handsender Button1 der hat z.B. die ID 0000AA den hast Du schon in FHEM gepairt. Dadurch wurde in dem Handsender eine Verknüpfung angelegt das ein Funkbefehl von 0000AA an 0000CC gesendet werden soll. Durch erneutes anlernen mit der gleichen HMID ändert sich dadurch nichts. Es funktioniert nach wie vor mit FHEM.
Hättest Du aber in der Windows Software eine andere HMID z.B. 0000FF würde das Pairing im Sender überschrieben (es kann immer nur eine 'Zentrale' gepairt werden) und ab sofort würde ein Funkbefehl von 0000AA an 0000FF gesendet werden. Wenn Du dann zurück zu FHEM gehst bekommt der HMLAN Adapter aber wieder die ID 0000CC und würde sich nicht angesprochen fühlen. Der Sender würde es dann nämlich immer noch an 0000FF senden aber keine Bestätigung bekommen (weil Bidirektional), es mehrmals versuchen (erhöhter Batterieverbrauch) und dann den Befehl am Ende mit einer roten Lampe Quittieren.

Wenn Du jetzt noch eine Direkte GEräteverküpfung hinzufügst, z.B. um einen Aktor (0000BB) zu schalten, dann würde im Sender folgende Verknüpfungen stehen und für jede ein Funkbefehl gesendet:

0000AA->0000CC
0000AA->0000BB

Wenn jetzt die Zentrale 'Ausfällt' wird trotzdem noch der Befehl von 0000AA->0000BB gesendet und der Aktor geschaltet. Das ganze hat aber noch einen kleinen Nachteil:
Der Sender versucht den Empfänger mehrfach zu erreichen (wie oft kann man auch einstellen). In der Zeit macht er nichts anderes. Wenn also die Zentrale nicht erreichbar ist, dauert es ein paar Sekunden bis er aufgibt und dann die direkte Verknüpfung schaltet (aber wenigstens schaltet er irgendwann, im Ernstfall stehst Du dann wenigstens nicht ganz im Dunkeln)

Das kannst Du verhindern, indem Du, nachdem Du alle Einstellungen gemacht hast, den Sender (0000AA) wieder in der Windows Software unpairst. FHEM  bleibt unangetastet. Das macht auch noch aus einem anderen Grund Sinn, z.B. bei batteriebetriebenen Sendern, erhöht jeder zusätzliche Funkbefehl den Stromverbrauch. Und obwohl der Sender nun keinen Befehl mehr an die Zentrale schickt kann FHEM den Befehl von dem Sender an das direkt verknüpfte Gerät mitlesen und verarbeiten.

Es macht also durchaus Sinn bei einigen Geräten diese am besten gar nicht mit der Zentrale gepairt zu lassen. Solltest Du irgendwann doch wieder Einstellungen mit der Windows Software machen wollen, dann pairst Du den eben noch mal kurz. Natürlich geht das auch alles allein mit FHEM, aber gerade bei den Experteneisstellungen, Fand ich die Windows Software eine große Hilfe weil man dort erst mal eine guten Überblick bekommt was die einzelnen HM Geräte überhaupt alles für Einstellungen haben mit denen man erst mal einfach rumspielen kann. Meine HM-LC-Sw1PBU-FM z.B. hab ich im Expertenmodus so konfiguriert, das bei einem Kurzen Tastendruck nach unten das Licht sofort ausgeht, bei einem langen aber erst nach 10 Sekunden. Gut wenn man z.B. eine offene Küche hat, das Licht im Wohnzimmer aber aus ist. Anstatt das Licht also erst im Wohnzimmer einzuschalten, drücke ich einfach einmal lang und haben dann genügend zeit das Wohnzimmer zu durchqueren.

Viele Grüße

[locodriver]

@Samsi:

Danke für die ausführlichen Hintergrundinfos (und das Ersparen der Resets).
Zur Erklärung: Ich hatte ursprünglich eine CUNO als Funkschnittstelle, da diese aber (bis jetzt?) den TC und VD nicht unterstützt, bin ich auf den HMLAN umgestiegen, ohne mich weiter mit dessen Möglichkeiten zu beschäftigen - das werde ich wohl mal nachholen müssen.
Das Registerschreiben ist ja wirklich auch ein Grund, die Win-Software zu nutzen. Bei den z.T. "kryptischen" Registerwerten können doch ziemlich schnell Fehler entstehen. Das will ich natürlich vermeiden, da ich nur ein Produktivsystem betreibe (und das soll eigentlich auch so bleiben).

Einstweilen erst mal Danke

Uwe

[martinp876]

Hi,

pairen und auch unpairen kann man auch direkt mit FHEM.
Das einstellen der Register sollte in FHEM ähnlich bis genauso funktionieren wie in der Windows software - basis sind die gleichen XML daten.

Das Argument mit längerer Batterielaufzeit durch "nicht pairen" verstehe ich nicht. Entweder sendet der Sensor regelmässig Daten an die Zentrale (MDIR die Helligkeit) - wenn man nicht pairt sieht man diese wahrscheinlich nicht. Remotes senden, auch wenn gepairt, keine zusätzlichen Daten (meine jedenfalls). Den Vorteil kann ich nicht sehen.

Wenn man Sicherheitsbedenken hat sollte man sich unbedingt mir AES beschäftigen. Bedenken bei einem Lichtschalter habe ich kaum. Falls hier einer etwas macht werde ich ggf aktionen ergreifen. Zugangskontrolle ist eine komplett andere Baustelle.

Ausser fuer AES Einstellungen  sehe ich nicht die Notwendigkeit die Win-SW zu nutzen.

Gruss Martin

[gandy]

Hi Martin,

AES und Windows-Software ist mein Stichwort, ich habe seit einigen Tagen massive Probleme mit meinen Rolladenaktoren (die für Markenschalter, siehe Link ), die augenscheinlich mit AES zusammenhängen. Der Workaround sieht momentan so aus, dass ich FHEM beende, die Windowssoftare LAN-Konfigurator starte, einige Sekunden warte (sonst mache ich damit nichts), wieder beende, FHEM neu starte und dann einige Minuten bis mehrere Stunden wieder Ruhe habe.

Hab schon zwei wireshark Mitschnitte gemacht, was die Windowssoftware beim Start an den HMLAN schickt, da komm ich im Moment aber nicht dran, ich wollte dazu heut abend noch was in o.g. Thema schreiben. Oder soll ich die Infos per PM schicken?

Grüße,
Andy.

[martinp876]

Hallo Andy,

kannst du einmal schicken.
Habe keine Ahnung was das sein kann. Die Windows-SW veranlasst das Setzen der Keys falls AES eingeschaltet ist. Dies wird in HMLAN und in den Devices gespeichert. Falls ein Device AES fordert muss der Sender die AES anfrage beantworten.

- ist AES am Rolladenaktor eingeschaltet?
- hast du einen Mitschnitt wenn der Aktor nicht mehr funktioniert?

Gruss Martin

[Samsi]

Hallo Martin,


"Das einstellen der Register sollte in FHEM ähnlich bis genauso funktionieren wie in der Windows software - basis sind die gleichen XML daten."
Sicherlich kann man das mit FHEM und den Registern alles in FHEM irgendwie machen. Niemand behauptet das das nicht auch mit FHEM geht. Nur kann man aus der CommandRef schlecht ersehen was überhaupt machbar ist. Z.B.  damm man einem Handsender so kofigurieren kann, das er nur bei Doppelklick sendet. Oder meine Fensterkontakte, die LED leucht-zeiten verkürzt oder ganz abschaltet(spart auch Batterie). Oder dass man einem Wand Unterputz Dimmer auch so konfigurieren kann, das er bei einem langen Tastendruck nur bis 10% herunter dimmt, etc. Mit der Windows Software sieht man erst mal welche Möglichkeiten es überhaupt gibt. Den blanken Registern sieht man das nicht an. Und selbst jetzt, mit dem Wissen das es möglich ist, wüsste ich nicht wie ich mit Hilfe der CommandRef und den Registern das alles einstellen kann. Ist auch auch nicht schlimm, mich stört es nicht, ab und zu mal zur Windows Software zu wechseln, andere FHEM Entwicklungen sind wichtiger als jetzt speziell irgendwelche Homematic Einstellungen zu vereinfachen.


"Das Argument mit längerer Batterielaufzeit durch "nicht pairen" verstehe ich nicht. "
Es geht darum, das wenn man ein direktes Gerätepairing hat und ein Pairing mit der Zentrale, der Sender 2 Funkbefehle sendet (das ist jetzt unabhängig von der verwendeten Software). Wenn man aber nur das direkte Gerätepairing verwendet, dann sollte man darüber nachdenken, das Pairing mit dem HMLAN wieder zu löschen, dann wird nur ein Funkbefehl gesendet, und somit weniger Energie verbraucht, außerdem blockiert dann nicht der Sender (für ein paar sekunden) falls die Zentrale mal nicht erreichbar ist. Denn man sieht ja auch ohne Zentralenpairing das der Handsender einen Befehl direkt an einen Aktor gesendet hat und manchmal reicht das ja aus.


Viele Grüße

[martinp876]

Nur kann man aus der CommandRef schlecht ersehen was überhaupt machbar ist

korrekt. Das Kommando ist beschrieben - die Register sind (sehr Kurz) in get regList geschrieben, get regList selbst im Commandref. In der Windows-SW hatte ich nicht das Gefühl eine Beschreibung gefunden zu haben - hast du eine?

einem Handsender so kofigurieren kann, das er nur bei Doppelklick sendet.

geht das? Bei welchem Sender? Ich dachte er sendet bei doppelklick nur einmal. Hast du ein Beispiel und hast es getestet? Bin ich interessiert.

bei einer HM-RC-4-2 kann man einstellen:
register | range        | peer     |exp| description
dblPress |   0 to 1.5s  |          |exp| time to detect double press
longPress | 0.3 to 1.8s |          |exp| time to detect key long press

Oder meine Fensterkontakte, die LED leucht-zeiten verkürzt oder ganz abschaltet

hast du einen RHS gemeint?
Internals:
   DEF        332211
   TYPE       CUL_HM
Attributes:
   model      HM-SEC-RHS
   subType    threeStateSensor

get x regList
list:         register | range           | peer     |exp| description
   0: cyclicInfoMsg    |   - to -        |          |   | cyclic message options:on,off
   0: intKeyVisib      |   - to -        |          |exp| visibility of internal channel options:visib,invisib
   0: pairCentral      |   0 to 16777215 |          |   | pairing to central
   0: transmDevTryMax  |   1 to 10       |          |exp| max message re-transmit
   1: eventDlyTime     |   0 to 7620s    |          |   | event delay time
  1: ledOnTime        |   0 to 1.275s   |          |exp| LED ontime
   1: msgRhsPosA       |   - to -        |          |exp| Message for position A options:tilted,open,closed,noMsg
   1: msgRhsPosB       |   - to -        |          |exp| Message for position B options:tilted,open,closed,noMsg
   1: msgRhsPosC       |   - to -        |          |exp| Message for position C options:tilted,open,closed,noMsg
   1: transmitTryMax   |   1 to 10       |          |exp| max message re-transmit
   4: expectAES        |   - to -        | required |   | expect AES options:on,off
   4: peerNeedsBurst   |   - to -        | required |   | peer expects burst options:on,off

.. einem Wand Unterputz Dimmer auch so konfigurieren kann, das er bei einem langen Tastendruck nur bis 10% herunter dimmt..

3: shOnMinLevel     |   0 to 100%        | required |exp| minimum PowerLevel
   3: lgOnMinLevel     |   0 to 100%        | required |exp| minimum PowerLevel
bei short auch - und zwar für jede Trigger-Quelle getrennt. auch der Max level. Ist die Beschreibung zu schlecht?
Geht bei allen dimmern.

Mit der Windows Software sieht man erst mal welche Möglichkeiten es überhaupt gibt.

siehe regList - auch im Commandref

...wie ich mit Hilfe der CommandRef und den Registern ...

falscher Ort zum Suchen!

mich stört es nicht, ab und zu mal zur Windows Software zu wechseln

kannst du gerne machen. mich erstaunt nur, dass du in der HM-PC-SW so viel mehr findest. Aber offensichtlich hast du die Beschreibung in FHEM noch garnicht gesucht/gefunden. Kann man sicher verbessern...

Gerätepairing hat und ein Pairing mit der Zentrale, der Sender 2 Funkbefehle sendet

Kann ich nicht nachvollziehen. Habe gerade einfach einmal mit einem RC4 getestet. Der ist gepairt und sendet nur einen trigger. Was sollte der auch an die Zentrale senden? Einen Status hat er selbst ja nicht. Von welchen Device redest du konkret?

..blockiert dann nicht der Sender (für ein paar sekunden) falls die Zentrale mal nicht erreichbar ist

was wären 750ms. Nun ja - aber die Message sehe ich garnicht. So etwas kenne ich von Aktoren - und die haben a) meist keine Batterien und es ist b) meist wichtig es in der Zentrale zu loggen. Will man es ohne Zentrale/logging/remotesteuerung kann man erheblich billiger in jeden Baumarkt funksteckdosen kaufen.

Denn man sieht ja auch ohne Zentralenpairing das der Handsender einen Befehl direkt an einen Aktor gesendet hat und manchmal reicht das ja aus.

zum Loggen reicht dies vollauf aus. Der Sender wird auch nur so festgestellt da ich die 2. Message bei remotes nicht kenne.

Du kannst es selbstverständlich machen wie du es einfacher hast. Dennoch enttäuscht mich dass einige Funktionen wie get regList übersehen/ignoriert werden. Aber jemand(Rudi?) hat jetzt auch die "get" funktionen im webFrontend sichtbar gemacht. Das könnte helfen dass die User die Funktionen finden, welche im Commadnref übersehen werden.

Würde mich interessieren, was du zu regList sagst - oder ob es dir einfach nicht zugesagt hat. Beachte, dass es "entity sensitive" ist. Es werden nur für diese Entity möglichen Register angezeigt. Sollten channels unterscheidliche Register haben kommen nur diese - wie bei Kommands eben auch

Gruss Martin

[Samsi]

Hallo Martin,

"Würde mich interessieren, was du zu regList sagst - oder ob es dir einfach nicht zugesagt hat."
In der Tat habe ich das am Anfang, vor ca. 1 Jahr als ich angefangen habe auch damit probiert. Der Erfolg war eher bescheiden und mit der Windows Software hatte ich dann erst mal schnellere Erfolge. Z.B. hatte ich genau das hier auch probiert: Link
Das hab ich mit der Windows Software auch alleine hin bekommen.

"Dennoch enttäuscht mich dass einige Funktionen wie get regList übersehen/ignoriert werden."
Ja das ist leider so Kommandozeilen-basierten Systemen. Man findet einfach Sachen nicht so leicht, besonders als Einsteiger.  Dafür hat man später oft mehr Möglichkeiten, da gebe ich Dir völlig recht. Ich will noch mal betonen das ich NICHT gesagt habe das es mit FHEM nicht geht.
Wenn man versucht unter Windows etwas simples wie "tail -f" zu machen, dann kommt man da mit Bordmitteln schon nicht mehr weit.

"Du kannst es selbstverständlich machen wie du es einfacher hast."
Klar, denn für alles was für mich einfacher ist, muss ich niemanden fragen. Er reicht ja schon, wenn ich andere mit Fragen zu anderen Dingen 'nerve' ;) Und gerade am Anfang gibt es halt viele Dinge die man nicht weiss.

"Aber jemand(Rudi?) hat jetzt auch die "get" Funktionen im webFrontend sichtbar gemacht."
Das werde ich mir mal anschauen, hab gerade erst auf 5.4 Geupdated. Die meisten neuen Features fallen einem ja nicht gleich auf. Was mir aber gleich aufgefallen ist, ist dass neue devStateIcons Attribut, ganz einfach weil es direkt unter dem Device dafür einen Link gibt und man dort einfach ein Bild auswählt. Da klickt man mal drauf und schon hat man ein neues Attribut erstellt und kann sehen was passiert. Das meine ich mit schnellem Erfolg. Man hat erst mal ein aha Erlebnis man sieht sofort, was das Attribut macht und man weis, wenns einenm nicht gefällt löscht man es wieder.


"was wären 750ms. Nun ja"
Pro Wiederholung. Voreingestellt sind ja 3 oder 6 Wiederholungen. Hinzu kommt das dann der Sender auch noch pausen einlegt, weil er seine Funkzeit sonst überschreitet. Ich würde das nicht schreiben, wenn es bei mir nicht tatsächlich ein Problem war als die Zentrale nicht an war. Der Sender ( HM-SCI-3-FM) hat den Befehl an die Zentrale geschickt und keine ACK bekommen weil die Zentrale aus war, hat es dann mehrfach wiederholt und erst danach an das direkte gepairte Device den Funkbefehl gesendet. Das licht ging dann mit mehreren Sekunden Verspätung an.


Zu den mehrfachen Funk-Befehlen melde ich mich noch mal später wenn ich wieder am  FHEM Server bin, dann werde ich mal einen meiner Sender so konfigurieren und das noch mal nachstellen, wer wweis, vielleicht hast Du recht und ich habe wirklich einen Fehler gemacht.


Viele Grüße

[martinp876]

Hallo Samsi,

vor ca. 1 Jahr als ich angefangen habe auch damit probiert. Der Erfolg war eher bescheiden

nun, seit einem Jahr hat sich viel getan - aber egal. Da hat man die Registerwerte noch als Zahlen eingeben müssen. da habe ich gerade erst angefangen.

Ja das ist leider so Kommandozeilen-basierten Systeme

nun, etwas web-frontend hat FHEM schon.

hab gerade erst auf 5.4 Geupdated

kein Update zwischendurch? die Versionen haben im Vergleich zum "kontinuierlichen Update" fast keinen Unterschied

"was wären 750ms. Nun ja"
Pro Wiederholung

250ms je Wiederholung. Bei 3 Versuchen sind dies sogar nur 500ms - komplett. 6 Wiederholungen sind selten, manchmal kann man es einstellen.

Hinzu kommt das dann der Sender auch noch pausen einlegt, weil er seine Funkzeit sonst überschreitet.

aber nicht in diesem Zeitrahmen.

SCI-3 - da hat du natürlich besondere möglichkeiten:
   0: cyclicInfoMsg  | - to -       |          |   | cyclic message options:on,off
   0: intKeyVisib    | - to -       |          |exp| visibility of internal channel options:visib,invisib
   0: pairCentral    | 0 to 16777215|          |   | pairing to central
   0: transmDevTryMax| 1 to 10      |          |exp| max message re-transmit
   1: eventDlyTime   | 0 to 7620s   |          |   | event delay time
   1: msgScPosA      | - to -       |          |exp| Message for position A options:open,closed,noMsg
   1: msgScPosB      | - to -       |          |exp| Message for position B options:open,closed,noMsg
   1: transmitTryMax | 1 to 10      |          |exp| max message re-transmit
   4: expectAES      | - to -       | required |   | expect AES options:on,off
   4: peerNeedsBurst | - to -       | required |   | peer expects burst options:on,off

Die Wiederholungen kannst du einstellen - und der default ist 6. Macht 1,25sec - kannst du aber aendern.

Achtung: bei eventDlyTime ist mir die Berechnung nicht klar - oder, ich habe sie nicht verifiziert. Kannst du dies machen? einen Wert einstellen (mit PC SW ;-) ) und dann die Register Roh lesen. 3 Werte wären gut
5 sec
10 sec
500 sec

das sollte reichen.

Gruss Martin

[Samsi]

Hallo Martin,

geht das? Bei welchem Sender? Ich dachte er sendet bei doppelklick nur einmal. Hast du ein Beispiel und hast es getestet? Bin ich interessiert.

Ich weiss nicht genau wie Du mich verstanden hast, aber der sendet auch bei mir nur einmal. Also wenn Du in der Zeit doppelt drückst sendet er short, und wenn Du doppelt drückst und dann länger gedrückt hältst sendet er long. Ich vermute stark das ist das gleiche wie:
dblPress | 0 to 1.5s | |exp| time to detect double press

Ich habe jetzt mal ein bischen mit regList gespielt. Jetzt, wo ich schon eine Zeitlang die ganzen Einstellungen mit der PC Software gemacht habe (insbesondere auch die Experteneinstellungen) verstehe ich auch FHEM besser ;)

nun, etwas web-frontend hat FHEM schon.

Danke, ich habs jetzt gefunden ;) Im ernst, wenn man sich auskennt, dann geht das auch mit FHEM ganz gut. Als Anfänger hat es mir persönlich aber sehr geholfen, das es da noch was anderes gab. Ich bin mir jetzt nicht sicher ob ich das regList damals schon hatte, die Anzeige kommt mir aber jetzt umfangreicher vor.

kein Update zwischendurch?

Ich glaube nicht. Ich mache Updates nur wenn ich weiss ich habe genügend Zeit auch alles wieder zum laufen zu bringen (falls was nicht geht, kann ja immer mal vorkommen).
 

Achtung: bei eventDlyTime ist mir die Berechnung nicht klar - oder, ich habe sie nicht verifiziert. Kannst du dies machen? einen Wert einstellen (mit PC SW ;-) ) und dann die Register Roh lesen.

Gerne, aber erst im nächsten Beitrag. Ich muss da auch erst mal den SCI-3 ausbauen.

[Samsi]

Hallo Martin,

ich habe jetzt das Problem (oder eher Phänomen) mit den 2 Funkbefehlen untersucht. Zunächst einmal habe ich es mit dem HM-RC-4-B getestet und diesen mit einem Aktor und der Zentrale Gepairt. Tatsächlich sendet dieser den befehl nur and den Aktor:

2013-08-20 23:57:11 CUL_HM keyRemoteSchlafzimmer_Btn_03 Short (to licht_EG_Kueche)
2013-08-20 23:57:11 CUL_HM keyRemoteSchlafzimmer_Btn_03 trigger: Short_14

Da ich aber weiss was ich gesehen habe, auch wenn es schon fast ein Jahr her ist, habe ich den SCI-3 auch noch mal mit dem HMLAN gepairt:

2013-08-20 22:56:41 CUL_HM schalterKeller open
2013-08-20 22:56:41 CUL_HM schalterKeller contact: open (to HMLAN1)
2013-08-20 22:56:41 CUL_HM schalterKeller open
2013-08-20 22:56:41 CUL_HM schalterKeller contact: open (to aktorKeller)

und wenn ich dann die Zentrale abschalte (oder wie jetzt zum testen einfach eine andere Zentrale paire, die nicht antwortet) dann sieht man auch deutlich den Delay. Ich habe den SCI-3 geöffnet und sofort wieder gesclossen:


2013-08-20 23:16:33 CUL_HM schalterKeller_Sw_02 open
2013-08-20 23:16:33 CUL_HM schalterKeller_Sw_02 contact: open (to AAAAAA)
2013-08-20 23:16:33 CUL_HM schalterKeller_Sw_02 open
2013-08-20 23:16:33 CUL_HM schalterKeller_Sw_02 contact: open (to aktorKeller)
2013-08-20 23:16:33 CUL_HM aktorKeller_Sw_02 level: 100 %
2013-08-20 23:16:33 CUL_HM aktorKeller_Sw_02 deviceMsg: on (to schalterKeller)
2013-08-20 23:16:33 CUL_HM aktorKeller_Sw_02 on
2013-08-20 23:16:33 CUL_HM schalterKeller_Sw_02 open
2013-08-20 23:16:33 CUL_HM schalterKeller_Sw_02 contact: open (to AAAAAA)
2013-08-20 23:16:41 CUL_HM schalterKeller_Sw_02 closed
2013-08-20 23:16:41 CUL_HM schalterKeller_Sw_02 contact: closed (to AAAAAA)
2013-08-20 23:16:41 CUL_HM schalterKeller_Sw_02 closed
2013-08-20 23:16:41 CUL_HM schalterKeller_Sw_02 contact: closed (to aktorKeller)
2013-08-20 23:16:42 CUL_HM aktorKeller_Sw_02 level: 0 %
2013-08-20 23:16:42 CUL_HM aktorKeller_Sw_02 deviceMsg: off (to schalterKeller)
2013-08-20 23:16:42 CUL_HM aktorKeller_Sw_02 off
2013-08-20 23:16:42 CUL_HM schalterKeller_Sw_02 closed
2013-08-20 23:16:42 CUL_HM schalterKeller_Sw_02 contact: closed (to AAAAAA)


Von 23:16:33 bis 23:16:41 vergehen 8 Sekunden, bis der SCI-3 dann closed sendet.
Mir stellt sich die Frage, warum das bei dem Handsender anders reagiert. Denn für mich ist es eigentlich logisch, das der Sender jeweils einen Befehl zu jedem gepairten Gerät sendet, denn er muss ja auch von jedem Gerät eine Antwort verarbeiten. Das Verhalten von dem Handsender ist für mich eher unlogisch.


Hier noch Deine Registerwerte. Sieht so aus als passt es noch nicht ganz ;)

5.00:
R-eventDlyTime 0.5 s
RegL_01: 08:01 20:60 21:05 22:00 30:06 00:00


10.00
R-eventDlyTime 1 s
RegL_01: 08:01 20:60 21:0A 22:00 30:06 00:00


500.00
R-eventDlyTime 480 s
RegL_01: 08:01 20:60 21:88 22:00 30:06 00:00


Viele Grüße

[martinp876]

Hallo Samsi,

mit Sicherheit hat sich seit eine Jahr etwas getan - viel länger bin ich noch garnicht am Kodieren.
Der Umpfang von vor einem Jahr ist nicht mehr vergleichbar, nicht nur im HM Teil von FHEM.

Wenn man mit FHEM-HM mehr machen will als licht an/aus von der Zentrale empfehle ich immer das EinsteigerDoc - hier den HM teil. Ist evtl nicht ganz trivial... aber ich hoffe es erklärt einige Dinge die in HM ablaufen undwie FHEM damit umgeht.

Der SCI-3 sendet einen Status an die Zentrale - was bei einem Handsender keinen Sinn macht. Sinn ist, dass die Zentrale "sicher" informiert ist, da sie eine Quittung senden muss. ggf wird wiederholt. Die Anzahl der Wiederholungen kannst du programmieren - und damit die Wartezeit verkürzen.
Ein SCI3 hat 2 Zustände, die statisch sind. Ein Handsender nur einen. Somit passt das schon.

Danke für den Test
Martin