UDP-Multicast-Protokoll clever SmartHome

lano

Aktives Mitglied
Moin.

Ich hab da mal ne Frage.
Und zwar ist das so.
Ich schock euch am besten estmal mit nem Bildchen...
Untitled Diagram(9).png

Wie oben unschwer zu erkennen Ein paar Sensoren. Die sollen nur regelmäßig ihre infos raus posaunen.
Sowas wie jede Sekunde die Temperatur zB
In grün gehalten, mehr so die Aktoren. Ein LCD an den ein Sensor quasi Daten zum anzeigen schicken kann oder ein Türrelais um die Tür zu öffnen.

Jetzt mehr Mittig gesehen ein kleines Programm in c (@german freu dich drauf :) ) was auf meinem Raspi zum laufen käme.
Das soll jetzt primär alle infos erstmal in eine sql datenbank packen. zB die GPS Position vom Auto. Temperatur usw. Alles was die Sensoren so senden.

Darunter hab ich so Programme die die Daten aus den Datenbanken auswerten sollen und auch rückmeldung zur multicast Gruppe schicken sollen.
Also zB für ne Heizungssteuerung. Der Sensor Sendet die temperatur und die "Heizungssteuerung" steuert dann ein Thermostat.

Jetzt hab ich mich durch GPS inspiriert auf sowas wie NMEA 0183 geeinigt. Also so im Groben. Einfach mit Komma getrennt.

Nu ist meine Errungenschaft bisher das jeder Sensor ne Uhrzeit mitsenden müsste.
Ich will das die Daten im Auto zb wenn das Auto nicht zuhause ist an einen quasi Relay Buffer landen der dann im Paket nur alle 30 sek die Daten an Server schickt. Da bin ich noch am überlegen wie ich das machen könnte.

Jetzt frag ich mich wie ich die Daten am besten senden sollte. Klar durch Komma getrennt hinter einander weg.
Mir fehlt da nur nen halbwegs einheitliches Protokoll.

Ich dachte an sowas wie:
Zeit,Action,Device,Daten

Action könnte sowas wie GET, INFO, SET sein.
Device um einen Befehl auf einem bestimmten Gerät durchzuführen.
Daten dann halt Daten. Wobei man wohl auch die Art der Daten angeben müsste...

Ideen dafür?
 
Zuletzt bearbeitet von einem Moderator:
Also ich stehe vor einem ähnlichen Problem. Bei mir wird es keine Datenbank geben. Eine Serveranwendung auf den Raspi bekommt alles von den Sensoren geschickt, allerdings nur wenb sie die Microcontroller auch fragt. Vielleicht steckt in der Anfrage ja auch kein "gebe mir Temperatur" sondern "mache xy". Ich werde TCP verwenden, denn ich möchte nicht das was an Paketen verloren geht und ne Prüfsumme z. B. CRC möchte ich auch nicht erst anhängen. Als Protokoll könnte ich vielleicht was aus Bytes zusammenstellen, allerdings finde ich es angenehmer einfach JSON's hin und her zu senden und diese auszuwerten. Ist natürlich mehr Traffic. Das ist jetzt vielleicht keine genaue Antwort auf dein Problem, aber zumindest mit JSON eine Alternative. Bedenke auch, dass du eine Verschlüsselung nutzen solltest.
 
Japp, JSON macht da für mich auch mehr Sinn, wenn es um Text als Interface geht. Sind ja nicht nur GPS Daten. Ich weiß nicht ob es auch so etwas wie Datenarrays geben würde. Stell dir das mal vor, wenn alles stumpf kommagetrennt ist. Anfang und Ende zu finden wird kompliziert ;) JSON ist da deutlich flexibler im Customizing. Schreib dir ein JSON Schema für deine Daten, dann hast du was an dem du dich beim Schreiben und Lesen langhangeln kannst.
 
Es gibt auch wirklich gute und einfache JSON Parser. Das ist soweit verbreitet da gibt's auch sicher libs für deine Microcontroller. Wie @german schon geschrieben hat solltest du dir ein sinnvolles Schema überlegen. Paar Ideen dazu hattest du ja schon. Ich persönlich würde von UDP Abstand nehmen. Ich bin auch nur Anfänger, aber ich finde UDP lohnt sich eher wenn wirklich viele Daten kommen wo ein Paketverlust kein Problem darstellt. Streams zum Beispiel. Überlege dir auch wann du Zugriff auf die Daten brauchst. Willst du einfach per eigener App die Temperatur auslesen? Dann reicht es wenn wenn der Controller jede Minute mal nen Paket zum Server schickt. Oder vielleicht manche Abfragen sogar erst wenn du per darauf zugreifst. Selbst wenn du es loggen willst um in 3 Jahren zu schauen wo dein Auto zu welcher welcher Zeit war ist die Messung in Sekunden wohl etwas übertrieben.
 
Eine Serveranwendung auf den Raspi bekommt alles von den Sensoren geschickt, allerdings nur wenb sie die Microcontroller auch fragt.

Meine Sensoren sollen primär selbst die Daten immer raus haun.

allerdings finde ich es angenehmer einfach JSON's hin und her zu senden und diese auszuwerten.

Das ist nicht drin.

Ist natürlich mehr Traffic.

Genau.
Bei nem Serial mit 115200 baud sind das 14400byte/s bei einer maximalen Paketlänge von 80byte sind das 180 Pakete pro Sekunde.

Japp, JSON macht da für mich auch mehr Sinn, wenn es um Text als Interface geht.

Ich denke das das oversized ist.

Ich weiß nicht ob es auch so etwas wie Datenarrays geben würde. Stell dir das mal vor, wenn alles stumpf kommagetrennt ist.

Hmm. Also ich hatte es so gedacht das wenn man jetzt den anrufbeantworter als sensor hat, dann wird einem eine url geschickt für die wav datei. so wollte ich dann größere Datenmengen übertragen. Erstmal geht es eigentlich nur um einzelwerte.
Stromverbrauch wird zb alle 100ms erfasst, wobei ich da nicht jeden einzelwert schicke.

Ich persönlich würde von UDP Abstand nehmen. Ich bin auch nur Anfänger, aber ich finde UDP lohnt sich eher wenn wirklich viele Daten kommen wo ein Paketverlust kein Problem darstellt.

Wenn da mal was verschwindet ist das kein Problem. Ob ich die Daten wie bei upnp einfach mehrmals sende werd ich sehen.

Selbst wenn du es loggen willst um in 3 Jahren zu schauen wo dein Auto zu welcher welcher Zeit war ist die Messung in Sekunden wohl etwas übertrieben.

Man nimmt was man kriegt. Neigungswinkel und G Kräfte werden weitaus öfter geloggt. Wlan ssids weitaus weniger.
 
Du findest JSON oversized, schickst aber Dateien mit darüber? Also ich würde JSON und TCP verwenden. Mehr kann ich dazu leider nicht sagen :)
 
schickst aber Dateien mit darüber?

Hä? Meine Idee bisher war wenn ich eine größere Datei versenden will ich einen Link verschicke. ZB schickt der Anrufbeantworter:
$DevMsg,http://dzdztz.nn/file.wav*00

So richtig Sinnvoll ist mir bisher nur nen Firmware Update eingefallen.

NMEA bietet sich halt gut an weil es die meisten Sensoren da schon gibt. Ich kann die Nachricht gut verpacken. zB einfach über http als get Parameter.
TCP ist nicht nötig weil die Daten oft genug gesendet werden und es da nicht drauf ankommt wenn mal was flöten geht.

Ich hab mir jetzt für die ESP-01 Module nen Satz DHT11 zugelegt. Leider zu einem scheiß Preis, weil der Chinese nicht liefern kann.
Jetzt hab ich 2 Werte. Temperatur und Luftfeuchte. Und für das bisschen soll ich jetzt mit tcp rumspielen? Allein das Akn Paket ist ja mehr als strlen("22.3,43.6")
 
Zurück
Oben Unten