Hi, ich möchte gerne von meinem Raspberry aus die Mess-Ergebnisse über das lokale Netzwerk an andere Teilnehmer im Netz versenden. Das Internet möchte ich dabei nicht in Anspruch nehmen, d.h. es soll auch funktionieren, wenn das Internet nicht funktioniert! Die Nachrichten möchte ich von meinen Windows-PCs, Linux-PCs und Android-Handys empfangen können. Habt ihr einen Tipp, wie ich das realisieren kann?
Gast
#4861114
Bei mir lauft eine Webserver (Apache) auf den Pi. Damit hat jeden Zugang die auch Zugang hat auf das lokales Netzwerk. Internetzugang brauchts du nicht für lokales Verkehr.
Gast
#4861126
Aus deiner Frage geht nicht hervor, wie genau die Nachrichten mit den Messergebnissen aussehen sollen, also ob du da auf ein bestimmtes Format festgelegt bist. Falls nein: Ich nutze dafür MQTT mit Mosquitto auf dem Raspberry Pi. Es gibt für alle relevanten Systeme (Windows, Linux, Android, etc.) Programme, die einem sehr komfortabel den Zugriff auf diese Daten über das lokale Netzwerk ermöglichen.
Grundsätzlich möchte ich bei Alarm eine Nachricht senden, die ih dann am besten auf den verschiedenen Devices im Netzwerk angezeigt bekomme (automatisch, wie per Popup) Ist ein MQTT Server besser/einfacher wie ein Apache Server?
Gast
#4861218
H. C. schrieb: > automatisch, wie per Popup Dann kommst du um eine Anwendung auf den Ziel Systemen nicht herum. Irgendein Programm muss ja das "Popup" erzeugen und die Daten vom Netzwerk lesen
Gast
#4861306
H. C. schrieb: > Grundsätzlich möchte ich bei Alarm eine Nachricht senden, die ih dann am > besten auf den verschiedenen Devices im Netzwerk angezeigt bekomme > (automatisch, wie per Popup) > > Ist ein MQTT Server besser/einfacher wie ein Apache Server? Für den Fall wäre wohl MQTT geeigneter. Wo kommt denn der Alarm her? Selbstgeschriebenes Programm? Wenn man eh selber programmiert, wären eventuell UDP-Broadcastmessages die einfachste Möglichkeit.
Wenn du auf dem Zielsystem eh eine Anwendung brauchst (weil du ja was tun willst (Popup)), dann ist die Wahl des Protokolls auch relativ egal. MQTT ist an sich genau das richtige, aber auch da muss man sich einarbeiten. An und für sich würde aber ein ganz einfaches UDP basiertes Protokoll genauso gut funktionieren (welches an eine Broadcast-Adresse sendet). MQTT könnte dir ein bissl von der Low-Level-Netzwerkprogrammierung (hantieren mit Sockets) abnehmen, aber es wird dir nicht abnehmen einigermaßen zu verstehen was du tust.
Man könnte im eigenen Netzwerk einen E-Mail-Server betreiben, nicht notwendigerweise auf dem RasPi und dorthin die Daten schicken. Jeder, der an den Ergebnissen interessiert ist, abonniert das Postfach. Das Popup erzeugt dann der E-Mail-Client.
Wallhalla schrieb: > H. C. schrieb: >> automatisch, wie per Popup > > Dann kommst du um eine Anwendung auf den Ziel Systemen nicht herum. > Irgendein Programm muss ja das "Popup" erzeugen und die Daten vom > Netzwerk lesen Man könnt ja RSS nutzen. Da sollte es für jedes Zielsystem schon was geben.
Man könnte auch VoIP bzw. SIP benutzen, SMPP, SCTP, IRC, XMPP, SOAP oder über ODBC in eine Oracle SQL-Datenbank schreiben, auf welche alle Clients dann zugreifen. Es gibt soooooo viele Möglichkeiten, und soooo viele davon sind unnötig komplex. Bevor ich mit Technologien wie XML und HTTP (=> RSS) auf so ein Problem schieße, guck ich mir die Größe des Problems an. SMTP ist schon leicht besser, vorallem weil viele Clients es unterstützen. Hängt alles auch immens von der Erfahrung die man mit entsprechenden Technologien hat ab. Wenn man jeden Tag mit HTTP arbeitet, isses trivial. Vorallem weil viele (im Grunde alle) Sprachen mit Bibliotheken kommen und es im Notfall auch einfach selbst implementiert werden kann. Ist halt auch die Frage wie effizient alles sein soll. HTTP und polling sind nicht besonders schonen was Energie-Ressourcen angeht. Also inbes. für mobile Geräte nicht allzu gut (es sei denn, man implementiert long-polling mit HTTP, das lindert das Problem etwas). UDP, sehr low level, leider auch ohne Fehlerkorrektur oder Zuverlässigkeit, bietet dagegen echtes push-notifying, sogar Broadcasts werden unterstützt (sofern es die lokalen Netze zulassen). Ist auch die Frage, ob UDP broadcasts über WLAN auf den mobilen Geräten ankommen - müsste man mal mit experimentieren. Aber es würde erfordern, dass man eine eigene App für das mobile Gerät entwickelt. Also gleich mal das Android SDK runterladen und für 1-2 Monate einarbeiten. Dagegen wirkt HTTP und bissl JavaScript geradezu erfrischend einfach, aber dann muss auch immer der Browser laufen - auch doof. SMTP geht meist gut für mobile Geräte, die haben alle einen Mail-Client mit an Bord. Auf Desktops muss man eben sein Mail-Programm offen haben und/oder als Tray-Icon laufen lassen. Was Einfachheit angeht, gewinnt SMTP wie Georg es vorschlug. Wenn es effizienter sein soll, kann UDP ggf. hilfreich sein, kostet aber mehr eigenen Aufwand. MQTT hat nicht ganz so weite Verbreitung, aber auch hierfür gibts bereits Android Clients (MyMQTT offenbart eine kurze Google-Suche). Ist aber ein Weg, der noch nicht von so extrem vielen Leuten beschritten wurde wie SMTP, aber vergleichsweise mehr als eine eigene UDP-Lösung. PS: MQTT hat natürlich auch den unschlagbaren Vorteil, dass es extra für solche Zwecke entwickelt wurde.
Hallo, vielen Dank für eure Hilfe!! Ich habe mir MQTT mal installiert und denke, dass könnte der beste Weg sein. Nun bin ich noch auf der Suche nach den entspechenden Apps bzw. der entsprechenden Software unter Windows, die die Nachrichten in Empfang nehmen. Als App für Android möchte ich mir "IoT MQTT Dashboard" näher anschauen für Windows hab ich mir "MQTTBox" ansehen. Wichtig wäre mir halt, dass ich auf meinen Devices einen Alarm bekomme und sich das Handy / der Rechner auch wirklich bei mir meldet, so dass ich den Alarm nicht verpasse! Hat wer von euch Erfahrungen mit dem Empfänger?
Gast
#4866244
H. C. schrieb: > Das Internet möchte ich dabei nicht in Anspruch nehmen, d.h. es soll > auch funktionieren, wenn das Internet nicht funktioniert! d.h. wenn du Nicht Zuhause (im Netzwerk) bist verpasst du einen Alarm :) oder siehts in erst wenn du wieder im Netzwerk bist ( falls dann das Netzwerk noch steht...) Ich hoffe das hast du bei deinen Überlegungn bedacht.
imonbln schrieb: > H. C. schrieb: >> Das Internet möchte ich dabei nicht in Anspruch nehmen, d.h. es soll >> auch funktionieren, wenn das Internet nicht funktioniert! > > d.h. wenn du Nicht Zuhause (im Netzwerk) bist verpasst du einen Alarm :) > oder siehts in erst wenn du wieder im Netzwerk bist ( falls dann das > Netzwerk noch steht...) > > Ich hoffe das hast du bei deinen Überlegungn bedacht. Ich nehme an, er meint, dass ganze soll nicht über einen Server "in der Cloud" arbeiten. Sondern der Server soll lokal im LAN stehen. Und auf nen Einbruch-Alarm kann man doch meist eh nie schnell genug reagieren, um etwas sinnvolles zu tun. Holt man die Polizei und es war nachbars Katze, zahlt man noch drauf mit seiner selbst gebastelten Lösung. Das wirkungsvollste gegen Einbruch ist immernoch Absicherung der Zugänge.