Kein Problem, kein Stress!
Für mich ist die PR2 - Protokoll 3.5 also tatsächlich funktionsfähig. Ich habe es nicht auf meiner Produktion getestet, aber ich kann es tun, wenn nötig.
Danke @GBoulvin,
Ich habe das Docker-Image aktualisiert, das nun auch 3.4 unterstützt: Es wird jetzt an den Fork @demirdeniz/tuyapi-newgen weitergeleitet (derselbe, der 3.5 verwaltet), und ein Parser für Version 3.4 wurde zum lokalen UDP-Scan zwischen den Parsern 3.1 und 3.5 hinzugefügt. Du kannst es jederzeit mit dem neuen Image erneut testen.
Falls möglich, bitte auch den UDP-Scan (unabhängig) testen, um sicherzustellen, dass alles funktioniert. Vielen Dank im Voraus
Auf meiner Seite normalerweise nicht nötig: Die Änderungen fügen eine strikte Weiterleitung hinzu, die nur durch protocolVersion === '3.4' oder '3.5' ausgelöst wird. Geräte mit 3.1 und 3.3 verwenden weiterhin die Legacy-Bibliothek tuyapi ohne jegliche Änderung des Aufrufpfads — also kein Risiko von Rückschritten bei dem, was bereits funktioniert hat.
Das heißt, wenn du die Gelegenheit nutzen möchtest, um es auf deiner Produktion zu validieren, ist das ideal: Deine Geräte 3.4 (die nicht funktioniert haben) sollten jetzt funktionieren, und deine Geräte 3.1/3.3/3.5 sollten unverändert bleiben. Keine Verpflichtung, es ist nur ein Bonus, wenn du 5 Minuten Zeit hast.
EDIT :
Zur Information @pierre-gilles, ich habe den PR-Namen geändert, indem ich die explizite Hinzufügung von 3.4 neben 3.5 benannt habe, wobei beide dieselbe Bibliothek verwenden. Der PR ist etwas größer, aber wir bleiben unter 600 Zeilen Änderungen, es sind vor allem die Tests, die umfangreich sind (stellen die Hälfte der hinzugefügten Zeilen dar)
Vielleicht eine dumme Frage, aber ist das Bild immer noch auf demselben Tag (pr1)?
Ja immer ^^ Besser fragen ^^
Hallo!
Ich habe die verfügbare Version getestet und das Protokoll 3.4 wird erkannt und funktioniert direkt. Auch die Erkennung der lokalen IP-Adresse (für 3.4, ja, aber nicht für 3.5. Ich hatte das schon bemerkt, aber meine Netzwerkinstallation ist nicht die beste, um das zu testen, also schwer zu sagen, ob es am Protokoll liegt).
Alles gut für mich also! Danke!!
Die folgenden 2 PRs warten auf eine Überprüfung:
- Hinzufügen der Unterstützung für Protokolle 3.4 und 3.5:
- Hinzufügen der ersten Bausteine für die Zuordnung Cloud/Lokal und insbesondere die lokale UDP-Erkennung:
@GBoulvin, wenn du PR3 testen möchtest, habe ich ein neues Image terdious/gladys:tuya-PR3 erstellt, insbesondere:
- mit deiner Basis des letzten Tests starten,
- dann einen lokalen Auto-UDP-Scan durchführen
- dann die bereits registrierten Geräte löschen, dich abmelden, dann wieder anmelden und einen neuen lokalen Auto-UDP-Scan starten, um sicherzustellen, dass alles wiedergefunden wird.
Vielen Dank im Voraus.
Für mich ist das mit dem PR2 in Ordnung, es ist gemerged und wird in der nächsten Version von Gladys 
mit dabei sein.
Beim PR3 gibt es nach dem Merge Konflikte, sag mir Bescheid, sobald ich mir das anschauen kann!
Danke für die Entwicklung!
Verfügbar in Gladys Assistant 4.77:
Hallo @pierre-gilles,
Ich kümmere mich gleich darum und schaue es mir an!!
Danke
EDIT: Alles klar bei mir.
Super danke @Terdious! Es ist gemerged!
Ist der PR 4 bereit? 
Hallo @pierre-gilles,
Danke für das Mergen der PR3 
Für die PR4 #2467 ist sie bereit. Ich habe gerade master darin gemerged, um die 3 Konflikte zu lösen, die GitHub angezeigt hat.
Das ist für mich in Ordnung für PR4, es ist gemerged und wird in der nächsten Version von Gladys veröffentlicht
Danke für die PR 
Top, vielen Dank für das Mergen der PR4 und aller vorherigen 
Bei PR5 habe ich gerade master aktualisiert, sie ist bereit zur Überprüfung: #2470
Kleiner Hinweis : Du kannst dir Zeit für diese nehmen, ich würde lieber warten, bis @GBoulvin ein Feedback zum Docker-Image Terdious:tuya-smart-meter (im Bau) gibt, bevor wir mergen. Es ist die erste vollständige Tuya-Integration mit Cloud- und lokaler Verwaltung, und die Cloud-Thing-Model-Strategie ist neu — ein Test unter realen Bedingungen an seinem Zähler schadet nicht, bevor es in die Veröffentlichung geht, auch wenn er es bereits zuvor getestet hat. Wir haben einige Änderungen in den ersten drei PRs vorgenommen (normalerweise nicht beeinträchtigend)
Hallo @GBoulvin
PR5 ist code-seitig fertig und das Docker-Image Terdious:tuya-smart-meter wird in etwa 30 Minuten verfügbar sein (Build läuft).
Könntest du es an deinem Smart Meter testen, wenn du Zeit hast? Das Ziel ist es, unter realen Bedingungen zu validieren:
- die Erkennung des Geräts in der Cloud
- das Lesen der Werte (momentane Leistung, Gesamtenergie, Spannung, Strom)
- die Stabilität des Cloud-Pollings über die Zeit
- die Erkennung des Geräts lokal
- das Lesen der Werte (momentane Leistung, Gesamtenergie, Spannung, Strom) lokal
- die Stabilität des lokalen Pollings über die Zeit
Dein Feedback wird das Mergen bei Pierre-Gilles beeinflussen. Vielen Dank im Voraus 
Edit: Von meiner Seite getestet und funktionierend (aber nicht speziell mit einem Smart Meter getestet ^^)
Hallo @Terdious,
Kleines Problem mit den Zugriffsrechten für dein Testbild (nicht öffentlich?). Falls du einen Blick darauf werfen könntest… Entschuldige für meine langsame Reaktion!
Edit: Ich habe es gefunden: terdious/gladys:tuya-smart-meter 
Hier mein Feedback. Ich habe es getestet und es scheint, dass alles funktioniert. Es ist stabil, ich habe wie ein Wilder geklickt und überall Nullen eingesetzt und alles hat gehalten Die Einheiten sind gut, das lokale und Cloud-Polling läuft ohne Probleme.
Nur eine Sache, die nicht so wichtig ist:
Es steht forword statt forward. Ich bin mir nicht mal sicher, ob das von der PR kommt o:-)
Frage zur Energieerfassung, müssen die Berechnungen „alle 30 Minuten“ noch implementiert werden oder ist das bereits vorgesehen?
Ich lasse es dieses Wochenende laufen, um zu sehen, wie es sich verhält, aber für mich ist alles gut!
Danke @Terdious!
Oups !! ^^ Entschuldigung für den falschen Bildnamen.
Vielen Dank für die Tests 
@GBoulvin
Gut aufgepasst ^^ tatsächlich, der von der Tuya-API zurückgesendete DP-Code für diese Zähler ist wörtlich als energy_forword_a / energy_forword_b geschrieben, also ist es ein Fehler auf ihrer Seite, den ich aus Kohärenz mit der API-Dokumentation übernommen habe… aber es stört mich auch 
@pierre-gilles, was denkst du? Beibehaltung des Fehlers oder Korrektur auf Seiten von Gladys für die Benennung des Features?
Ansonsten, nach den überzeugenden Tests, überlasse ich dir die Prüfung des PR, wenn du Zeit hast
Korrektur auf Gladys-Seite 
Es wäre schade, einen Fehler in unseren eigenen Funktionen zu perpetuieren. 
Nach 48 Stunden Test, kein Bug, keine Abmeldung oder so etwas!
Hallo @pierre-gilles,
Erledigt, die Features wurden umbenannt. Danke dir.
Ich bin bereit, die Überprüfung für PR5 - Hinzufügen der Unterstützung für Smart Meter - zu starten, ich habe sie dir zugewiesen:
PR6, eine PR, die hauptsächlich Korrekturen enthält, wird ebenfalls zur Überprüfung bereit sein:
Danke!!