Problem bei Verbindung zweier Instanzen mittels FHEM2FHEM

[duke-f]

Mir fällt kein wirklich passender Titel ein, um mein Problem passen zu beschreiben. Vielleicht hat aber trotzdem einen Tipp.

Seit langem habe ich mehrere Rasperry Pi mit je einer Minimalversion von FHEM laufen. Die Hauptinstanz läuft auf einem Cubietruck. An einem der Raspi hangt ein IguanaWork IR-Tranceiver zur Ansteuerung der Hifi- und Videoanlage. Die Verbindung läuft über FHEM2FHEM, die abgesetzten Befehle sind als Systemkommandos über LIRC formuliert und werden auf dem entsprechenden FHEM-Client ausgeführt. Funktioniert seit Jahren praktisch einwandfrei. Jetzt hatte ich aber vor mehreren Wochen das erste Mal und dann diese Woche bereits zweimal das Phänomen, dass das Kommando an das System des Raspi nicht ankam oder nicht weitergegeben wurde. Normalerweise habe ich am Raspi einen Eintrag im Log, dieser fehlte dann jedoch in diesen Fällen. Es gibt absolut keine Anzeichen, dass irgendetwas nicht richtig funktioniert.

In diesen Fällen hatte ich jeweils einfach nur FHEM auf dem Raspi neu gestartet. Danach hat wieder alles funktioniert. Da das ganze nur selten auftritt, kann ich auch nicht viel probieren. Nächstes Mal werde ich versuchen, statt FHEM komplett neu zu starten, nur die FHEM2FHEM-Verbindung mittels reopen neu zu öffnen.

Unten füge ich die betreffenden Teile aus der Definition und dem Logging (in dem Fall, dass es funktioniert - sonst gibt es da einfach nichts) an. Vielleicht hat jemand einen Tipp, oder jemand hat ein ähnliches Problem.

Definition im Raspi

Code Auswählen Erweitern


define amerikaner FHEM2FHEM ip.des.cubie:7072 LOG:panacinema
define DI_Pana DOIF ([panacinema] eq "aus_ein")({system ("irsend send_once Panasonic KEY_POWER")}) \
DOELSEIF ([panacinema] eq "fm")({system ("irsend send_once Panasonic KEY_RADIO KEY_RADIO")}) \
....


Log-Auszug

Code Auswählen Erweitern


2017.09.29 06:57:11 2: DI_Pana: {system ("irsend send_once Panasonic KEY_POWER")}: -1
2017.09.29 06:57:22 2: DI_Pana: {system ("irsend send_once Panasonic KEY_RADIO KEY_RADIO")}: -1


[duke-f]

Nächstes Mal werde ich versuchen, statt FHEM komplett neu zu starten, nur die FHEM2FHEM-Verbindung mittels reopen neu zu öffnen.

Heute hatte ich das "Glück", das probieren zu können. Und tatsächlich hat es gereicht, mittels reopen die Verbindung neu zu öffnen. Da es offensichtlich sonst niemand mit dem Problem gibt bzw. niemand eine Lösung weiß, versuche ich es mal mit einem alltäglichen reopen von FHEM2FHEM per at morgens um 5:00 Uhr auf dem Raspberry.

[Grinsekatze]

Auch ohne Dein eigentliches Problem lösen zu können, kannst du einen Notify bauen, der prüft, ob die gewünschten Vorgänge tatsächlich auch umgesetzt wurden / eine Fehlermeldung produziert wurde. Wenn ja, dann wird ein reopen ausgeführt. Oder, wie Du schon angemerkt hast einen At, der täglich schaltet. ... zumindest ein Workaround.

[Otto123]

Hi,

es gab da schon mal was ähnliches, am Ende war das Netzwerk das Problem
https://forum.fhem.de/index.php?topic=72823.0

Gruß Otto

[duke-f]

Besten Dank.

Beide Ansätze werde ich mal verfolgen. Das Netzwerk hatte ich spontan zwar eher ausgeschlossen, da der Raspberry ja auch per ser2net angebunden ist und diese Verbindung steht. Aber wie gesagt, nachgehen werde ich dem Tipp auf jeden Fall.

Das mit dem notify klingt als bessere Lösung gegenüber dem reopen. Allerdings muss ich mir da dann auch überlegen, wie ich das umsetze. Bisher läuft bei mir FHEM2FHEM in diesem Fall ausschließlich als Einbahnstraße.

[Otto123]

Normalerweise macht FHEM2FHEM das völlig selbstständig. Ich habe mehrere F2F am laufen und hatte bei neustart und Phasen der Trennung der beiden noch nie Probleme. Der reconnect klappt normalerweise immer automatisch.
Schließt nicht aus, dass es doch einmal eine faule Situation gibt...

Wenn das jetzt wiederholt nicht geht, dann ist irgendetwas faul. Da würde ich nicht nach einem Workaround sondern nach dem Fehler suchen. Der Begriff Netzwerk ist auch weit fassbar, das kann sonstwas sein. Dabei geht alles andere. Manche Systeme kommen mit Fehlern zurecht, manche nicht.
Viel Erfolg bei der Suche

Gruß Otto

[duke-f]

Da stimme ich Dir absolut zu. Nur ist es eben so, dass der Fehler nun nach monate- oder jahrelangem problemlosem Betrieb ohne großartige Änderung am Rechner mit FHEM2FHEM in den letzten Wochen mittlerweile gerade 4 Mal dieses Phänomen hatte. Trennungen des Netzes oder Neustart des Raspies haben bisher nie Probleme gemacht, die Verbindung wurde immer wieder neu automatisch aufgebaut. Ist damit etwas schwer zu fassen. Mit verbose 5 jetzt die Log aufzublasen halte ich für wenig sinnvoll. Andere Hinweise in den syslogs, die auf Netzprobleme schließen ließen, finde ich auch nicht.

[Prof. Dr. Peter Henning]

Zwischen 3 verschiedenen FHE-Instanzen habe ich 6 FHEM2FHEM-Verbindungen (jeder mit jedem). Und zwar direkt, ohne LIRC oder so etwas. Nachdem ich die Kurzschlüsse beseitigt habe, problemlos.

LG

pah

[R1F800]

Hallo,
ich habe verucht mir eine Variable von einem entfernten fhem System zu holen.

Zielsystem:
define ESPEasy_Gartenhaus_Aussentemp dummy
define TAussen FHEM2FHEM 192.168.0.11:7072 LOG:ESPEasy_Gartenhaus_Aussentemp

Soweit so gut.
Seitdem ist die FHEM Instanz gähnend lahm und auch der Wert des entfernten Temperaturfühlers wird nicht übertragen.
Habt ihr eine Idee?


Im eventmonitor  erscheint immer connected .... disconnected

[Otto123]

Hi,

mach mal bitte auf der Quellinstanz

Code Auswählen Erweitern

list telnetPort

Gruß Otto

[CoolTux]

Hallo Otto,

Sollte nicht der Telnet auf der Zielinstanz laufen. Immerhin initialisierst Du ja einen telnet Client auf den QuellFHEM und willst Dich auf den ZielFHEM auf Telnet Port verbinden.
Oder meintest Du was anderes?

Grße

[Otto123]

Nein es ist doch so: Auf der Quelle läuft telnetPort und auf dem Ziel verbindet sich die F2F Instanz zu der Quelle.
Die Daten werden von Quelle nach Ziel übertragen.
FHEM2FHEM ist doch der Telnet Client?

Also zumindest ist es bei mir so: schließe ich auf der Quelle den telnetPort ist F2F auf dem Ziel anschließend disconnected.

Ergo will ich prüfen, ob auf der Quelle wirklich telnetPort definiert ist. Ist ja bei neuen System erstmal nicht mehr.

[CoolTux]

Ich glaube wir haben beide Recht. Wir denken Seitenverkehrt.


Die Quelle ist für mich das wo der Telnetprozess initialisiert wird, also am Ende wo ich die Daten haben will. Das Ziel ist von wo ich mir die Daten hole.

Am Ende stimmt beides. Also schau auf das System nach dem Telnet Device wo nicht FHEM2FHEM drauf läuft 

[Otto123]

Naja und Ingo hatte meine Gedankenrichtung ja so angenommen  Er hat auf dem "Ziel" FHEM2FHEM

[duke-f]

Für uns Dummies: Die Telnet-Sichtweise ist also entgegen der Datenrichtung ?!

Vielleicht noch ein Tipp: In solchen Fällen kann schon mal Freezemon der Suche nach Ursache hilfreich sein.

[CoolTux]

Die Sichtweise ist eigentlich immer die Richtung des Verbindungsaufbaus. Also wer startet die Verbindung. Und das ist immer der Client. Für FHEM2FHEM heißt das also, immer da wo die Instanz definiert ist ist der Verbindungsaufbauer.

[Otto123]

Vielleicht hat man einfach zwei Sichtweisen/Flussrichtungen:

Telnet
Client    -> Server
F2F       -> telnetPort
Daten
Dummy <- Original Device

Gruß Otto

[duke-f]

Will ja nicht Klugscheißern, aber hängt die Sichtweise nicht immer irgendwie vom Betrachter ab?

[R1F800]

Internals:
   CONNECTS   459
   DEF        7072 global
   FD         5
   FUUID      5c48ae86-f33f-0b1b-4957-ac4608784ba0c2ea
   NAME       telnetPort
   NR         2
   PORT       7072
   STATE      Initialized
   TYPE       telnet
   READINGS:
     2019-03-06 10:16:56   state           Initialized
Attributes:


Aber wie gesagt, das Zielsystem, welches die Daten pullt ist nach meinem Eindruck überlastet. Es dauert alles total lange ... pageaufbau, putty Zugriff etc.

[Otto123]

Dann wäre dieses regexp das Problem:
LOG:ESPEasy_Gartenhaus_Aussentemp

Kannst Du mal im Eventmonitor schauen was mit dem Filter ESPEasy_Gartenhaus_Aussentemp.* so passiert? Auf beiden Seiten? Eigentlich sollte ein einzelnen Device nicht das Problem sein.
Meist liegt "gähnend langsam" daran, das man F2F in beide Richtungen definiert hat. Hast Du?

Gruß Otto

[R1F800]

Hallo,
nein, F2F läuft nur auf einem device.


Quelle:
2019-03-08 09:46:53 ESPEasy ESPEasy_Gartenhaus_Aussentemp presence: present
2019-03-08 09:46:53 ESPEasy ESPEasy_Gartenhaus_Aussentemp Tem: 6.5

Ziel:
2019-03-08 09:48:40 FHEM2FHEM TAussen DISCONNECTED
2019-03-08 09:48:40 FHEM2FHEM TAussen CONNECTED
2019-03-08 09:48:45 FHEM2FHEM TAussen DISCONNECTED
2019-03-08 09:48:45 FHEM2FHEM TAussen CONNECTED
2019-03-08 09:48:45 FHEM2FHEM TAussen CONNECTED

[CoolTux]

Ich würde ja behaupten das Dein Netzwerk nicht stabil ist.

[R1F800]

Ich würde ja behaupten das Dein Netzwerk nicht stabil ist.

Ach ja, woher nimmst Du Deine Erkenntnis?

Und wieso gibt es "NUR" mit fhem2FHEM Probleme? Sämtliche ESP8266 laufen, Hue läuft etc .

[Otto123]

und die IP stimmt ? 192.168.0.11

Und das System auf dieser IP läuft ansonsten ruhig? Mal mit Top geschaut?

[R1F800]

und die IP stimmt ? 192.168.0.11

Und das System auf dieser IP läuft ansonsten ruhig? Mal mit Top geschaut?

Ja genau.
Das FHEM webfrontend läuft sehr flüssig

[Otto123]

Also wenn Du FHEM2FHEM mit einem Device einrichtest und das System läuft anschließend träge und macht einen ständigen Wechsel von connnect und disconnect dann stimmt was nicht. Ich habe mehrere F2F Instanzen mit mehreren Devices, das merkt man überhaupt nicht.
Mach mal zur Kontrolle auf beiden Systemen

Code Auswählen Erweitern

list TYPE=FHEM2FHEM
Geht von der FHEM Instanz aus wo F2F läuft (laufen soll)

Code Auswählen Erweitern

{qx(perl fhem.pl  192.168.0.11:7072 "list")} in der FHEM Kommandozeile?

Ansonsten weiß ich es nicht. 

Gruß Otto

[Wernieman]

also ich würde auch im Netzwerkbereich suchen. Andauernde Connekt/Disconnect hören sich nicht gut an.

Für Fehlersuche könnte man auch mal im Syslog/Kernlog schauen ...

[R1F800]

Also wenn Du FHEM2FHEM mit einem Device einrichtest und das System läuft anschließend träge und macht einen ständigen Wechsel von connnect und disconnect dann stimmt was nicht. Ich habe mehrere F2F Instanzen mit mehreren Devices, das merkt man überhaupt nicht.
Mach mal zur Kontrolle auf beiden Systemen

Code Auswählen Erweitern

list TYPE=FHEM2FHEM
Geht von der FHEM Instanz aus wo F2F läuft (laufen soll)

Code Auswählen Erweitern

{qx(perl fhem.pl  192.168.0.11:7072 "list")} in der FHEM Kommandozeile?

Ansonsten weiß ich es nicht. 

Gruß Otto

ZIEL:
   CFGFN     
   DEF        192.168.0.11:7072 LOG:ESPEasy_Gartenhaus_Aussentemp
   FD         4
   FUUID      5c822ac1-f33f-fa48-d79f-c3724656ee71b4e0
   Host       192.168.0.11:7072
   NAME       TAussen
   NR         99
   PARTIAL   
   STATE      connected
   TYPE       FHEM2FHEM
   informType LOG
   regexp     ESPEasy_Gartenhaus_Aussentemp
Attributes:
   room       F2F


was ist mit Security issues rund um das TELNET Socket ?

[Otto123]

Also der qx Befehl geht nicht? Dann geht die Telnet Schnittstelle nicht.

Issues die die Kommunikation verhindern gibt es per default nicht, es sei denn Du hast welche eingebaut

[R1F800]

also ich würde auch im Netzwerkbereich suchen. Andauernde Connekt/Disconnect hören sich nicht gut an.

Für Fehlersuche könnte man auch mal im Syslog/Kernlog schauen ...

syslog /kernlog des Zielsystems kommt der PI mit einem W1_master_driver W1_Busmastereintrag jede Min um die Ecke ...?
Vielleicht durch einen alten Test ..

interessanterweise kommt das auf dem Quellsystem auch ...

[Otto123]

gibt es denn FHEM Log Einträge bez. telnet auf dem 192.168.0.11 ?

[CoolTux]

Nimm einfach Mal einen telnet Client und verbinde Dich mit dem telnet Server von FHEM.

[R1F800]

Nimm einfach Mal einen telnet Client und verbinde Dich mit dem telnet Server von FHEM.

Mit dem WIN 10 telnet client kann keine Verbindung zum HOST hergestellt werden.
Also kein Connect auf das Socket möglich.  IP:Port#

Sorry.. hatte die falsche Syntax  IP Port#
Jetzt fragt er nach dem Passwort - wenn ich das eingebe verliehrt er die Verbindung ... "Verbindung zu Host verloren"

Wie gesagt mit putty (ssh) komme ich auf den PI ja drauf.

Ich habe jetz einmal TELNET aktiv auf dem PI nachinstalliert

Code Auswählen Erweitern

sudo apt-get install telnetd

Ich werde morgen wieder berichten

[CoolTux]

Du bringst da was durcheinander. Ssh und putty und Pi ist ganz was anderes. Das ist das System.
Wir reden von FHEM als Anwendung und die verwendet unteranderem als Möglichkeit einer Verbindung das telnetprotokoll. Es läuft also ein telnet Server für die Kommunikation mit FHEM.
So. Also was hast du genau gemacht? telnet ip-fhem 7072 sollte dein Aufruf im Normalfall sein. Was passiert dann?

[R1F800]

Du bringst da was durcheinander. Ssh und putty und Pi ist ganz was anderes. Das ist das System.
Wir reden von FHEM als Anwendung und die verwendet unteranderem als Möglichkeit einer Verbindung das telnetprotokoll. Es läuft also ein telnet Server für die Kommunikation mit FHEM.
So. Also was hast du genau gemacht? telnet ip-fhem 7072 sollte dein Aufruf im Normalfall sein. Was passiert dann?

ich habe auf meinem WIN10 system den Telnet Client zur Hand genommen und dann via Socket auf den PI zugreifen wollen ... die Passwortabfrage kommt und Ende

Putty auch auf der WIN10 Büchse geht über SSH; das weiß ich ...

direkt auf dem PI:

Code Auswählen Erweitern

$ telnet 127.0.0.1
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Raspbian GNU/Linux 8
Zaehlertafel login: pi
Password:
Last login: Fri Mar  8 19:38:39 CET 2019 from office.fritz.box on pts/1
Linux Zaehlertafel 4.19.25-v7+ #1205 SMP Mon Feb 25 18:19:20 GMT 2019 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
pi@Zaehlertafel:~ $


[CoolTux]

Sorry ich glaube ich verstehe Dich da nicht ganz.
Bist du so nett und schreibst mir kurz den kompletten telnet Befehl das ich sehe was du gemacht hast?
Und dann wäre ein list vom allowed Device welches dem telnet Device zugeordnet ist noch gut. Also so fern vorhanden.

[Otto123]

@Cooltux: Da ich dieses Schlamassel mit telnet irgendwie geahnt hatte, hatte ich ja das list über fhem.pl probieren wollen.

@R1F800 Hattest Du jetzt den Befehl aus #25 probiert oder nicht? Kam was zurück oder nicht? Gab es auf beiden Seiten irgendwelche Einträge im Log?

Gruß Otto

[CoolTux]

Das telnet auf localhost ist falsch. Dir fehlt die Angabe des Ports.
Also wenn dann

Code Auswählen Erweitern


telnet localhost 7072

Was passiert wenn du das auf dem pi aus führst? Also mit SSH auf dem pi anmelden und dann den telnet Befehl aus führen.
Und bitte Ottos letzten Post beachten.

[R1F800]

@Cooltux: Da ich dieses Schlamassel mit telnet irgendwie geahnt hatte, hatte ich ja das list über fhem.pl probieren wollen.

@R1F800 Hattest Du jetzt den Befehl aus #25 probiert oder nicht? Kam was zurück oder nicht? Gab es auf beiden Seiten irgendwelche Einträge im Log?

Gruß Otto

zum LIST Befehl das habe ich reinkopiert ...
zum anderen kam nichts zurück.

[R1F800]

Das telnet auf localhost ist falsch. Dir fehlt die Angabe des Ports.
Also wenn dann

Code Auswählen Erweitern


telnet localhost 7072

Was passiert wenn du das auf dem pi aus führst? Also mit SSH auf dem pi anmelden und dann den telnet Befehl aus führen.
Und bitte Ottos letzten Post beachten.

Code Auswählen Erweitern

telnet localhost 7072
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.


[CoolTux]

Das sieht erstmal okay aus. Und das hast du jetzt auf dem pi gemacht mit dem FHEM wo Du NICHT das FHEM2FHEM Device angelegt hast?

[Otto123]

Wie sind die IPs von beiden Instanzen?

NOTE: if this attribute is not defined and there is no valid allowed device defined for the telnet/FHEMWEB instance and the client tries to connect from a non-local net, then the connection is refused. Following is considered a local net:
IPV4: 127/8, 10/8, 192.168/16, 172.16/10, 169.254/16
IPV6: ::1, fe80/10

Es gab im LOG von dem wo F2F nicht definiert ist keinen Hinweis auf Ablehnung der Telnetverbindung? Funktioniert das LOG dort überhaupt?

[Wernieman]

Hast Du OneWire Sensoren dran?

Kenne ich so nicht vom Pi ....

[abc2006]

Moin zusammen,
ich häng mich mal dazwischen, weil ich seit ein paar Tagen ein ähnliches Problem habe.

Ich besitze einen Hauptrechner, der das gesamte Logging und Monitoring macht, ja, und noch so ein paar Schaltaufgaben nebenbei (licht), an denen man super merkt, wenn was nicht stimmt.
Dazu besitze ich seit drei Raspberry Pi, die mit der Hauptinstanz über FHEM2FHEM verbunden sind.

hzfhem und hvfhem laufen seit langem problemlos, pvfhem kam jetzt dazu. Seitdem reagiert mein Hauptsystem mega träge und sammelt sich die Events an (Lichtschalter drücken - passiert nix. Nochmal drücken - passiert immer noch nix. Fluchend im Dunkeln zum Kühlschrank laufen - Licht geht an, aus, an, aus - je nachdem wie oft ich gedrückt habe.
Deshalb habe ich mit apptime nach dem Problem gesucht:

Code Auswählen Erweitern

active-timers: 125; max-active timers: 129; max-timer-load: 5  min-tmrHandlingTm: 0.2ms; max-tmrHandlingTm: 42.2ms; totAvgDly: 821.4ms

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
  pvfhemTOfhem                             FHEM2FHEM_Read                         521      140   50523.43   360.88     0.00     0.00 09.03. 12:06:07 HASH(pvfhemTOfhem)
hzfhemTOfhem                             FHEM2FHEM_Read                         591       12    3267.86   272.32     0.00     0.00 09.03. 11:13:37 HASH(hzfhemTOfhem)
hvfhemTOfhem                             FHEM2FHEM_Read                         410       12    2405.51   200.46     0.00     0.00 09.03. 11:14:01 HASH(hvfhemTOfhem)

Und wundere mich jetzt, dass der Raspberry, der immer mal ein paar Werte überträgt, so viel schlechter da steht, als die anderen beiden, die hunderte Werte pro minute aktualisieren bzw. 4-5 Werte alle paar Sekunden.

Nachdem ich den Thread gelesen hab, werd ich erstmal das Netzwerkkabel tauschen... bin mal gespannt, ob es dann weg ist - und reiner Zufall, dass zweimal das gleiche Problem zeitgleich auftritt - oder ob es doch einen anderen Grund hat...

Warum eigentlich hängt die Instanz, in der F2F definiert ist, wenn der remote nichts liefert/nicht erreichbar ist/sonstwie probleme macht?


Grüße,
Stephan

[abc2006]

Hast Du OneWire Sensoren dran?

Habe ich an hvfhem angeschlossen - keine Probleme...

Grüße,
Stephan

[R1F800]

Wie sind die IPs von beiden Instanzen?Es gab im LOG von dem wo F2F nicht definiert ist keinen Hinweis auf Ablehnung der Telnetverbindung? Funktioniert das LOG dort überhaupt?

Nein.
Kein Eintrag, zumindest habe ich keinen gefunden.

192.168.0.11  und 192.168.0.31

Wie gesagt:
1) keine Verbindung zum entfernten System   mit Telnet von WIN20 Client > Kein Problem, localhost > kein Problem 
Kann es vielleicht sein das der Telnet vom PI selber nicht rausgelassen wird ? interne Firewall des PI ?

2) System mit F2F Definition wird fast bis zum existus langsam.... (Problem beim FHEM2FHEM Modul ?)

[Otto123]

Bist Du so weit in der Zukunft (WIN20) oder ist das was, was ich nicht kenne? 

Per default gibt es keine Regel die das verhindert. Wenn dein Pi nicht per Telnet an das entfernte System kommt, musst Du da weiter suchen.

Wenn FHEM2FHEM keine klare Ablehnung vom entfernten System bekommt, habe ich keine Ahnung was da passieren kann. 
Wenn mal F2F keine Verbindung bekommt ist das kein Problem. Ich habe einige F2F am laufen, ich glaube nicht, dass es da ein internes Problem gibt.

Wobei das hier:

Ich habe jetz einmal TELNET aktiv auf dem PI nachinstalliert
Code: [Auswählen]
sudo apt-get install telnetd

nicht zielführend war. Das hätte gereicht:

Code Auswählen Erweitern

sudo apt-get install telnet

Gruß Otto

[Wernieman]

Und beim Verbinden einfach mal den Verbose-level hochdrehen. Die meisten Unix-Befehle kennen so etwas: "-v"

Bei telnet allerdings "-d" (wie in Debug)

Siehe "man File":
"man telnet"

[R1F800]

Manchmal bin ich echt sprachlos, was ein Neustart so alles kann :

System das ich mittels Fhem2FHem  auslesen will *.*.*.11

Code Auswählen Erweitern

2019.03.15 15:31:40 3: Login denied via telnetPort_192.168.0.31_47054

Quellsystem von dem aus der Zugriff erfolgen soll: *.*.*.31

Code Auswählen Erweitern

2019.03.15 15:31:40 1: FHEM2FHEM 192.168.0.11:7072 reappeared (TAussen)
2019.03.15 15:31:40 1: 192.168.0.11:7072 disconnected, waiting to reappear

[Wernieman]

Hat sich die IP geändert?

[R1F800]

Hat sich die IP geändert?

wie sollte sich die IP ändern? und wo?

Nein.

[Wernieman]

Durch den reboot ... wie vergiebst Du denn die netzwerkaresse?

War auch nur ein Schnellschuß .. warum sollte durch einen reboot sich die Daten ändern .. außer Du hättest in FHEM nicht auf "speichern" gedrückt ...

[R1F800]

Durch den reboot ... wie vergiebst Du denn die netzwerkaresse?

War auch nur ein Schnellschuß .. warum sollte durch einen reboot sich die Daten ändern .. außer Du hättest in FHEM nicht auf "speichern" gedrückt ...

FHEM hat immer ein und die Gleiche IP bei jeder einzelnen FHEM INstanz.
Da ist die MAC Routing Table der Fritz Box führend.

[R1F800]

Bist Du so weit in der Zukunft (WIN20) oder ist das was, was ich nicht kenne? 

Per default gibt es keine Regel die das verhindert. Wenn dein Pi nicht per Telnet an das entfernte System kommt, musst Du da weiter suchen.

Wenn FHEM2FHEM keine klare Ablehnung vom entfernten System bekommt, habe ich keine Ahnung was da passieren kann. 
Wenn mal F2F keine Verbindung bekommt ist das kein Problem. Ich habe einige F2F am laufen, ich glaube nicht, dass es da ein internes Problem gibt.

Wobei das hier: nicht zielführend war. Das hätte gereicht:

Code Auswählen Erweitern

sudo apt-get install telnet

Gruß Otto

Kannst Du mir vielleicht mal ein Besipiel von Deinem FHEM2FHEM posten ?
also die Definition bei der Quell Instamz und die bei der Ziel (Pull) Instanz?

Müssen für das Telnet ggf. noch Passwort Attribute im GLOBAL gesetzt werden?

[Otto123]

Moin,

ich hatte deinen Aussage in #48 irgendwie nicht verstanden. Ich dachte Du hättest den Fehler gefunden ...

Hast Du eine allowed Instanz?

Code Auswählen Erweitern

list TYPE=allowed

Mach doch einfach mal eine neue telnetPort Instanz und verwende diese?

Code Auswählen Erweitern

define telnetPort2 telnet 7074 global und ändere den Port in deiner FHEM2FHEM Instanz.
Ansonsten ist es simpel:
Die F2F Instanz auf raspib3

Code Auswählen Erweitern

defmod F2Fb FHEM2FHEM raspib:7072 LOG:Lamp|wert|wetter.(fc0_rain:.*|state.*)|.*Temperatur:|WL_.*

Auf raspib gibt es die Geräte die im regExp stehen
Auf raspib3 gibt es Dummys mit entsprechenden Namen.

Gruß Otto

[R1F800]

"Sender und Empfänger"
allowed_WEB
allowed_WEBphone
allowed_WEBtablet
allowed_telnetPort

scheiss die Wand an ...
auf beiden Instanzen den TELNET Port verbogen ... altes Device gelöscht :

System reagiert wieder schnell
System hat nun im LOG den Wert des entfernten FHEM :
2019.03.17 13:04:10 4: ESPEasy_Gartenhaus_Aussentemp: ESPEasy ESPEasy_Gartenhaus_Aussentemp Temperature: 11.0
2019.03.17 13:04:10 4: ESPEasy_Gartenhaus_Aussentemp: ESPEasy ESPEasy_Gartenhaus_Aussentemp Tem: 11.0

Jetzt fehlt mit noch die ordentliche Aufbereitung der variablen  - bis jetzt sehe ich nur

[Otto123]

Wie lautet dein define für FHEM2FHEM?

[R1F800]

defmod F2Fb FHEM2FHEM 192.168.0.11:7074 LOG:ESPEasy_Gartenhaus_Aussentemp

Ich habe dem DUMMY dann ein STATEFORMAT verpasst:

Stateformat Temperature °C

et voila :
ESPEasy_Gartenhaus_Aussentemp  6.1 °C

[R1F800]

Moin,

ich hatte deinen Aussage in #48 irgendwie nicht verstanden. Ich dachte Du hättest den Fehler gefunden ...

Hast Du eine allowed Instanz?

Code Auswählen Erweitern

list TYPE=allowed

Mach doch einfach mal eine neue telnetPort Instanz und verwende diese?

Code Auswählen Erweitern

define telnetPort2 telnet 7074 global und ändere den Port in deiner FHEM2FHEM Instanz.
Ansonsten ist es simpel:
Die F2F Instanz auf raspib3

Code Auswählen Erweitern

defmod F2Fb FHEM2FHEM raspib:7072 LOG:Lamp|wert|wetter.(fc0_rain:.*|state.*)|.*Temperatur:|WL_.*

Auf raspib gibt es die Geräte die im regExp stehen
Auf raspib3 gibt es Dummys mit entsprechenden Namen.

Gruß Otto

warum das jetzt mit dem anderen PORT klappt verstehe ich nicht !

[Otto123]

Naja Du hast ein/mehrere  allowed Definitionen. Die schränken den Zugang zum zu den Funktionen/Ports ein. Du musst bloß dorthinein schauen und kannst sicher erkennen warum es mit Port 7072 nicht klappen konnte. Mit der neuen DEF und Port 7074 hast Du jetzt einen offenen Telnet Zugang.

Potentiell stellt das eine Gefährdung dar, ob die relevant ist musst Du selbst wissen. Du kannst jetzt:

• Den Zugang auf 192.168.0.11 zu telnetPort (7072) wieder herstellen und den weiter verwenden,
• oder den Zugang zu telnetPort2 (7074) mit einem allowed Device absichern,
• oder einfach alles so lassen.

Aber ich würde an Deiner Stelle aufräumen und es "ordentlich" machen. Sonst stehst Du in einem halben Jahr vor einem ähnlichen Problem und weisst nicht mehr warum.

Gruß Otto

[R1F800]

Naja Du hast ein/mehrere  allowed Definitionen. Die schränken den Zugang zum zu den Funktionen/Ports ein. Du musst bloß dorthinein schauen und kannst sicher erkennen warum es mit Port 7072 nicht klappen konnte. Mit der neuen DEF und Port 7074 hast Du jetzt einen offenen Telnet Zugang.

Potentiell stellt das eine Gefährdung dar, ob die relevant ist musst Du selbst wissen. Du kannst jetzt:

• Den Zugang auf 192.168.0.11 zu telnetPort (7072) wieder herstellen und den weiter verwenden,
• oder den Zugang zu telnetPort2 (7074) mit einem allowed Device absichern,
• oder einfach alles so lassen.

Aber ich würde an Deiner Stelle aufräumen und es "ordentlich" machen. Sonst stehst Du in einem halben Jahr vor einem ähnlichen Problem und weisst nicht mehr warum.

Gruß Otto

JETZT KLICK ...
Also, der ALLOWED TelnetPort für 7072 hatte meine Passwortfefinition für globalpasswort ...
Naja und wenn ich dann mittels TelNet daherkomme und kein Passwort in den credentials mitbrnge kann es gar nciht anders sein, als dass die connection rejected wird ...