jojo

ça semble super ta prise ! As-tu un lien ?

ah ok, ça me parait en effet plus judicieux.

@Lazer, je te remonte une fonctionnalité qui a disparu : Pouvoir éditer/supprimer ses posts

en effet j'avais déjà vu ses vidéos, mais je n'avais pas réussi à implémenter le VPN L2TP sur mon USG (mais mon routeur est connecté à mon modem qui est en mode bridge, ce qui est (je crois) proche de ,la config de Michaël). Quoi qu'il en soit, je vais d'abord changer mon switch puis passer au Dream Machine Pro, mais il faut d'abord gagner au lotto. Si tu utilises la solution VPN pour ton Doorbird, ça veut dire qu'elle est 24/7 activée sur ton GSM ?

je ne comprend pas bien la différence entre la "Dream Machine Pro" et la "Dream Machine SE", si ce n'est le PoE sur le SE. Mais si on a un switch PoE derrière, la pro serait suffisante ? Ou il y a un point important que j'ai loupé ?

j'avais fait à l'époque un petit tuto pour se connecter à Yubi sans FibaroID : pour se connecter à la box, je n'utilise pas non plus le fibaroID, mais fibaro.mondomaine.moi où mondomaine.moi est hosté chez OVH et j'ai un HAProxy configuré comme il faut chez moi

toutes les amélioration sont dans la future v1.2, qui n'est pas encore publiée

en effet, très étrange comme résultat : il n'y a que les paramètres ? Voici un exemple de json que j'ai pour un Wall-Plug z-wave: content.json

que donne le json de l'appareil ? http://<user>:<pwd>@<IPBox>/api/devices/<idDevice>

Great these coming improvement ! Do not forget to add the variable to keep the name of the child devices, as I just spend few hours to understand why sope of my QA crached, and this was because they refered to non existing items in a table ... So, it is important (for me) to be able to keep the name I "want". => THANK YOU

bienvenue et content que tu commences à y trouver ton bonheur

regénère de nouveaux tokens ?

a variable in the variable QA tab or one at the beginning of the code ?

Since you work on a next version, could you please include what I consider a VERY small bug : To comply with my HC3 naming convention, I changed the name of the child devices. And after a few minutes, it comes back to the original name. This is also important to keep the one provided, as we do use an automatic Devices name/id generator for eg GEA. Thank you.

Great QA ! Much more interesting info in the child icons ! and it resist to automatic backups !

I will replace the installed version by yours and hope it will be better

Indeed I use GSmart v2.7. I didn't knew there was several versions/Developpers.. Your version is the one with the alternate auth server ?

nice , but then why at least @Lazerand I have problems during the backup process ? As it does not last 3 hours, but could be possible that the box is not up within the 10 min time frame.

suggestion for next release (2.8 ?) : 1) create QA variable <Connexion> : Ok|not Ok (to be able to generate actions with GEA) 2) send an e-mail when lost|return of conexion

Je l'utilise uniquement comme sonde de température intérieure d'une de mes pièces, car sans piles et sans soudures ... Sinon du même avis que toi, c'est un bel objet de déco ...

Je crains que tu ait raison ... Suite au backup automatique de cette nuit (via script de @Lazer) j'ai à nouveau perdu la connection, et je dois regénérer des tokens. Quel ennui de devoir le refaire tous les dimanche matins

Les relais des FGS et WP sont probablement différents. Si tu as le soucis uniquement avec tes rubans, c'est peut-être à cause du transfo ?

en effet, ce sont des ampoules standard en 200V (avec look spots, mais petit car dans plafond des pièces à vivre) qui ont remplacé des spots halogènes alimentés en 12V par des gros transfos dans le garage => bye bye aussi les pertes de rendement des transfos. (mais on s'écarte du sujet du topic)

très instructif tout ce que vous dites. Mais j'ai bcp de FGS qui commandent les éclairage LED (spots 220V), et je n'ai jamais eu de soucis. Car s'il faut rajouter 2 limitateurs de courant à 18€ par module, ça finit par faire cher le module.

Lorsque je connecte mes 2 neurones (donc sans aucune preuve de ce que j'avance) Je dirais oui car : Pour un message sécurisé envoyé par la box au module (et réciproquement) C'est l'émetteur qui encrypte le message Il est donc illisible par tous les modules qui le relaient (même les sécurisé) il est décrypté par le seul qui a la clé, le destinatiare. Chaque module sécurisé comporterait donc sa clé, et la box devrait donc connaitre les clés de tous les modules sécurisé. Mais je raconte sûrement des bêtises, car vous avez tous plus que 2 neurones.