Wegfall von Telnet - FHEM command Types in der Doku

[Otto123]

Hi,

bei einer Neuinstallation von FHEM gibt es ja jetzt kein Telnet mehr. Damit stimmt doch der Abschnitt in der commandref auch nicht mehr?:

FHEM command types
[EN DE]
There are three types of commands: "fhem" commands (described in this document), shell commands (they must be enclosed in double quotes ") and perl expressions (enclosed in curly brackets {}). shell commands or perl expressions are needed for complex at or notify arguments, but can also issued as a "normal" command.

E.g. the following three commands all do the same when issued from a telnet prompt:
set lamp off
"fhem.pl 7072 "set lamp off""
{fhem("set lamp off")}

Aber viel wichtiger wäre für mich die Antwort auf die Frage, gibt es denn jetzt eine Alternative zu

Code Auswählen Erweitern

"fhem.pl 7072 "set lamp off""?
Also eine Möglichkeit der Kommandoeingabe von der Linux Befehlszeile?

Gruß Otto

[hexenmeister]

Einfach das Telnet wieder in den Config eintragen

Code Auswählen Erweitern

define telnetPort telnet 7072

[Otto123]

Einfach das Telnet wieder in den Config eintragen

Code Auswählen Erweitern

define telnetPort telnet 7072

Das war nicht die Frage 
Ich war eigentlich froh, einen "supporteten Weg" zu haben, nach einer Installation die Konfiguration noch auf der Linux Kommandozeile etwas anzupassen.
Ich weiß es gibt "tausend" Möglichkeiten - mir wäre ein Weg der in der Doku steht lieber. 

[hexenmeister]

Telnet ist ja nicht unsupported. Einfach nicht per se installiert, was man als sinnvoll ansehen kann (als etwas für diejenigen, die wissen, was sie tun). Aber ich verstehe dein Problem. Du möchtest vermutlich einen automatischen Installationsscript erstellen. Ich ersetzte in solchen Fällen die komplette Konfiguration durch meine eigene.

[Otto123]

Ich möchte das nicht mal für mich  sondern eher für den offiziellen Sprachgebrauch, z.B. Wiki
https://wiki.fhem.de/wiki/Raspberry_Pi#FHEM

Und jederzeit der mögliche Hinweis auf die Doku und das haut derzeit nicht hin...

[hexenmeister]

 Da hast du natürlich recht.

[rudolfkoenig]

Ich will das System nicht ungeschuetzt (ohne Passwort) ausliefern. Selbst bei localhost ist es mir mulmig.
Der FHEM-Anfaenger soll auch nicht sofort nach der Installation mit Aufgaben (wie Passwort fuer telnet setzen) verwirrt werden, insb. da er keine Ahnung hat, wozu man telnet braucht.

Ich bin aber offen, die Doku zu erweitern, fuer global per attrTemplate ein "richte telnet ein mit passwort" hinzufuegen, das FHEM Commandline von telnet auf FHEMWEB umzubuauen, oder was auch immer. Ideen willkommen, am besten konkret mit Patch.

[Otto123]

Hallo Rudi,

Naja mir wäre sowieso am liebsten es geht nur lokal. Und dann so in der Art:

Code Auswählen Erweitern

fhem.pl cmd "set lamp off"
Ich will auch nicht Telnet sofort wieder aktivieren!

Für einen Patch bin ich der Falsche. Ich kann ein Shellscript bauen, was das Ganze über FHEMWEB macht. Aber das wird vergleichsweise so aufwendig...

Oder Du baust mal

Code Auswählen Erweitern

attr initialUsbCheck disable 1 in die fhem.cfg ein.
Dann fällt zumindest in dem Wiki Artikel die Notwendigkeit weg 

Aber wenn ich mich so an einige Post von Dir erinnere, ich meine Du verwendest gaaanz oft die Schreibweise mit fhem.pl 7072 ....

Edit: Ich hatte gedacht vielleicht gibt es die lokale Kommandozeile mit fhem.pl und ohne Telnet schon und ich kenne sie bloß nicht. 

[Otto123]

Als pragmatische Zwischenlösung habe ich mal ein bash Script für FHEMWEB in Anlehnung an den Raw Import gebaut.
Damit kann man einen Befehlsblock mit einem Rutsch in FHEM importieren.
Primär kann ich damit relativ komfortabel eine Grundkonfiguration in FHEM übernehmen, nach dem Setup ist FHEMWEB für lokalen Zugriff ja (noch) offen. 

Code Auswählen Erweitern

#!/bin/bash
# fhemraw Import analog Raw Definition
if [ $# -eq 0 ] ; then
     echo fhemraw bitte so verwenden
     echo fhemraw <dateiName> [<hostName>] [<portNummer>]
     exit 1
fi

if [ -z $2 ] ; then
     fhemhost=localhost
   else
     fhemhost=$2
fi
if [ -z $3 ] ; then
     fhemhost=$fhemhost:8083
   else
     fhemhost=$fhemhost:$3
fi
token=$(curl -s -D - "http://$fhemhost/fhem?XHR=1" | awk '/X-FHEM-csrfToken/{print $2}')

while read line
do
    curl --data "fwcsrf=$token" http://$fhemhost/fhem?cmd=$(echo $line|sed 's/ /%20/g')
done < $1Gruß Otto

[Otto123]

Mittlerweile habe ich eine besser HTTP Client Variante gebaut.
Ich hänge die Perl Variante mal an, vielleicht kann man die ja ganz oder teilweise als zukünftigen Ersatz verwenden. Ist allerdings mit 80 Zeilen etwa vier mal soviel Code als der originale Teil. Der Funktionsumfang vom Original lässt sich auch mit weniger machen.
Das soll aber keine Aufforderung oder Wunsch oder so sein. Einfach nur als Information 

Ich bin kein Perl Programmierer, vielleicht geht es ja auch viel kürzer und effektiver.

Code Auswählen Erweitern

#!/usr/bin/env perl
# send commands to FHEM over HTTP
# if no Argument, show usage

use strict;
use warnings;
use URI::Escape;
use LWP::UserAgent;

my $token;
my $hosturl;
my $fhemcmd;

if ( not @ARGV ) {
     print 'fhemcl Usage',"\n";
     print 'fhemcl [http://<hostName>:]<portNummer> "FHEM command1" "FHEM command2"',"\n";
     print 'fhemcl [http://<hostName>:]<portNummer> filename',"\n";
     print 'echo -e "set Aktor01 toggle" | fhemcl [http://<hostName>:]<portNumber>',"\n";
     exit;
}

if ($ARGV[0] !~ m/:/) {
   if ($ARGV[0] eq ($ARGV[0]+0)) { # isnumber?
       $hosturl = "http://localhost:$ARGV[0]";
   }
   else {
       print "$ARGV[0] is not a Portnumber";
       exit(1);
   }
}
else {
    $hosturl = $ARGV[0];
}

# get token
my $ua = new LWP::UserAgent;
my $url = "$hosturl/fhem?XHR=1/";
my $resp = $ua->get($url);
   $token = $resp->header('X-FHEM-CsrfToken');

my @cmdarray ;

# test the pipe and read
if (-p STDIN) {
   while(<STDIN>) {
       s/\r[\n]*/\n/gm;      #remove any \r from $_
       chomp($_);
       push(@cmdarray,$_);
   }
}
# second Argument is file or command?
if ($ARGV[1] and -e $ARGV[1]) {
    open(DATA, '<', $ARGV[1]);
    while(<DATA>) {
       s/\r[\n]*/\n/gm;      #remove any \r from $_
       chomp($_);
       push(@cmdarray,$_);
    }
    close(DATA);
}
else {
    for(my $i=1; $i < int(@ARGV); $i++) {
    push(@cmdarray, $ARGV[$i]);
    }
}
#execute commands and print response from FHEMWEB
for(my $i = 0; $i < @cmdarray; $i++) {
    # concat def lines with ending \ to the next line
    my $cmd = $cmdarray[$i];
    while ($cmd =~ m/\\$/) {
        $i++;
        $cmd = substr($cmd,0, -1)."\n".$cmdarray[$i];
    };
    # url encode the cmd
    $fhemcmd = uri_escape($cmd);
    print "proceeding line ".eval($i+1)." : $fhemcmd\n";
    $url = "$hosturl/fhem?cmd=$fhemcmd&fwcsrf=$token";
    $resp = $ua->get($url)->content;
    # only between the lines <pre></pre> and remove any HTML Tag
    #funktioniert noch nicht sauber bei massenimport
    my @resparray = split("\n", $resp);
    foreach my $zeile(@resparray){
        if ($zeile !~ /<[^>]*>/ or $zeile =~ /pre>/ or $zeile =~ /NAME/) {
           $zeile =~ s/<[^>]*>//g;
           print "$zeile\n" ;
        }
    }
}

Gruß Otto

[Beta-User]

Ich bin aber offen, die Doku zu erweitern, fuer global per attrTemplate ein "richte telnet ein mit passwort" hinzufuegen, das FHEM Commandline von telnet auf FHEMWEB umzubuauen, oder was auch immer. Ideen willkommen, am besten konkret mit Patch.

Bin da eben wegen des aktualisierten Scripts von Otto drüber gestolpert...

Das mit dem template für sichere Zugänge fände ich an sich eine gute Sache, vor allem, wenn man es generalisieren könnte und dann nicht nur (von global aus) für das erstmalige define eines telnet-Zugangs zu nutzen, sondern die darin enthaltene Absicherung gleich für alle Module anzubieten, die "allowed" unterstützen. Die Zusammenhänge scheinen da nämlich vielen einfach nicht klar zu sein, was es mit allowed auf sich hat, und wenn man es z.B. bei einem MQTT2_SERVER oder FHEMWEB-Device "vor Ort" hätte, wäre es m.E. etwas übersichtlicher/leichter zu finden.

Bei der Gelegenheit gleich noch ein paar Wünsche und Anregungen für einen eventuellen "template-Weg" rund um global:
- Deaktivieren des initialUsbCheck? (Wir hatten da neulich einen Fall, da hat sich CUL den zigbee2mqtt-Stick geschnappt... Nicht startende Pi's sind sowieso Legion. Persönlich würde ich dazu tendieren, den Check per default zu deaktivieren und nur auf ausdrücklichen Befehl auszuführen (ich weiß, dass das heute schon prolemlos geht...), und die user nur darauf zu stoßen/dahin als Option zu führen, indem man es in die template-Form umverpackt)

- dnsServer

- Regionalangaben "auf einen Rutsch" (nicht so wichtig); vielleicht gäbe es einen Weg, das durch Angabe eines Ortes zu vereinfachen?

tbc...

[rudolfkoenig]

[...] die darin enthaltene Absicherung gleich für alle Module anzubieten, die "allowed" unterstützen.

Ich will niemanden von etwas abhalten, aber FHEMWEB meldet auf der Startseite FHEM-Interne Netzwerkserver (FHEMWEB/telnet/MQTT2_SERVER) ohne Passwort, und bietet einen Link an, um ein allowed zu definieren. Das allowed-Wizard ermoeglicht relativ einfach fuer alle Dienste Passwort zu setzen.

Deaktivieren des initialUsbCheck?

Ungern. Es gibt sicher Faelle, wo es zum Problem fuehrt, aber ich vermute mehr Faelle, wo es hilft.

Wir hatten da neulich einen Fall, da hat sich CUL den zigbee2mqtt-Stick geschnappt.

Dann sollten wir die Pruefung in autocreate.pm verbessern.
Mir ist z.Zt. nur FRM ein Dorn im Auge bei usb create, weil es mit seinem Timeout von 5 Sekunden relativ lange blockiert.

dnsServer

das ist nur in speziellen Faellen sinnvoll: wenn man auf Netzwerk angewiesen ist, und dieser Netzwerk unzuverlaessig ist.
Und der Benutzer muss wissen, was die richtige IP-Adresse ist.

Regionalangaben

Ich habe nichts gegen einem "Einrichtungsassistenten", wenn jemand sich zustaendig fuehlt, nur zu

[Beta-User]

Vorab mal Danke für die Rückmeldung, für manche features (wie das mit dem link auf der üblichen Startseite) wird man mit der Zeit scheinbar betriebsblind...

Was den USB-Check angeht, haben wir leider keine belastbaren Infos, das schlägt halt immer nur auf, wenn es Probleme gibt, und irgendwann sollte man es nicht mehr benötigen (meine Meinung). M.E. wäre es sinnvoller, dem User ggf. - ähnlich wie von dir zu allowed geschildert - einfach anzubieten, das zu starten. Ist aber auch nur ein Bauchgefühl.
Welche Angaben benötigst du für den dusseligen CC2531, um das zu verbessern? Muß den eh' neu flashen, da kann ich ihn auch gerne bei der Gelegenheit mit Kommandos füttern...

Das mit dnsServer habe ich irgendwo aufgeschnappt und als sinnvoll im Hinterkopf, kann das aber nicht wirklich beurteilen. Stand halt auf meiner privaten "kann problematisch sein"-Liste.

Und für einen Installation-Wizzard fühle ich mich jedenfalls derzeit weder berufen noch qualifiziert . Die templates reichen mir einstweilen, komme ja nicht mal dazu, den MySensors-Teil vollends abzuschließen, da gäbe es noch ein paar Kleinigkeiten .