Lazer

Tu as encore choppé des chats noirs....

Hum... du coup en comparaison ton taux d'occupation CPU du QA GEA parait élevé.... après je ne sais pas dire pourquoi...

Je trouve que c'est beaucoup.... tu as combien de règles GEA ? De mon coté, j'ai dépassé les 300 je crois.

Non pas à ma connaissance....

[Frandroid] Un seul appareil pour Apple, Google et Alexa : c’est la promesse de Matter 1.6

Le Log de GEA dit quoi sur la consommation CPU ? Par exemple, ici tout va bien. De façon générale, dans tous mes QuickApps j'ai des lignes de logs similaires qui me permettent de détecter un QA qui pèterait les plombs... en CPU comme en RAM. Car il faut trouver le coupable, ce n'est pas forcément GEA, car il est peut être lui-même impacté par un autre QA qui boufferait tout le CPU.

Ah si complètement Désolé pour la typo !

C'est dans la tendance amorcée depuis plus d'un an : rendre TEMPO totalement inintéressant pour forcer les abonnés à se détourner de cette offre. Ce que je ne comprend toujours pas, puisque les tranches horaires de Tempo ne correspondant plus aux nouveaux besoins d'équilibrage du réseau électrique (solaire à midi, etc), c'est pourquoi ne pas faire évoluer les tranches horaires elles-même de Tempo....

Les API pour voir les types supportés : /api/quickApp/availableTypes /api/devices/hierarchy

Je n'ai pas le temps de vérifier, mais quelques pistes : Si tu as déjà un module de type portail/gate, il faudrait regarder dans son JSON quel est son "type" : Si c'est différent de ton Quickapp "portail avec retour d'information", alors l'astuce est d'exporter ton QA, modifier le type à la main le fichier FQA avec un éditeur de texte, puis le réimporter. Si le type est identique, alors ce n'est pas la bonne piste, il faut chercher du coté des autres propriétés pour voir ce qui peut être modifiée (en LUA et/ou via l'API) pour lui donner les bonnes caractéristiques.

Tel quel non il ne sera pas compatible, car l'API a complètement changé depuis l'IPX800 v5... que je n'ai déjà pas pris le temps d'intégrer. Le QuickApp est modulaire, un fichier main, et une librairie dédiée à l'interfaçage avec l'API des produits GCE, et c'est ce dernier fichier qu'il faudrait adapter. Donc du boulot en perspective.... mais de mon coté ce n'est pas prévu prochainement... désolé... Si quelqu'un a le courage de se lancer, ça serait top.

Merci, pour l'instant ça va on a un peu d'avance dans les comptes. Si j'héberge à domicile, il faudra juste que je prenne un abonnement pour l'envoi des emails, c'est pas très cher.

Tiens, j'ai vu Octave Klaba aujourd'hui, le patron d'OVH Du coup, j'en profite pour vous dire que j'ai un peu avancé, j'ai réussi à redémarrer une instance du forum sur mon serveur à la maison, ce n'est pas encore 100% fonctionnel mais c'est en bonne voie. Car l'échéance du renouvellement de l'hébergement OVH c'est au 1er juillet, donc ça me motive, si on peut faire cette économie là, car ils ont sérieusement augmenté leurs prix !

Perso je passe mon tour car cette nouvelle version ne supporte pas toutes les extensions qu'on avait avant, et notamment le X8D qui me permettait d'ajouter des entrées numériques pour compteur à impulsion. Dommage, espérons que ça arrive plus tard....

Top ça Si je bascule mes caméras sur UniFi, je prendrai le nouveau Network Video Recorder G2... plus cher mais plus puissant et embarquant des fonctionnalités qui nécessitaient un module externe avec la gamme précédente, notamment l'AI Key.

On constate que "water_box_status" a toujours la valeur 1 sur ton robot, même avec le réservoir vide. On dirait bien qu'à cause de la présence du dock, le robot considère que son réservoir n'est jamais vide, certainement car il peut aller se remplir tout seul. J'ai trouvé ceci qui donne les valeurs pour "dock_error_status" : https://github.com/copystring/ioBroker.roborock/issues/36#issuecomment-1408613528 "dock_error_status": 0 => All OK. "dock_error_status": 34 => Charging station blocked during automatic emptying. Dustbin, filter, or air duct is clogged. Check and clean the components. "dock_error_status": 38 => Hall sensor for clean water tank triggered. Check if the clean water tank is correctly inserted or refill it as recommended. "dock_error_status": 39 => Check the dirty water tank. Check if the dirty water tank is correctly inserted or empty it as recommended. "dock_error_status": 46 => Dustbin not installed. Reinsert the dustbin with the bag and try again. Il faudrait faire d'autres tests avec le réservoir plein/vide, et de même pour le dock, afin de voir comment évolue la valeur de "dock_error_status", peut être que c'est la bonne piste, mais peut être pas. Et ensuite, faire des modifications qui vont bien dans le code source du QuickApp.... si tu as le courage, désolé mais de mon coté je ne vais pas avoir le temps de le faire.

Top, bien vu, c'est exactement ça Merci pour le partage

Aucune idée.... mais l'absence de template/modèle, ce n'est pas le problème. Le problème, particulièrement avec les modules Qubino Fil Pilote, c'est le firmware buggé qui ne répond pas correctement aux requêtes lors de l'interview initiale (inclusion). Donc j'ai quelques doutes sur la prise en charge de ces modules... là est la question.

Oui, effectivement, j'ai un conseil

Il y a un article intéressant et bien détaillé concernant les nouveautés de l'API liées au nouveau moteur Z-Wave v3 sur le forum officiel : [forum.fibaro.com] Z-Wave engine 2.0 -3.0 Migration. Changes in API

ça date, mais tu as vu ce message ? Sinon, on peut faire du MD5 dans les QuickApps sur HC3 à l'aide des librairies sha partagées par @tinman sur le forum officiel : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/31/?tab=comments#comment-212984 Tu as un exemple d'utilisation dans mon QuickApp Xiaomi Roborock si tu es motivé pour fouiller dans le code source : En gros une fois que tu as importé la librairie sha dans ton QA, tu peux faire un (en tout cas c'est comme ça que je l'ai utilisé) : local key = sha.hex2bin(sha.md5(self.token))

Installée sans souci sur ma box de test

Merci pour le log détaillé, mais je vois que water_box_status = 1, ce qui indique que le réservoir est rempli. Sur mon modèle, j'ai bien 0 avec le réservoir vide. Donc si l'API de ton robot indique toujours 1 pour cette valeur, malheureusement impossible pour le QuickApp de savoir ce qu'il en est vraiment. Après, est-ce que c'est un bug, ou bien un changement de l'API sur ton modèle qui est probablement plus récent ??? (message "Attention : this vacuum model is unknown and may not be supported") Désolé mais là tout de suite je sèche un peu...

Oui et ça fonctionne même déjà très bien

Montage Composants Les processeurs Intel Xeon arrivent dans des emballages individuels, se sont des versions "tray" normalement prévus pour l'intégration directe dans un serveur, donc pas d'emballage en boite marketing comme pour les processeurs grands publics : Les lingots d'or barrettes RAM DDR5 ECC (dont le prix a été multiplié par 5 entre l'achat et 3 mois plus tard, et elles ne sont carrément plus disponibles depuis) : Les SSD M.2 NVMe : Le ventirad SilverStone AR09-1700 faible hauteur destiné au boitier 2U, avec le ventilateur de remplacement Noctua NF-A6x25 PWM : Processeur Intel Xeon 6357P en cours de montage sur la carte mère ASRock Rack EC266D4U : SSD Kingston DC2000B installé sur la carte mère ASRock Rack EC266D4U dans le boitier 2U SilverStone RM23-502-MINI : Boitier 2U SilverStone RM23-502-MINI Vue de l'intérieur du boitier 2U SilverStone RM23-502-MINI, on voit le ventirad SilverStone AR09-1700 avec son ventilateur Noctua NF-A6x25 PWM, et la carte réseau Intel X710-DA2 : Vue arrière du boitier 2U SilverStone RM23-502-MINI, qui permet de voir l'alimentation Cooler Master MWE Gold 750 V3 ATX 3.1 qui fonctionne en passif à faible charge, et dont l'extraction de l'air chaud se fait par une grille percée dans le capot supérieur du boitier : Détail de l'intérieur du boitier SilverStone RM23-502-MINI, permettant de visualiser le SSD Micron 7500 Pro au format U.3. Ce boitier est livré avec une cage disque que j'ai retiré car elle faisait obstruction à l'un des 2 ventilateurs Noctua NF-A8 PWM chromax.black.swap. J'ai imprimé en 3D un support pour ce SSD en PETG gris afin de fixer solidement le SSD tout en lui assurant un refroidissement optimal : Boitier 4U SilverStone RM41-H08 Vue avant permettant de voir les 2 ventilateurs d'extraction arrière Noctua NF-A8 PWM (qui remplacement les ventilateurs SilverStone d'origines trop bruyants), ainsi que le SSD U.3 Micron 7500 Pro en premier plan. Cette cage disque interne comporte 2 autres SSD SATA Samsung 870 EVO non visibles sur les photos. J'ai également ajouté 2 ports USB sur équerre PCI à l'arrière parce qu'il y a des ports disponibles sur le carte mère, donc pourquoi pas : Vue permettant de visualiser les 2 cages disques hot-swap SilverStone FS305-12G (1 seule est fournie de base avec le boitier) dont j'ai remplacé les ventilateurs SilverStone d'origines trop bruyants par des Noctua NF-R8 redux-1200 : Vue permettant de voir le ventirad Noctua NH-U9S, la carte réseau Intel X710-DA4, la carte HBA SAS Broadcom 9500-8i, ainsi que son câble pieuvre SlimSAS SFF-8654 to 8x SATA vers les différents disques : Vue avant du boitier SilverStone RM41-H08 montrant le détail de la cage hot-swap SilverStone FS305-12G pouvant contenir 5 disques durs, ainsi que la cage hot-swap Icy Dock ToughArmor MB411SPO-1B contenant un SSD Samsung SATA 870 EVO : Vue de l'intérieur de la cage hot-swap SilverStone FS305-12G afin de montrer les connexions SATA, chaque disque dur vient directement s'insérer dedans sans nécessiter d'adaptateur : Boitier Jonsbo NV10 Black Support des composants de protection de l'alimentation DC, réalisé en impression 3D en PETG avec inserts filetés : Bloc de protection DC complet, avec connecteur XT-90, interrupteur et porte-fusible en façade, et à l'intérieur la ferrite et la carte de protection électronique comportant les diodes et condensateurs. Après la photo j'ai emballé le connecteur externe XT-90 sur son câble avec de la gaine thermorétractable. On aperçoit également le câble d'alimentation CPU 8 pin qui va se brancher sur la carte mère : Dans la partie supérieure du boitier Jonsbo NV10, se trouvent la carte-mère ASRock Rack EC266D2I au format Mini-ITX, le ventirad Noctua NH-L9i-17xx chromax.black, le SSD Kingston DC2000B, et le riser PCI-Express déporté vers le dessous du boitier : Dans la partie inférieure du boitier Jonsbo NV10, on peut voir en premier plan le bloc support de protection d'alimentation DC (de la colle chaude permet de maintenir les composants en place sur la plaque d'essai à trous, ce n'est pas très esthétique mais ça garantie que ça ne bougera jamais). En peut également voir le SSD U.3 Micron 7500 Pro sur un support sur mesure en impression 3D afin de le faire tenir sur un emplacement PCI, juste devant la carte réseau Intel X710-DA2. En haut de la photo, sur le coté du boitier, une impression 3D permet d'ajouter des ventilateurs d'extraction forcée Noctua NF-A4x10 PWM. Il n'y en n'a que 2 sur la photo, mais je vais en ajouter un troisième car en pratique ça chauffe beaucoup à cause du SSD : Vue arrière du boitier Jonsbo NV10, on voit la carte réseau PCI, et le bracket PCI imprimé en 3D pour le SSD avec des ouïes de ventilation : Vue du boitier Jonsbo NV10 sous tension avec tous les câbles connectés, notamment les 2 câbles DAC à 10 Gbps : Comparatif de la taille des boitiers Empilement de : Switch UniFi Aggregation Switch UniFi Pro HD 24 PoE Boitier SilverStone RM23-502-MINI Boitier SilverStone RM41-H08 Vue arrière de : Boitier Jonsbo NV10 Black Boitier SilverStone RM23-502-MINI Boitier SilverStone RM41-H08 Pendant les premières semaines j'ai réalisé l'installation initiale des nœuds et la configuration du cluster dans un coin de mon bureau, on peut également voir un bien connu Microserver HP Proliant Gen8 (qui tourne sous Proxmox Backup Server pour l'instant). Ne pas faire attention au câblage réseau qui était très temporaire au moment de la photo, c'était lors de la toute première initialisation des noeuds avec uniquement les connexions IPMI (port de management intégré à la carte mère) sur un petit switch UniFi 8 :