##########################
#
# Es gibt zwei Git-Repositories mit dem Sourcecode:
# https://gitlab.com/volkerkettenbach/FHEM-TPLink-Kasa
# https://github.com/kettenbach-it/FHEM-TPLink-HS110/
#
##########################
Hallo,
wie bereits in (1) angekündigt, habe ich ein Modul für die TP-Link HS-110 und HS-100 WLAN-Steckdosen geschrieben.
Der Unterschied zwischen der HS100 und HS110 besteht darin, dass die HS110 eine Echtzeit-Messung von
Strom, Spannung sowie Leistung durchführt.
Das Modul erkennt automatisch, welchen Typ Sie verwenden und passt die Readings entsprechend an.
Das Modul implementiert nicht alle Funktionen der HS100/110.
Derzeit werden alle für den sinnvollen Betrieb an FHEM benötigten Parameter ausgelesen.
Geschrieben werden jedoch nur die Schaltzustände "An", "Aus" sowie der Nachtmodus An/Aus (Nachtmodus = LEDs der Steckdose ausschalten).
Für eine weitergehende Programmierung der Steckdosen wird daher die TP Link App "Kasa" empfohlen, wobei deren
Funktionen wie Timer etc. letztlich redundant zu Kernfunktionen von FHEM sind.
Für alles weitere am besten in die Doku im Modul schauen.
Das Modul ist hier zum Testen erhältlich:
https://github.com/kettenbach-it/FHEM-TPLink-HS110
Bugreports bitte hier!
Change Requests bitte als Patch über die Pull-Request Funktion von github submitten.
Nach einer Testphase werde ich das Modul in das offizielle FHEM Repository einchecken.
Gruß
Volker
(1) https://forum.fhem.de/index.php/topic,52124.0.html (https://forum.fhem.de/index.php/topic,52124.0.html)
Hallo Volker,
vielen Dank für das Modul. Leider startet es nicht bei mir.
Im Log steht folgendes:
2016.08.27 11:46:14 1: reload: Error:Modul 24_TPLinkHS110 deactivated:
Can't locate IO/Socket/Timeout.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/24_TPLinkHS110.pm line 31, <$fh> line 597.
BEGIN failed--compilation aborted at ./FHEM/24_TPLinkHS110.pm line 31, <$fh> line 597.
2016.08.27 11:46:14 0: Can't locate IO/Socket/Timeout.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/24_TPLinkHS110.pm line 31, <$fh> line 597.
BEGIN failed--compilation aborted at ./FHEM/24_TPLinkHS110.pm line 31, <$fh> line 597.
Die Perl Module habe ich installiert, denke ich.
Viele Grüße
Stefan
So ein Teil eben gekauft, nachdem ich im Geschäft geprüft habe ob es mit FHEM funktioniert.
Frage: Wie komme ich an die IP Adresse??? Das Gerät wird mir in der FritzBox nicht angezeigt, obwohl es bereits mit der APP funktioniert.
Auszug aus dem LOG:
Zitat2016.08.27 13:32:49 1: reload: Error:Modul 24_TPLinkHS110 deactivated:
Can't locate IO/Socket/Timeout.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/24_TPLinkHS110.pm line 31.
BEGIN failed--compilation aborted at ./FHEM/24_TPLinkHS110.pm line 31.
2016.08.27 13:32:49 0: Can't locate IO/Socket/Timeout.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/24_TPLinkHS110.pm line 31.
BEGIN failed--compilation aborted at ./FHEM/24_TPLinkHS110.pm line 31.
2016.08.27 13:33:09 1: reload: Error:Modul 24_TPLinkHS110 deactivated:
Can't locate IO/Socket/Timeout.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/24_TPLinkHS110.pm line 31.
BEGIN failed--compilation aborted at ./FHEM/24_TPLinkHS110.pm line 31.
2016.08.27 13:33:09 0: Can't locate IO/Socket/Timeout.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/24_TPLinkHS110.pm line 31.
BEGIN failed--compilation aborted at ./FHEM/24_TPLinkHS110.pm line 31.
Zitat von: bjoernbo am 27 August 2016, 13:29:09
So ein Teil eben gekauft, nachdem ich im Geschäft geprüft habe ob es mit FHEM funktioniert.
Frage: Wie komme ich an die IP Adresse??? Das Gerät wird mir in der FritzBox nicht angezeigt, obwohl es bereits mit der APP funktioniert.
Hallo,
für das iPhone gibt es eine App, die scannt das lokale Netz nach IP Adressen (fing):
https://itunes.apple.com/de/app/fing-network-scanner/id430921107?mt=8
Gruß
Stefan
Danke!
Also IP Adresse habe ich nun!
define VerbrKuehlschr TPLinkHS110 192.168.178.52 sagt mir aber:
ZitatCannot load module TPLinkHS110
Habe 24_TPLinkHS110.PM in das Verzeichnis in das FHEM Verzeichnis kopiert. Dort wo auch alle anderen .PM Dateien sind. Danach ein Shutdown restart :-[
OK. Ich denke mir fehlt das Modul
ZitatPerl Module: IO::Socket::Timeout
. Wo bekomme ich das her und wie richte ich das ein. Wird das auf Kommandozeilenebene installiert?
Zitat von: stefan_kah am 27 August 2016, 11:50:50
2016.08.27 11:46:14 0: Can't locate IO/Socket/Timeout.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/24_TPLinkHS110.pm line 31, <$fh> line 597.
BEGIN failed--compilation aborted at ./FHEM/24_TPLinkHS110.pm line 31, <$fh> line 597.
Die Perl Module habe ich installiert, denke ich.
Welche Distribution verwendest Du?
Zitat von: bjoernbo am 27 August 2016, 13:36:49
Auszug aus dem LOG:
Wie in der Doku steht: das Modul benötigt das Perl Modul IO::Socket::Timeout.pm
Im Falle von Debian/Raspbian/Ubuntu:
apt-get install libio-socket-timeout-perl
Zitatpi@raspberrypi ~ $ sudo apt-get install libio-socket-timeout-perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libio-socket-timeout-perl
:-\
Zitat von: Volker Kettenbach am 27 August 2016, 19:58:38
Wie in der Doku steht: das Modul benötigt das Perl Modul IO::Socket::Timeout.pm
Im Falle von Debian/Raspbian/Ubuntu:
apt-get install libio-socket-timeout-perl
Danke für deine Antwort.
pi@fhem ~ $ sudo apt-get install libio-socket-timeout-perl
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
E: Paket libio-socket-timeout-perl kann nicht gefunden werden.
sudo apt-get update hab ich vorher gemacht
pi@fhem ~ $ uname -a
Linux fhem 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux
ist ein Raspbian wheezy auf einem Raspberry Pi 2
Entweder auf jessie updaten, denn da gibt es das Paket.
Oder das Paket mittels cpan installieren. Hier steht im Abschnitt 'Install Perl Modules using CPAN automatically' wie das geht.
schade auch mit jessie funktioniert es leider nicht!! Somit kann ich das Modul auch nicht testen :-\
Zitat von: Volker Kettenbach am 28 August 2016, 00:20:56
Entweder auf jessie updaten, denn da gibt es das Paket.
Oder das Paket mittels cpan installieren. Hier steht im Abschnitt 'Install Perl Modules using CPAN automatically' wie das geht.
habe cpan eingerichtet, das Modul installiert, und den server neu gestartet:
cpan[1]> install IO::Socket::INET
Going to read '/home/pi/.cpan/Metadata'
Database was generated on Sun, 28 Aug 2016 05:17:02 GMT
IO::Socket::INET is up to date (1.31).
cpan[2]> install IO::Socket::Timeout
IO::Socket::Timeout is up to date (0.32).
geht leider nicht.
werde heute abend mal jessie neu aufsetzen. auf einer frischen SD Karte.
2016.08.28 13:40:15 0: Can't locate IO/Socket/Timeout.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/24_TPLinkHS110.pm line 31, <$fh> line 593.
BEGIN failed--compilation aborted at ./FHEM/24_TPLinkHS110.pm line 31, <$fh> line 593.
Zitatwerde heute abend mal jessie neu aufsetzen. auf einer frischen SD Karte.
Ich denke das werden die wenigsten machen, nur für ein neues Modul!
Zitat von: bjoernbo am 28 August 2016, 16:07:00
Ich denke das werden die wenigsten machen, nur für ein neues Modul!
Ich wollte eh auf Jessie updaten, um unter anderem an eine neuere Version von Kodi zu kommen.
Auf einem frischen Jessie läuft es. Man muss aber noch JSON installieren.
apt-get install libjson-perl
apt-get install libio-socket-timeout-perl
@Volker: Vielen Dank für das Plugin
ich verstehe es einfach nicht
Zitatpi@raspberrypi ~ $ sudo apt-get install libjson-perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
libjson-perl is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 46 not upgraded.
pi@raspberrypi ~ $ sudo apt-get install libio-socket-timeout-perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libio-socket-timeout-perl
pi@raspberrypi ~ $
Zitat von: bjoernbo am 28 August 2016, 18:42:00
ich verstehe es einfach nicht
Hast du mal ein sudo apt-get update und dann ein sudo apt-get upgrade gemacht?
Da sind 46 Pakete noch nicht auf dem neuesten Stand.
Dein RPi läuft mit jessie?
Danke für den Tipp! Eben durchgeführt, aber an dem Ergebnis ändert es leider nichts :-[
Das System ist nun auf dem aktuellsten Stand. Habt ihr noch einen Tipp???
Bitte mal den Output von " apt-cache policy libio-socket-timeout-perl " hier posten
Zitatpi@raspberrypi ~ $ sudo apt-cache policy libio-socket-timeout-perl
N: Unable to locate package libio-socket-timeout-perl
Bitte mal den Output von "cat /etc/apt/sources.list" posten.
Zitatpi@raspberrypi ~ $ cat /etc/apt/sources.list
deb http://packages.dotdeb.org wheezy all
deb-src http://packages.dotdeb.org wheezy all
deb http://packages.dotdeb.org wheezy-php55 all
deb-src http://packages.dotdeb.org wheezy-php55 all
deb http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi
Das system läuft auf wheezy. Da gibt es das Paket nicht.
Du musst auf jessie upgraden oder das Paket über das Kommando "cpan" installieren:
cpan IO::Socket::Timeout
Danke Volker!
Werde ich heute Abend einmal durchführen. Habe hierzu bereits eine Anleitung gefunden https://www.rootusers.com/how-to-upgrade-debian-7-wheezy-to-debian-8-jessie/ (https://www.rootusers.com/how-to-upgrade-debian-7-wheezy-to-debian-8-jessie/)
Ich hoffe danach funktioniert noch alles ::)
habe es mit
Zitatcpan IO::Socket::Timeout
zum laufen bekommen. Das Modul wird in FHEM erkannt und ist bereits eingerichtet! Läuft!
Gut!
Funktioniert die Steuerung der Steckdose bei allen?
Da es mir nur um das Auslesen der Wert geht, habe ich das nicht ausführlich getestet.Aber wenn ich den Status auf off setzte, passiert genau das was passieren soll. Die Steckdose geht aus ;D
@Volker: Kannst Du noch "Daily Average" irgendwie einbinden? Momentan ist ja nur der aktuelle Verbrauch ablesbar sowie der Gesamtverbrauch. In der Kasa-App gibt es ja auch o.g. Ausgabe noch.
Zitat von: bjoernbo am 31 August 2016, 16:43:47
@Volker: Kannst Du noch "Daily Average" irgendwie einbinden? Momentan ist ja nur der aktuelle Verbrauch ablesbar sowie der Gesamtverbrauch. In der Kasa-App gibt es ja auch o.g. Ausgabe noch.
Hallo Björn,
grundsätzlich ja.
Allerdings sind die Abfragen "teuer", d.h. Sie brauchen viel Rechenzeit und blockieren FHEM während der Abfrage.
Ich werde das mal implementieren und dann schauen, wie viel CPU-Zeit dafür verbraucht wird bzw. wie lange FHEM blockiert.
Dann sehen wir weiter.
Gruß
Volker
Hallo zusammen,
die Werte "daily_average" (per month) und "monthly_total" sind jetzt implementiert.
Hier ist das neue Modul: https://github.com/kettenbach-it/FHEM-TPLink-HS110
Gruß
VK
Hallo Volker!
Super! Herzlichen Dank. Funktioniert SUPER !!!
Hallo Volker,
vielen Dank für das Modul. Ich habe es installiert und mein hs100 wird auch erkannt. Leider stürzt anschließend fhem direkt ab. Das log sagt:
2016.09.05 19:21:05 1: PERL WARNING: "my" variable $command masks earlier declaration in same scope at ./FHEM/24_TPLinkHS110.pm line 142.
2016.09.05 19:21:05 1: PERL WARNING: "my" variable $c masks earlier declaration in same scope at ./FHEM/24_TPLinkHS110.pm line 143.
2016.09.05 19:21:05 1: PERL WARNING: "my" variable $socket masks earlier declaration in same scope at ./FHEM/24_TPLinkHS110.pm line 144.
2016.09.05 19:21:05 1: PERL WARNING: "my" variable $data masks earlier declaration in same scope at ./FHEM/24_TPLinkHS110.pm line 151.
2016.09.05 19:21:05 1: PERL WARNING: "my" variable $json masks earlier declaration in same scope at ./FHEM/24_TPLinkHS110.pm line 155.
2016.09.05 19:21:05 3: TPLinkHS110: my_hs100 defined.
2016.09.05 19:21:05 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/24_TPLinkHS110.pm line 175.
2016.09.05 19:21:07 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/24_TPLinkHS110.pm line 83.
2016.09.05 19:21:07 3: TPLinkHS110: my_hs100 Get called. Relay state: 1, RSSI: -60
Illegal division by zero at ./FHEM/24_TPLinkHS110.pm line 164.
FHEM läuft auf einem raspi 2 unter raspbian, alle Updates sind eingespielt. Hast Du eine Idee, was schief läuft?
Viele Grüße,
Robert
Habe da einen Verdacht und das Modul geändert.
Versuch es mal mit der neues Version, die jetzt auf github ist.
Gruß
Volker
Hallo Volker,
leider keine Änderung. Das log bringt genau dieselbe Ausgabe. Kann es daran liegen, dass ich kein Online Konto erstellt habe, sondern den Plug nur intern nutze?
Viele Grüsse,
Robert
Nein, das ist es sicher nicht.
Hast Du ein 100 oder 110?
Ist ein 100 ... gerade ausgepackt und in Betrieb genommen. Schalten per app geht einwandfrei.
In FHEM wird der Status Bildshirm aufgebaut, dann stürzt FHEM ab.
Okay, das erklärt einiges!
Ich denke, mit dem jetzt im github befindlichen Modul sollte es laufen!
Danke für den Bugreport!
Hallo Volker,
ich habe mein System nun im laufenden Betrieb von Whezzy auf Jessie geupdatet. Nun läuft es :-)
Vielen Dank für das Plugin
Du solltest auf jeden Fall auch das neueste Modul einsetzen, da die hs100 besser unterstützt wird!
Hallo Volker,
habe gerade die neuste Modul-Version eingespielt und siehe da .... es funktioniert :-) !
Vielen herzlichen Dank für das Modul inkl. Update!
Viele Grüsse,
Robert
Hallo Volker,
es läuft soweit alles. Aber im Log steht nach einem Neustart folgendes:
2016.09.07 15:59:24 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/24_TPLinkHS110.pm line 83.
2016.09.07 15:59:27 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/24_TPLinkHS110.pm line 176.
Hast du da eine Idee?
Viele Grüße
Stefan
An diesen Stellen wird im Code geprüft, ob das Attribut "disabled" gesetzt ist.
Falls das Attribut nicht existiert, kommt dieser Fehler.
Wenn Du den loswerden willst, dann setze disabled auf 0.
Zitat von: Volker Kettenbach am 07 September 2016, 21:06:02
An diesen Stellen wird im Code geprüft, ob das Attribut "disabled" gesetzt ist.
Falls das Attribut nicht existiert, kommt dieser Fehler.
Wenn Du den loswerden willst, dann setze disabled auf 0.
Danke für deine Antwort. Könnte man den Wert nicht per default auf 0 setzen?
Die Warnung würde doch sonst bei allen im Log stehen, oder?
Ist in der neuesten Version eingebaut!
Das Modul ist jetzt Teil des offiziellen FHEM Repositories
Steuert jemand die Steckdosen via Hostname an ?
z.b. define HS110 TPLinkHS110 HS110
Beim absetzen eines Schaltbefehls (mit definiertem Hostname), kommt die Fehlermeldung:
Couldn't connect to HS110:9999: IO::Socket::INET: Bad hostname 'HS110'
Mit der IP funktioniert meine HS110 ohne Probleme.
mfg
OGOL
Hallo,
ja, ich mache das und es funktioniert.
Die Fehlermeldung weisst auf eine nicht funktionierende Namensauflösung auf dem Host, auf dem FHEM läuft, hin.
Wenn Du nur "HS110" als Hostnamen verwenden willst, dann musst Du die Search-Domain auf dem host in /etc/resolv.conf richtig eintragen.
Oder Du gibst den Hostname im define als fqdn an.
Eine korrekte Auflösung über den DNS-Server oder die Datei /etc/hosts musst Du in jedem Fall sicher stellen.
Du kannst das auf den Host testen mit de Kommado "hostname"
rpi:~# host plug1
plug1.xxxxx..de has address 192.168.11.61
bzw.:
rpi:~# host plug1121
Host plug1121 not found: 3(NXDOMAIN)
Couldn't connect to HS110:9999: IO::Socket::INET: Bad hostname 'HS110'
Zitat von: Volker Kettenbach am 10 September 2016, 15:38:23
Die Fehlermeldung weisst auf eine nicht funktionierende Namensauflösung auf dem Host, auf dem FHEM läuft, hin.
Das wars !
Vielen Dank für das Plugin !
Ich empfehle jedem, die neueste Version ein zu spielen.
Entweder durch SVN Update oder auf github https://github.com/kettenbach-it/FHEM-TPLink-HS110
Ich habe einen Bug behoben, der zum Absturz von FHEM führen kann.
Hätte ich mal hier zuerst nachgeschaut! War schon verzweifelt! DANKE. Jetzt läuft es wieder.
Ich dachte heute morgen schon, was ist denn jetzt los. Hing das mit dem UPDATE der APP zusammen die auf iOS10 verfügbar war?
Zitat von: Volker Kettenbach am 20 September 2016, 11:55:18
Ich habe einen Bug behoben, der zum Absturz von FHEM führen kann.
DANKE. Jetzt läuft alles wieder :D
Hallöchen ...
Habe zufällig Dein Modul gefunden und daraufhin mal eine dieser HS110 bestellt.
Erstinbetriebnahme war etwas krampfig - schade, dass das Setup nur per App möglich ist.
Danach funktioniert die Steckdose recht gut. Danke für Deine Arbeit.
Habe noch ein paar Userreadings hinzugefügt:
powerR { my $pp = (split '"."',ReadingsVal("$name","power",0)) [0]; substr($pp,0,3); },
voltageR { my $pp = (split '"."',ReadingsVal("$name","voltage",0)) [0]; substr($pp,0,3); }
So werden die Daten bei Power und Voltage ohne Komma angezeigt.
Evtl. kann man dies ja direkt ins Modul einbauen und/oder für User, die lieber auf's millionstel genaue Daten haben möchten, die Anzahl der Nachkommastellen (u.U. mit Rundung) per Attribut einstellbar machen -> rounddecimalplaces {Anzahl Stellen / default wenn nicht gesetzt}?
Weiterhin setze ich per DOIF den Interval auf 60 (Sekunden), sobald die HS110 angeschaltet wird und lösche dies wieder, sobald sie wieder ausgeschaltet wird. Wäre auch eine Idee, dies direkt ins Modul zu implementieren, wenn machbar -> intervalwhenon {sekunden / default wenn nicht gesetzt} ;)
Grüße ... Sebastian
Hallo,
habe mal eben in mein Logfile geschaut und habe unendlich Meldungen : Hier mal ein Auszug:
Zitat2016.10.14 07:15:15 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056831) line 1, near "0)"
2016.10.14 07:15:20 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056835) line 1, near "0)"
2016.10.14 07:15:25 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056838) line 1, near "0)"
2016.10.14 07:15:30 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056841) line 1, near "0)"
2016.10.14 07:15:35 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056844) line 1, near "0)"
2016.10.14 07:15:40 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056847) line 1, near "0)"
2016.10.14 07:15:45 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056850) line 1, near "0)"
2016.10.14 07:15:50 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056853) line 1, near "0)"
2016.10.14 07:15:55 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056858) line 1, near "0)"
2016.10.14 07:16:00 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056878) line 1, near "0)"
2016.10.14 07:16:05 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056881) line 1, near "0)"
2016.10.14 07:16:10 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056884) line 1, near "0)"
2016.10.14 07:16:15 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056889) line 1, near "0)"
2016.10.14 07:16:20 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056892) line 1, near "0)"
2016.10.14 07:16:25 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056897) line 1, near "0)"
2016.10.14 07:16:30 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056901) line 1, near "0)"
2016.10.14 07:16:35 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056906) line 1, near "0)"
2016.10.14 07:16:40 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056911) line 1, near "0)"
2016.10.14 07:16:45 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056914) line 1, near "0)"
2016.10.14 07:16:50 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 1056918) line 1, near "0)"
Moin
Mal eine kurze Frage so zwischendrin. Kann man die Steckdose so konfigurieren, dass Sie nach einem Stromausfall wieder an geht? (Kuehlschrank!)
Gruss Christoph
Zitat von: pc1246 am 14 Oktober 2016, 09:18:28
Moin
Mal eine kurze Frage so zwischendrin. Kann man die Steckdose so konfigurieren, dass Sie nach einem Stromausfall wieder an geht? (Kuehlschrank!)
Gruss Christoph
Meiner Kenntnis nach leider nicht. Bin auch schon drauf rein gehalten.
Was du aber machen kannst, ist einen schedule einrichten, der die Steckdose zum Beispiel 1x pro Stunde einschaltet. Das geht derzeit nur über die app.
Hi,
tschuldigung schon mal für die möglicherweise doofe Frage.
Ich hab ein aktuelles fhem auf einem Raspi testweise laufen. Jetzt hab ich versucht dein Modul zu laden bzw. mit define anzulegen.
Dabei kommt "Modul TPLinkHS110 nicht vorhanden".......zumindest sinngemäß.
Bin gerade nicht zu Hause darum aus dem Gedächtnisprotokoll.
Wie kann ich das Modul installieren?
Bzw. wo muß ich es hinschieben?
in der FHEM Zeile folgendes Eintrag:
update check
dann sollte es angezeigt werden. Danach
update all
Danke für den Tip,hat leider nix gebracht! :'(
Die Meldung lautet: Cannot load Modul TPLinkHS110
Dieses Modul stand aber auch nicht bei update check dabei......
Also sollte es doch schon installiert sein oder?
Update:
Ich habe Raspberrian nochmal neu installiert,vorher möglicherweiße totgespielt ;-) ,fhem neu......und siehe da es funktioniert!
Danke für das Modul!!!
Hallo,
zuerst einmal vielen Dank für das Modul. Ich habe mittlerweile 6 TPLinkHS110 im Einsatz und bin soweit auch zufrieden!.
Hin und wieder kommt es beim Schalten zu einem Fehler, wobei dann die betroffene Steckdose auch über die APP nicht
mehr zu schalten ist und als inaktiv dargestellt wird. Das übelste ist aber, das FHEM dann nicht mehr reagiert.
Beim Neustart des Servers erscheint im Log folgende Fehlermeldung:
2016.11.14 15:12:52.813 1: PERL WARNING: substr outside of string at ./FHEM/24_TPLinkHS110.pm line 310.
2016.11.14 15:12:52.813 1: PERL WARNING: Use of uninitialized value $_[0] in split at ./FHEM/24_TPLinkHS110.pm line 310.
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/24_TPLinkHS110.pm line 107.
Das Device sieht so aus:
Internals:
DEF 192.168.1.10
HOST 192.168.1.10
INTERVAL 300
NAME stSteckdose2
NEXTUPDATE Mon Nov 14 15:24:37 2016
NR 670
STATE off
TIMEOUT 1
TYPE TPLinkHS110
Readings:
2016-11-14 15:19:37 active_mode schedule
2016-11-14 15:19:37 alias Steckdose 2
2016-11-14 15:19:37 dev_name Wi-Fi Smart Plug
2016-11-14 15:19:37 deviceId 80065A934CBB34FC14E1EB59D8481541174CF316
2016-11-14 15:19:37 err_code 0
2016-11-14 15:19:37 feature TIM
2016-11-14 15:19:37 fwId BFF24826FBC561803E49379DBE74FD71
2016-11-14 15:19:37 hwId 22603EA5E716DEAEA6642A30BE87AFCA
2016-11-14 15:19:37 hw_ver 1.0
2016-11-14 15:19:37 icon_hash
2016-11-14 15:19:37 latitude 0
2016-11-14 15:19:37 led_off 0
2016-11-14 15:19:37 longitude 0
2016-11-14 15:19:37 mac 50:C7:BF:03:FD:13
2016-11-14 15:19:37 model HS100(EU)
2016-11-14 15:19:37 oemId 812A90EB2FCF306A993FAD8748024B07
2016-11-14 15:19:37 on_time 0
2016-11-14 15:19:37 relay_state 0
2016-11-14 15:19:37 rssi -57
2016-11-14 15:19:37 state off
2016-11-14 15:19:37 sw_ver 1.0.8 Build 151101 Rel.24452
2016-11-14 15:19:37 type smartplug
2016-11-14 15:19:37 updating 0
Attributes:
disable 0
room 020_Steckdosen
Ist es vielleicht möglich den Fehler abzufangen, damit die Steckdose nicht den FHEM-Prozeß killt.
Gruß Norbert
Zitat von: redlav am 14 November 2016, 21:56:33
Ist es vielleicht möglich den Fehler abzufangen, damit die Steckdose nicht den FHEM-Prozeß killt.
Danke für den präzisen Report!
Ist auf jeden Fall machbar.
Ich schaue, dass ich mich nachher mal dran setze!
So, ich habe eine paar Sicherheitschecks eingebaut, dass FHEM im Falle eines gecrashten HS100/110 nicht auch crashed.
Code ist im github und (ich glaube) am morgen auch im FHEM-SVN.
Würde ich mich über Feedback und weitere Bugreports freuen.
Meine Erfahrungen mit dem TPLinks sind auch ganz gut. Man bekommt viele Features für wenig Geld und die FHEM-Anbindung funktioniert auch gut.
Hallo Volker,
nach dem Update hatte ich heute das erste mal wieder das Problem mit der Steckdose. Dieses mal ist FHEM aber nicht abgestürzt :)
Offensichtlich verträgt sich die Steckdose nicht mit einem eingesteckten Netzteil eines kleinen Springbrunnen und verliert dadurch
die wlan-Verbindung. Die gleiche Steckdose mit einer Lampe funktioniert ohne Problem.
Vielen Dank für deinen schnellen Support!
Gruß Norbert
Ich habe leider das Problem, dass sich FHEM regelmäßig beim ersten/zweiten Ausschaltvorgang der TPLink-Steckdose aufhängt und nur noch ein FHEM Neustart hilft. FHEM läuft noch, aber es passiert nichts mehr und FHEM ist über das Webinterface nicht mehr erreichbar.
Ich habe als 24_TPLinkHS110.pm den neuesten Code von Github verwendet. Hilft aber leider nicht :-(
Für Hilfe wäre ich dankbar!
Nachtrag:
Ich habe jetzt den Hostnamen durch die IP-Adresse ersetzt und jetzt scheint es stabil(er) zu funktionieren. Werde das mal weiter beobachten.
Wie ist das bei Euch, funktioniert es zuverlässig oder gibt es immer mal wieder Aussetzer/fehlerhafte Schaltvorgänge?
Viele Grüße
Christian
Bei mir läuft es stabil.
Auch mit hostname.
Aber ich schalte auch nicht oft.
Aber ich Frage alle 5 Minuten die Readings ab.
HI,
ich habe 5 TPLink HS110 im Einsatz. Manchmal bekomme ich folgende Fehler-Meldung (verschiedene Geräte, nicht nachvollziehbar wann):
-->json-decoding failed. Problem decoding getting statistical data
Daraufhin habe ich ein paar Debug-messages eingebaut und herausgefunden dass in dem eval (Zeile 157) das letzte readingsBulkUpdate schiefgeht, weil $count = 0 ist und die Division dann scheitert.
$jason enthält folgende Daten:
{"emeter":{"get_daystat":{"day_list":[],"err_code":0}}}
Kann es sein, dass dass Array-Format in day_list der Grund ist - wenn die Abfrage klappt, ist es wie erwartet ein Hash
Testweise habe ich ein if ($count) um das letzte readingsBulkUpdate gebaut und damit die Fehlermeldung erledigt.
Viele Grüße
Zitat von: cs1711 am 24 November 2016, 22:02:10
Ich habe leider das Problem, dass sich FHEM regelmäßig beim ersten/zweiten Ausschaltvorgang der TPLink-Steckdose aufhängt und nur noch ein FHEM Neustart hilft. FHEM läuft noch, aber es passiert nichts mehr und FHEM ist über das Webinterface nicht mehr erreichbar.
Ich habe als 24_TPLinkHS110.pm den neuesten Code von Github verwendet. Hilft aber leider nicht :-(
Für Hilfe wäre ich dankbar!
Nachtrag:
Ich habe jetzt den Hostnamen durch die IP-Adresse ersetzt und jetzt scheint es stabil(er) zu funktionieren. Werde das mal weiter beobachten.
Jetzt hatte ich gerade wieder einen FHEM Hänger, weil die Steckdose nicht erreichbar ist. Auch die TPLink-Software KASA meldet, dass der Device nicht erreichbar ist.
Das sie nicht schaltet, weil sie nicht im WLAN erreichbar ist, ist ja eine Sache. Aber das FHEM sich komplett deswegen aufhängt und damit auch sämtliche andere (automatische) Steuerung nicht mehr geht, ist schon extrem ärgerlich.
Bin nun leider kein PERL-Spezialist, aber kann man das ggf. irgendwie weiter stabilisieren?
Wie ist das timeout Attribut bei Dir gesetzt?
Hallo Volker,
TIMEOUT 1
Sollte das auf einem anderen Wert stehen?
Viele Grüße
Christian
Nein.
An sich sollte fhem nach einer Sekunde aufgeben, wenn keine Verbindung zur Steckdose zu Stande kommt.
Antwortet Deine Steckdose noch auf Ping, wenn sie hängt?
Kann ich Dir leider nicht sagen, vergessen zu überprüfen. Checke ich beim nächsten Hänger. Hilft es Dir bei der Fehleranalyse, wenn ich einen bestimmten Loglevel o. ä. setze?
Im FHEM Log kann ich sehen, dass alle fünf Minuten bis 20:57:33 der Status abgefragt wurde:
2016.11.30 20:57:33 3: TPLinkHS110: ESSZIMMER_ECKE Get called. Relay state: 1, RSSI: -53
2016.11.30 20:57:33 3: TPLinkHS110: ESSZIMMER_ECKE Device is an HS110. Got extra realtime data: 2.326024 Watt, 237.422021 Volt, 0.023718 Ampere
2016.11.30 20:57:33 3: TPLinkHS110: ESSZIMMER_ECKE Get end
Dann ist der nächste Befehl:
2016.11.30 21:01:00 3: TPLinkHS110: ESSZIMMER_ECKE Set <off> called
Danach ist Schluß.
Timeout 1 bedeutet, dass FHEM durchaus für eine Minute hängen könnte, bis der Timeout zuschlägt?
Nein, es bedeutet eine Sekunde!
Zitat von: pc1246 am 14 Oktober 2016, 09:18:28
Moin
Mal eine kurze Frage so zwischendrin. Kann man die Steckdose so konfigurieren, dass Sie nach einem Stromausfall wieder an geht? (Kuehlschrank!)
Gruss Christoph
Hallo.
Ich habe die Firmware sw_ver 1.0.8 Build 151101 Rel.24452 auf meiner gerade gekaufte HS110. Wenn sie eingeschaltet ist und stromlos "wird" kehrt sie nach "Rückkehr" des Stroms wieder in den "AN-Zustand" zurück. Evtl. hilft also ein Firmwareupdate?
Gruß
Andre
Hallo.
Erstmal vielen Dank für die ganze Arbeit. Auch ich musste auf Jessie upgraden borvor es funktionierte. Was mich interessiert ist ob man den Schalten (An/Aus) sperren kann und auch die Schaltfunktion in FHEM "deaktivieren" kann. Hintergrund ist das ich die Dose bzw. bestimmte Dosen nur für die Verbrauchsmessung nutzen möchte und daher diese Funktion gerne gegen Fremdzugriff schützen möchte.
Danke für jede Hilfe.
Gruß
Andre
Schau Dir mal die Attribute dummy und webcmd an.
Zitat von: rola am 26 November 2016, 10:16:01
HI,
ich habe 5 TPLink HS110 im Einsatz. Manchmal bekomme ich folgende Fehler-Meldung (verschiedene Geräte, nicht nachvollziehbar wann):
-->json-decoding failed. Problem decoding getting statistical data
Daraufhin habe ich ein paar Debug-messages eingebaut und herausgefunden dass in dem eval (Zeile 157) das letzte readingsBulkUpdate schiefgeht, weil $count = 0 ist und die Division dann scheitert.
$jason enthält folgende Daten:
{"emeter":{"get_daystat":{"day_list":[],"err_code":0}}}
Kann es sein, dass dass Array-Format in day_list der Grund ist - wenn die Abfrage klappt, ist es wie erwartet ein Hash
Testweise habe ich ein if ($count) um das letzte readingsBulkUpdate gebaut und damit die Fehlermeldung erledigt.
Viele Grüße
Danke für den Tip!
Ich habe den Code angepasst und eingecheckt.
Ab morgen ist das auch im offiziellen FHEM drin.
auch auf die Gefahr hin, dass ich mich wiederhole! Das Modul läuft einwandfrei, allerdings wird mein globales-FHEM Logfile mit folgenden Einträgen zugefüllt !
Zitat2016.12.01 00:00:04 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 543933) line 1, near "0)"
2016.12.01 00:00:09 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 543937) line 1, near "0)"
2016.12.01 00:00:14 3: WattVerbrauchsmesser: Too many arguments for main::ReadingsVal at (eval 543942) line 1, near "0)"
Diese Einträge ziehen sich fast bis ins unendliche fort!
Da alles einwandfrei läuft, daher die Frage, kann ich es irgendwie unterbinden das diese Einträge ins FHEM-LOGFILE geschrieben werden?
Komisch.
Neueste Modulversion im Einsatz?
Wie ist Dein define?
Wie ist der loglevel?
Sorry für die blöde Frage aber ich stehe gerade maximal auf dem Schlauch. ???
Was für Werte werden zurückgeliefert, um welche Einheiten handelt es sich?
current = Aktueller Strom in A
voltage = Aktuelle Spannung in V
daily_average = Tagesdurchschnitt in Wh? Sprich, Wie viel W hat das Gerät im Durchschnitt pro Stunde verbraucht
monthly_total = Monat Gesamt in Wh?
total = Gesamtzähler in Wh?
Irgendwie ergeben die Zahlen für mich keinen Sinn und ich habe das Gefühl völlig daneben zu liegen. Ich würde gerne aus den Daten den Stromverbrauch in kw/h berechnen, bin mir jedoch nicht sicher was ich hier für Werte vor mir habe.
Zitat von: DasB am 02 Januar 2017, 18:07:31
Sorry für die blöde Frage aber ich stehe gerade maximal auf dem Schlauch. ???
Was für Werte werden zurückgeliefert, um welche Einheiten handelt es sich?
current = Aktueller Strom in A
voltage = Aktuelle Spannung in V
daily_average = Tagesdurchschnitt in Wh? Sprich, Wie viel W hat das Gerät im Durchschnitt pro Stunde verbraucht
monthly_total = Monat Gesamt in Wh?
total = Gesamtzähler in Wh?
Irgendwie ergeben die Zahlen für mich keinen Sinn und ich habe das Gefühl völlig daneben zu liegen. Ich würde gerne aus den Daten den Stromverbrauch in kw/h berechnen, bin mir jedoch nicht sicher was ich hier für Werte vor mir habe.
Schau mal in der App.
Fhem gibt die gleichen Werte aus wie die App.
Ich weiss es nämlich auch nicht genau.
Gute Idee,
warum bin ich da nicht selbst drauf gekommen :-X
Habe die Werte mal verglichen, irgendwie werde ich da nicht schlau daraus. Das passt doch nicht zusammen?
Readings:
2017-01-02 20:11:13 current 0.032747
2017-01-02 20:11:13 daily_average 0.4885
2017-01-02 20:11:13 monthly_total 0.977
2017-01-02 20:11:13 on_time 263972
2017-01-02 20:11:13 power 0
2017-01-02 20:11:13 relay_state 1
2017-01-02 20:11:13 rssi -78
2017-01-02 20:11:13 state on
2017-01-02 20:11:13 sw_ver 1.0.8 Build 151101 Rel.24452
2017-01-02 20:11:13 total 0.977
2017-01-02 20:11:13 type smartplug
2017-01-02 20:11:13 updating 0
2017-01-02 20:11:13 voltage 224.478151
Zitat von: DasB am 02 Januar 2017, 20:13:30
Gute Idee,
warum bin ich da nicht selbst drauf gekommen :-X
Habe die Werte mal verglichen, irgendwie werde ich da nicht schlau daraus. Das passt doch nicht zusammen?
Readings:
2017-01-02 20:11:13 current 0.032747
2017-01-02 20:11:13 daily_average 0.4885
2017-01-02 20:11:13 monthly_total 0.977
2017-01-02 20:11:13 on_time 263972
2017-01-02 20:11:13 power 0
2017-01-02 20:11:13 relay_state 1
2017-01-02 20:11:13 rssi -78
2017-01-02 20:11:13 state on
2017-01-02 20:11:13 sw_ver 1.0.8 Build 151101 Rel.24452
2017-01-02 20:11:13 total 0.977
2017-01-02 20:11:13 type smartplug
2017-01-02 20:11:13 updating 0
2017-01-02 20:11:13 voltage 224.478151
Die aktuellen Werte passen:
monthly_total = Total Consumption (gerundet auf 2 Nachkommastellen)
power = current power
Die Daily AVgs passen irgendwie nicht.
Vorschlag: versuch mal mit dem CLI-Tool Deine Geräte aus zu lesen:
./tplink_hs110_cmd.pl -i plug1 -c daystat
./tplink_hs110_cmd.pl -i plug1 -c monthstat
Es gibt in der Steckdose nämlich daily und monthly stats.
Was das "Daily in past 7 days" und "daily ind 30 days" in der App bedeuten soll, verstehe ich nämlich auch nicht.
Mit den CLI Tool siehst Du, was aus der Steckdose wirklich an Daten kommt.
Okay, die Werte passen.
Angaben sind kWh.
Hallo!
Ich verwende einige der HS100 und habe das Problem, dass sich fhem alle paar Tage einmal aufhängt - der letzte Logeintrag ist immer von TPLinkHS110. da ich einen Watchdog laufen habe, ist das nicht so dramatisch, aber vielleicht lässt sich der Fehler ja finden. Hier die letzten Logeinträge vom gestrigen Hänger:
2017.01.07 22:52:07 3: TPLinkHS110: 13.Smartplug.01 Get called. Relay state: 1, RSSI: -77
2017.01.07 22:53:07 3: TPLinkHS110: 13.Smartplug.01 Set <off> called
2017.01.07 22:53:17 3: TPLinkHS110: 13.Smartplug.01 Get called. Relay state: 0, RSSI: -77
2017.01.07 22:53:20 3: TPLinkHS110: 15.Smartplug.03 Set <off> called
2017.01.07 22:53:30 3: TPLinkHS110: 11.Smartplug.05 Get called. Relay state: 0, RSSI: -59
2017.01.07 22:53:35 1: PERL WARNING: substr outside of string at ./FHEM/24_TPLinkHS110.pm line 315.
2017.01.07 22:53:35 1: PERL WARNING: Use of uninitialized value $_[0] in split at ./FHEM/24_TPLinkHS110.pm line 315.
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/24_TPLinkHS110.pm line 137.
Falls ich für den nächsten Hänger an den Logs was ändern soll, bitte um Info.
lG Kurt
Hi Kurtl,
danke für die Info.
Zwei Dinge fallen mir dazu ein:
1. Scheinbar liefert Deine HS100 unvollständige oder leere Daten zurück. Warum Sie das tut, weiss ich auch nicht. Vlt. solltest Du mal prüfen, ob es ein Softwareupdate für das Ding gibt. Meine HS110s machen das jedenfalls nicht.
Das Abfangen diesen Fehlers ist machbar. Ich werde die Tage dafür was programmieren und ins nächste Release bringen.
2. Warum FHEM sich dabei aufhängt, weiss ich auch nicht. Das sollte an sich nicht sein, denn es ist keine Division durch 0 oder ähnlich involviert.
Gruß
Volker
So, ich hab's gleich gemacht.
Entweder ab morgen das Modul 24_TPLinkHS110 aus dem FHEM-SVN holen oder ab sofort hier:
https://github.com/kettenbach-it/FHEM-TPLink-HS110/blob/master/24_TPLinkHS110.pm
Ab Log-Level 1 wird geloggt, wenn das TPLink Gerät 0-Daten sendet und ab Log-Level 2 werden Fehler im JSON geloggt.
Ich empfehle also mal den Betrieb mit 2.
Bei Bedarf auch 3, dann werden auch Decoding-Ergebnisse geloggt.
Viel Spaß!
Hi!
Danke, werde ich gleich einspielen. Meine Steckdosen sind übrigens HS110 (habe mich oben vertippt) und sind alle auf der aktuellen Firmware.
lG Kurt
Hallo, heute wollte ich das neue Modul testen. Allerdings ohne Erfolg. Die beiden benötigten Perl-Module sind am dem Raspberry Pi 3 installiert. Es erscheint die Fehlermeldung in FHEM: Cannot load Modul TPLinkSSH110.
Woran kanns liegen?
Das Modul heisst TPLinkHS110 und nicht TPLinkSSH110
In meinem letzten Beitrag habe ich mich leider vertippt.
Es erscheint weiterhin die Fehlermeldung "Cannot load Modul TPLinkHS110".
FHEM ist up to date. Auch die benötigten Perl-Module wurden über capnm installiert geben die Rückmeldung up to date zu sein.
Was mache ich falsch??
Bitte aus dem Log File mal eine ausführlichere Fehlermeldung kopieren, da sich mit diesen Informationen nichts sagen lässt.
Dafür ggf. den Loglevel erhöhen.
Hallo Volker,
erstmal vielen Dank für dein tolles Modul. Es läuft bei mir soweit sehr gut und stabil.
Einen kleinen Verbesserungsvorschlag hätte ich noch:
Mir fehlt ein Reading mit dem kWh Verbrauch für den aktuellen Tag (vielleicht habe ich es auch nur übersehen). daily_average liefert ja nur einen Durchschnittswert der letzten Tage oder Monate? Ich habe den gewünschten Wert mal provisorisch in deinen Code eingefügt:
foreach my $key (sort keys @{$json->{'emeter'}->{'get_daystat'}->{'day_list'}}) {
foreach my $key2 ($json->{'emeter'}->{'get_daystat'}->{'day_list'}[$key]) {
$total = $total+ $key2->{'energy'};
# added for "daily_total" reading
if ($key2->{'day'} == $mday) {
readingsBulkUpdate($hash, "daily_total", sprintf("%.3f", $key2->{'energy'}));
}
# end added
}
}
Es wäre schön, wenn du das als Standard in Deinen Code mit aufnehmen könntest.
Außerdem wäre es schön, wenn du die Readings wie power, daily_average, current, voltage... etwas runden könntest (z.B. 2 Nachkommastellen). Dann würde die event-on-change-reading Option die Daten etwas effektiver reduzieren können.
Viele Grüße
Frank
Hallo Frank,
das Reading habe ich eingebaut.
Das Modul ist in git (https://github.com/kettenbach-it/FHEM-TPLink-HS110) und SVN - also ab morgen über die Update Funktion von FHEM zu bekommen.
Vielen Dank für den Tip!
Was das Runden angeht: ich hatte auch schon darüber nachgedacht. Aber wenn ich das jetzt einbaue, ruft ein anderer, dass er das nicht will sondern die exakten Werte.
Daher lasse ich es und verweise auf die Bordmittel von FHEM - Stichwort userReadings.
Gruß
Volker
Hallo Volker,
wow, das ging ja schnell, vielen Dank dafür!
Das Runden werde ich dann selbst in userReadings machen.
Viele Grüße
Frank
Hallo zusammen,
mein FHEM läuft auf einer Diskstation und ich bekomme immer den Fehler der hier auch schon beschrieben wurde.
Can't locate IO/Socket/Timeout.pm
Bei IO::Socket::Timeout bekomme ich immer folgenden Fehler:
ZitatRunning install for module 'IO::Socket::Timeout'
Running Build for D/DA/DAMS/IO-Socket-Timeout-0.32.tar.gz
Has already been unwrapped into directory /root/.cpan/build/IO-Socket-Timeout-0.32-0n6Ecy
'/opt/bin/perl Build.PL ' returned status 512, won't make
Running Build test
Make had some problems, won't test
Running Build install
Make had some problems, won't install
Hat jemand eine Idee was ich falsch mache?
Grüße Ralf
Da heb ich schon mal was dazu geschrieben:
https://forum.fhem.de/index.php/topic,52124.msg544426.html#msg544426
Wenn Du nicht die nächsten Wochen damit verbringen willst, auf das Nas ein vollwertiges Linux zu installieren, würde ich empfehlen, einen Raspberry Pi zu kaufen.
Ansonsten bitte an ein Synology Forum wenden, dann das ganze ist kein Thema für FHEM.
Ahoi!
Ich bin grade auf des Rätsels Lösung gestoßen, das mich seit Wochen plagt (bzw seit ich die Funksteckdose durch ne HS110 ersetzt habe): mein FHEM-Prozess auf dem Raspberry 1 B stürzt komplett ab. Log sieht direkt nach dem Absturz immer so aus:
2017.01.26 17:26:07 3: TPLinkHS110: Steckdose Set <on> called
2017.01.26 17:26:07 3: TPLinkHS110: Steckdose Get called. Relay state: 1, RSSI: -64
2017.01.26 17:26:07 3: TPLinkHS110: Steckdose Device is an HS110. Got extra realtime data: 0 Watt, 233.998885 Volt, 0.019419 Ampere
2017.01.26 17:26:07 3: TPLinkHS110: Steckdose Get end
2017.01.26 17:26:16 3: TPLinkHS110: Steckdose Set <dim> called
2017.01.26 17:26:16 1: PERL WARNING: Use of uninitialized value $_[0] in split at ./FHEM/24_TPLinkHS110.pm line 317.
2017.01.26 17:26:20 1: PERL WARNING: substr outside of string at ./FHEM/24_TPLinkHS110.pm line 328.
2017.01.26 17:26:20 1: PERL WARNING: Use of uninitialized value $_[0] in split at ./FHEM/24_TPLinkHS110.pm line 328.
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/24_TPLinkHS110.pm line 223.
Jetzt gerade so:
2017.01.30 16:52:13 3: TPLinkHS110: Steckdose Set <on> called
2017.01.30 16:52:13 3: TPLinkHS110: Steckdose Get called. Relay state: 1, RSSI: -63
2017.01.30 16:52:13 3: TPLinkHS110: Steckdose Device is an HS110. Got extra realtime data: 0 Watt, 234.236638 Volt, 0.019231 Ampere
2017.01.30 16:52:13 2: TPLinkHS110: Steckdose json-decoding failed. Problem decoding getting statistical data
2017.01.30 16:52:13 3: TPLinkHS110: Steckdose Get end
2017.01.30 16:55:57 3: TPLinkHS110: Steckdose Set <discoSpeedDown> called
2017.01.30 16:55:57 1: PERL WARNING: Use of uninitialized value $_[0] in split at ./FHEM/24_TPLinkHS110.pm line 317.
2017.01.30 16:56:01 1: PERL WARNING: substr outside of string at ./FHEM/24_TPLinkHS110.pm line 328.
2017.01.30 16:56:01 1: PERL WARNING: Use of uninitialized value $_[0] in split at ./FHEM/24_TPLinkHS110.pm line 328.
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/24_TPLinkHS110.pm line 223.
Ich habe ne Funksteckdose, 3 Milights und die HS110 in einer Structure, also Gruppe. Den Funksteckdose waren unbekannte Befehle bisher wurscht, aber dein Script steigt aus wenn nach "Set" was Unbekanntes kommt (wie hier <dim> oder <discoSpeedDown>).
Kannst Du Dir dafür bitte was überlegen? Ich mag das Modul und die Steckdose inzwischen nämlich schon gern...
Danke Dir!
Sebastian
Hallo Sebastian,
danke für den Bugreport. In der Tat fehlte da die Abfrage für ungültige Kommandos.
Ich kann es zwar mangels Gruppe nicht testen, denke aber, dass die neueste Version des Moduls bei Dir stabil laufen sollte.
Probier es einfach aus!
Das neue Modul ist ab sofort im github (https://github.com/kettenbach-it/FHEM-TPLink-HS110) und ab morgen im SVN.
Gruß
Volker
Sieht gut aus, die Milight Kommandos machen dem Modul jetzt nichts mehr aus. Im Log steht auch nichts bedenkliches. Danke dir!
Hallo,
erstmal Danke für das Modul und damit die Einbindung der HS110 in FHEM.
Eine Frage habe ich. Kann ich den Status der Dose direkt bei der Dose abfragen? Hintergrund ist der weil ich die Dose auch über den Amazon Echo schalte und wenn ich die Zeit ungünstig war erst nach 5 Minuten im FHEM sehen das sie geschaltet ist. Würde es z.B. über einen at Befehl alle 5 Sekunden oder so dann machen.
Danke
Gruß
Jörg
Das Device hat Standardmäßig einen Intervall von 300s, wenn du es einrichtest:
Attribute
interval: Das Intervall in Sekunden, nach dem FHEM die Messwerte aktualisiert. Default: 300s
Eine Aktualisierung der Messwerte findet auch bei jedem Schaltvorgang statt.
Wenn du die Steckdose jetzt manuell oder per Echo schaltest dauert es im ungünstigsten Fall 300s
bis der Status in FHEM akualisiert wird. Wenn du es schneller haben willst, musst du den Intervall
verkleinern, wobei das permanente pollen vermutlich bei vielen Steckdosen auch nicht optimal ist.
So ist das halt, wenn man von unterschiedlichen Systemen ein Gerät schaltet.
http://fhem.de/commandref_DE.html#TPLinkHS110 (http://fhem.de/commandref_DE.html#TPLinkHS110)
Wie redlav schreibt: Intervall verkürzen.
Oder Amazon Echo ein FHEM Kommando absetzen lassen und FHEM den Schaltvorgang vornehmen lassen.
Wobei ich nicht weiss, ob es bereits für dieses Gerät Schnittstellen gibt.
Hallo Volker,
könntest Du bitte alle Aufrufe von
my $json = decode_json($data);
durch ein eval absichern? Mir ist jetzt der FHEM Server z.B beim Schalten der Steckdose abgestürzt.
Wie kommt es eigentlich, dass der FHEM Server durch einen Fehler durch korrupte Daten beim decode_json
komplett abstürzt. Könnte man sowas nicht im Server durch einen "die" Handler abfangen?
Generell bin ich aber nicht sehr zufrieden mit der TPLink-Steckdose, da diese mit meinem Speedport-Router
nicht sauber zusammen arbeitet. Irgendwann kann der Router den Namen der Steckdose nicht mehr auflösen
und FHEM kann diese nicht mehr erreichen. Ich kann im Speedport leider auch keine feste IP-Adresse für die
Steckdose vergeben. Also muss ich die Adresse des Devices ständig im FHEM anpassen...
Viele Grüße
Frank
Ist erledigt!
Danke für den Vorschlag!
Modul list up-to-date im github und ab morgen im SVN.
Supi, danke Dir!
Mein Problem mit der Adressauflösung und den dynamischen IP-Adressen habe ich jetzt dadurch gelöst, dass ich meinen Speedport-Router durch eine Fritzbox abgelöst habe. Bei der Fritzbox funktioniert die Auflösung der Hostnamen einwandfrei und macht mir das Leben mit FHEM und Homeautomation wesentlich leichter.
Hallo Volker,
gestern hatte ich seit langem mal wieder ein Problem:
2017.04.15 10:30:02.431 1: PERL WARNING: Use of uninitialized value $_[0] in split at ./FHEM/24_TPLinkHS110.pm line 328.
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/24_TPLinkHS110.pm line 108.
Nach dem schalten der Steckdose war das die letzte Zeile im Log, bevor fhem gestorben ist. Ich kann den Fehler nicht
reproduzieren und die steckdose funktioniert seitdem wieder. Kannst du den Fehler vielleicht abfangen, damit der nicht das
System abschießt?
Gruß Norbert
Hallo Volker,
ich setze Dein TPLink Modul derzeit testweise ein und habe folgendes Problem festgestellt:
Bei einer TPLink HS110 Steckdose im Wohnzimmer habe ich absolut keine Probleme mit dem Ein- und Ausschalten. Funktioniert immer auf Anhieb beim ersten Mal.
Bei zwei weiteren HS110 Steckdosen im Pavillon und im Gartenhaus klappt das Einschalten meistens nicht beim ersten Mal. Stattdessen kommt nach ein paar Sekunden die Fehlermeldung: Couldn't connect to 192.168.1.58:9999: IO::Socket::INET: connect: timeout
Erst nach dem zweiten oder dritten Anlauf lässt sich die Steckdose dann einschalten. Danach klappt das Ein- und Ausschalten problemlos.
Ich habe mal den TimeOut auf 5 Sekunden erhöht, konnte das Problem damit aber nicht lösen.
Mein WLAN im Garten ist vermutlich nicht so stark wie im Haus, was eventuell eine Erklärung sein könnte. Mit der Kasa App habe ich diese Probleme aber nicht und die Steckdosen lassen sich alle gut schalten.
Vielen Dank für Deine Hilfe.
Grüße Mave
Hallo Mave,
dasvProbkem habe ich auch hin und wieder.
Ich habe auch keine Ahnung, woran das liegt.
Ich könnte versuchen, den request bei einem timeout nochmal zu schicken.
Moin Volker,
das würde ich sehr begrüßen.
Vielen Dank.
Grüße Mave
Ich habe das jetzt mal so gelöst, dass im Falle eine Timeout genau 1x versucht wird, nochmal zu senden (schalten).
Mal schauen, ob das ausreicht.
Das Update ist ab sofort im git und ab morgen im svn.
Super, vielen Dank.
Ich werde testen und berichten.
Grüße Mave
Das habe ich nach einem Neustart im Log gefunden:
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/24_TPLinkHS110.pm line 167.
Nicht tragisch. Kannst Du ignorieren.
Hi,
ich hab nach dem letzten Update das Problem, das bei der HS110 das Reading power permanent 0 anzeigt, auch wenn definitiv Strom verbraucht wird.
Das kann ich leider nicht nachvollziehen.
Bei mir geht es bei allen Steckdosen.
Hi,
weiss jemand ob die Steckdosen oder die App irgendwelche Daten nach aussen zu TP-Link senden?
Gruß
Chris
Hallo,
leider kann auch ich betätigen, dass die Readings power, current, voltage und total nicht mehr im FHEM ankommen. Es werden wohl nur die info-readings angezeigt. Per Kommandlinescript sind die realtime Angaben aber da. Woran kann das liegen. Bis zum 18.05. war noch alles da.
Gruß Ronny
Ja genau so ist es auch bei mir. Ich habe wieder die Vorversion installiert und seitdem geht wieder alles.
Ich habe die GitHub und SVN Version wieder auf den Stand vor der Änderung zurück gebracht.
Ich kann den Fehler leider nicht nach vollziehen.
@Mave: vlt. solltest Du Dein Netz optimieren!?
@All: wenn jemand den Retry implementieren kann, dann nur zu. Ich akzeptiere auf github gerne pull-requests für das Modul.
Danke. Tut jetzt wieder wunderbar. ;D
Gruß Ronny
Moin,
habe am Primeday zugeschlagen und mir, aufgrund der FHEM Unterstützung, auch eine geschossen.
Soweit läuft alles ziemlich gut, habe nur im Log folgende Log Einträge:
2017.07.14 09:25:30 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:25:32 3: TPLinkHS110: Drucker Set <on> called
2017.07.14 09:25:32 3: TPLinkHS110: Drucker Get called. Relay state: 1, RSSI: -72
2017.07.14 09:25:32 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:25:32 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:25:32 3: TPLinkHS110: Drucker Get end
2017.07.14 09:27:43 3: TPLinkHS110: Drucker Set <off> called
2017.07.14 09:27:43 3: TPLinkHS110: Drucker Get called. Relay state: 0, RSSI: -72
2017.07.14 09:27:43 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:27:43 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:27:43 3: TPLinkHS110: Drucker Get end
2017.07.14 09:27:48 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:27:48 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:28:06 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:28:06 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:28:06 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:28:06 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:32:43 3: TPLinkHS110: Drucker Get called. Relay state: 0, RSSI: -72
2017.07.14 09:32:43 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:32:43 3: TPLinkHS110: Drucker Get end
2017.07.14 09:32:53 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:32:55 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:32:55 3: TPLinkHS110: Drucker Set <?> called
teilweise passiert das alle paar Minuten, und eigtl. immer wenn ich die Dose schalte.
Sie schaltet dann auch sauber.
Hatte noch ein interessantes Phänomen:
seit die Steckdose im Fhem integriert war, reagierte dieser extrem träge wenn ich von lokal (VPN - dann auf lokale IP) gekommen bin, wenn ich von außen (externe IP über ReverseProxy) kam, lief alles wie gewohnt.
Habe daraufhin im Device Timeout auf 3 gesetzt, jetzt scheint es lokal besser zu sein.
Zur Konstellation:
FHEM auf rpi3 jessie (älterer updatestand)
HS100 in Fritzbox geblockt für Internetzugriff
FW HS100 1.1.3
disable 0
timeout 3
FHEM ist aktuell
Zitat von: link611 am 14 Juli 2017, 09:34:04
Moin,
habe am Primeday zugeschlagen und mir, aufgrund der FHEM Unterstützung, auch eine geschossen.
Soweit läuft alles ziemlich gut, habe nur im Log folgende Log Einträge:
2017.07.14 09:25:30 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:25:32 3: TPLinkHS110: Drucker Set <on> called
2017.07.14 09:25:32 3: TPLinkHS110: Drucker Get called. Relay state: 1, RSSI: -72
2017.07.14 09:25:32 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:25:32 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:25:32 3: TPLinkHS110: Drucker Get end
2017.07.14 09:27:43 3: TPLinkHS110: Drucker Set <off> called
2017.07.14 09:27:43 3: TPLinkHS110: Drucker Get called. Relay state: 0, RSSI: -72
2017.07.14 09:27:43 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:27:43 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:27:43 3: TPLinkHS110: Drucker Get end
2017.07.14 09:27:48 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:27:48 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:28:06 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:28:06 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:28:06 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:28:06 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:32:43 3: TPLinkHS110: Drucker Get called. Relay state: 0, RSSI: -72
2017.07.14 09:32:43 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:32:43 3: TPLinkHS110: Drucker Get end
2017.07.14 09:32:53 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:32:55 3: TPLinkHS110: Drucker Set <?> called
2017.07.14 09:32:55 3: TPLinkHS110: Drucker Set <?> called
teilweise passiert das alle paar Minuten, und eigtl. immer wenn ich die Dose schalte.
Sie schaltet dann auch sauber.
Hatte noch ein interessantes Phänomen:
seit die Steckdose im Fhem integriert war, reagierte dieser extrem träge wenn ich von lokal (VPN - dann auf lokale IP) gekommen bin, wenn ich von außen (externe IP über ReverseProxy) kam, lief alles wie gewohnt.
Habe daraufhin im Device Timeout auf 3 gesetzt, jetzt scheint es lokal besser zu sein.
Zur Konstellation:
FHEM auf rpi3 jessie (älterer updatestand)
HS100 in Fritzbox geblockt für Internetzugriff
FW HS100 1.1.3
disable 0
timeout 3
FHEM ist aktuell
Ah,
hab's jetzt verstanden, das sind die Statusabfragen, die alle 5 Minuten anhand des Intervalls kommen. Habe das Intervall jetzt auf 86400 gesetzt (1x pro Tag)
Gibt es eine Möglichkeit die Abfrage komplett abzuschalten? Da ich die Steckdose ausschließlich über FHEM schalte.
dann noch 2 Feature-Requests:
- Cool wäre ein set toggle (da ich die Dose mit einem Dashbutton schalte), klar geht das mit einer IF auch, aber ein toggle wäre eleganter.
- ein set on-for-timer wäre auch eine sinnvolle Ergänzung.
Dann noch eine Frage:
- wo/wie kann man denn bei einer HS100 den Nachtmodus aktivieren?
Zitat von: Volker Kettenbach am 12 Mai 2017, 07:17:31
Hallo Mave,
dasvProbkem habe ich auch hin und wieder.
Ich habe auch keine Ahnung, woran das liegt.
Ich könnte versuchen, den request bei einem timeout nochmal zu schicken.
Hallo Volker,
ich suche seit Wochen immer wieder nach einer Lösung für die sporadischen Probleme, dass die Steckdosen nicht erreichbar sind.
Mittlerweile habe ich sogar die Qualität meines WLAN über FritzRepeater stark verbessert. Dennoch funktionieren die beiden Steckdosen im Garten meistens nicht auf's erste Mal.
Meistens muss ich 4 bis 5 Mal klicken, damit die Steckdosen ein- bzw. ausschalten. Das hat leider zur Folge, dass bei einer zeitgesteuerten Schaltung die Gartenbeleuchtung abends dunkel bleibt.
Auch ein Timeout von 5 Sekunden bringt keine Besserung.
Hast Du noch eine Idee?
Vielen Dank.
Grüße Kai
Du könntest:
1. die Steckdosen mal pingen (über einen gewissen Zeitraum) und schauen, ob diese konstant erreichbar sind. Z.B. mittels smokeping o.ä. auf dem raspberry pi
2. die App von TPLink dazu nutzen zu testen, ob diese zuverlässiger schaltet
3. den Loglevel in FHEM erhöhen, um zu sehen, welche Meldungen im Fehlerfalle in der Logdatei stehen
Gruß
Volker
P.S.: für die zuverlässige Steuerung einer Gartenbeleuchtung halte ich solche Spielzeuggeräte wie diese Steckdosen nicht geeignet. WLAN ist viel zu anfällig. Ich würde Dir zu einem KNX Bus raten. Den verwende ich für so etwas und das ist 100% stabil auch mit FHEM.
Volker,
gerade für so "unwichtige" Dinge wie die Gartenbeleuchtung halte ich die kostengünstigen TPLink Steckdosen für optimal.
Die Schaltung der Steckdosen per App läuft seit einem halben Jahr völlig problemlos.
Die "manuelle" Schaltung über FHEMWEB funktioniert mittlerweile (ich habe meine WLAN Repeater erneuert) ganz gut.
Nur bei einer zeitgesteuerten Schaltung über "at" kommt fast immer diese Fehlermeldung (TimeOut auf 5s):
2017.07.25 21:20:52 3: at_Gartenbeleuchtung_an: Couldn't connect to 192.168.1.91:9999: IO::Socket::INET: connect: timeout
Couldn't connect to 192.168.1.92:9999: IO::Socket::INET: connect: timeout
2017.07.25 21:20:52 1: Perfmon: possible freeze starting at 21:20:42, delay is 10.211
Grüße Mave
Dass da eine Timeout Auftritt ist klar.
Interessant wäre zu wissen, was Ping sagt.
Volker,
ich habe jetzt mal 2 Tage lang einen Dauerping auf meine TPLink Dosen laufen lassen.
Kein einziger Ping ging verloren, Antwortrate 100%
Die Antwortzeiten schwanken allerdings erheblich - zwischen 4 ms und 100 ms.
Seltsam ist nur Folgendes:
Ein manuelles schalten über die Kasa App oder auch über FHEM funktioniert so gut wie immer.
Aber sobald ich die Dosen zeitgesteuert über einen at Befehl schalten lasse, funktioniert es meistens nicht.
Könntest Du die Schaltung der Dosen in Deinem Modul eventuell etwas "robuster" gestalten?
Eventuell mehrmals einen on oder off Befehl senden? Eventuell länger auf eine Rückmeldung warten?
Gefühlt betrifft es nur die Dosen, die über einen WLAN Repeater angebunden sind und da vermutlich die Antwortzeiten etwas länger sind.
Vielen Dank.
Grüße Mave
Ich überlege mir, die HS110 zuzulegen weil die recht günstig ist. Kurz Off-Topic Frage: Wenn die Steckdose den Strom verliert, kehrt sie in den letzten Zustand zurück vor Stromverlust? D.h. An wenn sie vorher An war, Aus wenn sie vorher Aus war?
Zitat von: prodigy7 am 04 August 2017, 14:11:09
Wenn die Steckdose den Strom verliert, kehrt sie in den letzten Zustand zurück vor Stromverlust? D.h. An wenn sie vorher An war, Aus wenn sie vorher Aus war?
nein, die ist dann leider aus.
Hallo, ich habe seit kurzen 3 von den HS100 Steckern. Vorerst hatte ich eine und die hat immer gut geschaltet. Jetzt habe ich noch 2 dazu und hatte Probleme, dass nicht immer alle ein bzw. ausgeschaltet werden.
Mir ist auf gefallen, dass es wohl an der Abarbeitung liegt, wie Fhem die Befehle sendet.
So gibt es keine Probleme:
fhem ("set TPLINK_SD_LampeFlurStehlampe off; set TPLINK_SD_LampeSofaFensterbank off; set TPLINK_SD_LampeWZBuntSchrank off");
..und so macht es nur Probleme:
fhem ("set TPLINK_SD_LampeFlurStehlampe off");
fhem ("set TPLINK_SD_LampeSofaFensterbank off");
fhem ("set TPLINK_SD_LampeWZBuntSchrank off");
Hi,
die Dosen gibt es ab 18 Uhr bei Amazon im Angebot und Dank Google bin ich auf das Modul gestoßen ;-)
Grüße
Achim
Zitat von: CBSnake am 20 September 2017, 11:00:44
Hi,
die Dosen gibt es ab 18 Uhr bei Amazon im Angebot und Dank Google bin ich auf das Modul gestoßen ;-)
Grüße
Achim
Hi Achim,
das klingt interessant!
Woher hast du die Info und weißt du schon den Angebotspreis?
Update:
Ok, hab's gefunden!
Gruß Christian
Sehr gut, hast es ja schon gefunden :-)
Ich schau mir mehrmals täglich an, was es diese Woche im Angebot gibt (Smarthome Woche) und schau was FHEM kompatible ist.
Hi,
angekommen, die mega APP (80MB :o) installiert, ins Wlan gepackt und gleich aus dem Internet ausgesperrt. Perl Module haben natürlich gefehlt ;-) musste mich dann erstmal mit CPAN angooglen. Klappt aber nun und tut was sie soll :-)
Danke fürs Modul ;)
Grüße
Achim
Ich habe schlechte Erfahrungen mit den TP-Link Dosen an FHEM gemacht.
Ca. 50% aller Schaltvorgänge funktionieren nicht.
Die Steuerung der Dosen über die Kasa App ist sehr träge. Von unterwegs Bedarf es manchmal mehrerer Neustarts der App, damit die Dosen überhaupt Remote gesteuert werden können. Optik und Funktionalität der Kasa App ist Geschmacksache - mein Geschmack ist es nicht. Sie wird zwar immer mal wieder per Update modifiziert, an der Stabilität wird aber nichts mehr verbessert.
Mein WLAN ist inzwischen optimiert und läuft einwandfrei.
In FHEM habe ich schon alles Mögliche ausprobiert und habe mittlerweile sogar 2 Schaltvorgänge mit sleep 2 getrennt hintereinander angeordnet und trotzdem schalten die Dosen immer mal wieder nicht in den gewünschten Zustand.
Ich schalte damit nur noch ein paar Lampen im Garten, weil es da nicht so tragisch ist, wenn die Lampen mal abends nicht angehen oder die ganze Nacht an bleiben, weil der Ausschaltvorgang mal wieder nicht funktioniert hat.
Ich denke, für 10 Euro mehr, sind die HomeMatic Steckdosen die deutlich bessere Wahl.
Grüße Mave
Moin,
dann bin ich mal gespannt :-) Die App werde ich eh nicht nutzen, das soll FHEM erledigen. Bisher hab ich nur ZWAVE im Einsatz die sind halt leider nicht günstig. Die TP-Link hätte ich ohne Angebot auch nicht gekauft ;D
Grüße
Achim
Zitat von: stera am 16 September 2017, 12:43:47
Hallo, ich habe seit kurzen 3 von den HS100 Steckern. Vorerst hatte ich eine und die hat immer gut geschaltet. Jetzt habe ich noch 2 dazu und hatte Probleme, dass nicht immer alle ein bzw. ausgeschaltet werden.
Mir ist auf gefallen, dass es wohl an der Abarbeitung liegt, wie Fhem die Befehle sendet.
So gibt es keine Probleme:
fhem ("set TPLINK_SD_LampeFlurStehlampe off; set TPLINK_SD_LampeSofaFensterbank off; set TPLINK_SD_LampeWZBuntSchrank off");
..und so macht es nur Probleme:
fhem ("set TPLINK_SD_LampeFlurStehlampe off");
fhem ("set TPLINK_SD_LampeSofaFensterbank off");
fhem ("set TPLINK_SD_LampeWZBuntSchrank off");
Moin,
ich muss meine Aussage etwas zurücknehmen. Ich hatte auch mit der zweiten Variante noch echt Probleme mit den Schaltvorgängen. Mir ist aber auch noch was aufgefallen.
Ich habe eine FritzBox7490. In der Netzwerkübersicht, werden auch alle 3 Dosen angezeigt, verhalten sich aber anders ->
TP-HS100-LampeFlurStehlampe
WLAN, 2,4 GHz Details
TP-HS100-LampeWZBuntSchrank
WLAN, 2,4 GHz Details
TP-HS100-LampeWZFensterbank
WLAN, 2,4 GHz, 72 Mbit/s Details
Bei der letzten "TP-HS100-LampeWZFensterbank" wird immer die Signalstärke angezeigt, bei den anderen neueren Dosen nicht. Warum, keine Ahnung. Die anderen beiden Dosen verschwinden auch ab und zu, ob diese sich in Standby legen. Genau dann machen sie beim ersten Schaltvorgang diese An/Aus Schaltprobleme.
Habe dann in dem Moment auch nochmal ein Pingtest gemacht und die ersten Ansprechzeiten lagen bei über 100ms, der zweite,dritte Wert bei 4ms.
Jetzt habe ich auf alle 3 Dosen ein Presencemodul mit Pingabfrage laufen. Seitdem funktionieren die Dosen Störungsfrei..
Es gibt ja noch eine Attr. INTERVAL, die hatte ich bisher noch nicht angepasst.
Internals:
ADDRESS 192.168.10.119
CHANGED
DEF lan-ping 192.168.10.119 60
MODE lan-ping
NAME TPLinkHS110_FlurStehlampe
NOTIFYDEV global
NR 58
NTFY_ORDER 50-TPLinkHS110_FlurStehlampe
STATE present
TIMEOUT_NORMAL 60
TIMEOUT_PRESENT 60
TYPE PRESENCE
Helper:
DBLOG:
state:
myDbLog:
TIME 1506130021.76567
VALUE present
READINGS:
2017-09-22 13:45:58 model lan-ping
2017-09-23 05:52:17 presence present
2017-09-23 05:52:17 state present
helper:
CURRENT_STATE present
Attributes:
devStateIcon present:WLAN_Status.1 absent:WLAN_Status.0
event-on-change-reading .*
room Netzwerk Evtl. hat Volker eine Lösung irgendwann mal für uns parat. Denke dieses pingen, wird den Standbyverbrauch der Dosen auch erhöhen.
Gruß,
SteRa
stera,
wenn eine Übertragungsrate MBit/s angezeigt wird, heißt das nach meinem Verständnis, dass Deine Dose mit dem WLAN Deiner FritzBox verbunden ist. Die anderen beiden Dosen ohne Übertragungsrate müssten demnach mit einem Repeater verbunden sein.
Der Dauerping ist ein guter Hinweis, vielen Dank. Ich habe nämlich auch schon die Beobachtung gemacht, dass wenn ein Schaltvorgang mal funktioniert hat, dass dann alle darauffolgenden auch funktionieren. Man könnte wirklich meinen, die Dose geht mit der Zeit in einen Sleepmodus und das Aufwecken durch FHEM scheint mal mehr und mal weniger gut zu funktionieren.
Wie gesagt, braucht bei mir die Kasa App auch manchmal ewig lange, bis sie einzelne Dosen erreichen kann. Könnte also ein generelles Aufweckproblem aus dem Sleepmodus sein.
Grüße Mave
PS: Ich hatte Volker auch schon mal gebeten, das TP-Link Modul dahingehend robuster zu machen, dass es hartnäckiger und länger an einem Ein- bzw. Ausschaltvorgang arbeitet. Aber vielleicht ist das nicht so einfach zu realisieren, keine Ahnung.
Zitat von: Mave am 23 September 2017, 07:33:01
stera,
wenn eine Übertragungsrate MBit/s angezeigt wird, heißt das nach meinem Verständnis, dass Deine Dose mit dem WLAN Deiner FritzBox verbunden ist. Die anderen beiden Dosen ohne Übertragungsrate müssten demnach mit einem Repeater verbunden sein.
Der Dauerping ist ein guter Hinweis, vielen Dank. Ich habe nämlich auch schon die Beobachtung gemacht, dass wenn ein Schaltvorgang mal funktioniert hat, dass dann alle darauffolgenden auch funktionieren. Man könnte wirklich meinen, die Dose geht mit der Zeit in einen Sleepmodus und das Aufwecken durch FHEM scheint mal mehr und mal weniger gut zu funktionieren.
Wie gesagt, braucht bei mir die Kasa App auch manchmal ewig lange, bis sie einzelne Dosen erreichen kann. Könnte also ein generelles Aufweckproblem aus dem Sleepmodus sein.
Grüße Mave
PS: Ich hatte Volker auch schon mal gebeten, das TP-Link Modul dahingehend robuster zu machen, dass es hartnäckiger und länger an einem Ein- bzw. Ausschaltvorgang arbeitet. Aber vielleicht ist das nicht so einfach zu realisieren, keine Ahnung.
Hallo Mave,
die sind nicht über einen Repeater verbunden sondern alle direkt.. Mich wundert das auch..
Gruß,
SteRa
Hier auch nochmal die Logauswertung der Steckdosen mit dem PresenceModul. Das schalten funktioniert immer noch tadellos, aber der ping reist komischerweise bei den beiden neueren auch mal ab.
Die Entfernung zu den Dosen, ist ziemlich gleich!
2017-09-22_13:44:45 present
2017-09-22_22:23:28 absent
2017-09-22_22:24:31 present
2017-09-22_22:54:10 absent
2017-09-22_22:55:13 present
2017-09-23_01:48:58 absent
2017-09-23_01:50:01 present
2017-09-23_02:25:58 absent
2017-09-23_02:27:01 present
2017-09-23_04:41:55 absent
2017-09-23_04:42:58 present
#TPLinkHS110_WZBunt:state:::
2017-09-22_13:44:45 present
2017-09-23_00:58:28 absent
2017-09-23_00:59:31 present
2017-09-23_03:25:58 absent
2017-09-23_03:27:01 present
#TPLinkHS110_FlurStehlampe:state:::
Bei der garnix! War die allererste Dose, die ich bestellt habe.
2017-09-22_13:46:15 present
#TPLinkHS110_WZFensterbank:state:::
Ich kann die ganzen Erreichbarkeitsprobleme nicht nach vollziehen und daher auch schlecht helfen.
Wie ich aber auch schon vormals erwähnt hatte: wenn ich vernünftige Informationen bekomme, kann ich ggf. helfen.
Zitat von: Mave am 23 September 2017, 07:33:01
Der Dauerping ist ein guter Hinweis, vielen Dank. Ich habe nämlich auch schon die Beobachtung gemacht, dass wenn ein Schaltvorgang mal funktioniert hat, dass dann alle darauffolgenden auch funktionieren. Man könnte wirklich meinen, die Dose geht mit der Zeit in einen Sleepmodus und das Aufwecken durch FHEM scheint mal mehr und mal weniger gut zu funktionieren.
Wie gesagt, braucht bei mir die Kasa App auch manchmal ewig lange, bis sie einzelne Dosen erreichen kann. Könnte also ein generelles Aufweckproblem aus dem Sleepmodus sein.
Das ist ein guter Hinweis.
Ich setze die HS110 ein und frage diese 1x pro Minute ab (Leistung usw.).
Evtl. kommt das einen Dauerping gleich.
Nicht-Erreichbarkeit ist bei mir kein Thema.
Zitat von: Mave am 23 September 2017, 07:33:01
PS: Ich hatte Volker auch schon mal gebeten, das TP-Link Modul dahingehend robuster zu machen, dass es hartnäckiger und länger an einem Ein- bzw. Ausschaltvorgang arbeitet. Aber vielleicht ist das nicht so einfach zu realisieren, keine Ahnung.
Auch hier kann ich nur darauf verweisen, dass ich das nicht nach vollziehen kann.
Neben dem oben erwähnten Thema Dauerping ist noch zu sagen:
WLAN ist keine Technik, die für eine verlässliche Realtime-Anwendung tauglich ist.
Fritzboxen sind teilweise stark fehlerbehaftete Consumer-Produkte.
Wer sein Haus stabil vernetzen will, sollte erstens KNX verwenden und zweitens kabelgebundenes Ethernet mit Switches, die Stabiltät hergeben z.B. von Cisco.
Wenn Drahtlostechnik gefordert ist, gibt es besseres als WLAN.
Und WLAN eingesetzt wird, dann gibt es auch hier Access-Points (Cisco, Unify), die deutlich bessere Ergebnisse erzielen als Consumer-Produkte.
Ich setze die o.g. Techniken von Cisco und 1-2 anderen soliden Herstellern in 3 Häusern ein und steuere darüber fast 100 Geräte.
Alles läuft 100% verlässlich, auch die HS110.
In meinem fhem Log taucht TPLinkHS110: Keller.Waschkueche.Device.Waschmaschine2 Set <?> calledauf wenn ich die Seite eines entsprechenden Gerätes im FHEM Web Interface aufrufe. Ist das Kunst oder kann das weg?
Edit: Und noch eine Frage -> Bei mir wird derzeit kein Logfile geschrieben. Bei meiner Revolt bekomme ich ein Logfile im Format 2017-09-24_14:12:03 Keller.Waschkueche.Device.Trockner P: 0.0 E: 20.73 V: 229 C: 0.00 F: 50 Pf: 0.00
2017-09-24_14:12:03 Keller.Waschkueche.Device.Trockner voltage: 229
2017-09-24_14:12:03 Keller.Waschkueche.Device.Trockner current: 0
2017-09-24_14:12:03 Keller.Waschkueche.Device.Trockner frequency: 50
2017-09-24_14:12:03 Keller.Waschkueche.Device.Trockner power: 0
2017-09-24_14:12:03 Keller.Waschkueche.Device.Trockner pf: 0
2017-09-24_14:12:03 Keller.Waschkueche.Device.Trockner energy: 20.73. Ginge das auch noch für die TP-Link, dass man daraus eine grafische Auswertung machen kann mit einem Plot?
Hi,
zum Thema Log:
Klar musst du dir halt selber anlegen
define FileLog_Keller.Waschkueche.Device.Waschmaschine2 FileLog ./log/Keller.Waschkueche.Device.Waschmaschine2-%Y-%m.log
Könnte aber mit deinen .... im Namen kolidieren ;-) probieres aus
auch das
./log/
solltest du vorher mit dem Logfile des Trockners abgleichen ;-)
Grüße
Achim
Halllo zusammen, ich nutze ein TPLinkHS100 schon seit einiger Zeit, um eine Lampe programmatisch zu schalten.
Das geht bei mir auch soweit gut.
Nun will ich damit aber einen PC vom Strom trennen können.
Jetzt dachte ich mir, wenn ich den TPLink einschalte, kann ich auch mittels WOL den PC automatisch starten. Hat erstmal nicht geklappt, da WOL etwas schwerfällig einzurichten war (BIOS, Windows-Netz-Treiber, Programm, das das kann, ...).
Nachdem ich diese Hürde genommen habe, habe ich mich gewundert, warum das notify auf meinem Device TPLinkHS100 nicht funktioniert.
Dann musste ich feststellen, dass FHEM anscheinend nicht in Echt-Zeit mit bekommt, dass ich den Schalter betätigt habe, sondern erst dann, wenn das nächste Intervall für die Kommunikation wieder rum ist.
Default sind hier 300 Sekunden.
Jetzt meine Frage: Kann ich das Intervall auf 1 Sekunde (oder 2) drücken? Macht das Probleme bei der Auslastung von FHEM? Bläst mir das das Log voll?
Oder gibt es da andere Möglichkeiten?
Eventuell ist auch dieser Schalter für meinen Zweck nicht das richtige. Kennt jemand Alternativen?
Danke
Hast du einen normalen PC oder Laptop? Beim normalen PC kannst du doch im bios das so einstellen, das er automatisch angeht, sobald die tp Link Strom schaltet.
Ich habe ein Laptop, schalte alle Zusatzgeräte mit einer tp Link weg. Der Laptop hat immer Strom und fährt in Energie sparen. Mit WOL wecke ich manchmal per fern auf.
Gruß SteRa
Gesendet von meinem SM-G930F mit Tapatalk
Ich nutze einen normalen PC.
Nach einigem Rumprobieren scheine ich die richtige Option im BIOS gefunden zu haben, ich weiß aber nicht mehr welche :).
Damit war die ganze Sucherei nach WOL für die Füße >:(. Aber man lernt dadurch ja auch was.
Danke an SteRa für den Tipp.
Zitat von: jhohmann am 06 Oktober 2017, 15:47:23
Ich nutze einen normalen PC.
Nach einigem Rumprobieren scheine ich die richtige Option im BIOS gefunden zu haben, ich weiß aber nicht mehr welche :).
Damit war die ganze Sucherei nach WOL für die Füße >:(. Aber man lernt dadurch ja auch was.
Danke an SteRa für den Tipp.
"Restore on AC/Power Loss" heißt das meistens ;-)
Gesendet von meinem SM-G930F mit Tapatalk
Hi,
kaum bin ich ne Woche weg spinnt die Dose ;-( Meine Frau meldet Fehler bei den Lampen, verantwortlich ist evtl die TP Link, diese füllt den Log mit
json-decoding failed. Problem decoding getting statistical data
Oder doch ein Netzwerkproblem welches auch die TP Link Spinnen lässt?
Mehr Infos könnte ich nachher liefern wenn ich mit nem PC aufs system komme.
Grüße
Achim
funktioniert das Modul auch mit dem Großen Bruder der beiden?
Den TP-Link RE270K AC750
https://www.amazon.de/gp/product/B01N4WMSL1/ref=ask_ql_qh_dp_hza
Hallo Volker,
ist es möglich Deinen Code um auch LED Lampen zu erweitern?
Hier ist ein ähnliches Modul für Homebridge: https://github.com/plasticrake/homebridge-tplink-smarthome
würde mich freuen
Gruß Gordon
Hi,
I have bought one of these plugs in the UK and its model name is HS110(UK) which means the meter readings are ignored.
I have tried to put a patch on your Github page to fix this but failed, I am not authorised.
I tried to replace line 128 that reads:
if ($json->{'system'}->{'get_sysinfo'}->{'model'} eq "HS110(EU)") {
to:
if ($json->{'system'}->{'get_sysinfo'}->{'model'} =~ /HS110[(][A-Z]{2}[)]/) {
So it should work on any two character region version of this plug.
Regards,
Lawrence
Hi Lawrence,
thanks for submitting this code.
I added it to github a few seconds ago.
The fhem repository will be updated next day (afaik).
Concerning patches: you could have either sent me a patch-file (diff) or create a PullRequest on GitHub which can be done here:
https://github.com/kettenbach-it/FHEM-TPLink-HS110/pulls
by cloning the repository, modifying your branch and submitting the changes as a PpullRequest.
Best regards
Volker
Nach einspielen des heutigen Updates, kann das Modul bei mir nicht mehr geladen werden (HS100) ...
2017.12.01 10:28:33 1: PERL WARNING: Subroutine TPLinkHS110_Initialize redefined at ./FHEM/24_TPLinkHS110.pm line 40.
2017.12.01 10:28:33 1: PERL WARNING: Subroutine TPLinkHS110_Define redefined at ./FHEM/24_TPLinkHS110.pm line 58.
2017.12.01 10:28:33 1: PERL WARNING: "my" variable $socket masks earlier declaration in same scope at ./FHEM/24_TPLinkHS110.pm line 131.
2017.12.01 10:28:33 1: PERL WARNING: "my" variable $command masks earlier declaration in same scope at ./FHEM/24_TPLinkHS110.pm line 159.
2017.12.01 10:28:33 1: PERL WARNING: "my" variable $c masks earlier declaration in same scope at ./FHEM/24_TPLinkHS110.pm line 160.
2017.12.01 10:28:33 1: PERL WARNING: "my" variable $data masks earlier declaration in same scope at ./FHEM/24_TPLinkHS110.pm line 168.
2017.12.01 10:28:33 1: PERL WARNING: "my" variable $hash masks earlier declaration in same scope at ./FHEM/24_TPLinkHS110.pm line 251.
2017.12.01 10:28:33 1: reload: Error:Modul 24_TPLinkHS110 deactivated:
syntax error at ./FHEM/24_TPLinkHS110.pm line 128, near ")) "
Global symbol "$realtimejcommand" requires explicit package name at ./FHEM/24_TPLinkHS110.pm line 130.
Global symbol "$hash" requires explicit package name at ./FHEM/24_TPLinkHS110.pm line 194.
Global symbol "$hash" requires explicit package name at ./FHEM/24_TPLinkHS110.pm line 195.
Global symbol "$name" requires explicit package name at ./FHEM/24_TPLinkHS110.pm line 195.
syntax error at ./FHEM/24_TPLinkHS110.pm line 196, near "}"
Can't use global @_ in "my" at ./FHEM/24_TPLinkHS110.pm line 202, near "= @_"
Global symbol "$hash" requires explicit package name at ./FHEM/24_TPLinkHS110.pm line 203.
syntax error at ./FHEM/24_TPLinkHS110.pm line 245, near "}"
Can't use global @_ in "my" at ./FHEM/24_TPLinkHS110.pm line 251, near "= @_"
./FHEM/24_TPLinkHS110.pm has too many errors.
2017.12.01 10:28:33 0: syntax error at ./FHEM/24_TPLinkHS110.pm line 128, near ")) "
Global symbol "$realtimejcommand" requires explicit package name at ./FHEM/24_TPLinkHS110.pm line 130.
Global symbol "$hash" requires explicit package name at ./FHEM/24_TPLinkHS110.pm line 194.
Global symbol "$hash" requires explicit package name at ./FHEM/24_TPLinkHS110.pm line 195.
Global symbol "$name" requires explicit package name at ./FHEM/24_TPLinkHS110.pm line 195.
syntax error at ./FHEM/24_TPLinkHS110.pm line 196, near "}"
Can't use global @_ in "my" at ./FHEM/24_TPLinkHS110.pm line 202, near "= @_"
Global symbol "$hash" requires explicit package name at ./FHEM/24_TPLinkHS110.pm line 203.
syntax error at ./FHEM/24_TPLinkHS110.pm line 245, near "}"
Can't use global @_ in "my" at ./FHEM/24_TPLinkHS110.pm line 251, near "= @_"
./FHEM/24_TPLinkHS110.pm has too many errors.
Dem schließe ich mich an ! :-\
ZitatMessages collected while initializing FHEM:
configfile: Cannot load module TPLinkHS110
Autosave deactivated
muss ich ebenfalls bestätigen :(
Ich hatte vorhin nach dem Update von FHEM das gleiche Problem, FHEM wieder hergestellt aus dem Backup und dann lief es wieder.
Ich mache erstmal kein Update
Modul lässt sich nicht mehr laden... :(
Fehler ist gefunden und behoben
Super, vielen Dank.
Cannot load module TPLinkHS110 :(
Wollte die Tage testweise eine HS110 in fhem einbinden und habe das gleiche Problem:
Messages collected while initializing FHEM:
configfile: Cannot load module TPLinkHS110
Kann es sein, dass ich noch die benötigten Module nachinstallieren muss?
- Perl Module: IO::Socket::Timeout
- Perl Module: IO::Socket::INET
Edit:
Ja so einfach ist es, wer lesen kann ist...
sudo apt-get install libio-socket-timeout-perl
und schon läufts!
Zitat von: CBSnake am 27 November 2017, 16:13:55
Hi,
kaum bin ich ne Woche weg spinnt die Dose ;-( Meine Frau meldet Fehler bei den Lampen, verantwortlich ist evtl die TP Link, diese füllt den Log mit
json-decoding failed. Problem decoding getting statistical data
Oder doch ein Netzwerkproblem welches auch die TP Link Spinnen lässt?
Mehr Infos könnte ich nachher liefern wenn ich mit nem PC aufs system komme.
Grüße
Achim
Hallo Achim,
hast Du bzgl. dieser Meldung etwas in Erfahrung bringen können? Ich bekomme die auch immer wieder - jedoch habe ich die Vermutung, es tritt NICHT sporadisch auf, sondern immer nach einer gewissen Zeit (vermute so 26 bis 27 Tage). Dann kommt die Meldung ein paar Tage lang und danach fängt sich das wieder.
Für mich hat es den Anschein, als ob hier eine Variable "überläuft" (was ich mir bei Perl zwar nicht nicht vorstellen kann - aber Meldung deutet ja auf json hin und das kenne ich quasi gar nicht).
Wäre super falls Du was hier eine Lösung gefunden hast, bzw. woran es bei Dir lag - würde mich sehr freuen, wenn Du das hier posten könntest.
Danke & viele Grüße
Steff
Guten Morgen,
Nicht wirklich, ich hab im Anschluss mein Netzwerk neu aufgebaut, der DHCP Server war bisher die Fritzbox der Nachbarin, war die nicht erreichbar lief das halbe smarthome Amok ;-) jetzt übernimmt den DHCP Job eine Fritzbox direkt in meinem Netzwerk.
Grüße
Achim
Hab ich jetzt auch im Log stehen:
json-decoding failed. Problem decoding getting statistical data
Außerdem heute zum ersten Mal folgendes Phänomen:
TPLink Dose wurde zeitgesteuert um 23 Uhr ausgeschaltet. Eingesteckt Lampe ging auch brav aus.
In FHEM erscheint die Dose aber noch als on.
Dabei fällt auf: das Reading state ist off, das Internal STATE ist on.
Für die Ansteuerung meiner WLAN-Steckdosen per UI habe ich eine "toggle"-Funktion vermisst. Deshalb habe ich die mal selbst in das Modul "reingebastelt".
Sind letztlich nur ein paar Zeilen Code. Vielleicht mag der Modulautor sich die mal ansehen und ggf. in die offizielle Version übernehmen?
Einschränkung: Es wird "nur" in FHEM selbst ermittelt, wie der aktuelle Status vorm Toggle ist. Wenn die Steckdose kurz zuvor manuell geschaltet wurde und FHEM das noch nicht mitbekommen hat, würde genau falsch geschaltet, also gar nichts passieren. Wollte man es perfekt machen, müsste man erst den Status bei der Steckdose abfragen und dann schalten. Aber das war mir zu aufwändig, da für meinen Anwendungsfall überflüssig (ich schalte die praktisch nie manuell).
Ich habe leider auf die Schnelle keine Software für ein Diff oder einen PullRequest. Deshalb poste ich hier meine geänderte Version der Funktion TPLinkHS110_Set bezogen auf 24_TPLinkHS110.pm 15532 2017-12-01 07:31:38Z vk
#####################################
sub TPLinkHS110_Set($$)
{
my ( $hash, @a ) = @_;
my $name= $hash->{NAME};
return "Device disabled in config" if ($attr{$name}{"disable"} eq "1");
Log3 $hash, 3, "TPLinkHS110: $name Set <". $a[1] ."> called";
return "Unknown argument $a[1], choose one of on off toggle " if($a[1] ne "on" & $a[1] ne "off" & $a[1] ne "toggle");
my $command;
if($a[1] eq "on") {
$command = '{"system":{"set_relay_state":{"state":1}}}';
}
if($a[1] eq "off") {
$command = '{"system":{"set_relay_state":{"state":0}}}';
}
if($a[1] eq "toggle") {
if (ReadingsVal($name,"state", "???") eq "off") {
$command = '{"system":{"set_relay_state":{"state":1}}}';
}
if (ReadingsVal($name,"state", "???") eq "on") {
$command = '{"system":{"set_relay_state":{"state":0}}}';
}
}
my $remote_host = $hash->{HOST};
my $remote_port = 9999;
my $c = encrypt($command);
my $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 $data;
my $retval = $socket->recv($data,8192);
$socket->close();
unless( defined $retval) { return undef; }
$data = decrypt(substr($data,4));
my $json;
eval {
$json = decode_json($data);
} or do {
Log3 $hash, 2, "TPLinkHS110: $name json-decoding failed. Problem decoding getting statistical data";
return;
};
if ($json->{'system'}->{'set_relay_state'}->{'err_code'} eq "0") {
TPLinkHS110_Get($hash,"");
} else {
return "Command failed!";
}
return undef;
}
Servus Brockmann,
ich baue das ein und stelle ein neues Modul in Github bzw. FHEM bereit.
Bitte etwas Geduld.
Gruß
Volker
Verstehe nicht wieso man das Rad zweimal erfinden muß.
https://wiki.fhem.de/wiki/DevelopmentModuleAPI#SetExtensions
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/SetExtensions.pm
Grüße
Zitat von: CoolTux am 09 Januar 2018, 10:10:35
Verstehe nicht wieso man das Rad zweimal erfinden muß.
https://wiki.fhem.de/wiki/DevelopmentModuleAPI#SetExtensions
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/SetExtensions.pm
Danke für den Hinweis. Bin nun mal kein Entwickler und mit solchen Mechanismen nicht vertraut. Aber Recht hast Du und neben toggle bekommt man gleich noch einige andere Befehle gratis dazu.
Hier also die Variante mit setExtensions (bezogen auf
24_TPLinkHS110.pm 15532 2017-12-01 07:31:38Z vk:
Diesmal die komplette Datei, wobei außer in der Set-Funktion nur ganz oben eine use-Zeile ergänzt wurde.
Ggf. sollte in der HTML-Doku noch erwähnt werden, dass das Modul die setExtensions-Befehle unterstützt?
################################################################
# $Id: 24_TPLinkHS110.pm 15532 2017-12-01 07:31:38Z vk $
#
# Copyright notice
#
# (c) 2016 Copyright: Volker Kettenbach
# e-mail: volker at kettenbach minus it dot de
#
# Description:
# This is an FHEM-Module for the TP Link TPLinkHS110110/110
# wifi controlled power outlet.
# It support switching on and of the outlet as well as switching
# on and of the nightmode (green led off).
# It supports reading several readings as well as the
# realtime power readings of the HS110.
#
# Requirements
# Perl Module: IO::Socket::INET
# Perl Module: IO::Socket::Timeout
#
# In recent debian based distributions IO::Socket::Timeout can
# be installed by "apt-get install libio-socket-timeout-perl"
# In older distribution try "cpan IO::Socket::Timeout"
#
# Origin:
# https://github.com/kettenbach-it/FHEM-TPLink-HS110
#
################################################################
package main;
use strict;
use warnings;
use IO::Socket::INET;
use IO::Socket::Timeout;
use JSON;
use SetExtensions;
#####################################
sub TPLinkHS110_Initialize($)
{
my ($hash) = @_;
$hash->{DefFn} = "TPLinkHS110_Define";
$hash->{ReadFn} = "TPLinkHS110_Get";
$hash->{SetFn} = "TPLinkHS110_Set";
$hash->{UndefFn} = "TPLinkHS110_Undefine";
$hash->{DeleteFn} = "TPLinkHS110_Delete";
$hash->{AttrFn} = "TPLinkHS110_Attr";
$hash->{AttrList} = "interval ".
"disable:0,1 " .
"nightmode:on,off " .
"timeout " .
"$readingFnAttributes";
}
#####################################
sub TPLinkHS110_Define($$)
{
my ($hash, $def) = @_;
my $name= $hash->{NAME};
my @a = split( "[ \t][ \t]*", $def );
return "Wrong syntax: use define <name> TPLinkHS110 <hostname/ip> " if (int(@a) != 3);
$hash->{INTERVAL}=300;
$hash->{TIMEOUT}=1;
$hash->{HOST}=$a[2];
$attr{$name}{"disable"} = 0;
# initial request after 2 secs, there timer is set to interval for further update
InternalTimer(gettimeofday()+2, "TPLinkHS110_Get", $hash, 0);
Log3 $hash, 3, "TPLinkHS110: $name defined.";
return undef;
}
#####################################
sub TPLinkHS110_Get($$)
{
my ($hash) = @_;
my $name = $hash->{NAME};
return "Device disabled in config" if ($attr{$name}{"disable"} eq "1");
RemoveInternalTimer($hash);
InternalTimer(gettimeofday()+$hash->{INTERVAL}, "TPLinkHS110_Get", $hash, 1);
$hash->{NEXTUPDATE}=localtime(gettimeofday()+$hash->{INTERVAL});
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
$mon++;
$year += 1900;
my $remote_host = $hash->{HOST};
my $remote_port = 9999;
my $command = '{"system":{"get_sysinfo":{}}}';
my $c = encrypt($command);
my $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 $data;
my $retval = $socket->recv($data,8192);
$socket->close();
unless( defined $retval) { return undef; }
$data = decrypt(substr($data,4));
my $json;
eval {
$json = decode_json($data);
} or do {
Log3 $hash, 2, "TPLinkHS110: $name json-decoding failed. Problem decoding getting statistical data";
return;
};
Log3 $hash, 3, "TPLinkHS110: $name Get called. Relay state: $json->{'system'}->{'get_sysinfo'}->{'relay_state'}, RSSI: $json->{'system'}->{'get_sysinfo'}->{'rssi'}";
readingsBeginUpdate($hash);
foreach my $key (sort keys %{$json->{'system'}->{'get_sysinfo'}}) {
readingsBulkUpdate($hash, $key, $json->{'system'}->{'get_sysinfo'}->{$key});
}
if ($json->{'system'}->{'get_sysinfo'}->{'relay_state'} == 0) {
readingsBulkUpdate($hash, "state", "off");
}
if ($json->{'system'}->{'get_sysinfo'}->{'relay_state'} == 1) {
readingsBulkUpdate($hash, "state", "on");
}
# If the device is a HS110, get realtime data:
if ($json->{'system'}->{'get_sysinfo'}->{'model'} eq "HS110(EU)" or $json->{'system'}->{'get_sysinfo'}->{'model'} eq "HS110(UK)") {
my $realtimejcommand='{"emeter":{"get_realtime":{}}}';
my $rc = encrypt($realtimejcommand);
my $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($rc);
my $rdata;
$retval = $socket->recv($rdata,8192);
$socket->close();
unless( defined $retval) { return undef; }
$rdata = decrypt(substr($rdata,4));
my $realtimejson;
if (length($rdata)==0) {
Log3 $hash, 1, "TPLinkHS110: $name: Received zero bytes of realtime data. Cannot process realtime data";
return;
}
eval {
$realtimejson = decode_json($rdata);
} or do {
Log3 $hash, 2, "TPLinkHS110: $name json-decoding failed. Problem decoding getting statistical data";
return;
};
foreach my $key2 (sort keys %{$realtimejson->{'emeter'}->{'get_realtime'}}) {
readingsBulkUpdate($hash, $key2, $realtimejson->{'emeter'}->{'get_realtime'}->{$key2});
}
Log3 $hash, 3, "TPLinkHS110: $name Device is an HS110. Got extra realtime data: $realtimejson->{'emeter'}->{'get_realtime'}->{'power'} Watt, $realtimejson->{'emeter'}->{'get_realtime'}->{'voltage'} Volt, $realtimejson->{'emeter'}->{'get_realtime'}->{'current'} Ampere";
# 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 $data;
$retval = $socket->recv($data,8192);
$socket->close();
unless( defined $retval) { return undef; }
$data = decrypt(substr($data,4));
eval {
my $json = decode_json($data);
my $total=0;
foreach my $key (sort keys @{$json->{'emeter'}->{'get_daystat'}->{'day_list'}}) {
foreach my $key2 ($json->{'emeter'}->{'get_daystat'}->{'day_list'}[$key]) {
$total = $total+ $key2->{'energy'};
if ($key2->{'day'} == $mday) {
readingsBulkUpdate($hash, "daily_total", sprintf("%.3f", $key2->{'energy'}));
}
}
}
my $count=1;
$count = @{$json->{'emeter'}->{'get_daystat'}->{'day_list'}};
readingsBulkUpdate($hash, "monthly_total", $total);
if ($count) { readingsBulkUpdate($hash, "daily_average", $total/$count)};
1;
} or do {
Log3 $hash, 2, "TPLinkHS110: $name json-decoding failed. Problem decoding getting statistical data";
return;
};
}
readingsEndUpdate($hash, 1);
Log3 $hash, 3, "TPLinkHS110: $name Get end";
}
#####################################
sub TPLinkHS110_Set($$)
{
my ( $hash, $name, $cmd, @args ) = @_;
my $cmdList = "on off";
return "\"set $name\" needs at least one argument" unless(defined($cmd));
return "Device disabled in config" if ($attr{$name}{"disable"} eq "1");
Log3 $hash, 3, "TPLinkHS110: $name Set <". $cmd ."> called";
my $command="";
if($cmd eq "on")
{
$command = '{"system":{"set_relay_state":{"state":1}}}';
}
elsif($cmd eq "off")
{
$command = '{"system":{"set_relay_state":{"state":0}}}';
}
else # wenn der übergebene Befehl nicht durch X_Set() verarbeitet werden kann, Weitergabe an SetExtensions
{
return SetExtensions($hash, $cmdList, $name, $cmd, @args);
}
my $remote_host = $hash->{HOST};
my $remote_port = 9999;
my $c = encrypt($command);
my $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 $data;
my $retval = $socket->recv($data,8192);
$socket->close();
unless( defined $retval) { return undef; }
$data = decrypt(substr($data,4));
my $json;
eval {
$json = decode_json($data);
} or do {
Log3 $hash, 2, "TPLinkHS110: $name json-decoding failed. Problem decoding getting statistical data";
return;
};
if ($json->{'system'}->{'set_relay_state'}->{'err_code'} eq "0") {
TPLinkHS110_Get($hash,"");
} else {
return "Command failed!";
}
return undef;
}
#####################################
sub TPLinkHS110_Undefine($$)
{
my ($hash, $arg) = @_;
my $name= $hash->{NAME};
RemoveInternalTimer($hash);
Log3 $hash, 3, "TPLinkHS110: $name undefined.";
return;
}
#####################################
sub TPLinkHS110_Delete {
my ($hash, $arg) = @_;
my $name= $hash->{NAME};
Log3 $hash, 3, "TPLinkHS110: $name deleted.";
return undef;
}
#####################################
sub TPLinkHS110_Attr {
my ($cmd,$name,$aName,$aVal) = @_;
my $hash = $defs{$name};
if ($aName eq "interval") {
if ($cmd eq "set") {
$hash->{INTERVAL} = $aVal;
} else {
$hash->{INTERVAL} = 300;
}
Log3 $hash, 3, "TPLinkHS110: $name INTERVAL set to " . $hash->{INTERVAL};
}
if ($aName eq "timeout") {
if ($cmd eq "set") {
$hash->{TIMEOUT} = $aVal;
} else {
$hash->{TIMEOUT} = 1;
}
Log3 $hash, 3, "TPLinkHS110: $name TIMEOUT set to " . $hash->{TIMEOUT};
}
if ($aName eq "nightmode") {
my $command;
if ($cmd eq "set") {
$hash->{NIGHTMODE} = $aVal;
Log3 $hash, 3, "TPLinkHS110: $name Nightmode $aVal.";
$command = '{"system":{"set_led_off":{"off":1}}}' if ($aVal eq "on");
$command = '{"system":{"set_led_off":{"off":0}}}' if ($aVal eq "off");
}
if ($cmd eq "del") {
Log3 $hash, 3, "TPLinkHS110: $name Nightmode attribute removed. Nightmode disabled.";
$command = '{"system":{"set_led_off":{"off":0}}}';
$hash->{NIGHTMODE} = "off";
}
my $remote_host = $hash->{HOST};
my $remote_port = 9999;
my $c = encrypt($command);
my $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 $data;
my $retval = $socket->recv($data,8192);
$socket->close();
unless( defined $retval) { return undef; }
$data = decrypt(substr($data,4));
my $json;
eval {
$json = decode_json($data);
} or do {
Log3 $hash, 2, "TPLinkHS110: $name json-decoding failed. Problem decoding getting statistical data";
return;
};
}
return undef;
}
# Encryption and Decryption of TP-Link Smart Home Protocol
# XOR Autokey Cipher with starting key = 171
# Based on https://www.softscheck.com/en/reverse-engineering-tp-link-hs110/
sub encrypt {
my $key = 171;
my $result = "\0\0\0\0";
my @string=split(//, $_[0]);
foreach (@string) {
my $a = $key ^ ord($_);
$key = $a;
$result .= chr($a);
}
return $result;
}
sub decrypt {
my $key = 171;
my $result = "";
my @string=split(//, $_[0]);
foreach (@string) {
my $a = $key ^ ord($_);
$key = ord($_);
$result .= chr($a);
}
return $result;
}
######################################################################################
1;
=pod
=begin html
<a name="TPLinkHS110"></a>
<h3>TPLinkHS110</h3>
<ul>
<br>
<a name="TPLinkHS110"></a>
<b>Define</b>
<code>define <name> TPLinkHS110 <ip/hostname></code><br>
<br>
Defines a TP-Link HS100 or HS110 wifi-controlled switchable power outlet.<br>
The difference between HS100 and HS110 is, that the HS110 provides realtime measurments of<br>
power, current and voltage.<br>
This module automatically detects the modul defined and adapts the readings accordingly.<br>
<br><br>
This module does not implement all functions of the HS100/110.<br>
Currently, all parameters relevant for running the outlet under FHEM are processed.<br>
Writeable are only "On", "Off" and the nightmode (On/Off) (Nightmode: the LEDs of the outlet are switched off).<br>
Further programming of the outlet should be done by TPLinks app "Kasa", which funtionality is partly redundant<br>
with FHEMs core functions.
<p>
<b>Attributs</b>
<ul>
<li><b>interval</b>: The interval in seconds, after which FHEM will update the current measurements. Default: 300s</li>
An update of the measurements is done on each switch (On/Off) as well.
<p>
<li><b>timeout</b>: Timeout in seconds used while communicationg with the outlet. Default: 1s</li>
<i>Warning:</i>: the timeout of 1s is chosen fairly aggressive. It could lead to errors, if the outlet is not answerings the requests
within this timeout.<br>
Please consider, that raising the timeout could mean blocking the whole FHEM during the timeout!
<p>
<li><b>disable</b>: The execution of the module is suspended. Default: no.</li>
<i>Warning: if your outlet is not on or not connected to the wifi network, consider disabling this module
by the attribute "disable". Otherwise the cyclic update of the outlets measurments will lead to blockings in FHEM.</i>
</ul>
<p>
<b>Requirements</b>
<ul>
This module uses the follwing perl-modules:<br><br>
<li> Perl Module: IO::Socket::INET </li>
<li> Perl Module: IO::Socket::Timeout </li>
</ul>
</ul>
=end html
=begin html_DE
<a name="TPLinkHS110"></a>
<h3>TPLinkHS110</h3>
<ul>
<br>
<a name="TPLinkHS110"></a>
<b>Define</b>
<code>define <name> TPLinkHS110 <ip/hostname></code><br>
<br>
Definiert eine TP-Link HS100 oder HS110 schaltbare WLAN-Steckdose. <br>
Der Unterschied zwischen der HS100 und HS110 besteht darin, dass die HS110 eine Echtzeit-Messung von <br>
Strom, Spannung sowie Leistung durchführt.<br>
Dieses Modul erkennt automatisch, welchen Typ Sie verwenden und passt die Readings entsprechend an.
<br><br>
Das Modul implementiert nicht alle Funktionen der HS100/110.<br>
Derzeit werden alle für den sinnvollen Betrieb an FHEM benötigten Parameter ausgelesen.<br>
Geschrieben werden jedoch nur die Schaltzustände "An", "Aus" sowie der Nachtmodus An/Aus (Nachtmodus = LEDs der Steckdose ausschalten).<br>
Für eine weitergehende Programmierung der Steckdosen wird daher die TP Link App "Kasa" empfohlen, wobei deren<br>
Funktionen wie Timer etc. letztlich redundant zu Kernfunktionen von FHEM sind.
<p>
<b>Attribute</b>
<ul>
<li><b>interval</b>: Das Intervall in Sekunden, nach dem FHEM die Messwerte aktualisiert. Default: 300s</li>
Eine Aktualisierung der Messwerte findet auch bei jedem Schaltvorgang statt.
<p>
<li><b>timeout</b>: Der Timeout in Sekunden, der bei der Kommunikation mit der Steckdose verwendet wird. Default: 1s</li>
<i>Achtung</i>: der Timeout von 1s ist knapp gewählt. Ggf. kann es zu Fehlermeldungen kommen, wenn die Steckdose nicht
schnell genug antwortet.<br>
Bitte beachten Sie aber auch, dass längere Timeouts FHEM für den Zeitraum des Requests blockieren!
<p>
<li><b>disable</b>: Die Ausführung des Moduls wird gestoppt. Default: no.</li>
<i>Achtung: wenn Ihre Steckdose nicht in Betrieb oder über das WLAN erreichbar ist, sollten Sie
dieses FHEM-Modul per Attribut "disable" abschalten, da sonst beim zyklischen Abruf der Messdaten
der Steckdose Timeouts auftreten, die FHEM unnötig verlangsamen.</i>
</ul>
<p>
<b>Requirements</b>
<ul>
Das Modul benötigt die folgenden Perl-Module:<br><br>
<li> Perl Module: IO::Socket::INET </li>
<li> Perl Module: IO::Socket::Timeout </li>
</ul>
</ul>
=end html_DE
=item summary Support for TPLink HS100/100 wifi controlled power outlet
=item summary_DE Support für die TPLink HS100/110 WLAN Steckdosen
Kannst Du das Modul bitte noch mal als Attachment hoch laden?
Zitat von: Volker Kettenbach am 10 Januar 2018, 23:09:42
Kannst Du das Modul bitte noch mal als Attachment hoch laden?
Klar.
Guten Abend allerseits,
das neue Release mit SetExtension (Danke für den Tip - Das kannte ich bisher auch nicht!) ist fertig.
Das FHEM-SVN habe ich aktualisiert. Das Modul sollte morgen verfügbar sein.
Wer's früher mag, findet es hier:
https://github.com/kettenbach-it/FHEM-TPLink-HS110
Ein Bitte:
ich bin dankbar für jeden Beitrag.
Aber diesen bitte entweder als komplettes Modul hier hochladen, so dass ich einen Patch/Pull-Request damit erzeigen kann.
Oder einen Pull-Request auf GitHub erzeugen.
Wer regelmäßig contributen will, der kann gerne auch Zugriff auf Git bekommen.
In diesem Falle wäre aber wichtig, sich mit GitFlow aus zu kennen, denn das verwende ich zum Management des Git-Repos.
Gruß
VK
Hallo Volker,
danke für das schöne Modul.
Dank der anderen, die dieselben Fehler gemacht haben, wie ich, habe ich es mit ein bisschen Lesen doch recht schnell hinbekommen, meine Steckdose an Fhem anzubinden.
Danke!
Hallo!
Erst einmal danke für das sehr nützliche Modul. Ich bin auch über den Fehler mit den nicht immer aktualisierenden Werten gestolpert. Ab und an scheint der Plug keine sinnvollen Tages-/Monatsdaten zuliefern. Auch in der Kasa-App ist dann nichts zu sehen. Dann werden ab auch die Real-Time Daten nicht mehr aktualisiert.
Soweit ich das Modul verstanden habe, scheint nach dem Log-Eintrag in Level 2 direkt ein Return zu folgen, ohne ein readingsEndUpdate davor. Das scheint dazuzuführen, dass zwar die Readings am Device aktuell sind, aber keine Events geschickt werden.
Ich habe Lokal bei mir nun a) die Fehlerlogs geändert, damit ich weiß welches Json decoding schief geht und b) vor das Return ein readingsEndUpdate gestellt.
Jetzt scheint mein Waschmaschinen-Ende-Doif wieder zu funktionieren.
Ich beobachte mal, ob ich nichts kaputt gemacht habe. Und wenn ich herausfinde, wie ich das Modul per Tablett hochlade teile ich gerne meine Änderungen.
Viele Grüße, Robert
Edit: Datei angefügt
Hallo!
ich nutze das Modul seit ca. einen Monat und habe nun seit 2 Tagen folgendes Problem, dass bei Internals der state nicht mehr aktualisiert wird. Dieser steht permanent auf off.
Der state unter den readings wird bei jedem manuellen Schaltvorgang aktualisiert.
Ich steuere mit folgender Routine, die dadurch nicht mehr so in dieser Art funktioniert, da der state sich nicht ändert und somit die Steckdose nicht mehr ausschaltet.
([Heizkreis_VLVM:temperature:d] < 33.0) (set wifipowerplug1:FILTER=STATE=on off) DOELSEIF ([Heizkreis_VLVM:temperature:d] > 35.0) (set wifipowerplug1:FILTER=STATE=off on)
Im logfile taucht auch ein neuer Eintrag auf:
Vorher:
2018.01.01 00:03:51 3: TPLinkHS110: wifipowerplug1 Get called. Relay state: 0, RSSI: -73
2018.01.01 00:03:51 3: TPLinkHS110: wifipowerplug1 Device is an HS110. Got extra realtime data: 0 Watt, 226.388095 Volt, 0.02574 Ampere
2018.01.01 00:03:51 3: TPLinkHS110: wifipowerplug1 Get end
Seit 2 Tagen:
2018.01.31 21:20:11 3: TPLinkHS110: wifipowerplug1 Get called. Relay state: 1, RSSI: -50
2018.01.31 21:20:11 3: TPLinkHS110: wifipowerplug1 Device is an HS110. Got extra realtime data: 0 Watt, 225.183699 Volt, 0.025733 Ampere
2018.01.31 21:20:11 2: TPLinkHS110: wifipowerplug1 json-decoding failed. Problem decoding getting statistical dat
Ich habe das Problem gelöst, indem ich bei der Steuerung das :FILTER=STATE=on entfernt habe.
Kann mir jemand sagen wieso auf einmal bei Internals der state hängt und sich nicht aktualisiert?
Vielen Dank im voraus.
VG
Hallo tox14,
ich hatte das selbe Problem und habe das Modul bei mir Lokal modifiziert, so dass auch beim auftreten dieses Fehlers noch die der (anscheinend nötige) Befehl abgesetzt wird um die alles vollständig zu aktualisieren und die Events abzufeuern. Meine Änderungen habe ich oben angehängt.
Zumindest bei mir läuft die Welt nun wieder normal.
Hallo zusammen,
ich habe die Änderungen von Wizzball ins offizielle Release eingebaut.
Vielen Dank dafür! Du hast in der Tat einen Bug gefixed!
(Dafür dass die Steckdosen manchmal keine Daten liefern kann ich aber nichts).
Das neue Modul steht unter https://github.com/kettenbach-it/FHEM-TPLink-HS110 und ab morgen im FHEM-SVN zur Verfügung.
Gruß
VK
Cool, freut mich dass ich ein kleines bisschen beitragen konnte.
@Wizzball: Danke für das schnelle Feedback und die Modifikation
Ich habe wie oben beschrieben, die eine Statusabfrage rausgenommen und gestern hat alles wieder ordnungsgemäß funktioniert. Ich denke auch, dass der Status wieder aktualisiert wurde.
@VK: Ich werde das Modul mal updaten, die Routine wieder auf den Ausgangszustand zurücksetzen und beobachten. Danke erstmal dafür.
Hallo Volker,
habe mir jetzt auch mal eine solche Dose zugelegt und hat auch einwandfrei funktioniert.
Frage ... in der Commandref steht:
Zitat
Geschrieben werden jedoch nur die Schaltzustände "An", "Aus" sowie der Nachtmodus An/Aus (Nachtmodus = LEDs der Steckdose ausschalten).
Mal abgesehen davon dass ich irgendwie nicht deuten kannst was du mit "Geschrieben" meinst, finde ich auch kein set-Kommando mit dem man den Nachmodus ein/ausschalten könnte.
Vielleicht habe ich auch etwas übersehen ?
Danke und LG,
Heiko
Zitat von: DS_Starter am 16 März 2018, 11:13:36
Mal abgesehen davon dass ich irgendwie nicht deuten kannst was du mit "Geschrieben" meinst, finde ich auch kein set-Kommando mit dem man den Nachmodus ein/ausschalten könnte.
Vielleicht habe ich auch etwas übersehen ?
Der Nightmode wird über ein Attribut festgelegt.
Geschrieben heißt an das Gerät gesendet.
Morgen Volker,
ZitatDer Nightmode wird über ein Attribut festgelegt.
Ahh ... jetzt habe ich es gefunden. Das Attribut ist in der Commandref nicht aufgeführt !
Grüße,
Heiko
Gibt es eine Möglichkeit dem Gerät eine feste IP zuzuordnen ?
Ich habe bis jetzt auch in der Kasa-App nichts dergleichen gefunden.
Vielleicht habt ihr es doch irgendwie hinbekommen.
LG,
Heiko
Ich kann mich nicht erinnern, ob das evtl in der App geht.
Ich habe es auf jeden Fall per DHCP gelöst (statischer Eintrag).
Hallo,
ich bin begeisterter Benutzer des Moduls für die HS110 und auch sehr zufrieden mit den Steckdosen selbst.
Nachrem ich mir ganz aktuellen Nachschub gegönnt habe, muss ich nun leider feststellen, dass im Log nur noch die Meldung
TPLinkHS110: XXX json-decoding failed. Problem decoding getting statistical data
TPLinkHS110: XXX json-raw:
erscheint.
Nach etwas Recherche ist mir aufgefallen, dass die beiden neuen Steckdosen nun HW-Version 2.0 (anstatt 1.0 bei den alten Dosen) in der App anzeigen und die Firmware bei den alten 1.2.5 und bei den neuen 1.5.2 lautet. Möglicherweise scheint hier etwas nicht mehr kompatibel zu sein. In der Kasa App scheinen natürlich sonst beide identisch zu sein.
Kann ich irgendentwas beisteuern, so dass sich das Problem hoffentlich lösen lässt? Danke schon mal!
Hi, ich nochmal.
Nachdem ich mich nun intensiv mit dem Problem beschäftigt habe, ist es mir nun tatsächlich gelungen das Problem zu lösen. Wenn ich von V2 spreche meine ich die neuen Dosen (hw_ver=2.0), bei V1 meine ich die "alten" Dosen mit hw_ver=1.0
Folgende Dinge sind mir aufgefallen:
1.) In der Funktion encrypt muss eine Änderung erfolgen, da sonst die neuen Dosen V2 nicht antworten. Ich habe keinen Ahnung warum, aber die Änderung interessiert die alten Dosen V1 anscheinend nicht, hier läuft nach meinen Tests alles auch nach der Änderung problemlos weiter:
349: my $result = "\0\0\0\0";
wird zu
my $result = "\0\0\0".chr(@string);
Anschließend antwortet die Dose schon wieder und alle mit einer HS100 V2 habens bereits geschafft. Allerdings gab es bei der HS110 V2 noch ein paar Änderungen, so dass nun das Auslesen der Verbäuche nicht mehr funktioniert.
2.) Bei V2 wurden leider die Werte im json-String {'emeter'}->{'get_realtime'} umbenannt, so dass nicht mehr auf die entsprechenden Daten zur Auswertung von Volt, Watt, Ampere etc zugegriffen werden kann.
Konkret wurde
{'power'} zu {'power_mw'}
{'voltage'} zu {'voltage_mv'}
{'current'} zu {'current_ma'}
{'energy'} zu {'energy_wh'}
Damit nun alles wieder funktioniert muss an diesen Stellen natürlich die Version der Dosen unterschieden werden. Ich hab das für mich jetzt mal so gelöst:
163: Log3 $hash, 3, "TPLinkHS110: $name Device is an HS110. Got extra realtime data: $realtimejson->{'emeter'}->{'get_realtime'}->{'power'} Watt, $realtimejson->{'emeter'}->{'get_realtime'}->{'voltage'} Volt, $realtimejson->{'emeter'}->{'get_realtime'}->{'current'} Ampere";
wird zu
my $hw_ver = $json->{'system'}->{'get_sysinfo'}->{'hw_ver'};
if ($hw_ver eq "1.0") {
Log3 $hash, 3, "TPLinkHS110: $name Device is an HS110. Got extra realtime data: $realtimejson->{'emeter'}->{'get_realtime'}->{'power'} Watt, $realtimejson->{'emeter'}->{'get_realtime'}->{'voltage'} Volt, $realtimejson->{'emeter'}->{'get_realtime'}->{'current'} Ampere";
# hw_vers >= 2.0
} else {
Log3 $hash, 3, "TPLinkHS110: $name Device is an HS110. Got extra realtime data: $realtimejson->{'emeter'}->{'get_realtime'}->{'power_mw'} Milliwatt, $realtimejson->{'emeter'}->{'get_realtime'}->{'voltage_mv'} Millivolt, $realtimejson->{'emeter'}->{'get_realtime'}->{'current_ma'} Milliampere";
}
und
182: foreach my $key (sort keys @{$json->{'emeter'}->{'get_daystat'}->{'day_list'}}) {
foreach my $key2 ($json->{'emeter'}->{'get_daystat'}->{'day_list'}[$key]) {
$total = $total+ $key2->{'energy'};
if ($key2->{'day'} == $mday) {
readingsBulkUpdate($hash, "daily_total", sprintf("%.3f", $key2->{'energy'}));
}
}
}
wird nun zu:
foreach my $key (sort keys @{$json->{'emeter'}->{'get_daystat'}->{'day_list'}}) {
foreach my $key2 ($json->{'emeter'}->{'get_daystat'}->{'day_list'}[$key]) {
if ($hw_ver eq "1.0") {
$total = $total+ $key2->{'energy'};
if ($key2->{'day'} == $mday) {
readingsBulkUpdate($hash, "daily_total", sprintf("%.3f", $key2->{'energy'}));
}
} else {
$total = $total+ $key2->{'energy_wh'};
if ($key2->{'day'} == $mday) {
readingsBulkUpdate($hash, "daily_total", sprintf("%.3f", $key2->{'energy_wh'}));
}
}
}
}
So funktioniert das Ganze nun erst mal. Wie jedoch die geänderten Werte schon erahnen lassen werden nun tatsächlich auch die Einheiten bei der Auswertung geändert. Wo früher Volt stand und Werte wie current=229.3001 gesendet wurden sind es nun tatsächlich Millivolt und der Wert lautet current_mv=229300. Ebenso bei den anderen Werten (Milliampere etc.) Hier sollten eventuell die Readings angeasst werden ( / 1000), so dass das Modul wieder einheitliche Werte liefert. Ich hoffe der aktuelle Stand hilft aber bereits dem ein oder anderen.
Schöne Grüße
Edit: Noch etwas. Es gibt ein neues Reading unter {"system":{"get_sysinfo":{}}} mit dem Namen "next_action". Dabei handelt es sich um eine geschachteltes JSON-Objekt und taucht aktuell dann in fhem natürlich als "HASH(0x47e4180)" auf. Sollte auch noch gefixt werden, nur zur Info...
Hallo Graph,
vielen Dank für Deine Beitrag und den Pull-Request.
Da ich selbst keine Version 2 Dosen haben, hätte ich auch nur bedingt helfen können.
Dein Beitrag schaut auch im Code sehr sinnvoll aus und ich würde den Pull-Request grundsätzlich mergen.
Aber es wäre nett, wenn Du die vorgeschlagene Division /1000 einbauen würdest und einen neuen Pull-Request schicken könntest.
Grund ist, dass sonst bei einem Mischbetrieb der beiden Versionen der Dosen unterschiedliche Einheiten in de Readings stehen und das Rechnen damit dann zu einem Durcheinander würde.
Wäre es möglich, dass Du das noch machst und noch mal einen Pull-Request schickst?
Ich merge den dann sofort.
Gruß
Volker
Hallo,
hab den Code entsprechend aktualisiert. Da bei mir die Dosen Version 1/2 ja jetzt auch im Mischbetrieb laufen, war mir das auch ein persönliches Anliegen die Werte schnell zu vereinheitlichen.
Was momentan noch fehlt ist das verschachtelte neue json-Element für die "next_action" im sysinfo mittels foreach auszulesen. Keine große Sache, aber sollte man eventuell irgendwann der Vollständigkeit halber noch einbauen.
Da die Dosen zur Zeit, weil "Alexa kompatibel", extrem auf Amazon beworben werden, hab ich jetzt ein Werte/Faktor Mapping gebaut. Nicht, dass in Kürze dann Hardwareversion 3.0 erscheint und die Readings wieder umständlich geändert werden müssen. ;D
Hier sollte im Code zur Vereinheitlichung auch im Abschnitt "total/energy" noch auf das Mapping verwiesen werden, wie im Abschnitt "sysinfo" und "emeter". Aber funktioniert dort natürlich im Moment auch anhand der Unterscheidung von "hw_ver". Aber schöner - weil einheitlicher - wär's.
Schöne Grüße
Super!
Gib mir mal das Wochenende Zeit.
Dann teste und merge ich das!
Hallo Volker,
gibt es hier schon etwas neues? Habe seit dem WE auch die HS110 V2 im Einsatz, und bekomme auch nur die Logeinträge:
TPLinkHS110: HS110 json-decoding failed. Problem decoding getting statistical data
Meine HS100 V1 läuft immer noch einwandfrei. Wenn ich irgendwie helfen kann, würde ich das gerne machen.
VG
Raik
Habe viel um die Ohren.
Ich kümmere mich heute Abend drum
Das neue Modul steht im Git bereit: https://github.com/kettenbach-it/FHEM-TPLink-HS110
Ab morgen dann auch im offiziellen SVN des FHEM Projekts.
Hallo Volker,
vielen Dank, dass Du Dich kümmerst! Leider hat das Update bei der HS110 V2 noch nicht den gewünschten Effekt. In FHEM bekomme ich als State nur ???.
Im Log habe ich folgendes stehen:
PERL WARNING: Use of uninitialized value in string eq at ./FHEM/24_TPLinkHS110.pm line 253.
Die andere Meldung scheint dafür aber weg zu sein. Kann ich noch irgendwie helfen?
VG
EDIT: Sorry, aber bekomme jetzt doch Meldungen von der Steckdose. Scheint also zu funktionieren. Musste nur einmal einen request an die HS110 senden. Also: VIELEN DANK noch einmal!!!
Hallo Volker,
bin aus dem Urlaub gekommen und habe ein Update in FHEM gemacht. Seitdem bekomme ich bei meiner V1-Steckdose immer wieder die Meldungen:
2018.05.28 07:59:53.038 2: TPLinkHS110: tplink.energymeter json-decoding failed. Problem decoding getting daily stat data
2018.05.28 08:15:22.996 2: TPLinkHS110: tplink.energymeter json-decoding failed. Problem decoding getting daily stat data
2018.05.28 08:17:58.041 2: TPLinkHS110: tplink.energymeter json-decoding failed. Problem decoding getting daily stat data
Manchmal funktioniert es auch. Aber so stabil wie vorher ist es leider nicht mehr. Zwei Beiträge vorher hat dynamoa das gleiche Problem mit V2 Dosen beschrieben das bei ihm offensichtlich nach einer Codeänderung beseitigt ist, bei mir aber nun dieser Fehler kommt.
list:
Internals:
DEF 192.168.2.102
HOST 192.168.2.102
INTERVAL 155
NAME tplink.energymeter
NR 1551
STATE 2.249066 W
TIMEOUT 1
TYPE TPLinkHS110
READINGS:
2018-05-28 08:37:53 active_mode schedule
2018-05-28 08:37:53 alias Steckdose 2
2018-05-28 08:37:53 current 0.074613
2018-05-28 08:37:53 daily_average 0.0740714285714286
2018-05-28 08:37:53 daily_total 0.022
2018-05-28 08:37:53 dev_name Wi-Fi Smart Plug With Energy Monitoring
2018-05-28 08:37:53 deviceId 800631C67AD9E0A84E8DF3B6BA79D2941991980D
2018-05-28 08:37:53 err_code 0
2018-05-28 08:37:53 feature TIM:ENE
2018-05-28 08:37:53 fwId 851E8C7225C3220531D5A3AFDACD9098
2018-05-28 08:37:53 hwId 45E29DA8382494D2E82688B52A0B2EB5
2018-05-28 08:37:53 hw_ver 1.0
2018-05-28 08:37:53 icon_hash
2018-05-28 08:37:53 latitude 51.316095
2018-05-28 08:37:53 led_off 0
2018-05-28 08:37:53 longitude 12.06025
2018-05-28 08:37:53 mac B0:4E:26:6B:99:03
2018-05-28 08:37:53 model HS110(EU)
2018-05-28 08:37:53 monthly_total 2.074
2018-05-28 08:37:53 oemId 3D341ECE302C0642C99E31CE2430544B
2018-05-28 08:37:53 on_time 465
2018-05-28 08:37:53 power 2.249066
2018-05-28 08:37:53 relay_state 1
2018-05-28 08:37:53 rssi -60
2018-05-28 08:37:53 state on
2018-05-28 08:37:53 sw_ver 1.1.4 Build 170417 Rel.145118
2018-05-28 08:37:53 total 3.503
2018-05-28 08:37:53 type IOT.SMARTPLUGSWITCH
2018-05-28 08:37:53 updating 0
2018-05-28 08:37:53 voltage 233.371585
Attributes:
alias TPLink Energiemesser
cmdIcon on:remotecontrol/black_btn_GREEN off:remotecontrol/black_btn_RED
comment *_total: Wh
power: aktueller Verbrauch in Watt
on_time: s
disable 0
event-on-update-reading state
group Energiemesser
interval 155
room Energie
stateFormat power W
verbose 2
Grüße
Heiko
Hi Volker,
ich nehme alles zurück behaupte das Gegenteil :)
Habe die vorherige Version wieder eingespielt und bekomme die gleichen Fehlermitteilungen. Muß also an etwas anderem liegen und muss mal auf die Suche gehen.
Grüße
Heiko
Hallo Volker,
ich habe das Modul etwas umgebaut damit man mehr sieht. Mit verbose 5 kann man sich die empfangenen Daten (Get) ansehen.
Es ist deutlich zu sehen dass im Meldungsfall die Daten unvollständig/abgeschnitten sind.
Hast du eine Idee woran das liegen könnte. Es kommt immer mal wieder vor.
2018.05.28 22:31:34.208 3: TPLinkHS110: tplink.energymeter Get called. Relay state: 1, RSSI: -60
2018.05.28 22:31:34.251 3: TPLinkHS110: tplink.energymeter Device is an HS110. Got extra realtime data: 2.26819 Watt, 233.937667 Volt, 0.074182 Ampere
2018.05.28 22:31:34.287 5: tplink.energymeter - Data returned: '{"emeter":{"get_daystat":{"day_list":[{"year":2018,"month":5,"day":1,"energy":0.064000},{"year":2018,"month":5,"day":2,"energy":0.062000},{"year":2018,"month":5,"day":3,"energy":0.062000},{"year":2018,"month":5,"day":4,"energy":0.063000},{"year":2018,"month":5,"day":5,"energy":0.074000},{"year":2018,"month":5,"day":6,"energy":0.083000},{"year":2018,"month":5,"day":7,"energy":0.083000},{"year":2018,"month":5,"day":8,"energy":0.083000},{"year":2018,"month":5,"day":9,"energy":0.083000},{"year":2018,"month":5,"day":10,"energy":0.083000},{"year":2018,"month":5,"day":11,"energy":0.083000},{"year":2018,"month":5,"day":12,"energy":0.083000},{"year":2018,"month":5,"day":13,"energy":0.082000},{"year":2018,"month":5,"day":14,"energy":0.083000},{"year":2018,"month":5,"day":15,"energy":0.083000},{"year":2018,"month":5,"day":16,"energy":0.083000},{"year":2018,"month":5,"day":17,"energy":0.083000},{"year":2018,"month":5,"day":18,"energy":0.083000},{"year":2018,"month":5,"day":19,"energy":0.083000},{"year":2018,"month":5,"day":20,"energy":0.083000},{"year":2018,"month":5,"day":21,"energy":0.082000},{"year":2018,"month":5,"day":22,"energy":0.083000},{"year":2018,"month":5,"day":23,"energy":0.063000},{"year":2018,"month":5,"day":24,"energy":0.064000},{"year":2018,"month":5,"day":25,"energy":0.067000},{"year":2018,"month":5,"day":26,"energy":0.062000},{"year":2018,"month":5,"day":27,"energy":0.062000},{"year":2018,"month":5,"day":28,"energ'
Die Fehlermeldung falls beim Dekodieren etwas schiefgeht erscheint nun in einem Reading "decode_json", sonst steht dort "ok".
Das geänderte Modulhabe ich mit angehängt.
Vielleicht magst du es so ins SVN übernehemen. Ich denke das ist jetzt hilfreicher und aussagefähiger für eine Fehlersuche.
Grüße
Heiko
Könntest Du einen Pullrequest schicken
https://github.com/kettenbach-it/FHEM-TPLink-HS110/pulls
Ich hoffe es richtig gemacht zu haben, tue mich immer sehr schwer mit dem Git.
Das Problem an sich ist damit natürlich nicht aus der Welt.
Hast du eine Idee zu den "Verstümmelungen" ?
Grüße
Heiko
Hallo Heiko,
die Verstümmelungen beobachte ich auch. Ich weiss nicht, warum die auftreten. Ich tippe mal auf die Hardware.
Der Pullrequest wurde irgendwie mit dem Code von der-graph vermischt, der jedoch bereits committet ist.
Ich habe den Pull-Request verworfen und habe mir das Diff zwischen dem o.g. Modul und dem im Master-Branch angeschaut.
Dein Patch ist recht umfangreich.
Ich verstehe nicht, wofür er da ist.
Du schreibst, Du willst den Debug-Output verbessern. Warum dann das hier:
> my $emeterValue = $realtimejson->{'emeter'}->{'get_realtime'}->{$key2};
>
> #adjust different hw_ver readings, be sure to list all emeter readings in hwMapping
> if (exists($hwMap{$hw_ver}{'emeter'}{'get_realtime'}{$key2})) {
> if (exists($hwMap{$hw_ver}{'emeter'}{'get_realtime'}{$key2}{'factor'})) {
> $emeterValue = $emeterValue * $hwMap{$hw_ver}{'emeter'}{'get_realtime'}{$key2}{'factor'};
> }
> $key2 = $hwMap{$hw_ver}{'emeter'}{'get_realtime'}{$key2}{'name'};
> readingsBulkUpdate($hash, $key2, $emeterValue);
> $emeterReadings{$key2} = $emeterValue;
> } else {
> return "Check supported hw_ver of device: $hw_ver\n";
> }
163c192,195
An sich ist der Code vom Modul gut, so wie er ist.
An den Verstümmelungen können wir vermutlich nichts ändern.
Wenn ich Code committen soll, dann müsste dieser besser lesbar und kommentiert sein.
Und in Form einer Patch-Datei oder eines Pull-Requests.
Gruß
Volker
Hi Volker,
Zitat
> my $emeterValue = $realtimejson->{'emeter'}->{'get_realtime'}->{$key2};
>
> #adjust different hw_ver readings, be sure to list all emeter readings in hwMapping
> if (exists($hwMap{$hw_ver}{'emeter'}{'get_realtime'}{$key2})) {
> if (exists($hwMap{$hw_ver}{'emeter'}{'get_realtime'}{$key2}{'factor'})) {
> $emeterValue = $emeterValue * $hwMap{$hw_ver}{'emeter'}{'get_realtime'}{$key2}{'factor'};
> }
> $key2 = $hwMap{$hw_ver}{'emeter'}{'get_realtime'}{$key2}{'name'};
> readingsBulkUpdate($hash, $key2, $emeterValue);
> $emeterReadings{$key2} = $emeterValue;
> } else {
> return "Check supported hw_ver of device: $hw_ver\n";
> }
163c192,195
Da habe ich nix mit zu tun ;) ... Nein, schau nochmal, da hast du wahrscheinlich etwas anderes gesehen als die von mit geänderten Stellen.
Zitat
An sich ist der Code vom Modul gut, so wie er ist.
Ja ist er. Es geht tatsächlich nur um die Möglichkeiten dieser Fehlerdarstellung/Analyse.
ZitatUnd in Form einer Patch-Datei oder eines Pull-Requests.
Ich mache lieber einen SVN-Patch. Ist mir echt sympathischer.
(Kannst du natürlich auch selbst anschauen, die Datei ist ja angehängt)
Melde mich wieder
Grüße
Heiko
Hallo Volker,
anbei ist der SVN-Diff.
Grüße
Heiko
Hallo Heiko,
ich habe mir das jetzt mal angeschaut. Prinzipiell okay.
Ich habe nur ein persönliches Problem:
Mein FHEM ist schon ca. 2 Jahre alt. Ich habe aufgehört das zu aktualisieren, da damals eine erhebliche Änderung des KNX-Moduls gemacht wurde, welches mich zwingen würde, alle meine KNX-Devices neu zu definieren. Da das bei mir sehr viele sind und es Stunden und Tage dauern würde, bin ich auf dieser alten Version stehen geblieben.
Was bei mir jetzt nicht geht ist die Funktion readingsBulkUpdateIfChanged, denn die wurde erst später eingeführt.
Wäre es möglich, dass Du diese Funktion nicht verwendest sondern einfach ein Update machst, egal ob sich was geändert hat?
Für Dein Feature habe ich einen Feature-Branch aufgemacht (ich arbeite mit git-flow):
Der liegt hier:
https://github.com/kettenbach-it/FHEM-TPLink-HS110/tree/feature/ds-starter_extradedebugging
Da kannst Du mir einfach einen Patch dagegen schicken oder die Datei ändern und schicken.
Gruß
Volker
Hallo Volker,
Zitat
Was bei mir jetzt nicht geht ist die Funktion readingsBulkUpdateIfChanged, denn die wurde erst später eingeführt.
Wäre es möglich, dass Du diese Funktion nicht verwendest sondern einfach ein Update machst, egal ob sich was geändert hat?
Ja klar, kein Problem.
Ich ändere das und versuche mich mal bei deinem Git ;)
Grüße
Heiko
Morgen Volker,
Änderung ist drin ... schau mal.
Grüße
Heiko
Du müsstest eine Datei anhängen oder einen Pull-Request auf den Branch machen
Hast du eine Handlungsanleitung was wo wie zu machen ist ? Ich würde gern ein File anhängen, geht aber nicht wegen fehlernder Schreibberechtigung. Ansonsten finde ich nur Kommentarfelder. Ist das immer so aufwändig ? Da lobe ich mir doch SVN :)
Bitte ein Diff hier anhängen
Hi Volker,
gerne :) ... hier ist das Diff.
Grüße
Heiko
Änderungen sind im Git und ab morgen im SVN
Danke Volker !
Lg
Heiko
Hallo Volker,
ich habe noch eine kleine Unschönheit im Modul festgestellt. Wenn das Modul disabled ist, erscheinen unter "set" ein paar unsinnige Auswahlmöglichkeiten. Der angehängte diff behebt das.
viele Grüße
Heiko
Hi Heiko,
ich kann den Patch nicht anwenden. Da stimmt was nicht.
vsauer@volkers-mbp: ~/GitHub/FHEM-TPLink-HS110[develop*]>patch --dry-run < /tmp/24_TPLinkHS110.diff
(Stripping trailing CRs from patch.)
patching file 24_TPLinkHS110.pm
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n] <
Skipping patch.
4 out of 4 hunks ignored -- saving rejects to file 24_TPLinkHS110.pm.rej
Der Inhalt des Patches sieht auch recht komisch aus.
Bitte den Patch gegen die Master Branch von https://github.com/kettenbach-it/FHEM-TPLink-HS110 erzeugen!
Gruß
Volker
Hallo Volker,
sorry, das ist ein SVN-diff.
Kommst du damit klar ? Wenn nicht versuche ich mich nochmal mit dem GIT.
Grüße
Heiko
Ob Git oder Svn ist doch letztlich egal.
Es muss ein mit diff erzeugter Patch sein, der sich auf den Master Branch bezieht
Tja, tut mir leid, in dem Git-Molloch habe ich jetzt wieder endlos Zeit verbracht um irgendeine Stelle zu finden wo man "einfach" einen diff erzeugen kann. Eine simple Beschreibung für solche Tätigkeiten kenne ich ja nach wie vor nicht. Ist mir jetzt echt zu viel Aufwand und schade um die vergeudete (Frei)Zeit nur um eine Zeile zu ändern:
252 -> return "Device disabled in config" if ($attr{$name}{"disable"} eq "1");
ändere in:
return if (IsDisabled($name));
Dann passt das und funktioniert wie gewünscht.
Aber habe mit meinem Tortoise-Diff nochmal ein File gegen das SVN erstellt. Sieht jetzt besser aus denke ich.
Zitat von: DS_Starter am 01 Juli 2018, 09:20:17
Tja, tut mir leid, in dem Git-Molloch habe ich jetzt wieder endlos Zeit verbracht um irgendeine Stelle zu finden wo man "einfach" einen diff erzeugen kann. Eine simple Beschreibung für solche Tätigkeiten kenne ich ja nach wie vor nicht. Ist mir jetzt echt zu viel Aufwand und schade um die vergeudete (Frei)Zeit nur um eine Zeile zu ändern:
Hier steht wie das geht:
https://feldspaten.org/2014/12/05/patch-erzeugen-diff-patch/
Mit GIT oder SVN hat das im Grunde ja gar nichts zu tun.
Die Tool heissen diff und patch und können auch aus irgendwelchen GUI wie Eclipse, IntelliJ usw. aufgerufen werden.
Ggf. auch von irgendwelchen GIT oder SVN-Tools.
Vlt. solltest Du Dir wegen GIT das hier mal anschauen:
https://www.sourcetreeapp.com/
Das kann eine Alternative sein, wenn Du keine IDE verwendest.
Ich nutze es gelegentlich, wenn ich nicht meine IDE starten will.
Stichwort IDE: evtl. wäre das hier sinnvoll für Dich: https://code.visualstudio.com/
Mit den entsprechenden Plugins kann das auch Perl. GIT oder SVN sowieso.
Bei diesen Tools heisst das einfach nur VCS (Version Control System).
Ansonsten kann ich Dich nur ermuntern, Dich mit GIT zu beschäftigen.
SVN ist mausetot und im Vergleich zu GIT auch wie Käfer zu Porsche 911.
Die Codezeile habe ich geändert und ins GIT und SVN eingecheckt.
Hi Volker,
danke für die Links. Schaue ich mir an.
Da war ich gestern wohl etwas sehr genervt :o
Grüße
Heiko
Hallo in die Runde,
ich habe ein Problem auf einem Whezzy Pi mit cpan. Hier (https://forum.fhem.de/index.php/topic,89166.msg816530.html#msg816530) der Thread dazu. Wäre klasse wenn mich da jemand unterstützen könnte.
Danke und Grüße
Fritz
Hallo,
also ich kriege das nicht hin. Habe auf meinem Raspberry (wheezy) nun via cpan IO::Socket::Timeout die benötigten Pakete installiert. Bekomme aber wenn ich
define MbAktTplWlan01 TPLinkHS110 192.168.178.53 eingeben ein
Cannot load module TPLinkHS110 als Ausgabe.
Wäre dankbar wenn mich hier jemand unterstützen könnte.
Grüße Fritz
Zitat von: Fritz Muster am 07 Juli 2018, 17:15:42
Cannot load module TPLinkHS110 als Ausgabe.
Wäre dankbar wenn mich hier jemand unterstützen könnte.
Wenn Du in die Log-Datei schaust, sollte da für diesen Zeitpunkt eine ausführlichere Fehlermeldung stehen. Daran kann man sehen, woran es genau hapert...
Zunächst einmal Danke für den Hinweis.
Im Log steht folgendes
2018.07.09 18:02:10 1: reload: Error:Modul 24_TPLinkHS110 deactivated:
Excessively long <> operator at ./FHEM/24_TPLinkHS110.pm line 21.
2018.07.09 18:02:10 0: Excessively long <> operator at ./FHEM/24_TPLinkHS110.pm line 21.
Güße
Fritz
Zitat von: Fritz Muster am 09 Juli 2018, 18:04:45
Zunächst einmal Danke für den Hinweis.
Hast Du die aktuelleste Version der TPLinkHS110.pm? Es gab da kürzlich einige Änderungen, damit auch Geräte mit neuerer Firmware unterstützt werden.
Zitat von: Brockmann am 10 Juli 2018, 08:04:35
Hast Du die aktuelleste Version der TPLinkHS110.pm? Es gab da kürzlich einige Änderungen, damit auch Geräte mit neuerer Firmware unterstützt werden.
Ja, habe von github die aktuelle Version von DS_Starter runtergeladen und ins Verzeichnis fhem/FHEM kopiert. Rechte und Gruppe angepasst. Werde das aber nochmal kontrollieren.
Danke
Zitat von: Fritz Muster am 10 Juli 2018, 11:24:53
Ja, habe von github die aktuelle Version von DS_Starter runtergeladen und ins Verzeichnis fhem/FHEM kopiert. Rechte und Gruppe angepasst. Werde das aber nochmal kontrollieren.
Also das ist dann zumindest nicht die aktuelle "offizielle" Version der Datei. Warum nimmst Du nicht einfach die Version, die zum aktuellen Lieferumfang von FHEM gehört?
Da sollten die Änderungen von DS_Starter auch schon integriert sein, wenn ich die letzten Posts hier richtig interpretiere.
Ein Fehler in Zeile 21 kommt mir jedenfalls komisch vor. Bei der "offiziellen" Datei sind die ersten 30 Zeilen Kommentare, da kann gar kein Fehler auftreten.
Hast Du mal in die Datei (bei Dir) reingeschaut? Eventuell ist da beim Runterladen was schiefgelaufen?
Zitat von: Brockmann am 10 Juli 2018, 15:25:50
Hast Du mal in die Datei (bei Dir) reingeschaut? Eventuell ist da beim Runterladen was schiefgelaufen?
Danke für den Tipp. In der Datei stand tatsächlich Kokolores. Habe die Datei nochmal gezogen und nun läuft es.
Vielen Dank und Grüße
Fritz
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 (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
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
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
Hab die lb130 bestellt.
Dann Mal schauen.
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.
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):
Zitat
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
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?
Zitat von: BM030 am 06 September 2018, 07:09:52
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 (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.
... kann es kaum erwarten! Teste gerne soweit ich kann, falls du Hilfe brauchst.
Zitat von: Volker Kettenbach am 25 September 2018, 07:29:31
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.
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.
Zitat# 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);
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.
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...
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.
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.
Hallo Volker,
Ich bin neu hier und vorweg ein Dank für deinen Code und den super Support. Bei mir gibts leider Probleme seit dem letzten FHEM-Update von gestern.
Ich habe 2 TPLinkk HS110(EU) am Laufen:
Nr. HW-Ver SW-Ver
1 1.0 1.2.5
2 2.0 1.5.4
Nr 1 machte vorher und nachher keine Probleme.
Nr 2 wirft seit dem Update einen decode_json-Fehler und liefert keine Verbrauchsdaten mehr. Schalten lässt es sich und alle anderen Readings kommen auch. Ähnlich wie oben bei chani666.
Mein Workaround ist jetzt der Wechsel zurück auf die alte Modul-Datei vom 1. Feb 18 aus dem GitHub-Archiv -> Verbrauchsdaten kommen wieder.
VG
Christoph
Kannst Du das Debugging mal per "verbose 5" Attribut beim Gerät aktivieren und den LogOutput hier posten?
Ich habe mir gerade bei Amazon mal eine neue HS110 bestellt. Ich hoffe, das ist eine Version 2 (es gibt wohl schon die 3).
Weil ohne kann ich das nicht nachvollziehen.
Morgen Volker,
nach dem Update kommen in meinem Log laufende Meter diese Meldungen:
2018.10.05 06:53:32.693 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 06:53:32.706 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 06:54:52.688 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 06:54:52.700 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 06:56:12.688 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 06:56:12.701 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 06:57:32.689 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 06:57:32.701 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 06:58:52.697 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 06:58:52.710 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 07:00:12.695 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 07:00:12.710 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 07:01:32.692 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 07:01:32.704 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 07:02:52.694 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 07:02:52.707 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 07:04:12.709 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 07:04:12.745 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 07:05:32.780 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 07:05:32.792 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 07:06:52.777 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 07:06:52.791 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 07:08:12.779 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 07:08:12.791 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 07:09:32.798 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 07:09:32.810 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 07:10:52.781 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 07:10:52.796 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 07:12:12.781 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 07:12:12.794 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 07:13:32.855 1: TPLinkHS110: tplink.energymeter Realtime data updated
2018.10.05 07:13:32.867 1: TPLinkHS110: tplink.energymeter Daystat updated
2018.10.05 07:14:52.857 1: TPLinkHS110: tplink.energymeter Realtime data updated
Muß ich wirklich verbose 0 einstellen ? Ist bestimmt nicht so gewollt.
Meine Softwareversion ist: sw_ver = 1.1.4 Build 170417 Rel.145118
viele Grüße
Heiko
Hi,
also ich bekomme seit gestern (da habe ich glaube das Update gemacht) auch keine Verbrauchsdaten mehr
in den decode_json readings steht
"garbage after JSON object, at character offset 112 (before "\x{fffd}\x{0}\x{2}\x{fffd}...") at ./FHEM/24_TPLinkHS110.pm line 472, <GEN210> line 1."
Irgendwas scheint sich geändert zu haben
folgendes steht im Log
2018.10.05 10:20:23 5: TpLinkHS110Umwaelzpumpe - Data returned: $VAR1 = '{"system":{"get_sysinfo":{"sw_ver":"1.5.4 Build 180815 Rel.121440","hw_ver":"2.0","type":"IOT.SMARTPLUGSWITCH","model":"HS110(EU)","mac":"AC:84:C6:29:11:47","dev_name":"Smart Wi-Fi Plug With Energy Monitoring","alias":"Umwälzpumpe","relay_state":1,"on_time":372,"active_mode":"schedule","feature":"TIM:ENE","updating":0,"icon_hash":"","rssi":-67,"led_off":0,"longitude_i":86026,"latitude_i":521927,"hwId":"044A516EE63C875F9458DA25C2CCC5A0","fwId":"00000000000000000000000000000000","deviceId":"80062E1B8FD1B5DC7CD4271C6E7EBD4819E2E05B","oemId":"1998A14DAA86E4E001FD7CAF42868B5E","next_action":{"type":1,"id":"C1F224EAB9965A1E920F7039664BD61C","schd_sec":81000,"action":0},"err_code":0}}}';
2018.10.05 10:20:23 3: TPLinkHS110: TpLinkHS110Umwaelzpumpe Get called. Relay state: 1, RSSI: -67
2018.10.05 10:20:24 5: TpLinkHS110Umwaelzpumpe - Data returned: $VAR1 = '{"emeter":{"get_realtime":{"voltage_mv":222641,"current_ma":96,"power_mw":20876,"total_wh":2,"err_code":0}}}��`"system":{"get_sysinfo":{"sw_ver":"1.5.4 Build 180815 Rel.121440","hw_ver":"2.0","type":"IOT.SMARTPLUGSWITCH","model":"HS110(EU)","mac":"AC:84:C6:29:11:47","dev_name":"Smart Wi-Fi Plug With Energy Monitoring","alias":"Umwälzpumpe","relay_state":1,"on_time":372,"active_mode":"schedule","feature":"TIM:ENE","updating":0,"icon_hash":"","rssi":-67,"led_off":0,"longitude_i":86026,"latitude_i":521927,"hwId":"044A516EE63C875F9458DA25C2CCC5A0","fwId":"00000000000000000000000000000000","deviceId":"80062E1B8FD1B5DC7CD4271C6E7EBD4819E2E05B","oemId":"1998A14DAA86E4E001FD7CAF42868B5E","next_action":{"type":1,"id":"C1F224EAB9965A1E920F7039664BD61C","schd_sec":81000,"action":0},"err_code":0}}}';
und es scheint nru bei hw_ver 2.0 zu dem Problem zu kommen, denn meine ältere HW_ver 1.0 funktioniert scheinbar noch
DANKE und Gruß
Marcel
Okay, der Fehler mit der Version 2 ist gefunden und hier (https://github.com/kettenbach-it/FHEM-TPLink-HS110) im Master enthalten!!
@Heiko: Das Thema mit dem Loglevel 1 habe ich auch gerade mit gefixed.
Das SVN ist ab morgen up -to-date!!
Eine Sache noch:
Geholfen hat, dass ich gerade meine neue TPLink HS110 bekommen! Aber es ist eine Version 3!
Damit habe ich jetzt mehrere Version 1 und eine Version 3.
Aber leider keine Version 2.
Es wäre aber gut, wenn ich eine hätte.
Frage in die Runde: wer würde mir seine Version 2 im Austausch gegen eine Version 1 geben!?
Dann hätte ich alles Version zum testen da!
Gruß
Volker
Danke Volker und einen schönen Abend
Achso , ich habe nur version 1 steckdosen. Da kann ich nicht mit dienen.
Lg,
Heiko
Danke Volker, dann bin ich auf das Update morgen gespannt
Hallo Volker,
klar können wir tauschen. Meine Version 2 ist recht neu, habe sie auch erst vorletzte Woche von Amazon bekommen. Drum wundert es mich, dass sie jetzt schon V3 liefern. Ich schicke Dir eine PM mit meiner Adresse.
VG
Christoph
Hallo nochmal zusammen,
wg. dem Versions-Thema noch mal eine Frage in die Runde:
Meine neue HS110 hat einen Aufkleber, auf dem steht Version 3.0
Lt. der Support Seite von TPLink gibt es in der Tat wohl 3 Versionen: https://www.tp-link.com/de/download/HS110.html
Die Software meldet jedoch 2.0.
Genauer:
hw_ver: 2.0
sw_ver: 1.4.3 Build 171009 Rel.104144
Meine Frage ist: wie sieht das bei den 2.0 Dosen aus? Was steht drauf, was meldet die Software?
Bitte hier mal posten!
Gruß
Volker
P.S.: mein Verdacht ist, dass softwaremäßig V2==V3 ist.
Das wäre gut für mich, denn ich habe keine HW-Version 2.
gerade das Update gemacht.
Läuft wieder! DANKE!!!
bei mir auch: Update funktioniert! Danke!
VG
Christoph
Moin,
seit dem letzten Update füllt es mit den LOG im 5 Minuten Takt
2018.10.08 00:10:38.248 2: TPLinkHS110: TPLink1 Realtime data updated
2018.10.08 00:10:38.287 2: TPLinkHS110: TPLink1 Daystat updated
2018.10.08 00:15:38.249 2: TPLinkHS110: TPLink1 Realtime data updated
2018.10.08 00:15:38.283 2: TPLinkHS110: TPLink1 Daystat updated
Ist ein so häufiges Update normal? Wenn ja wäre das nicht was für Verbose Level 3?
Grüße
Achim
Ein verbose Level von 1 ist für das Modul angebracht. Dann zeigt es nur Fehler.
Aber Du hast im Grunde recht. Ich werde das mit dem nächsten Update auf Level 2 oder gar 3 ändern.
Perfekt, danke dir :-)
Hallo,
ich habe hier seit vorigem Jahr 8 Stück HS110 in Hardware-Version 1.0, Firmware-Version 1.2.5 am laufen. Nun habe ich mir noch zwei weitere gekauft, diese sind Hardware-Version 2.0, Firmware-Version 1.5.4 (device HS110_09 und HS110_10).
Anscheinend sind die angezeigten Werte bei den Hardware-Versionen unterschiedlich (Version 1 in kWatt, Version 2 in Watt). Das hat bei der Anzeige im ersten Moment doch ... naja, eine kurze Panikattacke ob des Verbrauchswertes
verursacht :o ;D
Auszug aus Datenbank, Tabelle "current"
timestamp device reading value unit
2018-10-26 19:38:22 HS110_01 daily_total 11.071
2018-10-26 19:39:21 HS110_02 daily_total 8.426
2018-10-26 19:17:55 HS110_03 daily_total 0.000
2018-10-26 19:41:54 HS110_04 daily_total 2.198
2018-10-26 19:38:05 HS110_05 daily_total 0.000
2018-10-26 19:38:07 HS110_06 daily_total 2.892
2018-10-26 19:39:58 HS110_07 daily_total 4.527
2018-10-26 19:40:01 HS110_08 daily_total 1.867
2018-10-26 19:40:06 HS110_09 daily_total 2285.000
2018-10-26 19:41:24 HS110_10 daily_total 1429.000
Gibt es hier die Möglichkeit einer "Vereinheitlichung" der Einheit oder muss ich hier schlicht und ergreifend bezüglich Anzeige und Auswertung per Hand ran ?
Ich bedanke mich schon im voraus für allfällige Infos und Hinweise :-)
Liebe Grüße aus Österreich
Nachdem ich einen FHEM-Update gemacht hatte, kommt es nach ca. 1-2 Stunden zum Absturz von FHEM.
Letzte Meldungen im Log:
2018.10.28 20:55:10 3: TPLinkHS110: HS100 Get called. Relay state: 0, RSSI: -72
2018.10.28 20:55:10 3: TPLinkHS110: HS100 Updating readings
2018.10.28 20:55:10 3: TPLinkHS110: HS100 Get end
2018.10.28 20:55:11 1: PERL WARNING: Use of uninitialized value $data in substr at ./FHEM/24_TPLinkHS110.pm line 116.
substr outside of string at ./FHEM/24_TPLinkHS110.pm line 116.
Nach Einsatz einer älteren Version von 24_TPLinkHS110.pm läuft es wieder.
Zitat von: Volker Kettenbach am 25 September 2018, 07:31:56
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.
Hallo Volker,
Bist du schon dazu gekommen?
Grüße Gordon
Nein. Eventuell bis Ende des Jahres.
Zitat von: Lichti am 29 Oktober 2018, 16:02:36
Nachdem ich einen FHEM-Update gemacht hatte, kommt es nach ca. 1-2 Stunden zum Absturz von FHEM.
Letzte Meldungen im Log:
2018.10.28 20:55:10 3: TPLinkHS110: HS100 Get called. Relay state: 0, RSSI: -72
2018.10.28 20:55:10 3: TPLinkHS110: HS100 Updating readings
2018.10.28 20:55:10 3: TPLinkHS110: HS100 Get end
2018.10.28 20:55:11 1: PERL WARNING: Use of uninitialized value $data in substr at ./FHEM/24_TPLinkHS110.pm line 116.
substr outside of string at ./FHEM/24_TPLinkHS110.pm line 116.
Nach Einsatz einer älteren Version von 24_TPLinkHS110.pm läuft es wieder.
ich habe das gleiche Problem. Gibt es dazu schon eine Lösung?
Nein, weil ich es nicht nachvollziehen kann.
Hmm kann ich irgendwie helfen?
mir ist noch aufgefallen das die Zeilen Angabe nicht immer gleich ist.
Ich bekomme manchmal:
PERL WARNING: Use of uninitialized value $data in substr at ./FHEM/24_TPLinkHS110.pm line 214.
oder
PERL WARNING: Use of uninitialized value $rdata in substr at ./FHEM/24_TPLinkHS110.pm line 162.
oder
PERL WARNING: Use of uninitialized value $data in substr at ./FHEM/24_TPLinkHS110.pm line 116.
ebenfalls denke ich, es hat was mit der Erreichbarkeit der Steckdose zu tun. Ich bin mir nicht ganz sicher. Aber es kann sein das der Fehler erst auftritt, seitdem ich sie an einer anderen Steckdose angesteckt habe. Dort ist der Wlan Empfang nicht sehr gut.
Könnte das die Ursache sein?
Bei mir ist der Empfang immer sehr gut. Fehler tritt aber trotzdem auf.
Mit der alten Version läuft es aber wieder problemlos.
Moin,
mal eine Frage, habe von TP-Link RE270K (Steckdose wie HS100 mit Repeater + LAN Port) würde die auch gerne über FHEM schalten. Hatte die Hoffnung das würde mit deinem Modul klappen....
Einbinden geht auch aber es kommt dann die folgende Meldung:
,,Couldn't connect to 192.168.2.250:9999: IO::Socket::INET: connect: timeout"
Die Steckdose und Reapeater werden auch über die KASA App gesteuert exakt wie die HS100/HS110. Besteht die Chance die auch über das Modul zu steuern?
Was würde ggf. Benötigt das diese eingebaut werden könnte?
Von den HS100/110 nutze ich 9 Stück alle zuverlässig :)
Danke und Gruß
Gerhard
Zitat von: STING333 am 01 Dezember 2018, 20:20:16
Moin,
mal eine Frage, habe von TP-Link RE270K (Steckdose wie HS100 mit Repeater + LAN Port) würde die auch gerne über FHEM schalten. Hatte die Hoffnung das würde mit deinem Modul klappen....
Einbinden geht auch aber es kommt dann die folgende Meldung:
,,Couldn't connect to 192.168.2.250:9999: IO::Socket::INET: connect: timeout"
Die Steckdose und Reapeater werden auch über die KASA App gesteuert exakt wie die HS100/HS110. Besteht die Chance die auch über das Modul zu steuern?
Was würde ggf. Benötigt das diese eingebaut werden könnte?
Von den HS100/110 nutze ich 9 Stück alle zuverlässig :)
Danke und Gruß
Gerhard
Hallo Gerhard,
Hier kannst du den Stand der Dinge nachlesen, was die Entschlüsselung des Protokolls angeht:
https://github.com/plasticrake/tplink-smarthome-api/issues/15
Da hat sich seit einem Jahr nichts getan. Ich sehe die Chancen daher schlecht.
Gruss
Volker
Hallo Volker,
oh danke... wenn ich das richtig sehe würde das Thema ,,geschlossen" kennst du ggf. eine Alternative?
An sich ist es kein Must have..... aber im Smarthome ein Nice to have. Ich hab mir die Steckdose an sich gekauft weil diese das WiFi Siglnal an die LAN Dose weitergibt. Plus die Schaltbare Steckdose.... sowie 2,4 und 5Ghz die Kombination und der Preis haben mir gut gefallen....
Oder hat jemand ggf. Erfahrung mit den neueren Modellen? Nur die sind ja gut doppelt so teuer....
einen schönen 1. Advent
Gerhard
Hallo Volker,
zunächst einmal Danke für deine Arbeit und die Bereitstellung des Moduls!
Leider läuft bei mir etwas nicht ganz rund: Ich betreibe zwei HS100 Steckdosen, eine HW Rev 1 und eine Rev 2.
Während die Rev2 problemlos läuft, habe ich mit der Rev1 vermehrt Ausfälle/Abstürze (Schlatpunkte werden nicht ausgeführt bis hin zum totalen aufhängen der Steckdose)
Im "decode_json" Reading konnte ich vermehr die Fehlermeldung bzgl "malformed json, died in line 471" entdecken.
Ein Blick in den Code und der Verbose Mode 5 offenbarte das Problem: Es werden immer zwei Befehle ausgeführt, einmal das Schalten and sich und danach ein Update des Status. Letzterer liefert bei mir aber sehr oft nur ein leeres reading zurück und bring die Steckdose in einen Rest oder zum hängen:
2018.12.02 15:30:40 3: TPLinkHS110: Umwaelzpumpe Set <on> called
2018.12.02 15:30:41 5: Umwaelzpumpe - Data returned: $VAR1 = '{"system":{"set_relay_state":{"err_code":0}}}';
2018.12.02 15:30:41 5: Umwaelzpumpe - Data returned: $VAR1 = '';
Testweise habe ich den Code angepasst und die 2 Commands durch eine pause von einer Sekunde entzerrt:
if ($json->{'system'}->{'set_relay_state'}->{'err_code'} eq "0") {
#HS100 HW v1.0 is not returning an answer if commands are comming too fast. Hold on for a second
sleep(1);
TPLinkHS110_Get($hash,"");
} else {
return "Command failed!";
}
Das Ergebnis: Ein Stresstest von vielen Schaltdurchgängen wurde endlich ohne Hänger gemeistert:
2018.12.02 16:09:00 3: TPLinkHS110: Umwaelzpumpe Set <on> called
2018.12.02 16:09:00 5: Umwaelzpumpe - Data returned: $VAR1 = '{"system":{"set_relay_state":{"err_code":0}}}';
2018.12.02 16:09:01 5: Umwaelzpumpe - Data returned: $VAR1 = '{"system":{"get_sysinfo":{"err_code":0,"sw_ver":"1.2.5 Build 171213 Rel.101415","hw_ver":"1.0","type":"IOT.SMARTPLUGSWITCH","model":"HS100(EU)","mac":"xxx","deviceId":"xxx","hwId":"xxx","fwId":"00000000000000000000000000000000","oemId":"xxx","alias":"Umwaelzpumpe","dev_name":"Wi-Fi Smart Plug","icon_hash":"","relay_state":1,"on_time":1,"active_mode":"none","feature":"TIM","updating":0,"rssi":-65,"led_off":0,"latitude":0,"longitude":0}}}';
Eine Pause von 0.5 war bei mir noch zu kurz, aber gegebenfalls kann man die Pause, und die ggf. benötigte Zeitspanne über ein Attribut einstellbar machen, bzw eine alternative Art die Commands zu separieren implementieren.
Danke & Gruß,
der Wu
Ich werde sehen, was ich tun kann.
Ich will versuchen zwischen den Jahren den Support für die Bulbs LB100-130 einzubauen.
Da werde ich mich nochmal mit dem Thema Stabilität befassen.
Ich bekomme nach einem Update am 07.12.2018 sporadisch folgende Einträge im Log:
2018.12.07 21:10:48 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/24_TPLinkHS110.pm line 415.
2018.12.07 21:10:48 1: PERL WARNING: substr outside of string at ./FHEM/24_TPLinkHS110.pm line 415.
2018.12.07 21:10:48 1: PERL WARNING: Use of uninitialized value $_[0] in split at ./FHEM/24_TPLinkHS110.pm line 415.
2018.12.07 21:10:48 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2018.12.07 21:14:49 1: PERL WARNING: Use of uninitialized value $json in concatenation (.) or string at ./FHEM/24_TPLinkHS110.pm line 243.
2018.12.07 21:14:49 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
Ergänzend zeigt mir Freezemon fast immer recht lange Laufzeiten:
myFreezemon: possible freeze starting at 11:56:56, delay is 1.723 possibly caused by: tmr-TPLinkHS110_Get(LBE250.Steckdose)
Ich habe:
hw_ver 2.0
sw_ver 1.5.4 Build 180815 Rel.121440
Ergänzend verdächtige ich die Steckdose zum "Einfrieren" von FHEM zu führen. Der Prozess läuft weiter, es wird aber nix mehr geloggt, erst ein Beenden über die Konsole wird wieder protokolliert. Nach dem Neustart läuft's wieder problemlos.
Hat jemand Erfahrungen dazu?
Hi Volker,
auch von mir ein großes Dankeschön, wenns läuft ists eine der günstigsten Leistungsmessungen. Die 7 Lines im Logfile bei Verbose 3 finde ich recht viel, aber mit 2 bei vb2 komm ich klar.
Bislang läufts bei mir auch durch, bei jedem Schaltvorgang hab ich jedoch einen Freeze: Connection lost, trying a reconnect every 5 seconds.
bin ich damit allein?
ciao Carlo
Zu früh gefreut. :(
Jetzt doch wieder ein FHEM-Absturz mit der Meldung:
substr outside of string at ./FHEM/24_TPLinkHS110.pm line 161
Hallo, ich versuche gerade, meine HS100 per define <name> TPLinkHS110 <ip> in fhem einzubinden. Jedes Mal, wenn ich das versuche, stürzt fhem ab. Gespeichert ist dann natürlich nichts. Fhem läuft bei mir auf einem Raspberry 2, Perl ist installiert. Das logfile zeigt mir folgendes vor dem Absturz an:
PERL WARNING: substr outside of string at ./FHEM/24_TPLinkHS110.pm line 328.
2018.12.16 20:55:29 1: PERL WARNING: Use of uninitialized value $_[0] in split at ./FHEM/24_TPLinkHS110.pm line 328.
malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/24_TPLinkHS110.pm line 108
Kann mir da vielleicht jemand helfen?
Viele Grüße, Dennis
Scheinbar häufen sich diese Stabilitätsprobleme.
Ich kann die leider nicht nachvollziehen.
Ich hatte vor zwischen den Jahren nach der Implementierung der lb130 zu schauen.
Da werde ich auch den relevanten Codev anschauen.
Zitat von: klein.michael am 26 Oktober 2018, 20:09:27
Hallo,
ich habe hier seit vorigem Jahr 8 Stück HS110 in Hardware-Version 1.0, Firmware-Version 1.2.5 am laufen. Nun habe ich mir noch zwei weitere gekauft, diese sind Hardware-Version 2.0, Firmware-Version 1.5.4 (device HS110_09 und HS110_10).
Anscheinend sind die angezeigten Werte bei den Hardware-Versionen unterschiedlich (Version 1 in kWatt, Version 2 in Watt). Das hat bei der Anzeige im ersten Moment doch ... naja, eine kurze Panikattacke ob des Verbrauchswertes
verursacht :o ;D
Auszug aus Datenbank, Tabelle "current"
timestamp device reading value unit
2018-10-26 19:38:22 HS110_01 daily_total 11.071
2018-10-26 19:39:21 HS110_02 daily_total 8.426
2018-10-26 19:17:55 HS110_03 daily_total 0.000
2018-10-26 19:41:54 HS110_04 daily_total 2.198
2018-10-26 19:38:05 HS110_05 daily_total 0.000
2018-10-26 19:38:07 HS110_06 daily_total 2.892
2018-10-26 19:39:58 HS110_07 daily_total 4.527
2018-10-26 19:40:01 HS110_08 daily_total 1.867
2018-10-26 19:40:06 HS110_09 daily_total 2285.000
2018-10-26 19:41:24 HS110_10 daily_total 1429.000
Gibt es hier die Möglichkeit einer "Vereinheitlichung" der Einheit oder muss ich hier schlicht und ergreifend bezüglich Anzeige und Auswertung per Hand ran ?
Ich bedanke mich schon im voraus für allfällige Infos und Hinweise :-)
Liebe Grüße aus Österreich
ich hab das skript (neustes vom SVN so geändert) ungefähr bei Linie 220:
my $total=0;
foreach my $key (sort keys @{$json->{'emeter'}->{'get_daystat'}->{'day_list'}}) {
foreach my $key2 ($json->{'emeter'}->{'get_daystat'}->{'day_list'}[$key]) {
if ($hw_ver eq "1.0") {
$total = $total+ $key2->{'energy'};
if ($key2->{'day'} == $mday) {
readingsBulkUpdate($hash, "daily_total", sprintf("%.3f", $key2->{'energy'}));
}
} else {
$total = $total+ $key2->{'energy_wh'};
if ($key2->{'day'} == $mday) {
readingsBulkUpdate($hash, "daily_total", sprintf("%.3f", $key2->{'energy_wh'}*0.001)); }
}
}
}
my $count=1;
$count = @{$json->{'emeter'}->{'get_daystat'}->{'day_list'}};
if ($hw_ver eq "1.0") {readingsBulkUpdate($hash, "monthly_total", $total);}
if ($hw_ver eq "2.0") {readingsBulkUpdate($hash, "monthly_total", $total*0.001);} und dank an Herr Kettenbach für die letzten updates, SVN läuft bei mir Problemlos. Übrigens glaube ich dass die Probleme teilweise von HW ver 2.0 ohne FW update kommen, da ich meine erst nach ein paare Tage updatete und danach erst die Probleme mit einer neueren Modulversion kamen, und mit der alten FW im Auslieferzustand ich keine Probleme hatte... aber ja, das ist anekdotisch :/
Frohe Weihnachten und Guten Rutsch!
Danke für den Code!
Ich will versuchen, den auch einzubauen.
Ich hoffe, ich komme in den nächsten Tagen noch wie versprochen dazu.
Wg. dem Thema Stabilität:
Welche Firmware Version führt denn bei der HW 2.0 (vermutlich) zu den Instabilitäten?
Noch mal der Aufruf: bitte schickt mal Eure HW und SW Versionen mit einem Vermerkt, ob stabil oder nicht!
Bitte einfach die Tabelle im kommenden Post ergänzen!
Und noch mal der Hinweis:
Mir würde es sehr helfen, wenn jeglicher Code zumindest als Patch oder - noch viel besser - als Merge Reuqest über Gitlab eingebracht würde:
https://gitlab.com/volkerkettenbach/FHEM-TPLink-Kasa
Git(Lab) nicht zu verwenden ist, wie wenn Du einen Auto-Motor mit einem Taschenmesser auseinander baust, obwohl neben dran ein Werkzeugwagen mit dem feinsten Spezialwerkzeug steht.
Übersicht der HW und Software Versionen
Produkt | HW | SW | Stabil? | Owner |
HS110 | 1.0 | 1.0.8 Build 151101 Rel.24452 | Ja | VolkerKettenbach |
HS110 | 2.0 | 1.4.3 Build 171009 Rel.104144 | Ja | VolkerKettenbach |
Zitat von: Volker Kettenbach am 30 Dezember 2018, 10:50:23
Übersicht der HW und Software Versionen
Produkt | HW | SW | Stabil? | Owner |
HS110 | 1.0 | 1.0.8 Build 151101 Rel.24452 | Ja | VolkerKettenbach |
HS110 | 2.0 | 1.4.3 Build 171009 Rel.104144 | Ja | VolkerKettenbach |
Produkt | HW | SW | Stabil? | Owner |
HS110 | 1.0 | 1.0.8 Build 151101 Rel.24452 | Ja | VolkerKettenbach |
HS110 | 2.0 | 1.4.3 Build 171009 Rel.104144 | Ja | VolkerKettenbach |
HS110 | 1.0 | 1.1.4 Build ? Rel.? | nein | Johannes Maier |
Produkt | HW | SW | Stabil? | Owner |
HS110 | 1.0 | 1.0.8 Build 151101 Rel.24452 | Ja | VolkerKettenbach |
HS110 | 2.0 | 1.4.3 Build 171009 Rel.104144 | Ja | VolkerKettenbach |
HS110 | 1.0 | 1.1.4 Build ? Rel.? | nein | Johannes Maier |
HS110 | 1.0 | 1.2.5 Build 171213 Rel.101523 | ja | BM030 |
Produkt | HW | SW | Cloud | Stabil? | Owner |
HS110 | 1.0 | 1.0.8 Build 151101 Rel.24452 | Nein | Ja | VolkerKettenbach |
HS110 | 2.0 | 1.4.3 Build 171009 Rel.104144 | Nein | Ja | VolkerKettenbach |
HS110 | 1.0 | 1.1.4 Build ? Rel.? | ? | nein | Johannes Maier (delta8585) |
HS110 | 1.0 | 1.2.5 Build 171213 Rel.101523 | ? | ja | BM030 |
Produkt | HW | SW | Cloud | Stabil? | Owner |
HS110 | 1.0 | 1.0.8 Build 151101 Rel.24452 | Nein | Ja | VolkerKettenbach |
HS110 | 2.0 | 1.4.3 Build 171009 Rel.104144 | Nein | Ja | VolkerKettenbach |
HS110 | 1.0 | 1.1.4 Build ? Rel.? | ? | nein | Johannes Maier (delta8585) |
HS110 | 1.0 | 1.2.5 Build 171213 Rel.101523 | nein | ja | BM030 |
Produkt | HW | SW | Cloud | Stabil? | Owner |
HS110 | 1.0 | 1.0.8 Build 151101 Rel.24452 | Nein | Ja | VolkerKettenbach |
HS110 | 2.0 | 1.4.3 Build 171009 Rel.104144 | Nein | Ja | VolkerKettenbach |
HS110 | 1.0 | 1.1.4 Build ? Rel.? | ? | nein | Johannes Maier (delta8585) |
HS110 | 1.0 | 1.2.5 Build 171213 Rel.101523 | nein | ja | BM030 |
HS110 | 2.0 | 1.5.4 Build 180815 Rel.121440 | ? | nein | TheTrumpeter |
Irgendwelche Neuigkeiten dazu?
Ich habe weiterhin ein paar solcher Logfile-Einträge pro Tag:
2019.02.13 19:31:25 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2019.02.13 19:34:27 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
2019.02.13 19:44:28 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
2019.02.13 19:53:28 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
2019.02.13 20:00:28 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2019.02.13 20:16:28 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2019.02.13 22:27:35 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2019.02.14 06:04:09 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2019.02.14 19:55:49 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
2019.02.14 19:57:49 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
2019.02.14 20:33:48 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2019.02.15 06:05:18 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2019.02.16 19:16:13 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2019.02.17 19:26:27 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2019.02.17 20:39:32 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
2019.02.17 20:41:32 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
2019.02.17 20:54:32 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
2019.02.17 22:08:37 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
2019.02.17 22:50:39 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
2019.02.17 23:06:38 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2019.02.18 21:24:51 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
2019.02.18 21:34:50 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2019.02.18 21:35:50 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2019.02.19 05:58:17 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
2019.02.19 06:17:18 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime data
Schließe mich TheTrumpeter an. Diese Meldungen gibt es immer wieder. Ich möchte deswegen aber ungern den verbose level 0 einstellen. Vielleicht gibt es ja auch ein paar sinnvolle Meldungen die man lesen sollte. ;)
Ich wage zu behaupten dass frühere Versionen des Moduls dieses Problem in dieser Form nicht hatten, kann mich aber auch täuschen.
LG,
Heiko
Ich denke, dass es nicht frühere Versionen des Moduls waren, sondern frühere Versionen der Firmware.
Wie man an der Tabelle sieht, wird diese ja eifrig upgedatet.
Bei mir aber nicht, da ich meine Steckdosen nicht in der Cloud habe.
Ich selbst kann da wenig machen, da ich die Probleme nicht nachvollziehen kann. Und auch derzeit keine Zeit habe. Vlt. im Laufe des Jahres mal.
Hi - ich kann Volker da bestätigen: Meiner Meinung nach ist es ein Problem der Firmware in Verbindung mit einer stark genutzten Wlan Umgebung.
Ich habe 4 HS110 (1 x Version 1 / 3 x Version V3 (bzw. V2 laut App)). Leider haben alle 3 V3 Versionen massive Probleme (Die V1 gar nicht). Die HS110 sind alle im gleichen Raum im Umkreis von ca 3m.
Ich hatte auch Kontakt mir TP-Link - aber leider können (bzw. wollen) die nicht wirklich helfen.
Ich habe nun über Wochen hinweg diverses ausprobiert (Wlan Kanal geändert, Wlan Sendeleistung auf 100% / 50%, Reset der HS110 , Firewall offen für die Dosen oder mal nur der Zeitserver pool.org ...) Leider hat alles keine Besserung gebracht.
Dann habe ich in meinem Router (Fritz 7490) die An- und Abmeldeversuche protokollieren lassen und habe festgestellt, dass sich die V3 Versionen sich alle 5 Minuten (mal alle Stunde) ab und wieder neu anmelden! Leider habe ich in meiner Umgebung (Mehrfamilienhaus) ca. 60-70 Wlan-Funknetze. Auch wenn man das nicht unbedingt machen sollte: Ich habe testweise auf Kanal 13 gewechselt und siehe da: Seit dem haben sich die Wlan Ab - und Anmeldungen auf ein Minimum reduziert (ca. 4-20 am Tag, von vorher ca. 50-80)! Und damit auch die Meldungen in FHEM!
Ich vermute dies hängt direkt mit den Meldungen in FHEM zusammen - wenn die HS110 gerade nicht erreichbar ist, dann klappt der decode JSON halt nicht und es kommt zu den oben genannten Meldungen (Timeout).
Ich hoffe auf ein baldiges Firmware-Update (in der Hoffnung, das dies dann auch eine stabile Version sein wird - ansonsten würde ich mich über eine PM freuen, falls noch jemand die V1.4.3 als *.bin file rumliegen hat.
Wer also diese Probleme hat, sollte auf jeden Fall mal die An- und Abmeldungen protokollieren und ggf. auf einen ,,exotsichen" Kanal wechseln und weiter beobachten.
@Volker: Wäre aber trotzdem schön, wenn du bei Gelegenheit mal die von chani666 genannten Zeilen anpassen könntest (dann muß nicht nach jedem Update die Sicherung ,,24_TPLINKHS110.pm" zurückgespielt werden)
Danke & schöne Grüße
Steff
Hallo steff555,
danke für die systematische Analyse.
Ich kann von meiner Seite bestätigen, dass meine HS110 mit alter (also die zum Kaufzeitpunkt) Firmware (kein Update über Cloud möglich, da nicht in Cloud angemeldet) i.d.R. keine Reconnects zum WLAN machen sondern dauerhaft connected sind. Folglich machen Sie auch keine Probleme mit FHEM. Meine WLAN Umgebung würde ich eher als ruhig bezeichnen und der Empfang der Geräte ist gut, da sie immer recht nah (wenige Meter) von einem Access-Point entfernt sind.
Sorry, den Code von chani666 hatte ich übersehen. Ich kann hier nur immer wieder darauf hinweisen, dass ein Merge Request oder zumindest in Issue auf https://gitlab.com/volkerkettenbach/FHEM-TPLink-Kasa der wesentlich bessere Weg ist, Code bei zu tragen.
Ich habe den Code von chani666 gerade eingebaut und ins Gitlab gepushed: https://gitlab.com/volkerkettenbach/FHEM-TPLink-Kasa
Das FHEM-SVN sollte meiner Kenntnis nach morgen das aktuelle Modul haben.
Gruß
Volker
Hallo Leute,
bin noch etwas neu in FHEM aber habe soweit fast alles in meinem Zuhause zum Laufen gebracht bis auf meine LB130 Lampe. Ich kriege mit dem Modul meine LB130 nicht geschaltet. Es kommt immer ein trockenes "command failed" wenn ich die Lampe schalten möchte. Log und Event Monitor enthalten dabei zu dem Ereigniss keine Meldungen dazu. Readings werden aber angezeigt. Readings unten.
Würde mich sehr freuen wenn mir jemand einen Lösungsansatz hätte.
LG Dmitri
Readings
active_mode
none
2019-04-06 11:56:37
alias
Lampa
2019-04-06 11:56:37
ctrl_protocols
HASH(0x2badfc0)
2019-04-06 11:56:37
decode_json
ok
2019-04-06 11:57:01
description
Smart Wi-Fi LED Bulb with Color Changing
2019-04-06 11:56:37
dev_state
normal
2019-04-06 11:56:37
deviceId
8012119C2E94CB91425852F39B34075D18E08E7A
2019-04-06 11:56:37
disco_ver
1.0
2019-04-06 11:56:37
err_code
0
2019-04-06 11:56:37
heapsize
315384
2019-04-06 11:56:37
hwId
111E35908497A05512E259BB76801E10
2019-04-06 11:56:37
hw_ver
1.0
2019-04-06 11:56:37
is_color
1
2019-04-06 11:56:37
is_dimmable
1
2019-04-06 11:56:37
is_factory
false
2019-04-06 11:56:37
is_variable_color_temp
1
2019-04-06 11:56:37
light_state
HASH(0x2ba3f70)
2019-04-06 11:56:37
mic_mac
704F5705054D
2019-04-06 11:56:37
mic_type
IOT.SMARTBULB
2019-04-06 11:56:37
model
LB130(EU)
2019-04-06 11:56:37
oemId
D5C424D3C480911C980ECDD56C27988F
2019-04-06 11:56:37
preferred_state
ARRAY(0x15f1438)
2019-04-06 11:56:37
rssi
-62
2019-04-06 11:56:37
state
off
2019-04-06 11:56:37
sw_ver
1.8.6 Build 180809 Rel.091659
2019-04-06 11:56:37
Die lb130 wird bisher nicht unterstützt.
okay. Danke
Moin, hab meine HS110 eben über die App ins WLAN gebracht und in fhem eingebunden. Wie kann ich Updates verhindern an der Dose bzw Cloud Sperren? Über die Firewall oder gibt's eine andere Lösung?
Gruß
Zitat von: Xell1984 am 19 April 2019, 13:46:13
Über die Firewall oder gibt's eine andere Lösung?
Ich hab's einfach in der Fritz.Box verboten.
Zitat von: Xell1984 am 19 April 2019, 13:46:13
Moin, hab meine HS110 eben über die App ins WLAN gebracht und in fhem eingebunden. Wie kann ich Updates verhindern an der Dose bzw Cloud Sperren? Über die Firewall oder gibt's eine andere Lösung?
Gruß
Ich habe mich nicht an der cloud angemeldet.
Vielleicht für manche interessant:
Die HS110 gibt's heute im Doppelpack bei iBood um EUR 39,95 zzgl. Versand: https://www.ibood.com/electronics-at/de/product-specs/48688/196408/2-x-tp-link-hs110-wifi-smart-plug.html
Nachdem mein zweiter TPLink auch ein HS110 mit neuerer Hardware (und firmware version) ist, habe ich leider auch regelmässige Probleme. Schaltfunktionen laufen problemlos, aber regelmässige Freezes, die nach meinem bisherigen Verständnis auf die TPLinks zurückzuführen sind.
Laut Readings:
sw_ver 1.5.4 Build 180815 Rel.121440
hw_ver 2.0
Vermutung, diese treten beim normalerweise alle 5-minuten laufenden timergesteuerten ..._get auf, aber auch bei jedem aus FHEM initierten Schaltvorgang auf.
Wenn ich es im Thread richtig verstanden habe, gibt es dafür bisher keine Lösung?
Leider richtig.
Ich kann die Probleme nicht nachvollziehen, da meine Steckdosen alle älter sind und die Firmware nicht aktualisiert wird.
Hallo
Ich habe aktuell fünf HS110. Bei vier von den fünf habe ich das Problem das die daily und monthly Werte nicht mehr aktualisiert werden.
Nach dem was ich in meinem Log sehe seit dem ersten April. Bzw. seit der letzten Firmwareaktualisierung und dem darauf folgenden Monatswechsel.
List von dem Einen der noch funktioniert:
Internals:
CFGFN /var/fhem/FHEM/KG_Badezimmer.cfg
DEF 192.168.6.145
FUUID 5c46c494-f33f-a5a6-a713-0d1daee70282dd5d
HOST 192.168.6.145
INTERVAL 300
NAME KG_BZ_Trockner
NEXTUPDATE Mon May 20 13:10:31 2019
NR 764
STATE on
TIMEOUT 1
TYPE TPLinkHS110
Helper:
DBLOG:
monthly_total:
mylogdb:
TIME 1558349132.81315
VALUE 15.784
power:
mylogdb:
TIME 1558350332.84528
VALUE 0.308
state:
mylogdb:
TIME 1558349132.81315
VALUE on
READINGS:
2019-05-20 13:05:31 active_mode none
2019-05-20 13:05:31 alias KG_BZ_Trockner
2019-05-20 13:05:31 current 0.038
2019-05-20 13:05:31 daily_average 789.2
2019-05-20 13:05:31 daily_total 0.003
2019-05-20 13:05:31 decode_json ok
2019-05-20 13:05:31 dev_name Smart Wi-Fi Plug With Energy Monitoring
2019-05-20 13:05:31 deviceId 8006DAD6044104540C433830515A51681AA795E0
2019-05-20 13:05:31 err_code 0
2019-05-20 13:05:31 feature TIM:ENE
2019-05-20 13:05:31 fwId 00000000000000000000000000000000
2019-05-20 13:05:31 hwId 044A516EE63C875F9458DA25C2CCC5A0
2019-05-20 13:05:31 hw_ver 2.0
2019-05-20 13:05:31 icon_hash
2019-05-20 13:05:31 latitude 51.4532
2019-05-20 13:05:31 led_off 0
2019-05-20 13:05:31 longitude 7.4875
2019-05-20 13:05:31 mac 0C:80:63:DD:63:97
2019-05-20 13:05:31 model HS110(EU)
2019-05-20 13:05:31 monthly_total 15.784
2019-05-20 13:05:31 next_action HASH(0x67756b4)
2019-05-20 13:05:31 oemId 1998A14DAA86E4E001FD7CAF42868B5E
2019-05-20 13:05:31 on_time 1898318
2019-05-20 13:05:31 power 0.308
2019-05-20 13:05:31 relay_state 1
2019-05-20 13:05:31 rssi -87
2019-05-20 13:05:31 state on
2019-05-20 13:05:31 sw_ver 1.5.4 Build 180815 Rel.121440
2019-05-20 13:05:31 total 19.166
2019-05-20 13:05:31 type IOT.SMARTPLUGSWITCH
2019-05-20 13:05:31 updating 0
2019-05-20 13:05:31 voltage 223.79
Attributes:
disable 0
event-min-interval monthly_total:1800,power:1800,state:1800
event-on-change-reading monthly_total,power,state
interval 300
room Keller->Badezimmer
verbose 0
List von einem der nicht mehr funktioniert:
Internals:
CFGFN /var/fhem/FHEM/KG_Badezimmer.cfg
CHANGED
DEF 192.168.6.144
FUUID 5c46c496-f33f-a5a6-79d4-2a0cd00419275a01
HOST 192.168.6.144
INTERVAL 300
NAME KG_BZ_Waschmaschine
NEXTUPDATE Mon May 20 13:10:33 2019
NIGHTMODE off
NR 768
STATE on
TIMEOUT 1
TYPE TPLinkHS110
Helper:
DBLOG:
monthly_total:
mylogdb:
TIME 1558350035.91618
VALUE 0
power:
mylogdb:
TIME 1558350035.91618
VALUE 0
state:
mylogdb:
TIME 1558350035.91618
VALUE on
READINGS:
2019-05-20 13:05:34 active_mode none
2019-05-20 13:05:34 alias KG_BZ_Waschmaschine
2019-05-20 13:05:34 current 0.049
2019-05-20 13:05:34 decode_json ok
2019-05-20 13:05:34 dev_name Smart Wi-Fi Plug With Energy Monitoring
2019-05-20 13:05:34 deviceId 800686FE2560C35F95A68FAB4632B8C01A090A10
2019-05-20 13:05:34 err_code 0
2019-05-20 13:05:34 feature TIM:ENE
2019-05-20 13:05:34 fwId 00000000000000000000000000000000
2019-05-20 13:05:34 hwId 044A516EE63C875F9458DA25C2CCC5A0
2019-05-20 13:05:34 hw_ver 2.0
2019-05-20 13:05:34 icon_hash
2019-05-20 13:05:34 latitude 51.4532
2019-05-20 13:05:34 led_off 0
2019-05-20 13:05:34 longitude 7.4875
2019-05-20 13:05:34 mac AC:84:C6:65:A5:CD
2019-05-20 13:05:34 model HS110(EU)
2019-05-20 13:05:34 monthly_total 0
2019-05-20 13:05:34 next_action HASH(0x6c5bc6c)
2019-05-20 13:05:34 oemId 1998A14DAA86E4E001FD7CAF42868B5E
2019-05-20 13:05:34 on_time 1897846
2019-05-20 13:05:34 power 0
2019-05-20 13:05:34 relay_state 1
2019-05-20 13:05:34 rssi -78
2019-05-20 13:05:34 state on
2019-05-20 13:05:34 sw_ver 1.5.4 Build 180815 Rel.121440
2019-05-20 13:05:34 total 8.397
2019-05-20 13:05:34 type IOT.SMARTPLUGSWITCH
2019-05-20 13:05:34 updating 0
2019-05-20 13:05:34 voltage 223.668
Attributes:
disable 0
event-min-interval monthly_total:1800,power:1800,state:1800
event-on-change-reading monthly_total,power,state
interval 300
nightmode off
room Keller->Badezimmer
verbose 0
Angeblich sind HW und SW Version gleich.
Was mir aufgefallen ist ist das der Anfang der MAC Adresse bei den nicht funktionierenden anders ist als bei dem der funktioniert.
Der Funktionierende hat eine 0C:80:63 und alle Anderen eine AC:84:C6.
Auch in der KASA App werden keine Statistikwerte mehr angezeigt. Dort wird auch lediglich die aktuelle Leistungsaufnamhme angezeigt.
Ich gehe daher nicht von einem Fehler im Fhem Modul aus.
Hat noch jemand das Problem oder weis vielleicht sogar wie ich es beheben kann?
Gruß
Daniel
Zitat von: Volker Kettenbach am 20 Mai 2019, 07:46:17
Leider richtig.
Ich kann die Probleme nicht nachvollziehen, da meine Steckdosen alle älter sind und die Firmware nicht aktualisiert wird.
Ich kann Dir gerne eine neue Version zur Verfügung stellen.
Inzwischen habe ich aber auch etwas in den Code reingeschaut, grundsätzlich sind die Verbindungsaufbauten im _get ja blockierend, so dass der freeze erklärbar ist. bei den 110er werden ja eigentlich 3 requests gemacht (status, realtime data, daystats), jeder davon braucht etwas Zeit zum Verbindungsaufbau und hat ein Read timeout von 0.5 sek --> also sagen wir mal jeweils 0.6 s --> das entspricht ziemlich genau den 1.8s freezes bei mir.
Kann es also sein, dass die alte Firmware direkt nach dem Datentransfer den Socket zumacht --> kaum Verzögerung, während die neue Firmware daten sendet aber eben die Verbindung nicht schliesst?
Da das Format ja in den ersten 4 Bytes die Länge der Daten versendet, ist das vermutlich auch bei der Antwort so. Damit sollte es möglich sein erst die 4 Bytes zu lesen und dann danach genau soviele Bytes zu lesen wie zu erwarten sind und nicht auf das Timeout zu warten.
Ich habe dazu noch keine Experimente gemacht, aber vielleicht löst das zumindest das timeout/freeze problem?
Ich habe mal eine Testversion erstellt, die beim set und get nur soviele Daten liest, wie benötigt wird.
Bei mir scheint das soweit zu funktionieren und ich habe bisher auch keine freezes mehr gesehen. Möchte das noch jemand anders ausprobieren?
EDIT: 22.5. - Update mit Fehlerbehebung für Realtimedata und Statistik
EDIT: 27.5 - Update für Unterstützung auch längerer Datenmengen
Da bei mir auch bei eine von 5 identen HS110 die Log-Einträge erzeugte, habe ich mal die neue Version aus dem vorherigen Post ausprobiert. Fehler ist weg, bis jetzt keinerlei Auffälligkeiten.
Danke - und *daumengedrückthalten*!
Zitat von: viegener am 21 Mai 2019, 20:55:31
Ich habe mal eine Testversion erstellt, die beim set und get nur soviele Daten liest, wie benötigt wird.
Bei mir scheint das soweit zu funktionieren und ich habe bisher auch keine freezes mehr gesehen. Möchte das noch jemand anders ausprobieren?
Hattest Du davor auch die folgenden Fehler?
2019.05.20 21:50:12 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/24_TPLinkHS110.pm line 415.
2019.05.20 21:50:12 1: PERL WARNING: substr outside of string at ./FHEM/24_TPLinkHS110.pm line 415.
2019.05.20 21:50:12 1: PERL WARNING: Use of uninitialized value $_[0] in split at ./FHEM/24_TPLinkHS110.pm line 415.
2019.05.22 06:12:57 1: PERL WARNING: Use of uninitialized value $json in concatenation (.) or string at ./FHEM/24_TPLinkHS110.pm line 243.
2019.05.22 06:12:57 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
2019.05.22 06:44:58 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime dat
Zitat von: TheTrumpeter am 22 Mai 2019, 07:25:31
Hattest Du davor auch die folgenden Fehler?
2019.05.20 21:50:12 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/24_TPLinkHS110.pm line 415.
2019.05.20 21:50:12 1: PERL WARNING: substr outside of string at ./FHEM/24_TPLinkHS110.pm line 415.
2019.05.20 21:50:12 1: PERL WARNING: Use of uninitialized value $_[0] in split at ./FHEM/24_TPLinkHS110.pm line 415.
2019.05.22 06:12:57 1: PERL WARNING: Use of uninitialized value $json in concatenation (.) or string at ./FHEM/24_TPLinkHS110.pm line 243.
2019.05.22 06:12:57 1: TPLinkHS110: LBE250.Steckdose Error updating daystat. Success: 0, json:
2019.05.22 06:44:58 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime dat
Nein ich hatte andere Meldungen --> das hängt aber vielleicht auch damit zusammen, das die Fehlermeldungen von Dir nicht zur aktuellen Version des Moduls in FHEM passt. Hast Du mal ein update gemacht?
Generell sollten auch ähnliche Fehler nicht mehr auftreten, ich habe dazu nochmal eine aktualisierte Version oben eingespielt, da ist auch ein Fehler ausgemerzt.
Zitat von: viegener am 22 Mai 2019, 14:32:22
Nein ich hatte andere Meldungen --> das hängt aber vielleicht auch damit zusammen, das die Fehlermeldungen von Dir nicht zur aktuellen Version des Moduls in FHEM passt. Hast Du mal ein update gemacht?
Habe ich gestern Abend dann gemacht, heut' ist schon wieder so ein Eintrag da:
2019.05.23 06:35:37 1: TPLinkHS110: LBE250.Steckdose: Received zero bytes of realtime data. Cannot process realtime dataZitat von: viegener am 22 Mai 2019, 14:32:22
Generell sollten auch ähnliche Fehler nicht mehr auftreten, ich habe dazu nochmal eine aktualisierte Version oben eingespielt, da ist auch ein Fehler ausgemerzt.
Werd' ich mal ausprobieren...
Zitat von: WhyTea am 20 Mai 2019, 13:33:52
Hallo
Ich habe aktuell fünf HS110. Bei vier von den fünf habe ich das Problem das die daily und monthly Werte nicht mehr aktualisiert werden.
Nach dem was ich in meinem Log sehe seit dem ersten April. Bzw. seit der letzten Firmwareaktualisierung und dem darauf folgenden Monatswechsel.
...
Hat noch jemand das Problem oder weis vielleicht sogar wie ich es beheben kann?
Inzwischen habe ich selbst die Lösung gefunden. Danke für die Hilfe.
Für alle die das Gleiche oder ein ähnliches Problem haben...
Man muss die betreffenden HS110 in Werkseinstellung zurücksetzen (RESET-Knopf am Gerät 20 Sek. gedrückt halten) und per KASA-App komplett neu einrichten.
Gruß
Daniel
@Volker Kettenbach: Macht es Sinn die Änderungen in die offizielle Version zu übernehmen?
Ich habe die aktuellste Version hier hinterlegt: https://forum.fhem.de/index.php/topic,57068.msg942121.html#msg942121 (https://forum.fhem.de/index.php/topic,57068.msg942121.html#msg942121)
Grundsätzlich schon.
Ich habe mal kurz den Code angeschaut und bin selbst ein bisschen raus aus dem Thema.
Wenn ich das richtig sehe, dann hast Du:
- den Code für das viermalige Abrufen in eine Methode gepackt (=> don't repeat yourself)
- Du liest am Anfang 4 Bytes und dann ermittelst damit die länge des Pakets und liest dann genau dieses Länge - richtig!?
Bisher hatte ich mit der aktuellen Version immer das Problem, das nach einigen Tagen FHEM abgestürzt ist.
Eine ältere Version läuft hingegen.
Seit ca. einer Woche habe ich die obige Version im Einsatz.
Hiermit bisher keine Probleme.
Zitat von: Volker Kettenbach am 29 Mai 2019, 17:21:01
Grundsätzlich schon.
Ich habe mal kurz den Code angeschaut und bin selbst ein bisschen raus aus dem Thema.
Wenn ich das richtig sehe, dann hast Du:
- den Code für das viermalige Abrufen in eine Methode gepackt (=> don't repeat yourself)
- Du liest am Anfang 4 Bytes und dann ermittelst damit die länge des Pakets und liest dann genau dieses Länge - richtig!?
Ja, genau, das sind die wesentlichen Änderungen. Beim Abrufenhabe ich noch einen Teil eingebaut, der weiter vom Socket liest, wenn die Daten in mehreren Abschnitten kommen (bei mir kamen zum Beispiel im ersten Schritt maximal 1024 Bytes an).
Okay, ich werde die Änderungen checken und in die offizielle Version einbauen.
Ich habe übrigens jetzt eine HW Version und stelle fest, dass die sich in der Tat anders verhält als die Version 1.
Insbesondere dauert das Abrufen der Daten mit der alten Version des Moduls deutlich länger.
Mit der Version 1 und der Originalfirmware geht es vollkommen ohne Verzögerung.
Die Version 2 legt immer ca. 3-4 "Gedenksekunden" ein, während denen FHEM blockiert ist.
So, der Patch ist gemerged und im Master-Branch vorhanden:
https://gitlab.com/volkerkettenbach/FHEM-TPLink-Kasa
Am SVN bin ich dran. Habe da gerade Probleme mit dem Zugriff.
Neues Modul ist auch jetzt im SVN.
Seit dem Update haben sich die Fehlermeldungen verändert, weg sind sie nicht:
2019.06.16 18:14:04 1: TPLinkHS110: LBE250.Steckdose Get failed - Couldn't connect to 10.0.0.16:9999: IO::Socket::INET: connect: timeout
2019.06.16 20:11:11 1: TPLinkHS110: LBE250.Steckdose Get daily stats failed - Couldn't connect to 10.0.0.16:9999: IO::Socket::INET: connect: timeout
Die Meldungen kommen mal sporadisch, mal im Minutentakt.
Zitat von: STING333 am 01 Dezember 2018, 20:20:16
Moin,
mal eine Frage, habe von TP-Link RE270K (Steckdose wie HS100 mit Repeater + LAN Port) würde die auch gerne über FHEM schalten. Hatte die Hoffnung das würde mit deinem Modul klappen....
Einbinden geht auch aber es kommt dann die folgende Meldung:
,,Couldn't connect to 192.168.2.250:9999: IO::Socket::INET: connect: timeout"
...
Ich habe bei mir die gleiche Situation. Das tritt bei mir nach einem Neustart von FHEM auf. Erst nachdem ich einmal mit der Kasa App (bei mir iOS) die Steckdose getoggelt habe, kann ich sie auch über FHEM steuern. Warum das so ist weiss ich leider auch nicht.
Meine Versionen:
HS110:
hw_ver: 1.0
sw_ver: 1.1.4 Build 170417 Rel.145118
TPlinkHS110 Modul:
Latest Revision: 19661
24_TPLinkHS110.pm 19532 2019-06-02 06:38:05Z vk
Übrigens erhält man ziemlich viele Logausgaben bei verbose/loglevel 3 im Log, alle 5 Minuten by default:
...
2019.06.01 00:15:09 3: TPLinkHS110: CouchLicht Get called. Relay state: 1, RSSI: -73
2019.06.01 00:15:10 2: TPLinkHS110: CouchLicht Realtime data updated
2019.06.01 00:15:10 3: TPLinkHS110: CouchLicht Device is an HS110. Got extra realtime data: 10.121952 Watt, 234.379034 Volt, 0.078238 Ampere
2019.06.01 00:15:10 3: TPLinkHS110: CouchLicht Updating daystat. Data: {"emeter":{"get_daystat":{"day_list":[{"year":2019,"month":6,"day":1,"energy":0.003000}],"err_code":0}}}
2019.06.01 00:15:10 2: TPLinkHS110: CouchLicht Daystat updated
2019.06.01 00:15:10 3: TPLinkHS110: CouchLicht Updating readings
2019.06.01 00:15:10 3: TPLinkHS110: CouchLicht Get end
2019.06.01 00:20:09 3: TPLinkHS110: CouchLicht Get called. Relay state: 1, RSSI: -73
2019.06.01 00:20:10 2: TPLinkHS110: CouchLicht Realtime data updated
2019.06.01 00:20:10 3: TPLinkHS110: CouchLicht Device is an HS110. Got extra realtime data: 10.338583 Watt, 237.788829 Volt, 0.079619 Ampere
2019.06.01 00:20:10 3: TPLinkHS110: CouchLicht Updating daystat. Data: {"emeter":{"get_daystat":{"day_list":[{"year":2019,"month":6,"day":1,"energy":0.004000}],"err_code":0}}}
2019.06.01 00:20:10 2: TPLinkHS110: CouchLicht Daystat updated
2019.06.01 00:20:10 3: TPLinkHS110: CouchLicht Updating readings
2019.06.01 00:20:10 3: TPLinkHS110: CouchLicht Get end
...
Ich denke da könnte man einige Zeilen auf Loglevel 4 oder sogar 5 setzen.
Hallo,
ich habe mehrere HS110 im Einsatz und soweit funktioniert alles wunderbar.
Außer, wenn ich mal einen HS110 aus der Steckdose ziehe oder einer sonstwie W-Lan-Offline ist!
Habe diesen Fall mit PRESENCE abgefangen und setzte, wenn absent, den entsprechenden HS110 auf disable=1 und vergrößere das Intervall für den PING-Test. Das funktioniert.
Wenn der HS110 aber wieder online ist, setzt PRESENCE das Gerät wieder auf disable=0. Das funktioniert, aber die Readings-Abfrage starten nicht mehr automatisch. Erst wenn ich auf den Anzeigetext im WEB-Fenster klicke oder das Relai schalte werden die Readings wieder kontinuierlich aktualisiert.
(Ich weiß nicht, wie man an dieser Stelle einen Screenshot einfügen kann...)
Das Problem müsste doch eigentlich bekannt sein, ich finde im Netz aber keine Lösung. Die Readings-Abfrage soll wieder aktiviert werden ohne Benutzereingriff.
Ein fhem ('trigger WEB JS:location.reload(true)'); hilft nicht, die Readings bleiben unverändert.
Der Parameter (set) NEXTUPDATE:Tue Jul 2 07:30:35 2019 ist und bleibt hinter dem aktuellen Datum und ich weiß nicht, wie ich ihn ändern könnte.
Bei disable=1 ändert sich die Textfarbe im WEB-Fenster von rot auf schwarz und bei disable=0 wieder von schwarz auf rot, aber die Readings ändern sich nicht.
Kann mir da jemand weiter helfen?
Viele Grüße
Zitat von: Pauline am 02 Juli 2019, 07:42:08
Hallo,
ich habe mehrere HS110 im Einsatz und soweit funktioniert alles wunderbar.
Außer, wenn ich mal einen HS110 aus der Steckdose ziehe oder einer sonstwie W-Lan-Offline ist!
Habe diesen Fall mit PRESENCE abgefangen und setzte, wenn absent, den entsprechenden HS110 auf disable=1 und vergrößere das Intervall für den PING-Test. Das funktioniert.
Wenn der HS110 aber wieder online ist, setzt PRESENCE das Gerät wieder auf disable=0. Das funktioniert, aber die Readings-Abfrage starten nicht mehr automatisch. Erst wenn ich auf den Anzeigetext im WEB-Fenster klicke oder das Relai schalte werden die Readings wieder kontinuierlich aktualisiert.
(Ich weiß nicht, wie man an dieser Stelle einen Screenshot einfügen kann...)
Das Problem müsste doch eigentlich bekannt sein, ich finde im Netz aber keine Lösung. Die Readings-Abfrage soll wieder aktiviert werden ohne Benutzereingriff.
Ein fhem ('trigger WEB JS:location.reload(true)'); hilft nicht, die Readings bleiben unverändert.
Der Parameter (set) NEXTUPDATE:Tue Jul 2 07:30:35 2019 ist und bleibt hinter dem aktuellen Datum und ich weiß nicht, wie ich ihn ändern könnte.
Bei disable=1 ändert sich die Textfarbe im WEB-Fenster von rot auf schwarz und bei disable=0 wieder von schwarz auf rot, aber die Readings ändern sich nicht.
Kann mir da jemand weiter helfen?
Viele Grüße
Das Problem ist einfach, dass im Code bei einem disable=0 die regelmässigen Anfragen nicht wieder automatisch starten.
Ich denke ein möglicher Workaround wäre NACH dem Setzen von "disable=0" noch ein
get auf dem TPLink device auszuführen, damit sollte auch der automatische Zyklus von updates wieder getriggert
Zitat von: TheTrumpeter am 16 Juni 2019, 20:18:59
Seit dem Update haben sich die Fehlermeldungen verändert, weg sind sie nicht:
2019.06.16 18:14:04 1: TPLinkHS110: LBE250.Steckdose Get failed - Couldn't connect to 10.0.0.16:9999: IO::Socket::INET: connect: timeout
2019.06.16 20:11:11 1: TPLinkHS110: LBE250.Steckdose Get daily stats failed - Couldn't connect to 10.0.0.16:9999: IO::Socket::INET: connect: timeout
Die Meldungen kommen mal sporadisch, mal im Minutentakt.
Hallo zusammen,
ich habe die gleichen Fehlermeldungen. Bisher ist FHEM aber nicht (wie zuvor) komplett abgestürzt. Läuft denn bei jemandem mittlerweile die HS110
Version 2 stabil (also mehrere Tage oder gar Wochen) ?
Viele Grüße
Hatte vorher auch alle paar Tage einen Absturz.
Mit der aktuellen Version seit ca. 3 Wochen kein Absturz und keine Fehlermeldungen.
Danke, das macht mir Mut !
Zitat von: TheTrumpeter am 16 Juni 2019, 20:18:59
Seit dem Update haben sich die Fehlermeldungen verändert, weg sind sie nicht:
2019.06.16 18:14:04 1: TPLinkHS110: LBE250.Steckdose Get failed - Couldn't connect to 10.0.0.16:9999: IO::Socket::INET: connect: timeout
2019.06.16 20:11:11 1: TPLinkHS110: LBE250.Steckdose Get daily stats failed - Couldn't connect to 10.0.0.16:9999: IO::Socket::INET: connect: timeout
Die Meldungen kommen mal sporadisch, mal im Minutentakt.
ich habe jetzt mal unabsichtlich für ein paar Tage eine meiner V2-Steckdosen vom Netz getrennt gehabt und bekomme dieselben Fehlermeldungen - ganz wie zu erwarten. Beim Wiederverbinden mit dem Strom hat sich das sofort gegeben.
Wenn die Fehlermeldungen stören - müsste man per presence das Gerät dann wirklich deaktivieren - wie oben gesagt aber mindestens einmal den get beim Aktivieren wieder einfügen.
Also Fazit:
- Die Fehlermeldungen bei Verbindungsproblemen sind aus meiner Sicht völlig richtig
- Durch etwas Aufwand (presence/notify) lässt sich das aber auch lösen
Wunschliste:
- Automatisches Aktivieren der Abfrage beim enable
- Eingebauter Präsentstatus, der das im Device auch anzeigt (wie bei anderen Geräten ebenfalls)
Zitat von: viegener am 08 Juli 2019, 16:57:32
ich habe jetzt mal unabsichtlich für ein paar Tage eine meiner V2-Steckdosen vom Netz getrennt gehabt und bekomme dieselben Fehlermeldungen - ganz wie zu erwarten. Beim Wiederverbinden mit dem Strom hat sich das sofort gegeben.
Mit dem Unterschied, dass die Steckdose bei mir nicht vom Netz getrennt ist, sondern ständig eingesteckt und auch eingeschaltet ist.
Zitat von: TheTrumpeter am 09 Juli 2019, 06:39:18
Mit dem Unterschied, dass die Steckdose bei mir nicht vom Netz getrennt ist, sondern ständig eingesteckt und auch eingeschaltet ist.
Dann beschreibt die Meldung aber auf ein Netzwerkproblem zwischen FHEM und TPLink-Steckdose hin, hast Du mal ein regelemässiges ping auf das device gemacht (per presence)? Ich sehe das Problem bei mir nur sehr selten.
Gelegentliche W-Lan-Unterbrechungen habe ich auch immer mal wieder. Deshalb fange ich die Abfrage im HS110-Modul mit disable 0/1 eben ab.
Zitat von: viegener am 03 Juli 2019, 09:29:10
Das Problem ist einfach, dass im Code bei einem disable=0 die regelmässigen Anfragen nicht wieder automatisch starten.
Ich denke ein möglicher Workaround wäre NACH dem Setzen von "disable=0" noch ein get auf dem TPLink device auszuführen, damit sollte auch der automatische Zyklus von updates wieder getriggert
Ja, die regelmäßige automatische Abfrage startet nach disable 1 auf 0 nicht mehr.
Ein "get <device name> power" ergibt: "No get implemented for <device name>"
Demnach kann das TPLinkHS110 das nicht, oder?
Hat noch jemand eine Idee?
@Pauline: Sorry, Du hast recht, ich habe mich durch die Funktion _get im COde verwirren lassen, diese wird aber nicht an einen Get-Befehl gebunden. Ohne Code-änderung sehe ich da moment keine einfache Möglichkeit. Die regelmässige Abfrage lässt sich momentan nur über einen Schaltbefehl oder einen redefine wieder aktivieren.
Zitat von: Pauline am 09 Juli 2019, 17:28:21
Gelegentliche W-Lan-Unterbrechungen habe ich auch immer mal wieder. Deshalb fange ich die Abfrage im HS110-Modul mit disable 0/1 eben ab.
Verstehe ich grad nicht...
Du kannst die WLAN-Unterbrechung vorhersehen und daher rechtzeitig die FHEM-Anfrage an die Steckdose ausschalten, um keine Fehlermeldungen zu erhalten? :-\
Zitat von: TheTrumpeter am 10 Juli 2019, 09:09:46
Verstehe ich grad nicht...
Du kannst die WLAN-Unterbrechung vorhersehen und daher rechtzeitig die FHEM-Anfrage an die Steckdose ausschalten, um keine Fehlermeldungen zu erhalten? :-\
Machst Du das per PRESENCE?
Hab' dieses Modul bisher nicht genutzt, weil ich keinen Anwendungsfall dafür hatte... hab's jetzt mal eingerichtet um die Steckdose zu überprüfen, wahrscheinlich schaltest Du die HS110-Abfrage ab, wenn die Steckdose auf "abwesend" geht und gleich wieder ein, wenn sie auf "anwesend" geht? Werde das mal ausprobieren.
Ja, genau so mache ich das. Hat den Vorteil, dass PRESENCE bei absent die PING-Rate hoch setzt (also nur z.B. alle 30 oder 60 Sekunden testet ob das Gerät sich wieder meldet). Und das entsprechende HS110-Modul schweigt. Der Traffic und eventuelle Wartezeiten in FHEM werden enorm reduziert.
Ich stecke meine Geräte immer mal wieder um oder schalte eine Steckdosenleiste, in der ein HS110 steckt, über Nacht komplett aus.
Zitat von: Pauline am 09 Juli 2019, 17:28:21
Gelegentliche W-Lan-Unterbrechungen habe ich auch immer mal wieder. Deshalb fange ich die Abfrage im HS110-Modul mit disable 0/1 eben ab.
Genauer: Deshalb fange ich die Abfrage
des HS110-Moduls mit disable 0 bzw. 1 eben ab....
Derzeit speichere ich laufend den Zustand des Relais und setzte den Status, wenn der HS110 sich wieder meldet, mit set auf den letzten Zustand. Damit startet die automatische Abfrage der Readings wieder!
Geht soweit ganz gut, hat aber ein kleines Fenster (kurz vor dem Ausstecken/Abschalten und bis W-Lan wieder connect ist nach dem Einstecken/Einschalten, dass manuelle Schaltzustandswechsel am Gerät evt. vom letzten Status überschrieben werden.... Naja, kann ich mit leben.
Zitat von: Pauline am 11 Juli 2019, 21:10:26
Derzeit speichere ich laufend den Zustand des Relais und setzte den Status, wenn der HS110 sich wieder meldet, mit set auf den letzten Zustand. Damit startet die automatische Abfrage der Readings wieder!
Geht soweit ganz gut, hat aber ein kleines Fenster (kurz vor dem Ausstecken/Abschalten und bis W-Lan wieder connect ist nach dem Einstecken/Einschalten, dass manuelle Schaltzustandswechsel am Gerät evt. vom letzten Status überschrieben werden.... Naja, kann ich mit leben.
Teilst Du den Code hier? Dann brauch' ich nicht selbst basteln...
Hallo,
kann bitte jemand seine .cfg für die HS110 posten.
Vielleicht mit Filelog und schöner Grafik.
Ich suche nach einer .cfg, die eben täglich den daily_total um 23:59 ausliest und dann grafisch darstellt. Gleiches für monthly_total.
Danke
Jörg
Hallo zusammen, ich bekomme seit einigen Tagen im ca. 15 Minutentakt folgende Fehlermeldung:
2019.10.19 10:10:31 1: TPLinkHS110: BUT_TPLink_3D_Drucker Get failed - Couldn't connect to 192.168.178.37:9999: IO::Socket::INET: connect: timeout
IO::Socket::INET ist installiert und aktuell.
Internals:
CHANGED
DEF 192.168.178.37
FUUID 5d741eeb-f33f-2e6c-d074-9e1d6d04cb69acdb
FVERSION 24_TPLinkHS110.pm:0.195320/2019-06-02
HOST 192.168.178.37
INTERVAL 300
NAME BUT_TPLink_3D_Drucker
NR 27
STATE off
TIMEOUT 1
TYPE TPLinkHS110
READINGS:
2019-10-19 10:15:30 active_mode none
2019-10-19 10:15:30 alias Steckdose Drucker
2019-10-19 10:15:30 decode_json ok
2019-10-19 10:15:30 dev_name Wi-Fi Smart Plug
2019-10-19 10:15:30 deviceId 80067BD603E4D06F234C5D1B767FD625196BEC10
2019-10-19 10:15:30 err_code 0
2019-10-19 10:15:30 feature TIM
2019-10-19 10:15:30 fwId 00000000000000000000000000000000
2019-10-19 10:15:30 hwId 22603EA5E716DEAEA6642A30BE87AFCA
2019-10-19 10:15:30 hw_ver 1.0
2019-10-19 10:15:30 icon_hash
2019-10-19 10:15:30 latitude 48.407936
2019-10-19 10:15:30 led_off 0
2019-10-19 10:15:30 longitude 10.963076
2019-10-19 10:15:30 mac B0:4E:26:17:88:1B
2019-10-19 10:15:30 model HS100(EU)
2019-10-19 10:15:30 oemId 812A90EB2FCF306A993FAD8748024B07
2019-10-19 10:15:30 on_time 0
2019-10-19 10:15:30 relay_state 0
2019-10-19 10:15:30 rssi -72
2019-10-19 10:15:30 state off
2019-10-19 10:15:30 sw_ver 1.2.5 Build 171213 Rel.101415
2019-10-19 10:15:30 type IOT.SMARTPLUGSWITCH
2019-10-19 10:15:30 updating 0
Attributes:
DbLogExclude .*
alexaName Drucker
alexaRoom Büro Thomas
alias Steckdose 3D Drucker
devStateIcon on:ios-on-green off:ios-off toggle:rc_BLUE
disable 0
event-on-change-reading .*
group Geräte
icon hue_filled_outlet
room Büro Thomas,Geräte,Homekit
verbose 2
webCmd :
Niemand eine Idee wie ich das Problem lösen könnte?
Die Fehlermeldung ist ja recht klar: Deine Steckdose ist über das Netz nicht erreichbar.
Also:
1. Prüfen, ob die Steckdose noch die angegebene IP hat. Falls nein: IP ändern
2. Prüfen, ob ie IP von anderen Geräten pingbar ist
Falls nein: Fehlerquelle ist Steckose
Falls ja: Fehlerquelle ist FHEM
3. Falls Fehlerquelle Steckdose (wahrscheinlich)
- Steckdose rebooten
- Steckdose resetten
Falls nicht erfolgreich, nochmal melden
4. Falls Fehlerquelle FHEM: noch mal melden
Zitat von: Volker Kettenbach am 28 Oktober 2019, 12:32:58
- Steckdose resetten
Hätte ich eigentlich selbst drauf kommen können... :D
Läuft jetzt seit 2 Stunden ohne Fehlermeldung, mal hoffen das es so bleibt.
Mich hatte es halt nur gewundert, weil die Dose trotz Fehlermeldung ganz normal geschalten hat...
Danke! :)
Zitat von: Volker Kettenbach am 25 September 2018, 07:31:56
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.
Hallo Volker,
traue mich schon fast gar nicht mehr zu fragen.... die LBs sind die einzigsten Geräte, die ich noch mit App steuern muss, alles andere ist über FHEM angebunden ...
Greetings Gordon
Zu früh gefreut, die Fehlermeldung ist wieder da...
1. Prüfen, ob die Steckdose noch die angegebene IP hat. Falls nein: IP ändern
-> IP passt
2. Prüfen, ob ie IP von anderen Geräten pingbar ist
-> ist pingbar
3. Falls Fehlerquelle Steckdose (wahrscheinlich)
- Steckdose resetten
-> durchgeführt, hat nichts gebracht
4. Falls Fehlerquelle FHEM: noch mal melden
*nochmalmeld*
Was ist die Fehlermeldung im fhem?
Weiterhin
2019.10.30 16:45:22 1: TPLinkHS110: BUT_TPLink_3D_Drucker Get failed - Couldn't connect to 192.168.178.37:9999: IO::Socket::INET: connect: timeout
Da wird wohl die Steckdose kaputt sein
Grad noch eine andere Steckdose ausgepackt, gleiches Modell.
2019.10.30 21:45:39 1: TPLinkHS110: Test_Dose Get failed - Couldn't connect to 192.168.178.55:9999: IO::Socket::INET: connect: timeout :/
Dürfte also wohl nicht an den Dosen liegen. Kann es sein das vllt im IO::Socket::INET Modull irgendwas falsch läuft? Kann ich das irgendwie neu installieren?
Ich denke nicht, dass IO::Socket::INET ein Problem hat. Das Modul wird von sehr vielen Programmen verwendet.
Die Fehlermeldung sagt ja klar und deutlich, dass Deine Dose nicht über das Netz erreichbar ist.
Da kann das Modul und das FHEM nichts dafür.
Das liegt an der Dose oder ggf. Deinem Netzwerk (WLAN?).
Du könntest mal versuchen mit dem Tool nmap von dem FHEM-Rechner aus den Port 9999 (ich glaube udp) zu erreichen. Das wird nicht gehen, weil die Dose einfach nicht erreichbar ist.
Lies ausserdem mal den Thread hier genauer durch.Da wirst Du finden, dass es bei den Dosen scheinbar mit den neueren Firmwareversionen Probleme gibt, die wir uns nicht erklären können.
Ich habe auf allen meinen Dosen eine alte Firmware drauf und habe keine Probleme.
Sollten Dosen benötigt werden, die 100% zuverlässig schalten, würde ich sowieso von diesem Produkt und allen Produkten, die per WLAN arbeiten abraten und etwas was per Kabel-Ethernet oder KNX funktioniert nehmen.
@Humpelpumpel: Ich habe die Meldung
TPLinkHS110: kugellampe Get failed - Couldn't connect to 192.168.2.60:9999: IO::Socket::INET: connect: timeout
auch sporadisch manchmal alle paar Stunden / manchmal über Wochen nicht.
Bei mir ist allerdings die Vermutung, dass die Steckdosen aus irgendeinem Grund gelegentlich die Verbindung ins WLAN verlieren.
Kommt die Meldung denn bei Dir dauerhaft oder auch nur sproadisch.
Kommt tatsächlich leider alle 15-20 Minuten, bei bei Steckdosen die ich im einsatz habe. Habe jetzt verbose erstmal auf 0 gestellt damit mein Log nicht komplett platzt :D
Bin ganz neu hier ...
Habe mir die TP HS100 gekauft (Hardware 4.0, FW 1.1.1) und krieg sie nicht verbunden. Die Fehlermeldung lautet:
2020.03.28 16:26:26 3: TPLinkHS110: tp_test defined.
2020.03.28 16:26:28 1: TPLinkHS110: tp_test Get failed - Couldn't connect to 192.168.6.25:9999: IO::Socket::INET: connect: Connection refused
Ping funktioniert, Web-Oberfläche auch, was tun?
Zitat von: Tenge_Home am 28 März 2020, 16:48:23
Bin ganz neu hier ...
Habe mir die TP HS100 gekauft (Hardware 4.0, FW 1.1.1) und krieg sie nicht verbunden. Die Fehlermeldung lautet:
2020.03.28 16:26:26 3: TPLinkHS110: tp_test defined.
2020.03.28 16:26:28 1: TPLinkHS110: tp_test Get failed - Couldn't connect to 192.168.6.25:9999: IO::Socket::INET: connect: Connection refused
Ping funktioniert, Web-Oberfläche auch, was tun?
Vielleicht stehe ich ja auf der Leitung, aber welche Web-Oberfläche meinst Du?
Ping auch vom pi zur Steckdose?
IO::Socket::INET: connect: Connection refused bedeutet, dass die Dose per IP-Protokoll erreichbar ist, auf dem Port, zu dem verbunden werden soll, aber kein Service läuft.
Daraus und dass Tenge_Home von einer Weboberfläche berichtet schliesse ich, dass die Version 4 wohl eine ganze andere Software hat, als 1-3.
Das ist nicht gut.
Ohne ein solches Teil können wir da nichts programmieren.
Völlig crazy:
nachdem ich das Teil erstmalig installiert habe, wollte ich die IP-Adresse davon haben und habe in der Fritzbox nachgesehen. Da wurde das Teil gelistet und ich konnte es sogar anklicken und landete dann in der Web-Oberfläche. Dort konnte man einstellen, ob das ein AP und/oder STA Betrieb sein sollte mit allen möglichen Zusatzinfos (DNS,....), wie man eben so einen Router o.ä. konfiguriert.
Nur: ich konnte den nicht von FHEM aus ansprechen - s. o.
Nach euren Antworten war ich etwas frustiert und habe einen reset gemacht und die Dose über die App neu angemeldet. Und nun?
Oh Wunder: die Weboberfläche ist nicht mehr erreichbar, aber FHEM kann jetzt plötzlich darauf zugreifen und schalten.
Im Moment sieht also alles gut aus. Wenn ich neue Erkenntnisse habe, melde ich mich.
Bis hierher erst einmal vielen Dank!
Hallo,
erstmal vielen Dank für das Modul. Mittlerweile gibt es Hardware Version 4. Daher müssten die Mappings angepasst werden, bzw. da die Readings identisch zu Version 2 sind, diese auch für Version 4 eingefügt werden. Zu Version 3 kann ich leider nichts sagen.
Da ich Anfänger bin, kann ich leider nicht mit viel mehr Infos dienen, bin aber natürlich gerne behilflich.
Vielen Dank und Grüße!
Hallo,
ich habe folgendes an die HArdware Mappings angehängt und nun funktioniert die Dose wie gewünscht und gibt auch korrekte Werte aus.
$hwMap{'4.0'}{'emeter'}{'get_realtime'}{'power_mw'}{'name'} = 'power';
$hwMap{'4.0'}{'emeter'}{'get_realtime'}{'power_mw'}{'factor'} = 0.001;
$hwMap{'4.0'}{'emeter'}{'get_realtime'}{'voltage_mv'}{'name'} = 'voltage';
$hwMap{'4.0'}{'emeter'}{'get_realtime'}{'voltage_mv'}{'factor'} = 0.001;
$hwMap{'4.0'}{'emeter'}{'get_realtime'}{'current_ma'}{'name'} = 'current';
$hwMap{'4.0'}{'emeter'}{'get_realtime'}{'current_ma'}{'factor'} = 0.001;
$hwMap{'4.0'}{'emeter'}{'get_realtime'}{'total_wh'}{'name'} = 'total';
$hwMap{'4.0'}{'emeter'}{'get_realtime'}{'total_wh'}{'factor'} = 0.001;
$hwMap{'4.0'}{'emeter'}{'get_realtime'}{'err_code'}{'name'} = 'err_code';
$hwMap{'4.0'}{'emeter'}{'get_realtime'}{'err_code'}{'factor'} = 1;
Einziges Problem ist, dass nach jedem Upgrade die Änderung wieder weg ist. Könnte das jemand im Modul anpassen? Vielen Dank.
Zitat von: phoenix-anasazi am 10 April 2020, 17:06:53
Einziges Problem ist, dass nach jedem Upgrade die Änderung wieder weg ist. Könnte das jemand im Modul anpassen? Vielen Dank.
Du kannst das Modul erstmal vom update ausschliessen (exclude_from_update an global
Die Änderungen kannst Du auch als pull request in github stellen - der link ist im ersten beitrag
Vielen Dank für deine Antwort. Beides erledigt. ;)
@phoenix-anasazi: Vielen Dank für den Pull-Request!
Das Update ist ab sofort im Git https://github.com/kettenbach-it/FHEM-TPLink-HS110
und ab morgen im offiziellen FHEM SVN-Repo.
Frohe Ostern!
Super. Vielen Dank und ebenfalls frohe Ostern!
Gibt es eigentlich eine Möglichkeit die HS110 ohne die China-App ausschließlich mit fhem zu betreiben ?
Die Kasa App tunnelt ja meine fritzbox und ich benutze die Steckdose faktisch ausschließlich als Strommessgerät am Gefrierschrank und schalte die Dose somals nie.
Danke für die Info
Jörg
Zitat von: jnewton957 am 14 April 2020, 21:05:54
Gibt es eigentlich eine Möglichkeit die HS110 ohne die China-App ausschließlich mit fhem zu betreiben ?
Die Kasa App tunnelt ja meine fritzbox und ich benutze die Steckdose faktisch ausschließlich als Strommessgerät am Gefrierschrank und schalte die Dose somals nie.
Danke für die Info
Jörg
Was meinst Du mit tunneln? Ich habe es nicht im Detail analysiert, aber aus meiner Sicht melden die Schalter Ihren Status an die KASA-Server und nehmen über diesen Weg auch Schaltbefehle entgegen, aber es wird kein "Tunnel" von aussen nach innen geschaffen (also kein Port geöffnet oder ähnliches).
Was ich ausprobiert habe, ist im Router den Steckdosen den Zugang ins Internet zu nehmen, im eigenen Netz funktioniert die App dann immer noch und natürlich FHEM ebenfalls.
Zitat von: viegener am 14 April 2020, 22:08:53
Was meinst Du mit tunneln? Ich habe es nicht im Detail analysiert, aber aus meiner Sicht melden die Schalter Ihren Status an die KASA-Server und nehmen über diesen Weg auch Schaltbefehle entgegen, aber es wird kein "Tunnel" von aussen nach innen geschaffen (also kein Port geöffnet oder ähnliches).
Was ich ausprobiert habe, ist im Router den Steckdosen den Zugang ins Internet zu nehmen, im eigenen Netz funktioniert die App dann immer noch und natürlich FHEM ebenfalls.
Ich hatte das so bei der Einrichtung von KASA gelesen, dass somit der Zugriff "durch" den Router auf die Steckdosen passiert. Die Steckdose meldet ja auch regelmäßig seinen Verbrauch an die KASA App.
Gute Idee mal im Router die Internetverbindung der IP Adresse der Steckdose zu verwehren. Mal sehen, was passiert.
Hi,
ich hab seit kurzem ein Problem mit einer HS110 Hardware Version 1.0 Software Version 1.1.4 die bisher ohne Probleme lief. Aktuell geht schalten wunderbar aber es werden weder power noch total Werte übertragen, beide stehen immer auf 0.
Die beiden anderen HS110 (Hardware beide 2.0 Software 1.5.4 und 1.4.3) funktionieren problemlos.
Weiter oben im Thread hab ich von einer Anpassung für die Hardware 3.0 gelesen. Könnte das damit zusammenhängen? Updates mache ich regelmäßig und automatisch Dienstag Nacht :-)
24_TPLinkHS110.pm 21645 2020-04-12 09:11:23Z vk
Hat noch jemand diese Modulversion mit ner 1.0 Hardware im Einsatz und könnte das mal prüfen ob er den Fehler auch hat?`
Wenn ich mal dazu kommen lad ich mir mal ne ältere Version aus dem Github und prüf das nochmal
Grüße
Achim
Nachtrag: Auch mit 24_TPLinkHS110.pm 19095 2019-04-02 13:02:04Z vk keine Readings bei Power und Total :-( scheint dann doch die Hardware zu sein
Guten Morgen,
ich habe das geprüft: mit der gleichen Version gibt es bei mir keine Probleme mit dem Datenabruf.
Es wäre auch sehr verwunderlich, da die von Dir erwähnte Änderung nur ein kleiner Eingriff war und den Datenabruf nicht betraf.
Ich meine in diesem Thread weiter vorne mal gelesen zu haben, dass jemand auch ein Problem mit dem Datenabruf hatte - er hatte das, glaube ich, in den Griff bekommen.
Lies mal in diesem Thread nach - evtl hilft Dir das.
Gruß
Volker
Hi,
danke fürs prüfen, aktuell tut er, auch mit der neuen Version wieder, er ruft die Daten wie z.b. on/off schon ab, aber z.b. die Netzspannung fehlt im Fehlerfall komplett ich vermute mal das da evtl ne kalte Lötstelle ist und ohne Spannung kein Verbrauch :-)
Grüße
Achim
Hallo,
Ich habe eine HS100(EU) mit hw_ver 2.0.
Ich will den Stromverbrauch des laufenden Tages graphen.
In der Kasa-App habe ich:
Gesamtverbrauch heute: 0,20 kWh
Gesamtverbrauch 7 Tage 1,28 kWh
Gesamtverbrauch 30 Tage 1,28 kWh
In den readings stehen aber komplett andere Werte:
Internals:
DEF 192.168.178.160
FUUID 5f37dcd6-f33f-6385-03ca-5f4bf9175c76e579
HOST 192.168.178.160
INTERVAL 60
NAME tplinkswitch7
NEXTUPDATE Thu Aug 20 14:15:14 2020
NR 944
STATE on 3.848 W
TIMEOUT 1
TYPE TPLinkHS110
READINGS:
2020-08-20 14:14:14 active_mode none
2020-08-20 14:14:14 alias HWW
2020-08-20 14:14:14 current 0.062
2020-08-20 14:14:14 daily_average 247.166666666667
2020-08-20 14:14:14 daily_total 0.203
2020-08-20 14:14:14 decode_json ok
2020-08-20 14:14:14 dev_name Smart Wi-Fi Plug With Energy Monitoring
2020-08-20 14:14:14 deviceId 8006655ACAAA60197EA9D90187F93D601B88E927
2020-08-20 14:14:14 err_code 0
2020-08-20 14:14:14 feature TIM:ENE
2020-08-20 14:14:14 fwId 00000000000000000000000000000000
2020-08-20 14:14:14 hwId 044A516EE63C875F9458DA25C2CCC5A0
2020-08-20 14:14:14 hw_ver 2.0
2020-08-20 14:14:14 icon_hash
2020-08-20 14:14:14 led_off 0
2020-08-20 14:14:14 mac 98:DA:C4:08:78:52
2020-08-20 14:14:14 model HS110(EU)
2020-08-20 14:14:14 monthly_total 1.483
2020-08-20 14:14:14 next_action -None-
2020-08-20 14:14:14 oemId 1998A14DAA86E4E001FD7CAF42868B5E
2020-08-20 14:14:14 on_time 3937
2020-08-20 14:14:14 power 3.848
2020-08-20 14:14:14 relay_state 1
2020-08-20 14:14:14 rssi -63
2020-08-20 14:14:14 state on
2020-08-20 14:14:14 sw_ver 1.5.6 Build 191125 Rel.083657
2020-08-20 14:14:14 time 2020-8-20 14:14:13
2020-08-20 14:14:14 total 1.483
2020-08-20 14:14:14 type IOT.SMARTPLUGSWITCH
2020-08-20 14:14:14 updating 0
2020-08-20 14:14:14 voltage 233.311
Attributes:
alias HWW Schaltsteckdose
devStateIcon on.*:message_socket_on_off@red:off off.*:message_socket_on_off@black:on
disable 0
event-min-interval total:300,on_time:300
event-on-change-reading state,total,on_time
group HWW
interval 60
room Keller
stateFormat state power W
Muss ich da noch was umrechnen ? Die Last ist ein Hauswasserwerk (Pumpe), also im Wesentlichen induktive Last.
Grüße, gadget
daily_total scheint zu zu stimmen. 2.03 vs 2.0 - hier hat Kasa gerundet.
Die anderen Werte, also Avg. 7 Tage und Avg. 30 Tage sind schlicht und einfach nicht im FHEM drin.
Frag mich nicht warum. Ich glaube das wurde nie implementiert.
Von daher läuft hier nichts falsch.
Hallo Leute,
besitze seit heute meine 3 TP Link Steckdose. Die anderen 2 sind ohne Energiemesser. Nur leider wird bei mir keine Energiemessung angezeigt. Dauert das ein bisschen bis das kommt oder habe ich was falsch?
Das neuste Update des Moduls bekomme ich doch über die update Routine oder nicht?
Habe mal eine List mit dran gepackt. Und bei mir stehen auch Fragezeichen als Status bei meinen anderen beiden hatte ich direkt das Lampen Symbol. Schalten lässt sie sich aber über Fhem. Ändert aber auch nicht die Fragezeichen.
Internals:
CFGFN
DEF 192.168.33.26
FUUID 5f7efb32-f33f-faf7-e7ba-b58ce67c68d04ac5
HOST 192.168.33.26
INTERVAL 300
NAME WLan_Stromzahler1
NR 4841
STATE ???
TIMEOUT 1
TYPE TPLinkHS110
READINGS:
2020-10-08 13:43:06 active_mode none
2020-10-08 13:43:06 alias Stromz�hler Steckdose 1
2020-10-08 13:43:06 decode_json ok
2020-10-08 13:43:06 dev_name Smart Wi-Fi Plug With Energy Monitoring
2020-10-08 13:43:06 deviceId 8006C34046915F03EC9631831B4323B81CC55F09
2020-10-08 13:43:06 err_code 0
2020-10-08 13:43:06 feature TIM:ENE
2020-10-08 13:43:06 hwId 06D9793BF7C4C3E37A386CB6C5D4A929
2020-10-08 13:43:06 hw_ver 4.0
2020-10-08 13:43:06 icon_hash
2020-10-08 13:43:06 latitude_i 522800
2020-10-08 13:43:06 led_off 0
2020-10-08 13:43:06 longitude_i 77146
2020-10-08 13:43:06 mac B0:95:75:15:6A:8B
2020-10-08 13:43:06 mic_type IOT.SMARTPLUGSWITCH
2020-10-08 13:43:06 model HS110(EU)
2020-10-08 13:43:06 next_action HASH(0x6b930c8)
2020-10-08 13:43:06 oemId BC7DF59F436483CD3D8396111011B83E
2020-10-08 13:43:06 on_time 1
2020-10-08 13:43:06 relay_state 1
2020-10-08 13:43:06 rssi -24
2020-10-08 13:43:06 state on
2020-10-08 13:43:06 status new
2020-10-08 13:43:06 sw_ver 1.0.4 Build 191111 Rel.143500
2020-10-08 13:43:06 updating 0
Attributes:
alias WLan_Stromzahler1
disable 0
room Steckdosen
Fehler gefunden. Es fehlte mir die neue Version 4.0. Hoffe das nun die älteren auch noch funktionieren
Ich verwende fhem schon eine Weile für Stromaufzeichnungen mit einem EDIPLUG SP2101W. Jetzt habe ich mir noch 2 TP-Link HS110 geholt. Ich betreibe fhem unter Windows. Die Inbetriebnahme des HS110 hat leider ein paar Probleme bereitet, da IO::Socket::Timeout sowie PerlIO::via::Timeout in der Strawberry Perl Portable nicht enthalten sind. Man kann diese aber von metacpan beziehen und in die entsprechenden Pfade (fhem-5.8\perl\lib\PerlIO\via bzw. fhem\perl\lib\IO\Socket) kopieren.
https://metacpan.org/pod/PerlIO::via::Timeout
https://metacpan.org/pod/IO::Socket::Timeout
Anschließend funktioniert der Stecker auch unter Windows. Nur falls noch jemand über das Problem stolpert...
Positiv beim HS110 ist mir aufgefallen, dass dieser im Gegensatz zum EDIPLUG sekündlich einen neuen Wert liefert.
EDIT: Mein Stecker ist übrigens ein V4.
Hallo,
nachdem ich mit tplink Steckdose und diesem Modul gute Erfahrungen gemacht habe, habe ich mir KL110 Wlan Leuchte von tplink zugelegt. Funktioniert super. Die Einrichtung in Fhem habe (aufgrund fehlender? Alternativen) mit dem Modul für die Steckdose versucht. Die Gerätedaten der Wlan Leuchte werden auch ausgelesen. Die Schaltbefehle funktionieren logischerweise nicht... Gibt es vllt. eine Weiterentwicklung in Richtung KL110?, oder habe ich etwas übersehen?
LG
Readings
active_mode
none
alias
Vorbaulicht
ctrl_protocols
HASH(0x87f5a10)
decode_json
ok
description
Smart Wi-Fi LED Bulb with Dimmable Light
dev_state
normal
deviceId
80123AF174F125854163A8D0FAB4003A1CDC39DC
disco_ver
1.0
err_code
0
heapsize
293084
hwId
111E35908497A05512E259BB76801E10
hw_ver
1.0
is_color
0
is_dimmable
1
is_factory
0
is_variable_color_temp
0
light_state
HASH(0xabe8ad8)
mic_mac
B09575AF8F62
mic_type
IOT.SMARTBULB
model
KL110(EU)
oemId
775B67C11038B99BEEDE39B0C910F6E9
preferred_state
ARRAY(0xa095a30)
rssi
-58
state
off
sw_ver
1.8.11 Build 191113 Rel.105336
time
-- ::
Hallo Zusammen,
ich hätt eine Frage zu den WLAN Steckdosen. Ich bin recht neu in FHEM und Perl deshalb habt bitte nachsicht.
Meine Frage ist wie ich den Verbrauch auslesen kann.
Ich hab die Steckdose hinterlegt und bekomme nun im Log folgendes:
2020.10.17 11:46:22.596 5: Test_Steckdose - Data returned: $VAR1 = '{"emeter":{"get_realtime":{"voltage_mv":235293,"current_ma":29,"power_mw":2717,"total_wh":6,"err_code":0}}}';
Wie bekomme ich nun die Werte als "Readings", sodass ich sie zb. in eine Datenbank schreiben kann.
Mfg
Sascha
Hallo zusammen,
ich habe hier mehrere HS110 Steckdosen von TP-Link im Betrieb. Die funktionieren alle auch genau so, wie ich es möchte, nur eine, die ich jetzt erst gekauft habe, will irgendwie nicht. Dies ehat die Hardware Rev. 4.0.
Ich binde die Steckdose in FHEM wie folgt ein:
define HS110_Zahnbuerste TPLinkHS110 192.168.1.115
Die Steckdose ist online, lässt sich über KASA ganz normal schalten, funktioniert alles super. Die Steckdose wurde mit dem Standardverfahren eingerichtet (KASA App).
ping 192.168.1.115
Ping wird ausgeführt für 192.168.1.115 mit 32 Bytes Daten:
Antwort von 192.168.1.115: Bytes=32 Zeit=23ms TTL=255
Antwort von 192.168.1.115: Bytes=32 Zeit=40ms TTL=255
Antwort von 192.168.1.115: Bytes=32 Zeit=17ms TTL=255
Antwort von 192.168.1.115: Bytes=32 Zeit=27ms TTL=255
Ping-Statistik für 192.168.1.115:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 17ms, Maximum = 40ms, Mittelwert = 26ms
Leider sehe ich im FHEM keinen Status der Steckdose (Anhang hc_001.jpg).
Das dazugehörige Filelog wird auch nicht beschrieben. Attribute wie current und power fehlen auch.
Klicke ich auf die drei Fragezeichen, so schaltet die Steckdose EIN und die Werte unten aktualisieren sich. Außerdem erscheint im Event Monitor folgendes:
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste decode_json: ok
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste decode_json: ok
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste active_mode: none
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste alias: HS110_Zahnbuerste
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste dev_name: Smart Wi-Fi Plug With Energy Monitoring
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste deviceId: 80062B0EBFBAB5F1BD7B3B24FEBE9BB51DA82C3C
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste err_code: 0
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste feature: TIM:ENE
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste hwId: 06D9793BF7C4C3E37A386CB6C5D4A929
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste hw_ver: 4.0
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste icon_hash:
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste latitude_i: 514595
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste led_off: 0
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste longitude_i: 119690
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste mac: E4:C3:2A:2C:E9:C4
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste mic_type: IOT.SMARTPLUGSWITCH
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste model: HS110(EU)
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste next_action: HASH(0x4521290)
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste oemId: BC7DF59F436483CD3D8396111011B83E
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste on_time: 0
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste relay_state: 1
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste rssi: -61
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste status: new
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste sw_ver: 1.0.5 Build 200917 Rel.095551
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste updating: 0
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste on
2020-12-31 10:38:30.919 TPLinkHS110 HS110_Zahnbuerste decode_json: ok
Klicke ich nochmal passiert nichts.
Liegt hier eventuell ein Fehler vor, da das die Revision 4 ist?
Stell mal verbose auf 5 und schau dann mal, was im Log steht
Ich habe Steckdose einmal auf on und einmal auf off gestellt:
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test decode_json: ok
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test decode_json: ok
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test active_mode: none
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test alias: Test
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test dev_name: Smart Wi-Fi Plug With Energy Monitoring
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test deviceId: 80069D47071F088D865AFA509FF121FA1DA8665A
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test err_code: 0
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test feature: TIM:ENE
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test hwId: 06D9793BF7C4C3E37A386CB6C5D4A929
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test hw_ver: 4.0
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test icon_hash:
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test latitude_i: 514595
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test led_off: 0
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test longitude_i: 119690
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test mac: E4:C3:2A:2C:E3:3F
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test mic_type: IOT.SMARTPLUGSWITCH
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test model: HS110(EU)
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test next_action: HASH(0x49171c8)
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test oemId: BC7DF59F436483CD3D8396111011B83E
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test on_time: 0
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test relay_state: 1
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test rssi: -52
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test status: new
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test sw_ver: 1.0.4 Build 191111 Rel.143500
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test updating: 0
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test on
2021-01-08 08:43:35.538 TPLinkHS110 HS110_Test decode_json: ok
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test decode_json: ok
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test decode_json: ok
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test active_mode: none
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test alias: Test
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test dev_name: Smart Wi-Fi Plug With Energy Monitoring
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test deviceId: 80069D47071F088D865AFA509FF121FA1DA8665A
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test err_code: 0
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test feature: TIM:ENE
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test hwId: 06D9793BF7C4C3E37A386CB6C5D4A929
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test hw_ver: 4.0
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test icon_hash:
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test latitude_i: 514595
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test led_off: 0
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test longitude_i: 119690
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test mac: E4:C3:2A:2C:E3:3F
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test mic_type: IOT.SMARTPLUGSWITCH
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test model: HS110(EU)
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test next_action: HASH(0x4917be8)
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test oemId: BC7DF59F436483CD3D8396111011B83E
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test on_time: 0
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test relay_state: 0
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test rssi: -58
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test status: new
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test sw_ver: 1.0.4 Build 191111 Rel.143500
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test updating: 0
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test off
2021-01-08 08:43:36.371 TPLinkHS110 HS110_Test decode_json: ok
Soll ich noch weitere Logs erzeugen?
//
Das ist eine andere Steckdose als die oben. Ich hatte die zurück geschickt, um einen Hardwaredefekt auszuschließen. Bei dieser habe ich absichtlich kein Software-Update gemacht.
Bitte vor dem On/Off mal das "verbose" Attribut für Dein Device auf 5 setzen.
Da sollte deutlich mehr an Logging-Informationen angezeigt werden
Das habe ich vorher schon getan und jetzt noch einmal gecheckt, scheinbar hat es jetzt aber doch funktioniert ;)
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test decode_json: ok
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test active_mode: none
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test alias: Test
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test dev_name: Smart Wi-Fi Plug With Energy Monitoring
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test deviceId: 80069D47071F088D865AFA509FF121FA1DA8665A
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test err_code: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test feature: TIM:ENE
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test hwId: 06D9793BF7C4C3E37A386CB6C5D4A929
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test hw_ver: 4.0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test icon_hash:
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test latitude_i: 514595
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test led_off: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test longitude_i: 119690
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test mac: E4:C3:2A:2C:E3:3F
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test mic_type: IOT.SMARTPLUGSWITCH
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test model: HS110(EU)
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test next_action: HASH(0x46565c0)
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test oemId: BC7DF59F436483CD3D8396111011B83E
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test on_time: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test relay_state: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test rssi: -49
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test status: new
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test sw_ver: 1.0.4 Build 191111 Rel.143500
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test updating: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test off
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test decode_json: ok
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test decode_json: ok
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test active_mode: none
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test alias: Test
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test dev_name: Smart Wi-Fi Plug With Energy Monitoring
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test deviceId: 80069D47071F088D865AFA509FF121FA1DA8665A
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test err_code: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test feature: TIM:ENE
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test hwId: 06D9793BF7C4C3E37A386CB6C5D4A929
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test hw_ver: 4.0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test icon_hash:
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test latitude_i: 514595
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test led_off: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test longitude_i: 119690
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test mac: E4:C3:2A:2C:E3:3F
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test mic_type: IOT.SMARTPLUGSWITCH
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test model: HS110(EU)
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test next_action: HASH(0x47abba0)
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test oemId: BC7DF59F436483CD3D8396111011B83E
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test on_time: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test relay_state: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test rssi: -55
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test status: new
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test sw_ver: 1.0.4 Build 191111 Rel.143500
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test updating: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test off
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test decode_json: ok
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test decode_json: ok
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test active_mode: none
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test alias: Test
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test dev_name: Smart Wi-Fi Plug With Energy Monitoring
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test deviceId: 80069D47071F088D865AFA509FF121FA1DA8665A
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test err_code: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test feature: TIM:ENE
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test hwId: 06D9793BF7C4C3E37A386CB6C5D4A929
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test hw_ver: 4.0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test icon_hash:
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test latitude_i: 514595
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test led_off: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test longitude_i: 119690
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test mac: E4:C3:2A:2C:E3:3F
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test mic_type: IOT.SMARTPLUGSWITCH
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test model: HS110(EU)
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test next_action: HASH(0x47ad1f8)
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test oemId: BC7DF59F436483CD3D8396111011B83E
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test on_time: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test relay_state: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test rssi: -52
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test status: new
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test sw_ver: 1.0.4 Build 191111 Rel.143500
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test updating: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test off
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test decode_json: ok
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test decode_json: ok
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test decode_json: ok
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test active_mode: none
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test alias: Test
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test dev_name: Smart Wi-Fi Plug With Energy Monitoring
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test deviceId: 80069D47071F088D865AFA509FF121FA1DA8665A
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test err_code: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test feature: TIM:ENE
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test hwId: 06D9793BF7C4C3E37A386CB6C5D4A929
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test hw_ver: 4.0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test icon_hash:
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test latitude_i: 514595
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test led_off: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test longitude_i: 119690
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test mac: E4:C3:2A:2C:E3:3F
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test mic_type: IOT.SMARTPLUGSWITCH
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test model: HS110(EU)
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test next_action: HASH(0x43ab6d0)
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test oemId: BC7DF59F436483CD3D8396111011B83E
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test on_time: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test relay_state: 1
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test rssi: -55
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test status: new
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test sw_ver: 1.0.4 Build 191111 Rel.143500
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test updating: 0
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test on
2021-01-09 11:44:58.161 TPLinkHS110 HS110_Test decode_json: ok
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test decode_json: ok
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test decode_json: ok
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test active_mode: none
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test alias: Test
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test dev_name: Smart Wi-Fi Plug With Energy Monitoring
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test deviceId: 80069D47071F088D865AFA509FF121FA1DA8665A
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test err_code: 0
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test feature: TIM:ENE
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test hwId: 06D9793BF7C4C3E37A386CB6C5D4A929
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test hw_ver: 4.0
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test icon_hash:
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test latitude_i: 514595
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test led_off: 0
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test longitude_i: 119690
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test mac: E4:C3:2A:2C:E3:3F
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test mic_type: IOT.SMARTPLUGSWITCH
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test model: HS110(EU)
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test next_action: HASH(0x4655d38)
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test oemId: BC7DF59F436483CD3D8396111011B83E
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test on_time: 0
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test relay_state: 0
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test rssi: -53
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test status: new
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test sw_ver: 1.0.4 Build 191111 Rel.143500
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test updating: 0
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test off
2021-01-09 11:44:58.862 TPLinkHS110 HS110_Test decode_json: ok
Kannst Du mal im Modul schauen, wie die ersten 4 Zeilen des Modules aussehen und diese hier posten!?
Ich meine diesen Part:
################################################################
# $Id: 24_TPLinkHS110.pm 21645 2020-04-12 09:11:23Z vk $
#
# Release 2020-04-12
root@81e8de770d97:/opt/fhem# cat ./FHEM/24_TPLinkHS110.pm | head -n 4
################################################################
# $Id: 24_TPLinkHS110.pm 19532 2019-06-02 06:38:05Z vk $
#
# Release 2019-05-31 SendCommand2
Aha, ich sehe schon, dass das eine alte Version ist.
Ich nutze fhem mit dem offiziellen Docker-Image. Fehlt da vielleicht das Update drin oder muss ich das manuell aktualisieren?
fhem:
image: fhem/fhem:latest
root@raspberrypi:/opt/fhem/docker# docker-compose pull fhem
Pulling fhem ... done
root@raspberrypi:/opt/fhem/docker# docker-compose up -d
docker_fhem_1 is up-to-date
Das Modul ist im FHEM-Repository up-to-date und auch das Docker-Image (ich verwende auch Docker) sollte es enthalten.
Das ist sehr komisch.
Hier gibt es das aktuelle Modul:
https://github.com/kettenbach-it/FHEM-TPLink-HS110
Ich habe den Container einmal vernichtet und frisch gepullt:
root@raspberrypi:/opt/fhem/docker# doc stop && doc rm -f && yes | docker system prune -a --volumes && doc up -d && doc exec fhem cat ./FHEM/24_TPLinkHS110.pm | head -n 4
Stopping docker_fhem_1 ... done
Going to remove docker_fhem_1
Removing docker_fhem_1 ... done
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all volumes not used by at least one container
- all images without at least one container associated to them
- all build cache
Are you sure you want to continue? [y/N] Deleted Images:
untagged: fhem/fhem:latest
untagged: fhem/fhem@sha256:75973596e008dd3f1dd88c92abce9d644d326302817917fa867b6f48241e40b8
deleted: sha256:85af1223416b39e78d77c91f7fa35cbbe9dedda4031ee8aa3d3f2366510819cf
deleted: sha256:80f64f602147a66c6ec7c18f0b60207a939f3d850798c3ed197e542431163de9
deleted: sha256:480096afdef5f2c66b983e51f96d54f2375e922d070caca4f2f7c477e00e4b97
deleted: sha256:69622e1e300fefeca7fb1fef41f9738e132a9722c0b3b636b217579ee82b620c
deleted: sha256:86465334a93ec1b89243e6e166e36c0a3875380e48dcd6051b79e1b8e43db3f3
deleted: sha256:7adf15a0ec1508097db3aff1151dc7516797501aeabe59f99414a0514641ec41
deleted: sha256:6d2cee745772d5afe8eea401a786c3978898924b72e5e82187f97b72c5e4ebfc
deleted: sha256:62f52e1679a9108e74f103dd3dfc1e16f96a51afe017c2767fd18d58f533c9d9
deleted: sha256:24cbf67494a92b5e4531a57df01b20a9008f509a15a73a2fdf054a97ac66f8ca
deleted: sha256:68ff9fc844f93ef466d66f9d212ca34a9a2e1497008a05c993238e4eb9af1139
deleted: sha256:f52c859a64b6962a95f371754a7fcc65922262b3a71da7ed94a3a3330c52b561
deleted: sha256:4453e2c480ed2cea09240cde5ee8ef06a4b26666d2c8cbccc3ffbdd6b043a5a9
deleted: sha256:82544df279011c5ae4c248d7081c8bea38f15ef3eae3890f7e226d5bc71a2ff3
deleted: sha256:55221c3e13f68f78a319ef8b526411760b346308da6fc5a01738aed02722b79c
deleted: sha256:475d3a38ae6f47f385a15de8fa730acd7c3b62de5a1f23306abc3cdebd5584ba
deleted: sha256:aae879272b7f56ff6222bd8ac4377ac6648a68fa5416a6b08e3911c7d7f73431
deleted: sha256:48a94f296076b031618544a1c90387bd780918448907094f2525b41aa5661dcf
deleted: sha256:352c3217a0e0b0e937d6373aa2cb511332147a65124f83758697692add99b313
Total reclaimed space: 1.403GB
Pulling fhem (fhem/fhem:latest)...
latest: Pulling from fhem/fhem
ebde10b25101: Pull complete
f591c25c1b7a: Pull complete
36b17dac7d72: Pull complete
ba5d7392f8d2: Pull complete
4a66da5bae34: Pull complete
227c6149b98e: Pull complete
fde861b149d5: Pull complete
3b7595832102: Pull complete
b5a63e62d178: Pull complete
e0865e2c305a: Pull complete
b4b5fe054902: Pull complete
28fb8432ab02: Pull complete
32ccab69f84f: Pull complete
f71d771135d7: Pull complete
190bcec24dad: Pull complete
f81d398c588a: Pull complete
990e6a3ad8a4: Pull complete
Digest: sha256:75973596e008dd3f1dd88c92abce9d644d326302817917fa867b6f48241e40b8
Status: Downloaded newer image for fhem/fhem:latest
Creating docker_fhem_1 ... done
################################################################
# $Id: 24_TPLinkHS110.pm 19532 2019-06-02 06:38:05Z vk $
#
# Release 2019-05-31 SendCommand2
Das war auf meinem Raspberry Pi 4.
Ich habe den Container auf meinem Laptop (amd64) ausgeführt und siehe da:
root@laptop:/tmp/fhem# doc exec fhem cat ./FHEM/24_TPLinkHS110.pm | head -n 4
################################################################
# $Id: 24_TPLinkHS110.pm 21645 2020-04-12 09:11:23Z vk $
#
# Release 2020-04-12
Das sieht für mich so aus, als wäre das Image für die Architektur armv8 (müsste das sein) nicht aktuell? Hast du fhem auf einem RPi laufen?
// zumal alle Module 2019 das letzte Update erhalten haben zu scheinen. :O
Ich habe zudem mal ein paar Informationen aus der Oberfläche angehangen:
Ok, Kommando zurück!
Es gab einen Fehler beim mounten in meiner Konfiguration. Ich habe versehentlich die Module in ein Volume ausgelagert. So kann das natürlich nichts werden :-\
Mein Fehler, tut mir leid :(
Trotzdem ganz lieben Dank für die Hilfe! :)
Geht's denn jetzt?
Tip: Du musst nur die fhem.cfg auf ein Volume legen (Symlink). Der Rest gehört ins Image. Dann passiert sowas nicht.
Ja, jetzt läuft es :)
Ich hatte mich an dem Beispiel hier orientiert: https://github.com/fhem/fhem-docker/blob/dev/docker-compose.yml
Dort wird der komplette fhem-Ordner in das Volume gepackt.
Ich hatte nun versucht, notwendige Ordner und Dateien (fhem/.config/, fhem/.ssh/, fhem/fhem.cfg, fhem/fhem.cfg.bak, fhem/log/, fhem/restoreDir/, fhem/www/) in ein volume auszulagern, jedoch wurde mein TelegramBot dann nach jedem Neustart entfernt.
Das war der Moment, in dem ich gemerkt habe, dass man einfach "update all" eingeben kann - und zack - alles aktuell. ;D
Super, dass es läuft.
Zitat von: -kw am 11 Januar 2021, 13:35:10
Ich hatte mich an dem Beispiel hier orientiert: https://github.com/fhem/fhem-docker/blob/dev/docker-compose.yml
Dort wird der komplette fhem-Ordner in das Volume gepackt.
Das Beispiel ist total Unsinn und stellt das Docker-Konzept komplett auf den Kopf. Alles ausser de fhem.cfg gehört in das Image und nicht ins Volume.
Ich baue mit einem Dockerfile mein eigenes Image und lade ist meine private Registry.
Wenn ich eine neue Version von FHEM starten will, baue ich das Image. Bis auf die fhem.cfg und ein paar Dingen im "vk" Folder wird alles neu erzeugt.
Hier steht wie das geht:
➜ volker@volkers-mbp ~/PycharmProjects/dockerfiles/fhem > cat Dockerfile
FROM fhem/fhem:latest
COPY pre-start.sh /
RUN chmod a+x /pre-start.sh➜ volker@volkers-mbp ~/PycharmProjects/dockerfiles/fhem > cat pre-start.sh
#!/bin/bash
ln -s /opt/fhem/vk/99_myUtils.pm /opt/fhem/FHEM/99_myUtils.pm
# More personal links go here
version: '3.7'
services:
fhem:
image: eu.gcr.io/kettenbach-it/fhem:20200521
build: .
container_name: fhem
restart: always
networks:
default:
ipv4_address: 192.168.11.131
volumes:
- /opt/fhem/fhem.cfg:/opt/fhem/fhem.cfg
- /opt/fhem/db.conf:/opt/fhem/db.conf
- /opt/fhem/log:/opt/fhem/log
- /opt/fhem/restoreDir:/opt/fhem/restoreDir
- /opt/fhem/vk:/opt/fhem/vk
- /opt/fhem/FhemUtils:/opt/fhem/FhemUtils
environment:
FHEM_UID: 0
FHEM_GID: 6061
TIMEOUT: 10
RESTART: 1
TELNETPORT: 7072
TZ: Europe/Berlin
APT_PKGS: "vim less libio-socket-timeout-perl libio-socket-multicast-perl ow-shell libownet-perl libwww-curl-perl"
Mystisch, db.conf und FhemUtils habe ich gar nicht. Ist aber nicht weiter schlimm, ich habe mir jetzt mit dem Update-Befehl geholfen. Ich danke dir. :)
6x TP-Link HS110 zu verkaufen!
Da ich nach und nach aus FHEM aussteige, brauche ich ab sofort meine HS110 TP110 für die ich mein Modul 24_TPLinkHS110 entwickelt habe, nicht mehr.
Es handelt sich um 5x um die Hardwareversion 1.0 und 1x um die Version 3.0
Alle diese HS110 waren nie mit der Cloud verbunden. Daher ist noch die ursprüngliche Software darauf und die funktioniert daher einwandfrei mit FHEM 24_TPLink und ggf. auch anderen Systemen.
Die 6 Stück mit HW 1 haben die Firmware 1.0.8 Build 151101 Rel.24452 und sind hier zu finden: https://www.ebay-kleinanzeigen.de/s-anzeige/smart-wlan-plug-tplink-hs110-hw-v1-0-funktioniert-mit-fhem-co/1631159647-168-4906
Die HW 3 hat die Firmware 1.4.3 Build 171009 Rel.104144 und ist hier zu finden: https://www.ebay-kleinanzeigen.de/s-anzeige/smart-wlan-plug-tplink-hs110-hw-v3-0-funktioniert-mit-fhem-co/1631169709-168-4906
Früher oder später wäre es vermutlich auch sinnvoll, wenn es noch einen weiteren Maintainer für den Code geben würde, der sich hier finden:
https://github.com/kettenbach-it/FHEM-TPLink-HS110
Wer dazu Lust hat, kann sich gerne melden.
Die TPLink HS110 sind weg
Hallo,
ich bin Fhem Neuling und versuche gerade eine HS100 zu integrieren. Bei dem Versuch mit "define WLAN_Steckdose_1 TPLinkHS110 192.168.7.144" bekomme ich die Meldung "Cannot load module TPLinkHS110" von Fhem zurück.
Die Abhängigkeiten IO::Socket::SSL und IO::Socket::INET habe ich nachinstalliert.
Wie kann ich denn weiter vorgehen um dem Fehler auf die Schliche zu kommen?
Viele Grüße
Moin
Und herzlich willkommen im Forum!
Ist Dein fhem aktuell? Wobei ich gerade mal nachgesehen habe, das Modul ist schon ca 4 Jahre im Repository!
Da kann ich nur eine Schreibfehler vermuten!
Sind Deine Zitate kopiert, oder getippt?
Nutze bitte die Raute (#) ueber den Smilies wenn Du Code einfuegst! Das macht es allen einfacher!
Gruss Christoph
Zitat von: Coachi am 14 Februar 2021, 10:06:07
Hallo,
ich bin Fhem Neuling und versuche gerade eine HS100 zu integrieren. Bei dem Versuch mit "define WLAN_Steckdose_1 TPLinkHS110 192.168.7.144" bekomme ich die Meldung "Cannot load module TPLinkHS110" von Fhem zurück.
Die Abhängigkeiten IO::Socket::SSL und IO::Socket::INET habe ich nachinstalliert.
Wie kann ich denn weiter vorgehen um dem Fehler auf die Schliche zu kommen?
Viele Grüße
Sind die Perl-Module JSON und Data__Dumper installiert?
Hallo,
sorry für die Verspätung, ich bekomme noch keine Benachrichtigung bei einem Beitrag
Ich konnte das Problem gestern noch lösen indem ich die besagten Perl-Module nochmal installiert habe. Vermutlich habe ich beim ersten mal beim installieren was falsch gemacht. War eig fast klar das es das Modul ja schon länger gibt und ja auch funktioniert...
Danke trotzdem für eure Rückmeldungen
Hi,
mal eine kurze Frage zu den gemessenen Energiewerten. Vergleiche ich die Kasa App mit den Daten aus FHEM, habe ich ein riesiges ? über dem Kopf.
FHEM und Kasa zeigen beide bei power den selben Wert, nur alles andere ist irgendwie anders.
daily_total in FHEM bei 0.001, Kasa 0.00kWh
daily_average in FHEM 0.724333333333333, Kasa bei 7 Tagen 1.30kWh und bei 30 Tagen 1.18kWh
monthly_total in FHEM 2.173, Kasa bei 30 Tagen 35.3kWh.
Wie errechnet das Modul die Verbrauchsdaten und in welcher Einheit sind sie. Wie kommt diese Differenz zwischen Kasa und Modul zu stande bzw. was muss ich die umrechnen, um auf die tatsächlichen Werte zu kommen. Oder sind die Werte die das Modul liefert die tatsächlichen und die Kasa App errechnet was anderes?
Ich würde gerne den Verrbauch loggen um die Kosten zu berechnen, nur dazu müsste ich erst einmal wissen, was genau das Modul da anzeigt.
Hier mal ein List von dem Device:
Internals:
DEF 192.168.188.21
FUUID 5c4dc69e-f33f-59c6-8250-3e3d7a7ef8e93b22
HOST 192.168.188.21
INTERVAL 60
NAME Trockner
NEXTUPDATE Wed Mar 3 02:16:12 2021
NR 91
STATE on
TIMEOUT 1
TYPE TPLinkHS110
READINGS:
2021-03-03 02:15:12 active_mode none
2021-03-03 02:15:12 alias Trockner
2021-03-03 02:15:12 current 0.032185
2021-03-03 02:15:12 daily_average 0.724333333333333
2021-03-03 02:15:12 daily_total 0.001
2021-03-03 02:15:12 decode_json ok
2021-03-03 02:15:12 dev_name Wi-Fi Smart Plug With Energy Monitoring
2021-03-03 02:15:12 deviceId 800641F264509XXXXXX4D5962D207F62194DXXXX
2021-03-03 02:15:12 err_code 0
2021-03-03 02:15:12 feature TIM:ENE
2021-03-03 02:15:12 fwId 851E8C7225C322XXXXXXA3AFDACDXXXX
2021-03-03 02:15:12 hwId 45E29DA8382494XXXXXX88B52A0BXXXX
2021-03-03 02:15:12 hw_ver 1.0
2021-03-03 02:15:12 icon_hash
2021-03-03 02:15:12 latitude XX.XXXXXX
2021-03-03 02:15:12 led_off 0
2021-03-03 02:15:12 longitude XX.XXXXXX
2021-03-03 02:15:12 mac XX:XX:XX:XX:XX:XX
2021-03-03 02:15:12 model HS110(EU)
2021-03-03 02:15:12 monthly_total 2.173
2021-03-03 02:15:12 oemId 3D341ECE302XXXXXX9E31CE2430XXXX
2021-03-03 02:15:12 on_time 3426879
2021-03-03 02:15:12 power 0.473554
2021-03-03 02:15:12 relay_state 1
2021-03-03 02:15:12 rssi -57
2021-03-03 02:15:12 state on
2021-03-03 02:15:12 sw_ver 1.1.4 Build 170417 Rel.145118
2021-03-03 02:15:12 time 2021-3-3 2:15:12
2021-03-03 02:15:12 total 49.14
2021-03-03 02:15:12 type IOT.SMARTPLUGSWITCH
2021-03-03 02:15:12 updating 0
2021-03-03 02:15:12 voltage 233.311815
helper:
bm:
TPLinkHS110_Set:
cnt 136
dmx -1000
dtot 0
dtotcnt 0
mTS 03.03. 01:58:12
max 0.00559401512145996
tot 0.383682489395142
mAr:
HASH(0x5616a2133848)
Trockner
?
Attributes:
disable 0
event-on-change-reading power,state
group Geräte
icon scene_clothes_dryer
interval 60
room 08_Hauswirtschaft
Hallo,
habe mir kürzlich das Model KP115 über Amazon zugelegt. Eigentlich mit Energieanzeige. Wird auch in der KASA-App angezeigt. Hab es normal angelegt. Schalten geht, jedoch fehlt mir das Reading 'power'. Kann man da was machen?
Gruß
Keiner eine idee?
Habe mal den Code etwas angepasst. So werden auch die Verbrauchswerte des KP115 angezeigt. Ist etwas quick an dirty geworden.
Die Abfrage des Model wurde um den KP115 erweitert. Da die Hardwareversion des KP115 leider 1 ist, passt dies mit dem Hardwaremapping nicht zusammen. Der KP115 benutzt die Ausgabe des HS110 V2. Somit wird nun vor der Auswahl des hw_mapping nochmals das Model aus der JSON gelesen. Ist die Ausgabe "KP115(EU)" wird die Variable $hm_ver auf 2.0 gesetzt. Somit passt dann auch die Auswahl des richtigen Mappings.
Eventuell werde ich das ganze noch mal etwas sauberer umschreiben.
Hallo
Da ich bei mir umfangreiche Umbaumaßnahmen durchgefürt habe und nun alles schön Unterputz ist gebe ich meine HS110EU V3 ab.
Es sind 3 voll funktionsfähige und 1 die etwas zwischert/pfeifft aber ansonsten funktioniert.
Ich würde die 3 für 5€ pro Stück + Versand verkaufen. Wenn jemand alle drei kauft lege ich die eine pfeifende kostenlos dabei. ;-)
Bei Interesse einfach ne PM.
Gruß
Daniel
Zitat von: keymaster am 18 August 2021, 17:02:40
Habe mal den Code etwas angepasst.
...
Somit passt dann auch die Auswahl des richtigen Mappings.
Eventuell werde ich das ganze noch mal etwas sauberer umschreiben.
Hast du nochmal drüber geschaut und es sauber gemacht? ;-)
Funktioniert deine Version mit gemischten
HS100/110 und KP115?
Ich will meine HS1x0 nicht austauschen.
Christian
Zitat von: ChrisH am 20 September 2021, 21:10:46
Hast du nochmal drüber geschaut und es sauber gemacht? ;-)
Funktioniert deine Version mit gemischten
HS100/110 und KP115?
Ich will meine HS1x0 nicht austauschen.
Christian
hey,
also hab auch das TPLinkHS110.pm angepasst...
Version im Anhang...
mit der Version funktioniert HS110 HS100 und KP115
hab mir jetzt aber den Code von keymaster nicht angeschaut lest sich aber als hätte er das selbe gemacht wie ich...
meine Änderung
- Zeile 199 - 206
- Zeile 253 - 259
LG.
Erwin
Funktioniert auch bei mir fuer beide wie es scheint.
Sollen Wir (Du oder ich) einen pull request daraus machen?
Christian
PR wäre sehr gut.
Ich nehme diese gerne auf https://github.com/kettenbach-it/FHEM-TPLink-HS110 entgegen.
Was ich nicht leisten kann (und will, weil es mittelfristig zu schlechter Software führt) ist hier im Forum Code-Schnipsel austauschen.
Noch ein Hinweis: ich reagiere hier in diesem Forum - wenn überhaupt - dann nur mit bis zu mehreren Tagen Verzögerung.
Für akute Bugs oder eigene Code Beiträge (in Form von Pull-Requests) reagiere ich auf Github schneller.
Allgemeinen User-Support werde ich aber weder dort noch hier leisten, da sich 99% aller Probleme mit dem Modul durch das Lesen dieses Threads lösen lassen und die restlichen 1% von anderen User beantwortet werden können.
Und noch ein Hinweis: wenn jemand Module hier aus diesem Thread einsetzt, so werden diese beim nächsten Update mit der alten Version überschrieben.
Daher sollten diese wie beschrieben per PullRequest über den Github in das offizielle Repository eingepflegt werden.
Ich habe gestern den ersten KP115 eingebaut und muss feststellen das mir (mindestens) 2 Werte fehlen:
current:
power:
beide sind 0. In der KASA App sind aktuell >1800Watt angezeigt. Ideen wie ich da troubleshoote?
EDIT: nachdem ich angefangen habe im Modul rumzuedieren und mir eine LOG3 Zeile reingepackt habe geht es.
Und jetzt fehlen Power und Current schon wieder.
Christian
Das kommt vermutlich daher, dass die Patches nicht an mich ins Github übermittelt wurden sondern hier im Forum verbreitet werden.
Pech!
Oh Mann. Danke. :-[
Ich hab vor ein paar Tagen einen OS Update aller meiner Rechner laufen lassen dabei ist wohl auch eine neue fhem Version reingerutscht.
Ich mach den Pull Request dann doch bald.
Christian.
Zitat von: ChrisH am 07 November 2021, 18:20:51
Ich mach den Pull Request dann doch bald.
PR ist erstellt. Ich hoffe das passt so, das ist mein zweiter PR und der erste Pull Request ohne Unterstuetzung.
Christian
PR ist gemerged und ab morgen auch im SVN
Hat eigentlich jemand die KP105 schon mit dem Modul probiert?
Die gibt's grad bei Amazon um knapp EUR 10,-; die HS100/HS110 sind de facto ja nicht mehr erhältlich.
Da die KP115 nun angeblich funktioniert, würd' ich davon ausgehen, dass die KP105 ebenfalls läuft.
Zitat von: TheTrumpeter am 29 November 2021, 11:42:32
Hat eigentlich jemand die KP105 schon mit dem Modul probiert?
Die gibt's grad bei Amazon um knapp EUR 10,-; die HS100/HS110 sind de facto ja nicht mehr erhältlich.
Da die KP115 nun angeblich funktioniert, würd' ich davon ausgehen, dass die KP105 ebenfalls läuft.
Ich beantwort' die Frage mal selbst, nachdem die Amazon-Lieferung vor einigen Minuten eingetroffen ist...
Funktioniert, Modell meldet sich als "KP105(EU)" und lässt sich problemlos schalten.
Danke für die gute Arbeit. HS110, eingerichtet, funktioniert. Super!
Habe seit kurzem 2 weitere Steckdosen (1x HS110 und 1x HS100) im Einsatz und bei der Gelegenheit festgestellt, dass sie immer wieder keine aktuellen Daten liefern...
Habe nun etwas genauer draufgeschaut und einen möglichen Zusammenhang mit meiner Fritz.Box (bzw. einem der WLAN-Extender) festgestellt.
Insgesamt sind dzt. 5 Steckdosen dauerhaft im Einsatz. 2 davon sind unauffällig und mit dem Extender im Keller verbunden. Die 3 auffälligen Steckdosen sind alle mit dem Extender in der Garage verbunden. Habe nun bei Problemen immer nachgeschaut, ob die Steckdosen, wenn sie keine Readings mehr liefern, noch verbunden sind. Die Fritz.Box sagt, dass sie verbunden sind und dass die IP-Adresse ,,gerade" genutzt wurde. (Die Fritz.Box zeigt in der Detailansicht der Geräte an, wann die IP-Adresse zuletzt genutzt wurde. Die Uhrzeit war immer höchstens 1 Minute alt, wenn ich draufgeschaut habe.)
Über Ping waren die Steckdosen aber nicht erreichbar und auch die Kasa-App hat sie nicht angezeigt. Wenn ich dann das betroffene Gerät aus der Fritz.Box ,,gelöscht" habe, d.h. in der Detailansicht des Geräts die ,,Einstellungen zurückgesetzt" habe, hat sich das Gerät ein paar Sekunden später wieder verbunden und auch in FHEM wurden wieder aktuelle Werte angezeigt. Ausserdem hat die Kasa-App das Gerät dann wieder angezeigt.
Hat das schon jemand ausprobiert (gibt in anderen Routern sicher ähnliche Einstellungen) oder bin ich der Einzige, der (wieder?) Verbindungsprobleme hat?
(Am gleichen WLAN-Extender habe ich 2 weitere Geräte permanent verbunden, von denen 1 komplett unauffällig ist und 1 nur alle paar Wochen mal kleinere ,,Aussetzer" hat, die aber auch eine andere Ursache haben könnten.)
Ach ja, die Geräte wurden zwar mit der Kasa-App eingerichtet (mir ist kein anderer Weg bekannt ihnen das WLAN und das Passwort ,,beizubringen"), dürfen aber nicht ,,nach-Hause-telefonieren" und in der Kasa-App bin ich auch nicht ,,angemeldet".
gelöscht
Moin,
auch wenn Volker hier nicht mehr regelmäßig liest versuche ich es zuerst hier :-)
Bei mir läuft FHEM auf einem Server mit Debian 10 (Buster), die 2 x HS110 taten bis vor kurzem klaglos ihren Dienst. Auf dem Server mach ich regelmäßig Updates und ich vermute bei einem hat es dann wohl was "zerschossen" ich kann die HS110 zwar lesen, Verbrauch etc. aber nicht mehr schalten.
Der Log ist voll von:
2023.02.28 00:03:16.410 1: TPLinkHS110: steckdose_08 Get failed - Couldn't connect to 192.168.222.64:9999: IO::Socket::INET: connect: timeout
Die hier erwähnten Pakete hab ich nochmal geprüft, alle installiert.
Wo könnte ich mit der Fehlersuche weitermachen?
Viele Grüße
Achim
Guten Morgen,
ich lese hier durchaus regelmäßig. Aber nur einmal pro Woche. Ich beantworte aber nicht jede Frage, da viele sich durch Nachlesen im Forum oder Googlen beantworten lassen. Ferner rate ich dazu, zu schaltbaren Zwischensteckern zu wechseln, auf denen Tasmota läuft und die dann per MQTT gesteuert werden.
Die Fehlermeldung bedeutet, dass FHEM den Stecker über das Netzwerk nicht erreichen kann. Du wirst die Stecker auch nicht Pingen können, vermute ich.
Ursachen können Firewalls, Switches oder die Stecker selbst sein. Weniger dass hier besprochene Modul.
Gruß
Volker
Moin Volker,
doch pingen geht, eben probiert, interessanterweise gehen 3 von 4 Pakete aber dabei verloren ;-)
Auslesen geht ja auch, Verbrauch usw. wird erfasst nur schalten geht leider nicht mehr :-(
Viele Grüße
Achim
Bei einem so hohen Packetloss es ist kein Wunder, dass das nicht richtig funktioniert. Das Netzwerk hat ein erhebliches Problem.
Moin,
ich hab eben mal ne kleine Ping-Orgie gemacht. Auffällig ist halt, GHoma, Shelly, Sonoff antworten sofort und 4 mal, TPLink geht manchmal, manchmal geht garnichts oder nur der erste Ping und der zweite dritte und vierte nicht mehr :-(
Vlt. ist auch die TPLink defekt