FHEM2FHEM - Umsetzung

[Pf@nne]

Welches UserReading hättest du den gerne?

Na ja, da fangen die Problme schon an.... Ich habe zwar 4 Raspberrys und eine DS laufen, aber im Grunde weiß ich noch nicht mal genau was ein UserReading ist, bzw. wie man dieses zum Steuern benutzt....
Ich nutze ein UserReading um meine Temperaturmessung zu formatieren...

Du hast geschrieben:

Ein UserReading erstellt und das Regexp entsprechend angepasst und der Kuchen ist im Ofen.

Jetzt fehlt mir das Rezept....

Gruß
Pf@nne

[Prof. Dr. Peter Henning]

..aber im Grunde weiß ich noch nicht mal genau was ein UserReading

Allerdings bin ich auch der Meinung, dass eine zentrale Intelligenz einfacher zu administrieren ist und somit weniger Fehlerpotenzial birgt.

Pardon, aber irgendwie laufen da Anspruch und Wirklichkeit ein wenig auseinander: Keinen richtigen Durchblick bei FHEM, aber ein System aufbauen, von dem hier mehrere Leute abgeraten haben...

Noch einmal zum Mitschreiben: Es handelt sich bei der Lösung, zwei FHEM-Instanzen über zwei FHEM2FHEM miteinander kommunizieren zu lassen, nicht um eine "fachgerechte" Lösung. Sondern um eine fehleranfällige und langsame Lösung.

Stattdessen sollte auf der zentralen FHEM-Instanz für das gezielte Absetzen von Befehlen an einen Client (nicht "Slave") das ECMD / ECMDDevice verwendet werden, das sich an den Telnetport des anderen FHEM wendet.

pah

P.S.: Auch in diesem Falle handelt es sich bei dem zentralen FHEM nicht um eine Intelligenz...

[Pf@nne]

Guten Morgen Peter,

erstmal möchte ich auch Dir ein fohes (rest) Osterfest wünschen.

Auch vielen Dank für die Beteiligung an diesem Thema.

Pardon, aber irgendwie laufen da Anspruch und Wirklichkeit ein wenig auseinander: Keinen richtigen Durchblick bei FHEM, aber ein System aufbauen, von dem hier mehrere Leute abgeraten haben...

Wieso fühle ich mich jetzt als Trottel?
Natürlich habe ich bisher nur geringe Erfahrungen mit FHEM und stelle dumme Fragen und verstehe nicht alles auf Anhieb. Dazu gibt es doch aber Foren, hier helfen die alten Hasen (wie du einer bist) den Newbies (wie ich einer bin). Nur weil ich noch nicht so tief in der Materie drin stecke heißt das ja noch lange nicht, dass das nicht noch werden kann.
Mir persönlich bereitet die Umstellung auf ein so komplexes  Perl-System wie FHEM es ist ziemliche Probleme. Dennoch halte ich FHEM für das richtige System für meine angestrebte Hausautomatisierung, auch wenn ich viel neues lernen muss. Der Beitrag läuft ja auch im Anfängerbereich unter ,,fachgerechte" Umsetzung.

Vielleicht gelingt es ja den Newbies wie mir unter die Arme zu greifen, ohne dass sie sich wie Dummköpfe fühlen.
Und auch hier nochmal zum mitschreiben: Wir Newbies sind nicht von haus aus störrisch und begriffsstutzig, wir wissen es nur (NOCH) nicht besser. Bitte nicht immer gleich aufgeben, ich verstehe, dass es manchmal schon ein wenig nach ,,Beratungsresistenz" aussieht. Aber bitte nicht aufgeben und auch ein wenig Geduld mit den neuen mitbringen.

Wir sind zwingend auf die Hilfe der alten Hasen angewiesen und nehmen diese auch gerne an UND wir wissen die Hilfe auch zu schätzen.
Wenn das vorgeschlagene nicht sofort umsetzen, dann liegt es meistens daran, dass wir es noch nicht verstanden haben und weiterführende Hilfe vom Profi notwendig ist.

Nur so können Newbies wie ich etwas dazu lernen und später dann, mit ein wenig mehr Erfahrung, den neuen Newbies mit Rat und Tat zu Seite stehen.
Das macht doch ein Forum aus!

Das musste ich auch einfach mal loswerden.....nichts für ungut....
Ich hoffe, dass ich weiterhin mit deiner zielführenden Unterstützung rechnen kann.


Zurück zum Thema....

Stattdessen sollte auf der zentralen FHEM-Instanz für das gezielte Absetzen von Befehlen an einen Client (nicht "Slave") das ECMD / ECMDDevice verwendet werden, das sich an den Telnetport des anderen FHEM wendet.

Wenn das der fachgerechte Weg ist, dann werde ich versuchen mich hier mal einzulesen.
Hast du hierfür ein einfaches Beispiel, z.B. für die Steuerung einer LED?
Vielen Dank wir diesen Tipp.


Gruß
Pf@nne

EDIT:
Ohne, dass ich jetzt schon näher nachgeschlagen habe halte ich die Telnet-Variante auch für sinnvoller, da hier die Anbindung an "nicht FHEM" Geräte erfolgen könnte. So wäre dies doch, so glaube ich jedenfalls, der richtige Weg um z.B. eine Steuerung über eine eigene Anwendung z.B. auf meinem Linux-SAT-Receiver zu ermöglichen oder die Anbindung von AVR Schaltungen über das Netzwerk zu realisieren.

[Prof. Dr. Peter Henning]

Auch einen guten Morgen.

Ich bitte um Nachsicht, aber nach Beratungsresistenz sah das schon aus. Aber, Schwamm drüber.

In diesem Thread hier: http://forum.fhem.de/index.php/topic,29737.0.html und auf dieser Wiki-Seite http://www.fhemwiki.de/wiki/EBUS wird die Steuerung einer kompletten Heizungsanlage beschrieben. Dabei läuft ein externer (ebusd-)Server auf einem separaten Raspberry Pi und wird von FHEM aus über ECMD/ECDMDevice gesteuert. Weiters dazu in der commandref.

LG

pah

[Pf@nne]

Hi,

Ich bitte um Nachsicht, aber nach Beratungsresistenz sah das schon aus. Aber, Schwamm drüber.

Klar, Schwamm drüber, manchmal muss man nur mal drüber sprechen.....

Sehe ich bisher folgendes richtig?:

• ECMD/ECDMDevice stellt eine definierte Datenverbindung zwischen zwei FHEM Instanzen dar.
• Alternativ kann auch eine Verbindung zu einem "nicht FHEM" TCP-Gerät erstellt werden, hier muss nur festgelegt werden wie was geschrieben bzw. gelesen wird.
• Die "Verbindungskanäle" (was wird wie ausgetauscht) werden in s.g. classes definiert
• Die definierten classes werden in *.cfg-Files abgelegt und dem ECMD-define mitgeteilt.
• Jede class kann dann in einem eigenen ECDMDevice genutzt werden.

Das heißt ich muss die für meine Steuerung benötigte class selber definieren, was wie über das Netzwerk gesendet bzw. geantwortet wird.

Siehst du eine Möglichkeit hierzu ein einfaches Beispiel zu erstellen, da deine links sich im Wesentlichen auf bindung eines FHEM-ECMD an ein "nicht FHEM" Gerät beschreiben.

Es müssten dann ja in beiden FHEM-Instanzen ECMD-Telnet-Verbindungen definiert werden. Was ist mit der stanardmäßig vorhandenen Telnet-Verbindung?

Wie gesagt, am meisten (und schnellsten) lernt man anhand eines Beispiels.

Schalten und rückmelden einer "fernen" LED würde mir hier als "erster Schritt" einfallen.
Vielleicht siehst du eine Möglichkeit hier zu unterstützen....


Gruß
Pf@nne

[Prof. Dr. Peter Henning]

Dafür würde ich im entsprechenden Thread nachfragen, das hat garantiert schon jemand realisiert.

LG

pah

[Pf@nne]

OK,

---> hier geht es weiter
http://forum.fhem.de/index.php/topic,36060.msg283788.html#msg283788

[Pf@nne]

OK, da bin ich wieder......

Nach aussage von Boris Neubert ist ECMD nicht für die Kommunikation zwier FEHM-Instanzen unterienander gedacht.

Dem entnehme ich, das ECMD für diese Fälle garnicht konzipiert wurde??
Sonder für die Anbindung von TCP-Server basierter Fremdhardware?

Als klassisches Beispiel wäre hier der Pollin NET-IO zu nennen, der im Grunde ja nur auf Befehle von Außen reagiert,
als da wären....

  sag mit mal wie warm es ist, mach mal Ausgang 3 an, wie steht Eingang 5 gerade.....

Korrekt.

Zitat

Dann wäre ich ja mit ECMD auf der falschen Fährte.....und vielleich doch mit FHEM2FHEM besser beraten?

Am Ende des Tages läuft die Lösung mit ECMD doch nur darauf hinaus, dasselbe zu bewirken wie FHEM2FHEM, nur mit mehr Gewürge.

Viele Grüße
Boris

pah, hast du dazu noch eine weiterführende Idee? Warum würdest du ECMD dafür nutzen und vor allem wie?


Demnach muss ich mir über meine ferne GPIO-Steuerung mit "echter" Rückmeldung hier weiter Gedanken machen.
Ich hoffe (wie bisher auch) auf eure Unterstützung....

Ich werde jetzt mal ein Beispiel fertig machen und dann reinstellen.

[Prof. Dr. Peter Henning]

Ob es dafür "gedacht" war, ist doch irrelevant - Hauptsache, es funktioniert damit.  Und "Gewürge" kann ich nicht erkennen.

Also nochmal in Kürze meine Argumente

- FHEM2FHEM führt eine lokale Filterung durch. Das bedeutet, dass alle Events der entfernten FHEM-Instanz über das Netz geschickt werden, das ist ggf. eine Menge Traffic. Je nach Auslastung kann das auch Sekunden dauern, bis ein speziell für die lokale Instanz gedachter Befehl dabei ist,ausgefiltert und dann in der lokalen Queue abgearbeitet wurde. Darüber hinaus ist diese Zeit auch vom Zustand des Netzes abhängig. Will die lokale FHEM-Instanz der entfernten etwas mitteilen, geht dies also nicht gezielt. Sondern eher mit der Flaschenpost: Man wirft etwas in den Strom und hofft, dass der Empfänger es herausfieselt.

- ECMD hingegen setzt gezielte write/read-Anweisungen per telnet ab. Das vemeidet Netztraffic, und es ist vollkommen egal, ob am anderen Ende ein FHEM oder ein andere Software mit offenem Port wartet. Sehr viel direkter, mit sehr viel weniger Overhead.

LG

pah

[Pf@nne]

Moin Peter,

Ob es dafür "gedacht" war, ist doch irrelevant - Hauptsache, es funktioniert damit.  Und "Gewürge" kann ich nicht erkennen.

Da hast du recht, auch konnte ich deine Argumente schon vorher nachvollziehen.
Ich teile deine Meinung, eine direkte TCP-Verbindung mit direkten commands und den dazugehörigen responses sind alle mal sinnvoller, so kann auch wesentlich gezielter auf etwailige Störungen reagiert werden.

Ich würde auch lieber mit ECMD weiter "forschen", nur stecke ich ja an dem Punkt wo ich auf der Empfängerinstanz auch das ankommende Telegramm reagieren möchte. Die TCP-Verbindung besteht, nur wie fange ich die SET/GET-CMDs ab?
Im EnventLOG ist nichts zu sehen. Muss eine class mit "Read" od "Wait_for_Data" geschrieben werden?

Vielleicht kannst du mir hier noch ein wenig Starthilfe geben.

Gruß
Pf@nne

[Prof. Dr. Peter Henning]

In die "class"-Datei für ECMDDevice eintragen:

Code Auswählen Erweitern

get state cmd {<hier befehl für die entfernte telnet-Instanz>}
get state expect ".*"
get state postproc { perlauswertefunktion($_) }

Dann in der eigenen myUtils.pm-Datei eine Prozedur anlegen, die

Code Auswählen Erweitern

sub perlauswertefunktion($){
<hier diverse perl-Befehle zur Umwandlung der gelesenen Daten>
}

LG

pah

[Pf@nne]

Hallo Peter,

Code Auswählen Erweitern

get state cmd {<hier befehl für die entfernte telnet-Instanz>}
get state expect ".*"
get state postproc { perlauswertefunktion($_) }

Das hatte ich glaube ich so weit verstanden...
get cmd = zu sendender TCP-String an das entfernte "Gerät"
get expect = Filtermöglichkeit für die response vom entfernen "Gerät"
get postproc = Verarbeitung der Response z.B. in einer eigenen Perl-Routine

Das ist doch aber wieder die Prozedur zum aktiven einleiten einer Kommunikation.
Mir fehlt jetzt das Gegenstück auf der entfernen FHEM-Instanz.

Code Auswählen Erweitern

get state cmd {<hier befehl für die entfernte telnet-Instanz>}
Wie kann ich dieses command auf der entfernten FHEM-Instanz wieder einfangen?

Auf der entfernten FHEM-Instanz muss doch ein TCP-Server laufen der die empfangenen Strings auswertet und weiter verwendet.
Um z.B. einen GPIO zu schalten...

Es mus doch auf der entfernten FHEM-Instanz so etwas wie

Muss eine class mit "Read" od "Wait_for_Data" geschrieben werden?

geben....

Sorry wenn ich mich immer noch so dusselig anstelle, aber irgendwie hab ich das Gefühl, das wir aneinander vorbei reden..

Und danke für deine Geduld....


Gruß
Pf@nne

[Prof. Dr. Peter Henning]

Einfach mal direkt auf der externen FHEM.Instanz mit lelnet einloggen (port 7072). Dort kann man jeden FHEM-Befehl absetzen. Und das wird nun eben von ECMDDevice übernommen.


LG

pah

[Pf@nne]

Moin,

Dort kann man jeden FHEM-Befehl absetzen

Jetzt ist der Groschen endlich gefallen, so langsam wird mir klar warum mir keiner so richtig helfen konnte!
Das "set cmd" in der steuernden FHEM-Instanz muss einfach nur einen gültigen FHEM-Befehl enthalten!!!
Ich war der Auffassung man könnte "irgendetwas" senden und müsste dies dann im "postproc" des Empfänger wieder zerlegen, auswerten und damit die richtigen Ereignisse Triggern.....dem ist aber nicht so. Die "postproc" ist scheibar nur für Geräte die als response tatsächlich "irgendetwas" antworten, was dann erstmal ausgewertet werden muss.

Ein "Gewürge" würde ich jetzt erstmal auch nicht vermuten wollen. Sieht mir nach dem jetzigen Stand recht strukturiert aus.
Mit den neuen Erkenntnissen werde ich mich heute Abend mal drann setzen und versuchen einen "fernen" GPIO zu steuern und die "echte" Rückmeldung zum Sender zurück zu schicken.

Schönes Wochenende....
Pf@nne

[justme1968]

fhem2fhem sendet im LOG modus ab morgen nicht mehr alles über die leitung sondern filtert schon direkt auf dem quell system.

gruss
  andre