Forum: PC-Programmierung Protokoll: Schaltbefehle über Netzwerk


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Android (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

Ich möchte gerne kurze Schaltbefehle über mein bestehendes Heimnetzwerk 
übertragen. Im ersten Schritt soll die Übertragung zwischen zwei PCs 
erfolgen. Später soll die schaltende Einheit evtl. ein RaPi sein. Es 
muss sichergestellt sein, dass die Schaltbefehle auch wirklich ankommen. 
Der Datendurchsatz ist sehr gering.

Welches Protokoll würdet ihr mir empfehlen?

Schon mal vielen Dank!

von Frank W. (Firma: DB1FW) (frankw) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Schau dir mal MQTT an

https://de.wikipedia.org/wiki/MQTT

von Noch einer (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Was meinst du mit "sichergestellt"? Muss es auch bei Hardwarefehlern 
funktionieren?

Handelt es sich um einen Futterautomaten und das Leben deiner Haustiere 
hängt von der sicheren Übertragung ab?

von PittyJ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe so etwas bei mir über UDP gemacht.
Allerdings gibt es dabei keine Garantie, dass die Befehle auch wirklich 
ankommen. Um das sicher zu stellen, muss ein TCP Protokoll genommen 
werden. Am besten eines, wo es auch noch ein Antwort vom Empfänger 
zurück gibt.

von Android (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mit "sichergestellt" meine ich, dass das Paket nochmal gesendet wird, 
wenn es auf dem Transportweg verloren geht.

Ich beabsichtige damit eine Hausautomation umzusetzen. Also von Licht, 
über Fensterkontakt, Temperatur, Luftqualität, usw...

Hab mir MQTT mal angeschaut. Das sieht ziemlich gut aus. Hat jemand von 
euch so ein System schon mal aufgesetzt?

von Stephan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Android schrieb:
> Mit "sichergestellt" meine ich, dass das Paket nochmal gesendet wird,
> wenn es auf dem Transportweg verloren geht.

ist doch mit TCP alles sicher gestellt, wie bereits oben gesagt.

von dunno.. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Android schrieb:
> Hab mir MQTT mal angeschaut. Das sieht ziemlich gut aus. Hat jemand von
> euch so ein System schon mal aufgesetzt?

ja.

von Android (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Den Broker würde ich mal mit mosquito aufsetzen oder vorab mal mit einem 
öffentlichen testen.
Könnt ihr mir ein Programm für IOS oder Android empfehlen, mit dem ich 
freie Testnachrichten publishen und subscriben kann?

von длинний зелёний тролль (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ein sicheres Protokol mit Autoretry usw ist ja gut, reicht aber 
moeglicherweise nicht.
Ich wuerde auf den Controller eine sicherheitsbasierte Zustandsmaschine 
aufsetzen. Also definieren wie schaut jeweils ein eigensicherer Zustand 
aus. Es kann zB sein, dass ein Verbraucher/Pumpe/Heizung/.. eigensicher 
= "aus" sein soll. Dann setzt man das Protokoll so auf, dass nach einem 
setzbaren Timeout, der eigensichere Zustand eingenommen wird. Ein Befehl 
sieht dann zB so aus :
 Pumpe ein, Timeout, Pumpe aus, CRC

Falls also aufgrund von irgendwelchen nicht spezifizierten Gruenden* 
kein weiterer Befehl eintrifft, geht das System nach dem Timeout in den 
sicheren Zustand.

*nicht spezifizierte Gruende : jemand stolpert ueber das Kabel, 
dauerhafter Unterbruch, Batterie des Steuergeaetes ist leer, ...

von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
PittyJ schrieb:
> Ich habe so etwas bei mir über UDP gemacht.
> Allerdings gibt es dabei keine Garantie, dass die Befehle auch wirklich
> ankommen. Um das sicher zu stellen, muss ein TCP Protokoll genommen
> werden.

Nö, stimmt nicht. Man kann oberhalb der Protokollebene von UDP natürlich 
trotzdem ein Handshake programmieren.

Und bei Mikrocontrollern ist das auch nicht völlig sinnlos, denn eine 
UDP-Implementation erfordert wesentlich weniger Resourcen als TCP.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:

> Nö, stimmt nicht. Man kann oberhalb der Protokollebene von UDP natürlich
> trotzdem ein Handshake programmieren.
>
> Und bei Mikrocontrollern ist das auch nicht völlig sinnlos, denn eine
> UDP-Implementation erfordert wesentlich weniger Resourcen als TCP.

JA!

Mehr noch: Im LAN kann man auch noch auf UDP und IP (samt aller zum 
Betrieb nötigen Anhängsel wie ARP und ICMP) verzichten. Das ist alles 
völlig über, wenn man in nur einem Netzwerksegment eine Art 
Fernsteuerung betreiben will.

Genau deswegen funktionieren auch industrielle Ethernet-basierte 
"Fernsteuerungen" knapp über dem MAC-Layer. Die brauchen diesen ganzen 
Kram dann nicht und benutzen ihn deshalb auch nicht. Wozu auch?

Benutzt wird das Zeug nur dann, wenn sich die Notwendigkeit einer 
Kommunikation über mehrere Ethernet-Netzwerksegmente hinweg ergibt. So 
war das mit den Protokollschichten ursprünglich auch mal gedacht: immer 
nur die benutzen, deren Features man wirklich benötigt...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.