Test Adapter TP-Link Tapo

[Codierknecht]

@tombox
Der Adapter flutet mein Log.
Die Dose mit der genannten IP ist eingeschaltet und im Router nicht gesperrt. Schalten kann ich sowohl mit der App als auch mit dem Adapter.


Von den aktuell 4 in der App eingerichteten Dosen ist eine (Lichterkette) aktuell gar nicht gesteckt. Die ist im Log völlig unauffällig.

BTW: Von dem Konzept "Anmelden an der Cloud, um die Adressen zu ermitteln" bin ich noch nicht 100% überzeugt.
Für meine Begriffe wäre ein manuelles Eintragen der IP dem Anwender durchaus zuzumuten. Natürlich nur, wenn das auch zur Steuerung ausreichen würde.
Was passiert denn, wenn die Cloud mal nicht erreichbar ist? Sind die Dosen dann trotzdem schalt- und abfragbar?
Kann man dann das Abfragen der Cloud - soweit es denn notwendig ist - per Button in den Instanzeinstellungen nur bei Bedarf ausführen?

[tombox]

@codierknecht Abfrage zur cloud wird nur bei adapter start gemacht dann ist es unabhängig davon könnte man auch noch verbessern wenn die cloud nicht bei adapter start verfügbar ist

[Codierknecht]

@tombox
Mal 'ne Frage aus technischem Interesse:
Habe ich das richtig mitbekommen, dass solche Adapter (Tapo, Meross usw.) intern für die lokale Kommunikation MQTT verwenden?
Wenn ja: Könnte man dann - mit entsprechendem Aufwand - das Ganze auch selbst ohne Adapter einrichten? Oder ist die Kommunikation da mit einem (evtl. zeitlich begrenzten) Secret verschlüsselt?
Grund meiner Frage: Ich habe hier mittlerweile die verschiedensten Hersteller im Einsatz, die aktuell jeweils einen eigenen Adapter benötigen. Vielleicht wäre es da vorteilhafter, das Ganze mit MQTT zu zentralisieren. Wenn eine Anmeldung an der Cloud nicht wirklich nötig ist und die Kommunikation dadurch rein lokal möglich ist, hätte das für mich einen gewissen Charme.

[Codierknecht]

@tombox sagte in Test Adapter TP-Link Tapo:

@codierknecht Abfrage zur cloud wird nur bei adapter start gemacht dann ist es unabhängig davon könnte man auch noch verbessern wenn die cloud nicht bei adapter start verfügbar ist

Dann darf das für meine Begriffe gerne ins Log geschrieben werden und der Adapter arbeitet nur mit den Geräten, die bereits eingerichtet sind.
Dabei darfst Du gerne einen DP vorsehen, mit dem man ein Gerät auch mal logisch deaktivieren könnte, um z.B. vergebliche Verbindungsversuche bei ausgesteckten Geräten zu unterbinden.
Dann wäre es natürlich auch praktisch, wenn man Geräte auch manuell hinzufügen könnte, um die Cloud komplett zu umgehen.
Wenn die IP (evtl. auch die MAC) ausreichen sollte, bräuchte man theoretisch auch gar keine Cloud.

[Codierknecht]

@schuellerf sagte in Test Adapter TP-Link Tapo:

@tombox Hat bei mir auf Anhieb geklappt. Ich habe drei P110 und bin soweit sehr happy, danke! 🥳

Zwei Kleinigkeiten:

• Die Liste der remotes functions sollte offensichtlich vom Attribut "category" abhängen. Bei der P100 ist category: plug und da macht natürlich setBrightness, setColor und setColorTemp keinen Sinn
  (aber setPowerState schon, ... und geht wunderbar!)

Die Liste der DP je Gerät ist reichlich lang.
Hätte ich natürlich auch so gemacht. Erst mal alles holen was man kriegen kann. Wer weiß, wofür man es noch brauchen kann.
Wenn der Adapter ins Repo wandert, könnte man auf einige der DP sicher verzichten.

Auch von mir zunächst mal vielen Dank für Deine Mühe!

[Codierknecht]

@tombox
Aktuell zeigt sich bei mir folgendes Bild:

• Der Adapter benötigt bei mir mehrere Neustarts, bevor er nicht nur grün wird, sondern sich die DP auch tatsächlich schalten lassen
• Nach einer Weile fängt er dann wieder an, das Log voll zu schreiben. Synchron zum eingestellten Updateintervall. Dann lassen sich die Dosen auch nicht mehr schalten.

[tombox]

@codierknecht Schon mal probiert die Dose ein und ausschalten

[Codierknecht]

@tombox sagte in Test Adapter TP-Link Tapo:

@codierknecht Schon mal probiert die Dose ein und ausschalten

Ich werde erstmal die nicht gesteckte Dose aus der App werfen, um die als Ursache auszuschließen.

[Codierknecht]

@tombox
Worauf bezieht sich denn "tapo.0.info.connection" ???
Auf die Verbindung zur Cloud oder zu den Geräten?

Wenn Cloud, dann passt da was nicht:

Der Status sagt "verbunden". Kann aber nicht, da ich gerade die API lahmgelegt habe:

Nach meinem Verständnis dürfte die Instanz dann nicht grün werden.
Ich probier's dann in 30 Minuten wieder.

[Codierknecht]

@tombox
Eine wahrscheinliche Fehlerquelle konnte ich ausschalten.
Es lief noch eine Homebridge-Instanz mit dem Tapo-Plugin. Dadurch wird wohl das Limit der API überschritten.
Die Intelligenz sitzt wie immer vor dem Gerät
Außerdem habe ich das Refresh-Intervall mal auf 30 Sekunden hochgesetzt.
Seit 20 Minuten läuft der Adapter nun fehlerfrei. Auch mit der inaktiven Dose.

Zu dem Connection-Problem habe ich in GitHub ein Issue aufgemacht.

Toll wäre jetzt, wenn er auch bei nicht erfolgreicher Verbindung mit der Cloud eine rein lokale Kommunikation mit den Geräten aufsetzen könnte. Einfach mit den vorhandenen Daten.
Dann könnte ich die Dosen wieder im Router sperren, damit sie nicht länger "nach Hause telefonieren" können.

Und nicht falsch verstehen:
Das alles soll hier kein Gemeckere sein, sondern hoffentlich konstruktive Zuarbeit.

[surfer09]

Hallo,

kann mir vielleicht jemand sagen was das hier bedeutet?

2022-10-08 20:40:50.999 - debug: tapo.0 (2548) Redis Objects: Use Redis connection: 0.0.0.0:9001
2022-10-08 20:40:51.017 - debug: tapo.0 (2548) Objects client ready ... initialize now
2022-10-08 20:40:51.018 - debug: tapo.0 (2548) Objects create System PubSub Client
2022-10-08 20:40:51.018 - debug: tapo.0 (2548) Objects create User PubSub Client
2022-10-08 20:40:51.035 - debug: tapo.0 (2548) Objects client initialize lua scripts
2022-10-08 20:40:51.038 - debug: tapo.0 (2548) Objects connected to redis: 0.0.0.0:9001
2022-10-08 20:40:51.047 - debug: tapo.0 (2548) Redis States: Use Redis connection: 0.0.0.0:9000
2022-10-08 20:40:51.052 - debug: tapo.0 (2548) States create System PubSub Client
2022-10-08 20:40:51.052 - debug: tapo.0 (2548) States create User PubSub Client
2022-10-08 20:40:51.060 - debug: tapo.0 (2548) States connected to redis: 0.0.0.0:9000
2022-10-08 20:40:51.084 - debug: tapo.0 (2548) Plugin sentry Initialize Plugin (enabled=true)
2022-10-08 20:40:51.226 - info: tapo.0 (2548) starting. Version 0.0.1 (non-npm: TA2k/ioBroker.tapo#82a8e2866ca61d44b4f161a50bdb84a76babe589) in I:/ioBroker/node_modules/iobroker.tapo, node: v16.17.0, js-controller: 4.0.23
2022-10-08 20:40:51.237 - info: tapo.0 (2548) Login tp TAPO App
2022-10-08 20:40:51.240 - debug: tapo.0 (2548) ZJuNCLuRtvbRimn148tJig==
2022-10-08 20:40:51.417 - debug: tapo.0 (2548) {"error_code":-10306,"msg":"Access denied request in blackList"}
2022-10-08 20:40:51.417 - error: tapo.0 (2548) {"error_code":-10306,"msg":"Access denied request in blackList"}

Ich bekomme den Adapter nicht mehr gestartet...

[tombox]

@surfer09 bitte mal 0.0.3 probieren

[surfer09]

@tombox Gibt es da auch einen Link zu?

[tombox]

@surfer09 Entweder unter Adapter via GitHub oder npm installieren

[surfer09]

@tombox Über Github kann ich "tapo" gar nicht finden. Wie gehe ich über npm vor, damit ich die 0.0.3 installieren kann?

[mrbungle64]

@tombox

Ich habe eben die 0.0.4 installiert (via GitHub) - leider wird seitdem nichts mehr aktualisiert (nur noch beim Neustart) ...

Edit: mit der der Version 0.0.3 (via npm) scheint alles soweit zu gehen.

[surfer09]

@mrbungle64 Kannst du mir vielleicht einmal den npm Befehl nennen?

[tombox]

@mrbungle64 Bitte 0.0.5 probieren

[mrbungle64]

@surfer09 sagte in Test Adapter TP-Link Tapo:

@mrbungle64 Kannst du mir vielleicht einmal den npm Befehl nennen?

Das x mit der gewünschten Version ersetzen

/opt/iobroker $ npm install iobroker.tapo@0.0.x

[surfer09]

@tombox Also mit der 0.0.5 funktioniert zumindest der Adapterstart wieder bei mir.