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

[Thorsten Pferdekaemper]

Hi,

wie schon in einem anderen Thread angekündigt bin ich mit den Leuten von http://haus-bus.de in Kontakt:
https://forum.fhem.de/index.php/topic,64700.msg623681.html#msg623681
Es sieht momentan ganz gut aus für eine Homematic-Wired (bzw. HomebrewWired) Version deren 6fach-Tasters. Das ganze wird wohl so laufen, dass es eine Firmware geben wird, die man selbst auf deren 6-fach-Taster laden kann. Außerdem baue ich ein XML dazu, so dass man das Teil sauber in FHEM (und wohl auch die CCU) einbinden kann.
Das ganze wird es wohl hier geben:
https://github.com/haus-bus/MultitasterSD6/tree/HM-Wired

Es ist momenta nicht geplant, dass es einen fertigen Taster mit HBW-Firmware gibt. Der Entwickler ist nur locker mit dem Hersteller verbunden und die Entwicklung der Firmware scheint auch eher ein Privatvergnügen zu sein.
Ich bin bin mit haus-bus.de gar nicht verbunden, das hier soll also keine Werbung sein.

Der momentane Stand ist, dass es für "meine" Libraries eine für den Controller kompilierbare Version gibt. Außerdem gibt es den ersten Wurf eines Geräte-XML. In FHEM könnte das mal so aussehen wie auf dem angehängten Screenshot. Wirklich funktionieren tut allerdings noch nichts.

Falls jemand hier Wünsche, Fragen oder Ideen hat, nur raus damit. Ich kann und will allerdings nichts versprechen... 

Gruß,
    Thorsten

[QLink]

Hi Thorsten,

vielen Dank für deinen Einsatz.
Ich bin sehr interessiert an so einem Taster.

Mich würde interessieren, ob du eventuell so eine Art How-To Guide bzw. Step by Step Guide schreiben könntest?
Wenn ja, wäre ich gerne bereit mir so ein Ding zu holen und dich beim Testen zu unterstützen, falls dir das helfen würde...
Gibt es eventuell auch eine Timeline oder ein changelog oder ein Protkoll über die Fortschritte ?

Beste Grüße

[Thorsten Pferdekaemper]

LOL... Und Freibier für alle Tester.
Ich kann jetzt noch nicht sagen, ob es dafür ein How-To oder sonstwas geben wird. Es gibt auch keine Timeline oder sonst irgendwas. Wenn es was zu berichten gibt und wir Lust dazu haben, dann wird das hier erscheinen. Mehr weiß man derzeit noch nicht.

Anscheinend ist es inzwischen gelungen, das Teil in einer CCU sichtbar zu machen.

Gruß,
    Thorsten

[Viktor Pankraz]

Hallo,

ich bin der Entwickler der Multitasterplatine und programmiere gerade die Homematic integration auf Basis der HBW-library von Thorsten.
Aktueller Status ist:
- 6 Taster und 6 Leds können über die WebUI der CCU2 abgefragt und angesteuert werden ( sollte mit FHEM dann auch schon gehen, hab es aber noch nicht getestet )
- Kommunikation funktioniert dank der Library soweit ohne probleme

Nächste Schritte:
- LEDs dimmbar machen (PWM)
- Temperatursensor (1-Wire DS18B20) auf einem weiteren Kanal zu verfügung stellen
- 10bit ADC -Wert für Helligkeits Messung auf einem weiteren Kanal zu verfügung stellen

geplant ist auch auf dem Modul das Peering zu unterstützen. Geh ich aber erst an, wenn die Basis stabil funktioniert.

[papa]

Das sieht ja wirklich interessant aus. Kriegt man da auch noch ein CC1101 um Funk zu machen ran ?

[Viktor Pankraz]

Hardware technisch kein Problem. Alle nicht benötigten IOs sind auf Pfostenstecker verfügbar. Ebenso die Pheripherien ADC, PWM, USART, SPI, USB, TWI ...
Es muss aber einer die FW dafür schreiben oder portieren (falls es schon was gibt, was wieder verwendet werden kann )
Wenn mann es noch schön machen möchte, müsste mann eine AdapterPlatine mit integriertem C1101 Modul machen

[papa]

Software ist sicherlich kein großes Problem. Es gibt hier im Forum 2 Library Implementierungen für Homematic

https://forum.fhem.de/index.php/topic,14140.msg88923.html#msg88923

https://forum.fhem.de/index.php/topic,57486.msg489099.html#msg489099

Beide haben den Support für Remote-Geräte drin. Entsprechende Code-Beispiele gibt es auch.

[Thorsten Pferdekaemper]

Das sieht ja wirklich interessant aus. Kriegt man da auch noch ein CC1101 um Funk zu machen ran ?

Vielleicht wäre das einen eigenen Thread wert, wenn Du das machen willst.
Damit das mit dem Funk so richtig sinnvoll wird müsste man sich auch noch über die Stromversorgung Gedanken machen...
Gruß,
   Thorsten

[papa]

Vielleicht wäre das einen eigenen Thread wert, wenn Du das machen willst.

Da hast Du Recht - Sorry - wollte Deinen Thread nicht kapern.

Damit das mit dem Funk so richtig sinnvoll wird müsste man sich auch noch über die Stromversorgung Gedanken machen...

Wenn die LEDs nicht dauerhaft leuchten, sollte auch eine Batterielösung gehen.

[Viktor Pankraz]

Hier der nächste Fortschritt:
Leds lassen sich per WebUI dimmen und liefern auch den korrekten Wert als feedback.
Temperatur ist auch schon da. Sie wird alle 10s nach der letzten Meldung aus dem DS1820 ausgelesen und erneut gemeldet. Morgen mach ich mich dann an die Helligkeitsermittlung dran. Zumindest erst mal den ADC Wert verfügbar machen, damit dann weitere tests folgen können.

Nächste Woche werde ich dann im HausBus-Wiki beschreiben wie man das ganze in Betrieb nehmen kann und hier den Link posten.

[Thorsten Pferdekaemper]

Hi Viktor,
das ist sieht ja wirklich gut aus.
Das mit den 10 Sekunden ist wahrscheinlich ein bisschen heftig. Wenn man sich mal vorstellt, jemand hat 10 ähnliche Geräte am Bus, dann kommt nur deshalb schon jede Sekunde ein Event. Darauf muss dann FHEM (oder auch die CCU) mit nottifies etc. zurecht komen.
Das ist für den langsamen Bus und für manch "kleine" Hardware schon fast etwas viel.
Deshalb hatte ich damals in meine 1-Wire-Implementierung eingebaut, dass man das Sendeverhalten einstellen kann. Im XML, das ich Dir geschicjt hatte, ist das auch schon drin. Du müsstest das auch in der CCU irgendwo sehen.

Code Auswählen Erweitern


    <paramset type="MASTER" id="hmw_temp_ch_master" address_step="16" address_start="0x20">
<parameter id="SEND_DELTA_TEMP">
   <logical type="float" unit="℃" default="0.5" min="0.1" max="25.0">
       <special_value id="NOT_USED" value="0"/>
   </logical>    
               <physical size="1.0" type="integer" interface="eeprom">
                  <address index="+1.0"/>
               </physical>
               <conversion type="float_integer_scale" factor="10"/>
               <conversion type="integer_integer_map">
                 <value_map to_device="false" from_device="true" parameter_value="5" device_value="0xff"/>
               </conversion>    
</parameter>
<parameter id="SEND_MIN_INTERVAL">
   <logical type="integer" unit="s" default="10" min="5" max="3600">
     <special_value id="NOT_USED" value="0"/>
   </logical>    
               <physical size="2.0" type="integer" interface="eeprom" endian="little">
                  <address index="+3.0"/>
               </physical>  
               <conversion type="integer_integer_map">
                 <value_map to_device="false" from_device="true" parameter_value="10" device_value="0xffff"/>
               </conversion>    
</parameter>
<parameter id="SEND_MAX_INTERVAL">
   <logical type="integer" unit="s" default="150" min="5" max="3600">
     <special_value id="NOT_USED" value="0"/>
   </logical>    
               <physical size="2.0" type="integer" interface="eeprom" endian="little">
                  <address index="+5.0"/>
               </physical>
               <conversion type="integer_integer_map">
                 <value_map to_device="false" from_device="true" parameter_value="150" device_value="0xffff"/>
               </conversion>    
</parameter>
</paramset>

Die Version, die Du hast, hat allerdings noch den ONEWIRE_TYPE, was nicht so sinnvoll ist. Ich habe Dir hier mal eine neue Version ohne das Feld drangehängt.
Was die Parameter tun sollen ist hier beschrieben:
https://wiki.fhem.de/wiki/HBW-1W-T10#Bedienung_.C3.BCber_eine_Zentrale
In der CCU müsste es so aussehen, wie auf dem angehängten Screenshot.

Hier ist meine alte Routine, die prüft, ob was gesendet werden muss:

Code Auswählen Erweitern


// Pruefen, ob wir irgendwas senden muessen
   long now = millis();
   for(byte channel = 0; channel < MAX_SENSORS; channel++) {
// do not send before min interval
if(sensors[channel].send_min_interval && now - lastSentTime[channel] < (long)(sensors[channel].send_min_interval) * 1000)
  continue;
     if(    (sensors[channel].send_max_interval && now - lastSentTime[channel] >= (long)(sensors[channel].send_max_interval) * 1000)
    || (sensors[channel].send_delta_temp
             && abs( currentTemp[channel] - lastSentTemp[channel] ) >= (unsigned int)(sensors[channel].send_delta_temp) * 10)) {
         // if bus is busy, we might retry
    if(hmwmodule->sendInfoMessage(channel,currentTemp[channel], centralAddressGet()) != 1) {
             lastSentTemp[channel] = currentTemp[channel];
             lastSentTime[channel] = now;
    };
     };
   };

Natürlich hast Du nur einen Sensor, da kann das Zeugs mit dem Array wegfallen.

Wenn Du es für den ersten Wurf nicht so kompliziert machen willst, dann sollte das Senden wenigstens etwas seltener kommen. So etwa alle 2 Minuten wäre wahrscheinlich gut.

Das Lesen des Sensors geht hoffentlich sowieso non-blocking, da es ansonsten ca 750ms blockiert. Sag' Bescheid, wenn Du dazu noch Coding willst.

Gruß,
   Thorsten

[ManfredC]

Moin,

Temperaturmeldungen  alle 5 oder gar zehn Minuten reicht meiner Meinung nach. Die meisten Funkthermometer senden auch nicht öfter, und für die Raumregelung ist das dicke ausreichend.

@Viktor: wie ist es denn mit der Temperatur bei eingeschalteten LEDs? Bei dem einfachen Taster, der ja einen Längsregler für die 5V Erzeugung nutzt, steigt die Platinentemperatur merklich an wenn alle 6 LEDs eingeschaltet sind. Ich versorge den Taster mit 24V weil die am wired Bus eh vorhanden sind.

Gruß,

Manfred

[QLink]

Hier der nächste Fortschritt:
Leds lassen sich per WebUI dimmen und liefern auch den korrekten Wert als feedback.
Temperatur ist auch schon da. Sie wird alle 10s nach der letzten Meldung aus dem DS1820 ausgelesen und erneut gemeldet. Morgen mach ich mich dann an die Helligkeitsermittlung dran. Zumindest erst mal den ADC Wert verfügbar machen, damit dann weitere tests folgen können.

Nächste Woche werde ich dann im HausBus-Wiki beschreiben wie man das ganze in Betrieb nehmen kann und hier den Link posten.

Hi Viktori,

das sind ja super Neuigkeiten. Vielen Dank für deine tolle Arbeit !
Verstehe ich es richtig, dass der Taster auch einen Helligkeitssensor hat ?
Wie stark der Temperatursensor verfälscht wird durch die Platinentemperatur würde mich auch interessieren ?
Wäre es eventuell auch möglich einen Feuchtigkeitssensor zu integrieren ? Wie würde es hier mit der Messgenauigkeit aussehen ?

Beste Grüße

[Thorsten Pferdekaemper]

Hi Viktor,
ich habe mal eine Übersicht des EEPROM-Layouts, das sich aus dem letzten XML ergibt, hier drangehängt. Es geht von einer EEPROM-Größe von 1k (1024 Byte) aus. Wenn das EEPROM Deines Controllers eine andere Größe hat, dann müsste man ggf. etwas ändern.
Hier noch die Erklärung zu den einzelnen Parametern:

LOGGING_TIME: Das ist ein Byte und wird in zehntel Sekunden angegeben. Kleinster "erlaubter" Wert ist 0.1s, größter 25.5s. Etwas komisch ist, dass der Default-Wert 5.0s ist, da der Default normalerweise bei 0xFF angenommen wird, aber das ist ja schon 25.5s.
Das kannst Du jetzt so interpretieren, wie Du willst.
Die Verwendung davon ist: Wenn ein Aktor (also bei uns einer der Dimmer) geschaltet wird (egal ob über die Zentrale oder über ein direktes Peering), dann gibt er nach dieser Zeit nochmal eine Rückmeldung über den aktuellen Wert.

CENTRAL_ADDRESS: Das ist die Adresse der Zentrale. Normalerweise erledigt das die Library, also Du musst damit wahrscheinlich gar nichts tun.

LONG_PRESS_TIME: Das ist die Zeit, die ein Tastendruck mindestens dauern muss, bis er als langer erkannt wird. Ein Byte, Einheit ist Zehntelsekunde. Erlaubte Werte sind 0.4 bis 5.0, alles andere sollte als 1s interpretiert werden.

LOGGING: Das ist ein Bit und schaltet das Logging an (1) und aus (0). Siehe auch LOGGING_TIME.

SEND_DELTA_TEMP: Das is ein Byte und die Angabe ist in zehntel Kelvin (ok, da steht °C im XML...). Erlaubte Werte gehen von 0.1 bis 25.0. Bei 0 wird das Feature nicht verwendet.
Alles andere sollte als Default, also 0.5K 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.

Die SEND_...-Parameter sind auch noch hier beschrieben:
https://wiki.fhem.de/wiki/HBW-1W-T10#Bedienung_.C3.BCber_eine_Zentrale

Gruß,
   Thorsten

[Viktor Pankraz]

@Viktor: wie ist es denn mit der Temperatur bei eingeschalteten LEDs? Bei dem einfachen Taster, der ja einen Längsregler für die 5V Erzeugung nutzt, steigt die Platinentemperatur merklich an wenn alle 6 LEDs eingeschaltet sind. Ich versorge den Taster mit 24V weil die am wired Bus eh vorhanden sind.

Das Layout der Platine hat auch einen optionalen DCDC Wandler, der bei den einfachen Plainen aus Kostengründen nicht bestückt ist. Die Platinen mit MCU hat den DCDC Wandler ( Eingang 7-30V, Output 5V ) und einen linear Wandler von 5V auf 3,3V. Dieser liegt so weit wie möglich weg vom Sensor. Die Erwärmung ist kaum merklich. Aber ich werde dazu mal einen Versuch machen um die exakte Abweichung zu ermitteln.

Verstehe ich es richtig, dass der Taster auch einen Helligkeitssensor hat ?
Wie stark der Temperatursensor verfälscht wird durch die Platinentemperatur würde mich auch interessieren ?
Wäre es eventuell auch möglich einen Feuchtigkeitssensor zu integrieren ? Wie würde es hier mit der Messgenauigkeit aussehen ?

Ja im Layout git es drei verschiedene Positionen für Photodioden, die an einem ADC Eingang des Controllers angeschlossen sind. Allerdings müssen bei der Messung die LEDs ausgeschaltet werden und die Transparenz der Blende spielt natürlich auch eine große Rolle. D.h. im Moment werde ich erstmal nur den ADC Wert direkt ausgeben und dann müssen einige Versuche zeigen, ob es funktionieren kann oder nicht. Habe bisher aber noch keine Versuche gemacht...
Einen DHT22 Feuchtesensor hatten wir auch in unserem eigenen Bussystem an den Taster angeschlossen, funktioniert problemlos. Allerdings hatten wir für den Sensor eine spezielle Blende die eine passende Aussparung hatte, so dass die Feuchtigkeit auch korrekt gemessen werden konnte.

@Thorsten
Danke für das Eeprom Layout in der Exceldatei. Werde es mal mit dem Layout in der FW abgleichen. Das Eeprom ist bei diesem Controller auch nur 1k groß.

[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

[Viktor Pankraz]

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.

Einverstanden.

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.

Bei nicht angeschlossenem Helligkeitssensor ist der Pegel über den Widerstand an einem definierten Potential und flattert nur einige wenige digits. Sollte bei 50 als default also kein Problem darstellen.

hier ist jetzt auch die neue XML.

Danke, das geht ja schnell

um welchen DCDC-Wandler geht es denn überhaupt?

Um den DCDC neben dem großen Kondensator auf der Rückseite

[Thorsten Pferdekaemper]

Danke, das geht ja schnell

Ja, jetzt hat mich die Erkältung erwischt und um wenigstens Julian und seine Mama schlafen zu lassen bin ich zum Husten schonmal nach unten gegangen...

Um den DCDC neben dem großen Kondensator auf der Rückseite

Ah, es geht also nur darum, die Abwärme vom Temperatursensor wegzubekommen. Richtig?

Gruß,
   Thorsten

[Viktor Pankraz]

Ah, es geht also nur darum, die Abwärme vom Temperatursensor wegzubekommen. Richtig?

Exakt

[Thorsten Pferdekaemper]

Hi,
vielleicht wäre es da einfacher und zielführender, wenn man einen zweiten Sensor anklemmen kann, den man dann selbst an geeigneter Stelle verlegen kann. Wir könnten dann ja eine Option spendieren, die den zweiten Sensor statt des ersten benutzt.
...oder wir machen halt doch gleich zwei Kanäle dafür. Der Key des ersten ist ja bekannt, da weiß man dann ja, welches der zweite ist. Oder?
Gruß,
   Thorsten

[ManfredC]

Hi Viktor,

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).

Da frage ich mich warum man den Prozessortaster nimmt, wenn man keinen Bus verwenden will. Dann kann man ja auch den Standard-Taster verwenden.

Grüße,

Manfred

[Viktor Pankraz]

vielleicht wäre es da einfacher und zielführender, wenn man einen zweiten Sensor anklemmen kann, den man dann selbst an geeigneter Stelle verlegen kann. Wir könnten dann ja eine Option spendieren, die den zweiten Sensor statt des ersten benutzt.

Der Temperatursensor auf der Platine ist optional und bisher nicht standardmäßig bestückt und der 1-Wire Anschluss ist auch extern verfügbar. D.h. jeder, der kann da einen externen anschließen und dahin legen, wo er messen möchte und es würde bereits mit der aktuellen FW funktionieren. Schöner fände ich natürlich, dass man da mehrere Kanäle anbietet und der Benutzer auch mehrere externe anschließen kann.

Da frage ich mich warum man den Prozessortaster nimmt, wenn man keinen Bus verwenden will. Dann kann man ja auch den Standard-Taster verwenden.

Die Homematic version ist ja nicht die einzige die den Prozessor hat, es gibt auch andere Systeme, die den Taster exakt so nutzen (mit anderer FW natürlich). Natürlich kann ich für jeden Anwendungsfall (Bussystem) ein Bestückungsvariante erzeugen und auch eine neue Variante der Adapterplatine anlegen. Dies erzeugt für mich aber zu viel Arbeit und ich kann nicht in geringen Stückzahlen alle Varianten produzieren lassen ohne dass es dann richtig ins Geld geht. Wenn ich allerdings von der Homematic Variante gleich 100-200St. auflegen kann und sie mir garantiert abgenommen werden, kann ich da gerne weiter optimieren

[QLink]

Wenn ich allerdings von der Homematic Variante gleich 100-200St. auflegen kann und sie mir garantiert abgenommen werden, kann ich da gerne weiter optimieren

Wenn das Ding stabil funktioniert und du die Verfälschung des Temperaturfühlers noch in den Griff bekommst, denke ich wird das Ding fliegen.
Eine gute Anleitung natürlich vorausgesetzt.

Eine Frage: Wenn mein Schalterprogramm(Schrack Visio 50: http://image.schrack.com/datenblaetter/h_ev1xxxxx--_de.pdf) nicht in den aufgeführten dabei ist, welche Möglichkeit hab ich dann den Taster zu integrieren ?

[Viktor Pankraz]

hmm mit 50mm Innenmaß wird es in der Tat schwierig. Die Tasterplatine ist 54,5x54,5mm und passt wunderbar in viele Schalterprogramme mit 55x55mm Zentralplatten Maße. Den Taster auf 50mm kleiner zu machen wäre ein redesign

[Viktor Pankraz]

Hier übrigens eine aktuelle FW. Sozusagen die erste Version die laufen sollte und folgende Features hat:
- 6 Taster inkl. 30 peering Kanäle
- 6 LEDs inkl. 30 peering Kanäle
- Temperatursensor (aber noch nicht kompensiert )
- Analog-Eingang um Helligkeit zu messen ist noch deaktiviert
- automatisches LED Feedback bei Tastendruck

Würde gerne wissen, ob es in der FHEM Umgebung schon gut funktioniert und stabil eingesetzt werden könnte. Zu hause teste ich noch mit ner CCU2 auf dem PI (https://github.com/leonsio/YAHM)

Nächste FW soll dann noch die von Thorsten gewünschten Blink-Features (BLINK_ON, BLINK_TOGGLE) realisieren.

[Viktor Pankraz]

Hallo Thorsten,

habe mal eine Direktverknüpfung von Taster:1 und LED:12 angelegt. Dann sehe ich folgenden Datenverkehr zwischen CCU und dem Taster:

I-Nachricht an 0x42FFFFFF von CCU: Daten [20] WRITE_EEPROM address: 40, nrBytes = 16 data = 0 42 FF FF FF B FF FF FF FF FF FF FF FF FF FF
ACK-Nachricht an CCU von 0x42FFFFFF:

I-Nachricht an 0x42FFFFFF von CCU: Daten [20] WRITE_EEPROM address: F0, nrBytes = 16 data = FF FF FF FF 42 FF FF FF 0 B FF C8 0 C8 0 FF 
ACK-Nachricht an CCU von 0x42FFFFFF:

Der erste Schreibbefehl auf Adresse 0x40 und 0xF0 ins Eeprom scheint OK zu sein und die Daten sehen auch plausibel aus.
Aber ich kann die Parameter in der WebUi nicht bearbeiten sobald ich auf "Bearbeiten" klicke, bekomme ich nur eine leere Seite angezeigt. Hast du ne Idee? Vielleicht noch etwas in der xml-Datei?

[Thorsten Pferdekaemper]

Würde gerne wissen, ob es in der FHEM Umgebung schon gut funktioniert und stabil eingesetzt werden könnte.

Ich habe vor, das in den nächsten paar Tagen auszuprobieren. Kannst Du mir den schnellsten Weg sagen, wie ich das Hex-File auf das Gerät laden kann?

Der erste Schreibbefehl auf Adresse 0x40 und 0xF0 ins Eeprom scheint OK zu sein und die Daten sehen auch plausibel aus.
Aber ich kann die Parameter in der WebUi nicht bearbeiten sobald ich auf "Bearbeiten" klicke, bekomme ich nur eine leere Seite angezeigt. Hast du ne Idee? Vielleicht noch etwas in der xml-Datei?

Eigentlich ist mir persönlich ziemlich egal, was die CCU macht, aber...
Für mich sieht das auch alles gut aus. Die CCU scheint das ganze ja auch erstmal richtig interpretiert zu haben. Hast Du mal nachgeschaut, ob im Log der CCU was ankommt? Also auf die CCU per SSH oder so und dort

Code Auswählen Erweitern


tail -f /var/log/messages

Die nötigen Einstellungen solltest Du in der CCU unter "Systemsteuerung-> Sicherheit" finden.

Möglicherweise muss man in der CCU auch irgendeinen Expertenmodus aktivieren.

Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
ich habe jetzt versucht, das neue hex-file per Flip auf den Taster zu laden. Allerdings scheitere ich am Flip. Wenn ich zur Verbindung "USB" wähle, dann bekomme ich die Fehlermeldung
"AtLibUsbDfu.dll not found"
Wenn man danach im Internet sucht, dann erfährt man, dass das wohl an USB-Treiberproblemen liegt. Tatsächlich nennt mein Win7 das Teil auch "Unbekanntes Gerät" oder so. Allerdings enden alle Versuche, einen Treiber laut der verschiedenen Lösungen zu installieren in einer Meldung, dass schon der optimale Treiber installiert sei.
Ich habe dann den USB-Treiber im "freien" Tool "dfu-programmer" probiert, was auf dasselbe herauslief.
Ich weiß jetzt nicht so recht weiter...
Gruß,
   Thorsten

[Viktor Pankraz]

Also ich habe dies mindestens auf 4 verschiedenen Rechnern getestet, aber dies Problem noch nie gehabt. Ein Unteschied zu dir wird vielleciht sein, dass ich immer vorher noch das Atmel Studio installiert habe. Bei der Installation werden auch USB Treiber installiert. Aber eigentlich sollte es auch ohne gehen:
Ich habe immer dieser Variante FLIP 3.4.7 for Windows (Java Runtime Environement included) installiert. Welche hattest du?

ah was mir noch gerade einfällt. Hast du auch den Bootloader gestartet (grüne und rote LED auf der Rückseite blinken im Wechsel)? Hier www.haus-bus.de/wiki/index.php/Produktbeschreibung_SD6 ist beschrieben, wie du den Bootloader startest und hier http://www.haus-bus.de/wiki/index.php/HowTo_Eigene_Firmware_laden ist die Beschreibung wie die FW geladen werden muss.

[Thorsten Pferdekaemper]

Hast du auch den Bootloader gestartet (grüne und rote LED auf der Rückseite blinken im Wechsel)? Hier www.haus-bus.de/wiki/index.php/Produktbeschreibung_SD6 ist beschrieben, wie du den Bootloader startest

Das mit der Taste 6 hatte ich nicht gesehen. Ich werd's mal heute abend probieren.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
also erst einmal die gute Nachricht: Ich habe es jetzt geschafft, die neue Firmware aufzuspielen, das ganze funktioniert im Prinzip in FHEM und Peerings funktionieren im Prinzip auch.

Nachdem ich die Taste 6 vor dem Einstöpseln gedrückt hatte, kam tatsächlich das rot/grüne Blinken. Die Fehlermeldung kam in Flip aber trotzdem noch. Allerdings taucht das Teil im Geräte-Manager jetzt unter "Andere Geräte" auf und ich konnte den Treiber per "Treiber aktualisieren" nachinstallieren.
Das eigentliche Flashen ging dann so schnell, dass ich mir nicht sicher war, ob es auch geklappt hat. Die Rückmeldung vom Flip sind ja nicht sooo der Hit.

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.

Getestet habe ich in FHEM was mir halt so einfiel. Das kam dabei raus:

• 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%.
• 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.

So, das war's jetzt erstmal.
Gruß,
   Thorsten

[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

[Thorsten Pferdekaemper]

Hi,
ich bin auch gerade erst wieder nach Hause gekommen. Ich werde mir das alles in den nächsten Tagen genauer anschauen und meinen Senf dazugeben.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Also wenn ich es richtig verstehe, dann ist für alle Aktionen aus den Peerings offLevel und onLevel zu benutzen, richtig?

Genau so war es gemeint.

Hier die FW 1.02:

Da ich jetzt 10 Tage weg war ist bei mir auch einiges liegen geblieben. Ich hoffe aber, dass ich das in den nächsten drei Tagen testen kann.

und das Verhalten sollte so sein wie Thorsten es sich gewünscht hat

Dankeschön.

• 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.

Ich denke, dass es ausreicht, wenn man sich jeweils nur die Daten des letzten Key-Events merkt, welches zu einem Peering gehört. D.h. man hat nur genau eine Device/Kanal/Nummer-Kombination im Speicher. Die Wiederholungen kommen alle 300ms. Dazwischen kommt dann noch mindestens ein ACK, wenn das Ding gepeert ist. Im Prinzip kann also kaum was dazwischenfunken.
Wenn man's ganz richtig machen will, dann würde es auf jeden Fall ausreichen, einen "Datensatz" pro gepeertem Aktor-Kanal zu speichern.
Wenn das alles zu kompliziert wird, dann kann ich mir auch vorstellen, dass wir das ganze ge-toggle weglassen. ...zumindest bei langen Tastendrücken.

Es könnte funktionieren, wenn auch die Anzahl der Wiederholungen mit übertragen werden würden

Tja, wirds aber nicht. Selbst wenn wir das machen würden, würde es nichts nützen, da es die Original-Geräte nicht machen.

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

Das klingt schonmal nicht schlecht, aber warum muss man dafür neu starten? Nach einer EEPROM-Änderung sollte jedesmal ein 0x43 kommen, das dem Gerät signalisiert, jetzt bitte die Konfiguration neu zu lesen. Dann könnte man relativ locker das neue Gerät "anlegen" und dafür auch eine A-Message senden. Zumindest in FHEM würde das neue Gerät dann automatisch angelegt werden. In der CCU müsste es dann im "Posteingang" landen.
Beim Entfernen muss die Firmware nur alles zum zweiten Gerät "sperren" und in FHEM (oder auch der CCU) kann man alles löschen. Das ist dann so, als ob man ein Gerät vom Bus nimmt.

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

Also irgendwie finde ich das immer noch hässlich. Andererseits hat ein HMW...12/14 er ja auch alle Kanäle, auch wenn nur drei genutzt werden.  Wir hätten dann 12 Tastereingänge, 12 LED-Ausgänge, 1 AD-Wandler und 1 (oder 2?) Temperaturkanäle. Richtig?

Dritte Möglichkeit sind 2 verschiedene Definitionen in XML und 2 verschiedene FW.
Letztes finde ich aber sehr unschön

Also ich finde das auch nicht gerade schön, aber so schlimm auch wieder nicht, zumindest nicht für den Anwender. Der Anwender muss sich ja sowieso seine Firmware selbst auf das Teil schießen, da sollte die Entscheidung dann ja nicht schwer fallen. Andererseits kann mich mir vorstellen, dass dann viele "just in case..." die große Firmware nehmen.

Aber was ist eure Meinung als Benutzer solcher Geräte?

Meine persönliche Meinung ist, dass man die Erweiterung eigentlich nicht braucht. Bausteine mit Tastereingängen und Aktorausgängen gibt es schon. Die kann man dann anbinden. Außerdem ist ein zweiter SD6 gegenüber einem 6-fach Taster ohne Prozessor auch nicht so viel teurer.
Aber wenn das andere haben wollen, dann bauen wir's vielleicht doch ein.

Gruß,
   Thorsten

[Viktor Pankraz]

Meine persönliche Meinung ist, dass man die Erweiterung eigentlich nicht braucht. Bausteine mit Tastereingängen und Aktorausgängen gibt es schon. Die kann man dann anbinden. Außerdem ist ein zweiter SD6 gegenüber einem 6-fach Taster ohne Prozessor auch nicht so viel teurer.
Aber wenn das andere haben wollen, dann bauen wir's vielleicht doch ein.
Gruß,
   Thorsten

Bei R******t kostet die CPU schon knapp 5 EUR + 1 EUR für DCDC + RS485 Adapterplatine, die wegen der beidseitigen Bestückung 4 Euro teurer als die normale ist. Kommen also schon min. 10EUR zusammen, die der Einfache Taster als Erweiterung günstiger wäre. Und das ist für die meisten schon ein Grund, sich die Erweiterung zu wünschen. Ich selber habe ja kein Homematic und würde nicht vorschlagen ne Erweiterung zu unterstützen, wenn da nicht jeder Kunde bereits danach fragt

[Thorsten Pferdekaemper]

Naja, also die 10 Euro wären mir das Gefummel mit den vielen Strippen nicht wirklich wert...
Aber egal, wenn Du es unterstützen willst, dann machen wir's halt.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hier die FW 1.02:
[...]

• Das Blinken der LEDs wird nun durch neues Kommando abgebrochen
• TOGGLE verwendet nun auch die Peering Parameter
• BLINK_TOGGLE ist implementiert und getestet

Hi,
das funktioniert jetzt im Prinzip, nur dass "blink_quantity = 0" immer noch das Blinken ganz abschaltet. Das ist nicht wirklich sinnvoll, da es ja sowieso nur blinkt, wenn bei ..._action_type so angegeben. Könntest Du das noch ändern, so dass es bei 0 endlos blinkt?
Das ist aber nicht so dringend. Etwas blöd ist dagegen, dass on/off/level nicht mehr funktioniert. "on" schaltet die LED aus, "off" schaltet sie an und ein "level" ungleich 0 und 100 macht gar nichts.
Kannst Du das nachvollziehen?
Gruß,
   Thorsten

[Viktor Pankraz]

Hi Thorsten,

Oh man, wie konnte ich es nur übersehen  on/off/level Kommandos wurden immer im mit Toggle überschrieben. Ist nun in FW 1.03 gefixt und liegt im Repository
https://github.com/haus-bus/MultitasterSD6/tree/HM-Wired/binaries

nur dass "blink_quantity = 0" immer noch das Blinken ganz abschaltet. Das ist nicht wirklich sinnvoll, da es ja sowieso nur blinkt, wenn bei ..._action_type so angegeben. Könntest Du das noch ändern, so dass es bei 0 endlos blinkt?

hmm, für mich ist es genau andersrum unsinnig: Warum 0 wenn ich doch endlos blinken will? 255 ist das maximum was mit einem byte angegeben werden kann, das kann man ja für endlos verwenden. Während des blinkens zähle ich runter und wenn ich bei 0 ankomme bleibt das blinken automatisch aus danach. Andersrum müsste ich im Programm beim Runterzählen dann die 0 mit 255 ersetzen, wenn ich von 1 komme und andernfalls endlos blinken, was im Programm sehr unschön ist...

Oder verstehe ich einfach noch nicht warum 0=endlos sein muss und 255=unused? Ist das bei Homematic immer so spezifiziert? Stört es andere Geräte oder kommen die User nicht damit klar, wenn hier 0=not_used ist?

Gruß,
Viktor

[Thorsten Pferdekaemper]

Oh man, wie konnte ich es nur übersehen  on/off/level Kommandos wurden immer im mit Toggle überschrieben. Ist nun in FW 1.03 gefixt und liegt im Repository
https://github.com/haus-bus/MultitasterSD6/tree/HM-Wired/binaries

Ok, frühestens morgen Abend werde ich das mal ausprobieren.

hmm, für mich ist es genau andersrum unsinnig: Warum 0 wenn ich doch endlos blinken will?

Weil der Wert 0 an sich unsinnig ist und damit prädestiniert für eine Sonderbehandlung.

255 ist das maximum was mit einem byte angegeben werden kann, das kann man ja für endlos verwenden. Während des blinkens zähle ich runter und wenn ich bei 0 ankomme bleibt das blinken automatisch aus danach.
Andersrum müsste ich im Programm beim Runterzählen dann die 0 mit 255 ersetzen, wenn ich von 1 komme und andernfalls endlos blinken, was im Programm sehr unschön ist...

Das verstehe ich jetzt nicht ganz, aber das mit dem Runterzählen ist tatsächlich einfacher, wenn 0 "Ende" bedeutet.

Oder verstehe ich einfach noch nicht warum 0=endlos sein muss und 255=unused?

So hatte ich das auch gar nicht gemeint. "unused" und "endlos" ist für mich dasselbe. Wenn der Parameter "Blinken nach n Blinks beenden" nicht benutzt wird, dann kommt dabei "für immer blinken" raus.

Ist das bei Homematic immer so spezifiziert? Stört es andere Geräte oder kommen die User nicht damit klar, wenn hier 0=not_used ist?

Nein, nichts davon.
Wir können das auch ändern, wenn es Dir lieber ist. Ich werde dann mal das XML so abändern, dass für blink_quantity nur Werte von 1 bis 254 erlaubt sind und 255 als "forever" oder "endless" ausgegeben wird. Dann gibt's auch keine Missverständnisse mehr.
"0" kann man dann gar nicht mehr eingeben. Bei 0-mal blinken kann man ja auch das Peering gleich ganz weglassen.

Gruß,
   Thorsten

[Viktor Pankraz]

Hallo,

hier hat sich nun schon länger nichts getan und ich weiß auch nicht wie viele den MultiTaster von Haus-Bud.de in einer FHEM Umgebung einsetzten, aber ich wollte hier mal den aktuellen Stand posten:

Aktuelle FW Version ist 1.08 und seit der letzten hier veröffentlichten hat es einige Änderungen gegeben (alles basierend auf realen Kundenwünschen). Hier ein Überblick der Historie

• v1.04 es werden 32 Kanäle - 12x Key, 12xx Led, 6x DS18x20 - angeboten, d.h. ihr könnt bis zu insgesamt 6 Temperatursensoren an den Taster anklemmen (inkl. des evtl onBoard Sensors)
• v1.05 Fehler in direkten Verknüpfungen behoben
• v1.06 neues Feature: Eingänge können ACTIVE_LOW oder ACTIVE_HIGH konfiguriert werden
• v1.07 bug in der Ansteuerung des RS485 Transceivers behoben ( Taster hatte nicht immer alle Nachrichten empfangen können und schien offline zu sein; Außerdem ist das LED_FEEDBACK pro Taste individuell konfigurierbar
• v1.08 neues Feature: Eingang kann als Taster oder Schalter konfiguriert werden, damit können nun auch Bewegungsmelder oder andere Sensorik an den Taster angeschlossen werden

Ich hänge hier mal den letzten Stand nochmal an

Gruß,
Viktor

[ManfredC]

Hallo Viktor,

Ich hänge hier mal den letzten Stand nochmal an

vielen Dank, werde ich am WE testen.

Grüße,
Manfred

[loetmeister]

Hallo,

um eine Firmware zu laden muss der Taster vom Bus getrennt und das USB Kabel an JP3 angeschlossen werden? Oder ist ein Update über den Bus möglich?
[EDIT: Es sieht für mich so aus, als ob das Update über den Bus seit v1.08 mit dem aktuellen "SD6-Booter"gehen müsste... Wobei dann alle 6 weißen LEDs blinken - nicht die LEDs auf der Rückseite?]

Noch eine andere Frage 
Welcher RS485 Transceiver ist verbaut? Ich habe schon ein paar eigene Module mit MAX487CSA....

Gruß,
Thomas

[Viktor Pankraz]

Hallo Thomas,

ja, seit FW 1.08 gab es einige änderungen an dem Konzept insgesamt. Will versuchen sie entsprechend im Wiki zu dokumentieren (in den Tagen zwischen Weihnachten und Neujahr). Hier schon mal vorab:

• seit FW 1.08 gibt es auch einen Homematic Booter, wo nicht mehr das USB Kabel benötigt wird, sondern direkt am BUS geladen werden kann. Dies geht leider noch nicht mit der CCU (bin da aber noch dran). Im Moment kann man zum Download einer neuen FW das Tool SerialCommunicator, dass im Git Repository abgelegt ist, benutzen. https://github.com/haus-bus/MultitasterSD6/blob/HM-Wired/Tools/SerialCommunicator.exe (genaue Beschreibung folgt im WIKI
• mit der nächsten Hardware version des Tasters werden die rote und grüne LED hinten entfallen, da sie im eingebauten zustand sowieso schwer zu erkennen waren. Stattdessen nutzt der Booter die vorderen LEDs als anzeige. Kurzes aufblitzen (1x pro s) bedeutet Booter ist aktiv und wartet auf Daten. Sobald Daten eintreffen leuchten die LEDs im Kreis reihum auf und gehen wieder aus. Ist der Download komplett, startet die neue FW wenn kein Fehler vorliegt (LEds sind dann wieder alle aus und bei Tastendruck sollten sie als Feedback leuchten) Bleiben die LEDs einfach an, so ist beim download ein Problem aufgetreten und muss wiederholt werden
• seit FW 1.10 ist die Kommunikation auf Interrupt getriebenen Empfang mit einem Nachrichten Puffer umgestellt. Auch die gesendeten Pakete warten nicht mehr direkt auf ein ACK, was bei BUS störungen immer zu "hängender Feedback LED" geführt hat. Die Nachricht wird jetzt verschickt und in einem Vector gehalten bis das ACK dafür eintrifft. Kommt innerhalb 150ms kein ACK wird die Nachricht von der Kommunikationsschicht automatisch bis zu 3x wiederholt und anschließend ausdem Vector entfernt
• es wird für die Ein- und Ausgehenden Nachrichten dynamische Puffer verwendet max 8 IN und 16 OUT
• Tastendrücke senden jetzt auch immer eine announce Nachricht mit solange sie noch nicht verlinkt worden sind. Damit ist auch kein gleichzeitiges drücken der Taste 5 und 6 mehr erforderlich und auch kein neustarten des Tasters bei laufender Software um die Announce Nachricht zu bekommen.

Aktuell ist FW 1.12 wo einige wichtige Fehlerbilder noch behoben worden sind.

• Der verwendete interne Oscillator ist zu ungenau und hat zwischendurch die baudrate 19200bps nicht erreicht, was zu Probleme in der Kommunikation zu anderen Geräten führte. Mit aktivierter automatischer Kalibrierung konnte ich das Problem nicht mehr sehen
• In Vorbereitung zur nächsten Hardware version des Tasters wird die HW_REV im EEPROM abgelegt. FW 1.12 setzt die HW_REV für bisher ausgelieferte Taster auf REV0 wenn die Zelle noch den Wert 0xFF enthalten sollte

Habe hier FW 1.12 nochmal angehängt.
Wer den USB DFU Booter noch hat, benötigt die HEX Datei. Für den Download über den SerialCommunicator muss die BIN-Datei verwendet werden.

Gruß,
Viktor

[loetmeister]

Hallo Viktor,

das klingt wirklich gut.
Um vom DFU auf den Homematic Booter zu wechseln müsste ich aber an den PDI des XMEGA, richtig?
Ich bin echt gespannt auf die neue Hardware Version... falls du jemand zum Testen brauchst... 

Falls die REV_1 Hardware noch nicht Final ist...  würde es sinnvoll sein eine Verpolungsschutzdiode ("Idioten-Diode"  ) für den 24V Busanschluss einplanen? Ich habe für meine Geräte eine B140 / SB140 eingebaut. (0,5 V drop bei 1A)
Noch eine Anmerkung. In deinem aktuellen Schaltplan ist C22 mit 470pF angegeben, wenn ich aber die Formel im MC34063A Datenblatt anwende, müsste Ct=150 pF haben, dann kann L=222 µH sein, bei ca. 62 kHz Mindestfrequenz (Ipk=300 mA, Rsc=1 Ohm, R1=1k, R2=3k (5V output)).

Gruß,
Thomas

[Viktor Pankraz]

Hallo Thomas,

danke für den Hinweis. Der C22 ist eindeutig zu groß. War vorher auch immer auf 220pF gewesen, muss irgendwie mit dem C11 vereinheitlicht worden sein.
Die REV_1 enthält den Verpolungsschutz und ab der nächsten Charge nun auch wieder den kleinen C22.
Aktuell arbeite ich daran, dass das flashen der FW auch im Hausbus über flash-ota funktioniert. Es stehen noch ein paar tests aus, aber kann nicht mehr lange dauern.

Gruß,
Viktor

[loetmeister]

Hallo Viktor,

ich wollte einen der beiden Analogen (HmwAnalogIn) Kanäle nutzen... dabei hab ich gesehen das die Analogeingänge schon vor einiger Zeit aus dem Quelltext geflogen sind. Einfach die Kanäle wieder anlegen ist wohl nicht.. der ganze adc_init(void) Teil fehlt...
Hast du das noch auf deiner "Entwicklungs-roadmap"?

Code Auswählen Erweitern

// default constructor
HBWMultiKeySD6BaseHw::HBWMultiKeySD6BaseHw( PortPin txEnablePin, PortPin owPin, bool invertLed1To6 ) :
...
HmwAnalogIn hbwAnIn1 ( &ADCA , ADC_CH0, &config.analogInCfg[0] ),
HmwAnalogIn hbwAnIn2 ( &ADCA , ADC_CH1, &config.analogInCfg[1] ),

Ich könnte das im HmwAnalogIn::loop hart verdrahten... so schön wärs natürlich nicht...
http://wa4bvy.com/xmega_doxy/adc_quickstart.html

Gruß,
Thomas

[loetmeister]

Hi Viktor,

habe mal den ADC mit den beiden Analog Kanälen ans laufen gebracht:
https://github.com/loetmeister/HBW-Devices/commit/90989030952e9bd046ec251708ae0ea007b124f4

Ist stellenweise etwas quick & dirty, aber es läuft. 

Ultimatives Ziel wäre die Funktionalität des Bewegungsmelders zu erweitern. Meine Vorstellung: PIR Modul an EXT_S1 anschließen und input_type -> "motionsensor" setzten. Dieser neue input_type verhält sich ganz ähnlich zu "switch", schickt aber den Helligkeitswert mit dem Key Event mit. So sind direkte peerings mit einer Schaltschwelle möglich.

Update:
Habe mal input_type "motionsensor" hinzugefügt + zwei weitere Kanäle, welche die Helligkeit aus Kanal 31 und 32 über einen längeren Zeitraum Berechnen ("moving average" - aktuell max. 34 Minuten, ist aber Konfigurierbar) und als 0...100% ausgeben.
https://github.com/loetmeister/HBW-Devices/commit/be7fa9798829863f80836d74a83e89fac0888a6e


Bsp. vom HM-Sec-MDIR-2:
Sie haben die Möglichkeit, den Funk-Bewegungsmelder mit oder ohne
Helligkeitsschwelle anzulernen.
[...] wobei insgesamt und fortlaufend die letzten 8 Helligkeitswerte
(Messung alle 6 Minuten) in einem internen Speicher gespeichert werden
und der niedrigste Helligkeitswert als Schaltkriterium herangezogen
wird.



Mal eine Frage zur Debug Ausgabe. die CRC Fehler beziehen sich auf Empfangene Frames? Oder kann das andere Quellen haben?

Code Auswählen Erweitern

>15BB ERROR> CRC 0 0 0 1 F8 60 8F 3D 0 6 69 1B 95 4D AD
>1598 ERROR> CRC 0 0 0 1 FC 60 8F 3D 0 6 69 60 8F 3D 0
>15BD ERROR> MsgTooLong
>1639 ERROR> CRC 0 0 0 1 FC 60 8F 3D 0 6 69 19 95 4D D7
>324D -C: GET_LEVEL


Gruß,
Thomas

[loetmeister]

Hallo,

ich habe die Funktionen für einen Bewegungsmelder mit Helligkeitsmessung nun eingebaut, aber etwas anders wie zunächst angedacht.
--> https://github.com/loetmeister/HBW-Devices

Homematic Geräte mit Funk nutzen einen eigenen Nachrichtentyp (message id=0x41), bei dem der Helligkeitsmesswert mit dem Schaltsignal (KeyEvent) mitgesendet wird und dann der Aktor im peering einen Schwellwert konfiguriert hat.
Homematic Wired kennt diesen Nachrichtentyp wohl nicht. Ursprünglich wollte ich diesen Hinzufügen, dann hätten jedenfalls alle Homebrew Geräte diese Funktion erhalten.

Um Standard Geräte kompatibel zu halten, habe ich es über zwei paar zusätzliche Kanäle im HBW-SD6-Multikey Device realisiert. Es ist nicht ganz so flexibel wie mit dem speziellen Nachrichtentyp, aber lässt doch verschiedene Konfigurationen zu.

Funktion
Kanal 31 & 32 stellen wie bisher den Analogen Messwert (12bit) zur Verfügung.
Kanal 33 & 34 sind fest mit je einem der vorhergehen Kanäle verknüpft, sie errechnen einen 0-100% Helligkeitswert. (Zeitraum ist konfigurierbar, 1,3 bis 60 Minuten)
Kanal 35 & 36 sind wieder fest mit je einem der beiden vorhergehen Kanäle verknüpft, hier wird der Schwellwert festgelegt. (größer oder kleiner gleich dem Helligkeitsmesswert)

Bsp. Konfig:
Der Bewegungsmelder wird an einen der 12 Taster Eingänge Angeschlossen (Kanalkonfiguration "motionsensor"), dann ein peering mit z.B Kanal 33 angelegt. Das Schaltsignal wird intern an Kanal 35 geleitet. Mit diesem Kanal kann dann ganz normal ein externes peering mit einem Aktor angelegt werden. Kanal 35 gibt das Schaltsignal des Bewegungsmelders nur weiter, wenn die Vergleichsoperation zutrifft, d.h. der Helligkeitswert z.B. unterschritten wurde. (siehe screenshot)

Man könnte so auch Bewegungsmelder und Helligkeitssensoren verschiedener HBW-SD6-Multikey Geräte verknüpfen...

Gruß,
Thomas

[a_quadrat]

Hallo,

ich bin vor kurzem auf den HBW-SD6-Multikey gestoßen und bin begeistert. Genau das was ich suche, bis auf die Tasterplatine, die ich nicht benötige. Ich möchte es gern in der UP-Dose verschwinden lassen und mit externen Schalter verdraten. Daher meine Frage, kann ich die Firmware auch auf einen Arduino Nano flashen?

VG Andreas

[loetmeister]

Hi Andreas,

Da der Quellcode verfügbar ist, würde ich sagen es ist möglich. Aber einfach flashen, ohne Anpassung wird wohl nicht funktionieren. Es werden Interrupts und spezielle Funktionen des xmega genutzt. Auch hat der mega 328 auf dem Nano nur halb so viel RAM wie der xmega 32a4u. Kann sein das es passt oder man ein paar Funktionen raus nehmen muss.

Es gibt auch eine Unterputz Version des Schalters. Leider ist der Schaltplan nicht verfügbar, da muss man sich was passendes ausdenken.. 

Gruß,
Thomas

[Thorsten Pferdekaemper]

Hi,
es gäbe da auch noch den HBW-Sen-SC8 und den HBW-Sen-Key-12. (Siehe auch https://wiki.fhem.de/wiki/HomeMatic_Wired#Aktoren_.2F_Sensoren) Wenn man sowieso eigene Taster einbaut bzw. das Geblinke nicht braucht, dann dürften die reichen.
Gruß,
   Thorsten

[a_quadrat]

Hi,

danke für die schnellen Rückmeldungen. Es muss nicht das SD-6 Modul sein, ich beschreibe euch mal was ich vor habe. In meinen Räumen sind zu den Wandthermostaten 5- adrige Leitungen verlegt, die zentral zum Heitzkreisverteiler laufen. Unter den Thermostaten befinden sich die Lichtschalter. Ich möchte die Temperatur und Luftfeuchte messen (aktuell über onewire), das Licht schalten, einen Bewegungsmelder installieren und eine LED zur Anzeige des Heitzbetriebes. Ich benötige also zwei Inputs und zwei Outputs - Temperatur und Luftfeuchte könnte weiter über onewire laufen.
Habt ihr eine Idee, wie ich das realisieren kann?

VG Andreas

[Thorsten Pferdekaemper]

Hi,
es gibt eine Implementierung des HMW-LC-Sw2-DR. (Siehe Wiki.) Der hat 2 Tastsensoren und zwei Schaltausgänge.
Gruß,
   Thorsten

[a_quadrat]

Hi,

danke, ich habe die Version von jfische geflasht, das Gerät wird auch von der CCU erkannt, aber ich kann den Taster und Ausgang nicht direkt verknüpfen. Den Lichtschalter würde ich gern mit dem Ausgang für das Licht verknüpfen, da die CCU für die Auswertung der Taster 1-3 s braucht. Das ist nicht sonderlich komfortabel.
Ist es aufwendig die Verknüpfung zu implementieren?

VG Andreas

[Thorsten Pferdekaemper]

danke, ich habe die Version von jfische geflasht,

Von was? Hast Du einen Link?

das Gerät wird auch von der CCU erkannt, aber ich kann den Taster und Ausgang nicht direkt verknüpfen. Den Lichtschalter würde ich gern mit dem Ausgang für das Licht verknüpfen, da die CCU für die Auswertung der Taster 1-3 s braucht. Das ist nicht sonderlich komfortabel.

Nein, deshalb verwenden die meisten, die hier im FHEM-Forum schreiben auch FHEM.

Ist es aufwendig die Verknüpfung zu implementieren?

Wenn man sich gerade damit befasst, dann nicht unbedingt. Ich bin aber seit einer Weile draußen und habe momentan auch gar keinen Testaufbau. Vielleicht erbarmt sich ja loetmeister...

Gruß,
   Thorsten

[a_quadrat]

Hi,

unter folgendem Link habe ich den Code gefunden:
https://github.com/jfische

Ich nutze auch FHEM, aber bin gerade dabei die HM Komponenten auf eine CCU auszulagern, um auch HMIP und HMIP-wired nutzen zu können.

Die Tastereingänge kann ich mit einem Originalmodul verknüpfen, nur die eigenen Relaisausgänge funktionieren nicht.

VG Andreas

[loetmeister]

Hi,

soweit ich das sehe basiert https://github.com/jfische/HMW_LC_Sw2_DR auf der alten Library von Dirk und Thorsten, welche keine Direktverknüpfungen (peering) unterstützt...
Am besten nimmst du Geräte aus der aktuellen Version als Vorlage, z.B.
https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-Sen-Key-12
https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-LC-Sw-8


Gruß,
Thomas

[a_quadrat]

Hi,

ich habe das LC-Sw-8 Modul schon ausprobiert, aber das peering hat auch nicht funktioniert, zumindest nicht mit original HMW Geräten.
Kann ich die beiden Geräte (Sen-Key-12 und LC-Sw-8) zu einem zusammen fassen?

VG Andreas

[loetmeister]

Hallo Andreas,

Ja, das geht. Wenn du beide kombinierst und die Anzahl der Kanäle auf jeweils zwei reduzierst, hast du die Funktion von HMW-LC-Sw2-DR mit der aktuellen library.

Was war denn bei dem HBW-LC-Sw-8 Modul das Problem? Die peerings zu erstellen? Oder haben sie nicht funktioniert?
Eventuell machst du ein neuen thread dafür auf, um das zu lösen. Wäre ja schade wenn du ein neues Gerät erstellst, was nicht richtig funktioniert.

Gruß,
Thomas

[a_quadrat]

Ich habe ein neues Thema hierfür erstellt.

https://forum.fhem.de/index.php/topic,104354.0.html