FHEM Forum

Hallo,

bereits vor Jahren habe ich mir ein kleines Home Automatisierungssystem gebaut. Basis sind zwei 8 Kanal Dimmer die per RS485 verbunden sind. Eine PC Anbindung gibt es derzeit nicht. Das System ist autark. Jeder Dimmer hat auch noch 8 Schaltereingänge. Es gibt auch noch ein paar kleine reine Schaltermodule die mit am Bus hängen.
Nun möchte ich das Ganze mit FHEM verbinden und stelle dabei fest, daß mein System Schwächen hat, die aus dem komplexen Regelwerk in den Dimmern herrühren. Von aussen kann eine Zentrale kaum den aktuellen Status der Aktoren ermitteln. Im einfachsten Fall baue ich ein, daß jeder Aktor und jeder Schalter bei Statusänderung und periodisch seinen Status meldet.
Aber ich denke hier ist weniger mehr. Also den Dimmer "verdummen" und die Abläufe dem FHEM überlassen. Dafür ist es ja da.

Was braucht man also um ein System zu erhalten, das eine sichere Statusanzeige in FHEM erreicht und auch bei Ausfall der Zentrale halbwegs nutzbar bleibt? Im folgenden meine Ideen:

- Schalter senden bei Zustandsänderung ihren Status, auch wenn der gepaarte Aktor auf dem selben Controller liegt
- Aktoren werden an ein oder mehrere Schalter gepaart, der Dimmer reagiert dabei auf obige Statusänderung
- Aktoren und Schalter melden minütlich ihren aktuellen Status als Keepalive
- Es kann mehrere Aktoren und Schalter pro Controller geben
- Adressierung erfolgt über Controlleradresse und Kanalnummer

Diskussionswürding ist:

- wie werden Gruppen dargestellt? Definiert man pro Aktor ein oder mehrere Gruppenzugehörigkeiten und stellt diese quasi als Pseudo-Aktor dar. So mache ich das derzeit: Kanalnummer < 128 ist ein echter Kanal, >128 ist eine Gruppe. Um Controllerübergeifende Gruppen zu definieren sende ich Broadcasts an alle Controller.
- Ist es vielleicht sinnvoll grundsätzlich nur Broadcasts zu machen und einfach jedem Kanal eine Adresse zu geben?
- Kann man Lichtszenen (also verschiedene Dimmerstati mehrerer auch deviceübergreifender irgendwie auch ohne Zentrale nutzbar machen? Im Moment definiere ich die Szenen in jedem Controller, wodurch die Zentrale diese gar nicht kennt. Idee?

Gibt es ein offenes Protokoll was man benutzen könnte um nicht alles neu zu erfinden. Im Prinzip könnte man ja das FS20 Protokoll aufs Kabel legen und um die Statusrückmeldungen erweitern. Oder vielleicht noch besser KNX/EIB auf RS485. Ist das offen? Zumindest scheint es recht komplex zu sein? Lohnt der Aufwand?

Bis denn
Thorsten

Hi Thorsten,

da deine Hardware schon auf  RS485 bassiert, schau dir mal das Homematic-Wired Protokoll an. Vergleicht ist das was für dich. Das Bassiert auf dem HS485 Protokoll von ELV. Die Protokoll Erweiterungen habe ich soweit es ging dokumentiert.
Link (http://forum.fhem.de/index.php?topic=10027.msg56562#msg56562)

 Ich bin im Moment auch dabei entsprechende Module für FHEM zu entwickeln. RAW senden und empfangen funktioniert bereits. Das könnte ich dir mal zukommen lassen. Somit könntest du da schon mal experimentieren.
Einen Anfang für einen Protokollstack für AVR habe ich hier auch schon liegen.

Gruß
Dirk

Hallo Dirk,

danke für die ausführliche Doku. Zum CMSA/CD auf RS485 habe ich bei meinem System schon Erfahrungen gemacht: es funktioniert nicht. Jedenfalls dann nicht wenn einige Meter Kabel zwischen den kollidierenden Modulen liegen. Ich habe es wie folgt versucht:

Jedes Byte das ich sende empfange ich auch gleich wieder da ich den Empfänger Transceiver aktiviert lasse. Unterscheidet sich gesendetes und empfangenes Byte liegt wohl eine Kollision vor. Dies passiert aber praktisch nie.

Nun aber zu Deiner Protokollbeschreibung. Im Prinzip könnte ich das sicherlich nehmen. Was mir aber fehlt ist die Möglichkeit Szenen zu definieren. Ich habe z.B. in meinem Heimkino drei Lichtkreise plus einen Sternenhimmel der auch nochmal acht Kanäle belegt (damit die Sterne nicht alle gleich hell sind). Wenn ich nun auf den Lichtschalter drücke soll dieser alle Lampen und den Sternenhimmel einschalten, Lampen auf volle Helligkeit, Sternenhimmel auf unterschiedliche Werte. Drücke ich nochmal soll alles ausgehen. Über eine Fernbedienung kann ich zusätzlich drei verschiedene Szenen schalten: Nur Sternenhimmel an, Sternenhimmel und Tischbeleuchtung auf 50%, Sternenhimmel Tisch und Lichtschlauch in der Decke.

Das würde vermutlich ohne Zentrale mit dem Protokoll nicht funktionieren. Wobei ich zugeben muß, daß ich die Direktverknüpfungen noch nicht verstanden habe. Nun muß ich mir klar werden ob das für mich ein Thema ist. Im Normalfall ist die Zentrale ja da. Wenn sie mal nicht da ist reicht es ja vielleicht auch wenn man nur das Gesamtlicht schalten kann.

Mal drüber nachdenken.

Du schreibst da etwas von einem Homebrew Modul. Gibts das schon (softwareseitig). Könnte ich dann vielleicht mal mit rumprobieren. Einfach auf dem STK aufbauen oder auf dem NetIO Board. Insbesondere diese Timingerkennungen sind ja immer recht mühsam umzusetzen.

Achja, eine Kleinigkeit fehlt noch in der Beschreibung. Beim Maskieren ("Escapen" brrr) von 0xFD im Datenstrom durch 0xFC 0x7D wird glaube ich nicht beschrieben wie dann das 0xFC zu maskieren ist, vermutlich durch 0xFC 0x7C.

Bis denn
Thorsten

Hi Thorsten,

Zu CMSA/CD hab ich noch nix gemacht, in der Ursprünglichen Protokollbeschreibung finde auch dazu auch nix. Daher wird es hier wohl auf den Versuch ankommen wenn es soweit ist. Bis dahin ignoriere ich das erstmal.
Jedenfalls schalten die Homematic-Module  RX und TX um, da der /RE-Pin vom Transceiver fest auf Masse liegt. Somit kann der Empfänger vom Sender Bauartbedingt nicht "mitlauschen"
Daher wir das hier irgendwie anders bewerkstelligt oder komplett ignoriert.

Zitat> Nun aber zu Deiner Protokollbeschreibung

Naja, ist ja nicht von mir. Ich habe "nur" die Erweiterung zu Homematic-Wired dokumentiert :) Das Original ist übgigens hier: http://www.elv-downloads.de/downloads/programme/HS485/HS485_Protokoll.pdf (//www.elv-downloads.de/downloads/programme/HS485/HS485_Protokoll.pdf)

Zitat> Was mir aber fehlt ist die Möglichkeit Szenen zu definieren.

Szenen würden über Conditions im Modul Definiert.
Das würde dann z.B. auch über eine Direktverknüpfung bzw. über bestimmte Register funktionieren.
Das EEprom der Module kann Prinzipiell von außen über den Bus programmiert/konfiguriert werden.
Darüber kann dann auch das Verhalten eingestellt werden.

Z.B. Modul empfängt:
- 1. Tastendruck -> Ein halbe Helligkeit,
- 2. Tastendruck -> volle Helligkeit,
- 3. Tastendruck -> aus

Die entsprechende Programmierung wird dann in der Firmware des Modul vorbereitet und durch bestimmte Register aktiviert bzw. Parametrisiert.

PC-Seitig haben die Module umfangreiche XML Beschreibungen die die Register dokumentieren welche zur Parametrisierung benutzt werden. Diese XML-Dateien werden dann von der Konfigurationssoftware ausgewertet. Damit können die Register dann recht einfach gesetzt werden.

So ähnlich habe ich das für FHEM auch vor. FHEM muss dann also die Register jedes Modules kennen. Dazu gibt es dann für jedes Modul eine entsprechende Konfigurationsdatei.

Bei Direktverknüpfungen, auch Pairing, wird in einem Empfänger die zugeordnete Senderadresse gespeichert.
Damit weiß der Aktor auf welche Senderbefehle er reagieren muss. Dazu braucht es dann keine Zentrale. Ebenso wird dabei festgelegt welche Aktion der Aktor dann Auszuführen hat.
Um auf deine Szene wieder zu sprechen zu kommen: Man kann einen Schalter (Sender) natürlich auch zu mehreren Aktoren (Empfänger) verknüpfen. Mit Bedingungen wie oben skiziert könnte man dann auch Szenen ohne FHEM schalten.

Mit Hombrew Modulen meine ich einfach eigene Module die es (noch) nicht zu kaufen gibt. Ich vermisse z.B. noch einen RGB-LED Dimmer. Auch Sensoren wie ein Temperatursensor usw. Fehlen noch. Also im Prinzip Module die du bereits gebaut hast, eben Softwareseitig mit dem HM485 Protokoll.
Ich habe damit schon ein bisschen auf Basis eines Atmega 16 bzw. 32 experimentiert.
Zumindest das Empfangen und Senden der Frames ist da schon implementiert. Das kann ich dir sicher mal zukommen lassen. Ist aber in Bascom geschrieben. Sollte sich aber einfach nach C portieren lassen.

ZitatAchja, eine Kleinigkeit fehlt noch in der Beschreibung. Beim Maskieren ("Escapen" brrr) von 0xFD im Datenstrom durch 0xFC 0x7D wird glaube ich nicht beschrieben wie dann das 0xFC zu maskieren ist, vermutlich durch 0xFC 0x7C.

0xFC muss natürlich nicht maskiert werden wenn es als Escape-Zeichen benutz wird. Wenn 0xFC in den Daten vorkommt, wird es ganz "normal" maskiert.

Zitatvermutlich durch 0xFC 0x7C.

Korrekt.

Gruß
Dirk