HM-SCI-3-FM unterschiedliche eventDlyTime setzten

[sherwood]

Ich versuche für unterschiedliche channels (Kontakt) unterschiedliche eventDlyTime zu setzten.
Das ganze wird auch in der console/web richtig angezeigt. Sobald aber die Daten an den SCI übertragen werden, werden alle channels mit den (letzten gesetzten) Wert alle überschrieben (gleich gesetzt).

Ist das normal, dass man nur eine eventDlyTime für alle Kontakte setzen kann, oder ein Bug?

Code Auswählen Erweitern

fhem> set Eingangstuer_1x_um regSet eventDlyTime 3
fhem> 2014-01-06 14:32:59 CUL_HM Eingangstuer_1x_um R-eventDlyTime: set_3 s

fhem> set Eingangstuer_2x_um regSet eventDlyTime 10
fhem> 2014-01-06 14:33:18 CUL_HM Eingangstuer_2x_um R-eventDlyTime: set_10 s

Dann die Daten übertragen, Anlernknopf drücken.

Code Auswählen Erweitern

fhem> 2014-01-06 14:33:32 CUL_HM Eingangstuer_1x_um R-eventDlyTime: 10 s
2014-01-06 14:33:33 CUL_HM Eingangstuer_2x_um R-eventDlyTime: 10 s


Anbei das fhem.log mit verbose 5 während der Übertragung, und ein weiteres nach einem anschließenden getConfig.

[sherwood]

Ach, Verisonen sind:

fhem.pl 4519
10_CUL_HM.pm  4563
00_HMLAN.pm 4562

[martinp876]

macht mich ratlos.
beide werte werden geschrieben und akzeptiert. Aber beim Ruecklesen ist nur die 10 zu sehen.
Wenn die 3 zum Schluss gesendet wird, steht sie dann drin?

kann man die msgScPosA und msgScPosB kanalindividuell aendern?

[sherwood]

Es wird immer nur ein Wert für alle geschrieben, oder bei mehreren immer der letzte.
MsgScPosA scheint zu funktionieren, dort behält er für jeden channel individuelle settings bei.

Code Auswählen Erweitern

fhem> set Eingangstuer_Sw_03 regSet eventDlyTime 3
fhem> 2014-01-07 11:12:33 CUL_HM Eingangstuer_Sw_03 R-eventDlyTime: set_3 s

fhem> set Eingangstuer getConfig
fhem> 2014-01-07 11:13:25 CUL_HM Eingangstuer_1x_um R-eventDlyTime: 3 s
2014-01-07 11:13:26 CUL_HM Eingangstuer_2x_um R-eventDlyTime: 3 s
2014-01-07 11:13:27 CUL_HM Eingangstuer_Sw_03 R-eventDlyTime: 3 s

[sherwood]

Also mit der Windows SW verhält es sich ähnlich. Alle drei Kanäle haben den gleichen eventDlyTime, auch wenn sie unterschiedlich angezeigt werden.


Kann das mal jemand mit einem anderen HM-SCI-3-FM nachvollziehen/prüfen?

Meine Firmware ist 1.1.

[Wastegate]

Ich nutze den HM-SCI-3-FM zur Steuerung und Überwachung meiner Alarmanlage. Ein Kanal hängt an einem Fingerprintscanner der die Haustür öffnet und gleichzeitig die Alarmanlage unscharf schaltet. Der zweite Kanal Überwacht die LED`S die Anzeigen das die Anlage scharf ist. Wenn ich die Anlage entschärfe wird gleichzeitig die Information Tür öffnen und LED´S aus gesendet, was bei dem Funkverkehr der HM`s natürlich nicht richtig funktioniert. Als ich dann Versuchte die eventDlyTime für den einen Kanal auf 5 Sekunden zu setzen ist mir das selbe wie dir aufgefallen. Setzt man 5 Sekunden, haben alle Kanäle 5 sec.
Leider hab ich keine Lösung für das Problem, kann es nur Bestätigen.

[martinp876]

Du hast noch einen weiteren Parameter (oder 2)

transmDevTryMax
für das Device

transmitTryMax
je kanal

kann man auf 10 setzen - dann sollte der Schalter 10 mal versuchen zu senden.
Wie Device und Channelparameter zusammenspielen ist mir nicht 100% klar. Ich denke bei dir reicht es, den Kanalparameter zu setzen - 10 ist max.
Kannst du das einmal loggen? Die Zentrale sollte es ja auch sehen können... auch die Wiederholungen. kommen die auch?

[Wastegate]

Ich denke mal das Problem ist der Funkverkehr, die Informationen werden fast zeitgleich gesendet Sodas durch die Überschneidung wahrscheinlich nur eine Information ankommt und verarbeitet wird. (Zumindest sieht das so im Logfile aus). Wenn sich pro Kanal eine sendeverzögerung einstellen lies wäre mein Problem gelöst. Aber Danke für den Tipp. Ich werde am Wochenende mal Probieren und ein Log mit anhängen.

[sherwood]

Da sich msgScPosA ja auch getrennt einstellen lässt scheint das ein Bug in der Firmware zu sein.

Ich hatte zwischenzeitlich auch mal mit ELV Kontakt aufgenommen, die sich an den Hersteller gewendet haben und den Fehler bestätigten.

... Das von Ihnen geschilderte Fehlverhalten konnte durch den Hersteller EQ-3 nachvollzogen werden und entsprechend für das nächsten Release vorgemärkt. Wann diese jedoch erscheinen wird konnte uns dieser heute leider noch nicht mitteilen...

Tja, schei...

Wann soll ich jetzt wissen wann und wo ich ein funktionierendes Teil her bekomme ohne es zu testen?
Da muss ich mir wohl was anderes ausdenken




@Martin
habe das Ding schon zurückgeschickt, da noch ein Widerstand defekt war. Ich glaube aber damit mein Problem nicht gelöst zu bekommen.
Ich benötige definitiv eine Schaltverzögerung für den ersten Kanal von ca. 10s und für den anderen 180s.
Könnte das ganze natürlich auch über FHEM machen, da der 2 Kanal aber alles abschalten soll, hilft mir das auch nicht viel. Außerdem ist das direkte peeren ja das schöner (wenn FHEM mal nicht läuft oder will)

Muss dann wohl zwei einzelne devices kaufen (teuer teuer und Batterie Verschwendung)

[sherwood]

Das Problem soll wohl am USB/LAN liegen.

Das Update betrifft Zentrale (CCU1/CCU2) bzw. Konfigurationsadapter (LAN/USB) und kann daher vom Endkunden durchgeführt werden.

Kann das sein?

[martinp876]

welcher update?
der Text ist aus den Zusammenhang gerissen. Update eines  SCI über HMLAN oder update des HMLAN?
Von welchen Versionen reden sie? Welche Version hat den Bug nicht mehr?

[sherwood]

Noch gibt es kein Update. Aber wenn es eins geben soll, dann soll es für die CCU oder HM-USB/LAN sein.
Die Firmware des HM-SCI-3 scheint wohl OK zu sein.

Deshalb die Frage, kann es sein den Fehler des eventDlyTime setzen in der Firmware des SCI liegt oder durch die Übertragung des HM-LAN/USB?

[martinp876]

nun, da kann ich nur raten.
Ich vermute, dass
- es kein übertragungsproblem ist
- es ein Problem der addressierung ist (HM nutzt die falsche Adresse)
im 2teren fall werden wir eine änderung im XML file sehen und werden es nachziehen.

[sherwood]

So, jetzt habe ich einen neuen HM-SCI-3-FM mit Firmware 1.2.
Leider ist der Fehler unterschiedliche eventDlyTime für unterschiedliche Chanel immer noch da.

@Martin, wie/wo kann ich den sehen ob es Änderungen an der XML file gibt? Gab es mittlerweile schon ein Update?

[martinp876]

nur, wenn du die XML vergleichst.
Das hilft dir hier aber nicht - das XML geht davon aus, dass die Werte unterschiedlich sind - es ist ein FW bug.