FHEM Forum

Moin allerseits,

beim Auswerten der Logs ist mir aufgefallen, dass manche Taster beim Betätigen insgesamt 4 Mal ein press_short Event auslösen.
Beispiel Taster im Büro, der am S1 eines HMW_LC_Dim1L_DR (Dimmeraktor) hängt. Dieser hat eine Direktverknüpfung zum L Ausgang eines     
HMW_LC_Sw2_DR (2fach Schaltaktor), wo die Lampe im Büro dranhängt. Beim Drücken passiert gemäss Event Log Folgendes:


2017-03-09 23:24:58 HM485 Taster.OGBuero.CH1 press_short: 34
2017-03-09 23:24:58 HM485 Taster.OGBuero.CH1 press_short_34
2017-03-09 23:24:58 HM485 Taster.OGBuero.CH1 press_short: 34
2017-03-09 23:24:58 HM485 Taster.OGBuero.CH1 press_short_34
2017-03-09 23:24:58 HM485 Licht.OGBuero working: off
2017-03-09 23:24:58 HM485 Licht.OGBuero on
2017-03-09 23:24:59 HM485 Licht.OGBuero working: off
2017-03-09 23:24:59 HM485 Licht.OGBuero on

es wird also 2x das press_short: und 2 mal das press_short_n ausgelöst und folglich der Schaltbefehl 2x ausgeführt.

Ein anderer Taster, der an einem 7fach Schaltaktor HMW_IO_12_Sw7_DR hängt und die Lampe über den selben Aktor Ausgang schaltet, hat das Problem nicht. Hingegen ein anderer Taster am selben Aktor, der eine andere Lampe über einen anderen Dimmer Aktor schaltet wiederum schon. Ich habe übrigens ausschliesslich Direktverknüpfungen zwischen meinen HM485 Komponenten.

Die FHEM Version ist auf dem neusten Stand
Latest Revision 12709
fhem.pl                  13622 2017-03-05 21:37:35Z rudolfkoenig

Ebenso verhält es sich mit den Versionen auf allen Aktoren (wobei EQ3 seit über einem Jahr kein Update mehr liefert)
Nebenher ist mir aufgefallen, dass beim Betätigen eines Tasters, der am S eines Rollladenaktors hängt, nicht nur die Direktverknüpfung ausgelöst (wie gewünscht), sondern gleichzeitig ein Reading dieses Aktors ausgelöst/im Event Log ausgegeben wird. Ausserdem, in äusserst seltenen Fällen, kann es sein, dass ich das Licht im Keller einschalte und gleichzeitig das Licht im Wohnzimmer von 60 auf 100% hochdimmt - obwohl weder eine Verknüpfung besteht noch Taster und Ausgang auf dem selben Aktor liegen.

Wohlgemerkt, die gesamte Anlage besteht aus 39 Aktoren, 90 Tastern, 60 Verbrauchern sowie zahlreichen Funkkomponenten und die Geschichte läuft grundsätzlich einwandfrei. Trotzdem ist die Sache nicht ganz sauber und verbesserungsfähig.

Mein erster Verdacht ist, dass das Problem mit dem BUS zusammenhängt.

• Taster und Ausgang am selben Aktor => ok
• Taster an Aktor A, Ausgang an Aktor B => Ärger

Leider habe ich keine Idee, ob ich A) am richtigen Ort schnuppere und B) wie und an welcher Stelle ich testen soll. Deshalb würde ich mich freuen, wenn mich jemand in die richtige Richtung schubsen könnte.

Merci einstweilen und bis denne
Der Dröhn

Zitat von: droehn am 10 März 2017, 00:31:15
beim Auswerten der Logs ist mir aufgefallen, dass manche Taster beim Betätigen insgesamt 4 Mal ein press_short Event auslösen.

Wenn Du ganz genau hinschaust, dann kannst Du sehen, dass es nur jeweils 2 press_short und 2 state Events sind. Im Prinzip entsprechen nur die echten press_short Events einem vom Bus empfangenen Event. Die state Events macht das Modul. D.h. jeweils zwei Events, die ähnlich aussehen, sind ganz normal. Vier jedoch nicht.

Zitat

Code Auswählen Erweitern


2017-03-09 23:24:58 HM485 Taster.OGBuero.CH1 press_short: 34
2017-03-09 23:24:58 HM485 Taster.OGBuero.CH1 press_short_34
2017-03-09 23:24:58 HM485 Taster.OGBuero.CH1 press_short: 34
2017-03-09 23:24:58 HM485 Taster.OGBuero.CH1 press_short_34
2017-03-09 23:24:58 HM485 Licht.OGBuero working: off
2017-03-09 23:24:58 HM485 Licht.OGBuero on
2017-03-09 23:24:59 HM485 Licht.OGBuero working: off
2017-03-09 23:24:59 HM485 Licht.OGBuero on

Du bist Dir sicher, dass "Taster.OGBueror" und "Licht1.OGBuero.CH1" tatsächlich direkt gepeert sind? Das würde nämlich bedeuten, dass das Problem tatsächlich auf dem Bus liegt und nicht in FHEM. Möglicherweise bekommt der Taster das ACK von Licht nicht mit und sendet nochmal. Allerdings müssten solche Doppel-Sendungen ignoriert werden.
Vielleicht ist es aber auch ganz anders...

Zitat
es wird also 2x das press_short: und 2 mal das press_short_n ausgelöst und folglich der Schaltbefehl 2x ausgeführt.

Das mit dem "folglich" ist nicht ganz richtig. Wenn das wirklich eine Sendungswiederholung ist, dann dürfte das nicht sein. Weißt Du eigentlich sicher, dass der Schaltbefehl zweimal ausgeführt wird, oder kann es auch sein, dass es einfach nur in FHEM doppelt angezeigt wird?

ZitatEin anderer Taster, der an einem 7fach Schaltaktor HMW_IO_12_Sw7_DR hängt und die Lampe über den selben Aktor Ausgang schaltet, hat das Problem nicht.

Das deutet darauf hin, dass tatsächlich die Nachrichten zu verschiedenen Empfängern (einmal zur Zentrale und einmal zum Peer) ankommen. Eigentlich dürfte das aber nichts ausmachen.
Ich habe inzwischen auch den Eindruck, dass die HM-Wired-Aktoren nicht alle gleich reagieren. Manche scheinen zu schalten, wenn sie eine Nachricht von irgendwoher bekommen, andere nur, wenn die Nachricht von einem eingetragenen Peer kommt. Möglicherweise gibt es da sogar ein paar Inkompatibilitäten.

Zitat
Die FHEM Version ist auf dem neusten Stand

Code Auswählen Erweitern

Latest Revision 12709
fhem.pl                  13622 2017-03-05 21:37:35Z rudolfkoenig

Das ist egal. Es kommt auf die Version der HMW-Module an. Mach mal ein "version" und zeige die Zeile von "10_HM485.pm".

ZitatEbenso verhält es sich mit den Versionen auf allen Aktoren (wobei EQ3 seit über einem Jahr kein Update mehr liefert)

Ich wusste gar nicht, dass es da überhaupt updates gibt.

ZitatNebenher ist mir aufgefallen, dass beim Betätigen eines Tasters, der am S eines Rollladenaktors hängt, nicht nur die Direktverknüpfung ausgelöst (wie gewünscht), sondern gleichzeitig ein Reading dieses Aktors ausgelöst/im Event Log ausgegeben wird.

Natürlich ist das so. Die Zentrale bekommt alles mit.

ZitatAusserdem, in äusserst seltenen Fällen, kann es sein, dass ich das Licht im Keller einschalte und gleichzeitig das Licht im Wohnzimmer von 60 auf 100% hochdimmt - obwohl weder eine Verknüpfung besteht noch Taster und Ausgang auf dem selben Aktor liegen.

Das ist sehr seltsam. Es ist ziemlich unwahrscheinlich, dass irgendeine Busstörung gerade das richtige Signal erzeugt, um irgend etwas zu schalten. Da halte ich es eher für wahrscheinlich, dass mit dem Kabeln zu den Taster-Eingängen was nicht stimmt und da irgend etwas "überspringt". Hängt da alles sauber an einer gemeinsamen Masse (GND)?

Gruß,
   Thorsten

ZitatDas ist egal. Es kommt auf die Version der HMW-Module an. Mach mal ein "version" und zeige die Zeile von "10_HM485.pm".

Vielleicht gibt's hier eine heisse Spur, so sieht die Zeile(n) im Bereich HM485 aus:
# $Id: 10_HM485.pm 0743 2016-02-26 09:02:00Z Thorsten Pferdekaemper $
No Id found for 00_HM485_LAN.pm
98_HMinfo.pm             12705 2016-12-03 15:37:05Z martinp876
00_HMLAN.pm              13605 2017-03-05 10:25:35Z martinp876

Ich habe nochmal einen Update durchgeführt, scheint aber nichts Neuses oder so dabei zu sein. In Bezug auf HM485 kommt
2017.03.10 18:44:22 1 : hm485
2017.03.10 18:44:22 1 : nothing to do...

Ist da was, wo ich dran schrauben kann?
Deine anderen Kommentare stelle ich mal zu Gunsten der Übersichtlichkeit zurück.

Grüsse
Der Dröhn

Hi,
das ist Version 0.7.43, also auch das neuste was derzeit stabil läuft.
Tja...
Kannst Du mal im IO-Device (also im HM485_LAN-Device) das Attribut verbose auf 5 setzen und dann diese doppelten Events erzeugen? Das, was dann im Logfile steht, hätte ich gerne.
Gruß,
   Thorsten

Los geht's, ich habe den Taster betätigt.

Output im Event Monitor:
2017-03-10 20:24:31 HM485 Taster.OGBuero.CH1 press_short: 42
2017-03-10 20:24:31 HM485 Taster.OGBuero.CH1 press_short_42
2017-03-10 20:24:31 HM485 Aktor.Dim_6 ACK
2017-03-10 20:24:31 HM485 Taster.OGBuero.CH1 press_short: 42
2017-03-10 20:24:31 HM485 Taster.OGBuero.CH1 press_short_42
2017-03-10 20:24:31 HM485 Aktor.SW2_8 ACK
2017-03-10 20:24:31 HM485 Licht.OGBuero working: off
2017-03-10 20:24:31 HM485 Licht.OGBuero on
2017-03-10 20:24:31 HM485 Aktor.Dim_6 ACK


Output im Logfile:
2017.03.10 20:24:31 5: HM485_LAN: HM485_LAN_parseIncommingCommand: MsgId: 60 Cmd: 101
2017.03.10 20:24:31 4: HM485_LAN: Event:HASH(0x2c57500)
2017.03.10 20:24:31 5: HM485_LAN: dispatch �\017<e�����\000\001/RK\000\000�
2017.03.10 20:24:31 5: HM485_LAN: HM485_Parse: MsgId: 60
2017.03.10 20:24:31 5: HM485_LAN: HM485_Parse: ProcessEvent
2017.03.10 20:24:31 5: HM485_LAN: HM485_ProcessEvent: hmwId = 00012F52 msgData = 4B0000AA
2017.03.10 20:24:31 5: HM485_LAN: HM485_LAN_parseIncommingCommand: MsgId: 61 Cmd: 101
2017.03.10 20:24:31 4: HM485_LAN: Event:HASH(0x2b1e8b8)
2017.03.10 20:24:31 5: HM485_LAN: dispatch �\017=e\000\001\037\e\036\000\001/RK\000\003�
2017.03.10 20:24:31 5: HM485_LAN: HM485_Parse: MsgId: 61
2017.03.10 20:24:31 5: HM485_LAN: HM485_Parse: ProcessEvent
2017.03.10 20:24:31 5: HM485_LAN: HM485_ProcessEvent: hmwId = 00012F52 msgData = 4B0003A8
2017.03.10 20:24:31 5: HM485_LAN: HM485_LAN_parseIncommingCommand: MsgId: 62 Cmd: 101
2017.03.10 20:24:31 4: HM485_LAN: Event:HASH(0x2703370)
2017.03.10 20:24:31 5: HM485_LAN: dispatch �\017>e\000\001/R�\000\001\037\ei\003�\000
2017.03.10 20:24:31 5: HM485_LAN: HM485_Parse: MsgId: 62
2017.03.10 20:24:31 5: HM485_LAN: HM485_Parse: ProcessEvent
2017.03.10 20:24:31 5: HM485_LAN: HM485_ProcessEvent: hmwId = 00011F1B msgData = 6903C800
2017.03.10 20:24:31 5: HM485_LAN: HM485_LAN_parseIncommingCommand: MsgId: 63 Cmd: 101
2017.03.10 20:24:31 4: HM485_LAN: Event:HASH(0x241d1b0)
2017.03.10 20:24:31 5: HM485_LAN: dispatch �\013?e\000\001\037\eY\000\001/R
2017.03.10 20:24:31 5: HM485_LAN: HM485_Parse: MsgId: 63
2017.03.10 20:24:31 5: HM485_LAN: HM485_Parse: ProcessEvent
2017.03.10 20:24:31 5: HM485_LAN: HM485_ProcessEvent: hmwId = 00012F52 msgData =
2017.03.10 20:24:31 5: HM485_LAN: HM485_LAN_parseIncommingCommand: MsgId: 64 Cmd: 101
2017.03.10 20:24:31 4: HM485_LAN: Event:HASH(0x2a81a80)
2017.03.10 20:24:31 5: HM485_LAN: dispatch �\e@e�����\000\001/RA\000\024\000\003\003MEQ0312230
2017.03.10 20:24:31 5: HM485_LAN: HM485_Parse: MsgId: 64
2017.03.10 20:24:31 5: HM485_LAN: HM485_Parse: ProcessEvent
2017.03.10 20:24:31 5: HM485_LAN: HM485_ProcessEvent: hmwId = 00012F52 msgData = 4100140003034D455130333132323330


Der Taster hat die Adresse 00012F52_01.
Aktor.Dim_6 ist da, wo der Taster angeschlossen ist. Dieser hat die Serial MEQ0312230 und das DEF 00012F52
Die Lampe hat die Adresse 00011F1B_04
Aktor.SW2_8 schaltet die Lampe. Dieser hat die Serial MEQ0080022 und das DEF 00011F1B

Edith: der Log Auszug war nicht vollständig, 2 Sekunden später tut der Kollege noch etwas mit dem Schaltaktor des Lampenanschluss' (00011F1B)
2017.03.10 20:24:33 5: HM485_LAN: HM485_LAN_parseIncommingCommand: MsgId: 65 Cmd: 101
2017.03.10 20:24:33 4: HM485_LAN: Event:HASH(0x2b27e18)
2017.03.10 20:24:33 5: HM485_LAN: dispatch �\017Ae\000\000\000\001�\000\001\037\ei\003�\000
2017.03.10 20:24:33 5: HM485_LAN: HM485_Parse: MsgId: 65
2017.03.10 20:24:33 5: HM485_LAN: HM485_Parse: ProcessEvent
2017.03.10 20:24:33 5: HM485_LAN: HM485_ProcessEvent: hmwId = 00011F1B msgData = 6903C800


Edith2, das ist die entsprechende Passage im Event Monitor:
2017-03-10 20:24:33 HM485 Aktor.SW2_8 ACK
2017-03-10 20:24:33 HM485 Licht.OGBuero working: off
2017-03-10 20:24:33 HM485 Licht.OGBuero on


Hi,
ich denke, dass ich eine gute Vermutung habe, was da schiefgeht.

Zitat von: droehn am 10 März 2017, 20:36:30

Code Auswählen Erweitern


2017.03.10 20:24:31 5: HM485_LAN: dispatch �\017<e�����\000\001/RK\000\000�


Das sieht ein bisschen nutzlos aus. Ich glaube, da muss ich mal nachbessern, damit man da auch was erkennt.

Zitat

Code Auswählen Erweitern


2017.03.10 20:24:31 5: HM485_LAN: HM485_ProcessEvent: hmwId = 00012F52 msgData = 4B0000AA
2017.03.10 20:24:31 5: HM485_LAN: HM485_ProcessEvent: hmwId = 00012F52 msgData = 4B0003A8


Das ist der Tastendruck. Es sind zwei Nachrichten: Die erste geht an die Zentrale (Pairing), die andere an den Aktor (Peering). Die "03" steht für Kanal 4 im Aktor.

Zitat

Code Auswählen Erweitern


2017.03.10 20:24:31 5: HM485_LAN: HM485_ProcessEvent: hmwId = 00011F1B msgData = 6903C800


Das müsste jetzt die Antwort des Aktors an den Sensor (also den Taster) sein. Eigentlich würde hier auch ein simples ACK (also eine leere Nachricht) reichen, aber der Aktor erzählt hier sogar "Kanal 4 ist an".

Zitat

Code Auswählen Erweitern

2017.03.10 20:24:31 5: HM485_LAN: HM485_ProcessEvent: hmwId = 00012F52 msgData =


Das ist jetzt ein ACK vom Taster. Das muss so sein, da der Aktor nicht einfach nur ein ACK gesendet hat. Auch wenn der Taster mit der Information über den Zustand des Aktors nichts anfangen kann, muss er trotzdem ein ACK senden.

Zitat

Code Auswählen Erweitern


2017.03.10 20:24:31 5: HM485_LAN: HM485_ProcessEvent: hmwId = 00012F52 msgData = 4100140003034D455130333132323330


Das ist ein "Announce" vom Taster, was etwas seltsam ist. Eigentlich sollte das nur kommen, wenn das Gerät nicht gepairt ist. Ich habe aber die Vermutung, dass es manche Devices grundsätzlich senden.

Zitat

Code Auswählen Erweitern

2017.03.10 20:24:33 5: HM485_LAN: HM485_ProcessEvent: hmwId = 00011F1B msgData = 6903C800


Das kommt jetzt hinterher vom Aktor an die Zentrale. Wahrscheinlich steht "logging_time" für das Gerät auf 2 Sekunden.

Das war jetzt erstmal die Rohanalyse...

Gruß,
   Thorsten

Hi,
so, was machen wir jetzt damit...

1. Die unlesbare Zeile im Log muss weg.
Das habe ich als issue im git aufgenommen:
https://github.com/kc-GitHub/FHEM-HM485/issues/33

2. Auf dem Bus ist im Prinzip alles ok. Die Nachrichten sind alle ok und erklärbar. Ich glaube auch nicht, dass irgend ein Aktor zweimal schaltet, nur die Nachricht darüber wird zweimal verschickt.

3. Die Announce-Nachricht ist ein bisschen seltsam, es kann aber sein, dass das einfach so ist. Sicherheitshalber solltest Du Dir mal das Reading R-centralAddress vom Taster-Device betrachten. Da sollte die Hmwid vom HM485_LAN-Device stehen, ohne "set_" oder irgendwas vorne dran.

4. Natürlich ist es unschön, dass die Events in FHEM doppelt ankommen. Ich muss mir das selbst nochmal genau anschauen, aber ich denke mal, dass eigentlich nur Nachrichten an die Zentrale und an "Broadcast" echte Readings bzw. Events ergeben sollten. Andererseits ist es natürlich schon ganz nett, wenn man in der Zentrale (also FHEM) sieht, was so alles auf dem Bus abgeht. Vielleicht in etwa so, dass man die heutigen Readings nur erzeugt, wenn es an die Zentrale gesendet wird. Alles andere erzeugt Spezial-Readings, die den Namen des Empfängers als Prä- oder Postfix haben.
Ich habe mir überlegt, warum das bisher kaum aufgefallen ist. Wahrscheinlich deshalb, weil Peerings oft intern sind, also im Gerät bleiben.
Auf jeden Fall auch dafür:
https://github.com/kc-GitHub/FHEM-HM485/issues/34

Ich überarbeite momentan den ganzen HM485-Kram komplett. Z.B. habe ich solche Sachen eingebaut wie automatisches lesen der Original-XMLs (Gerätebeschreibungsdateien) und vereinfachte Konfiguration der Peerings. Das geht dann von beiden Seiten gleichberechtigt und hat auch eine schönere Oberfläche.
Das bedeutet, dass der Fix für das hier etwas dauern kann. Da ich nächste Woche nicht da bin, wahrscheinlich mindestens zwei Wochen. Ich gehe mal davon aus, dass das nicht so schlimm ist, da ja nichts überflüssig schaltet.

Gruß,
   Thorsten

Moin moin,

na, da bin ich doch schon prima geholfen. Vielen Dank, dass Du Dir die Zeit nimmst und Dein Wissen und Deine Arbeit teilst  :)
Anbei noch Feedbacks und Rückfragen zu Deinen übrigen Kommentaren:

ZitatSicherheitshalber solltest Du Dir mal das Reading R-centralAddress vom Taster-Device betrachten. Da sollte die Hmwid vom HM485_LAN-Device stehen, ohne "set_" oder irgendwas vorne dran.

Zitat

Code Auswählen Erweitern

2017.03.10 20:24:33 5: HM485_LAN: HM485_ProcessEvent: hmwId = 00011F1B msgData = 6903C800
Das kommt jetzt hinterher vom Aktor an die Zentrale. Wahrscheinlich steht "logging_time" für das Gerät auf 2 Sekunden.

Hier die betreffenden Readings vom Taster Device, gemäss Deiner Beschreibung alles gut:
R-central_address 00000001 2017-03-09 18:18:38
R-logging_time 2.00 2017-03-09 18:18:38

---

Für die Firmware Version auf den Aktoren gibt es eine Übersicht:
https://www.homematic-inside.de/hardware/firmware-versions
Ich habe den Update nur im Rahmen meiner ersten Versuche mittels der CCU2 durchgeführt und mich seit FHEM nicht mehr drum gekümmert. Ich weiss auch nicht, wie man ohne CCU an die Firmware kommt.

---

Frage zur Version Ausgabe der 10_HM485.pm:
Warum steht da ein "# $Id:" davor? Die anderen Module haben das nicht:
# $Id: 10_HM485.pm 0743 2016-02-26 09:02:00Z Thorsten Pferdekaemper $
No Id found for 00_HM485_LAN.pm
98_HMinfo.pm             12705 2016-12-03 15:37:05Z martinp876
00_HMLAN.pm              13605 2017-03-05 10:25:35Z martinp876

---

Ein paar Details zu meiner Beobachtung mit den Readings des Rollladenaktors:
Der gedrückte Taster hängt am S eines HMW_LC_Bl1_DR (Storen Büro) und schaltet eine Lampe über einen HMW_LC_Sw2_DR (Treppenlicht). Im Event Log erscheint beim Tasterdruck Folgendes:
2017-03-11 09:07:49 HM485 Aktor.Roll_14 ACK
2017-03-11 09:07:49 HM485 Taster.OGBuero.CH4 press_short: 37
2017-03-11 09:07:49 HM485 Taster.OGBuero.CH4 press_short_37
2017-03-11 09:07:49 HM485 Aktor.Roll_14 ACK
2017-03-11 09:07:49 HM485 Taster.OGBuero.CH4 press_short: 37
2017-03-11 09:07:49 HM485 Taster.OGBuero.CH4 press_short_37
2017-03-11 09:07:49 HM485 Aktor.SW2_7 ACK
2017-03-11 09:07:49 HM485 Licht.OGTreppe working: off
2017-03-11 09:07:49 HM485 Licht.OGTreppe on
2017-03-11 09:07:49 HM485 Aktor.Roll_14 ACK
2017-03-11 09:07:51 HM485 Aktor.SW2_7 ACK
2017-03-11 09:07:51 HM485 Licht.OGTreppe working: off
2017-03-11 09:07:51 HM485 Licht.OGTreppe on
2017-03-11 09:07:51 HM485 Aktor.Roll_14 ACK
2017-03-11 09:07:51 HM485 Storen.OGBuero direction: none
2017-03-11 09:07:51 HM485 Storen.OGBuero level: 100
2017-03-11 09:07:51 HM485 Storen.OGBuero working: Geschlossen
2017-03-11 09:07:51 HM485 Storen.OGBuero level_100
2017-03-11 09:07:51 HM485 Aktor.Roll_14 ACK
2017-03-11 09:07:51 HM485 Storen.OGBuero direction: none
2017-03-11 09:07:51 HM485 Storen.OGBuero level: 100
2017-03-11 09:07:51 HM485 Storen.OGBuero working: Geschlossen
2017-03-11 09:07:51 HM485 Storen.OGBuero level_100
An der Stelle möchte ich ja bloss, dass der Befehl an den SW2 Aktor geschickt und das Licht eingeschaltet wird. Den Schaltzustand des Rolladenaktors brauche ich dazu nicht. Warum erhalte ich trotzdem diese Readings? Gerne sende ich Dir auch Log Einträge wenn gewünscht.

---

Dann noch ein paar Details wegen der Geisterschaltung:
Das Beispiel mit dem Wohnzimmerlicht und dem Schalter im Keller ist bisher nur einmal vorgekommen und lässt sich nicht reproduzieren. Die Verdrahtung ist ordentlich, sonst hätte ich dauernd Probleme. Ich hatte das selbe Verhalten auch schon mit dem Küchenlicht und konnte bisher kein Ereignis daran festmachen, geschweige denn reproduzieren. Der Taster hängt an einem SW7, das Licht an einem Dimmer-Aktor. Es passierte Folgendes:

• Taster für Küchenlicht gedrückt
• Licht ging auf 60% gemäss Taster peersettings
• Kurz darauf dimmte das Licht auf 100% hoch
• Dimmen war nicht mehr möglich (long_press)
• Taster wieder gedrückt, Licht ging aus
• Taster wieder gedrückt, Licht ging auf 100% an
• Ein paar mal wiederholt, irgendwann funktionierte alles wieder ganz normal

Das wars. Ist ein paar Mal vorgekommen, zuletzt bestimmt schon ein halbes Jahr her. Vielleicht hat EQ3 ein gelegentliches Leck in ihrem Dimmeraktor und hat mit meiner ursprünglichen Frage gar nichts zu tun. Wie auch immer, ich habe das Beispiel in meinem Post aufgenommen, falls ein Zusammenhang mit den doppelten press_short besteht. Vielleicht nützt Dir die Info ja etwas.

Hi,
das muss ich alles erst noch genauer anschauen. Morgen vielleicht...
Gruß,
   Thorsten

Zitat von: droehn am 11 März 2017, 09:15:21
Für die Firmware Version auf den Aktoren gibt es eine Übersicht:
https://www.homematic-inside.de/hardware/firmware-versions
Ich habe den Update nur im Rahmen meiner ersten Versuche mittels der CCU2 durchgeführt und mich seit FHEM nicht mehr drum gekümmert. Ich weiss auch nicht, wie man ohne CCU an die Firmware kommt.

Tja, da ist halt nur eine Übersicht. Normalerweise bekommt man die Firmware-Dateien bei eq3 im Downloads-Bereich. Ich kann da aber auch nichts zu Wired finden. Je nach Dateiformat wäre es möglicherweise gar nicht so schwierig, den Update in FHEM einzubauen, aber wenn man nicht weiß, wo man die Dateien herbekommt, dann braucht man nicht wirklich darüber nachzudenken.
Ich hatte bisher auch keinen Bedarf.

Zitat
Frage zur Version Ausgabe der 10_HM485.pm:
Warum steht da ein "# $Id:" davor? Die anderen Module haben das nicht:

Code Auswählen Erweitern

# $Id: 10_HM485.pm 0743 2016-02-26 09:02:00Z Thorsten Pferdekaemper $

Das mit dieser Id ist irgendwie eine SVN-Funktionalität, glaube ich. Ich verwende aber git und trage das immer manuell ein. Wahrscheinlich ist mir da ein Fehler unterlaufen. In meiner momentanen Entwicklungsversion sieht das besser aus.

ZitatEin paar Details zu meiner Beobachtung mit den Readings des Rollladenaktors:
Der gedrückte Taster hängt am S eines HMW_LC_Bl1_DR (Storen Büro) und schaltet eine Lampe über einen HMW_LC_Sw2_DR (Treppenlicht). Im Event Log erscheint beim Tasterdruck Folgendes:

Ach, das... Da hatte einer meiner Vorgänger etwas ins HM485-Modul eingebaut, was wohl dafür sorgen sollte, das der Aktor während der Rollladen "fährt" immer mal wieder den momentanen Stand zurückmeldet. Das sieht auf manchen UIs ganz nett aus, da man dann sieht, wie sich der Rollladen bewegt. Ich hatte mir mal überlegt, das auszubauen, aber möglicherweise verwendet das jemand tatsächlich. Ich selbst finde es eher nicht so gut, da ich möglichst die tatsächliche Funktion der Geräte abbilden will. Dazu muss ich mir mal noch was überlegen.

Zitat
Dann noch ein paar Details wegen der Geisterschaltung:

Nach wie vor habe ich dazu keine Idee. Sachen, die "mal aufgetreten" und nicht reproduzierbar sind, sind sehr schwierig zu fassen. Vor Allem, in einem doch etwas komplexeren Umfeld wie bei Dir. 

Gruß,
   Thorsten

Hi,
jetzt habe ich dazu mal noch eine Diskussion aufgemacht:
https://forum.fhem.de/index.php/topic,69052.0.html
Gruß,
   Thorsten

Hallo,

Danke für Deine Feedbacks!

Zitatjetzt habe ich dazu mal noch eine Diskussion aufgemacht

habe schon meinen Senf dazugegeben  ;D

ZitatNormalerweise bekommt man die Firmware-Dateien bei eq3 im Downloads-Bereich

Ich bezweifle, dass da überhaupt noch was Neues kommt sei es über die CCu oder sonstwie.

Die Geisterschaltung empfinde ich als ein Wohlstandsproblem. Zu 99.99545% funktioniert's ja :)

Grüsse
Der Dröhn