Homematic Wired - Homebrew Devices

[loetmeister]

Hallo,

habe ein wenig getestet. Peerings und über FHEM.
Das Verhalten der peerings ist denke ich ok, absolute Zeiten überschreiben minimale, delay Zeiten können übersprungen werden, etc.
Toggle (toggle [invers] to counter) lasse ich nur zu wenn keine timer laufen...

Wenn ich aus FHEM ein on/off schicke bin ich mir über das richtige Verhalten nicht ganz klar... aktuell wird immer ein- oder aus geschaltet, ohne aber die timer zu löschen. D.h. läuft der aktuelle timer dann aus, wird wieder aus dem aktuellen Status begonnen: jump table gelesen und z.B. von ON nach offdelay gewechselt.
Bsp. onDealy läuft, FEHM schickt ON -> nach Ablauf des onDealy timers wird zu OFF gewechselt. Der Ausgang war nur kurz eingeschaltet, wäre weder über das peering, noch FHEM das gewünschte verhalten... 

Wenn ich die timer bei einem set() aufruf über FHEM löschen will, nicht aber über ein peering (peeringEventTrigger), bastel ich wieder an der set() Funktion rum...

Aktueller Stand: https://github.com/loetmeister/HBWired/blob/master/HBW-LC-Sw-12/HBW-LC-Sw-12.ino

Edit:
Ich habe mal HBW-LC-Sw-8 mit dem erweiterten Peering erstellt. Ist eventuell was übersichtlicher als der HBW-LC-Sw-12...
Da habe ich peeringEventTrigger() erst mal wieder raus genommen. Mit set() finde ich es eigentlich ganz gut... so "missbraucht" wird die Methode gar nicht
https://github.com/loetmeister/HBWired/tree/master/HBW-LC-Sw-8_AdvancedPeering
https://github.com/loetmeister/HBWired/tree/master/libraries/HBWSwitchAdvanced

Gruß,
Thomas

[Thorsten Pferdekaemper]

Hi,
sorry, dass ich mir das bisher nicht genauer betrachtet habe. Ich hab's aber noch vor...
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
ich komme zurzeit beim besten Willen nicht dazu, mir das ganze wirklich richtig anzuschauen. Ich habe daher Deinen Pull-Request einfach so übernommen. Ich denke, Du weißt, was Du da tust.
Gruß,
   Thorsten

[loetmeister]

Hi Thorsten,

Danke. Es kommen wahrscheinlich nach dem Testen der Elektronik noch ein paar Korrekturen... 


Apropos Elektronik. Für HBW-LC-Sw-12 habe ich mal angefangen die erste Version der Platine zu bestücken und zu testen. Die Platine mit Atmega 328p, MAX 487CSA/ECSA und Spannungsversorgung soll vom grundsätzlichen Aufbau in allen Geräten gleich sein. Sie sitzt oben im Gehäuse und nimmt auch ISP Anschluss, LEDs und Taster auf. Dann gibt es eine weitere Platine auf der Relais und Klemmen montiert sind.
Der Atmel muss hier per ISP geflasht werden, das Hex File lässt sich aber per Arduino IDE erstellen.
Ein Bild vom Gerät im Anhang. Das Gehäuse hat 6 TE.


Gruß,
Thomas

[derHeimwerker]

Hallo Thomas,

wow ... Respekt. Sieht ja sensationell aus. Wenn du die Herstellungskosten durch eine erhöhte Abnahmemenge senken möchtest dann sag gerne Bescheid. Das Projekt "Heimkinosteuerung" steckt zwar noch in den Kinderschuhen, ist aber für die nächsten Winterabende vorgesehen

Gruß
Thomas

[loetmeister]

Hallo Namensvetter,

bisher belaufen sich die Kosten auf die Bauteile, die Platinen fräse ich selber. Ob ich das in größerer Stückzahl mache... mal sehen.
Im Anhang mal die Erste Version des HBW-LC-BL-8 (HBW-LC-BL-4, wenn man die Erweiterungsplatine weg lässt). Wahrscheinlich erstelle ich noch eine kleinere Erweiterung, die dann 3, statt 4 weitere Kanäle, aber in einem 4TE Gehäuse bringt (statt 6TE).
Also 4 + 4, oder 4 + 3 Kanäle/Rollos.

Wie man sieht haben die Platinen größenteils SMD Bauteile. Damit es nicht ganz so fummelig wird, ist nichts kleiner als Bauform 0805 (Länge 2 mm und eine Breite 1,25 mm)
(ok... die LEDs sind 0603, hatte noch 200 Stück - es passen aber auch 0805 drauf)


Gruß,
Thomas

[loetmeister]

Hallo,

eine Frage an die, die schon länger in diesem Thread dabei sind... Thorsten? 

Über die Liste im Wiki der Wired Geräte (https://wiki.fhem.de/wiki/HomeMatic_Wired#Aktoren_.2F_Sensoren) bin ich auf der GitHub Seite von Harald Glaser über die folgende change history gestolpert.

https://github.com/hresalg/HMW
Sep. 2016 Harald Glaser (hglaser-at-linuxen.at)
      -einige kleine Änderungen
      -Discovery hinzugefügt
      -Fallback Adresse und Modul Type dem Modul zugeordnet
      -frameControlByte in die untere HMWRS485 Schicht verlagert
      -Modul On/Off u.a. für Discovery
      -short_key_events senden/empfangen
      -long_key_events senden/empfangen TODO Broadcast empfangen
Okt. 2016
   - Timing verbessert
   - Sende- und Empfangsfolgenummer implementiert

Nach dem Datum und der Code Struktur handelt es sich wohl um Ergänzungen und Änderungen an der alten Lib?
Ein paar Dinge klingen ganz nützlich, z.B. "Modul On/Off u.a. für Discovery" oder auch "Sende- und Empfangsfolgenummer".
Hatte aktuelle und die Lib von Harald Glaser mal verglichen... die Unterschiede sind mittlerweile recht groß, zumindest Geräte für "Discovery" auf dem Bus müsste aber recht einfach eingebaut werden können...


PS: Der Link im Wiki für "HBW-CC-Vd2-T" auf GitHub führt in leere (Steuerung 24V-Ventile). Das finale Gerät scheint  -> https://github.com/hresalg/HBW_CC_VD2_FM zu sein, auch wenn es eine andere ID hat (ID 0x97).

Gruß,
Thomas

[derHeimwerker]

Hi Thomas,

mit der Platine machst du deinem Nickname aber allen Ehren ! Mich interessiert vor allem eine 230V Dimmer Platine. Da habe ich bisher im Netz so überhaupt nichts finden können. Eine Relaisplatine für diverse Hifi Komponenten würde ich dir aber auch abnehmen

Weiterhin viel Spaß !
Gruß
Thomas

[loetmeister]

Hi,

ein 230V Dimmer ist noch eine Sache bei der ich unschlüssig bin wie man das am besten Umsetzten kann. Einen Vernünftigen Phasenanschnitt/-abschnitt Dimmer zu bauen, der einem nicht die Unterverteilung abfackelt ist nicht mal eben gemacht... falls jemand Schaltpläne oder Vorschläge hat, immer her damit.

Optionen, die ich aktuell sehe:
1. Homematic HMW-LC-Dim1L-DR
    + Original Homematic Komponente
    - Preis, ca. 80,-
    - Nur Phasenanschnitt (230V LED Lampen brauchen teilw. Phasenabschnitt)
    - 2TE für nur einen Kanal


2. Eigenbau 6 Kanal Modul + 0-10V Dimmer
-> Die 6 PWM Kanäle des Ardunio (z.B. atmega328p) in 0-10V wandeln, dort können dann Dimmer, Trafos, etc. mit 0-10V "Schnittstelle" angeschossen werden.
    z.B.: Finder Typ 15.11 - Slave Dimmer (ca. 45,-)
    • Ansteuerung über 0...10 V / 1...10 V
    • Phasenanschnitt- und Phasenabschnitt-Dimmverfahren
    • Kurzschluß-, Übertemperatur-Schutz und Thermosicherung
    https://www.findernet.com/sites/default/files/2017-01/adv15de.pdf
    + Das Homebrew Modul wäre universell für Geräte mit 1-10V Eingang einsetzbar

Alternativ zum Finder Slave Dimmer: Eltako LUD12-230V https://www.eltako.com/fileadmin/downloads/de/datenblatt/Datenblatt_LUD12-230V.pdf
Statt 0-10V, PWM-Ansteuerung:
Frequenz: 100 Hz
Dutycycle: 0 (= Aus) linear bis 90 % (= volle Ausgangsspannung)
    + Vorteil, keine Wandlung PWM -> Analogspannung
    - Nachteil, weniger universell?


3. Kompletter Eigenbau...
Phasenanschnitt, (Komparator aus PWM-> Analogsignal speisen? https://www.mikrocontroller.net/attachment/8285/dimmer.jpg)
-> Galvanische Trennung unbedingt nötig! Überlast/Übertemperatur, Absicherung, etc. zu Beachten!!!


Mein Favorit ist aktuell Option 2 mit 0-10V

Gruß,
Thomas

[hresalg]

Hallo Thomas

PS: Der Link im Wiki für "HBW-CC-Vd2-T" auf GitHub führt in leere (Steuerung 24V-Ventile). Das finale Gerät scheint  -> https://github.com/hresalg/HBW_CC_VD2_FM zu sein, auch wenn es eine andere ID hat (ID 0x97).

tut mir leid, ich hab den HBW-CC-Vd2-T gelöscht, weil ich das Modul komplett umgeschrieben habe und jetzt nicht mehr auf Arduino Basis ist, sondern nur mehr normales gcc-avr. Auch einen Bootloader habe ich bereits. nur ist er noch immer ziemlich groß. (~2400 byte). Ich stelle es wieder online wenn ich fertig bin. also bitte nicht aus dem wiki löschen.

H.

[loetmeister]

Hi Harald,

alles klar. Dann bin ich mal auf die neue Version gespannt. 


Ich hab mir derweil weiter mit meinen Testgeräten. Rollo und Schaltaktor komplett mit Relais bestückt...
Beim testen des HBW-LC-Sw-12 ist mir aufgefallen, dass bei einer Änderung der Kanalkonfiguration (logging, inverted, o.ä.) alle Kanäle zurückgesetzt werden.
Das ist natürlich Käse...
Daher habe ich die lib für HBWSwitch und HBWSwitchAdvanced angepasst, so das afterReadConfig() nur beim ersten Einschalten die Kanäle auf AUS setzt.
HBW-LC-Sw-8 und HBW-LC-Sw-8_AdvancedPeering sind somit mit einer neuen Version im github.
https://github.com/loetmeister/HBWired/tree/master/libraries

Gruß,
Thomas

[loetmeister]

Hallo,

wie erwänt habe ich HBWSwitch und HBWSwitchAdvanced angepasst, so das afterReadConfig() nur beim ersten Einschalten die Kanäle auf AUS setzt (+ invert Option).
Dazu würde ich die Tage einen Pull Request stellen. Hier der diff:
https://github.com/ThorstenPferdekaemper/HBWired/compare/master...loetmeister:master#diff-c3decd83a85f5d65f1781e8f756c0157
Sieht nach viel aus, das meiste sind aber kleine Korrekturen, nur an HBW-LC-Sw-12 habe ich noch ein paar mehr Dinge verändert.


Die zweite Sache mit der ich mich beschäftige, ist Modul On/Off bzw. dann auch "Discovery" Funktion, die Harald Glaser bereits eingebaut hat... würde versuchen viel davon zu Übernehmen. 
Bevor das kommt, sollte aber erst mal 'Z' und 'z' - "zero communication" Modus funktionieren.

Dazu habe ich den Code in HBWDevice::processEvent() wieder aktiviert. Wenn der "zero communication" Modus aktiv ist, dann wird nur noch auf 'Z' und 'u' reagiert.
Denke das ist soweit ok... die Discovery Funktion würde ja noch eine Ebene tiefer arbeiten.
Um auf HBWDevice Ebene keine Sendeaktivität zuzulassen, habe ich
     if (pendingActions.zeroCommunicationActive) return 1;    // don't send in zeroCommunication mode, return with "bus busy" instead
in die folgenden Funktionen eingefügt:

• HBWDevice::broadcastAnnounce
• HBWDevice::sendInfoMessage
• HBWDevice::sendKeyEvent [alle 3]

Das ist 5 mal die selbe "if" Abfrage. Nicht besonders elegant... mir ist aber keine zentrale Stelle eingefallen in die das besser passen würde. 

Hier die Änderungen an processEvent() und broadcastAnnounce() als Beispiel:

Code Auswählen Erweitern

@@ -379,19 +383,26 @@ void HBWDevice::processEvent(byte const * const frameData, byte frameDataLength,
       // Wenn irgendwas von Broadcast kommt, dann gibt es darauf keine
       // Reaktion, ausser z und Z (und es kommt von der Zentrale)
       // TODO: Muessen wir pruefen, ob's wirklich von der Zentrale kommt?
+      if(isBroadcast) {
+         switch(frameData[0]) {
+            case 'Z':                                            // End discovery mode
+            pendingActions.zeroCommunicationActive = false;
+            break;
+          case 'z':                                              // start discovery mode
+            pendingActions.zeroCommunicationActive = true;
+            break;
+        }
+        return;
       };
+
+         if (pendingActions.zeroCommunicationActive) {                         // block any messages in this state, except:
+         /* case 'u':                                                              // Update (Bootloader starten)
+            // Bootloader neu starten
+            // Goto $7c00                                                          ' Adresse des Bootloaders
+               // TODO: Bootloader?
+               break; */
+                 return;
+         };

       txTargetAddress = senderAddress;
       // gibt es was zu verarbeiten -> Ja, die Kommunikationsschicht laesst nur Messages durch,

@@ -564,13 +576,14 @@ void HBWDevice::receiveKeyEvent(uint32_t senderAddress, uint8_t srcChan,

    // "Announce-Message" ueber broadcast senden
    byte HBWDevice::broadcastAnnounce(byte channel) {
+      if (pendingActions.zeroCommunicationActive) return 1;    // don't send in zeroCommunication mode, return with "bus busy" instead
       txTargetAddress = 0xFFFFFFFF;  // broadcast
       txFrameControlByte = 0xF8;     // control byte
......... usw.


Gruß,
Thomas

[loetmeister]

[...] Auch einen Bootloader habe ich bereits. nur ist er noch immer ziemlich groß. (~2400 byte). Ich stelle es wieder online wenn ich fertig bin.

Hallo,

Wenn du mit dem Bootloader noch nicht fertig bist, könnte man nicht den folgenden bootloader nehmen und anpassen? Er soll CCU Kompatibel sein
https://github.com/haus-bus/HBW-Devices/tree/HM-Wired/Firmware/HBW-Booter


Gruß,
Thomas

[loetmeister]

Hallo,

beim testen des "Discovery" ist mir aufgefallen das es nicht richtig funktioniert (mag an meinem USB - RS485 Adapter liegen, o.a.) und FHEM alle gescannten Geräte "gefunden" hat [Nachtrag. Eigene Doofheit: beim testen hat mein test Deive alle Discovery Nachrichten positiv beantwortet. Also war für jede angefragte Adresse fälschlicherweise ein Gerät vorhanden]. Auch ist mit "auto create", die Discovery Funktion nicht besonders wichtig (außer die kann noch mehr, was mir aktuell nicht bekannt ist)
Soll heißen, "nice to have" und werde ich erst mal nicht weiter verfolgen...

Ich habe nun einen Pull request gestellt. Im Kern ist folgendes geändert:

• Änderung um beim neu einlesen des EEPROM - mit afterReadConfig() - nicht alle Ausgänge zurückzusetzen. (Passierte z.B. wenn man logging oder invert Option für einen Kanal geändert hat, gab es einen kompletten Reset.

libraries/HBWSwitch/HBWSwitch.cpp (https://github.com/ThorstenPferdekaemper/HBWired/compare/master...loetmeister:master#diff-c3decd83a85f5d65f1781e8f756c0157)
libraries/HBWSwitchAdvanced/HBWSwitchAdvanced.cpp

• zeroCommunication hinzugefügt
• Bootloader starten ist als Platzhalter eingefügt. Die Startadressen des Bootloader (je nach Mikrocontroller) würde ich eine extra "hardware.h" auslagern

libraries/HBWired/HBWired.cpp (https://github.com/ThorstenPferdekaemper/HBWired/compare/master...loetmeister:master#diff-804b89404ca1977353cbc9be6b56c357)

Gruß,
Thomas

[Thorsten Pferdekaemper]

beim testen des "Discovery" ist mir aufgefallen das es nicht richtig funktioniert (mag an meinem USB - RS485 Adapter liegen, o.a.) und FHEM alle gescannten Geräte "gefunden" hat.

Also bei mir (mit dem einfachen Digitus USB-Adapter) hat das Discovery bisher bestens funktioniert, zumindest mit den Original-eq3-Geräten.
Was meinst Du damit eigentlich, dann es nicht funktioniert, da es alle Geräte gefunden hat. Das ist doch genau, was man vom Discovery erwartet.

Auch ist mit "auto create", die Discovery Funktion nicht besonders wichtig

Hä? Ohne Autocreate ist Discovery nicht so besonders interessant. Erst durch das Autocreate werden die gefundenen Geräte auch tatsächlich in FHEM angelegt (soweit ich mich erinnere).

Ich habe nun einen Pull request gestellt.

Ist ge-merge-t. (Oder wie man das auch immer auf Denglisch schreibt.)
Gruß,
   Thorsten