24_TPLinkHS110.pm: Support für TPLink HS100/HS110 v1/2/3 Steckdosen

[BM030]

Hallo Volker,

würdest Du Dein Modul auch auf Glühbirnen erweitern?

Hier gibt es ein Perl Script, welche beide TPLink Arten vereint, also LB und HS in einem Script:
https://github.com/pete1450/tPLink/blob/master/lib/My/TPLCmd.pm

Ich versuche schon seit einigen Tagen das irgendwie ins FHEM zu übersetzen, bekomme es aber leider nicht hin.
Habe leider von den FHEM Modulen keine Ahnung...

Könntest Du dir das mal anschauen?

Danke Grüße Gordon

[Volker Kettenbach]

Guten Morgen!

Ich habe mir den Code von pete1450 mal angeschaut.
Ich würde sagen, dass das eine gute Chance hat zu klappen.

Ich würde mir mal eine LB130 bestellen, weil ohne Testgerät wird es schwer.
Dazu eine Frage: bei Amazon gibt es mehrere negative Bewertungen, weil das Gerät nach einiger Zeit die WLAN Verbindung verliert.
It das bei Dir auch so?

Gruß
Volker

[BM030]

Hi Volker,
Ich nutze eine LB120 sowie LB130 und habe bisher keine Probleme. Natürlich spiele ich auch wie bei den Steckdosen Updates ein, diese über den PC und nicht über die Kasse App. Vielleicht wissen das die Nutzer der schlechten Bewertungen nicht.

Grüsse Gordon

[Volker Kettenbach]

Hab die lb130 bestellt.
Dann Mal schauen.

[BM030]

Super, ...

wenn ich an meine Heos Geräte denke, liegt es auch eher an der App und nicht an den Geräten selber, dass diese nicht reagieren.

Seitdem ich diese über FHEM bediene habe ich auch auch bei diesen keine wirklichen Probleme mehr.

[chani666]

Hallo,
ich habe 5 von den Steckdosen (HS110), 2 alte und 3 neue (HW 2.0). Zunächst haben die neuen auch funktioniert, ausser dass die neuen halt Watth statt kWatth rückgemeldet habe.

Aber nach ein paar Tagen habe ich jetzt diese Meldung bei den neuen (die alten kein Problem):

decode_json        unexpected end of string while parsing JSON string, at character offset 1020 (before "(end of string)") at ./FHEM/24_TPLinkHS110.pm line 458.

es geht nicht mehr weg, was kann ich tun? Im Githup komm ich nicht ganz klar mit den Branches, als aktuelleste habe ich eine 3 Monate alte version geladen, denke dass ist dort die aktuellste?

Grüße
Björn

[Volker Kettenbach]

Die aktuellste ist immer der Branch Master.
3 Monate ist korrekt. Du dürftest die letzte Version haben.

Was bei Dir los ist, ist schwer zu sagen.
Scheinbar kommen korrupte Daten an.
Gehen die Geräte mit der App?

[Volker Kettenbach]

Hallo Volker,

würdest Du Dein Modul auch auf Glühbirnen erweitern?

Hier gibt es ein Perl Script, welche beide TPLink Arten vereint, also LB und HS in einem Script:
https://github.com/pete1450/tPLink/blob/master/lib/My/TPLCmd.pm

Ich versuche schon seit einigen Tagen das irgendwie ins FHEM zu übersetzen, bekomme es aber leider nicht hin.
Habe leider von den FHEM Modulen keine Ahnung...

Könntest Du dir das mal anschauen?

Danke Grüße Gordon

Kurzes Update: die LB ist mittlerweile da.
Ich plane für die nächsten Wochen einiges zu programmieren. Da werde ich versuchen das mit zu machen.

[BM030]

... kann es kaum erwarten! Teste gerne soweit ich kann, falls du Hilfe brauchst.

[chani666]

Was bei Dir los ist, ist schwer zu sagen.
Scheinbar kommen korrupte Daten an.
Gehen die Geräte mit der App?

Ja mit der Kasa App klappts. Die APP zeigt aber ab und zu auch nur Laufzeit und nicht Verbrauch an. Aber das legt sich schnell nach ein paar Sekunden, bei FHEM nicht. Der String der in eval_json überprüft wird ist tatsächlich nur 1024 zeichen lang, während der string von den alten HW v1 viel länger ist bei get_dailystats.

Ich hab mit dem recv befehl rumgespielt, aber die 8000 irgendwas sinds wohl nicht... Es scheint bis zum 21ten eines Monats zu gehen:

Data returned: $VAR1 = '{"emeter":{"get_daystat":{"day_list":[{"year":2018,"month":9,"day":2,"energy_wh":787},{"year":2018,"month":9,"day":3,"energy_wh":0},{"year":2018,"month":9,"day":4,"energy_wh":0},{"year":2018,"month":9,"day":5,"energy_wh":0},{"year":2018,"month":9,"day":6,"energy_wh":0},{"year":2018,"month":9,"day":7,"energy_wh":0},{"year":2018,"month":9,"day":8,"energy_wh":0},{"year":2018,"month":9,"day":9,"energy_wh":0},{"year":2018,"month":9,"day":10,"energy_wh":56},{"year":2018,"month":9,"day":11,"energy_wh":221},{"year":2018,"month":9,"day":12,"energy_wh":497},{"year":2018,"month":9,"day":13,"energy_wh":564},{"year":2018,"month":9,"day":14,"energy_wh":700},{"year":2018,"month":9,"day":15,"energy_wh":394},{"year":2018,"month":9,"day":16,"energy_wh":485},{"year":2018,"month":9,"day":17,"energy_wh":471},{"year":2018,"month":9,"day":18,"energy_wh":393},{"year":2018,"month":9,"day":19,"energy_wh":481},{"year":2018,"month":9,"day":20,"energy_wh":488},{"year":2018,"month":9,"day":21,"energy_wh":577},{"year":2018,"month":9,"d';

FW ist 1.5.4, hätte jetzt keinen hardware defekt vermutet, sind ja alle 3 mit HW v2.

[chani666]

Ich habs Problem gelöst, auf diese Weise. Sicher nicht elegant, vorallem weil ich keine Ahnung hab ob das mit den alten Probleme gibt, ich lass es mal ein paar Tage so laufen un berichte.

# Get Daily Stats
      my $command = '{"emeter":{"get_daystat":{"month":'.$mon.',"year":'.$year.'}}}';
      my $c = encrypt($command);
      $socket = IO::Socket::INET->new(PeerAddr => $remote_host,
              PeerPort => $remote_port,
              Proto    => 'tcp',
              Type     => SOCK_STREAM,
                Timeout  => $hash->{TIMEOUT} )
              or return "Couldn't connect to $remote_host:$remote_port: $@\n";
      $socket->send($c);
      my $data1;
      $retval = $socket->recv($data1,16384);
      $data1 = decrypt(substr($data1,4));
       #($success,$json) = TPLinkHS110__evaljson($name,$data);         
      $socket->send($c);
      my $data2;
      $retval = $socket->recv($data2,16384);
      $socket->close();
      
      unless( defined $retval) { return undef; }
            
      $data2 = decrypt(substr($data2,4));
        my $data;
      
      $data = $data1.$data2;
      
        ($success,$json) = TPLinkHS110__evaljson($name,$data);

[Volker Kettenbach]

Der String in Deiner ersten Nachricht ist genau 1024 Bytes lang.
Meine Vermutung ist, dass das Programm nur 1kB liest. Das dürfte wohl an der "recv" Funktion liegen.
Du rufst den Socket 2x auf und verbindest das ganze.
Der Ansatz ist richtig.
Am besten wäre eine while Schleife, die so lange liest, bis keine Daten mehr kommen.
Ich setze das mal auf meine Todo-Liste.
Ich denke, ich kann das und die Implementation der LB in den nächsten Tagen machen.

[chani666]

jap, wobei man vorhersehen kann, dass der string bei 31 tage keine 2kb groß werden wird, aber ja.

es scheint auch mit den HWv1 keine Problem zu geben, allerdings in dem Code noch folgendes falsch:

ich hab die daten getrennt dekodiert und dann zusammen geworfen, dabei gehen zeichen verloren, man muss sie zuerst zusammen werden dann das decrypt aufrufen.

bisher gehts...

[Volker Kettenbach]

Guten Abend,

hier findet sich eine in der Stabilität stark verbesserte Version:

https://github.com/kettenbach-it/FHEM-TPLink-HS110/blob/hotfix/Fix_recv_function/24_TPLinkHS110.pm

(Update 2.10.2018: der Link ist nicht mehr gültig, da der Hotfix in den MasterBranch gemerged wurde)

Ich behaupte, dass damit die Probleme von chani666 und noch einige mehr gelöst sind.

Bitte das ganze mal testen!
Wenn alles okay ist, werde ich den Branch auf den aktuellen Master mergen und dann ins SVN releasen.

Gruß
Volker

P.S. an der LB130 bin ich dran.

[Volker Kettenbach]

Hallo zusammen,

da sich niemand gemeldet hat, nehme ich an, dass das ganze stabil läuft.
Ich habe den Hotfix daher gemerged und ins SVN eingecheckt.