02_HTTPAPI - Attribute im Device funktionieren nicht wie erwartet

[DS_Starter]

Hallo Klaus,

ich habe mich mit deinem Modul etwas beschäftigt. Es bietet mir vermutlich einen sehr guten Dienst als Agent für eine Anwendung.

Dabei ist mir aufgefallen, dass disable bzw. devicesCtrl nicht arbeiten. Grund ist, dass $name in der Sub HTTPAPI_Read -> Übergabe an HTTPAPI_TcpServerWrite nicht den Namen des Device enthält, sondern den Namen der temporären Web-Instanz.

Wenn in Sub HTTPAPI_Read ergänzt wird:

  # accept request and create a child
  if ($hash->{SERVERSOCKET}) {
    my $chash = TcpServer_Accept($hash, "HTTPAPI");
    return if (!$chash);
    $chash->{encoding} = $encoding;                           # Zeile 252
    $chash->{cname} = $name;
    $chash->{CD}->blocking(0);
    return;
  }

Und später:

      # CGI Aufruf
      $ret = HTTPAPI_TcpServerWrite(HTTPAPI_CGI($hash, $hash->{cname}, $url));   # Zeile 316

klappt es wie erwartet.
In der Zeile 117 (sub HTTPAPI_CGI) habe ich mal testweise den Kommentar von

  readingsSingleUpdate($defs{$name}, 'request', $request, 0);

entfernt. Ich finde es hilfreich wenn im Modul der letzte Request dokumentiert wird.
Weiterhin ist es etwas unschön falls "get" keine Daten zurückgibt, ein "error=400 Bad Request" returned wird. Nicht jeder get-Befehl muß unbedingt einen String zurück liefern.

LG,
Heiko

[klaus.schauer]

Hallo Heiko,
ich habe die Änderungen so übernommen. Weitergehende Tests hast Du ja schon gemacht. Lasse das noch ein paar Tage bei mir laufen, bevor ist das veröffentliche.

Weiterhin ist es etwas unschön falls "get" keine Daten zurückgibt, ein "error=400 Bad Request" returned wird. Nicht jeder get-Befehl muß unbedingt einen String zurück liefern.

Kann man sicher noch optimieren und die Fehlermeldung nur ausgeben, falls das Kommando oder das Reading nicht existiert.

Wahrscheinlich brauche ich dann noch die Möglichkeit Internals auszulesen.

Bisher gab es dazu bei mir keinen Bedarf. Das Modul sollte bewusst möglichst kompakt und ohne unnötigen Ballast sein. Kann man aber sicher auch einbauen.

Aber das würde ich dir im Forum vorschlagen.

Wenn es Dir nichts ausmacht, bitte eine Info über "persönliche Post". Ich lese regelmäßig nur wenige Foren.

Wirf die ganzen Prototypen ($$$$) raus. Die machen nur Ärger beim reload 02_HTTPAPI und braucht man nicht.

Das verstehe ich nicht. Vielleicht kannst Du mir das mit einem Beispiel verdeutlichen.

[DS_Starter]

Hallo Klaus,

danke. Melde mich wieder per PM.

LG,
Heiko

[betateilchen]

Wirf die ganzen Prototypen ($$$$) raus. Die machen nur Ärger beim reload 02_HTTPAPI und braucht man nicht.

Das verstehe ich nicht. Vielleicht kannst Du mir das mit einem Beispiel verdeutlichen.

Verwende anstatt

Code Auswählen Erweitern

sub HTTPAPI_Define($$) {
einfach

Code Auswählen Erweitern

sub HTTPAPI_Define() {

[klaus.schauer]

Ok verstanden. Die automatische Prüfung der Variablenliste finde ich aber nicht ganz nutzlos. Jedenfalls hat mich schon das eine oder andere Mal beim Umbau von Routinen vor Flüchtigkeitsfehlern bewahrt.

Weshalb kann es denn dadurch zu Ärger beim reload kommen?

[DS_Starter]

Weshalb kann es denn dadurch zu Ärger beim reload kommen?

Führe mit deinem aktuellen Modul einfach mal ein reload 02_HTTPAPI aus. Dann wirst du es sehen.

Es gab zu Prototypen auch mal eine größere Diskussion/Abhandlung -> https://forum.fhem.de/index.php?topic=109526.msg1035088#msg1035088

[klaus.schauer]

Heiko hat das Modul um die Funktion "readinternal" erweitert und ein paar Optimierungen vorgenommen. Danke dafür. Das aktuelle Modul steht mit dem nächsten Update zur Verfügung.