Autor Thema: Newbie - Modulkommunikation | Match | JSON | diverse Zusammenhänge u. Fragen  (Gelesen 2560 mal)

Offline HomeAuto_User

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Newbie - Modulkommunikation | Match | JSON | diverse Zusammenhänge
« Antwort #60 am: 13 Februar 2018, 15:19:27 »
Danke für die schnelle Antwort.
Ich konnte mir dies schon denken weil es ja mit normalen LAN Anschluss funktioniert. Dieser Fehler tritt nur in Verbindung mit DLAN auf.

Dieser Fall tritt nur auf, wenn get($address) undef zurückliefert. Das bedeutet, der Aufruf der URL in $address ist fehlgeschlagen. Ich nehme mal an get() stammt aus LWP::Simple.

Du solltest vorher immer prüfen, ob ein HTTP-Request erfolgreich war und Daten zurückliefert, bevor Du diese blind weiterverarbeitest.

Ich habe bisher mit
my $ua = LWP::UserAgent->new; ## CHECK JSON Adresse -> JSON-query, sonst FHEM shutdown
my $resp = $ua->request(HTTP::Request->new(GET => $adress));

if ($resp->code == "200") { ....
die Anfrage der get($address) geprüft.

PS: Für HTTP-Anfragen solltest du bei der Modulprogrammierung generell https://wiki.fhem.de/wiki/HttpUtils#HttpUtils_NonblockingGet verwenden

Ich werde mich dem mal annehmen und umsetzen. Fragen werde ich dann hier wieder los  ;)

Unbedingt! Lwp ist blockierend, use httputils!!!,

Dann werde ich das
use LWP::Simple;verbannen.
- FHEM v5.8 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) als Vergleichsempfänger
- Sensoren: 3x FHT 80b | 5x FHT 80 TF-2 | 2x S300TH | 1x WS7000-20 | 5x "Hideki" | THR128

Offline HomeAuto_User

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Newbie - Modulkommunikation | Match | JSON | diverse Zusammenhänge
« Antwort #61 am: 13 Februar 2018, 22:18:16 »
Ich setze nun das ganze mit HttpUtils um und komme an folgenden Punkt der für mich unverständlich ist?
Worin besteht der Unterschied?

Zitat
sub xs1Bridge_ParseHttpResponse($)
{
    my ($param, $err, $data) = @_;
    my $hash = $param->{hash};
    my $name = $hash->{NAME};
   my $connection;
   
    if($err ne "")                                                      # wenn ein Fehler bei der HTTP Abfrage aufgetreten ist
    {
        Log3 $name, 3, "error while requesting ".$param->{url}." - $err";            # Eintrag fürs Log
      $connection = 0;
    }

    elsif($data ne "")                                                   # wenn die Abfrage erfolgreich war ($data enthält die Ergebnisdaten des HTTP Aufrufes)
    {
        Log3 $name, 3, "url ".$param->{url}." returned: $data";
   $connection = 2;
   }
   
   Log3 $name, 3, "$connection";                     # Eintrag fürs Log
   return ($connection);
}

So erhalte ich keinen Wert übergeben von $connection.

Zitat
sub xs1Bridge_ParseHttpResponse($)
{
    my ($param, $err, $data) = @_;
    my $hash = $param->{hash};
    my $name = $hash->{NAME};
   my $connection;
   
    if($err ne "")                                                      # wenn ein Fehler bei der HTTP Abfrage aufgetreten ist
    {
        Log3 $name, 3, "error while requesting ".$param->{url}." - $err";            # Eintrag fürs Log
      #$connection = 0;
    }

    elsif($data ne "")                                                   # wenn die Abfrage erfolgreich war ($data enthält die Ergebnisdaten des HTTP Aufrufes)
    {
        Log3 $name, 3, "url ".$param->{url}." returned: $data";                     # Eintrag fürs Log
      #$connection = 2;
   }
   
   $connection = 2;
   Log3 $name, 3, "$connection";
   return ($connection);
}

So erhalte ich diesen und kann diesen abfragen.  :o :-\

Ich möchte Praktisch diesen Wert verarbeiten.

PS: Ja die Schleife fuktioniert und ich erhalte die Logausgabe. Das einzige, die Variable welche den Wert hat, wird nicht verarbeitet.
« Letzte Änderung: 13 Februar 2018, 22:22:17 von HomeAuto_User »
- FHEM v5.8 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) als Vergleichsempfänger
- Sensoren: 3x FHT 80b | 5x FHT 80 TF-2 | 2x S300TH | 1x WS7000-20 | 5x "Hideki" | THR128

Offline Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3401
Antw:Newbie - Modulkommunikation | Match | JSON | diverse Zusammenhänge
« Antwort #62 am: 13 Februar 2018, 22:44:25 »
Wieso willst du in der Callback-Funktion $connection als Funktionsergebnis zurückgeben??? HttpUtils verarbeitet diesen Wert nicht.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Offline HomeAuto_User

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Newbie - Modulkommunikation | Match | JSON | diverse Zusammenhänge
« Antwort #63 am: 13 Februar 2018, 23:16:41 »
Wieso willst du in der Callback-Funktion $connection als Funktionsergebnis zurückgeben??? HttpUtils verarbeitet diesen Wert nicht.

Ich habe mir als Ausgangspunkt dieses Beispiel von oben genommen.

Davon ausgehend durchlaufe ich die sub X_PerformHttpRequest mit all den Parametern.
-> Sprung in die sub X_ParseHttpResponse um zu sehen was die Verbindung sagt. Vorerst ohne Daten zu verarbeiten.
--> Anhand der Möglichkeiten JA Verbindung oder NEIN soll dies weiterverarbeitet werden in einer anderen Sub.

 :-\ oder denke bzw. stelle ich mir das verkehrt vor?
Wieso gehe ich den Weg mit der "übergabe"? Da das Programm zwischendurch immer wieder schauen soll zwecks Verbindung weil ich unterschiedliche HTTP Anfragen senden muss.
- FHEM v5.8 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) als Vergleichsempfänger
- Sensoren: 3x FHT 80b | 5x FHT 80 TF-2 | 2x S300TH | 1x WS7000-20 | 5x "Hideki" | THR128

Offline Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3401
Antw:Newbie - Modulkommunikation | Match | JSON | diverse Zusammenhänge
« Antwort #64 am: 13 Februar 2018, 23:41:17 »
In dem Beispiel steht jedoch nirgendswo ein return-Statement in X_ParseHttpResponse().

Ich glaube Dir fehlt etwas das Verständnis wie HttpUtils_NonblockingGet() konkret funktioniert.

Am Wiki-Beispiel erklärt: Die Funktion X_PerformHttpRequest() erzeugt einen Parameterhash $param in denen alle notwendigen Daten/Parameter gesetzt werden um einen HTTP-Request zu starten. Dieser Parameter-Hash wird nun mit HttpUtils_NonblockingGet() zur Ausführung gebracht. Dabei wird der TCP-Verbindungsaufbau zur Ziel-URL in Gang gesetzt. Anschließend beendet sich die Funktion HttpUtils_NonblockingGet() direkt, da nun FHEM selber (fhem.pl) sich weiter um den Request kümmert. Sobald ein Ergebnis vorliegt (Erfolgreiche Antwort, Fehlerhafte Antwort, Leere Antwort,  Verbindungstimeout, ...) wird das Ergebnis an die parametrisierte Callback-Funktion X_ParseHttpResponse() übergeben.

In der Callback-Funktion obliegt es dem Modulautor zu entscheiden, wie nun mit dem Ergebnis weiterzuverfahren ist.

-> Sprung in die sub X_ParseHttpResponse um zu sehen was die Verbindung sagt. Vorerst ohne Daten zu verarbeiten.

Es handelt sich hier nicht um einen direkten Sprung von X_PerformHttpRequest() nach X_ParseHttpResponse(). Es handelt sich um einen asynchronen Aufruf von X_ParseHttpResponse() nachdem ein HTTP-Request abgeschlossen wurde, in deren Parameter-Hash X_ParseHttpResponse() als Callback-Funktion definiert wurde.
--> Anhand der Möglichkeiten JA Verbindung oder NEIN soll dies weiterverarbeitet werden in einer anderen Sub.

Das ist kein Problem, die Subroutine kannst du ja direkt am Ende von xs1Bridge_ParseHttpResponse() mit $connection aufrufen.

:-\ oder denke bzw. stelle ich mir das verkehrt vor?
Wieso gehe ich den Weg mit der "übergabe"? Da das Programm zwischendurch immer wieder schauen soll zwecks Verbindung weil ich unterschiedliche HTTP Anfragen senden muss.

Was Du Dir denkst oder vorstellst weis ich ehrlich gesagt nicht. Da Du mit Codeschnipseln aus deinem Modul sehr, sehr sparsam bist, ist es ehrlich gesagt recht mühsam zu verstehen was Du vorhast.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Offline HomeAuto_User

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Newbie - Modulkommunikation | Match | JSON | diverse Zusammenhänge
« Antwort #65 am: 13 Februar 2018, 23:52:10 »
Danke Markus für die Antwort.
Ich habe auf jedenfall nun ein wenig mehr Verständnis dazu erlangt.

Was die Codesschnipsel angeht, stimme ich dir zu und kann mich auch in die Lage von dir da versetzen. Du kannst ja schlecht "hellsehen".
Mit deiner Erklärung und dem Wiki werde ich mir dies am Tage nochmal ansehen und angehen.

Nochmals danke für Eure / Deine Ausdauer mit "neuen Usern welche sich da mit Wissbegierigkeit" hineinfressen.
Erstmal Schicht für heute  8)
- FHEM v5.8 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) als Vergleichsempfänger
- Sensoren: 3x FHT 80b | 5x FHT 80 TF-2 | 2x S300TH | 1x WS7000-20 | 5x "Hideki" | THR128

Offline HomeAuto_User

  • Developer
  • Full Member
  • ****
  • Beiträge: 191
Antw:Newbie - Modulkommunikation | Match | JSON | diverse Zusammenhänge
« Antwort #66 am: 15 Februar 2018, 22:26:22 »
Hallo,
die Umstellung ist gelungen und ich habe die nicht konforme Variante ersetzt mit der eigenen FHEM Funktion.

Eine Frage hätte ich zwecks Realisierung einiger bestimmter State´s.
Wie Bsp. bei FS20 würde ich gern bei einem Dimmer meine Werte des States mit dem Dimmer Icon versehen.
Die Icons werden ja anhande des States zugeordenet. Bei Fs20 Bsp mit den State Werten 6, 12 usw.... , so sind ja auch die Icons benannt mit dim06% unsw.
Wie könnte ich das Umsetzen, das ich bei 1-5 auch das Icon vom dim06% state erhalte, das das zu steuernde Gerät Werte von 0 - 100 zulässt? Die Zwischenstufen wie bei FS20 habe ich schon umgesetzt aber  da habe ich ja angenommen bei State 5 kein Icon und bei State 6 habe ich eins.

Ich hoffe das Prinzip richtig erklärt zu haben.

EDIT: Um Missverständnisse zu vermeiden, JA man könnte die Icons kopieren so das man dann 100 der Sorte hätte aber das trifft dann nur bei mir zu. Das Modul soll ja ggf. auch für andere User zur Verfügung stellen. Ich weiß nicht, ob es auf Zustimmung trifft, wenn ich vorschlage die Icons dim für 0-100 zu erweitern. Mir ging es da um einen Alternativweg.
« Letzte Änderung: 15 Februar 2018, 23:45:02 von HomeAuto_User »
- FHEM v5.8 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) als Vergleichsempfänger
- Sensoren: 3x FHT 80b | 5x FHT 80 TF-2 | 2x S300TH | 1x WS7000-20 | 5x "Hideki" | THR128

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 17965
- als Benutzer: man kann sowas via regexp im devStateIcon abbilden.
- als Loesung fuer alle faellt mir nur www/images/*/iconalias.txt ein, und da 100 Zeilen einzufuegen, mit dem Nachteil, dass diese 100 beim Auswahl zusaetzlich auftauchen.
- weitere Alternative waere iconalias.txt mit Regexp zu erweitern.

 

decade-submarginal