Vorstellung & Frage zu Temperatur- & Feuchtesensor

God-of-Games · 16 Juli 2020, 13:55:51

Dann würde ich das mit dem Template heute Abend mal ausprobieren.
Der Aufbau der Device-Struktur in FHEM ist mir nicht klar. Nach dem einrichten des OpenMQTTGateway ist dieser in FHEM erschienen und ich habe das OpenMQTTGateway template angewendet. Nach starten des ClearGrass ist ein neues Device erstellt worden, welches im Reading die gleichen Werte hatte wie dieses.
Jetzt wollte hatte ich mir noch die Logik zum anzeigen der Werte aus einem anderen Gerät mit Template "nachgebaut", dachte aber dass es vielleicht schon was fertiges gibt.
Würdest du mir den Aufbau erklären oder gibt es hierzu eine Seite im Wiki?

Beta-User · 16 Juli 2020, 14:28:46

Zitat von: God-of-Games am 16 Juli 2020, 13:55:51
Dann würde ich das mit dem Template heute Abend mal ausprobieren.

Vermutlich sind "Trockenübungen" etwas abstrakt, und du solltest auch bitte bei Fragen genau mitteilen, welches template du jeweils angewendet hast (das ergibt sich für mich am einfachsten aus einer RAW-Definition).

Daher erst mal noch vorab, wie die Device-Struktur sein sollte. Das ist vermutlich v.a. dann etwas schwer nachzuvollziehen, wenn man nur ein entsprechendes Device hat...

Zitat
Der Aufbau der Device-Struktur in FHEM ist mir nicht klar. Nach dem einrichten des OpenMQTTGateway ist dieser in FHEM erschienen und ich habe das OpenMQTTGateway template angewendet.

Das sollte genauer gesagt das hier sein: OpenMQTTGateway_MCU. Das repräsentiert zukünftig dann nur noch den ESP(32|8266), also ob dieser mit dem MQTT-Server verbunden ist, und erlaubt das Absetzen von Kommandos, die an den Microcontroller selbst gerichtet sind. Das ist ganz so, wie du es evtl. auch von anderen .*2mqtt-Lösungen kennst (zigbee2mqtt, z.B.).

Dabei werden alle Readings gelöscht und nur wenige neue dann wieder (über der Zeit) angelegt).

ZitatNach starten des ClearGrass ist ein neues Device erstellt worden, welches im Reading die gleichen Werte hatte wie dieses.

Es können auch mehrere Devices angelegt werden, das hängt u.a. auch davon ab, was das betreffende Gateway eigentlich so alles "kann" bzw. an Schnittstellen hat. Bei einem reinen BT-Betrieb, düfte es ein Device mit der CID "oMQTTgw_BT" sein. In dem landet "alles", was irgendwie über den BT-Zweig an Infos kommt, ganz egal, von welcher Hardware das eigentlich kommt. Daher kann man mit diesem Device eigentlich m.E. nur eines tun: Man wendet darauf das OpenMQTTGateway_BT_scanner-template an...

Das bereitet dann alle über BT eingehenden Infos etwas anders auf und ist eigentlich v.a. als "Übersichtsdevice" konzipiert, was etwas schwierig nachzuvollziehen ist, wenn man das nicht etwas länger am laufen hat - z.B. werden auch alle BT-Signale von sämtlichen Handys empfangen, was besonders dann "lustig" ist, wenn es sich um angebissene Äpfel handelt: die wechseln nämlich alle Naselang ihre ID, so dass man dann irgendwann eine irre lange Liste mit unnützen Daten hat.
Dieses template sorgt daher dafür, dass die Readings auch wieder regelmäßig gelöscht werden.

ZitatJetzt wollte hatte ich mir noch die Logik zum anzeigen der Werte aus einem anderen Gerät mit Template "nachgebaut", dachte aber dass es vielleicht schon was fertiges gibt.
Würdest du mir den Aufbau erklären oder gibt es hierzu eine Seite im Wiki?

Was BT-Geräte angeht, die Temperatur und Humidity senden, gibt es ein template: OpenMQTTGateway_BT_temp_hum_sensor
(Ich sehe grade, dass da noch die CID falsch vergeben wird, muß ich nacharbeiten...)
Das template erstellt ein neues Device (BT-Adresse bekommt man aus dem "scanner"), das sollte es dann (ähnlich wie OpenMQTTGateway_BT_gtag für GTags uä.) möglich machen, einfach nur die Werte "ganz normal" (wie von anderen Sensoren her auch bekannt) darzustellen.

Kurzfassung ist daher: Man braucht bei OMG-BT m.E. eigentlich immer mind. drei Geräte: Das "MCU" für den ESP, das "scanner" als "Infogerät" und die eigentlichen "Hardware"-Geräte für jedes BT-Endgerät, das man separat sehen will.

(Ich packe das mal bei Gelegenheit etwas ausführlicher ins Wiki; da hat zwar jemand mal in https://wiki.fhem.de/wiki/MQTT#OpenMQTTGateway angefangen, aber was da steht, greift m.E. etwas zu kurz).

God-of-Games · 17 Juli 2020, 13:06:18

Perfekt, danke dir für die Erklärung, jetzt ist mir auch klar, wie das ganze abläuft und das einrichten hat auch geklappt.

Wenn ich es richtig verstanden habe, wäre es in diesem Fall auch kein Problem, wenn sich ein BT-Sender im Empfangsbereich von mehren Gateways befindet bzw. wechselt, da er über die MAC eindeutig identifiziert wird.

Beta-User · 17 Juli 2020, 13:14:34

Zitat von: God-of-Games am 17 Juli 2020, 13:06:18
Perfekt, danke dir für die Erklärung, jetzt ist mir auch klar, wie das ganze abläuft und das einrichten hat auch geklappt.

Danke für die Rückmeldung. Falls ich die Beschreibung in den templates selbst bzw. im Wiki noch optimieren kann/soll: bin für Vorschläge zu haben...

ZitatWenn ich es richtig verstanden habe, wäre es in diesem Fall auch kein Problem, wenn sich ein BT-Sender im Empfangsbereich von mehren Gateways befindet bzw. wechselt, da er über die MAC eindeutig identifiziert wird.

Korrekt, mehrere GW's sind kein Problem, außer, dass eben ggf. mehrere Events mit demselben Trigger generiert werden - da kann man dann aber z.B. bei notify mit disableAfterTrigger abhelfen (oder entsprechenden event-on-Attributen).

Das hat teilweise aber auch Vorteile - allerdings weniger bei deiner Art Sensor, sondern eher bei mobilen wie Handys oder G-Tags: Da kann man den ungefähren Standort über den besten RSSI-Wert ermitteln (gibt ein eigenes Template dafür).

Da das (bei den einfachen Sensoren) afaik auch "broadcasts" sind, braucht das auch nicht extra Batterie-Leistung, wenn man mit mehreren GW's empfängt.

God-of-Games · 20 Juli 2020, 10:35:18

Hi,
sorry, dass ich mirch jetzt erst melde, wir hatte am Wochenende Besuch...

Zitat von: Beta-User am 17 Juli 2020, 13:14:34
Danke für die Rückmeldung. Falls ich die Beschreibung in den templates selbst bzw. im Wiki noch optimieren kann/soll: bin für Vorschläge zu haben...

Meinst du diese Seite im Wiki?
bei meiner Suche ist mir aufgefallen, dass viele User Probleme haben zu unterscheiden, dass es für Tasmota "gerätespeztifische" und bei FHEM "funktionsspezifische" Templates gibt. Mein Problem war am Anfang aber eher herauszufinden, was das passende Template für mein Gerät ist. Verstärkt wurde es damals dadurch, dass damals scheinbar ein Bug im Template war, ich finde aber den Thread dazu nicht mehr.
Insgesamt hätte ich mir eine Seite gewünscht, die etwas übersichtlicher wäre, was mein passendes Template wäre. Also ein Bereiche schaltbare Steckdosen und dort alle möglich Templates gelistet (einfach, doppelt etc. mit und ohne Leistungsmessung).
Zum OMQTTG hatte ich keine Wiki-Seite gefunden, wobei ich ohne deine Hilfe nie darauf gekommen wäre wie die Geräte angelegt werden müssen.

Bei quer lesen im Forum bin ich noch auf einen anderen Thread gestoßen bei dem das ganze über Tasmota läuft. Wenn ich es richtig verstanden habe, würde dass dann, wenn SetOption89 funktioniert, auf die gleiche weise laufen?

Beta-User · 20 Juli 2020, 11:05:48

Also:
Im Wiki gibt es (allg.) https://wiki.fhem.de/wiki/AttrTemplate, speziell, was MQTT2_DEVICE angeht https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele, die Ultrakurzfassun gäbe es hier https://wiki.fhem.de/wiki/MQTT2_DEVICE#attrTemplate und hier hat dann noch jemand was zu OpenMQTTGateway geschrieben: https://wiki.fhem.de/wiki/MQTT#OpenMQTTGateway. Das verlinkte "template" ist dagegen was ganz anderes...

Das mit gerätespezifisch vs. funktionsspezifisch ist ein Dauerthema, zu dem ich auch keine definitive Lösung habe. Für zigbee2mqtt-Leuchtmittel gäbe es z.B. was hier: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#IKEA-Tradfri-Birne; sowas könnte man auch für die diversen Tasmota-Vertreter basteln. Oder eben in die desc: -Abschnitte typische Hardware-Verteter auflisten - da wäre ich aber auf entsprechende Zuarbeit angewiesen.

Was tasmota2bt angeht, könnte das auch in diese Richtung gehen, es fehlen aber Erfahrungen (für den Parallelfall tasmota2zigbee habe ich zwar ein paar attrTemplates bereitgestellt, aber die sind im wesentlichen bisher auch ungetestet...). Einen gößeren Vorteil für tasmota kann ich nicht erkennen (außer, dass es einfacher ist, updates auf den ESP zu bringen) - dafür ist die json-Datenstruktur in der Regel noch verschachtelter, die Tasmota liefert... (ich werde eher bei OMG bleiben).

God-of-Games · 21 Juli 2020, 11:47:37

Danke für die Klarstellung.
Wie schon gesagt war es zum Beginn recht schwierig das passende Template zu finden und nachdem ich bei Tasmota für jedes Endgerät ein spezifisches brauche, bin ich auch nicht auf die Idee gekommen, dass alle Steckdosen das gleiche verwenden, wenn man den MQTT-Server der Steckdosen passend konfiguriert. So war die Suche am Anfang etwas mühsam.

Leider ist der verlinkte Abschnitt zum OpenMQTTGateway sehr kurz gehalten und enthält für mich zum einen unrelevante Infos ("Ich habe es noch in den Raum MQTT2 geschoben."). Zum Anderen fehlt der Zwischenschritt mit dem korrekten anlegen des BT-Scanners.
Was aber für mich persönlich ser verwirrend war ist die Logik wie ich das BT-Gerät anlege.
Zum einen setzte ich mit dem Befehl

Code Auswählen

set MQTT2_OMG1 attrTemplate OpenMQTTGateway_MCU
das Template für den Gateway, zum andern mit dem "gleichen" Befehl

Code Auswählen

set MQTT2_OMG1 attrTemplate OpenMQTTGateway_BT_mi_flora_sensor
definiere ich die Endgeräte, welche jedoch nicht unbedingt etwas mit gerade diesem Gateway zu tun haben.

Was meinst du mit "desc: -Abschnitte"?

Bzgl. tasmota2bt sehe ich für mich neben dem erwähnten einfacheren Update die Vorteile des Webinterfaces falls man im Nachgang noch etwas anpassen möchte (bei OMG nur beim ersten Verbinden vorhanden) und das im andere Thread erwähnte auslesen der Batterie.

Würdest du mir noch erklären was eine MQTT-Bridge ist und für was ich die benötige oder ist das vor relevant, wenn FHEM nicht der MQTT2-Server ist?

Beta-User · 21 Juli 2020, 12:20:27

Zu desc: bzw. zur Frage, wie man was findet. Du kennst hoffentlich

Code Auswählen

set <device> attrTemplate ?
Wenn nein: Bitte ausprobieren!

Was man da sieht, ist eine Liste mit den _geladenen_ templates (ohne Filterung) sowie entsprechenden weiteren Infos, links zu Forenthreads, Projektseiten, ... Das kommt in der Regel aus "desc:" in der Source-file (zu finden beispielsweise in https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template). Derselbe Text kommt auch, wenn man in FHEMWEB eines der templates auswählt (ohne set).
Die Liste hat halt den Vorteil, dass man z.B. auch im Browser nach einer Gerätebezeichnung suchen kann (die aber eher selten dasteht).

Was den Ablauf für das "mi_flora" (und ein paar andere) angeht, ist es in der Tat etwas anders als üblich, eben weil ein weiteres Device benötigt wird. Bisher habe ich allerdings noch keine bessere Idee gehabt, wie man das sonst lösen könnte, erst manuell ein Device erstellen zu lassen, ist auch nicht wirklich besser, oder? Vielleicht könnte man den Hinweis, dass ein neues Device erstellt wird etwas deutlicher machen, aber wenn keiner eine Idee hat, was "desc:" denn sein könnte, liest das vermutlich auch keiner, wenn es in rot oder orange dasteht?

Das mit der Batterie@OMG kann ich übrigens so nicht bestätigen; ich habe auch einen "runden", da kommt auch der Batterie-Prozentwert und der sieht auch einigermaßen plausibel aus; ist evtl. auch eine Frage der Version, da tut sich auch @OMG einiges. Ohne eigenen Zweig je Hardware ist es jedenfalls mit Tasmota m.E. nicht wirklich nutzbar (soll aber kommen, und dann ist anzunehmen, dass da auch viele kompetente Mitentwickler an Bord sind, was evtl. mittelfristig hilfreich sein kann, wenn mehr Geräte verschlüsseln).

Was MQTT-Bridge sein soll, kann ich nur raten. Falls du das Modul 10_MQTT_BRIDGE.pm meinst: einfach vergessen, dass es das gibt, ab dem 2. Gerät ist es sehr viel einfacher, MQTT_GENERIC_BRIDGE zu nutzen, das im übrigen auch mit MQTT2-Interfacemodulen kann (MQTT_BRIDGE geht nur mit 00_MQTT.pm). Siehe auch hier: https://wiki.fhem.de/wiki/MQTT#MQTT_BRIDGE.
Zu beiden steht im Wiki (https://wiki.fhem.de/wiki/MQTT#Kommunikation_zu_sonstigen_FHEM-Ger.C3.A4ten_.C3.BCber_MQTT) als Einleitungssatz:

ZitatMöchte man Daten von einem Gerät (im FHEM-Sinn), das nicht vom Typ MQTT2_DEVICE oder MQTT_DEVICE (je nach IO-Modul) ist, per MQTT-Protokoll versenden (z.B. für eine andere Visualisierungslösung als FHEMWEB, oder als FHEM2FHEM-Ersatzlösung), oder diese sonstigen Geräte über MQTT-Anweisungen von außen steuern können, hat man mehrere Möglichkeiten:

Falls ich das hier in dem Zusammenhang gebraucht hatte: Es gibt neben OMG und Tasmota2zigbee noch einige andere Dienste und firmwares, die einfach nur "irgendwas2mqtt" machen. Dann war wohl ein FHEM-Device gemeint, das irgendwie diese Art Dienst oder MCU+firmware repäsentiert.

God-of-Games · 21 Juli 2020, 13:33:14

Code Auswählen

set <device> attrTemplate ?
ist mir bekannt, habe ich auch schon damals für die tasmota-Steckdosen verwendet um zu sehen, wie das tempalte genau heißt (in dem Thread war damals nur von POW-Template die Rede).
Ich würde mir im Wiki oder in den Foren öfters diese abstrahierte Schreibweise wünschen. Leider habe ich öfters (das die Syntax noch nicht so richtig sitzt) das Problem zu wissen, was das Gerät und was der Befehl ist.
Ich konnte jetzt mit der Abkürzung nichts anfangen, jetzt ist mir klar, dass es description also Beschreibung bedeutet. Hierfür müsste ich aber schon das passende Template gefunden haben. Ich dachte eher an eine Art Ablaufplan:
Art: Steckdose => Leistungsmessung ja/Nein => Anzahl Anschlüsse => Zu verwendentes Template

Bzgl. dem Ablauf bei solchen Geräten gebe ich dir Recht. Von der Logik her müsste man zuert ein neues Gerät anlegen und im Anschluss auf dieses das Template anlegen. Das wäre aber ein Schritt mehr, wobei mich es doch verwundert hatte das Gerät so anzulegen.
Ist es eigentlich auch möglich die Adresse des BT-Geräts gleiche beim

Code Auswählen

set <device> attrTemplate <template>
mitzugeben?
Bzgl. der aktuellen Vorgehensweise: Ist es egal von welchem OMG aus ich ein BT-Device anlege oder wird es dann nur mit diesem verknüpft?

Ich habe diese ClearGrass-Modell von Amazon, habe jetzt aber in den Reading keine Baterieanzeige gefunden, oder muss hierfür noch etwas gemacht werden?

Ok, wenn ich das mit der MQTT-Bridge richtig verstanden habe "generiert" diese ein MQTT-Gerät, welches ich per MQTT-Befehle ansprechen kann um damit in FHEM Schaltbefehle auszulösen. Da ganze natürlich auch andersherum mit Readings.

Die "irgendwas2mqtt" Geräte (Hard+Software) setzten wiederum ein anderes Protokoll auf MQTT um, so dass ich beispielsweise die Funkmodule besser positionieren oder mehrere Module verwenden kann um die USB-Sticks nicht verwenden zu müssen.

Beta-User · 21 Juli 2020, 14:25:28

Zitat von: God-of-Games am 21 Juli 2020, 13:33:14
Code Auswählen Erweitern
set <device> attrTemplate ?
ist mir bekannt, habe ich auch schon damals für die tasmota-Steckdosen verwendet um zu sehen, wie das tempalte genau heißt (in dem Thread war damals nur von POW-Template die Rede).

Na ja, manchmal ist "klar", um welches template es geht, und dann werden eben ggf. Abkürzungen verwendet, was für "uneingeweihte" oder "vorsichtig suchende" User manchmal nicht optimal ist.
Genauso mit "verkürzten" Schreibweisen für Befehle usw.. Gibt ermutlich keine optimale Lösung dafür, meistens hilft es, einfach ein wenig rumzuraten und FHEMWEB intensiver anzusehen; so lernt man mMn. auch relativ schnell viel, ist also eigentlich nicht verkehrt.

Zitat
Ich dachte eher an eine Art Ablaufplan:
Art: Steckdose => Leistungsmessung ja/Nein => Anzahl Anschlüsse => Zu verwendentes Template

Sowas kann man machen, ABER: jemand muß es a) machen und b) aktuell halten. Letzteres ist bei firmware-updates schon schwierig, wenn dann die Variantenvielfalt dazukommt, kann man eigentlich nur kapitulieren und versuchen, halbwegs sprechende Benennungen zu wählen und eine eher abstrahierende Struktur und Sortierung (so eben der aktuelle Versuch; wie gesagt: ich bin für zielführende Vorschläge zu haben)...

ZitatIst es eigentlich auch möglich die Adresse des BT-Geräts gleiche beim
Code Auswählen Erweitern
set <device> attrTemplate <template>
mitzugeben?

Prinzipiell ja

Code Auswählen

set <device> attrTemplate OpenMQTTGateway_BT_mi_flora_sensor <BT_ID>
sollte funktionieren, denn BT_ID ist die erste par:-Anweisung, etwas "zielgenauer" ginge

Code Auswählen

set <device> attrTemplate OpenMQTTGateway_BT_mi_flora_sensor BT_ID=<BT_ID>Ist nur etwas erklärungsbedürftig, von daher schadet es nicht, wenn wenigstens hin und wieder auch mal ein Parameter via Dialogfeld abgefragt wird...

ZitatBzgl. der aktuellen Vorgehensweise: Ist es egal von welchem OMG aus ich ein BT-Device anlege oder wird es dann nur mit diesem verknüpft?

Also: das attrTemplate löscht sowohl die CID-Angaben (von welchem Device kam das?) aus der readingList und ersetzt den konkreten Topic-Pfad durch eine regex-Variante, die auch auf mehrere OMG-Bridges passen sollte. Von daher gibt es danach keinen konkreten Bezug mehr zu einem bestimmten OMG. Das hat nur einen Haken: vergibt man Namen für das OMG, das nicht mit der regex kompatibel ist, geht es gar nicht...

ZitatIch habe diese ClearGrass-Modell von Amazon, habe jetzt aber in den Reading keine Baterieanzeige gefunden, oder muss hierfür noch etwas gemacht werden?

Afaik kann man beim OMG nichts einstellen; von daher: entweder das Reading ist da, oder eben nicht; ich kenne nur die LCD-Variante von dem Ding, und da geht es...

ZitatOk, wenn ich das mit der MQTT-Bridge richtig verstanden habe "generiert" diese ein MQTT-Gerät, welches ich per MQTT-Befehle ansprechen kann um damit in FHEM Schaltbefehle auszulösen. Da ganze natürlich auch andersherum mit Readings.

Im Prinzip richtig, aber solange du keine exakteren Bezeichnungen verwendest, fühle ich mich mit der Antwort nicht so recht wohl, weil ich nicht sicher weiß, ob wir wirklich über dasselbe reden.

Zitat
Die "irgendwas2mqtt" Geräte (Hard+Software) setzten wiederum ein anderes Protokoll auf MQTT um, so dass ich beispielsweise die Funkmodule besser positionieren oder mehrere Module verwenden kann um die USB-Sticks nicht verwenden zu müssen.

"Anderes Protokoll auf MQTT" paßt im Prinzip, allerdings ist das nicht beschränkt auf spezielle Funklösungen (siehe sonos2mqtt, da ist es afaik ein TCP/IP-Protokoll)). Was den "begründenden" Rest angeht, ist das für mich mehrfach schief: zum einen ist es so, dass man z.B. auch ser2net oder ein ser2LAN-Modul (oder einen ESP866 usw.) nutzen kann, um Funkschnittstellen besser zu positionieren, zum anderen bin ich ganz froh, dass ich alles, was mir wichtig ist, direkt an meinen (FHEM-)Server anstöpseln kann. Auf dem läuft z.B. auch deconz für zigbee. Darüber hinaus bin ich besonders froh, wenn ich sowas dann auch noch direkt von FHEM aus ansprechen kann; von daher ist selbst das lokal parallel laufende deconz in meiner Wahrnehmung nur eine (akzeptable) Notlösung

. Sobald irgendwo LAN (ohne localhost) im Spiel ist, ist es nicht mehr super, und WLAN kommt in meiner Wahrnehmung knapp oberhalb von 433MHz-"Gedöns" (just my2ct...)

God-of-Games · 21 Juli 2020, 16:54:57

Zitat von: Beta-User am 21 Juli 2020, 14:25:28
Afaik kann man beim OMG nichts einstellen; von daher: entweder das Reading ist da, oder eben nicht; ich kenne nur die LCD-Variante von dem Ding, und da geht es...

Ok, schade.

Zitat von: Beta-User am 21 Juli 2020, 14:25:28
Im Prinzip richtig, aber solange du keine exakteren Bezeichnungen verwendest, fühle ich mich mit der Antwort nicht so recht wohl, weil ich nicht sicher weiß, ob wir wirklich über dasselbe reden.

Die Ausführung so weit reicht mir bereits. Ich bin nicht so wirklich darauf gekommen, was es ist und ob ich es brauche, aber nachdem ich diese Info nun habe ist es für meinen aktuelle Stand nicht nötig.

Zitat von: Beta-User am 21 Juli 2020, 14:25:28
"Anderes Protokoll auf MQTT" paßt im Prinzip, allerdings ist das nicht beschränkt auf spezielle Funklösungen (siehe sonos2mqtt, da ist es afaik ein TCP/IP-Protokoll)). Was den "begründenden" Rest angeht, ist das für mich mehrfach schief: zum einen ist es so, dass man z.B. auch ser2net oder ein ser2LAN-Modul (oder einen ESP866 usw.) nutzen kann, um Funkschnittstellen besser zu positionieren, zum anderen bin ich ganz froh, dass ich alles, was mir wichtig ist, direkt an meinen (FHEM-)Server anstöpseln kann. Auf dem läuft z.B. auch deconz für zigbee. Darüber hinaus bin ich besonders froh, wenn ich sowas dann auch noch direkt von FHEM aus ansprechen kann; von daher ist selbst das lokal parallel laufende deconz in meiner Wahrnehmung nur eine (akzeptable) Notlösung . Sobald irgendwo LAN (ohne localhost) im Spiel ist, ist es nicht mehr super, und WLAN kommt in meiner Wahrnehmung knapp oberhalb von 433MHz-"Gedöns" (just my2ct...)

Danke für die Ausführung.
Ich bin wiederum von den USB Lösungen nicht so wirklich angetan, aber daher gibt es ja auch mehrere Varianten.
Du hast jetzt noch ser2net und ser2LAN ins Spiel gebracht. Wenn damit das Linux-Tool gemeint ist und ich die Doku richtig verstanden habe, kann ich mich damit per Telnet auf den Server verbinden und dort einen seriellen Port simulieren.
Wie sieht in diesem Fall die Hardware der Gegenseite aus?

Beta-User · 21 Juli 2020, 17:05:10

Zitat von: God-of-Games am 21 Juli 2020, 16:54:57
Du hast jetzt noch ser2net und ser2LAN ins Spiel gebracht. Wenn damit das Linux-Tool gemeint ist und ich die Doku richtig verstanden habe, kann ich mich damit per Telnet auf den Server verbinden und dort einen seriellen Port simulieren.
Wie sieht in diesem Fall die Hardware der Gegenseite aus?

ser2net ist ein Linux-dienst, korrekt. ser2LAN ist eine spontane Wortschöpfung, gemeint sind diverse Hardware-Optionen, um eine serielle Schnittstelle über einen fertigen oder selbsgebauten Microcontroller+LAN-Modul im Netz verfügbar zu machen. Das hat mWn. beides nicht wirklich was mit Telnet zu tun, selbst wenn man sich ggf. (auch) mit telnet da einwählen können sollte. Du findest die verschiedenen Varianten und links zum Weiterlesen am einfachsten über https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Verwendung; was da steht, kann im Prinzip fast universell mit allen möglichen Interfaces genutzt werden, die seriell angesprochen werden (mind. noch Signalduino, MySensors-GW, ...), Probleme kann es allerdings wegen Latenzen geben.