Hallo Zusammen, ich habe vor meinen Hausbus auf Basis von UDP Broadcasts aufzubauen. Somit benötige ich keine zentrale Instanz und kann trotzdem sehr leicht die MediaPCs, Handys und Tablets mit einbinden. Für die Mikrocontroller gesteuerten Aktoren wird es dann ein Gateway geben, das die UDP Pakete transparent auf einen Mikrocontroller freundlichen Bus weiterreicht (RS485 oder was auch immer) und auch umgekehrt. Hat das hier schon mal jemand realisiert? Oder gibt es evtl. gute Gründe die gegen ein solches Vorhaben sprechen? Vielen Dank schon mal für das Feedback Philipp
Gründe dagegen: UDP: Geht ein Paket verloren ist es weg - kein retransmit etc --> TCP unterstützt das, jedoch sollte ein Multicast nicht so einfach sein wie bei UDP Ethernet braucht viel Strom, wenn es nur wenige Schnittstellen Ethernet->RS 485 sind, dann problemlos (wenn TCP verwendet wird, gibt es das quasi schon fertig: AVR NET IO+Ethersex+Y-Port)
So nun angemeldet :) Vielen Dank für den Kommentar. Zu Punkt 1: Auf UDP geht das Paket zwar verloren, aber ebenso auf dem RS485. Das heißt das Hausbusprotokoll selbst muss für die Datensicherheit sorgen. Ich benutze UDP also quasi wie den physikalischen Layer bei RS485 (wird wohl eher etwas mit CAN Transceivern direkt am UART werden). Zudem habe ich bei TCP wieder eine Punkt zu Punkt Verbindung, bei der ich so etwas wie die IP Adresse des Gegenüber kennen muss und ich kann es auch nicht auf RS485 oder anderen Layern ohne weiteres Abbilden. Zum Stromverbrauch: Aus diesem Grund noch die anderen physikalischen Layer. Also RS485 und höchstwahrscheinlich auch RFM12. Es sind also nur Ethernetknoten angeschlossen, die ohnehin schon existieren. Also die Media PCs, Handy, Tablet und Notebooks. Dazu kommt nur ein Raspberry Pi der die Brücke realisiert. So ist es dann möglich, dass zB das Tablet direkt die "Ich bin fertig" Nachricht der Waschmaschine empfangen kann, obwohl diese über ein RFM12 Modul gesendet wurde. Der Pi hat es empfangen und den kompletten Inhalt des Pakets einfach über UDP gebroadcastet. Er muss dazu nichts von einer Washmaschine wissen, eigentlich sogar nicht mal das Hausbus-Protokoll können. Somit spielt sich das eigentliche Hausbus Protokoll nur im Payload der einzelnen Layer ab. Wichtig ist nur, dass die Pakete der unterschiedlichen Layer die kompletten Daten transportieren können. Sollte der Pi mal ausfallen, könnte man entsprechende Interfaces (z.B. RFM12) ans Notebook stecken und keiner im Bus würde merken, dass die Brücke nun woanders läuft. Viele Grüße Philipp
Angehängte Dateien:
-
DSC04935s.JPG
130 KB -
DSC04937s.JPG
130 KB
Philipp schrieb: > Für die Mikrocontroller > gesteuerten Aktoren wird es dann ein Gateway geben, das die UDP Pakete > transparent auf einen Mikrocontroller freundlichen Bus weiterreicht Meine Mikrocontroller können direkt ans Ethernet angeschlossen werden. Das teuerste an der Geschichte, die Du da siehst, ist die Ethernetbuchse. Die andere Buchse ist für den ICD3. Die Größe des Moduls wurde durch den DIL64-Sockel bestimmt, es geht also noch kleiner. IOs sind mehr als genug vorhanden, und die gängigen Internetprotokolle auch. Das wäre die Alternative. fchk
Schau Dir mal Ethersex und ZBus an. Das ist im Grunde IP über RS485. Damit kannst Du massenweise Geräte per TCP/IP (also sowohl TCP als auch UDP) erreichen, ohne überall Ethernetkabel zu verlegen und überall Ethernet-Übertrager, PHYs etc. zu verbauen. Funktioniert bei mir problemlos mit kleinen und großen Atmegas. Halt nur keine Geschwindigkeitsrekorde, aber das ist im Hausbus-Bereich ja normal nicht nötig.
@Frank K.: Dein Board sieht richtig chic aus. Damit würde ich ja gerne mal bisschen rumspielen. Hast du das zufällig schon mal irgendwo "veröffentlich" oder bleibt das Layout und der Quellcode in deiner Schublade? Gruß tu
Schau Dir das hier an, gleicher Chip, nur eben noch etwas mehr drumrum. https://www.olimex.com/Products/PIC/Proto/PIC-P67J60/ Der Controller hat praktisch alles erforderliche eingebaut, Du musst nur noch die Ethernetbuchse, 25 MHz Quarz und 3.3V und einige R,L,C anschließen. Einfacher, kleiner und billiger gehts nicht. Die Software gibts bei Microchip, da brauchst Du gar nicht mehr viel selber machen. http://www.microchip.com/MAL fchk
@Frank: Wie sieht es denn mit dem Energiebedarf Deines Moduls aus? Ich war von Ethernet für die kleinen Knoten abgerückt, weil ich gesehen habe wie viel Strom mein AVR-NET-IO benötigt. @Gerd: Danke für den Hinweis, ich werde mal rüberschauen, aber ich denke, dass ich an meinen Hausbus eher andere Anforderungen habe als sich problemlos mit TCP realisieren lassen. Möchte zB einfach in den Bus fragen können, wer alles hier im Wohnzimmer ist (also an Modulen). Oder ich möchte, dass alle Lampen eines bestimmten Raums ausgeschaltet werden ohne mir darüber Gedanken machen zu müssen wie viele Lampen es dort gibt und welche Adressen diese haben. Ich habe vor es eher wie auf einem CAN Bus (also mit Events) zu realisieren, anstatt Punkt zu Punkt Verbindungen mit TCP aufzubauen. Generell ging es mir hier im Thread auch weniger über den physical layer. Das gibt es ja schon in vielen anderen Threads und bei mir steht da eigentlich schon fest, dass mindestens RFM12 Funk dazukommen soll. Wenn Franks Lösung energiesparend ist, dann ist es auch sehr interessant, aber das ändert an dem eigentlichen Bus ja nicht wirklich was. Viel eher als die Hardware würde mich interessieren wie Eure Busprotokolle so aufgebaut sind. Viele Grüße Philipp
Philipp C. schrieb: > @Frank: Wie sieht es denn mit dem Energiebedarf Deines Moduls aus? Ich > war von Ethernet für die kleinen Knoten abgerückt, weil ich gesehen habe > wie viel Strom mein AVR-NET-IO benötigt. Ganz wenig ist das nicht, leider. Ich habe mal 0.6W gemessen, wobei 90% für den Ethernet PHY draufgingen. Das wird beim AVR-NET-IO wohl ähnlich sein, wobei dort die Leistungsaufnahme wegen 5V-Technik noch etwas höher sein dürfte. Bei mir spielt das aber keine so große Rolle, so viele Knoten habe ich nicht. fchk
Hmm, das ist wirklich ne Menge. Der ganze Raspberry Pi braucht im Idle keine 2W (380mA@5V) und da habe ich einen ganzen Linux Server. Wobei irgendwelche China Dimmer mit Fernbedienung wahrscheinlich auch nicht weniger brauchen als Deine Module, wenn die auf die Fernbedienung warten. Wie realisierst Du bei Dir die Kommunikation? Sprichst Du einzelne Knoten direkt per IP an und baust eine TCP Verbindung auf? Und hast Du da dann ein spezielles Protokoll um die Funktionen der einzelnen Knoten zu nutzen oder ist das universell gehalten? Viele Grüße Philipp
Moin Philipp, es geht dir doch vielmehr um die Adressierung, oder? Ich würde behaupten, dass das eine Aufgabe vom Network-Layer ist. UDP befindet sich ja einen Layer darüber, also im Transport-Layer. Wie wäre es, wenn du dich einfach bei ein paar Ideen von IPv6 bedienst? Dort gibt es keinen Broadcast mehr an alle, sondern nur noch Multicast. Jeder Node hätte somit einerseits eine feste Adresse und zusätzlich noch n Multicast-Adressen. Bspw. eine Multicast-Adresse für alle Lampen im Haus, eine für alle Lampen im Wohnzimmer, eine für alle Lampen in der Küche, ... usw. Somit kann man beliebig viele Gruppen von Aktoren bilden, die sich auch überschneiden können. Ein Lichtschalter könnte dann das Signal "Schalte dich aus" an entweder die jeweilige feste Adresse senden, oder eben an eine Multicast-Adresse. Als Absender wird dann die feste IPv6 des Schalters genutzt. Somit kann man den Ursprung der Nachricht auch jederzeit zurückverfolgen. Ein Abfragen von Sensoren ist dann ebenfalls möglich: Entweder per Unicast oder wieder durch eine Multicastgruppe. Somit könnte man mit einer einzigen Nachricht bspw. alle Temperaturen in allen Räumen einsammeln. (Entsprechend kommen auf eine Anfrage mehrere Antworten rein. Jeweils eine von einer immer klar identifizierbaren Absender-Adresse.) Ein Discovery von allen angeschlossenen Nodes kann man ebenfalls darüber realisieren. Ob du die Datagramme nun via UDP überträgst oder über was anderes, ist deine Sache. UDP hat sowas wie Checksummen - das könnte vielleicht ganz praktisch sein, damit du deine automatische Kaffeemaschine nicht wegen eines gekippten Bits auf eine falsche Uhrzeit programmierst und wohlmöglich der Morgenkaffee entweder schon kalt oder noch gar nicht fertig ist ;) Im Physical Layer kannst du irgendein shared Medium nutzen, was dir die Nachrichten überträgt. Wie du letztlich nun Kollisionen verhinderst oder detektierst liegt an der verwendeten Technik. Wenn du CAN benutzt, könntest du sogar QoS umsetzen! Denn das erste Feld ist das Versions-Feld (bei allen Frames gleich) und das zweite die Traffic Class. Somit tritt dabei erst der der Traffic Class der erste Unterschied zwischen den Frames auf. Ich kenne mich mit CAN kaum aus, aber ich meine, dass sich gewissen Bits durchsetzen, richtig? Wenn du Probleme mit der Last auf dem Bus bekommen solltest, könntest du sogar Routing bzw. Subnetting betreiben. Du müsstest dann nur beachten, die Multicasts jeweils entsprechend zu propagieren. (Die Profis machen das übrigens mit dem Protokoll IGMP ... damit meldet man "Multicastbedarf" für ein Subnet beim Router an.) Der Ansatz mit IPv6 hätte auch den Vorteil, dass du recht leicht Router zwischen deinem CAN und deinem Ethernet / WLAN bauen kannst und damit auch per Tablet steuern kannst. (von iPads / iPhones weiß ich, dass sie standardmäßig - auch wenns nirgends in der Einstellungen zu finden ist - auch IPv6 mitmachen sofern ein Router im Netz ist, der advertised wird.) Das wären nun meine Gedanken zu deinem Vorhaben. Derzeit bin ich dabei IPv6 auf die kleinen AVRs zu bringen - jedoch ruht dieses Projekt wegen absoluten Zeitmangel seit Monaten. Es ist aber schon mal um einiges einfacher zu portieren als IPv4, da im Gegensatz zu v4 keine Checksummen über den Header mehr in den Frames drin sind. (Muss also irgendwie auf PHY-Layer gesichert werden ...) Ebenso kann man der Übermittlungsstrecke verklickern, dass man bitte keine fragmentierten Pakete haben will. Sehr praktisch, da man das bei v4 noch immer irgendwie bedenken sollte (Habe ich aber nie gemacht ;)). Wenn du magst halte ich dich ein wenig über meinen IPv6-Stack auf dem laufenden. Was ich bisher habe, möchte ich lieber noch nicht veröffentlichen. Einerseits grottig dokumentiert, andererseits buggy. Zum Debuggen habe ich mir kürzlich ein Switch mit Port-Mirroring bestellt - hoffentlich finde ich dann heraus, was das Problem ist. Ich hoffe, das war für dich irgendwie teilweise brauchbar und ich habe jetzt nicht absolut an deinem Problem vorbei gesponnen. Grüße Jürgen
Philipp C. schrieb: > Wie realisierst Du bei Dir die Kommunikation? Sprichst Du einzelne > Knoten direkt per IP an und baust eine TCP Verbindung auf? Und hast Du > da dann ein spezielles Protokoll um die Funktionen der einzelnen Knoten > zu nutzen oder ist das universell gehalten? Ich gehe da mit einem Browser drauf und schalte die Sachen, die ich brauche. Daher brauchte ich mir auch keine Gedanken über irgendwelche Busprotokolle zu machen. fchk
@Jürgen: Ja das klingt genau nach dem was ich mir vorgestellt habe :). Ich betrachte UDP wie gesagt einfach nur als einen Ersatz für den Draht, bzw. die Luft die ich auf den anderen phys. Layern habe. Möchte mich also gar nicht auf irgendwas von UDP verlassen, weil ich es nicht überall habe. Mit CAN habe ich einiges an Erfahrung. Im Prinzip sehr schön, nur wenn man rein Eventbasiert bleibt, dann sind einige Dinge umständlich abzubilden und der Haupt KO-Grund sind die max. 8Byte Payload. (Ja ich weiß man könnte Pakete zusammenbauen, habe auch mal einen Bootloader im Auto über CAN realsiert, aber schön ist das nicht). Daher werden es CAN Transceiver am UART. So kann ich im Gegensatz zu RS485 sicher Kollisionen erkennen und habe trotzdem die Vorteile der differenziellen Übertragung. Außerdem habe ich noch etliche CAN Transceiver rumliegen. Das spart den CAN Controller und ich kann mehr Payload transportieren. Der Ansatz mit der Adressierung über diverse Multicast Adressen gefällt mir ganz gut. Ich hatte erst überlegt, die Adressen so aufzubauen, dass sie ungefähr so aussehen wie <RAUM><ModulID> und wenn die ModulID auf 0x00 ist, dann ist es halt ein Broadcast an alle Module des Raums. Aber damit lässt sich dann wieder nur schwer "alle Lichter des Raums" abbilden. Mit deinem Ansatz könnte man dann mit seiner Unicast Adresse Antworten und hätte beim "Lichter Discover" auch gleich alle Knoten gefunden. Bleibt nur noch die Frage, wie ein Broadcast (naja, eigentlich Multicast) an alle Lichter des Wohnzimmers aussieht? Dieser darf ja nicht alle Lichter des Hauses treffen und auch nicht alle Module des Wohnzimmers. Oder wäre ein Dimmermodul im Wohnzimmer nach Deinem Ansatz dann einfach in alle diesen Gruppen: - Wohnzimmer - Licht - Wohnzimmerlicht ? Das können dann ne ganze Menge Gruppen werden und man müsste vorher wissen was man wohl mal zusammenfassen will. Viele Grüße Philipp
Ich mache das komplett über Broadcasts. Die Module müssen sich dann rausfischen, welche Info für sie ist und welche nicht. Jedes Modul im Wohnzimmer weis dann z. B. das es auf "Wohnzimmerlicht an" reagieren muss, eines weis dann eben auch, dass es zusätzlich auf "Deckenleuchte-Wohnzimmer an" reagieren muss. Ausserdem wird zum Beispiel die Aussentemperatur regelmässig als Broadcast versendet. Alle Module kennen die dann, und die Heizungsregelungsbausteine können die dann verwenden. Eigentlich ähnlich wie bei CAN. Gruss Axel
Ja, ich bin mehr und mehr davon angetan es auch so zu machen. @Axel: Wie sieht denn bei Dir das weitere Protokoll so aus? Muss ein Client, der mit einem Knoten spricht für jeden neuen Knoten erweitert werden oder gibt es "Felder" die eine Bezeichnung und einen Wert haben können? Ich hätte das Protokoll gerne möglichst flexibel und würde ungern jedesmal den Client anfassen, wenn ein Knoten mit neuen Funktionen dazukommt. Viele Grüße Philipp
Philipp C. schrieb: > Mit CAN habe ich einiges an Erfahrung. Im Prinzip sehr schön, nur wenn > man rein Eventbasiert bleibt, dann sind einige Dinge umständlich > abzubilden und der Haupt KO-Grund sind die max. 8Byte Payload. (Ja ich > weiß man könnte Pakete zusammenbauen, habe auch mal einen Bootloader im > Auto über CAN realsiert, aber schön ist das nicht). Daher werden es CAN > Transceiver am UART. So kann ich im Gegensatz zu RS485 sicher > Kollisionen erkennen und habe trotzdem die Vorteile der differenziellen > Übertragung. Außerdem habe ich noch etliche CAN Transceiver rumliegen. > Das spart den CAN Controller und ich kann mehr Payload transportieren. 8Byte Payload sind nicht sehr viel. Da kannst du gerade mal eine halbe IPv6-Adresse unterbringen :D Du kannst dir das Protokoll natürlich designen, wie du möchtest: Kürzere Adressen bspw. Nur wenn du mit einen echten IPv6-Teilnehmern aus dem Ethernet sprechen möchtest, muss dein Router eine Umsetzung zwischen dem IPv6 light (ich nenns mal so) und IPv6 machen. Ich hatte mal über ein Bus-System nachgedacht, dass CAN recht nahe kommt. Als NIC hatte ich mir ein kleines, günstiges, nicht-flüchtiges FPGA vorgestellt. Das kann dann auch gleich den IPv6-Stack mitmachen und den dahinter geschaltete µC nur in dem Fall aufwecken, wenn tatsächlich Daten für ihn vorliegen. Ebenso kann es auf der anderen Seite des Stacks die Kollisionskontrolle usw. machen. Ggf. sogar noch eine Manchester-Codierung dazupacken - dann klappt es auch ganz gut mit der Taktrückgewinnung. PLLs sind ja Standard auf FPGAs ... Ich bin mir nur nicht ganz sicher, wie ich den Bus-Zugang hinbekomme. Entweder mit zwei RS485-Transceivern (einer im Modus "Senden" und einer im Modus "Empfangen") oder ich baue selber etwas mit OpAmps und Schmitt-Triggern. Kollisionen könnte ich dadurch erkennen, dass ich sende und gleichzeitig den Bus abhöre und das gesendete mit dem abgehörtem vergleiche. Aber das sind alles nur Gedankenspielereien. Natürlich mal wieder wo anders abgeguckt: Ethernet (also das 10MBit-Zeug) hat mir Manchester übertragen. (Abgesehen davon steigt mir mein Vermieter unters Dach, wenn ich seine Wohnung komplett umkremple und den Bus hier reinziehe ^^) Wie löst CAN denn die Kollisionsdetektion bzw. die Kollisionsvermeidung? Oder ist die Baud-Rate so niedrig, dass ein Sendesymbol sich vollständig auf dem Bus ausbreiten kann, bevor das nächste kommt? > Der Ansatz mit der Adressierung über diverse Multicast Adressen gefällt > mir ganz gut. Ich hatte erst überlegt, die Adressen so aufzubauen, dass > sie ungefähr so aussehen wie <RAUM><ModulID> und wenn die ModulID auf > 0x00 ist, dann ist es halt ein Broadcast an alle Module des Raums. Aber > damit lässt sich dann wieder nur schwer "alle Lichter des Raums" > abbilden. Mit deinem Ansatz könnte man dann mit seiner Unicast Adresse > Antworten und hätte beim "Lichter Discover" auch gleich alle Knoten > gefunden. Bleibt nur noch die Frage, wie ein Broadcast (naja, eigentlich > Multicast) an alle Lichter des Wohnzimmers aussieht? Dieser darf ja > nicht alle Lichter des Hauses treffen und auch nicht alle Module des > Wohnzimmers. > > Oder wäre ein Dimmermodul im Wohnzimmer nach Deinem Ansatz dann einfach > in alle diesen Gruppen: > - Wohnzimmer > - Licht > - Wohnzimmerlicht > ? > Das können dann ne ganze Menge Gruppen werden und man müsste vorher > wissen was man wohl mal zusammenfassen will. Genau. So würde ich es anstellen. Macht ja nichts, wenn ein Node in mehreren Multicast-Gruppen ist. In deiner Auflistung würde ich auf jeden Fall noch eine Gruppe "Alle" einbauen. Grüße Jürgen
IPv6 werde ich definitiv nicht auf dem Hausbus implementieren und auch keine Umsetzung zwischen verschiedenen Layern machen. Die Bridge soll so dumm wie möglich sein. Die packt einfach das Paket vom RFM12/Kabel aus und kippt den kompletten Payload (der Hausbusadressen usw enthält) stumpf auf UDP und umgedreht. Das heißt die Bridge weiß nix von einem Protokoll, die kennt nur Pakete mit einer Payload. Kollisionsdomänen kann ich einfach mit solchen Bridges trennen, die einfach Pakete von einem Bus auf den anderen Schaufeln. Das Problem bei RS485 ist, dass man nicht zuverlässig Kollisionen erkennen kann, weil der Pegel bei den meisten Transceivern in beide "Richtungen" getrieben wird. Das heißt nebenan mitzuhören bringt Dir nicht viel, wenn der andere Sender hochohmiger (weiter weg) als Dein Sender ist. Der Vorteil von CAN Transceivern ist, dass sie einen dominanten und einen rezessiven Pegel haben und so der dominante siegt, auch wenn er weiter weg liegt. Ob bei 10Base2 neben Manchester auch ein rezessiver Pegel die CD realisiert hat weiß ich nicht, würde ich aber vermuten. Ein weiterer Vorteil der CAN Transceiver ist, dass Du sie nicht umschalten musst. Du benötigst nur einen einen Transceiver und kannst RX und TX direkt mit dem UART verbinden, aber das wird jetzt OT :). Hier sollte es ja ums Protokoll gehen, die physical Layer wurden ja schon in 1000 anderen Threads diskutiert. Nachdem nun also jede Node eine eindeutige Unicast Adresse bekommt mit der auch die Antworten versehen werden und zusätzliche diverse Gruppen ist noch die Frage wie der Rest eines solchen Paketes aussehen sollte. Realisiert man es so, dass es diverse Key-Value Paare gibt die abgefragt werden können? Und man die Node nach ihren Keys fragen kann? Dazu würde man dann noch Wertebereiche benötigen. Und evtl. verschiedene Datentypen. Oder fängt man den Wertebereich einfach in der Node ab? Schön wäre natürlich, wenn der Key "Helligkeit" des Dimmers meinem Tablet verrät, dass er Werte zwischen 0 und 255 erwartet, damit das Tablet den Schiebebalken korrekt darstellen kann. Viele Grüße Philipp
So die Idee ist ist nun auf Subadressen usw. zu verzichten. Jede Funktion hat eine Unicastadresse egal ob es 10 Funktionen auf einem Controller gibt oder nur eine. Von außen sieht es dann halt aus wie 10 Nodes. Nach einiger Überlegung und diversen Anregungen von außen, hier nun eine erste Idee zum Paketaufbau: <Unicast oder Gruppenadresse> <- hier reicht 1 Bit <Empfängeradresse Unicast bzw. Gruppe> <Absenderadresse (immer eine Unicast Adresse)> <Typ der Nachricht. zB. GET_NAME> [<Datentyp (double; int; string)>] [<DATA>] Hierbei sollten dann folgende Nachrichtentypen implementiert werden: GET_NAME Fordert den Namen eines Moduls an. Ein Modul ist nicht zwangsläufig ein Controller. Ein Controller kann hierbei mehrere Module beinhalten und somit auch mehrere Unicast Adressen besitzen NAME Antwort auf ein GET_NAME. Kann beim Einschalten an die Gruppe "Alle" gesendet werden oder gezielt auf eine Unicast Adresse die GET_NAME angefordert hat. Datentyp ist String. GET_RANGE Anfrage nach dem erlaubten Bereich der Node. RANGE Antwort auf GET_RANGE. Über den Datentyp ist festgelegt welchen Datentyp die Node erwartet. Es werden MIN und MAX Wert hintereinander gesendet. Sollte der Datentyp String sein, so wird nur ein Wert gesendet, der der maximalen Länge entspricht GET_VALUE Fordert den aktuellen Wert an VALUE Sendet den aktuellen Wert inklusive Datentyp SET_VALUE Setzt die Value auf den übertragenen Wert. Diese Nachricht wird automatisch mit einem VALUE Paket beantwortet. Die Value Grenzen werden dabei von der Node eingehalten. ACK Wird als Empfangsbestätigung gesendet, wenn direkt an eine Unicast Adresse gesendet wurde. Multicast Sendungen sind so allerdings nicht gesichert, was aber auch nicht notwendig sein sollte. Ein Szenario könnte also folgendes sein: M steht hierbei für Multicast, U für Unicast. Ich schalte das Tablet ein und möchte die Temperatur in einem Raum ändern. <M><an alle Heizungen><Tablet><GET_NAME> <U><Tablet><Wohnzimmerheizung><NAME><string><"Wohnzimmer Heizung"> <U><Wohnzimmerheizung><Tablet><ACK> <U><Tablet><Esszimmerheizung><NAME><string><"Esszimmer Heizung"> <U><Esszimmerheizung><Tablet><ACK> ... usw Danach kennt das Tablet alle Heizungen und man könnte nun wieder einen Multicast senden und alle auf die Spartemperatur fahren lassen oder aber einer einzelnen Heizung einen Unicast mit <SET_VALUE> senden. Um das fehlende ACK beim Muticast auszumerzen könnte man einen Multicast mit GET_VALUE senden und kontrollieren ob es auch alle gemacht haben. Analog würde man bei Licht usw. verfahren. Viele Grüße Philipp
IMHO verstrickst du dich da in Details,
obwohl das ganze Konzept eher (naja) ... ist..
was soll das bringen? "Hoch intelligente", ("halb")dezentrale Aktoren,
(noch dazu als Beispiel Wohnzimmer, wo doch der Heizungsverteiler ganz
wo anders ist..;-)
Moin Robert, ich kann Deinen Kommentar nicht so ganz deuten. Warum nur "halb" dezentral? Ist doch komplett unabhängig von einer Zentrale. Das Ganze war nur ein Beispiel, aber in diesem Beispiel Heizungsthermostate wie ein HR20 und die sind genau da wo man es warm haben möchte. Und eine besondere Intelligenz der Aktoren ist so auch nicht notwendig. Ich würde mich sehr über Kritik freuen (darum ist es hier drin) nur sollte diese dann auch konstruktiv sein.
deshalb "halb" dezentral, weil du nicht jede Lampe und Taster mit einem
eigenen Kabel anfahren kannst (ich meine man könnte schon, aber dann
hättest 5 Switches mit je 24 port s im Keller ?? ..
du hast also eher "kleine Unterverteiler" in jedem Raum.. also mehrere
"zentralen" ...
>Ist doch komplett unabhängig von einer Zentrale.
im EFH wird das etwas überschätzt, finde ich..
(die "zentrale", sei es eine SPS oder sonst was) einfach 2mal zu kaufen,
ein paar meter kabel mehr, ist meist billiger, als alles dezentral zu
machen)
wenn dein (peo) switch defekt ist, geht auch GARNICHTS mehr..
Wieso Switches? Wenn überhaupt einen AVR mit entweder CAN Transceiver oder eben RFM12. Und wie oben schon geschrieben sagt ja niemand, dass ein Controller (meinetwegen auch ne SPS) nicht virtuell mehr als eine Node darstellen kann. Es ist also reine Auslegungssache ob das Ganze nur halbzentral ist, weil man es gerne direkt in die Unterverteilung baut oder wirklich jede Lampe einen Controller bekommt. Und bei RFM12 oder einem CAN artigen Bus hat man auch keinen Switch als single point of failure. Das Ganze hat doch genau gar nichts mit dem Protokoll zu tun?
>Wieso Switches? naja, deshalb: > Hausbus auf Ethernet (es gibt ja inzwischen tatsächlich TASTER auf Ethernet Basis, die sind richtig interessant, aber das ist ein anderes thema...) du willst also eher: mehrere Bussystem-abschnitte mit Ethernet verbinden so wie man es bei KNX auch machen kann? du willst also nicht nur ein eigenes Bussystem erfinden (can-basiert oder was auch immer) an dem hier eh noch JEDER gescheitert ist sondern diese auch noch mittels Ethernet verbinden .... >Das Ganze hat doch genau gar nichts mit dem Protokoll zu tun? nein, eh nicht, weil MEINE MEINUNG: das Protokoll dein kleinstes Problem ist..
Ich gebe zu, die Überschrift ist etwas verwirrende. Aber das war meine Ursprungsfrage. Um es noch einmal zusammenzufasssen: UDP ist nur ein Ersatz für das CAN (oder was auch immer) Kabel und wird nur für ohnehin bestehende "Computer" verwendet die ohnehin Ethernet haben. Ich habe in der Vergangenheit schon einige Bussysteme umgesetzt und das nicht nur Privat. Den größten Ärger hat dabei immer ein, nicht von vornherein, zuende gedachtes Protokoll beschert. Daher liegt mein Fokus hier komplett auf dem Protokoll. Und so wie es gerade angedacht ist lässt es sich auf so ziemlich jedem Bus umsetzen.
Man könnte ja auch KNXnet als Protokoll nehmen. Dann steht einem die gesamte (Software) KNX Welt zur verfügung...
>CAN >(oder was auch immer) CAN gibt es ja schon ein(/mehrere) "fix fertiges" Protokoll ? zum thema "ethernet Tunneln", da muss man das Protokoll nicht unbedingt kennen: http://www.systec-electronic.com/en/products/industrial-communication/interfaces-and-gateways/can-ethernet-gateway-v2
@Robert: lies bitte einfach den Thread, dann hättest Du Dir alle Deine bisherigen Kommentare sparen können. Philipp C. schrieb: > Die Bridge soll so > dumm wie möglich sein. Die packt einfach das Paket vom RFM12/Kabel aus > und kippt den kompletten Payload (der Hausbusadressen usw enthält) > stumpf auf UDP und umgedreht. Das heißt die Bridge weiß nix von einem > Protokoll, die kennt nur Pakete mit einer Payload.
Ich habs gelesen, inzwischen sogar ein 2. mal... dein "Konzept" hast du zwischendurch schon 3 mal über den Haufen geworfen, wie soll man da noch durchblicken... (dein "Beispiel" mit dem Tablet ist sowieso kurios..) es erschließt sich mir inzwischen überhaupt nicht mehr, was du überhaupt willst.. z.b. >Oder >ich möchte, dass alle Lampen eines bestimmten Raums ausgeschaltet werden >ohne mir darüber Gedanken machen zu müssen wie viele Lampen es dort gibt >und welche Adressen diese haben. (abgesehen davon, dass sich mir der Grund für diesen Wunsch nicht erschießt) hier sprichst du z.b. noch davon, dass du DESHALB! UDP broadcasts "brauchst" usw. von deinem Anfangsposting ist genau NIX übrig geblieben..
Wo wurde hier denn etwas über den Haufen geworden? Es wurde bisher nur verfeinert. Ich habe auch nirgendwo von der Notwendigkeit von UDP Broadcasts gesprochen. Warum man dieses oder jenes gerne hätte muss bei einem Hausbus glaube ich wirklich nicht gerechtfertigt werden. Schließlich geht es ja auch alles ohne einen Bus. Aber zu dem Beispiel mit dem Wohnzimmerlicht: Ich möchte einfach, dass wenn wir abends das Wohnzimmer verlassen, auf einen Schlag alles ausmachen können. Also die ganzen Schnickschnacklichter meiner Frau, die Lampe an der Couch usw. Zudem ist es einfach die gleich Funktion wie zB alle Heizkörper eines Raums (ja ich habe mehrere Räume mit mehr als einem Heizkörper) auf die Spartemperatur bzw. auf die Komforttemperatur zu stellen. Oder eben das Ganze Haus, wenn es in den Urlaub geht. Also nochmal als Fazit an dieser Stelle: - UDP soll (wie von vornerein gesagt) nur die Komponenten vernetzen, die ohnehin einen Ethernetzugang haben. Um z.B. den aktuellen Film zu pausieren und die Meldung "Waschmaschine ist fertig" einblenden zu können. Außerdem würde ich gerne mit dem Handy oder Tablet (WLAN) die Heizung verstellen können. - Alles weitere an Modulen, also zB die eigentlichen Aktoren hängen entweder über ein CAN artiges Netz oder über RFM12 am Bus. - Als Schnittstelle dient ein Raspberry Pi der die Pakete von einem physical Layer ins andere Übersetzt. Fällt dieser aus, so ist lediglich das Netz vom Ethernet getrennt. Lichtschalter und Lampen sind weiterhin auf der CAN Basis verbunden. Soweit zur Hardwareseite. Jetzt stellte sich die Frage, was man sinnvollerweise auf dem Bus sprechen sollte um möglichst einfach die genannten Wünsche zu realisieren. Da kam von Jürgen die Idee das Ganze an IPv6 anzulehnen und anstatt von Masken auf den Adressen einfach mehrere Multicastadressen einzurichten. Eine mögliche Ausprägung davon habe ich dann versucht in dem Tablet Beispiel darzustellen. Wenn daran etwas unklar ist oder zu weit ab von der Realität wäre ich da für Hinweise nach wie vor sehr dankbar. Achja. Hier noch mal der Ursprungsbeitrag von dem "NIX" übrig ist: Philipp schrieb: > Hallo Zusammen, > > ich habe vor meinen Hausbus auf Basis von UDP Broadcasts aufzubauen. > Somit benötige ich keine zentrale Instanz und kann trotzdem sehr leicht > die MediaPCs, Handys und Tablets mit einbinden. Für die Mikrocontroller Wie erwähnt Anbindung für Handy MediaPC usw... > gesteuerten Aktoren wird es dann ein Gateway geben, das die UDP Pakete > transparent auf einen Mikrocontroller freundlichen Bus weiterreicht > (RS485 oder was auch immer) und auch umgekehrt. Der Mikrocontrollerfreundliche Bus hat sich zu CAN Transceivern am UART entwickelt. Da seh ich nun auch nicht so den Bruch mit "RS485 oder was auch immer" > > Hat das hier schon mal jemand realisiert? Oder gibt es evtl. gute Gründe > die gegen ein solches Vorhaben sprechen? > > Vielen Dank schon mal für das Feedback > Philipp
loxone macht vom prinzip genau das alles, was du willst...
(ausser dass "CAN artiges Netz" eben ein "KNX artiges Netz" ist)
RFM12 u.U. per rs232 umsetzer anschließbar, weiß ich aber nicht..
schnittstelle zum LAN gibt es nur eine
die ganze logik ist also am server, und muss nicht am Tablet/PC/sonstige
clients "neu erfunden" werden
kommuniziert wird z.b. über WebSockets (mit dem Brower/ oder App)
http (imho auch Rest interface)
Protokoll/Möglichkeiten kannst dir auf der WebSIte anschauen..
vielleicht kannst die da ein paar ideen holen..
oder:
>Ich habe in der Vergangenheit schon einige Bussysteme umgesetzt
vielleicht nimmst dieses mal einfach einProfessionelles, damit dann
nicht noch eines auf deiner liste von "nachher hat es dann doch nicht
gepasst" dazukommt...
Bin gerade dabei mir KNX anzusehen. Es gibt übrigens kein einziges auf dieser Liste. Es war nur ärgerlich teilweise wieder Hand an Dinge anlegen zu müssen die fertig gewesen sein könnten, wenn man es gleich komplett durchgedacht hätte. Klar ist der Hausbus etwas wo es wirklich fertige Dinge gibt (im Gegensatz zu den anderen Geschichten), aber bei diesen ganzen Bastelprojekten ist ja meist auch weniger der fertige Hausbus das Ziel des ganzen, als viel eher die Freude am Basteln. So aber nun wirklich genug des Trollfütterns
Hallo, soweit ich das verstehe habe ich habe seit zwei Jahren einen Hausbus über CAN mit Ethernet-Backbone (UDP) im produktiven Einsatz, der ziemlich genau Deinen Vorstellungen entspricht. Am Anfang habe ich NetIOs für die Gateways benutzt, inzwischen verwende ich Carambola-Boards. Seit kurzem ist das System bei einem Kollegen in einem zweiten Haus im Einsatz. Wenn es Dich interessiert, findet sich unter https://github.com/maveric00/HomeCANtrol (fast) das ganze System. Fast deswegen, weil ich noch nicht dazu gekommen bin, das Layout vom neuen Gateway sowie die notwendigen Änderungen an OpenWRT einzustellen (werde ich aber vermutlich im Laufe der Woche nachholen). Auch ist die Dokumentation sicherlich verbesserungsfähig ;-). Adressierung des Protokolls ist an KNX angelegt (Linien- und Knotenadressen), auch ist die Verkabelung des Systems von KNX abgeschaut (zentrale Aktoren, dezentrale Schalter/Sensoren mit KNX-Leitung als Bus verbunden). Ein Umstellen auf KNX ist also ohne Neuverkabelung, wohl aber mit den (hohen) Kosten der KNX-Komponenten möglich (falls man einmal nicht mehr in der Lage sein sollte, das System weiter zu warten). Die Gateways haben jeder WLAN, 2 Ethernet-Ports, 2 CAN-Busse, 1*RS232 und 1*RS485; das ganze in einem 2TE Hutschienengehäuse. Auf einem der Gateways läuft auch eine Steuersoftware, die eine Steuerung über Web-Browser oder über Telnet-Kommandos bereitstellt und Makros sowie zeitgesteuerte Abläufe ermöglicht; auch kann das System durch diese Software konfiguriert werden. Die Konfiguration erfolgt über eine XML-Datei. An Automatisierungskomponenten steht ein 10* Relaisaktor im 6TE Hutschienengehäuse (ausgelegt auf jeweils 16A/250V), 1 Sensorboard (6 Ein/Ausgänge mit unterschiedlichen Beschaltungsmöglichkeiten) sowie 1 LED-Treiberboard (für 6*20mA RGB + 1*500mA RGBW) zur Verfügung; ein Sensorboard mit 10 einfachen Ein/Ausgängen kommt demnächst hinzu. Ganz fertig und fehlerfrei ist das System noch nicht (wann ist das eine Selbstbaulösung schon ;-) ), aber inzwischen ist es soweit, dass es (auch für meine technik-scheue Frau) zufriedenstellend funktioniert. Schöne Grüße, Martin
Hallo in die Runde, ich beschäftige mich seit längerem mit Heimautomatisiserung und diversen Bussystmen (ca.12Jahre) .Man sollte Meiner Meinung nach alles was möglich ist, mit Ethernet (TCP/UDP) verbinden. Meist ist mit Ethernet keine neue Verkabelung nötig (das ist nicht zu unterschätzen!) und wenn doch mal kein Kabel liegt geht das auch mit WLAN! Ansonsten wird wahrscheinlich keine Heimautomatisiserung (wie auch immer geartet) mit nur einem physischen Medium auskommen. Somit brauch man immer irgendwelche Wandler zwischen den Protokollen (Infraro, Funksteckdosen - Stichwort FS20/HomeMatic/Temperatursensoren, Serielle Kommiunikation, Internetanbindung, KNX,...) Im Endeffekt läuft es immer! auf das PROTOKOLL hinaus (wie von Philipp geschrieben). Der Ansatz mit der Kommunikation mit dem Tablet scheint mir vielversprechend. Wichtig und nicht zu unterschätzen ist auch, dass alle Komponenten autark laufen können. ALso keine Abhängigkeiten von einem zentralen Server. Idealerweise kann man einen Konten vom Netz nehmen und alles andere läuft "normal" weiter. So können später auch Funktionalitäten neu dazugebaut werden ohne alles andere umzuprogrammieren. Fertig wird so ein System ja nie (maveric00) Beste Grüße full www.full-it-service.de
Philipp C. schrieb: > Wie sieht es denn mit dem Energiebedarf Deines Moduls aus? Ich > war von Ethernet für die kleinen Knoten abgerückt, weil ich gesehen habe > wie viel Strom mein AVR-NET-IO benötigt. AVR-NET-IO ist sicher kein gutes Beispiel für effizente Energienutzung. Schau dich auch mal bei WIZNET um z.B. ein WIZ820io (W5200) kann man an jeden Micro mit SPI anbinden. Hat Powerdown funktion und sonst ca. 100mA bei 3.3V !! (ein Raspi kann zum Thema Energieverbrauch dagegen auch nicht mithalten) Und zusätzlich: In order to reduce power consumption of the system, W5200 provides WOL (Wake on LAN) and power down mode. To wake up during WOL, W5200 should be received magic packet, which is the Raw Ethernet packet. Es gibt aber auch noch andere Ethernet chips bei Wiznet.
Hallo, ich sehe Ethernet hier eher als Brücke zwischen den Medien. Für jeden Knoten Ethernet halte ich für zu Energieintensiv. Aber das bleibt ja am Ende jedem selbst überlassen. Bisher war der Gedanke ja alles komplett transparent auf alle Medien zu geben, damit man sich nicht darum kümmern muss, welcher Knoten welche Nachricht wirklich braucht und wie diese dorthin kommt. Nun habe ich kürzlich einen dieser neueren Drehstromzähler mit IR Schnittstelle bekommen. Dieser sendet ca. alle 2s die aktuellen Leistungen auf allen drei Zweigen. Das ist natürlich für den Hausbus sehr interessant, aber verursacht das nicht evtl. schon zuviel Traffic für RFM12? (1% Duty). Das wären alle 2s je ein Paket mit dem Zählerstand, eins mit L1 Leistung, eins mit L2 und noch eins mit L3. Das Ganze bei einer geringen Baudrate macht dann recht viel Sendezeit. Man könnte nun natürlich sagen, dass man einfach alle Leistungen in ein Paket packt, damit spart man sich den ganzen Adressoverhead, aber das bricht dann ja mit dem bisherigen Protokollüberlegungen. Hat jemand eine Idee wie man damit am besten umgeht? Viele Grüße Philipp
Philipp C. schrieb: > aber verursacht das nicht evtl. schon zuviel Traffic > für RFM12? (1% Duty). Siehe hier (Bundesnetzagentur) für Details: http://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/BNetzA/Sachgebiete/Telekommunikation/Regulierung/Frequenzordnung/Allgemeinzuteilung/SRDShortRangeDevicesVfg432012.pdf?__blob=publicationFile
Nehmen wir mal an, du sendest aller 2 sec ein Paket und das senden selbst dauert 200ms (was sicher großzügig gerechnet ist) Ergibt sich: (60min*60sec) = 3600sec/100 = 36sec. Damit darfst du 36 sec innerhalb einer Stunde senden. Bei 200msec/Paket sind das also 36000msec/200msec pro Pakete = 180Pakete Somit kannst du 180 Pakete pro Stunde senden. -------------------- Unabhängig davon würde ich das nicht so machen. Du musst ja den Zähler irgendwie ans Ethernet bringen. Somit brauchst du hier eine Brigde (Controller). Nun macht es Sinn, dass der Controller selbst die Daten konsolidiert und sagen wir mal aller 5min gesammelt ins Netzt stellt. Alternativ könnte man das auch so machen, dass der Controller die Daten überhaupt nicht Broadcasted, sondern sich (analog deiner beschriebenen Methode mit dem Tablet) nur zu erkennen gibt. Braucht nun eine andere Komponente diese Daten (also zB dein Tablet um das anzuzeigen), so kann sie die Daten beim Controller jederzeit abfragen. Somit ist der Traffic minimiert. Prinzipiell denke ich, sollte das so konzipiert sein, das immer aktiv nach Daten gefragt werden muss. Außer! es ist zeitkritisch oder ein Konten zeigt einen Fehler oder Alarm an! Beste Grüße full PS: Klingt alles total spannend, du solltest aber den Aufwand nicht unterschätzen! sowas zu implementieren. Denke bitte auch an die Fehlerscenarios, also Spannungsausfall, oder Konten fällt aus oder liefert fehlerhafte Daten. Die Daten sollten somit immer validiert werden. zB: habe ich vor einer Minute 22C gemessen können es jetzt nicht -20C sein!
Hallo, sobald mal wieder Zeit ist würde ich mal abklären ob ich wirklich alle 2s die Daten brauche. Wenn es nur um den Zählerstand geht, dann hast Du natürlich recht und das Broadcasten alle 2s ist sinnlos. Wobei ich mir hier eigentlich nur sorgen mache, dass ich mit dem 1% Duty irgendwann nicht mehr auskommen. Auf dem Ethernet würde das ja nicht stören, wenn da nebenher alle 2s die Daten langkommen. Ich habe aber die Hoffnung in den Leistungsmustern der drei Phasen z.B. erkennen zu können ob die Waschmaschine fertig ist, man das Bügeleisen vergessen hat usw. Die Auswertung dessen würde dann aber wohl einfacher auf dem Raspberry Pi laufen damit bräuchte er aber permanent diese Daten. Naja, mal den Zähler loggen während man wäscht (einmal Nachts und einmal mit Personen im Haushalt die "stören") und dann gucken ob es das nächste Großprojekt wird da Muster zu erkennen oder ob es realistisch ist. Hat sich damit schon mal jemand hier beschäftigt? Viele Grüße und vielen Dank für die rege Beteiligung Philipp
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.