RS485 in IP Tunneln

[owagner]

9600 Baud
8 Data Bits
E --> Parity Even ?
1 --> ! Stop Bis

Ja. (Korrekt: 19200 Baud, siehe später im Thread) Lesetipp: http://homematic-forum.de/forum/viewtop ... 31&t=24736

[owagner]

Wenn Du mir jetzt noch eine Alternative nennst, wie man das über's Wlan kriegt...

Wieso denn WLAN? Arduino nehmen, RS485-Adapter dran, irgendein 868Mhz-Funkmodul dran (RFM12B oder was auch immer da gerade in ist) und dann mit ein paar Zeilen Arduino-Code eine Wireless-HM-Wired-Bridge bauen

[Daimler]

Hi,

Arduino nehmen,

Ich glaube, wir müssen uns einmal näher unterhalten
Hört sich gut an - aber damit wir uns nicht missverstehen: Ich muss / müsste von einer zentralen UV zu einer / mehreren UV(s) und dazwischen gibt es keine Strippen - ausser nat. den höherspannigen!

Und was sich überhaupt nicht gut anhört:

.....und dann mit ein paar Zeilen Arduino-Code.....

[owagner]

Das klingt, glaub ich, schwieriger, als es ist.

Auf der RS485-Seite empfängt man solange Daten, bis man ein komplettes HM485-Paket hat. Man wartet auf ein Start-Byte (0xfd), empfängt dann erstmal 10 weitere Bytes, im zehnten Byte hat man dann die Länge der restlichen Payload und liest die auch. Es gibt noch eine einfache Escaping-Regel, die man beachten muss (bei 0xfc ist beim nächsten Byte das oberste Bit zu setzen).

Ich hatte das vor einiger Zeit einmal für die culfw implementiert: https://github.com/svn2github/culfw/blo ... ib/hm485.c

Mehr Interpretation des Protokolls braucht man ja gar nicht.

Hat man dann eine Nachricht zusammen, schickt man die mittels einer beliebigen Arduino-Funkbibliothek durch die Gegend. Da gibt es eine ganze Reihe, Beispiele:

https://github.com/LowPowerLab/RFM69

Die RFM69-Module gibts u.A. bei Pollin für ~5€

Solange man nicht per Funk sendet, empfängt man, wenn ein Datenpaket da ist (die obige Bibliothek liefert das ja mundgerecht), schickt man es per RS485 raus.

Das wars schon.

[Xel66]

Das klingt, glaub ich, schwieriger, als es ist.

Ich würde mal eher das Gegenteil behaupten, denn BidCos-RF ist nicht gleich BidCos-Wired. In der Anleitung zur XML-RPC-Schnittstelle auf Seite 10 sieht man, dass es zwischen beiden Protokollen eine große Schnittmenge, aber auch viele individuelle Parametersätze gibt. Auch dürften die die Ports, die die CCU anspricht, sich unterscheiden und man erreicht eben über die Funkschnittstelle keine Wired-Geräte, auch wenn dahinter ein Wandler hängt. Da muss man zusätzlich auch noch die Firmware umbiegen. Ich glaube eher nicht, dass sich das so 1:1 umsetzen lässt. Da ist der Schnittstellenkonverter, mit dem man den Bus über Ethernet "verlängern" kann, vermutlich die bessere und leider auch teurere Wahl.

Gruß Xel66

[owagner]

Ich würde mal eher das Gegenteil behaupten, denn BidCos-RF ist nicht gleich BidCos-Wired.

Ich glaube, das ist ein Mißverständnis; es war nicht die Rede von einem HM-Wired auf HM-RF-Umsetzer, sondern nur eine Möglichkeit, HM-Wired per Funk -- mit einem eigenen Protokoll -- zu brücken. Das könnte auf 868 Mhz passieren, oder auch auf 433 Mhz, die erwähnten RFM69-Module gibt es für beide Bänder.

Also eine Selbstbau-RS485-Verlängerung, mehr nicht.

[Xel66]

Also eine Selbstbau-RS485-Verlängerung, mehr nicht.

Ah, OK. Ich hatte nur 886MHz gelesen und das mit der HM-RF-Schnittstelle gleichgesetzt. Wäre dann nicht eine Umsetzung auf Ethernet mit einem Netzwerkshield und ggf. per WLAN einfacher zu handeln? Das Timingproblem bei ausgelastetem Netzwerk müsste man wohl auch noch puffern, weil die CCU sich sonst gleich über Kommunikationsprobleme beschweren wird. Die erwartet ja auch dem RS485 einen exklusiven Kommunikationskanal und sofortige Antworten.

Gruß Xel66

[owagner]

Das obige war ja nur ein Lowcost-Bastelvorschlag.

Klar könnte man die HM485-Pakete auch über Ethernet verschicken, das wird m.E. problemlos klappen.

Man könnte auch einfach zwei CUNO nehmen, den hm485-Modus der culfw aktivieren und mit einem kleinen Python-o.ä.-Script die Nachrichten gegeneinander austauschen.

WLAN ist immer so eine Sache. Je nach Nutzungsdichte des 2.4-Ghz-Bandes funktioniert es von sehr gut bis schwierig mit hoher Latenz...

Ob es mit fertigen RS485-IP-Umsetzern geht, weiss man halt bisher auch nicht -- theoretisch sollte es, praktisch habe ich z.B. keine Ahnung, wie die sich wirklich vom Timing/Buffering her verhalten und wie das mit dem Sende/Empfangsverhalten der EQ3-Implementierungen interagiert. Da hilft wohl wirklich nur ausprobieren...

Viele Grüße,
Olli

[aixtreme]

Hallo zusammen,

mittlerweile habe ich die Verkabelung aufgebaut:
1. vom HM 485 Bus auf einen Serial Port Device Server
2. Dann über Ethernet zum 2. Serial Port Device Server
3. Dann vom 2. Device Server wieder auf RS485 und an ein HM Wired angeschlossen.

Nach einiger Arbeit bei der Konfig (die Server sind nicht gerade Up-to-Date), sind die beiden connected (ein Server/ Ein Client)

Auf den RX/TX Anschlüssen kann ich auch Datenpakete sehen.

Aber: Anlernen der HM Komponente hat bislang nicht geklappt. Nach drücken des Buttons Geräte anlernen sehe ich 10 Datenpakete mehr, aber kein neues Gerät.

Jetzt weiß ich nicht mehr weiter. RS485 Bus ist über TCP/IP verlängert, aber mehr geht wohl nicht.

Jemand eine Idee?

Beste Grüße
Frank

[owagner]

Was für Optionen gibt es denn bei den RS485-IP-Bridges?