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

[Viktor Pankraz]

Sorry Leute, aber ich war jetzt mit einer Erkältung außer Gefecht diese Woche. Aber ein bischen weiter bin ich trotzdem gekommen.
Temperaturmeldungen sind jetzt wie von Thorsten beschrieben konfigurierbar. Auch habe ich eine Temperaturmessung in Abhängigkeit der eingeschalteten LEDs gemacht und festgestellt, dass wenn alle 6 Leds 100% an sind, sich die Temperatur in einem eingebauten Taste über eine Dauer von 1,5h r um ca. 3°C anhebt. Danach bleibt das Delta konstant. Die Abkühlung bei ausgeschalteten Leds geht deutlich schneller. Muss mal sehen, ob die termische Entkopplung im Layout noch besser machbar ist. Notfalls könnte man aber noch eine kompensation in FW einbauen (ist aber unschön)
Der ADC Kanal ist bereits implementiert aber noch nicht mit dem Helligkeitssensor getestet. (kommt als nächstes)

Danach würde ich gerne auch noch Peerings implementieren. Was meint ihr? Wie viele Peeringkanäle pro LED, Taster und Sensor sollte man anbieten können?

[Thorsten Pferdekaemper]

Danach würde ich gerne auch noch Peerings implementieren. Was meint ihr? Wie viele Peeringkanäle pro LED, Taster und Sensor sollte man anbieten können?

Ich habe mal bei den Standard-Geräten nachgeschaut. Üblich ist etwas zwischen 20 und 30. Mehr als 30 habe ich nicht gefunden. Also wärst Du mit 30 gut dabei. Das ist allerdings nicht pro Kanal, sondern pro Kanaltyp. D.h. für alle Tasten zusammen 30 und dann nochmal für alle Ausgänge zusammen 30. Natürlich kann man auch mehr anbieten, wenn es noch ins EEPROM passt, aber da gibt es ein paar Sachen zu bedenken:

• Die Peerings werden pro Kanaltyp als Liste abgespeichert. In dieser Liste steht sowohl der Quell- als auch der Zielkanal. Das kann man auch in Prinzip nicht anders machen, weil die Peerings von der Zentrale direkt ins EEPROM geschrieben werden. D.h. das Layout steht fest.
• Wegen dieser Art der Speicherung muss man prinzipiell bei einer eingehenden Nachricht alle Einträge dieser Liste durchgehen. Das schließt die leeren Einträge mit ein, da es keine Sortierung gibt und nicht garantiert ist, dass es keine Lücken gibt. D.h. das kann auf die Performance gehen.
• Ein Peering kann (auf Aktorseite) eine ganze Menge an Parametern haben. Bei Standard-Aktoren belegen die Peerings 28 Bytes. Das müssen wir nicht so machen, siehe den nächsten Punkt.
• Man sollte sich vorab Gedanken über die Semantik eines Peerings machen und auch festlegen, welche Parameter ein Peering haben kann. In unserem Fall sollten wir dafür vielleicht mal ein paar Anwendungsszenarien festlegen. Ich bin mir außerdem nicht sicher, ob ein direktes Peering für den Temperatur- und ACD-Kanal so sinnvoll ist. Die Standard-Geräte "verstehen" jedenfalls nur Tastendrücke, und die Dinger schicken ja erstmal keine Tastendrücke. Natürlich könnte man da was basteln, aber wie gesagt müsste man sich erst einmal Anwendungsszenarien überlegen.

Außerdem hat das momentane XML glaube ich gar keine Peerings, es würde also nicht funktionieren. Vielleicht kann ich mal heute Abend oder so einen Vorschlag zusammenbasteln.

Gruß,
    Thorsten

[ManfredC]

Hi Viktor,

Muss mal sehen, ob die termische Entkopplung im Layout noch besser machbar ist.

Wenn über eine Layoutänderung nachgedacht wird: Wäre es eine Option den DC/DC Wandler auf der Wago-Platine unter zu bringen?

Gruß,

Manfred

[Viktor Pankraz]

• Die Peerings werden pro Kanaltyp als Liste abgespeichert. In dieser Liste steht sowohl der Quell- als auch der Zielkanal. Das kann man auch in Prinzip nicht anders machen, weil die Peerings von der Zentrale direkt ins EEPROM geschrieben werden. D.h. das Layout steht fest.
• Wegen dieser Art der Speicherung muss man prinzipiell bei einer eingehenden Nachricht alle Einträge dieser Liste durchgehen. Das schließt die leeren Einträge mit ein, da es keine Sortierung gibt und nicht garantiert ist, dass es keine Lücken gibt. D.h. das kann auf die Performance gehen.
• Ein Peering kann (auf Aktorseite) eine ganze Menge an Parametern haben. Bei Standard-Aktoren belegen die Peerings 28 Bytes. Das müssen wir nicht so machen, siehe den nächsten Punkt.
• Man sollte sich vorab Gedanken über die Semantik eines Peerings machen und auch festlegen, welche Parameter ein Peering haben kann. In unserem Fall sollten wir dafür vielleicht mal ein paar Anwendungsszenarien festlegen. Ich bin mir außerdem nicht sicher, ob ein direktes Peering für den Temperatur- und ACD-Kanal so sinnvoll ist. Die Standard-Geräte "verstehen" jedenfalls nur Tastendrücke, und die Dinger schicken ja erstmal keine Tastendrücke. Natürlich könnte man da was basteln, aber wie gesagt müsste man sich erst einmal Anwendungsszenarien überlegen.

Performance sollte bei dieser MCU kein Problem sein. Der XMega läuft mit 32MHz und kann aus dem Eeprom fast so schnell wie aus dem RAM lesen. Ich würde also sowieso in einer der nächsten Versionen darüber nachdenken, die Kopie des EEPROMs im RAM zu entfernen.

Peerings für Temperatur und Helligkeit muss auch erstaml gar nicht sein. Ich denke das mit den Peerings folgendes Szenario möglich sein muss:

• Ein Tastendruck (kurz oder lang) soll einen Aktor in einen bestimmten Zustand (AN/AUS/Dimmer-Level) versetzten
• Die Leds werden von vielen Benutzern gerne als Feedback für den Status verschiedener Szenarien oder auch einzelner Aktoren benutzt. z.B. Außenbeleuchtung geht an -> LED leuchtet mit definierter Helligkeit; Wird eine bestimmte Szene (Lampe 1 und 3 an) im Wohnzimmer erreicht -> LED leuchtet mit definierter Helligkeit. Der Taster an dem die LED leuchtet wird dann meist dazu verwendet diesen Zustand wieder abzuschalten

Eine Frage noch:
Wenn ein Taster/Aktor Peerings anbietet, lässt sich dieser Kanal dann noch trotzdem über die WebUI schalten/verwenden?

[Viktor Pankraz]

Wenn über eine Layoutänderung nachgedacht wird: Wäre es eine Option den DC/DC Wandler auf der Wago-Platine unter zu bringen?

Hi Manfred,
den DCDC Wandler auf die WAGO-Platine zu bringen wäre sicher eine Option, aber damit werden die Herstellkosten dieser reinen Adapterplatine gleich verdoppelt (nicht wegen dem DCDC Wandler selbst, sondern dem zusätzlichen Fertigungsschritt außer den Steckern noch andere Bauteile anzubringen). Dies habe ich erfahren, als ich auf die Adapterplatine eine Invertierung der Tastersignale implementiert habe.
Ich werde zunächst mal prüfen, ob es der DCDC ist oder der 3V3 Linearregler, der die Erwärmung verursacht. Aber deine Idee ist gut, werde es im Hinterkopf behalten.

[Thorsten Pferdekaemper]

Performance sollte bei dieser MCU kein Problem sein.

Das ist erst einmal gut. Allerdings muss man noch den Bus bedenken. Wenn ein Taster z.B. 30 Peerings hat und alle gehen auf unterschiedliche Devices, dann müssen 30 Nachrichten rausgeschickt werden. Das kann u.U. auch schon ein bisschen unschön werden.

Peerings für Temperatur und Helligkeit muss auch erstaml gar nicht sein. Ich denke das mit den Peerings folgendes Szenario möglich sein muss:

• Ein Tastendruck (kurz oder lang) soll einen Aktor in einen bestimmten Zustand (AN/AUS/Dimmer-Level) versetzten
• Die Leds werden von vielen Benutzern gerne als Feedback für den Status verschiedener Szenarien oder auch einzelner Aktoren benutzt. z.B. Außenbeleuchtung geht an -> LED leuchtet mit definierter Helligkeit; Wird eine bestimmte Szene (Lampe 1 und 3 an) im Wohnzimmer erreicht -> LED leuchtet mit definierter Helligkeit. Der Taster an dem die LED leuchtet wird dann meist dazu verwendet diesen Zustand wieder abzuschalten

Ok, dann versuche ich mal, etwas entsprechendes zusammenzubauen.

Eine Frage noch:
Wenn ein Taster/Aktor Peerings anbietet, lässt sich dieser Kanal dann noch trotzdem über die WebUI schalten/verwenden?

Ja, außer Du baust etwas ein, was das verhindert.

Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi Viktor,
hier ist das XML mit den Peerings und das zugehörige EEPROM-Layout.
Schau mal, was Du damit anfangen kannst. HBWLinkKey müsstest Du direkt verwenden können. HBWLinkSwitchSimple geht nur fast, da es die LEVEL-Einstellungen nicht kennt.
Gruß,
   Thorsten

[Viktor Pankraz]

Habe hier http://www.haus-bus.de/wiki/index.php/Multitaster_SD6_im_Homematic_System_verwenden angefangen zu beschreiben, was alles benötigt wird um den Taster am Homematic Bus betreiben zu können. In den nächsten Tagen werde ich den Artikel um weitere Details erweitern (elektr. Anschluss usw) Wenn jemandem noch Infos fehlen, einfach fragen 

@Thorsten
Ist auch eine Beschreibung für die FHEM Umgebung notwendig oder kann das jeder anhand deiner Tutorien selbst machen?

[Thorsten Pferdekaemper]

@Thorsten
Ist auch eine Beschreibung für die FHEM Umgebung notwendig oder kann das jeder anhand deiner Tutorien selbst machen?

Viel Beschreibung ist da eigentlich nicht nötig, aber ich werde wohl dennoch einen Wiki-Artikel spendieren, sobald ich das Teil selbst mal an FHEM am Laufen habe.
Gruß,
   Thorsten

[Viktor Pankraz]

Ich hatte übrigens in der FW den Bereich 0x0030 - 0x003F im Eeprom bereits für den Kanal 13 (Analog Eingang Helligkeit) reserviert.
Hier die aktualisierten Dateien. Könnten wir die Konfiguration dann erstmal wie beim Temperatursensor machen?

SEND_DELTA_VALUE: Das is ein Byte und die Angabe ist in AD-Werten. Erlaubte Werte gehen von 1 bis 255. Bei 0 wird das Feature nicht verwendet.
Alles andere sollte als Default, also 50 interpretiert werden.

SEND_MIN_INTERVAL: Zwei Byte, little Endian. Die Einheit ist Sekunden und es geht von 5 bis 3600. Bei 0 wieder "nicht verwendet". Alles andere sollte wie 10s behandelt werden.

SEND_MAX_INTERVAL: Wie SEND_MIN_INTERVAL, nur dass der Default 150s sind.

Wenn ja, müsste die XML dafür noch angepasst werden.

[Thorsten Pferdekaemper]

Ich hatte übrigens in der FW den Bereich 0x0030 - 0x003F im Eeprom bereits für den Kanal 13 (Analog Eingang Helligkeit) reserviert.
Hier die aktualisierten Dateien.

Geht klar. Ich habe in Deinem Excel-Sheet nur zwei Fehler bei den Adressen gefunden. Im XML stimmt's. Das korrigierte Sheet hängt hier dran.

Könnten wir die Konfiguration dann erstmal wie beim Temperatursensor machen?

Im Prinzip ja.

SEND_DELTA_VALUE: Das is ein Byte und die Angabe ist in AD-Werten. Erlaubte Werte gehen von 1 bis 255. Bei 0 wird das Feature nicht verwendet.
Alles andere sollte als Default, also 50 interpretiert werden.

Wenn 0 und 1 bis 255 in einem Byte schon belegt sind, dann gibt es kein "alles andere". Außerdem enthalten "leere" EEPROMs anscheinend lauter 255. D.h. entweder wir nehmen 255 als Default oder 255 darf nicht bei den erlaubten Werten sein. Ich würde vorschlagen, wir lassen nur 1 bis 250 als normale Werte zu.

SEND_MIN_INTERVAL: Zwei Byte, little Endian. Die Einheit ist Sekunden und es geht von 5 bis 3600. Bei 0 wieder "nicht verwendet". Alles andere sollte wie 10s behandelt werden.
SEND_MAX_INTERVAL: Wie SEND_MIN_INTERVAL, nur dass der Default 150s sind.

Das bedeutet: Wenn man das Teil einfach so verwendet, wie es ist, dann sendet es alle 10 Sekunden falls sich der Wert um 50 ändert. Wie stark flattert denn der Wert, wenn nichts angeschlossen ist? Ich würde gerne vermeiden, alle 10 Sekunden einen (dazu noch sinnlosen) Wert über den Bus zu schicken.

Wenn ja, müsste die XML dafür noch angepasst werden.

Ok, mach ich noch.

Gruß,
    Thorsten

[Thorsten Pferdekaemper]

Hi,
hier ist jetzt auch die neue XML.
Gruß,
   Thorsten

[ManfredC]

Hi Viktor,

den DCDC Wandler auf die WAGO-Platine zu bringen wäre sicher eine Option, aber damit werden die Herstellkosten dieser reinen Adapterplatine gleich verdoppelt (nicht wegen dem DCDC Wandler selbst, sondern dem zusätzlichen Fertigungsschritt außer den Steckern noch andere Bauteile anzubringen).

ich bin auf die Idee gekommen weil der RS485-Treiber ja auch auf der Wago-Platine ist. Außerdem sieht es so aus als wären noch andere Bauteile auf dieser Adapterplatine vorgesehen. Das die natürlich teurer wird als die reine Wago-Platine für den Taster ohne MCU ist klar. Aber das ist die RS485-Klemme auch schon.

Gruß,

Manfred

[Viktor Pankraz]

Hi Viktor,
ich bin auf die Idee gekommen weil der RS485-Treiber ja auch auf der Wago-Platine ist. Außerdem sieht es so aus als wären noch andere Bauteile auf dieser Adapterplatine vorgesehen. Das die natürlich teurer wird als die reine Wago-Platine für den Taster ohne MCU ist klar. Aber das ist die RS485-Klemme auch schon.

Hi Manfred,

Wenn es nur die RS485 Adapterplatine gäbe, würde ich dir ja auch Recht geben. Aber es gibt auch Adapterplatinen, die nur Stecker bestückt haben. Und auf diese müsste ich den DCDC ja auch drauf tun, weil der auf dem Taster selbst fehlt. Diese Adapterplatine ist auch die meist verkaufte (weil eben günstig).

Gruß,
Viktor

[Thorsten Pferdekaemper]

Hi,
um welchen DCDC-Wandler geht es denn überhaupt?
Gruß,
   Thorsten