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
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
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
Zitat von: duke-f am 29 September 2017, 10:00:18
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.
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.
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
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.
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
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.
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
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
Hi,
mach mal bitte auf der Quellinstanz list telnetPort
Gruß Otto
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
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.
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 ;D
Naja und Ingo hatte meine Gedankenrichtung ja so angenommen ;D Er hat auf dem "Ziel" FHEM2FHEM :)
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.
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.
Vielleicht hat man einfach zwei Sichtweisen/Flussrichtungen:
Telnet
Client -> Server
F2F -> telnetPort
Daten
Dummy <- Original Device
Gruß Otto
Will ja nicht Klugscheißern, aber hängt die Sichtweise nicht immer irgendwie vom Betrachter ab? ;)
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.
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
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
Ich würde ja behaupten das Dein Netzwerk nicht stabil ist.
Zitat von: CoolTux am 08 März 2019, 09:50:10
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 .
und die IP stimmt ? 192.168.0.11
Und das System auf dieser IP läuft ansonsten ruhig? Mal mit Top geschaut?
Zitat von: Otto123 am 08 März 2019, 10:44:29
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
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 list TYPE=FHEM2FHEM
Geht von der FHEM Instanz aus wo F2F läuft (laufen soll) {qx(perl fhem.pl 192.168.0.11:7072 "list")} in der FHEM Kommandozeile?
Ansonsten weiß ich es nicht. :-[
Gruß Otto
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 ...
Zitat von: Otto123 am 08 März 2019, 11:45:44
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 list TYPE=FHEM2FHEM
Geht von der FHEM Instanz aus wo F2F läuft (laufen soll) {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 ?
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 :)
Zitat von: Wernieman am 08 März 2019, 13:56:46
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 ...
gibt es denn FHEM Log Einträge bez. telnet auf dem 192.168.0.11 ?
Nimm einfach Mal einen telnet Client und verbinde Dich mit dem telnet Server von FHEM.
Zitat von: CoolTux am 08 März 2019, 16:51:56
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 :-)
sudo apt-get install telnetdIch werde morgen wieder berichten
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?
Zitat von: CoolTux am 08 März 2019, 19:38:06
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:
$ 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:~ $
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.
@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
Das telnet auf localhost ist falsch. Dir fehlt die Angabe des Ports.
Also wenn dann
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.
Zitat von: Otto123 am 08 März 2019, 20:48:50
@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.
Zitat von: CoolTux am 08 März 2019, 20:53:40
Das telnet auf localhost ist falsch. Dir fehlt die Angabe des Ports.
Also wenn dann
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.
telnet localhost 7072
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
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?
Wie sind die IPs von beiden Instanzen?
ZitatNOTE: 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?
Hast Du OneWire Sensoren dran?
Kenne ich so nicht vom Pi ....
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:
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
Zitat von: Wernieman am 09 März 2019, 12:07:50
Hast Du OneWire Sensoren dran?
Habe ich an hvfhem angeschlossen - keine Probleme...
Grüße,
Stephan
Zitat von: Otto123 am 09 März 2019, 11:35:01
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 ?)
Bist Du so weit in der Zukunft (WIN20) oder ist das was, was ich nicht kenne? ;D
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:
ZitatIch 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:
sudo apt-get install telnetGruß Otto
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"
Manchmal bin ich echt sprachlos, was ein Neustart so alles kann :
System das ich mittels Fhem2FHem auslesen will *.*.*.11
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
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
Hat sich die IP geändert?
Zitat von: Wernieman am 16 März 2019, 10:57:20
Hat sich die IP geändert?
wie sollte sich die IP ändern? und wo?
Nein.
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 ...
Zitat von: Wernieman am 16 März 2019, 14:17:03
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.
Zitat von: Otto123 am 15 März 2019, 10:36:13
Bist Du so weit in der Zukunft (WIN20) oder ist das was, was ich nicht kenne? ;D
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: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?
Moin,
ich hatte deinen Aussage in #48 irgendwie nicht verstanden. Ich dachte Du hättest den Fehler gefunden ...
Hast Du eine allowed Instanz?
list TYPE=allowed
Mach doch einfach mal eine neue telnetPort Instanz und verwende diese?
define telnetPort2 telnet 7074 global und ändere den Port in deiner FHEM2FHEM Instanz.
Ansonsten ist es simpel:
Die F2F Instanz auf raspib3
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
"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 ???
Wie lautet dein define für FHEM2FHEM?
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
Zitat von: Otto123 am 17 März 2019, 12:27:36
Moin,
ich hatte deinen Aussage in #48 irgendwie nicht verstanden. Ich dachte Du hättest den Fehler gefunden ...
Hast Du eine allowed Instanz?
list TYPE=allowed
Mach doch einfach mal eine neue telnetPort Instanz und verwende diese?
define telnetPort2 telnet 7074 global und ändere den Port in deiner FHEM2FHEM Instanz.
Ansonsten ist es simpel:
Die F2F Instanz auf raspib3
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 !
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
Zitat von: Otto123 am 17 März 2019, 17:34:33
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 ...