Wenn ich per telnet auf mein FHEM zugreifen möchte, erlebe ich ein merkwürdiges Verhalten:
pi@pi4:~ $ telnet pi3 7072
Trying 192.168.1.4...
Connected to pi3.
Escape Character is '^]'.
Nichts weiter, kein Prompt, nichts. Also drücke ich Return. Antwort:
Unknown command, try help.
Drücke ich noch mal Return:
Unknown command, try help.
Unknown command, try help.
Mir fällt auf, dass das Return zwar ein LF aber kein CR auslöst. Muss das so sein?
Nochmals Return:
Unknown command, try help.
Unknown command, try help.
Unknown command, try help.
fhem>
Da erscheint dann erstmals ein Prompt und danach kann man dann auch FHEM-Kommandos eingeben. Dies ist so reproduzierbar: 3 Mal Unknown command, dann kann man mit FHEM kommunizieren. Und übrigens auch unabhängig davon, ob ich nur ein Return sende oder ein gültiges Kommando eingebe, wie z.B. ''help''.
Hintergrund: Ich versuche gerade, ioBroker auf einem anderen Pi zu installieren, aber bereits die initiale Verbindung mit FHEM haut nicht hin. Laut Dokumentation versucht ioBroker zuerst einmal, die FHEM-Konfiguration mit ''jsonlist2'' per telnet auszulesen. Schon da scheitert die Kommunikation und der FHEM-Adapter geht auf 'gelb'. Für mich sieht es so aus, als ob das mit dem eigenartigen telnet-Verhalten zusammenhängt.
OS und FHEM sind auf dem neusten Stand, ein telnet-Password ist nicht gesetzt und SSL ist auch nicht eingeschaltet.
Kann mir da jemand einen Tipp geben?
was steht denn im log??
und wie sieht das list von dem device aus??
Zitat von: nils_ am 04 Dezember 2017, 11:10:53
was steht denn im log??
Nichts. Warum sollte da auch etwas stehen? Es wurde ja nichts gesendet.
Zitat von: nils_ am 04 Dezember 2017, 11:10:53
und wie sieht das list von dem device aus??
Welches Device? Ich versuche mich mit fhem via telnet zu verbinden. Da ist (noch) kein Device im Spiel.
Zitat von: aloss am 04 Dezember 2017, 11:18:36
Nichts. Warum sollte da auch etwas stehen? Es wurde ja nichts gesendet.
sicher? mal reingeschaut??
evtl. ein fehler beim starten?
fehler beim verbinden ??
fehler bei der commando-auswertung ??
nicht zulässige def's in einer händisch editierten cfg...
es funkt dir was anderes dazwischen....
mir würden da schon noch einige sachen einfallen.
Zitat von: aloss am 04 Dezember 2017, 11:18:36
Welches Device? Ich versuche mich mit fhem via telnet zu verbinden. Da ist (noch) kein Device im Spiel.
ein telnet device? https://fhem.de/commandref_DE.html#telnet
Hmm. Ich checke das heute Abend mal, bin im Moment unterwegs.
So, habe gerade FHEM neu gestartet. Hier das Log davon:
2017.12.04 13:50:37 1: Including fhem.cfg
2017.12.04 13:50:37 1: Including myConfigs/01_Basics.cfg
2017.12.04 13:50:37 1: Including myConfigs/02_Web_Telnet.cfg
2017.12.04 13:50:37 3: telnetPort: port 7072 opened
2017.12.04 13:50:37 3: WEB: port 8083 opened
2017.12.04 13:50:37 1: Including myConfigs/03_CUL.cfg
2017.12.04 13:50:37 3: FHZ opening FHZ device /dev/serial/by-id/usb-ELV_AG_ELV_FHZ_1300_PC_EL65DBGU-if00-port0
2017.12.04 13:50:37 3: FHZ opened FHZ device /dev/serial/by-id/usb-ELV_AG_ELV_FHZ_1300_PC_EL65DBGU-if00-port0
2017.12.04 13:50:39 3: Opening CUL0 device /dev/serial/by-id/usb-busware.de_CUL868-if00
2017.12.04 13:50:39 3: CUL0: Possible commands: BbCFiAZNkGMKUYRTVWXefmLltux
2017.12.04 13:50:39 3: CUL0 device opened
2017.12.04 13:50:39 2: Switched CUL0 rfmode to HomeMatic
2017.12.04 13:50:39 1: Including myConfigs/04_Homebridge.cfg
2017.12.04 13:50:39 1: Including myConfigs/10_Gaestezimmer.cfg
2017.12.04 13:50:39 1: Including myConfigs/11_Kueche.cfg
2017.12.04 13:50:39 1: Including myConfigs/12_Wohnzimmer.cfg
2017.12.04 13:50:39 1: Including myConfigs/13_Flur_Treppe.cfg
2017.12.04 13:50:39 1: Including myConfigs/14_Schlafzimmer.cfg
2017.12.04 13:50:39 1: Including myConfigs/15_Lounge.cfg
2017.12.04 13:50:39 1: Including myConfigs/16_Buero.cfg
2017.12.04 13:50:39 1: Including myConfigs/17_Bad_OG.cfg
2017.12.04 13:50:40 1: Including myConfigs/18_Keller.cfg
2017.12.04 13:50:40 1: Including myConfigs/19_Funksteckdosen.cfg
2017.12.04 13:50:40 1: Including myConfigs/20_Fensterkontakte.cfg
2017.12.04 13:50:41 1: Including myConfigs/30_Wall.E.cfg
2017.12.04 13:50:43 2: Registering INDEGO Wall.E for URL /INDEGO/Wall.E/map...
2017.12.04 13:50:43 1: Including myConfigs/31_Garage.cfg
2017.12.04 13:50:43 1: Including myConfigs/32_Pool.cfg
2017.12.04 13:50:43 1: Including myConfigs/33_Poolbar.cfg
2017.12.04 13:50:43 1: Including myConfigs/34_Garten.cfg
2017.12.04 13:50:43 1: Including myConfigs/40_Rooms.cfg
2017.12.04 13:50:43 1: Including myConfigs/41_Structures.cfg
2017.12.04 13:50:43 1: Including myConfigs/42_Devices_OnOff.cfg
2017.12.04 13:50:43 1: Including myConfigs/43_Groups.cfg
2017.12.04 13:50:43 1: Including myConfigs/50_Szenarien.cfg
2017.12.04 13:50:43 1: Including myConfigs/70_Wetter.cfg
2017.12.04 13:50:44 1: Including myConfigs/71_Floorplan.cfg
2017.12.04 13:50:44 1: Including myConfigs/72_Anwesenheitserkennung.cfg
2017.12.04 13:50:44 2: Registering GEOFANCY geofency for URL /geo...
2017.12.04 13:50:44 1: Including myConfigs/73_RemoteFHEM.cfg
2017.12.04 13:50:44 1: Including myConfigs/90_at-Schaltpunkte.cfg
2017.12.04 13:50:44 1: Including myConfigs/91_at-Weihnachtsbaum.cfg
2017.12.04 13:50:44 1: Including myConfigs/96_Siri.cfg
2017.12.04 13:50:44 1: Including myConfigs/97_messenger.cfg
2017.12.04 13:50:44 1: Including myConfigs/98_Spielwiese.cfg
2017.12.04 13:50:44 1: Including ./log/fhem.save
2017.12.04 13:50:45 3: No I/O device found for ITSteck03
2017.12.04 13:50:45 3: No I/O device found for ITSteck01
2017.12.04 13:50:45 3: Device HM_41865E added to ActionDetector with 000:10 time
2017.12.04 13:50:45 3: Device HM_598CDE added to ActionDetector with 002:50 time
2017.12.04 13:50:45 3: Device TerrassentuerKontakt added to ActionDetector with 002:50 time
2017.12.04 13:50:45 1: usb create starting
2017.12.04 13:50:45 3: Probing CUL device /dev/ttyAMA0
2017.12.04 13:50:46 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.12.04 13:50:46 3: Probing ZWDongle device /dev/ttyAMA0
2017.12.04 13:50:46 3: Probing FRM device /dev/ttyAMA0
2017.12.04 13:50:51 3: Probing TCM_ESP3 device /dev/ttyUSB0
2017.12.04 13:50:52 3: Probing TCM_ESP2 device /dev/ttyUSB0
2017.12.04 13:50:52 3: Probing FHZ device /dev/ttyUSB0
2017.12.04 13:50:52 3: Probing TRX device /dev/ttyUSB0
2017.12.04 13:50:53 3: Probing ZWDongle device /dev/ttyUSB0
2017.12.04 13:50:53 3: Probing FRM device /dev/ttyUSB0
2017.12.04 13:50:58 3: Probing TCM_ESP3 device /dev/ttyUSB1
2017.12.04 13:50:58 3: Can't open /dev/ttyUSB1: Das Gerät oder die Ressource ist belegt
2017.12.04 13:50:58 1: usb create end
2017.12.04 13:50:58 0: Featurelevel: 5.8
2017.12.04 13:50:58 0: Server started with 192 defined entities (fhem.pl:15377/2017-11-01 perl:5.020002 os:linux user:fhem pid:3516)
Dann noch das list vom telnet:
telnet:
telnetPort (Initialized)
telnetPort_192.168.1.5_56316 (Connected)
telnetPort_192.168.1.5_56318 (Connected)
(Der 192.168.1.5 ist der pi4, auf dem offenbar noch ioBroker aktiv ist).
Hilft das?
oha.... soviele includes :o
Zitat von: aloss am 04 Dezember 2017, 14:04:16
Dann noch das list vom telnet:
telnet:
telnetPort (Initialized)
telnetPort_192.168.1.5_56316 (Connected)
telnetPort_192.168.1.5_56318 (Connected)
das ist ein _vollständiges_ list vom telnet device?
(ich kanns fast nicht glauben.... aber auch nicht überprüfen.... zweifele aber an dem informationsumfang)
Zitat von: aloss am 04 Dezember 2017, 14:04:16
(Der 192.168.1.5 ist der pi4, auf dem offenbar noch ioBroker aktiv ist).
Hilft das?
nee, der ist ja auch nicht korrekt verbunden laut deiner aussage.
ein log-auszug, wenn du dich per telnet verbindest wäre noch was!
So, da bin ich wieder. Hier noch einmal das list vom Telnet-Device:
Internals:
CFGFN myConfigs/02_Web_Telnet.cfg
CONNECTS 5
DEF 7072 global
FD 9
NAME telnetPort
NR 43
PORT 7072
STATE Initialized
TYPE telnet
Attributes:
encoding utf8
room System
(ioBroker habe ich inzwischen abgewürgt.)
Und hier das log einer telnet-Session mit verbose 5 (2 x Return, dann "exit"):
2017.12.04 20:30:23 5: Starting notify loop for global, 1 event(s), first is ATTR global verbose 5
2017.12.04 20:30:23 5: End notify loop for global
2017.12.04 20:30:23 4: Connection closed for WEB_192.168.178.22_43972: EOF
2017.12.04 20:30:23 4: Connection accepted from WEB_192.168.178.22_43974
2017.12.04 20:30:23 4: WEB_192.168.178.22_43974 GET /fhem?fw_id=1078; BUFLEN:0
2017.12.04 20:30:23 4: WEB: /fhem?fw_id=1078 / RL:1453 / text/html; charset=UTF-8 / Content-Encoding: gzip^M
/
2017.12.04 20:30:23 4: Connection closed for WEB_192.168.178.22_43974: EOF
2017.12.04 20:30:23 4: Connection accepted from WEB_192.168.178.22_43976
2017.12.04 20:30:23 4: WEB_192.168.178.22_43976 GET /fhem?fw_id=1078; BUFLEN:0
2017.12.04 20:30:23 4: WEB: /fhem?fw_id=1078 / RL:1453 / text/html; charset=UTF-8 / Content-Encoding: gzip^M
/
2017.12.04 20:30:23 4: Connection closed for WEB_192.168.178.22_43976: EOF
2017.12.04 20:30:23 4: Connection accepted from WEB_192.168.178.22_43978
2017.12.04 20:30:23 4: WEB_192.168.178.22_43978 GET /fhem?XHR=1&inform=type=status;filter=;since=1512415822;fmt=JSON&fw_id=1078×tamp=1512415823973; BUFLEN:0
2017.12.04 20:30:48 4: Connection accepted from telnetPort_127.0.0.1_39288
2017.12.04 20:30:51 5: Cmd: >ÿû^@<
2017.12.04 20:30:53 5: Cmd: >ÿý^@<
2017.12.04 20:31:02 5: Cmd: >exit<
2017.12.04 20:31:14 4: Connection closed for WEB_192.168.178.22_43978: EOF
2017.12.04 20:31:14 4: Connection accepted from WEB_192.168.178.22_43980
2017.12.04 20:31:14 4: WEB_192.168.178.22_43980 POST /fhem&fw_id=1078&cmd=attr+global+verbose+3; BUFLEN:0
2017.12.04 20:31:14 5: Cmd: >attr global verbose 3<
Entscheidend scheint mit das "Cmd: >ÿû^@<", das genau zwei mal autaucht. Da scheinen sich irgendwelche Zeichen im Puffer zu befinden, die erst nach 2 x Return weg sind. Als Telnet-Client benutze ich das, was bei "apt-get install telnet" geladen wurde.
Probier doch mal eine telnet-Verbindung von einem anderen Rechner (z.B. Windows) um zu überprüfen ob das Problem auf Client oder Server-Seite liegt.
Ich bin kein telnet-Experte, aber es gibt ja eine ganze Reihe von Einstellungen, die das Terminal-handling für telnet beeinflussen (ich meine den UNIX-Telnet befehl).
Das kein CR kommt ist normal, denn LF ist das normale Lineending für UNIX - Hier liegt das Problem wohl auf telnet client seite
Weiterer Hinweis ^@ ist das NUL-Zeichen, auch das spielt in telnet eine Rolle
Sorry für die Verzögerung, ich kann immer nur abends per telnet auf den Pi zugreifen.
Ich habe es nun mit putty lokal auf dem Raspberry Pi als auch mit "nc" vom Mac (der telnet Nachfolger, netcat(?)) probiert. In beiden Fällen kommen nach Verbindungsaufbau erst mal irgendwelche Steuerzeichen an. Wenn ich dann Return drücke (1 mal !) kommt das fhem> Prompt.
Es scheint also so zu sein, dass die Steuerzeichen vom Telnet-Server kommen und ich vermute, dass das der Grund ist, warum mein ioBroker sich nicht mit FHEM verbinden will. Immerhin muss ich bei ioBroker angeben, dass das fhem-prompt "fhem>" ist und darauf wartet er dann wohl.
Wie sieht es denn bei Dir aus, nils_? Bekommst Du unmittelbar ein fhem> prompt nach dem Verbinden oder musst Du auch erst mal ein Return senden (oder gar 2 oder 3)?
Zitat von: aloss am 06 Dezember 2017, 08:36:15
Wie sieht es denn bei Dir aus, nils_? Bekommst Du unmittelbar ein fhem> prompt nach dem Verbinden oder musst Du auch erst mal ein Return senden (oder gar 2 oder 3)?
ich hab es bisher noch nicht gestest.
wenn ich es schaffe, werde ich es mir heute abend mal angucken. (vllt. hat ja noch wer anderes vorher die möglichkeit :) )
hast du mal fhem mit der fhem.cfg.demo gestartet?? (zum testen, das sich da nix in die quere kommt!)
Einmal return drücken bevor der Prompt kommt ist auch bei mir normal.
Allerdings kann man auch direkt ein Kommando eingeben und absenden, das wird dann ausgeführt.
Vielen Dank soweit für Eure Hilfe. Ich fasse meine "Erkenntnisse" hier mal kurz zusammen:
- Der Standard-telnet-Client, den ich mit apt-get install telnet geliefert bekommen habe verhält sich etwas anders als andere Clients (putty und nc auf MacOS), was zu meiner Verwirrung beigetragen hat.
- Ebenfalls wenig intuitiv ist es, dass der telnet-Server in FHEM sich nach der Verbindung nicht unmittelbar mit einem Prompt meldet, sondern erst einmal auf ein Return wartet.
- Woher die erwähnten Steuerzeichen stammen ist unklar.
- Das beschriebene Verhalten scheint aber bei anderen FHEM-Versionen genauso aufzutreten. Deshalb gehe ich davon aus, dass dies nicht die Ursache dafür ist, dass sich der ioBroker nicht mit meinem FHEM verbinden will.
Ich werde also mein Glück bei den ioBroker-Leuten versuchen.
Danke nochmals!
Nur mal zum Testen:
echo -en "version\nquit\n" | nc -w 5 <mein-fhem-server> 7072
Sollte die FHEM-Version Dir ausgeben. Anstatt "version" sind alle anderen FHEM-Möglichkeiten erlaubt.
Das telnet nicht gleich mit einem Prompt kommt ist bekannt und wird von einigen (seit Ewigkeiten) als Bug gesehen, von anderen dagegen als gewollt. Für Automatismen (wie z.B. dem Obigen) ist es sogar nützlich.
P.S. Übrigens kannst Du dadurch auch das Passwort, falls eingerichtet, übertragen:
echo -en "<passwort>\nversion\nquit\n" | nc -w 5 <mein-fhem-server> 7072
P.P.S Und in der Telnet-Doku zu FHEM gibt es den Hinweis, wie man es mit SSL macht
Ich hatte noch ein anderes Problem, warum die Verbindung vom ioBroker zu FHEM nicht aufgebaut wurde.
Ich hatte mal einen neuen Raspberry 3+ für FHEM aufgesetzt und der alte Raspberry lief auch auch. Daher hatte ich bei neuen den Titel mit nachfolgendem Kommando geändert.
attr global title Fhem Pi+
Damit wurde dann auch "FHEM Pi+" im Tab des Browsers angezeigt.
Der title wird aber auch als Prompt in der Telnet-Konsole ausgegeben. Daher passte auch die Vorgabe "fhem>" im ioBroker nicht mehr.
Drauf gekommen bin als, als ich eine manuelle Telnet-Session über
telent ip_adresse 7072
zu FHEM aufgebaut hatte. Wenn man nach dem Login einmal Return drückt, dann wird der aktuelle Prompt angezeigt.