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