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

[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