Ja. (Korrekt: 19200 Baud, siehe später im Thread) Lesetipp: http://homematic-forum.de/forum/viewtop ... 31&t=24736aixtreme hat geschrieben:9600 Baud
8 Data Bits
E --> Parity Even ?
1 --> ! Stop Bis
RS485 in IP Tunneln
Moderator: Co-Administratoren
Re: RS485 in IP Tunneln
Zuletzt geändert von owagner am 06.10.2015, 20:50, insgesamt 2-mal geändert.
Re: RS485 in IP Tunneln
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 bauenDaimler hat geschrieben:Wenn Du mir jetzt noch eine Alternative nennst, wie man das über's Wlan kriegt...
-
- Beiträge: 9118
- Registriert: 17.11.2012, 10:47
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Köln
- Hat sich bedankt: 37 Mal
- Danksagung erhalten: 286 Mal
Re: RS485 in IP Tunneln
Hi,
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:
Ich glaube, wir müssen uns einmal näher unterhaltenowagner hat geschrieben:Arduino nehmen,
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:
owagner hat geschrieben:.....und dann mit ein paar Zeilen Arduino-Code.....
Gruß Günter
pivccx mit 3.xx in Produktiv und Testsystem mit HM-, HM-W, HMIP- und HMIP-W Geräten, HPCx Studio 4.1,
L-Gateways, RS-L-Gateways, HAP, Drap, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM / HM-IP: Zur Zeit knapp 300 Komponenten mit ??? Kanälen .
Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!
pivccx mit 3.xx in Produktiv und Testsystem mit HM-, HM-W, HMIP- und HMIP-W Geräten, HPCx Studio 4.1,
L-Gateways, RS-L-Gateways, HAP, Drap, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM / HM-IP: Zur Zeit knapp 300 Komponenten mit ??? Kanälen .
Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!
Re: RS485 in IP Tunneln
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.
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.
-
- Beiträge: 14297
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 601 Mal
- Danksagung erhalten: 1529 Mal
Re: RS485 in IP Tunneln
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.owagner hat geschrieben:Das klingt, glaub ich, schwieriger, als es ist.
Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
Re: RS485 in IP Tunneln
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.Xel66 hat geschrieben: Ich würde mal eher das Gegenteil behaupten, denn BidCos-RF ist nicht gleich BidCos-Wired.
Also eine Selbstbau-RS485-Verlängerung, mehr nicht.
-
- Beiträge: 14297
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 601 Mal
- Danksagung erhalten: 1529 Mal
Re: RS485 in IP Tunneln
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.owagner hat geschrieben:Also eine Selbstbau-RS485-Verlängerung, mehr nicht.
Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
Re: RS485 in IP Tunneln
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
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
Re: RS485 in IP Tunneln
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
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