Homematic Wired - Homebrew Devices

[Thorsten Pferdekaemper]

Hi,
bei mir funktioniert jetzt Dirks Platine auch mit vier Sensoren. (Siehe Bilder.)
Gruß,
    Thorsten

[Dirk]

Ganz schön warm bei dir

[Thorsten Pferdekaemper]

Die gefühlte Temperatur liegt noch höher und außerdem ist's hier drinnen noch relativ kühl.

Ich habe jetzt unsere Versionen der Firmware zusammengebracht. Die aktuelle Version in meinem Git-Branch enthält jetzt meine neusten Entwicklungen und ist mit dem Sensor-Board kompatibel.
Es gibt außerdem eine Compiler-Direktive (#define DEBUG_UNO), mit der man das ganze auf die Version mit SoftwareSerial zurückschalten kann. Allerdings haben sich die Pins gegenüber meiner alten Version etwas geändert, auch wenn man mit "DEBUG_UNO" übersetzt.

Code Auswählen Erweitern


#ifdef DEBUG_UNO
  #define RS485_RXD 5
  #define RS485_TXD 6
  #define LED 13        // Signal-LED
#else
  #define LED 4         // Signal-LED
#endif
#define BUTTON 8            // Das Bedienelement
#define RS485_TXEN 2        // Transmit-Enable

#define ONEWIRE_PIN A3

Ich habe außerdem herausgefunden, dass man den USB-Adapter vom Hardware-UART abstöpseln muss, damit die Platine etwas empfängt. Ansonsten funktioniert nur senden. Keine Ahnung warum...
Gruß,
    Thorsten

[Thorsten Pferdekaemper]

Hi,
es regnet...
Im aktuellen git gibt es folgende Neuigkeiten:

• Die "E-Message" ist jetzt vollständig implementiert. Das gilt auch für zukünftige Devices, die die Library verwenden. Das ganze ist generisch in der Library implementiert.
• Gegenüber der Version von vorgestern geht das Senden etwas schneller, da ich zwei delay(1) durch flush() ersetzt habe.
• Es gibt jetzt auch bei Verwendung von Dirks Platine eine Debug-Ausgabe. Das ganze läuft seriell mit 19200 Baud über Pin 5 (Rx) und 6 (Tx).
• Das ganze Coding rund um die Debug-Ausgaben ist etwas aufgeräumter.
• Wenn man über die Einstellungen in der CCU einen Sensor rauswirft, dann wird der entsprechende Kanal relativ bald danach mit "-273,15" angezeigt.
• Neue Sensoren werden jetzt beim Reset (bzw. Einschalten), Factory Reset und beim kurzen Druck der Taste gesucht. (Vorher war's statt beim Tastendruck beim Senden einer neuen Einstellung von der Zentrale. Das hat aber Probleme gemacht und ist meiner Meinung nach auch nicht besonders sinnvoll.)

Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
es gibt jetzt auch einen ordentliche Wiki-Eintrag:
http://www.fhemwiki.de/wiki/HWB-1WIRE-TMP10
...es kann sich trotzdem noch so einiges ändern, aber wenn ich's nicht dokumentiere, dann verliere ich selbst so langsam den Überblick.
Gruß,
   Thorsten

[ph1959de]

Hallo Thorsten,

ich hätte als Bezeichnung HB-1W-TMP10 erwartet ... habe ich das Namensschema im Wiki falsch verstanden?

Peter

[Thorsten Pferdekaemper]

ich hätte als Bezeichnung HB-1W-TMP10 erwartet ...

Hi,
da hast Du recht, die Namensgebung ist nicht wirklich richtig. Danke für den Hinweis. Es ist allerdings kein "HB". Eigentlich müsste es sogar so heißen:
     HBW-1W-T10 oder sogar HBW-1W-T10-PCB
(siehe http://www.fhemwiki.de/wiki/HomeMatic_Namen_verstehen)

Ich werde das demnächst noch ändern, komme aber vor übernächster Woche wahrscheilich nicht dazu. Es ist leider mit einer Änderung im Wiki nicht getan.
Gruß,
   Thorsten

[MarkusO]

Hallo zusammen,
hier hat sich in letzter Zeit ja richtig was getan! Mir hat in den letzten Wochen leider etwas die Zeit gefehlt, um mich mit dem Thema zu beschäftigen...
Ich habe allerdings angefangen, mir über einen Bootloader Gedanken zu machen. Für den Fall, dass die Eigenbau-Geräte mal irgendwo im Haus fest eingebaut sein sollten und man doch noch das ein oder andere Update einspielen möchte, könnte ein Bootloader, der den HM485-Bus verwendet, ja nützlich sein.

Meine Idee habe ich hier beschrieben:
https://github.com/kc-GitHub/HM485-Lib/tree/markus/hmwProgrammer
Mich würde Eure Meinung interessieren, ob so ein Bootloader überhaupt Sinn macht und was ihr von dem Konzept haltet.

Beim Bootloader selbst besteht derzeit noch das Problem, dass die ID des Geräts fest im Code implementiert ist, d.h. der Source-Code des Bootloaders müsste für jedes Gerät angepasst werden, um eindeutige IDs zu erhalten. Was haltet Ihr von den folgenden Ideen, um eindeutige IDs zu generieren?
- nachträgliche Vergabe der ID manuell (z.B. mit Befehl über serielle Schnittstelle)
- an jeden Client einem 1-wire Sensor anschließen - die 1-wire Sensoren haben angeblich alle eine eindeutige ID, die vom Client übernommen werden könnte
- generierung einer zufälligen ID, indem das Rauschen eines AD-Kanals ausgenutzt wird
- Zeitabstand auswerten (z.B. vom Reboot bis zum ersten Tastendruck oder dem ersten Empfang einer Busnachricht)
- sonstige Möglichkeiten?

Viele Grüße
Markus

[reneFHEM]

Hallo zusammen,

ich war auch lange Zeit zu beschäftigt um an dem Thema zu arbeiten. Aber ich habe diese Woche auch etwas geschafft. Ich habe ein neues Device HBW-Sec-MDIR-2 (bei mir sollte die Bezeichnung stimmen )angelegt. Das Device soll ein Unterputz-Gerät zur Anschaltung eines MDIR von Jung, Berker oder Gira an den HM485 realisieren. Damit ist es dann möglich einen Bewegungsmelder und sogar auch einen Präsenzmelder zu integrieren. Die Schaltung und die Logik stammt von: http://www.mikrocontroller.net/articles/24V_UP-Einsatz_f%C3%BCr_Bewegungsmelder_von_Jung,_Berker_und_Gira. Die Firmware habe ich für Arduino bereits portiert. Die "richtige" Hardware muss noch angpasst werden. Tests stehen allerdings noch aus, da mir noch ein paar Bauteile fehlen, die ich diese Woche noch bestellen will.

Ich habe noch ein paar architekturelle Verbesserungen gefunden, die ich in einem nächsten Commit beisteuern werde, um doppelten Code zu beseitigen.

@Markus: Mit deinem Bootloaderkonzept könnte man zumindest Entwicklungsseitig ein FW-Update durchführen. Ich glaube ein FW-Update sollte auch von FHEM oder CCU funktionieren. Das ist mir noch nicht klar wie das mit deinem Konzept funktioniert. Die Vergabe der ID über einen Zeitbezug halte ich auch für sinnvoll. Hier sollte aber trotzdem sichergestellt werden, das es keine Dopplungen mit den Seriengeräten gibt. Vielleicht kennt ja jemand den Vergabealgorithmus oder man müsste als Fallback noch die manuelle Vergabe integrieren.

Gruß Rene 

[Dirk]

Hallo,

der Bootloader zum Updaten über den Bus sollte auf alle Fälle noch kommen.

Die Adresse, die Seriennummer und ggf. sogar den Devicetype würde ich hier gerne im Hexfile des Bootloaders an definierten Adressen mit unterbringen. Vorteil: Man kann die Firmware flashen ohne diese Infos zu überschreiben. Das ist bei den fertigen Devices übrigens auch so implementiert.

Beim Flashen des Bootloaders kann man diese Informationen mit übergeben. So ähnlich mache ich das auch bei der Firmware vom Univeralsensor auch schon. Dort zwar noch nicht im Bootloader, aber das Verfahren währ ähnlich. Die zufällige Vergabe der Daten kann dann auch das "Flash-Tool" übernehmen.
Und da der Bootloader hier sowieso geflasht werden muss, können diese Infos dann hier auch mit rein.

Ein Speichern der Informationen im EEprom ist nicht ganz ungefärlich. Denn die CCU bzw. die Zentrale hat normalerweise die volle Kontrolle über den kompletten EEprom-Speicher eines Gerätes. Ansonsten muss man hier einen bestimmten Speicherbereich speziell schützen.

Gruß
Dirk

[reneFHEM]

Hallo,

Die Adresse, die Seriennummer und ggf. sogar den Devicetype würde ich hier gerne im Hexfile des Bootloaders an definierten Adressen mit unterbringen.

Das halte ich auch für gut. Wobei die Seriennummer durchaus auch aus der aktuellen Systemzeit des Rechners generiert werden kann. Für mein neu angelegtes Device brauche ich auch noch einen Devicetype. Kann ich mir da einfach einen definieren oder muss ich irgendwelche Regeln befolgen?

So ähnlich mache ich das auch bei der Firmware vom Univeralsensor auch schon.

Ist die Firmware dafür auch auf Arduino portiert ?

Gruß Rene

[justme1968]

wäre hier nicht auch ein i2c mac chip für die serien nummer gut?

gruss
  andre

[Dirk]

wäre hier nicht auch ein i2c mac chip für die serien nummer gut?

Ich finde die Idee nicht so gut.
Siehe hier: http://forum.fhem.de/index.php/topic,20620.msg186635.html#msg186635

Gruß
Dirk

[Dirk]

Für mein neu angelegtes Device brauche ich auch noch einen Devicetype. Kann ich mir da einfach einen definieren oder muss ich irgendwelche Regeln befolgen?

Regeln sind mir nicht bekannt.
Die RF-Devices haben 2 Bytes als Devicetype. HM-Wired Geräte theoretisch auch, aber hier bin ich mir derzeit nicht so sicher. Hiuer scheint nur ein Byte benutzt zu werden. Das will ich aber noch mal untersuchen.

Für die RF-Devices haben wir hier die ID-Bereiche dokumentiert.
http://www.fhemwiki.de/wiki/Kategorie:HomeBrew

Du kannst ja erstmal eine höheren ID testen.

Gruß
Dirk

[Thorsten Pferdekaemper]

Ein Speichern der Informationen im EEprom ist nicht ganz ungefärlich. Denn die CCU bzw. die Zentrale hat normalerweise die volle Kontrolle über den kompletten EEprom-Speicher eines Gerätes. Ansonsten muss man hier einen bestimmten Speicherbereich speziell schützen.

Im Endeffekt hat die Firmware des Geräts die Kontrolle darüber. Ich könnte relativ einfach die paar Bytes irgendwo reservieren und in der Firmware verhindern, dass sie überschrieben werden. (Auch beim "Factory-Reset.) Für eine CCU würde dieser Bereich dann immer als "leer" (0xFF) erscheinen.
Dazu dann noch einen speziellen "Befehl" und man könnte die Adresse bzw. Seriennummer von außen setzen. Das würde dann sogar über den Bus gehen.
Gruß,
   Thorsten