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

[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:

Code Auswählen Erweitern

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.

[betateilchen]

Code Auswählen Erweitern

PERL 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.

[betateilchen]

Dort habe ich vom Modul nun

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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.

[jnewton957]

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.

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[betateilchen]

Und FATAL ist eben keine Warning

Nein, aber auch das kommt nicht aus FHEM, sondern von der Betriebssytemebene.

[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]

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.

Hast du denn

Code Auswählen Erweitern

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?

[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:

Code Auswählen Erweitern

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]

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.

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.

 

[Damian]

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.

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.

[jnewton957]

Ich 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.

[Damian]

Ich 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

[Damian]

Inzwischen laufen bei mir einige Tapos in Home Assistant (HA). Per Ereignissteuerung in HA kann man sich die Werte per MQTT nach FHEM liefern, falls man das überhaupt will, denn die Visualisierung in HA ist sehr einfach realisierbar.