Homematic Wired - Homebrew Devices

[Thorsten Pferdekaemper]

Bei Firmata oder HTTPMOD müsste ich mich erst noch einlesen und einarbeiten.

Ich glaube, dass das weit weniger Aufwand wäre, als das HM485 irgendwie auf Ethernet zu bringen.

[Hoschiq]

Hallo,

hier http://forum.fhem.de/index.php/topic,14096.msg88557.html#msg88557

hat Dirk  einen Rs485 auf Ethernet Modul gebaut. Den lokalen homematic wired deamon kann man meiner Meinung nach auch die Ethernet Schnittstelle als Gerät zuweisen.
Dann braucht jedes Gerät so einen Adapter um von Rs485 auf LAN umzuwandeln.

[mago0211]

Hallo Thorsten,

heute ist mein max487 gekommen.
Ist der Schaltplan unten so korrekt? Bevor ich wieder was falsch mache   

Danke und Gruß
Markus

[Hoschiq]

Hallo Markus,

schaue dir hier einmal den Schaltplan vom Universalsensor an https://github.com/kc-GitHub/HM485-Lib/raw/thorsten/Schematic/Schematic-WIRED.pdf.
Den Spannungsteiler beim RO dort brauchst du nicht, da du mit 5V arbeitest.

Bei deinem Schaltplan ist der Anschluss von Lesen und Schreiben aktivieren (DE und RE) nicht korrekt. Es ist bei dir immer beides aktiv oder beides deaktiv.

Schalte RE gegen Ground dann empfängst du immer.
Senden (DE) sollte aktiv an und ausschaltbar sein also an einen Pin vom Arduino. Außerdem solltest du den DE zusätzlich mit einem 10K Widerstand gegen Ground schalten um einen sauberen Zustand zu haben.

Der Rest sollte passen.

VG
Hoschiq

[mago0211]

Hallo Hoschiq,

Danke für deine Erklärung.
Zu den A und B Ausgängen habe ich noch eine Frage  .

Ich habe jetzt verschieden Schaltpläne im Internet gefunden.
Bei der Zeichnung des Universalsensor werden zu den Augängen jeweils ein Kondensator nach GRD geschalten.
Habe aber auch schon gesehen das man einen 100k Wiederstand nach GRD schalten kann.
Oder brauch man keines von beiden?

Danke und Gruß
Markus

[Thorsten Pferdekaemper]

Bei deinem Schaltplan ist der Anschluss von Lesen und Schreiben aktivieren (DE und RE) nicht korrekt. Es ist bei dir immer beides aktiv oder beides deaktiv.

Nein, das stimmt schon so. Einer der beiden Pins auf dem MAX487 ist invertiert. Ich schließe das auch immer so an. Es geht auch so wie auf Dirks Plan, aber dann empfängt das Gerät immer auch seine eigenen Nachrichten, was manchmal lästig ist.

[Thorsten Pferdekaemper]

Bei der Zeichnung des Universalsensor werden zu den Augängen jeweils ein Kondensator nach GRD geschalten.
Habe aber auch schon gesehen das man einen 100k Wiederstand nach GRD schalten kann.
Oder brauch man keines von beiden?

Ich glaube nicht, dass man das braucht. Es kann aber wahrscheinlich auch nicht schaden.

[jwagner]

Hi,

ich hatte mich die Tage wieder etwas mit dem H(B)W 485 Protokoll beschäftigt, und 2 neue Dinge herausgefunden:


Befehls-Typ 'Q' (0x51) - Manuelles Anlernen direkter Peerings

Es gibt einen in Dirk's Protokoll-Doku nicht vorhandenen Befehls-Typ 'Q' (0x51). Dieser wird von einem Taster-Sensor an den Aktor gesendet, quasi als Abschluss für den 'q' (0x71) Anlern-Befehl vom Aktor an den Sensor.

Hintergrund ist m.E. folgendes:

• Ein Aktor wird in den Programmier-Modus versetzt (durch gedrückt-halten des Programmierknopfes am Gerät)
• Ein Tast-Sensor sendet ein Key-Event an Broadcast
• Der Aktor sendet das Anlern-Kommando 'q' (0x71) an den Tast-Sensor
• Der Tast-Sensor speichert die Verknüpfung Sensor-Channel => Aktor Adresse / Aktor Channel
• Der Tast-Sensor sendet das Anlern-Kommando 'Q' (0x51) an den Aktor
• Der Aktor speichert die Verknüpfung Aktor-Channel => Sensor Adresse / Sensor Channel

Dieser zusätzliche Schritt (im Vergleich zu dem ursprünglichen HS 485 Protokoll) macht Sinn, denn es könnte sein, dass der Tast-Senor im Schritt 4 z.B. keinen freien Speicher-Slot mehr hat, und deswegen die Verknüpfung nicht speichern kann. Der Aktor 'weiss' ja bereits vorher, ob er selbst noch einen Speicher-Slot frei hat, d.h. Schritt 6 sollte immer erfolgreich sein.


Das LAN Gateway sendet selbst ACKs

Das HomeMatic LAN Gateway erzeugt selbst ACK Nachrichten, und verwendet dabei Addressen anderer Devices!

Beispiel:

Zentrale (oder ein anderes Device) sendet ein SetActor oder SetLevel Frame an einen Aktor.
Der Aktor quittiert das Kommando mit einem Info-Frame statt einem ACK.

Das LAN Gateway erzeugt nun selbständig eine ACK Nachricht an den Aktor, und verwendet dafür die from- und to-Adressen aus dem Info-Frame in umgekehrter Reihenfolge.

Hoffe das hilft jemandem!

Viele Grüsse,
- jens

[mago0211]

Hallo zusammen,

nun habe ich es endlich geschafft meinen Homebrew zum laufen zu bekommen. Was nicht sofort funktionierte war die Erkennung in FHEM. Ich musste das Device manuell anlegen. Automatisch hat er es nicht erkannt, ich war mir auch nicht sicher ob dies überhaupt von Dirks letzter HM485 Version unterstützt wird für die Homebrew Geräte.

Ich habe das ganze mal in ein Hutschienengehäuse gepackt sieht eigentlich ganz nett aus (Bilder unten). Jetzt werde ich die nächsten Tage noch ausführlicher Testen und wenn ich Zeit habe einen Schaltplan erstellen und im Wiki dazu was schreiben.


Nochmals Danke für eure Hilfe! 

Grüße
Markus

[Thorsten Pferdekaemper]

Was nicht sofort funktionierte war die Erkennung in FHEM. Ich musste das Device manuell anlegen. Automatisch hat er es nicht erkannt, ich war mir auch nicht sicher ob dies überhaupt von Dirks letzter HM485 Version unterstützt wird für die Homebrew Geräte.

Eigentlich sollte das schon gehen. Hast Du im Sketch am Ende von setup sowas ähnliches wie das hier?

Code Auswählen Erweitern


hmwmodule->broadcastAnnounce(0);

Dann sollte FHEM das Teil bei einem Reset eigentlich erkennen.

Ich habe das ganze mal in ein Hutschienengehäuse gepackt sieht eigentlich ganz nett aus (Bilder unten).

Sieht wirklich nett aus.

[Hoschiq]

Hallo Jens,

danke für die zusätzliche Protokollinformation. Das hilft dabei das direkte Peering in der Homebrew Firmware abzubilden.

Ein paar Fragen habe ich noch zu deinen Erkenntnissen:

-mit welchen Geräten hast du das mit den Q Nachrichten ermittelt?
-wurde dabei der Sensor mit einem Aktor Kanal eines anderen Gerätes gepeert oder mit einem eigenen Aktor Kanal  (z.B. Rolladenaktor mit Ein- und Ausgängen)
-falls nein, könnstest du diesen Fall (Peering eines eigenen Aktor Kanals) einmal nachstellen?

-Kannst du das auch nochmal mit dem Löschen eines Peerings (am Aktor den Löschmodus aktivieren und dann Sensor betätigen) durchspielen und die dabei stattfindende Kommunikation mitteilen? Hier gibt es ja ein ähnliches Problem, wenn der Sensor den Löschbefehl nicht durchführte aber der Aktor das Peering löschen möchte.

Das Problem mit dem automatischen Erkennen in FHEM von Homebrew Geräten habe ich auch ab und zu.

VG
Hoschiq

[jwagner]

-mit welchen Geräten hast du das mit den Q Nachrichten ermittelt?

Mit einem HMW-LC-Sw2-DR (HomeMatic Wired RS485-Schaltaktor). Kann das Teil erfolgreich mit meinem PC oder einem Arduino peeren, ohne Zentrale.

-wurde dabei der Sensor mit einem Aktor Kanal eines anderen Gerätes gepeert oder mit einem eigenen Aktor Kanal  (z.B. Rolladenaktor mit Ein- und Ausgängen)

Sowohl als auch. Allerdings gehen bei einer 'internen Direktverknüpfung' keine q oder Q Meldungen nach aussen, man sieht nur den Key-Broadcast.

-falls nein, könnstest du diesen Fall (Peering eines eigenen Aktor Kanals) einmal nachstellen?

S.o., ausser dem K-Broadcast geht nichts nach aussen (wäre auch sinnlos).

-Kannst du das auch nochmal mit dem Löschen eines Peerings (am Aktor den Löschmodus aktivieren und dann Sensor betätigen) durchspielen und die dabei stattfindende Kommunikation mitteilen? Hier gibt es ja ein ähnliches Problem, wenn der Sensor den Löschbefehl nicht durchführte aber der Aktor das Peering löschen möchte.

Das Problem kann hier logischerweise nicht auftreten, Verknüpfungen können immer gelöscht werden. Der c-Request funktioniert noch wie im HS486 Protokoll beschrieben.

[Thorsten Pferdekaemper]

Das LAN Gateway sendet selbst ACKs

Das klingt für mich nach einen Bug im Gateway, außer für ganz spezielle Szenarien.

Zentrale (oder ein anderes Device) sendet ein SetActor oder SetLevel Frame an einen Aktor.
Der Aktor quittiert das Kommando mit einem Info-Frame statt einem ACK.
Das LAN Gateway erzeugt nun selbständig eine ACK Nachricht an den Aktor, und verwendet dafür die from- und to-Adressen aus dem Info-Frame in umgekehrter Reihenfolge.

Dass da zum Schluss noch mal ein ACK kommen muss ist klar. Der Info-Frame ist nicht nur ein ACK, also würde er wiederholt werden, wenn kein ACK kommt. Allerdings würde ich sagen, dass dieses ACK nur dann vom Gateway kommen darf, wenn das Info-Frame an die Zentrale geschickt wird. Ansonsten müsste ja das Device, an das die Info-Message gerichtet ist, das ACK senden.
Andererseits kann es sein, dass dieses spezielle Info-Frame immer an die Zentrale geschickt wird. Es sendet ansonsten ja kein Device einen Set-Befehl.
Naja, es klingt aber trotzdem irgendwie seltsam.

[mago0211]

Eigentlich sollte das schon gehen. Hast Du im Sketch am Ende von setup sowas ähnliches wie das hier?

Code Auswählen Erweitern


hmwmodule->broadcastAnnounce(0);


Ja der Eintrag ist vorhanden und müsste soweit ich cpp verstehe funktionieren. Leider komme ich eher aus der Python Welt deshalb tu ich mich etwas schwer den Code zu interpretieren aber probieren geht über studieren 

Ich muss mir nur endlich für Eclipse das Arduino Plugin installieren. Die Arduino IDE ist ja ne Zumutung.

Gruß
Markus

[Thorsten Pferdekaemper]

Ja der Eintrag ist vorhanden und müsste soweit ich cpp verstehe funktionieren.

Welche FHEM-HM485-Version hast Du? Im Zweifelsfall hol Dir mal die neuste von https://github.com/kc-GitHub/FHEM-HM485.