[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ß.