UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[W0lfNeuz]

@tombox Ja, in der App kann den Plug schalten und auch den Verbrauch sehen.
Unter der IP kommt Meldung

200 OK

[tombox]

@w0lfneuz Ist denn der iobroker im gleichen Netz wie die Steckdose

[W0lfNeuz]

@tombox im selben Mesh Netzwerk

[Lucas Stiefel]

Heyho, kann ich mit deinen Adapter meine Kamera C320WS (ganz normale Tapo TP Link Kamera mit Bewegungserkennung), die bewegungserkennung an und ausschalten, oder auch diese Quick Funktionen nutzen wie "ich bin zuhause" "zuhause verlassen", wäre super wichtig um eine Alarmanlage zu realisieren und nicht immer 5 Apps zu öffnen sondern das mit Blocky über ein Datenpunkt regeln zu können.

Danke dir vielmals

[tombox]

@lucas-stiefel wird denn irgendwas erkannt wenn du den Adapter installierst und die Login Daten eingibst.

[Codierknecht]

@tombox
So, jetzt komme ich auch endlich mal dazu, den Adapter zu testen.
Zuerst einmal vielen Dank für Deine Mühe.

Das erste Problem habe ich (wie fast immer) bereits bei der Installation aus GitHub.
Mein ioBroker läuft als Docker-Container auf dem NAS (HP ProLiant mit DSM 6.1.7).
Eine Installation von Adaptern aus GitHub funktioniert fast nie. Beim letzten Versuch einen Adapter darüber zu installieren, habe ich gefühlte 100 Versuche benötigt. Irgendwann hat's dann auf wundersame Weise mal funktioniert - ohne dass ich etwas geändert hätte.
Ach so: Hatte ich schon erwähnt, dass Linux für mich ein Buch mit sieben Siegeln ist? :confused:

Hier das Log:

0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli   '/usr/bin/node',
1 verbose cli   '/usr/bin/npm',
1 verbose cli   'install',
1 verbose cli   'TA2k/ioBroker.tapo#e99d534ec2420efacc344378ed55391cc8407ca9'
1 verbose cli ]
2 info using npm@6.14.15
3 info using node@v14.18.3
4 verbose config Skipping project config: /opt/iobroker/.npmrc. (matches userconfig)
5 verbose npm-session 73452b28fa3671ee
6 silly install loadCurrentTree
7 silly install readLocalPackageData
8 silly fetchPackageMetaData error for github:TA2k/ioBroker.tapo#e99d534ec2420efacc344378ed55391cc8407ca9 Error while executing:
8 silly fetchPackageMetaData /usr/bin/git ls-remote -h -t ssh://git@github.com/TA2k/ioBroker.tapo.git
8 silly fetchPackageMetaData
8 silly fetchPackageMetaData error: cannot run ssh: No such file or directory
8 silly fetchPackageMetaData fatal: unable to fork
8 silly fetchPackageMetaData
8 silly fetchPackageMetaData exited with error code: 128
9 timing stage:rollbackFailedOptional Completed in 2ms
10 timing stage:runTopLevelLifecycles Completed in 33447ms
11 verbose stack Error: exited with error code: 128
11 verbose stack     at ChildProcess.<anonymous> (/usr/lib/node_modules/npm/node_modules/pacote/lib/util/finished.js:12:19)
11 verbose stack     at ChildProcess.emit (events.js:400:28)
11 verbose stack     at maybeClose (internal/child_process.js:1058:16)
11 verbose stack     at Socket.<anonymous> (internal/child_process.js:443:11)
11 verbose stack     at Socket.emit (events.js:400:28)
11 verbose stack     at Pipe.<anonymous> (net.js:686:12)
12 verbose cwd /opt/iobroker
13 verbose Linux 3.10.102
14 verbose argv "/usr/bin/node" "/usr/bin/npm" "install" "TA2k/ioBroker.tapo#e99d534ec2420efacc344378ed55391cc8407ca9"
15 verbose node v14.18.3
16 verbose npm  v6.14.15
17 error Error while executing:
17 error /usr/bin/git ls-remote -h -t ssh://git@github.com/TA2k/ioBroker.tapo.git
17 error
17 error error: cannot run ssh: No such file or directory
17 error fatal: unable to fork
17 error
17 error exited with error code: 128
18 verbose exit [ 1, true ]

[tombox]

@codierknecht Empfehlung ist hier npm 8 also node 16.
Dazu müsstest du dein docker container updaten. der aktuelle buanet container enthält node 16
Bei npm 6 muss man 15min warten bei GitHub installation aber der adapter ist jetzt auch im latest enthalten

[Codierknecht]

@tombox
Danke für den Hinweis!

Ich hatte ein anderes Image verwendet. Mit dem Buanet-Image funktioniert's einwandfrei.
Ich werde dann mal testen und berichten ...

[Fraenki23]

Hallo
Ich habe mehrer Tapo P100 Diese habe ich mit dem Adapter abgerufen und kann wie gewollt den Status loggen.
Nun habe ich einen weiteren Tado p100 Acount und habe mit einem zusätzlichen Adapter den zweiten aktiviert. Leider habe ich festgestellt dass man nicht beide gleichzeitug nutzen kann wenn beide normal grün leuchten wird nur der Status von einem geändert.
Sollte das funktionieren?
Danke
Gruss Fränki

[tombox]

@fraenki23 Nie getestet eigentlich sollte es gehen aber einfacher wäre es mit einem account

[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! :+1: :clap:

[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 :man-facepalming:
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.