[HM-Wired] Entwicklung HBW-SD6-Multikey (haus-bus.de 6fach-Taster)

[Viktor Pankraz]

Hi Thorsten,

danke schon mal fürs erste Feedback.

In FHEM hatte ich zuerst mit dem Peering ebenfalls Probleme. Die hier drangehängte XML hat's dann gefixt. Möglicherweise funktioniert das auch für die CCU. Anscheinend muss man doch bei jedem Peering-Parameter ein Default angeben.

Werde die neue XML an der CCU testen. Hatte ja vorher geschrieben, dass ich an der CCU die Peering-Parameter gar nicht erst sehen konnte. Hoffe deine Änderung hat dies ebenfalls behoben

• Das LED-Feedback konnte ich nicht abschalten.

Müsste ja über die "INPUT_LOCKED"-Konfiguration des Tasters gehen gehen. Aber ich seh gerade, dass in deiner XML das Bit0 dafür genutzt wird und ich hatte noch die Konfig aus deiner Lib, wo Bit0 KEY_TYPE ist. Ändere ich dann mal.

• Peerings funktionieren im Prinzip intern und extern, aber...
• Lange Tastendrücke gehen raus, aber reinkommende (oder auch interne) bewirken nichts
• Die Level-Settings zu den Peerings bewirken nichts. Peerings setzen immer auf 100% bzw. 0%.

Das sollte auch schnell zu beheben sein

• Peerings, bei denen ein Taster vom SD6 einen externen Aktor schalten soll, sind irgendwie unzuverlässig. Ich glaube, dass das daran liegt, dass die HMW-Originale nicht nur ein ACK zurückliefern, sondern eine komplette I-Message. Darauf erwarten sie dann aber wieder ein ACK vom SD6, welches nicht kommt. Es kann sein, dass das noch ein Problem in meiner Lib ist, aber ich kann mich daran erinnern, so etwas in der Art schon einmal gelöst zu haben
• Ich habe die Vermutung, dass der SD6 manchmal sendet, obwohl der Bus nicht frei ist. Da bin ich mir aber noch nicht sicher.

Da muss ich dann mal genauer hinschauen. Mein Problem ist, dass ich keine große Homematic installation habe. Habe die CCU2 auf nem PI ein LAN->RS485 Gateway ein HMW-original und der Rest halt SD6-Taster. Aber ich versuche mal das beschriebene Problem zu provozieren. Melde mich wieder sobald ich Ergebnisse habe.

Danke[/list]

[Thorsten Pferdekaemper]

Müsste ja über die "INPUT_LOCKED"-Konfiguration des Tasters gehen gehen.

Ähm, nein. Das war nicht so gedacht. INPUT_LOCKED sollte die Taste komplett abschalten. D.h. wenn gesetzt, dann darf das Teil auf einen Tastendruck gar nicht mehr reagieren. Für die LED ist LED_FEEDBACK gedacht.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

ein HMW-original

Welches hast Du den? Ich glaube, die Dinger reagieren nicht unbedingt einheitlich...
Gruß,
   Thorsten

[Viktor Pankraz]

Hi Thorsten,
habe ein HMW-LC-Sw2-DR.

Ähm, nein. Das war nicht so gedacht. INPUT_LOCKED sollte die Taste komplett abschalten. D.h. wenn gesetzt, dann darf das Teil auf einen Tastendruck gar nicht mehr reagieren. Für die LED ist LED_FEEDBACK gedacht.

In deiner Mail vom 15.5 hieß es noch INPUT_LOCKED soll auch das Led feedback ausschalten, wenn Taster nicht aktiv ist. Mit LED_FEEDBACK hast du in der aktuellsten XML jetzt ein neues globales Bit reingebracht, richtig? Wäre super wenn du die Excel-Tabelle auf den letzten Stand aktualisierst, darin lässt sich die Speicherbelegung viel besser ablesen.

Gruß,
Viktor

[Viktor Pankraz]

• Das LED-Feedback konnte ich nicht abschalten.
• Peerings funktionieren im Prinzip intern und extern, aber...
• Lange Tastendrücke gehen raus, aber reinkommende (oder auch interne) bewirken nichts
• Die Level-Settings zu den Peerings bewirken nichts. Peerings setzen immer auf 100% bzw. 0%.

Die Probleme waren alle auf die neue XML zurückzuführen. FW 0100 hatte noch einen 2Bit ActionType und keine globale LED_FEEDBACK config. Es ist also besonders wichtig während der Entwicklung FW und XML Datei nur gemeinsam zu testen
Habe hier jetzt das aktuelle Paar hochgeladen.
- globale LED_FEEDBACK konfiguration implementiert
- ActionTypes beim Peering auf 3bit erweitert
- BLINK_ON action auf Leds implementiert
- BLINK_TOGGLE ist drin, aber evtl. nicht korrekt (konnte es noch nicht testen)

Gruß,
VIktor

[Thorsten Pferdekaemper]

habe ein HMW-LC-Sw2-DR.

Genau mit so einem hatte ich die Probleme. Wenn Du mal einen Taster des SD6 mit einem der Aktorkanäle peerst und dann die Taste so etwa zweimal pro Sekunde drückst, dann scheint was durcheinander zu kommen.

In deiner Mail vom 15.5 hieß es noch INPUT_LOCKED soll auch das Led feedback ausschalten, wenn Taster nicht aktiv ist. Mit LED_FEEDBACK hast du in der aktuellsten XML jetzt ein neues globales Bit reingebracht, richtig?

Sorry, da ist wohl irgendwo etwas untergegangen. Es war so gemeint: INPUT_LOCKED schaltet jegliche Reaktion auf die Taste ab und ist pro Taste einstellbar. D.h. auch das LED-Feedback ist dann aus. LED_FEEDBACK schaltet nur das LED-Feedback aus (oder an), aber für das ganze Ding.

Wäre super wenn du die Excel-Tabelle auf den letzten Stand aktualisierst, darin lässt sich die Speicherbelegung viel besser ablesen.

Das hatte ich schon gemacht, aber anscheinend hat es Dich nicht erreicht. Ich hänge mal den aktuellen Stand hier mit dran.

Es ist also besonders wichtig während der Entwicklung FW und XML Datei nur gemeinsam zu testen

Das ist tatsächlich wichtig. Ich hatte mir mal eine Version überlegt, bei der das XML im Gerät selbst gespeichert ist, aber das würde dann mit der CCU nicht mehr funktionieren.
Ich werde mal den neuen Stand testen. Hast Du was am XML geändert oder nur der Vollständigkeit halber nochmal hier drangehängt?

Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
sorry, testen hat gestern Abend nicht mehr geklappt. Ich hoffe auf heute Abend.
Gruß,
   Thorsten

[Viktor Pankraz]

Hi,

die XML ist nur vollständigkeitshalber nochmal mit der FW angehängt. Geändert habe ich nichts mehr.

Genau mit so einem hatte ich die Probleme. Wenn Du mal einen Taster des SD6 mit einem der Aktorkanäle peerst und dann die Taste so etwa zweimal pro Sekunde drückst, dann scheint was durcheinander zu kommen.

Versuche ich bei mir mal nachzuvollziehen.

Gruß,
Viktor

[Thorsten Pferdekaemper]

Hi,
ich habe jetzt die neue Firmware reingeladen und mal ein bisschen getestet:

• Das LED-Feedback konnte ich nicht abschalten.
  Das funktioniert jetzt wunderbar. Es lässt sich ein- und ausschalten.
• Lange Tastendrücke gehen raus, aber reinkommende (oder auch interne) bewirken nichts
  Das ist jetzt erledigt, allerdings blinkt die LED wenn für den langen Tastendruck "toggle" eingestellt ist. Das sollte nicht so sein. Zumindest für "toggle", aber genau genommen auch für "on" und "off" sollte die Nummer des Tastendrucks beachtet werden. Bei langen Tastendrücken kommt eine Nachricht/ ein Event mit derselben Nummer etwa alle 300ms. Das ist z.B. für Rollladensteuerungen oder Dimmer. Bei uns dürfen diese Wiederholungen nichts bewirken. D.h. wenn eine Nachricht mit derselben Nummer und demselben Device und demselben Kanal wie die letzte Nachricht reinkommt, dann ignorieren.
• Die Level-Settings zu den Peerings bewirken nichts. Peerings setzen immer auf 100% bzw. 0%.
  Das ist immer noch so.
• Peerings, bei denen ein Taster vom SD6 einen externen Aktor schalten soll, sind irgendwie unzuverlässig.
  Das habe ich jetzt mal so stehen gelassen.
• Ich habe die Vermutung, dass der SD6 manchmal sendet, obwohl der Bus nicht frei ist. Da bin ich mir aber noch nicht sicher.
  ...und das auch
• BLINK_ON action auf Leds implementiert
  Das klappt auch, aber ich hatte mir das ein bisschen anders vorgestellt. Wenn "BLINK_QUANTITY" auf 0 (not_used) steht, dann ging ich von "ewig" Blinken aus. D.h. bis ein "on", "off" oder "blink_toggle" kommt. Statt dessen blinkt bei 0 gar nichts. Andererseits blinkt es immer gnadenlos die eingestellte BLINK_QUANTITY, d.h. man bekommt das Blinken nicht wieder aus.
  Ich fände es akzeptabel (wenn auch unschön), wenn man ein eingestelltes n-mal Blinken halt so ablaufen lassen muss. Ich hätte aber doch gerne eine Möglichkeit, das Blinken "von außen" abzuschalten, zumindest wenn BLINK_QUANTITY auf not_used steht.
• BLINK_TOGGLE ist drin, aber evtl. nicht korrekt (konnte es noch nicht testen)
  Das bewirkt bei mir gar nichts. Das Blinken fängt weder an, noch hört es auf.
• INPUT_LOCKED funktioniert wie erwartet.

Gruß,
   Thorsten

[Viktor Pankraz]

Hi,

Das ist jetzt erledigt, allerdings blinkt die LED wenn für den langen Tastendruck "toggle" eingestellt ist. Das sollte nicht so sein. Zumindest für "toggle", aber genau genommen auch für "on" und "off" sollte die Nummer des Tastendrucks beachtet werden. Bei langen Tastendrücken kommt eine Nachricht/ ein Event mit derselben Nummer etwa alle 300ms. Das ist z.B. für Rollladensteuerungen oder Dimmer. Bei uns dürfen diese Wiederholungen nichts bewirken. D.h. wenn eine Nachricht mit derselben Nummer und demselben Device und demselben Kanal wie die letzte Nachricht reinkommt, dann ignorieren.

Ich hatte gedacht, dass das aus deiner Lib schon kommt. Oder muss das jeder Kanal für sich selber machen?

Die Level-Settings zu den Peerings bewirken nichts. Peerings setzen immer auf 100% bzw. 0%.
Das ist immer noch so.

Hatte bei mir aber funktioniert. Kannst du mir bitte das Image deines EEPROMs schicken, dann kann ich es mal nachstellen und debuggen.

BLINK_ON action auf Leds implementiert
Das klappt auch, aber ich hatte mir das ein bisschen anders vorgestellt. Wenn "BLINK_QUANTITY" auf 0 (not_used) steht, dann ging ich von "ewig" Blinken aus. D.h. bis ein "on", "off" oder "blink_toggle" kommt. Statt dessen blinkt bei 0 gar nichts. Andererseits blinkt es immer gnadenlos die eingestellte BLINK_QUANTITY, d.h. man bekommt das Blinken nicht wieder aus.
Ich fände es akzeptabel (wenn auch unschön), wenn man ein eingestelltes n-mal Blinken halt so ablaufen lassen muss. Ich hätte aber doch gerne eine Möglichkeit, das Blinken "von außen" abzuschalten, zumindest wenn BLINK_QUANTITY auf not_used steht.

Das BLINK feature sollten wir mal genauer spezifizieren
Ich hatte nämlich 0 als NOT_USED und 255 für endlos blinken implementiert. D.h. auch, dass man ein bereits laufendes Blinken mit BLINK_QUANTITY 0 abbrechen kann.

Bevor ich nun auch an BLINK_TOGGLE gehe, was genau erwartest du dabei?
- ON -> OFF
- BLINK -> OFF
- OFF -> ON oder BLINK ?

Gruß,
Viktor

[Thorsten Pferdekaemper]

Ich hatte gedacht, dass das aus deiner Lib schon kommt. Oder muss das jeder Kanal für sich selber machen?

Es kann durchaus sein, dass das Problem in der Lib gelöst werden sollte. Allerdings werde ich dafür die nächste Woche keine Möglichkeit haben.

Hatte bei mir aber funktioniert. Kannst du mir bitte das Image deines EEPROMs schicken, dann kann ich es mal nachstellen und debuggen.

Mal sehen, wie ich das am Besten mache. Ich hoffe, ich komme heute Abend noch dazu.

Das BLINK feature sollten wir mal genauer spezifizieren

Ich dachte, dass ich da mal eine Mail dazu geschrieben hätte.

Ich hatte nämlich 0 als NOT_USED und 255 für endlos blinken implementiert.

Für mein Verständnis is "NOT_USED" und "endlos blinken" dasselbe. Wenn man kein Blinken will, dann kann man ja einfach bei ACTIVITY was anderes setzen.

D.h. auch, dass man ein bereits laufendes Blinken mit BLINK_QUANTITY 0 abbrechen kann.

Wie soll das gehen? Dazu müsste man ja ein eigenes Peering definieren. Das halte ich für unpraktisch.

Bevor ich nun auch an BLINK_TOGGLE gehe, was genau erwartest du dabei?
- ON -> OFF
- BLINK -> OFF
- OFF -> ON oder BLINK ?

Ich erwarte für BLINK_TOGGLE das:
- ON -> BLINK
- BLINK -> OFF (oder der Zustand vor dem Blinken)
- OFF -> BLINK
Für ON erwarte ich:
- ON -> ON
- OFF -> ON
- BLINK -> ON
Für OFF entsprechend
- ON -> OFF
- OFF -> OFF
- BLINK -> OFF
Für TOGGLE:
- ON -> OFF
- OFF -> ON
- BLINK -> OFF (oder den Zustand vor dem Blinken)
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
hier jetzt noch die Sache mit dem EEPROM. Die angehängte hex-Datei ist das, was Flip erzeugt hat. Da mir das irgendwie komisch erschien, habe ich gleich noch einen Screenshot von Buffer-> Edit mit drangehängt.
Der dritte Anhang zeigt, wie das Peering (Taste 1 mit LED 2) aussieht.
Wenn ich die Taste kurz drücke, dann geht die LED komplett an (nach Augenschein und auch nach Rückmeldung an FHEM). Wenn ich sie nochmal drücke geht sie komplett aus.
Gruß,
    Thorsten

[Viktor Pankraz]

Ich erwarte für BLINK_TOGGLE das:
- ON -> BLINK
- BLINK -> OFF (oder der Zustand vor dem Blinken)
- OFF -> BLINK
Für ON erwarte ich:
- ON -> ON
- OFF -> ON
- BLINK -> ON
Für OFF entsprechend
- ON -> OFF
- OFF -> OFF
- BLINK -> OFF
Für TOGGLE:
- ON -> OFF
- OFF -> ON
- BLINK -> OFF (oder den Zustand vor dem Blinken)

Wahrscheinlich habe ich das ON/OFF/BLINK bisher falsch interpretiert. Ich ahbe für OFF immer 0% Helligkeit angenommen und den off/onLevel nur für das BLINK_ON Kommando berücksichtigt.
Also wenn ich es richtig verstehe, dann ist für alle Aktionen aus den Peerings offLevel und onLevel zu benutzen, richtig?

[Viktor Pankraz]

So nun bin ich fast 2 Wochen nicht mehr dazu gekommen etwas zu machen (Familie und Garten gehen halt vor ) aber jetzt gehts weiter.
Hier die FW 1.02:

Jetzt sollten die Peering Parameter nicht nur fürs Blinken wirken und das Verhalten sollte so sein wie Thorsten es sich gewünscht hat

• Wenn eine Nachricht mit derselben Nummer und demselben Device und demselben Kanal wie die letzte Nachricht reinkommt, dann ignorieren.
  Das lässt sich nicht wirklich realisieren, da sich der Kanal von jedem Kanal eines jeden Devices die Nummer merken müsste und dafür reicht der Speicher nicht aus. Es könnte funktionieren, wenn auch die Anzahl der Wiederholungen mit übertragen werden würden, dann kann man die Aktion bei der ersten Nachricht ausführen und alle weiteren ignorieren
• Das Blinken der LEDs wird nun durch neues Kommando abgebrochen
• TOGGLE verwendet nun auch die Peering Parameter
• BLINK_TOGGLE ist implementiert und getestet

Die XML hat sich nicht geändert, ist nur der Vollständigkeit halber mit hochgeladen.

Gruß,
Viktor

[Viktor Pankraz]

Es gibt übrigens schon Anfragen bei diesem Taster die herausgeführten IOs mit 6 weiteren Tastern und LEDs zu belegen. Ich hätte da einige Ideen:

Erstens, dynamisch und mit der selben XML und FW
1. Globales Bit (z.B. auf Adresse 6:1) noExtension (invertiert und damit ist der default keine Erweiterung)
2. Wenn das Bit gelöscht wird (6:1 = 0), meldet die FW beim nächsten BOOT 2 Geräte vom Typ HBW-SD6. Diese können dann separat prgrammiert werden nutzen aber die selbe Kommunikationshardware
3. Das würde bedeuten, dass pro Gerät nur 512 Bytes Eeprom Speicher zu verfügung stehen, d.h. die Peerings müssten auf 20/20 reduziert werden

- nur eine FW
- nur eine XML Datei
- Erweiterung dynamisch konfigurierbar, d.h. Kanäle bzw. Erweiterung nur sichtbar wenn konfiguriert


Eine andere Möglichkeit wäre natürlich noch weitere 6 Taster und LED Kanäle in der XML definieren und die Peerings auch 40/40 zu erhöhen.
- nur eine FW
- nur eine XML Datei
- Erweiterung statisch immer vorhanden, auch wenn nicht genutzt

Dritte Möglichkeit sind 2 verschiedene Definitionen in XML und 2 verschiedene FW.

Letztes finde ich aber sehr unschön und es erhöht nur die Komplexität für den Anwender. Beim Ersten ist das Feature auch schon etwas versteckt und man muss erst aktivieren und dann neustarten. Außerdem ist die FW dann etwas komplexer, da sich ein Sende-Kanal von 2 Devices geteilt werden muss. Die schnellste und einfachste Lösung ist für mich die zweite.
Aber was ist eure Meinung als Benutzer solcher Geräte?

Gruß,
Viktor