Hallo, ich möchte Meßwerte an einen Chat-Server senden, damit wir sie von unterwegs einsehen können. Anzahl Personen in der Gruppe: ca. 3 - 5. Datenvolumen: ca. 10 Zeichen alle 10 Minuten. Vermutlich wird dieses Datenvolumen immer wieder mal für mehrere Stunden beansprucht, es kann aber auch sein, dass wir es mal für mehrere Tage 24/7 benötigen. Ich suchen einen passenden Chat-Client und einen passenden Chat-Server und bitte um Empfehlungen. Optimal wäre ein Chat-Client, den ich im Terminal-Fenster eines Raspberry Pi im Text-Modus ausführen könnte und den ich mit cron über Kommandozeilen-Parameter aufrufen könnte, um einen Meßwert zu veröffentlichen. Ein schönes neues Jahr 2026!
Bei MS Teams kann man Chat-Nachrichten über ein REST-API senden: https://learn.microsoft.com/en-us/graph/api/chatmessage-post?view=graph-rest-1.0&tabs=http Ginge also z.B. per curl, einfaches Python-Script oder jegliche andere Sprache die HTTP-Requests absenden kann. Ein kleines bisschen fummelig ist die Authentifizierung mit Token im Header. Wird wohl Äquivalente für alle gängigen Chat-Systeme geben.
:
Bearbeitet durch User
Zur Verteilung von Messwerten an mehrere Clients ist eigentlich MQTT das System der Wahl. Allerdings ist das erstmal auf Machine-to-Machine-Kommunikation ausgelegt, eben um anhand der Messwerte irgendwie automatisch zu reagieren. Aber es gibt natürlich auch Programme die die Daten passend aufbereiten und einfach lesbar machen. Das hätte den Vorteil dass sowohl Mensch als auch Maschine an die Daten kommen, je nach Bedarf. Wenn es wirklich rein um Chat-Kommunikation geht, und z.B. die Teilnehmer Kommentare zu den Werten posten wollen oder ähnliches, wäre natürlich auch noch Matrix oder das altgediente IRC eine Überlegung Wert. Mir scheint aber MQTT für Messwerte besser geeignet.
Jabber/XMPP oder evtl. MQTT. Man muss keinen eigenen Server einrichten, es sind genug (kosten)freie Server verfügbar. Außerdem viele Clients auf allen Systemen/Oberflächen.
Gerd E. schrieb: > Mir scheint aber MQTT für Messwerte besser geeignet. Würde ich grundsätzlich auch denken. Man könnte einen MQTT-Broker "in der Cloud" laufen lassen, und einen weiteren Daemon/Dienst der die Daten vom MQTT-Broker empfängt und dann an den gewünschten Chat-Dienst weiterleitet. Dann kann man beliebige weitere Dienste zur Verarbeitung der Daten dazu schnallen ohne das IoT-Gerät anfassen zu müssen. Hat auch den Vorteil dass MQTT auf sehr einfachen Endgeräten funktioniert. Aber: Da das IoT-Gerät ja ein Raspberry-PI und damit ziemlich leistungsfähig ist, kann man problemlos direkt Chat-Nachrichten per REST-API abschicken und ggf. parallel noch per MQTT oder irgendwie anders verarbeiten. Also einfach direkt die Chat-Nachrichten per REST-API abzuschicken ist kein schlechter Start. Wenn man sich erstmal in Teams/Sharepoint eingeklinkt hat könnte man die Daten auch per REST-API direkt in eine Excel-Tabelle auf dem Sharepoint reinkippen oder sonstige Schweinereien basteln...
> Datenvolumen: ca. 10 Zeichen alle 10 Minuten
Das geht im Grundrauschen unter, bzw. der HTTP-Request mit seinem Header
ist deutlich länger, aber dieses Volumen ist praktisch gar nichts.
Es wäre nett, wenn wir die Meßwerte kommentieren könnten. Und sei es auch nur, um zu vereinbaren, dass wir es für diesmal gut sein lassen. :-) Bei den Meßwerten handelt es sich übrigens nur um ASCII-Zeichen, Textformatierung o. ä. ist überflüssig.
Es gibt Telegram-Bots mit API. Dann können alle in einer Telegram-Gruppe die Messwerte sehen/kommentieren und sogar Aktionen in die andere Richtung ausführen. Hab ich mal für ein bisschen Automatisierung in NodeRED gemacht, ging echt gut.
:
Bearbeitet durch User
Telegram kann ich ebenfalls dafür empfehlen: Es gibt z.B. Telegram-Clients in Python oder auch eine openHAB-Integration. Damit kann man ne Menge basteln. Ich empfehle, den Zugriff auf den "ChatBot" auf die Telegram-IDs der erlaubten Geräte einzuschränken, da man den chatBot problemlos mit der Telegram-Suche finden kann.
Michael schrieb: > ich möchte Meßwerte an einen Chat-Server senden, damit wir sie von > unterwegs einsehen können. Anzahl Personen in der Gruppe: ca. 3 - 5. > Datenvolumen: ca. 10 Zeichen alle 10 Minuten. Vermutlich wird dieses > Datenvolumen immer wieder mal für mehrere Stunden beansprucht, es kann > aber auch sein, dass wir es mal für mehrere Tage 24/7 benötigen. Ich > suchen einen passenden Chat-Client und einen passenden Chat-Server und > bitte um Empfehlungen. Optimal wäre ein Chat-Client, den ich im > Terminal-Fenster eines Raspberry Pi im Text-Modus ausführen könnte und > den ich mit cron über Kommandozeilen-Parameter aufrufen könnte, um einen > Meßwert zu veröffentlichen. Vermutlich habe ich noch nicht alles ganz genau verstanden, daher... Also, Du hast Meßdaten, die irgendwie irgendwo anfallen. Was genau passiert mit denen -- werden sie in eine beliebige Art von Datenbank geschrieben oder ist das nur ein einfacher Datenstrom, bei dem die Daten verloren gehen, wenn niemand sie gelesen oder abgeholt hat? Außerdem ist meine nächste Frage, wie Du Dir so einen Chat vorstellst. Sollen dort einfach Textdaten hineingeschrieben, sollen dort schicke Plots gezeichnet werden, oder eventuell auch beides? Woher kommt die Idee mit dem Terminal des RasPi -- bist Du (wie ich) ein Kommandozeilenfreund oder ist Dir gerade keine andere / bessere Lösung eingefallen, vielleicht weil in Deinem Setup ohnehin bereits ein RasPi vorhanden ist? Was den Chat angeht, würde ich vermutlich zuerst an einen kleinen Webservice mit Server-Sent Events [1] denken. Dadurch kommen die Daten jeweils als Event beim Webbrowser an, der sie mit ein paar Zeilen JavaScript verarbeiten kann und daraus beispielsweise hübsche (auch interaktive) Plots zeichnen, oder die Werte auch ganz einfach ausgeben kann. Wenn Du ein Terminal haben möchtest: natürlich kann man auch simple Terminal-Clients für SSE schreiben. [1] https://developer.mozilla.org/de/docs/Web/API/Server-sent_events/Using_server-sent_events [2] https://www.w3schools.com/html/html5_serversentevents.asp
Oder Du sammelst die Messwerte über eine Stunde und hängst die hundert Zeichen hier in dem Thread an. ;)
Gerd E. schrieb: > Zur Verteilung von Messwerten an mehrere Clients ist eigentlich MQTT das > System der Wahl. Hm, MQTT scheint sich langsam zu einer ähnlichen Pest für Message Queues und PubSub zu entwickeln, wie es SQL beim Speichern von Daten ist. Leute! Es gibt viel mehr als nur MQTT! Die Welt ist groß, und besteht nicht nur aus SQL und MQTT. Es gibt auch Redis (und Klone), PostgreSQL (dort heißt PubSub nur anders), und sogar richtig coole Sachen wie ZeroMQ!
Ein T. schrieb: > Was den Chat angeht, würde ich vermutlich zuerst an einen kleinen > Webservice mit Server-Sent Events [1] denken. Michael schrieb: > Es wäre nett, wenn wir die Meßwerte kommentieren könnten. Dann böten sich ebenfalls SSE, oder möglicherweise auch eine bidirektionale Kommunikation mit WebSockets [1,2] an. [1] https://developer.mozilla.org/de/docs/Web/API/WebSocket [2] https://websocket.org/
Ein T. schrieb: > MQTT scheint sich langsam zu einer ... Pest für Message Queues und > PubSub zu entwickeln Wieso Pest? Darf nicht jeder für sich entscheiden, welche Software er bevorzugt? Redis ist übrigens auch nicht der Weisheit letzter Schluss, z.B. weil es nicht garantieren kann, daß niemals Messages verloren gehen. Kafka hingegen kann das. Und dann gibt's noch das ätzende Lizenz Thema.
:
Bearbeitet durch User
Telegramm Bot ist echt easy. Da reicht selbst ein uC um eine Nachricht zu versenden. Also mit Raspi gar kein Problem.
Michael schrieb: > ich möchte Meßwerte an einen Chat-Server senden, damit wir sie von > unterwegs einsehen können. Anzahl Personen in der Gruppe: ca. 3 - 5. Habt ihr denn schon eine eigene gemeinsame Chat-Plattform? Dann würde ich zuallererst versuchen, die zu verwenden anstatt was Neues einzuführen. Der Google-Firmen-Chat, Teams, Slack, Telegram, Discord, RocketChat usw. geben sich da nicht viel, so ziemlich überall hast du die Möglichkeit per simplem HTTP-Post eine Nachricht abzusetzen. Schimpft sich nur bei jedem anders, mal "Integration", mal "Bot", mal "Webhook"...
Nemopuk schrieb: > Ein T. schrieb: >> MQTT scheint sich langsam zu einer ... Pest für Message Queues und >> PubSub zu entwickeln > > Wieso Pest? Darf nicht jeder für sich entscheiden, welche Software er > bevorzugt? Weil die Auswahl dieser Software häufig nicht auf einer seriösen Auswahl, sondern auf Reflexen basiert. Daten übertragen? MQTT! Daten speichern? SQL! (Und SQL heißt bei unseren einfacher gestrickten Mitmenschen leider häufig: SQLite.) So finden Fragende sich am Ende mit Mosquitto und SQLite wieder, während PostgreSQL beides kann und außerdem ein richtiges RDBMS mit MVCC, Berechtigungskonzept und mehr ist, statt kaputtem Flatfile-Firlefanz. Schau, mir persönlich ist es ziemlich gleichgültig, wie, warum, und womit Leute sich selbst unglücklich machen. Aber dabei belassen sie es ja nicht, sondern empfehlen ihre Lösungen auch allen anderen, häufig ganz unabhängig davon, ob es zum Anwendungsfall paßt oder ob sie den überhaupt kennen. So breitet es sich dann aus, wie eine Seuche, deswegen: "Pest". > Redis ist übrigens auch nicht der Weisheit letzter Schluss, z.B. weil es > nicht garantieren kann, daß niemals Messages verloren gehen. Und das garantiert MQTT? Überraschung: nein, tut es nicht. Gerade bei Meßdaten (wie hier, nicht wahr, Du weißt schon: Anwendungsfall!) ist es allerdings meistens kein Problem, einen oder zwei von n Millionen Datenpunkten zu verlieren. Aber wenn wirklich eine Anforderung ist, daß das auch bei Ausfällen kein Datenpunkt verloren gehen darf, ist das ein Fall, wo Redis PubSub nicht so gut paßt wie Redis Streams (oder andere MQ- und PS-Implementierungen, an denen ja beileibe kein Mangel herrscht). Dabei bestreite ich keineswegs, daß es valide Anwendungsfälle für MQTT gibt. Ich bestreite, daß MQTT IMMER und für ALLE Anwendungsfälle sinnvoll ist, und nenne ein paar Alternativen dazu. Ich spreche nicht gegen MQTT, sondern für informierte und reflektierte Entscheidungen, passend zum Anwendungsfall. > Kafka hingegen kann das. Andere -- wie etwa Redis Streams oder ZeroMQ -- können das auch.
Ein T. schrieb: > o finden Fragende sich am Ende mit > Mosquitto und SQLite wieder, während PostgreSQL beides kann Hast du eine "Fallstudie" zur Implementation eines PostgreSQL-Clients auf einem IoT-Gerät, z.B. einem ESP32?
Niklas G. schrieb: > Ein T. schrieb: >> o finden Fragende sich am Ende mit >> Mosquitto und SQLite wieder, während PostgreSQL beides kann > > Hast du eine "Fallstudie" zur Implementation eines PostgreSQL-Clients > auf einem IoT-Gerät, z.B. einem ESP32? Natürlich, und sogar eine Library für Embedded-Umgebungen: [1]. Außerdem gibt es den offiziellen C-Client [2], eine riesige Anzahl von Treibern und Clients [3,4], sowie die Dokumentation des Protokolls [5]. Der TO schrieb allerdings von einem Raspberry Pi, und ich hatte ausdrücklich um weitere Informationen zum Anwendungsfall gebeten. Hast Du sonst noch "kluge" Fragen? [1] https://github.com/ethanak/SimplePgSQL [2] https://www.postgresql.org/docs/current/libpq.html [3] https://wiki.postgresql.org/wiki/List_of_drivers [4] https://wiki.postgresql.org/wiki/PostgreSQL_Clients [5] https://www.postgresql.org/docs/current/protocol.html
Ein T. schrieb: > Hast Du sonst noch "kluge" Fragen? Beantworte doch mal meine erste Frage, nämlich nach einer Fallstudie, nicht nach Libraries. Also konkrete Anwendung inklusive Erfahrungsberichten wie gut/effizient das funktioniert, gern auch im Vergleich mit MQTT. Über SimplePgSQL hab ich nur irgendwo gelesen dass das Read-Only ist.
Niklas G. schrieb: > Ein T. schrieb: >> Hast Du sonst noch "kluge" Fragen? > > Beantworte doch mal meine erste Frage, nämlich nach einer Fallstudie, Also nicht. Ich bin übrigens nicht hier, um Deine Hausaufgaben zu machen.
Hallo, ich möchte meine Vorstellungen konkretisieren. Ich habe einen RPi mit dem Standard-Betriebssystem RPi-OS, den ich in C programmiere. (gcc, geany) Meine Programme laufen in einem Terminal- / Shell-Fenster im Text-Modus, ich benutze keine GUIs. Ein typischer Anwendungsfall für mich wäre ein Multimeter, dass ich über ein RS232-USB-Interface an den RPi angeschlossen habe. Ich empfange seine Daten in einer select ()-Schleife. Das Multimeter sendet seine Daten alle 400 ms, was mir viel zu schnell ist. Deshalb wähle ich alle 10 min einen Meßwert aus, den ich nach Plausibilitätskontrolle über IRC veröffentlichen möchte. In meiner Naivität stelle ich mir das so vor, dass ich über system () einen IRC-Client mit Kommandozeilen-Parameter aufrufe, der das dann für mich erledigt. Falls nötig, könnte ich evt. auch einen IRC-Client über die Umleitung von stdin und stdout ansprechen. (redirection) Auf einem anderen System (Handy, PC, o. ä.) können meine Bastelfreunde und ich die Meßwerte anschauen und ggf. kommentieren. Wenn wir uns dahingehend verständigen, gehe ich in den Hobbyraum und ändere Sollwerte oder schalte den Versuch ab. Im Moment dürfte die Versuchsdauer wohl kaum eine Stunde betragen. Dies könnte sich jedoch ändern, möglicherweise läuft der Versuch dann mit stark veringerter Publikationsfrequenz auch einige Tage bis Wochen. Uns reicht, wenn wir die Meßwerte im Textformat einsehen können. Falls wir sie abspeichern möchten, könnte das lokal auf dem RPi geschehen. Eine Versendung von Grafiken ist nicht vorgesehen. Falls wir uns entschließen sollten, unsere Meßwerte zu dokumentieren, würde ich das ebenfalls lokal machen und dann meinen Freunden per E-Mail zusenden. Im Moment ist nicht vorgesehen, Daten über den IRC-Client zu empfangen und beispielsweise als Sollwerte zu verwenden, aber auch das könnte sich ändern. Ich habe mal im Repository geschaut, dort gibt es einen "simple IRC client" sic zum herunterladen. Aber auch ii - ii (irc it) is a minimalist FIFO and filesystem-based IRC client. Ich weiß nicht, ob diese Programme für meine Zwecke einsetzbar sind, habe aber das Gefühl, das "richtige" IRC-Clients wie irssi oder hexchat für meine Zwecke völlig oversized oder ungeeignet sind. Da ich noch keine Erfahrungen mit IRC gesammelt habe, weiß ich auch nicht, was für einen IRC-Server ich für meine Anwendung wählen sollte. Wie gesagt - für Empfehlungen wäre ich dankbar.
Eine verrueckte Idee nach der anderen... Unter den keep-it-simple-Loesungen hat noch keiner genannt: - Ganz basic: nc/socat, screen, textdatei, ssh-login - rrdtool fuer etwas mehr Round Robin - Online-Services wie thingspeak (wenn deine Messdaten nicht hochgeheim sind) Du musst dich hier also nur um einen Bot kuemmern, der auf irgend einen Port per TCP Daten im Klartext reinstreamt und sich allenfalls selbsttaetig einloggen kann. Das kann schon ein bash-script, netter geht das in Python. Einen einfachen Telnet-Chatserver (*.c, aus dern fruehen 90ern) koennte ich dir schon zustellen, dagegen spricht allenfalls die 'security by obscurity', aber man kann alles pragmatisch durch ssh (putty unter Windows) tunneln.
Michael schrieb: > In meiner Naivität stelle ich mir das so vor, dass ich über system () > einen IRC-Client mit Kommandozeilen-Parameter aufrufe Geht grundsätzlich schon so, aber ist IRC das richtige System dafür? In Anbetracht der Tatsache, dass es jede Menge modernere Chatsysteme gibt, deren Clients auf so gut wie jedem Smartphone schon installiert sind, und dass die mit recht simplen HTTP-Requests gefüttert werden können, scheint mir IRC nicht so besonders sinnvoll. IRC braucht ja immer eine recht fummelige Konfiguration, umständliche Authentifizierung, ist oft nicht verschlüsselt, und jeder Verbindungsaufbau dauert eine ganze Weile; ein typischer REST-HTTP-Request erledigt das alles in einem und das auch recht fix.
Michael schrieb: > In meiner Naivität stelle ich mir das so vor, dass ich über system () > einen IRC-Client mit Kommandozeilen-Parameter aufrufe, der das dann für > mich erledigt. Wie gesagt, das ist bei "modernen" Chat-Systemen viel einfacher.
1 | curl -H 'Content-Type: application/json' -d '{"text": "Der Messwert ist 12.34"}' <WEBHOOK_URL>
|
Funktioniert so oder so ähnlich fast überall. Die WEBHOOK_URL kriegst du beim Einrichten (da wird dann festgelegt, in welche Gruppe gesendet wird usw) Das ganze kannst du natürlich in einen system()-Aufruf packen, für eine Quick-n-Dirty Lösung. Oder du hast eh Bibliotheken im Einsatz, die HTTP enthalten. Oder du verwendest libcurl direkt.
1 | #include <curl/curl.h> |
2 | ...
|
3 | curl_global_init(CURL_GLOBAL_ALL); |
4 | CURL * curl = curl_easy_init(); |
5 | |
6 | // snprintf...
|
7 | const char * json_data = "{\"text\": \"Ihr Messwert hier\"}"; |
8 | |
9 | struct curl_slist * headers = NULL; |
10 | headers = curl_slist_append(headers, "Content-Type: application/json"); |
11 | |
12 | curl_easy_setopt(curl, CURLOPT_URL, "https://..../"); |
13 | curl_easy_setopt(curl, CURLOPT_POSTFIELDS, json_data); |
14 | curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers); |
15 | |
16 | res = curl_easy_perform(curl); |
Mehr zu tippen, aber sauberer/schneller als da nochmal eine Shell mit Parameter-Parsing usw. dazwischen zu hängen.
Michael schrieb: > ich möchte meine Vorstellungen konkretisieren. Hm, ich habe Deine Ausführungen jetzt dreimal gelesen und die Fragezeichen in meinem Kopf werden leider eher mehr als weniger. > Ich habe einen RPi mit dem Standard-Betriebssystem RPi-OS, den ich in C > programmiere. (gcc, geany) Meine Programme laufen in einem Terminal- / > Shell-Fenster im Text-Modus, ich benutze keine GUIs. Okay... allerdings: Geany ist meines Wissens ein GUI-Editor, oder? > Ein typischer Anwendungsfall für mich wäre ein Multimeter, dass ich über > ein RS232-USB-Interface an den RPi angeschlossen habe. Ich empfange > seine Daten in einer select ()-Schleife. Das Multimeter sendet seine > Daten alle 400 ms, was mir viel zu schnell ist. Deshalb wähle ich alle > 10 min einen Meßwert aus, den ich nach Plausibilitätskontrolle über IRC > veröffentlichen möchte. Wenn Du diesen Meßwert wie auch immer über einen Internet Relay Chat (IRC) veröffentlichst, dann sehen ihn die, die in diesem Moment im Channel sind. Alle, die den Channel erst danach betreten, sehen den Wert nicht, und sie müssen dann bis zu zehn Minuten auf den nächsten Wert warten. Zudem benötigst Du für dieses Modell zunächst einen Server mit einem Channel, in den Du Deine Daten schreiben kannst und in den Deine Benutzer gehen können, um die Werte zu empfangen. Es gibt öffentliche IRC-Server, da mußt Du Dir also erst einen suchen, ... Mir ist auch noch nicht ganz klar, wie der Meßwert von Deinem Sensor -- dem Multimeter -- in den RasPi kommen soll. Du schreibst etwas von RS232-USB -- hat Dein Multimeter ein RS232-Interface und das willst Du über einen Adapter die Daten am USB-Port des RasPi empfangen? Und von den Werten, die dann dort ankommen, soll wiederum nur jeder 25. verwendet, über system(3) als Parameter an ein Kommandozeilenprogramm übergeben und davon dann auf einen IRC-Server in einen eigenen Channel gepostet werden? > In meiner Naivität stelle ich mir das so vor, dass ich über system () > einen IRC-Client mit Kommandozeilen-Parameter aufrufe, der das dann für > mich erledigt. Falls nötig, könnte ich evt. auch einen IRC-Client über > die Umleitung von stdin und stdout ansprechen. (redirection) Also ein C-Programm, um letztlich einen Datenpunkt in einen String zu packen und den dann mit system(3) in einer Shell auszuführen... warum willst es Dir unnötig kompliziert machen? > Auf einem anderen System (Handy, PC, o. ä.) können meine Bastelfreunde > und ich die Meßwerte anschauen und ggf. kommentieren. Wenn wir uns > dahingehend verständigen, gehe ich in den Hobbyraum und ändere Sollwerte > oder schalte den Versuch ab. Im Moment dürfte die Versuchsdauer wohl > kaum eine Stunde betragen. Dies könnte sich jedoch ändern, > möglicherweise läuft der Versuch dann mit stark veringerter > Publikationsfrequenz auch einige Tage bis Wochen. Ja, äh, nein. Ihr könnt Euch den Meßwert ansehen, also: wenn denn einer angekommen ist. Und während Ihr Euch den Meßwert anschaut, könnt Ihr auf den nächsten warten, der kommt dann in zehn Minuten. :-) > Uns reicht, wenn wir die Meßwerte im Textformat einsehen können. Falls > wir sie abspeichern möchten, könnte das lokal auf dem RPi geschehen. > Eine Versendung von Grafiken ist nicht vorgesehen. Falls wir uns > entschließen sollten, unsere Meßwerte zu dokumentieren, würde ich das > ebenfalls lokal machen und dann meinen Freunden per E-Mail zusenden. Bei meinem Vorschlag ging es nicht um das Versenden von Grafiken, sondern vielmehr darum, sie on-the-fly zu erzeugen, zum Beispiel mit sowas [1,2]. Diese Plots werden nicht als Grafiken erzeugt, sondern vom Webbrowser aus Daten gezeichnet. Damit das beim Öffnen halbwegs anständig aussieht, sind natürlich ältere Meßdaten... [1] https://www.flotcharts.org/flot/examples/series-types/index.html [2] http://www.jqplot.com/examples/area.php > Im Moment ist nicht vorgesehen, Daten über den IRC-Client zu empfangen > und beispielsweise als Sollwerte zu verwenden, aber auch das könnte sich > ändern. Du möchtest also langfristig eventuell etwas einstellen... auch dafür würde sich eine moderne Lösung mit HTTP und HTML meines Erachtens sehr viel eher anbieten als ein Chatserver mit Nachrichten in Freitext. Außerdem läßt sich eine solche Lösung viel leichter gegen unberechtigte Zugriffe absichern. Und dann ist noch die Frage, wie die Werte zu den Aktoren kommen sollen... :-) > Ich habe mal im Repository geschaut, dort gibt es einen "simple IRC > client" sic zum herunterladen. Aber auch ii - ii (irc it) is a > minimalist FIFO and filesystem-based IRC client. Ich weiß nicht, ob > diese Programme für meine Zwecke einsetzbar sind, habe aber das Gefühl, > das "richtige" IRC-Clients wie irssi oder hexchat für meine Zwecke > völlig oversized oder ungeeignet sind. > > Da ich noch keine Erfahrungen mit IRC gesammelt habe, weiß ich auch > nicht, was für einen IRC-Server ich für meine Anwendung wählen sollte. > Wie gesagt - für Empfehlungen wäre ich dankbar. Wie Du vielleicht aus dem ersehen kannst, was ich oben geschrieben habe, halte ich IRC grundsätzlich für einen Irrweg und empfehle stattdessen HTTP für die Datenübertragung und HTML für die Darstellung. Dafür findest Du auch sehr viel leichter eine passende Serverkomponente sowie einen Ort, wo sie laufen kann, und einen Webbrowser als Client für den Zugriff darauf findest Du heute auf jedem Mobiltelefon, Tablet oder Computer. Nur mal so als Nebenfrage: wollt Ihr den Anbau von Pflanzen überwachen? :-)
Michael schrieb: > Ein typischer Anwendungsfall für mich wäre ein Multimeter, dass ich über > ein RS232-USB-Interface an den RPi angeschlossen habe. Ich empfange > seine Daten in einer select ()-Schleife. Das Multimeter sendet seine > Daten alle 400 ms, was mir viel zu schnell ist. Deshalb wähle ich alle > 10 min einen Meßwert aus, den ich nach Plausibilitätskontrolle über IRC > veröffentlichen möchte. > > In meiner Naivität stelle ich mir das so vor, dass ich über system () > einen IRC-Client mit Kommandozeilen-Parameter aufrufe, der das dann für > mich erledigt. Hmm, mir scheint das unnötig unpraktisch zu bedienen. Mal ne ganz andere Idee: Häng an Deinen Raspi ne Kamera und nen Taster. Du drückst den Taster und das aktuelle Bild von der Kamera wird in Deinen Chat hochgeladen. Die Kamera kannst Du auf das Multimeter richten, oder mit einem Handgriff auf Deine Verkabelung, eine Skizze mit Deinen Ideen, das Oszi oder, wer es mag, die Pflanzen die Ein T. oben anbauen will. ;) Da brauchst Du weder mit Wandlern, Shell oder sonstwas rummachen. Nen paar Kumpel von mir spielen mit sowas ähnlichem ihre Boardgames mit kleinen Figuren etc. Die verwenden dafür Discord-Videos. > Auf einem anderen System (Handy, PC, o. ä.) können meine Bastelfreunde > und ich die Meßwerte anschauen und ggf. kommentieren. Was verwendet Ihr da bisher für ein Chat-System? Da würde ich das anbinden.
:
Bearbeitet durch User
Ich kann hier auch Telegram empfehlen. Ich selber nutze das seit bestimmt 10 Jahren schon für meine Heimautomation. Damals war Telegram das einzige System, welches meine Anforderungen erfüllte. Ich kann darüber mittlerweile alles steuern, z.B. die Wärmepumpe, die Lüftungsanlage, Beleuchtung, Rolläden, Garagentor, etc. Auch kann ich Diagramme mit den wichtigsten Werten auf Anforderung erhalten. Warnmeldungen laufen auch darüber. Die Bot API ist ziemlich umfangreich und läßt auch einfach Interaktion zu. Die vielen Features kann man ja auf der Homepage nachlesen, insbesondere die Bot-API: https://core.telegram.org/bots/api Die Kommunikation läuft über https, es werden GET und POST unterstützt. Die Parameter werden über folgende Methoden übertragen: - URL query string - application/x-www-form-urlencoded - application/json (ausser für File-Upload) - multipart/form-data (für File-Upload) Aber um zu zeigen, wie trivial Telegram für diesen Anwendungszweck ist, hier ein Beispiel. Zuerst in Telegram einen neuen Bot erzeugen:
1 | /newbot |
Dann gibt man den Namen für den Bot und einen Usernamen ein. Man bekommt daraufhin den Access Token für die HTTP API. Hier ein kleines Bash Script für den Versand einer Nachricht, eines Bildes und eines Dokuments:
1 | #!/bin/bash
|
2 | # Export Token
|
3 | export TELEGRAM_TOKEN="[Token vom Bot]" |
4 | |
5 | # Export Chat ID
|
6 | export TELEGRAM_CHAT_ID=$( |
7 | curl https://api.telegram.org/bot${TELEGRAM_TOKEN}/getUpdates | |
8 | jq '.result[0].message.chat.id' |
9 | )
|
10 | |
11 | # Send Message
|
12 | curl -X POST \ |
13 | -H "Content-Type:multipart/form-data" \ |
14 | -F chat_id=$TELEGRAM_CHAT_ID \ |
15 | -F text="Hallo Michael" \ |
16 | https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage |
17 | |
18 | # Send Picture
|
19 | curl -X POST \ |
20 | -H "Content-Type:multipart/form-data" \ |
21 | -F chat_id=$TELEGRAM_CHAT_ID \ |
22 | -F photo=@"test.png" \ |
23 | https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendPhoto |
24 | |
25 | # Send Document
|
26 | curl -X POST \ |
27 | -H "Content-Type:multipart/form-data" \ |
28 | -F chat_id=$TELEGRAM_CHAT_ID \ |
29 | -F document=@"test.pdf" \ |
30 | https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendDocument |
Wie man sieht, ist das ziemlich trivial. Im genannten Anwendungsfall könnte also auch "on the fly" ein Diagramm der Messwerte erstellt und verschickt werden. Oder die Messwerte als csv-Datei.
Ein T. schrieb: > auch dafür > würde sich eine moderne Lösung mit HTTP und HTML Wie lange gibt es AJAX schon? Ich bin mir nicht sicher, ob reines HTML modern ist... Und dazu muss es irgendwo gehostet werden. Wenn es auf dem Pi läuft, braucht es VPN oder etwas mehr Gehirnschmalz für die Zugangssicherung. Ein T. schrieb: > Chatserver mit Nachrichten in Freitext. Ich kann mal wieder aus eigener Erfahrung nur von Telegram berichten, aber andere Systeme können das sicher auch: Telegram-Bots können festgelegte, benutzerdefinierte Befehle und sogar Buttons mit benutzerdefinierten Aktionen haben. Damit wären Dinge wie "Hole Messwert", "Licht an/aus" einfach über Buttons im Chat möglich und mit
1 | /settemperature 25.6 |
ließe sich zum Beispiel ein Sollwert setzen. Hier sieht man, wie das aussehen könnte: https://core.telegram.org/bots/features#commands Dazu gibt es eine sehr gute Python-Lib: https://github.com/python-telegram-bot/python-telegram-bot Und ich als NodeRED-Fan nutze das hier: https://flows.nodered.org/node/node-red-contrib-telegrambot
Hallo, alle Kommentatoren scheinen sich darin einig, dass meine Idee, Meßwerte über IRC zu veröffentlichen, nicht besonders sinnvoll ist. Akzeptiert. Wenn ich das richtig begriffen habe, wird mir statt dessen ein Web-Hoster empfohlen, auf dem ich eine Art "Homepage" zur Veröffentlichung der Meßwerte betreiben soll. Ich hatte vor vielen Jahren bereits eine solche "Homepage", wobei ich den "Content" in Form von html-Dateien mit ftp hochgeladen habe. Ich nehme an, dass das nicht mehr zeitgemäß ist. Fragen: Habe ich es richtig verstanden? Und wenn ja - wie macht man das heute und welchen kostengünstigen Web-Hoster kann man mir dafür empfehlen? Zu den Meßgeräten: ich habe Multimeter mit RS232- und USB-Interfaces, die ich an meinen RPi anschließe und in einer select-Schleife auslese. Zum Versuch: wir sind Bastler, haben ein kaputtes Gerät geschenkt bekommen, es repariert (?) und fragen uns, ob es funktioniert.
Einfach einen IRC Server nutzen, selbstgehostet oder nicht.
Nachtrag: Ich habe meinen letzten Beitrag geschrieben, während hier Telegram thematisiert wurde. Ich frage mich, ob mein Beitrag mit der Home-Page und dem Web-Hoster dadurch überhaupt noch sinnvoll ist. Mir scheint, ich sollte vor einem neuen Beitrag vielleicht besser abwarten, bis sich die Profis hier untereinander auf eine Empfehlung für mich verständigt haben. Vielen Dank für euer Engagement und euer zur Verfügung stellen eures Know-Hows! Ich glaube, ich sollte mich womöglich in der nächsten Zeit vielleicht besser aufs Lesen beschränken - ich bin nicht raus, auch wenn ich gerade keine Beiträge mehr schreibe!
Installier Dir doch schnell Telegram und probier mein Beispiel aus. Keine 10 Minuten Aufwand. Dann weisst Du schnell, ob diese Variante für Dich in Frage kommt. Die aufwendigeren Sachen kannst Du dann später probieren, falls Du Dich gegen Telegram entscheidest.
Michael schrieb: > bis sich die > Profis hier untereinander auf eine Empfehlung für mich verständigt > haben. Da gibt's nicht viel zu verständigen, bis du Details rausrückst. Die Aufgabe selber ist trivialst simpel, wenn du eine der aktuell etablierten Chat-Plattformen verwendest. Um in's Detail zu gehen, müssen wir wissen, welche Plattform es denn nun werden soll. Wenn du und deine Kollegen sowieso 24/7 in einem Discord sind, macht es wenig Sinn dir Microsoft-Teams zu empfehlen. Wenn ihr sowieso von der Arbeit her gemeinsam Slack benutzt, macht es keinen Sinn Telegramm zu empfehlen. Wenn in der Gruppe ein Google-Totalverweigerer ist, ist der Google-Chat keine Option. Wenn für euch dieses ganze "Internet"-Dings Neuland ist, und die Schnittmenge eurer Chat-Systeme leer ist, schaut euch Telegramm mal an. Wenn ihr aus politischen/moralischen Gründen kein Telegramm wollt, dann vielleicht Signal(*)? Wenn es unbedingt self-hosted sein soll, weil hoch-geheime Daten und Diskussionen: RocketChat in der Community Edition. Und wenn es unbedingt IRC sein soll, weil "das hat Opa schon genutzt, das muss gut sein", dann installier dir halt einen IRC-Server. *) Signal ist wegen der vollständigen End-To-End Verschlüsselung nicht so einfach per HTTPs anzusprechen, weil das Klartext-Zugriff am Endpunkt erlauben würde. Da gibt's aber Kommandozeilen-Tools.
Michael schrieb: > alle Kommentatoren scheinen sich darin einig, dass meine Idee, Meßwerte > über IRC zu veröffentlichen, nicht besonders sinnvoll ist. Akzeptiert. > > Wenn ich das richtig begriffen habe, wird mir statt dessen ein > Web-Hoster empfohlen, auf dem ich eine Art "Homepage" zur > Veröffentlichung der Meßwerte betreiben soll. Das ist im Wesentlichen meine Empfehlung; andere Teilnehmer des Threads haben hingegen verschiedene Messenger wie beispielsweise Telegram. Jede Lösung hat jeweils ihre eigenen Vor- und Nachteile: HTTP und HTML: - Vorteil: zum Abrufen der Daten reicht ein Webbrowser - Nachteil: Du brauchst Webspace, auf dem Du Programme ausführen kannst Messenger (Telegram, Signal, ...): - Vorteil: Du brauchst keinen Webspace und keinen Server - Nachteil: jedes zugreifende Gerät muß den Messenger haben IRC: - Vorteil: Du brauchst keinen Server - Nachteil: das zu implementieren ist nicht trivial > Ich hatte vor vielen Jahren bereits eine solche "Homepage", wobei ich > den "Content" in Form von html-Dateien mit ftp hochgeladen habe. Ich > nehme an, dass das nicht mehr zeitgemäß ist. Unverschlüsseltes FTP ist nicht mehr zeitgemäß, aber verschlüsseltes FTPS und FTP über verschlüsselte SSH-Verbindungen sind es durchaus, und auch HTML ist natürlich -- vermutlich in einer neueren Version als damals, heute verwenden wir bevorzugt HTML5 -- immer noch aktuell. Das Problem: HTML-Dateien sind statische Dateien, die keine Daten verarbeiten können. Eine webbasierte Lösung würde allerdings genau das benötigen -- es sei denn, Du möchtest für jeden neuen Datensatz ein neues HTML-Dokument erzeugen und hochladen. Allerdings ist so ein HTML-Dokument mindestens 52 Bytes groß, was mir als "Verpackung" von lediglich vier Byte Nutzdaten (Dein Meßwert) ein bisschen ineffizient zu sein scheint. > Fragen: Habe ich es richtig verstanden? Und wenn ja - wie macht man das > heute und welchen kostengünstigen Web-Hoster kann man mir dafür > empfehlen? Naja, wenn Du -- was ich sehr empfehle -- auf die "Lösung" mit HTML-Dateien verzichtest, brauchst Du Webspace, auf dem Du etwas ausführen kannst -- und was Du da vorhast, geht auch mit dem billigsten Webspace, der PHP kann, den gibt es zum Beispiel bei Strato schon für einen Euro monatlich (wobei Strato nicht meine Empfehlung wäre, aber für einen begrenzten Zeitraum und wenn man unbedingt sparen möchte...). > Zu den Meßgeräten: ich habe Multimeter mit RS232- und USB-Interfaces, > die ich an meinen RPi anschließe und in einer select-Schleife auslese. Der Systembefehl select(2) ist keine Schleife, sondern ein Multiplexer (der allerdings häufig in Schleifen benutzt wird). select(2) benötigt man auch nur, um mehrere Dateideskriptoren zu "belauschen" und darauf zu warten, daß darauf Daten gelesen oder geschrieben werden können. Heute gilt select(2) jedoch als veraltet und es wird empfohlen, poll(2) oder epoll(7) zu verwenden. > Zum Versuch: wir sind Bastler, haben ein kaputtes Gerät geschenkt > bekommen, es repariert (?) und fragen uns, ob es funktioniert. Das muß ein tolles Gerät sein, wenn es so hohe Aufwände lohnt. :-)
Unter der Annahme dass von deinem Sensor etwas rauskommt wie "25.1\n" mal kurz etwas zusammengeklöppeltes für Telegram über einen einfachen POST im Anhang. Als "Messgerät" hat ein RP2040 fungiert:
1 | adc_select_input(4); |
2 | while (1) |
3 | {
|
4 | uint16_t u16Adc = adc_read(); |
5 | float temp = 27.0f - (((u16Adc * 3.3f) / 4096.0f) - 0.706f) / 0.001721f; |
6 | printf("%.2f\n", temp); |
7 | sleep_ms(1000); |
8 | }
|
Wenn das Format anders ist, wenn man filtern möchte, eine Statistik rechnen bzgl. Ausreißer, mehrere Messgeräte hat oder ähnliches muss man das natürlich noch ergänzen. Nicht schön, nicht alles abgefangen, aber grob gehts. Ich denke die grobe Richtung sieht man. Und wenn man das in C/CPP haben will muss man den String halt da zusammenbauen und den GET/POST Request halt dort machen. Ein settings.json könnte dann so in der Art aussehen:
1 | {
|
2 | "log_level": "INFO", |
3 | "serial": |
4 | {
|
5 | "com": "COM10", |
6 | "baud": 256000 |
7 | }, |
8 | "telegram": |
9 | {
|
10 | "active": false, |
11 | "tx_iv_s": 10, |
12 | "chat_id": YOUR_CHAT_ID_AS_NUMBER, |
13 | "token": "YOUR_TOKEN_AS_STRING" |
14 | } |
15 | } |
:
Bearbeitet durch User
> Nur mal so als Nebenfrage: wollt Ihr den Anbau von Pflanzen überwachen? > Das muß ein tolles Gerät sein, wenn es so hohe Aufwände lohnt. Es handelt sich weder um Pflanzen, noch um ein tolles Gerät, das so hohe Aufwände lohnt. Ich nehme lediglich die aktuelle Situation zum Anlass, ein Problem, das sich in der Vergangenheit so oder so immer wieder mal in einer ähnlichen Form gestellt hat, jetzt endlich anzugehen: weil ich das schon viel zu lange vor mir her schiebe, so dass es mir allmählich auf die Nerven geht. Ich glaube, mich interessiert beides, die Telegram-Lösung und, vielleicht für spätere Einsätze, bei denen mehr als ein paar ASCII-Zeichen publiziert werden sollen, die "Homepage"-Lösung. Zu dieser hätte ich dann noch ein paar Fragen, angefangen von einem Web-Hoster, den du mir empfehlen würdest, bis hin zur Programmierung der Seiten dieser "Homepage". Letzteres würde mich wirklich sehr interessieren, da ich diesbezüglich nicht mehr ganz up to date bin. So, jetzt bin ich bis Mitte / Ende Januar nicht mehr hier und würde anschließend in Abhängigkeit von dem, was bis dahin aufgelaufen ist und erfahrungsgemäß oberwichtig zu sein vorgibt, gerne beide Lösungen angehen. Ich verfolge die Vorschläge hier bis dahin auf meinem Handy, bitte aber um Verständnis dafür, dass ich mir den Wolf weder tippen möchte noch kann (da meine Zeit bis dahin recht begrenzt ist) und ich zudem auch nicht in der Lage bin, mal gerade etwas auszuprobieren. Einstweilen vielen Dank für eure Vorschläge, die ich zu einem späteren Zeitpunkt aufgreife!
:
Bearbeitet durch User
Michael schrieb: > u dieser > hätte ich dann noch ein paar Fragen, angefangen von einem Web-Hoster, > den du mir empfehlen würdest, bis hin zur Programmierung der Seiten > dieser "Homepage". Man könnte den Webserver zusammen mit einem VPN-Server auf dem Pi laufen lassen, wer dann die Zugangsdaten zu dem VPN hat, kommt auch an die Daten.
Sebastian R. schrieb: > Michael schrieb: >> u dieser >> hätte ich dann noch ein paar Fragen, angefangen von einem Web-Hoster, >> den du mir empfehlen würdest, bis hin zur Programmierung der Seiten >> dieser "Homepage". > > Man könnte den Webserver zusammen mit einem VPN-Server auf dem Pi laufen > lassen, wer dann die Zugangsdaten zu dem VPN hat, kommt auch an die > Daten. Und wenn der Pi dann hinter einem üblichen SNAT hängt, wie kommen Eigentümer von Zugangsdaten dann an den VPN-Endpunkt? :-/
Ein T. schrieb: > Und wenn der Pi dann hinter einem üblichen SNAT hängt, wie kommen > Eigentümer von Zugangsdaten dann an den VPN-Endpunkt? :-/ Durch eine korrekte Netzwerkkonfiguration.
Ich habe nun auch mal den Telegram-Bot verwendet, ja es ist wirklich einfach sich auf einen privaten Chat sich eine Message zu senden. Da meine WAN IP Adresse immer wieder neu vergeben wird und ich es gerne wüsste wenn ich unterwegs bin, bekomme ich nun eine Message in meinen privaten Chat. Ich habe mir das schon länger gewünscht, weil das Dynamische DNS nicht immer zuverlässig funktioniert. Falls das jemand braucht: Die EXE gibt es auf meiner Homepage unter Downloads > Neueste Builds > Tools > YourIP.zip kostenlos zum Download. In der ReadMe steht wie man das konfiguriert. Die EXE muss dann immer laufen, sonst kann die WAN Adresse ja nicht überwacht werden.
Sebastian R. schrieb: > Ein T. schrieb: >> Und wenn der Pi dann hinter einem üblichen SNAT hängt, wie kommen >> Eigentümer von Zugangsdaten dann an den VPN-Endpunkt? :-/ > > Durch eine korrekte Netzwerkkonfiguration. Wenn Du damit nicht DNAT mit DynDNS meinst -- bisweilen auch "Portforwarding" genannt -- dann erklär mir die doch bitte, ich lerne gern dazu. Danke! :-)
N. M. schrieb: > Nicht schön, nicht alles abgefangen, aber grob gehts. Äh... sollte "sendMessage()" nicht zu der Klasse "MsgSender" gehören? Zudem ist das ein bisschen Windows-lastig, da fehlt eine Shebang-Zeile und "COM1" ist halt nicht "/dev/ttyS0" oder sowas. Nur Hinweise, nicht schlimm: Dein Code gefällt mir sonst richtig gut. :-)
Sheeva P. schrieb: > Äh... sollte "sendMessage()" nicht zu der Klasse "MsgSender" gehören? Ja da hast du Recht. Habe nachträglich noch die Anzahl Leerzeichen gekürzt. Und das ist definitiv falsch. Sheeva P. schrieb: > Zudem ist das ein bisschen Windows-lastig Das stimmt. Bin hauptsächlich in Windows unterwegs und auch nicht sonderlich Python firm. Weiß also nicht wo da die Fallstricke sind was plattformübergreifende Python Scripte angeht. Sheeva P. schrieb: > da fehlt eine Shebang-Zeile Stimmt, ist halt für Windows nicht relevant. Ansonsten hätte ich mir das vermutlich schon angewöhnt. Sheeva P. schrieb: > und "COM1" ist halt nicht "/dev/ttyS0" oder sowas. Das ist ja nur der Default Parameter, der nicht benutzt wird weil beim Aufruf der Wert aus Settings übergeben wird. Da kannst du ja theoretisch "/dev/ttyS0" eintragen, oder? Sheeva P. schrieb: > Nur Hinweise, nicht schlimm Alles gut :-) Ich lerne gerne dazu. Die Anmerkungen waren ja zurecht (y)
:
Bearbeitet durch User
Michael schrieb: > Ich glaube, mich interessiert beides, die Telegram-Lösung und, > vielleicht für spätere Einsätze, bei denen mehr als ein paar > ASCII-Zeichen publiziert werden sollen, die "Homepage"-Lösung. Ich weiß, es ist nicht "Deine Sprache", aber ich habe mal eine kleine (und bislang eher rudimentäre) Lösung in Go(lang) angehängt. Alles Wissenswerte sollte in der README.md stehen, für Fragen, Ideen und Anregungen stehe ich natürlich gerne zur Verfügung. Die Datenübertragung funktioniert, die Datensammlung aber noch nicht. Es gibt aber schon ein bisschen Code für die serielle Schnittstelle, allerdings habe ich gerade nichts serielles zum Ausprobieren. Die Doku [1] hat jedoch viele nützliche Beispiele, im Zweifel helfe ich aber nach Möglichkeit gerne. Ob die Symlinks in dem Tarball unter Windows korrekt funktionieren, weiß ich nicht (ich kenne mich mit Windows nicht aus). Wichtig ist vor allem, daß der AES-Schlüssel "crypt_key" in allen "symmetric_crypt.go" derselbe ist. :-) Viel Spaß und Erfolg! :-) [1] https://pkg.go.dev/go.bug.st/serial
Michael schrieb: .... > Ein typischer Anwendungsfall für mich wäre ein Multimeter, dass ich über .... Das liest sich für mich nach einem klassischen Einstieg in die Maschinendatenerfassung (siehe hier https://www.mkware.de/lexikon/maschinendatenerfassung/ ), auch wenn der Umfang bewusst klein gehalten ist. Die Erfassung, Plausibilisierung und zeitliche Verdichtung der Werte hast du ja bereits klar vom Transport getrennt. Genau deshalb würde ich den Versand möglichst simpel halten und den Chat nur als Anzeige und Abstimmungskanal sehen, nicht als Datensenke. So bleibt die Lösung flexibel, falls später weitere Messquellen dazukommen oder sich die Anforderungen ändern.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.