Protokoll: Schaltbefehle über Netzwerk

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?

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.

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?

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.

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

ja.

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?

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

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