¡Sin problema, sin prisa!
Para mí, la PR2 - protocolo 3.5 funciona correctamente. No lo he probado en mi producción, pero puedo hacerlo si es necesario.
Gracias @GBoulvin,
He actualizado la imagen de Docker, que ahora también admite el 3.4: ahora se enruta hacia el fork @demirdeniz/tuyapi-newgen (el mismo que gestiona el 3.5), y se ha añadido un analizador de versión 3.4 al escaneo UDP local entre los analizadores 3.1 y 3.5. Puedes volver a probar cuando quieras con la nueva imagen.
Si es posible, también probar el escaneo UDP (independientemente) para asegurarse de que todo funcione. Gracias de antemano
De mi parte, normalmente no es necesario: los cambios añaden un enrutamiento estrictamente desencadenado por protocolVersion === '3.4' o '3.5'. Los dispositivos 3.1 y 3.3 siguen utilizando la librería tuyapi heredada sin ninguna modificación en la ruta de llamada — por lo tanto, no hay riesgo de regresión en lo que ya funcionaba.
Dicho esto, si quieres aprovechar la oportunidad para validar en tu producción, es todo indicado: tus dispositivos 3.4 (que no funcionaban) deberían ser ahora funcionales, y tus dispositivos 3.1/3.3/3.5 deben permanecer igual que antes. No hay obligación, es solo un bonus si tienes 5 minutos.
EDIT :
Para información @pierre-gilles, he renombrado la PR nombrando explícitamente la adición 3.4 además de 3.5, los dos pasando por la misma librería. La PR es un poco más grande, pero seguimos por debajo de las 600 líneas de cambios, son principalmente las pruebas las que son significativas (representan la mitad de las líneas añadidas)
Pregunta tonta, quizás, pero, ¿la imagen sigue en la misma etiqueta (pr1)?
Sí, siempre ^^ Mejor preguntar ^^
¡Hola!
He probado la versión disponible y el protocolo 3.4 se detecta y funciona directamente. También se detecta la dirección IP local (para el 3.4, sí, pero no para el 3.5. Ya lo había notado, pero mi instalación de red no es la mejor para probarlo, por lo que es difícil afirmar que se debe al protocolo).
¡Todo bien para mí entonces! ¡Gracias! !
Las 2 siguientes PR están en espera de revisión:
- Añadir soporte para los protocolos 3.4 y 3.5:
- Añadir los primeros bloques de mapeo cloud/local y, en particular, la detección UDP local:
@GBoulvin, si quieres probar la PR3, he creado una nueva imagen terdious/gladys:tuya-PR3, en particular:
- partiendo de tu base del último test,
- luego realizando un escaneo local auto UDP,
- luego eliminando los dispositivos ya registrados, desconectándote, volviéndote a conectar y lanzando de nuevo un escaneo local auto UDP, para asegurarte de que todo se encuentra correctamente.
Gracias de antemano.
¡Me parece bien para la PR2, está fusionada y saldrá en la próxima versión de Gladys!
Para la PR3, hay conflictos después de la fusión, ¡avísame cuando pueda echar un vistazo!
¡Gracias por el desarrollo!
Disponible en Gladys Assistant 4.77:
¡Muchas gracias @Terdious! ¡Ya está fusionado!
¿Está lista la PR 4? 
Hola @pierre-gilles,
Gracias por el merge de la PR3 
Para la PR4 #2467, está lista. Acabo de hacer merge de master en ella para resolver los 3 conflictos que GitHub señalaba.
Me parece bien para la PR4, está fusionada y saldrá en la próxima versión de Gladys 
Gracias por la PR 
Top, gracias por el merge de la PR4 y todas las anteriores 
En cuanto a la PR5, acabo de actualizar master también, está lista para revisión: #2470
Punto de atención : puedes tomarte tu tiempo con esta, preferiría esperar el feedback de @GBoulvin sobre la imagen Docker Terdious:tuya-smart-meter (en construcción) antes del merge. Es la primera integración completa de Tuya en gestión cloud + local, y la estrategia de Thing Model en la nube es nueva — una prueba en condiciones reales en su medidor no viene mal antes de que se lance, aunque ya lo haya probado antes, hemos hecho algunos cambios en las 3 primeras PR (normalmente no impactantes)
Hola @GBoulvin
La PR5 está lista en cuanto al código y la imagen Docker Terdious:tuya-smart-meter estará disponible en unos 30 minutos (construcción en curso).
¿Podrías probarla en tu Smart Meter cuando tengas un momento? El objetivo es validar en condiciones reales:
- la detección del dispositivo en la nube
- la lectura de los valores (potencia instantánea, energía total, voltaje, corriente)
- la estabilidad del polling en la nube a lo largo del tiempo
- la detección del dispositivo localmente
- la lectura de los valores (potencia instantánea, energía total, voltaje, corriente) localmente
- la estabilidad del polling local a lo largo del tiempo
Tu feedback condicionará el merge por parte de Pierre-Gilles. ¡Gracias de antemano 
Edición: De mi lado probado y funcional (pero no probado específicamente con un smart meter ^^)
Hola @Terdious,
Parece que hay un pequeño problema de permisos con tu imagen de prueba (¿no es pública?). Si puedes echarle un vistazo… ¡Disculpa mi falta de reactividad!
Edito, lo encontré: terdious/gladys:tuya-smart-meter 
Aquí está mi feedback. Lo he probado y parece que todo funciona. Es estable, he hecho clic como un loco y he puesto ceros por todas partes y todo ha aguantado Las unidades son correctas, el polling local y en la nube funcionan sin problemas.
Solo una cosa sin mucha importancia:
Pone forword en lugar de forward. Ni siquiera estoy seguro de que venga de la PR o:-)
En cuanto a la contabilización de energía, ¿los cálculos « cada 30 minutos » aún deben implementarse o ya están previstos?
Voy a dejarlo funcionando este fin de semana para ver qué tal va, pero para mí, ¡todo está bien!
¡Gracias @Terdious!
¡Ups! ^^ Disculpa por el mal nombre de la imagen.
Muchas gracias por las pruebas 
@GBoulvin
Bien visto ^^ de hecho, el código DP devuelto por la API de Tuya para estos contadores está literalmente escrito como energy_forword_a / energy_forword_b, por lo que es un error de su parte que he replicado por coherencia con la documentación de la API… pero en efecto, también me molesta 
@pierre-gilles, ¿qué opinas? ¿Mantener el error o corregirlo en Gladys para el nombre de la función?
De todos modos, tras las pruebas convincentes, te dejo a ti la revisión de la PR cuando puedas
Corrección en Gladys 
Sería una pena perpetuar un error en nuestras propias funciones. 
¡Después de 48 horas de prueba, ni un solo error, desconexión o nada!
Hola @pierre-gilles,
Hecho, renombrado de las características. Gracias a ti.
Para mí está bien para lanzar la revisión en la PR5 - Añadir soporte para Smart Meter, te la he asignado:
La PR6, PR que agrupa principalmente correcciones, también estará lista para la revisión:
¡Gracias! !