Hausbus auf Ethernet über UDP Broadcast

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

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.

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

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 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