Homematic wired

[Thorsten Pferdekaemper]

EIn langer Tastendruck löst bei mir folgende Zeilen aus:
2015-12-18 22:59:51 HM485 Buero_Taster press_long: 11
2015-12-18 22:59:51 HM485 Buero_Taster press_long_11
2015-12-18 22:59:51 HM485 Buero_Taster press_long: 11
2015-12-18 22:59:51 HM485 Buero_Taster press_long_11
2015-12-18 22:59:51 HM485 Buero_Taster press_long: 11
2015-12-18 22:59:51 HM485 Buero_Taster press_long_11
2015-12-18 22:59:51 HM485 Buero_Taster press_long: 11
2015-12-18 22:59:51 HM485 Buero_Taster press_long_11
(......)

Das ist ganz normal. Das Gerät sendet das bei einem langen Tastendruck etwa alle 300ms.

Meine Script:
Kueche_Taster_Buerowand_unten.*PRESS_LONG.* {
   if ( Value('WZ_Lampe') eq 'ON') {
      fhem("set WZ_Lampe off");
   } else {
      fhem("set WZ_Lampe on");
   }
}

Lässt aber nur das Licht flackern, bzw. an und ausgehen, solange ich auf dem Schalter bleibe. Das war bei einer äteren Version nicht. Wie umgehe ich nun, dass das Lich an und ausgeht?

Beim nächsten mal lange drücken ist dann eine "12". Scheint hochzuzählen, aber wenn ich auf dem Schalter bleibe, bleibt die Zahl.

Versuch mal im entsprechenden Kanal das Attribut event-on-change-reading auf press_long zu setzen. (Oder .*press_long*., ich hab' das selbst noch nie benutzt.) Dann dürftest Du bei einem langen Tastendruck nur das erste mitbekommen.
...und dann vielleicht noch Kueche_Taster_Buerowand_unten.*press_long:.*. Der Doppelpunkt sollte wahrscheinlich mit rein.

Gruß,
   Thorsten

[Tomili]

Hallo zusammen,

erst mal Danke für die Antworten.

@gevoo: mit Deinem Vorschlag flackert das immer noch (geht an und aus)

@Thorsten:
>>> das Attribut event-on-change-reading auf press_long zu setzen
funktioniert, aber dann werden die *short* events scheinbar nicht mehr ausgeführt

Noch jemand Ideen? Kurz gesagt will ich einfach bei einem kurzen drücken die
ein Lampe an machen, beim langen eine andere.

Gibt es sonst noch irgendwo Dokumentationen zum Programmieren von FHEM?
Oder am besten Beispiel-Scripte?

Gruss,
Tomili

[swhome]

Setze event-on-change-Reading auf press_long,press_short, dann kommen beide Ereignisse.

[Thorsten Pferdekaemper]

Setze event-on-change-Reading auf press_long,press_short, dann kommen beide Ereignisse.

...genau. Das hat nicht direkt etwas mit HMW zu tun. Das HM485-Modul macht da nichts spezielles. Siehe auch hier: http://www.fhemwiki.de/wiki/Event-on-change-reading.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

habe die Version aus dem dev 0.7.35 für den Rolloaktor etwas angepasst. Da Du jetzt die Readings erweitert hast, hat sich das etwas vereinfacht.
Es betrifft nur die sub HM485_ProcessResponse aus 10_HM485.pm.
Wenn Du diese Datei mit der Versionsnummer 0.7.35a mit ins git-dev einspielen könntest?

Hi,
ich habs eingecheckt, aber mit Versionsnummer 0.7.36. ("Vereinfachung für HMW_LC_BL1_DR")
So richtig glücklich bin ich damit aber nicht:

• Es handelt sich um Spezialcoding für ein bestimmtes Device.
• Es "erweitert" sozusagen das Device selbst. Meiner Meinung nach hat so etwas nichts im Modul zu suchen. Wenn das Device keine regelmäßigen Rückmeldungen gibt, dann ist das halt so. ...auch wenn's unschön ist.

Gruß,
   Thorsten

[Tomili]

>>> Setze event-on-change-Reading auf press_long,press_short, dann kommen beide Ereignisse.

Super. Danke. So hat es funktioniert.
Wenn ich was zur Unterstützung tun kann, teilt es mir mit.

Gruss,
Tomili

[Thorsten Pferdekaemper]

Wenn ich was zur Unterstützung tun kann, teilt es mir mit.

...immer die neuste Version einspielen und testen.

[Harox]

Hallo Thorsten,

ich lese und teste schon seit einiger Zeit sporadisch auf diesem Thread mit. Jetzt wird das Thema bei mir aktueller.

Zuerst einmal vielen Dank an dich und an gevoo für eure unermüdliche und sehr gute Arbeit.

In meinem Versuchsaufbau habe ich ein HMW-LGW,  ein HMW_IO_12_Sw14_DR und ein HMW_IO_12_Sw7_DR. Die FHEM läuft auf einer Raspi PI. Alles ist direkt im LAN verbunden.

Ich habe gerade einige Versuche mit den Peering Aktionen gemacht, dabei ist mir aufgefallen, dass bei gleichzeitiger Ansteuerung mehrerer Ausgänge auf dem 12/7, die Status der Ausgänge nicht oder nur teilweise in der FHEM Oberfläche aktualisiert werden.

Dann gleich noch eine Frage eines FHEM-Neulings. Kann ich für die Weiterverarbeitung einen Eingangs auch eine einfache on/off Information statt press_short erzeugen?

Gruß Harald

[Thorsten Pferdekaemper]

Zuerst einmal vielen Dank an dich und an gevoo für eure unermüdliche und sehr gute Arbeit.

Danke für die Rückmeldung.

Ich habe gerade einige Versuche mit den Peering Aktionen gemacht, dabei ist mir aufgefallen, dass bei gleichzeitiger Ansteuerung mehrerer Ausgänge auf dem 12/7, die Status der Ausgänge nicht oder nur teilweise in der FHEM Oberfläche aktualisiert werden.

Das liegt daran, dass die Devices in dem Fall die Rückmeldung nur für einen Kanal liefern. D.h. FHEM weiss gar nicht, dass das Device auch noch einen anderen Kanal geschaltet hat. Ein möglicher Workaround ist, in der Peering-Konfiguration für den zweiten Aktor-Kanal ein kleines Delay einzustellen. Oft reichen hier 200ms schon aus.
Ansonsten könnte man sich was mit notify und at oder so bauen.
Ich würde das nur sehr ungern ins Modul HM485 einbauen, da das Modul meiner Meinung nach einfach nur das weitergeben soll, was das Device nun eben macht.

Dann gleich noch eine Frage eines FHEM-Neulings. Kann ich für die Weiterverarbeitung einen Eingangs auch eine einfache on/off Information statt press_short erzeugen?

Bei den Eingängen, die Dir press_short/long (wie HMW_IO_12_Sw7_DR) liefern ist das nicht sinnvoll. Beim HMW_IO_12_Sw14_DR ist das doch schon so, oder?
Der Punkt ist, dass es Taster- und Schalterschnittstellen gibt. Erstere liefern eben press_short/long, letztere einen Zustand.
Gruß,
    Thorsten

[Harox]

Hallo Thorsten,

vielen Dank für deine Antwort.

Ein möglicher Workaround ist, in der Peering-Konfiguration für den zweiten Aktor-Kanal ein kleines Delay einzustellen. Oft reichen hier 200ms schon aus.

Das hat funktioniert.

Bei den Eingängen, die Dir press_short/long (wie HMW_IO_12_Sw7_DR) liefern ist das nicht sinnvoll. Beim HMW_IO_12_Sw14_DR ist das doch schon so, oder?
Der Punkt ist, dass es Taster- und Schalterschnittstellen gibt. Erstere liefern eben press_short/long, letztere einen Zustand.

Dann muss ich mir hier etwas anderes einfallen lassen.

Gruß Harald

[Thorsten Pferdekaemper]

Dann muss ich mir hier etwas anderes einfallen lassen.

Wenn Du sagst, was Du damit machen willst, dann könnte Dir vielleicht jemand noch einen Tipp geben.

[Harox]

Hallo Thorsten,

ich habe mir vor einiger Zeit für das 12/14er Modul ein Perl-Script geschrieben, das ich jetzt aber mit den Eingängen des 12/7er Modul betreiben möchte.
Im Script werden 2 Eingänge gegenseitig verriegelt.
Beim Aufruf der Scripts bekomme ich jetzt aber auch beim nicht betätigten Eingang den Status press_short_x. Somit kann ich auf Anhieb nicht mehr feststellen welcher Eingang gerade betätigt wurde.

Gruß Harald

[Thorsten Pferdekaemper]

ich habe mir vor einiger Zeit für das 12/14er Modul ein Perl-Script geschrieben, das ich jetzt aber mit den Eingängen des 12/7er Modul betreiben möchte.
Im Script werden 2 Eingänge gegenseitig verriegelt.
Beim Aufruf der Scripts bekomme ich jetzt aber auch beim nicht betätigten Eingang den Status press_short_x. Somit kann ich auf Anhieb nicht mehr feststellen welcher Eingang gerade betätigt wurde.

Es war der Eingang mit dem Event...
Key-Channels haben keinen Status sondern nur Events. Da hast Du wohl kaum eine Chance. Falls das für einen Rollladen ist, dann sollte man sowieso die Ausgänge (am Besten mechanisch) gegeneinander verriegeln und nicht die Eingänge.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,

man kann jetzt das ganze etwas einfacher installieren und updaten, zumindest wenn man auf der dev-Version ist oder sein möchte.

Code Auswählen Erweitern


update all https://raw.githubusercontent.com/kc-GitHub/FHEM-HM485/dev/controls_hm485.txt

Im Kommandofeld sollte es tun. Man wird dann auf den Event-Monitor weitergeleitet und sollte dort zumindest ein paar Sekunden warten.
Aber nochmal deutlich: Das ist die dev-Version! (...was eigentlich nicht schlimm ist, aber es sollte sich nachher niemand beschweren.)

Rudolf hat außerdem einen Mechanismus eingebaut, mit dem man das in den normalen FHEM-Updateprozess integrieren kann. Ab morgen müsste auch folgendes gehen:

Code Auswählen Erweitern


update add https://raw.githubusercontent.com/kc-GitHub/FHEM-HM485/dev/controls_hm485.txt

Danach wird dann HM485 bei jedem "update" automatisch mitgenommen.
Die lokale commandref enthält dann auch alles zu HM485 und HM485_LAN.
(Siehe auch hier: http://forum.fhem.de/index.php/topic,45121.msg378669.html#msg378669.)

Gruß,
   Thorsten

[zwockel]

Hallo,
ich habe folgendes Problem:
Woran kann es liegen, dass im logfile folgendes reingeschrieben wird:
2015.12.24 10:31:14 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/10_HM485.pm line 2479.
2015.12.24 10:31:14 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/10_HM485.pm line 2480.
Ich nutze die dev Version 10_HM485.pm Version 0.7.24.
Funktioniert soweit auch alles - bis auf die unschöne Fehlermeldung.
Bin für jeden Tip dankbar!