Fhem Modul für TP-Link Tapo P100, P110 und P115 schaltbare WLAN Steckdosen.

Begonnen von hirntot, 07 Dezember 2023, 12:41:16

Vorheriges Thema - Nächstes Thema

jnewton957

Ich habe mir nochmals die logs genauer angesehen und (ohne Ahnung) das 24_TPLinkP100.pm

In Zeile 542 und 544 steht tatsächlich "my $reply =" im Abschnitt (534) "sub TPLinkP100_GetUpdate ($)"
Die Fehlermeldung ist daher nachvollziehbar, wenn man get update macht.

Im Log habe ich dann aber noch den Eintrag:
FATAL: padding_depad failed: Invalid argument provided. at /usr/local/lib/aarch64-linux-gnu/perl/5.36.0/Crypt/Mode/CBC.pm line 20.
Vielleicht hilft die Info.
FHEM6.2 auf Pi5
V 1.66 nanoCUL 433 (IT)
V 1.66 nanoCUL868 (HM)
sqlite3 LogDb
ELRO AB440, DECT200,  TFA30.3125, esp8266, HM, TabletUI, IR-Schreiblesekopf (Udo),tibber Pulse, Kostal Pico, cfos Wallbox, Modbus TCP

betateilchen

Zitat von: jnewton957 am 18 Januar 2024, 18:37:51PERL WARNING: "my" variable $reply masks earlier declaration in same scope at ./FHEM/24_TPLinkP100.pm line 542, <$fh> line 173.
TapoDevice: Trying init()

Zum einen sind das zwei Meldungen, die höchstwahrscheinlich gar nichts miteinander zu tun haben.

Und die erste Meldung ist einfach ein Hinweis auf eine unsaubere Programmierung, aber grundsätzlich kein Problem, um das man sich als Anwender Gedanken machen müsste. Funktionale Auswirkungen hat das normalerweise gar keine.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: jnewton957 am 17 Januar 2024, 07:41:25Dort habe ich vom Modul nun
TapoDevice: Parsing JSON
Alle Devices funktionieren. Verbose = 0
Trotzdem bekomme ich die Meldung im log.

Das ist kein Fehler, das Modul ist einfach an sehr vielen Stellen an den für FHEM definierten Development-Guidelines vorbei programmiert.

Die Meldung ist einfach eine Logmeldung, die anstatt über den FHEM eigenen Log-Mechanismus lieber auf Betriebssysteme (STDERR) ausgegeben und deshalb vom FHEM-Log "eingefangen" wird.

print STDERR "TapoDevice: Parsing JSON\n";
Da kannst Du in FHEM verbose level definieren, wie Du möchtest - das greift an dieser Stelle einfach  nicht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

jnewton957

Zitat von: betateilchen am 19 Januar 2024, 21:47:15Die Meldung ist einfach eine Logmeldung, die anstatt über den FHEM eigenen Log-Mechanismus lieber auf Betriebssysteme (STDERR) ausgegeben und deshalb vom FHEM-Log "eingefangen" wird.

print STDERR "TapoDevice: Parsing JSON\n";
Da kannst Du in FHEM verbose level definieren, wie Du möchtest - das greift an dieser Stelle einfach  nicht.


Vielleicht liest das ja der Modulentwickler und baut das um. QS und Standards in der Softwarentwicklung haben eben ihre Bedeutung und zeigen auch hier wieder, wie sinnvoll sie sind.

Bleibt also noch der
FATAL: padding_depad failed: Invalid argument provided. at /usr/local/lib/aarch64-linux-gnu/perl/5.36.0/Crypt/Mode/CBC.pm line 20.
Und FATAL ist eben keine Warning :-)
FHEM6.2 auf Pi5
V 1.66 nanoCUL 433 (IT)
V 1.66 nanoCUL868 (HM)
sqlite3 LogDb
ELRO AB440, DECT200,  TFA30.3125, esp8266, HM, TabletUI, IR-Schreiblesekopf (Udo),tibber Pulse, Kostal Pico, cfos Wallbox, Modbus TCP

betateilchen

Zitat von: jnewton957 am 20 Januar 2024, 13:49:32Und FATAL ist eben keine Warning

Nein, aber auch das kommt nicht aus FHEM, sondern von der Betriebssytemebene.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Bitzer

Den Fatal Error hatte ich bei mir noch nicht, und auch keine Abstürze. Ich habe die Codezeile mit "print SDTERR..." einfach in dem Modul auskommentiert, dann wird auch das Log nicht mehr zugespamt. Insgesamt läuft das Modul in den letzten Tagen echt stabil.

jnewton957

Zitat von: Bitzer am 21 Januar 2024, 12:07:57Den Fatal Error hatte ich bei mir noch nicht, und auch keine Abstürze. Ich habe die Codezeile mit "print SDTERR..." einfach in dem Modul auskommentiert, dann wird auch das Log nicht mehr zugespamt. Insgesamt läuft das Modul in den letzten Tagen echt stabil.

Hast du denn
at /usr/local/lib/aarch64-linux-gnu/perl/5.36.0/Crypt/Mode/CBC.pmauf deiner Raspi o.ä

bzw. sudo apt install libcrypt-cbc-perl das Modul installiert?

Evtl brauche ich das ja nicht und kann es wieder ausbauen?
FHEM6.2 auf Pi5
V 1.66 nanoCUL 433 (IT)
V 1.66 nanoCUL868 (HM)
sqlite3 LogDb
ELRO AB440, DECT200,  TFA30.3125, esp8266, HM, TabletUI, IR-Schreiblesekopf (Udo),tibber Pulse, Kostal Pico, cfos Wallbox, Modbus TCP

Bitzer

Den Pfad gibt es bei mir nicht, das Modul ist allerdings installiert.

west2107

Hallo,

seit paar Tagen benutze ich das Modul auch.
Die Zeile "print STDERR "TapoDevice: Parsing JSON\n" habe ich auskommentiert,das Log bleibt sauber.

Allerdings verarbschidetet sich FHEM komplett nachts hiermit:
Can't use string ("0") as a HASH ref while "strict refs" in use at ./FHEM/24_TPLinkP100.pm line 544.
Ich habe versucht, über attr disable nachts die Steckdose und damit das Modul zu deaktivieren. Brachte nicht den Erfolg.
Ich habe jetzt mein WLAN-Zeitprogramm in Verdacht. Nachts wird abgeschaltet. Könnte sein, das die fehlende WLAN-Kennung
den Absturtz auslösst.

Ich teile das Ergebnis mit.

Tagsüber läuft alles problemlos.

Viele Grüße

west2107

Nachtrag:
Fehlendes WLAN führt zum kompletten Absturtz von FHEM. Ein disable des Geräte verhindert das nicht.
Das WLAN muss beim Einsatz dieses Moduls permanent verfügbar sein.




jnewton957

Zitat von: west2107 am 29 Januar 2024, 12:21:07Nachtrag:
Fehlendes WLAN führt zum kompletten Absturtz von FHEM. Ein disable des Geräte verhindert das nicht.
Das WLAN muss beim Einsatz dieses Moduls permanent verfügbar sein.

Das sind keine guten Nachrichten. Nun verliere ich nicht sehr häufig mein WLAN - aber garnicht ist es eben auch nicht. Ein Absturz von FHEM ist für mich sehr kritisch, da z.B. Gefrierschrank, Kühlschrank und ein paar andere Geräte wiederum von FHEM abhängen. Ganz geschweige von den vielen Statistiken, die dann wieder neu anfangen zu rechnen.

Ich hoffe mal, dass hirntot als Modulentwickler eine Idee hat, wie man das abfangen kann. Bei anderen WLAN Steckdosen-Devices führt ein Verlust vom WLAN ja nicht zum Absturz des FHEM sondern nur des entsprechenden devices.

 
FHEM6.2 auf Pi5
V 1.66 nanoCUL 433 (IT)
V 1.66 nanoCUL868 (HM)
sqlite3 LogDb
ELRO AB440, DECT200,  TFA30.3125, esp8266, HM, TabletUI, IR-Schreiblesekopf (Udo),tibber Pulse, Kostal Pico, cfos Wallbox, Modbus TCP

Damian

Zitat von: jnewton957 am 29 Januar 2024, 17:33:42
Zitat von: west2107 am 29 Januar 2024, 12:21:07Nachtrag:
Fehlendes WLAN führt zum kompletten Absturtz von FHEM. Ein disable des Geräte verhindert das nicht.
Das WLAN muss beim Einsatz dieses Moduls permanent verfügbar sein.

Das sind keine guten Nachrichten. Nun verliere ich nicht sehr häufig mein WLAN - aber garnicht ist es eben auch nicht. Ein Absturz von FHEM ist für mich sehr kritisch, da z.B. Gefrierschrank, Kühlschrank und ein paar andere Geräte wiederum von FHEM abhängen. Ganz geschweige von den vielen Statistiken, die dann wieder neu anfangen zu rechnen.

Ich hoffe mal, dass hirntot als Modulentwickler eine Idee hat, wie man das abfangen kann. Bei anderen WLAN Steckdosen-Devices führt ein Verlust vom WLAN ja nicht zum Absturz des FHEM sondern nur des entsprechenden devices.

 

Der Modulentwickler war zuletzt am 10.12.23 online. Er scheint also hier nicht besonders aktiv zu sein.

Ich habe meine P110 (wegen des Moduls angeschafft) nun in Home Assistant problemlos eingebunden - wäre schön gewesen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

jnewton957

Zitat von: Damian am 29 Januar 2024, 18:47:00Ich habe meine P110 (wegen des Moduls angeschafft) nun in Home Assistant problemlos eingebunden - wäre schön gewesen.

... wäre schön gewesen....

Heißt du hast das Modul wieder ausgebaut oder gehst du das Risiko ein?

Ein wenig zeigt sich auch, dass eine QS der FHEM-Module dringend erforderlich ist. Denn auch das Thema mit den vielen Statusmeldungen/-logs ("print STDERR "TapoDevice: Parsing JSON\n") würde eine generelle QS sicherlich rausfiltern.
Leider bin ich kein Programmierer - sonst hätte ich ja vielleicht überlegt bei anderen Modulen das coding zu finden (kopieren/anpassen), was eben beim WLAN Abbruch das FHEM/Modul nicht abstürzen lässt.

Vielleicht schaut aber der Entwickler ja doch mal nach seinem Modul :-)

PS Ich habe die Tapo zwar laufen - aber nicht in FHEM eingebunden. Zu riskant.
FHEM6.2 auf Pi5
V 1.66 nanoCUL 433 (IT)
V 1.66 nanoCUL868 (HM)
sqlite3 LogDb
ELRO AB440, DECT200,  TFA30.3125, esp8266, HM, TabletUI, IR-Schreiblesekopf (Udo),tibber Pulse, Kostal Pico, cfos Wallbox, Modbus TCP

Damian

Zitat von: jnewton957 am 30 Januar 2024, 10:46:54
Zitat von: Damian am 29 Januar 2024, 18:47:00Ich habe meine P110 (wegen des Moduls angeschafft) nun in Home Assistant problemlos eingebunden - wäre schön gewesen.

... wäre schön gewesen....

Heißt du hast das Modul wieder ausgebaut oder gehst du das Risiko ein?

Ein wenig zeigt sich auch, dass eine QS der FHEM-Module dringend erforderlich ist. Denn auch das Thema mit den vielen Statusmeldungen/-logs ("print STDERR "TapoDevice: Parsing JSON\n") würde eine generelle QS sicherlich rausfiltern.
Leider bin ich kein Programmierer - sonst hätte ich ja vielleicht überlegt bei anderen Modulen das coding zu finden (kopieren/anpassen), was eben beim WLAN Abbruch das FHEM/Modul nicht abstürzen lässt.

Vielleicht schaut aber der Entwickler ja doch mal nach seinem Modul :-)

PS Ich habe die Tapo zwar laufen - aber nicht in FHEM eingebunden. Zu riskant.

Ich habe es am Ende wegen der Kommentare hier gar nicht in fhem eingebunden.

Das Modul ist ja nicht offiziell eingecheckt, also darf man keine Ansprüche stellen. Und wenn der Modulentwickler keine Zeit oder Muße hat sich drum zu kümmern, dann muss man selber anpacken, mit Unzulänglichkeiten leben oder es eben nicht nutzen.

Ich habe noch von Osram (Ledvance) wifi-Steckdosen, die habe ich unter fhem auch nicht ans Laufen bekommen.

Beides funktioniert unter Home Assistant, das war schlussendlich der Auslöser mal über den Tellerrand zu schauen.

Mal schauen wie ich zukünftig zwei Systeme in Einklang bringe, vielleicht wird es aber irgendwann doch nur eins ;)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF