jjacques68

ce que je constate aussi, c'est qu'elle met plus de temps à démarrer... M'en suis rendu compte avec le backup auto. J'ai du mettre le timeout général à 15 min. La taille du fichier est toujours de 24-25 Mo. Le cycle de backup complet (avec téléchargement du fichier) prend un peu plus de 10 min. bref rien de grave mais ça évolue... au fait @Lazer tu as pu jeter un œil sur ton script de backup auto depuis nos bug de l'autre fois ? actuellement, j'ai toujours mon pseudo-script windev qui tourne à la place...

tu as raison, chose faite. merci...

alors je viens d'essayer un petit module Zigbee : Xiaomi Mi GZCGQ01LM - Capteur de luminosité (16€ - amazon) en vu de remplacer les capteurs de LUX Everspring ST815 qui vieillissent très mal et qu'on trouve plus... Ben c'est pas mal du tout : le range est de 0-83000 lux (comparé au ST815 qui va que jusqu'à 3000 lux) Par contre, usage intérieur... je l'ai quand même mis dehors pour vois comment il se comporte... après vu le prix... Pas d'options de paramétrage, c'est très rudimentaire. Le changement de valeur met quelques secondes à remonter... Petite erreur, dans l'API, son unité de mesure est en % au lieu d'être en LUX (pourtant "LX" apparait dans l'interface web, alors d'où il sort ça ... ???) Corrigé avec un api.put(). EDIT : ah ben nan, c'est marrant, le "%" reviennent systématiquement dans l'API... Les remontés dans l'API RefreshState() sont nickel, comme un module Zwave ! Plutôt satisfaisant pour un premier contact

oui moi aussi, ça m'a rendu fou, j'ai désactivé toutes les notifications de tous les device à batterie. Et je me suis fait un petit QA qui tourne 2x par jour pour vérifier l'état. Avec compte rendu par mail.

semble ok chez moi aussi...

nan rien du tout. j'ai abandonné la chose. Le plus simple resterait de quand même passé par une socket TCP. Mais jamais testé avec le S7...

MAJ ok pour moi, RAS pour le moment...

Cela m'a été demandé en MP, donc je partage mon QA IPX (version Parent/Child) (POUR UN IPX version 3 et non version 4 ou 5) . Différent de celui présenté en début de ce topic... Edit du 03/08/2022 : il faut que que le firmware de l'IPX soit minium en 3.05.74B et le site en 3.05.74 contacter GCE pour la mise à jour. Fichier : IPX.fqa Je fais pas de tutos complet car pas le temps... Mais très rapide description pour se lancer, après je vous laisse adapter à vos besoins. 1. il faut activer cette option dans l'IPX : de cette manière à chaque changement d'une valeur dans l'IPX, une trame est envoyée à la HC3. 2. Renseigner les 3 variables dans le QA (onglet variable). l'IP de l'IPX, le password (en clair - je sais... no comment... ) et le port (9898) 3. Renseigner la variable "Liste" dans le code : selon vos entrées/sorties de l'IPX. _Name = le nom de votre QA Child _var = le N° entrée ou sortie dans l'IPX _varName = suivant si c'est une entrée ou une sortie : entrée = IPX_INPUT ; sortie = IPX_OUTPUT local Liste = { {_class = "IPX_OUT", _name = "Eclairage NORD", _type = "com.fibaro.binarySwitch", _var = 3, _varName = "IPX_OUTPUT", _icon = 1068}, {_class = "IPX_OUT", _name = "Eclairage SUD", _type = "com.fibaro.binarySwitch", _var = 4, _varName = "IPX_OUTPUT", _icon = 1068}, {_class = "IPX_OUT", _name = "Eclairage OUEST", _type = "com.fibaro.binarySwitch", _var = 5, _varName = "IPX_OUTPUT", _icon = 1068}, {_class = "IPX_OUT", _name = "Eclairage Escalier", _type = "com.fibaro.binarySwitch", _var = 7, _varName = "IPX_OUTPUT", _icon = 1068}, {_class = "IPX_IN", _name = "IN7", _type = "com.fibaro.binarySensor", _var = 7, _varName = "IPX_INPUT", _icon = 1068}, {_class = "IPX_IN", _name = "IN8", _type = "com.fibaro.binarySensor", _var = 8, _varName = "IPX_INPUT", _icon = 1068}, } Ici je n'utilise que 2 type de QA Child (binarySwitch et binarySensor) S'il en fallait d'autres, à vous de modifier le QA Parent en conséquence. Le numéro de l'icône correspond à mes besoins, je vous laisse donc gérer vos ID d'icones Le bouton "CreatChild" permet de créer les child listé ci-dessus. Remarque concernant le compteur : Je n'utilise qu'un seul compteur, qui n'a pas de QA Child propre à lui. Je récupère la valeur de ce compteur dans la trame de l'IPX pour l'envoyer à un autre QA totalement indépendant.

hmm... J'ai reproduit ton script avec Windev. Aucun soucis sur le PC de dev. Quand j'ai exécuté le script sur un autre PC, une requête http est tombée dans un timeout, celle pour récupérer le fichier justement. J'ai porté à 30 secondes le timeout des requêtes http, et plus de soucis... !! J'ai regardé dans ton script, mais je ne trouve pas le timeout des requêtes Y a bien le "Backup timeout" mais c'est pas la même chose. Bref... peut-être une piste... quand tu auras le temps... pas d'urgence !

ah ! on est d'accord donc Mouai va falloir creuser d'avantage là...

elle a été copié dans le répertoire cible ?

Vou sne rencontrez pas de soucis depuis la mise à jour 5.101.19 ? moi j'ai ça dans le fichier de debug du script : Erreur : services Fibaro non redémarrés après le timeout de 900 secondes Reboot forcé du Home Center... Erreur : impossible de forcer le reboot de la box Fibaro : code de retour HTTP 404 Mais le backup est bien visible dans la liste sur la HC3... EDIT : étrange, car très vite, tous les services sont à "true" (HCServer.runnning, Zwave.running et FibaroServices.running) Mais il sort pas de la boucle de check... ?

Alors moi j'ai eu de sacrés mauvaises surprises avec Amazon et des piles de marques connues ! Piles clairement déchargées. La je suis entrain de m'équiper avec les piles rechargeable par USB. pour les modèles classiques (1.5 V LR6 LR3, 9V, ...) qui semblent plutôt bien fonctionner. ça fait quelques mois que je teste, suis content.

RAS pour moi...

je vais dire peutêtre une bêtise, mais sers toi que et uniquement que du status du QA ! Pas besoin de variable...

Problème réglé en mettant, dans le RequestID de la trame SNMP, l'ID du ChildDevice. Ducoup, lorsque le Parent reçoit la réponse SNMP, je sais d'office à quel Child ça s'adresse. Et comme l'ID des child est unique, ça marche nickel...

oui oui je sais à quoi m'attendre, pas de soucis...

Disons que j'ai pris ce qui m'était utile pour mon cas... et j'ai simplifié. En gros je formate le paquet dans un tableau d'octets, puis je fais le send. Exemple pour la réception d'un paquet, je choppe le 4ème octets en partant de la fin pour avoir le N° du port, puis le dernier pour avoir la valeur. Sans plus. Si les données changent de type, ou sont sur plusieurs octets, ça marche plus Tu vois le genre de simplifications que j'ai fait... ah mais tu passes par des requêtes HTTP alors ?

Bon ben j'ai fais ce que je voulais. Je rappelle, allumer/éteindre mes nouveaux AP wifi depuis la HC3. Donc je pilote cela en SNMP via le switch POE, vu que les MIB des AP sont foireux. J'ai donc : 1 QA parent contenant les fonction de socket UDP n QA Child par port du switch que je veux piloter. Le retour d'état pour mettre à jour les Child, se fait par analyse de la réponse à la trame SetRequest. Merci beaucoup @Lazer pour ta library. Je m'en suis beaucoup inspiré. Par contre, avec mon principe de QA Child/parent, il y a le soucis avec le coup de plusieurs utilisation des ressources du parents par plusieurs Child simultanément. C'est le bordel, ça se mélange. Et c'est normal. Pour bien faire, il faudrait faire, soit une QueueListe, soit comme disait @Lazer, gérer le RequestId de chaque échange. Que l'on récupère à la réponse. Bref dans mon cas, pour 3 ports, j'ai simplement temporisé on verra plus tard.

pas de soucis chez moi... je tag de cette manière : __TAG = string.format("QA_%s_%s", self.id, self.name)

question : La fonction SNMP:sequence() n'est pas utilisée ? on est d'accord ?

ben comme je l'ai mis : ID = setTimeout(...) jamais utilisé, je sais même pas si c'est possible...

ah oui exacte, et cet ID revient dans la réponse. @mprinfo : c'est pas un truc du genre : MonID = setTimeout(...) clearTimeout(MonID)

excellent ! merci !

je donne des news : le support technique de Netgear confirme que le MIB "propriétaire" des points d'accès WAC510 sont obsolètes. Donc je laisse tombé de ce côté là. du coup, je coupe le wifi en coupant le POE des ports qui alimentent les PA. et cela via le SNMP du switch, en utilisant les OID standard. par contre question bonne pratique : j'ai créé un QA parent et x QA child selon le nombre de port à gérer. J'ai mis la gestion de la socket UDP (write et receive) dans le parent. Ce qui veut dire que les child appellent ces méthodes dans le parent. Que se passe-t-il si plusieurs child veulent accéder à la méthode write du parent quasi simultanément ?