Lazer

C'est un paramètre au début du script Il parait même que c'est expliqué dans le tuto

Il te dit "services Fibaro non redémarrés après le timeout de 900 secondes" c'est clair Rassure moi, ta box était bien opérationnelle ce matin ? Si cela se reproduit régulièrement, il faudra que tu augmentes ton timeout... mais 900s, ça fait 15 minutes, je trouve ça déjà très long...

OK d'accord, désolé je n'avais pas compris ton besoin. Maintenant c'est clair. On ne peut pas faire un Ping (un vrai, protocole ICMP) avec la Home Center. On contourne le problème en tentant de se connecter sur un port ouvert (en écoute) sur l'appareil à surveiller. Donc protocole TCP uniquement (car le protocole UDP est sans état, donc même si un port UDP est ouvert, tu n'auras pas forcément de réponse, donc impossible de savoir de manière certaine si l'objet connecté est toujours présent ou non) Les ports vont de 1 à 65535. Les protocole de haut niveau (HTTP, etc) sont généralement basés sur TCP. Bon tu connais surement déjà tout ça. Il faut trouver un port qui serait en écoute.... des outils de scan, tel que "nmap", permettent de scanner les ports pour trouver ceux qui sont en écoute, donc ouvert. Ensuite tu peux utiliser mon QA Network Monitor, avec une config permettant d'interroger ce port à intervalle régulier. J'utilise cette technique pour rebooter 2 appareils qui ont la fâcheuse tendance à planter aléatoirement (box Freebox Mini 4K et passerelle APsystems ECU-C) Le QA Network Monitor incrémente une variable, celle-ci est surveillée par GEA, et au bout d'un certains temps => reboot forcé par action sur un Wall Plug.

Bon courage pour trouver une API locale sur ce genre de prise, conçue initialement pour être utilisée via leur Cloud. Pourquoi avoir pris ce genre de produit jetable, et pas une classique prise Z-Wave ou Zigbee ? Au moins tu aurais eu l'intégration native, sans dépendre d'un cloud qui s'arrêtera un jour plus ou moins proche. Une (très) rapide recherche Google me montre qu'il y a une API cloud, la possibilité de discuter en local via MQTT avec la prise (mais il te faudra un broker type Mosquitto en plus de la box), mais je n'ai pas vu d'API HTTP locale. Ou alors c'est bien caché.

Analyse intéressante : [nextpit] 4 raisons pour lesquelles la norme de maison connectée Matter échoue

-- ICONES Icones = { Confort = 1007, SdB = 1010, ECS = 1008, Off = 1009 } function QuickApp:UI_Maison_Mode(Chauf_Maison_Mode) -- changer l icône de la pièce api.put("/rooms/239", {icon = "User"..tostring(Icones[Chauf_Maison_Mode])}) end Il faut concaténer "User" avec le contenu de ta table. Pour info le tostring() n'est pas indispensable dans ce cas présent car LUA réalise la conversion de type number => string automatiquement.

Pas cher Passerelle ECU-C de chez APsystems : #grossebouseinfame #lowcost #daube Celle-ci a décidé de planter peu après le début des vacances. Impossible de la redémarrer à distance, elle ne répondait plus sur l'interface Web, l'API, elle ne pinguait même plus. Obligé de la débrancher/rebrancher en rentrant. Bilan, 10 jours de statistiques de production manquantes. Heureusement les micro-onduleurs continuent à produire pendant ce temps là.... Je vais la brancher sur un Wall Plug, pas le choix, et automatiser le redémarrage avec Network Monitor et GEA, comme la Freebox Mini 4K.... Autre chose, depuis le début de son initialisation, seul 1 onduleur DS3-L remontait sur le site Web d'APsystems, impossible de rendre visible le 2nd onduleur. Pourtant celui-ci était bien reconnu en local sur l'ECU. Du coup j'ai pu tester le SAV de chez APsystems, alors là je dois dire qu'ils marquent des points Email envoyé ce matin, réponse 1h après : problème réglé, l'onduleur apparait sur le site Web (et l'application mobile EMA App du coup). Voilà un support efficace en plein mois d'août (je les ai caressé dans le sens du poil, je n'ai pas osé leur dire tout le bien que je pense de l'ECU-C... ) Pour info : support.emea@apsystems.com

Efficace C'est donc une requête PUT

Le GET c'est juste afficher l’icône. Ensuite quand tu modifies l’icône de ta pièce et que tu sauvegardes, tu dois voir une requête POST je pense, avec des datas.

Avec les outils de développeurs de ton butineur sur la toile d'araignée mondiale (en clair : touche F12), tu regardes la requête effectuée lors tu modifies l'icône via le GUI. A mon avis ça va être un requête de type POST sur /api/rooms Il faut juste utiliser les bons paramètres, comme le fait le GUI.

Chez moi tout fonctionne. Le QuickApp en accès local, le site Web d'Enphase, et la remonté des infos dans le cloud : EDIT : pas testé le Live Enlighten, de toute façon ça n'a jamais fonctionné chez moi, je n'ai pas contacté Enphase pour qu'ils réparent le bug, donc ça attendra la mise à jour globale.

Le Bluetooth n'est pas activé sur la HC3, et ne le sera peut-être jamais... Le Zigbee est activé, mais en version Beta, de nombreux périphériques ne sont pas (encore) supportés. Mais normalement les lumières le sont, donc ça devrait être le cas des Philips Hue. Une petite recherche ici sur ce forum, ou bien sur le forum officiel, te permettra de t'en assurer.

La fréquence de communication du CPL entre les micro-onduleurs Enphase et la passerelle est de 110 kHz, ce qui est relativement faible (bien plus faible que les fréquences du CPL utilisé pour le réseau IP... plusieurs MHz). Pas sûr que l'effet de peau soit très significatif à ces fréquences... comme je disais, je pense que les perturbations externes ont bien plus d'influences sur la propagation du signal. Et surtout, comme discuté il y a quelques temps, la "qualité" du câble, à savoir un câble avec le minimum de raccord et de disjoncteurs/différentiels intermédiaires.

Oui ça fait quelques mois Shelly a déjà commencé à sortir les nouveaux modules Qubino rebadgés avec la marque et le look Shelly, avec la dernière puce Z-Wave. Donc ils ont racheté Qubino pour développer la marque, c'est bon signe. Et par la même occasion mettre un pied dans le monde Z-Wave. Reste à savoir s'ils sortiront de nouvelles versions des modules Fil Pilote.... le marché est tellement confidentiel. Du fil pilote en Wi-Fi ça pourrait être sympa aussi.

Et bien tu dis " la pompe est arrêtée pendant que ma box reboot " Donc je suggère de mémoriser l'état de la pompe (pareil que le timer, dans une variable persistante du QA), et lors du redémarrage du QA (dans le onInit) tu vérifies si l'état courant de la pompe correspond au dernier état connu (dans la variable du QA) Avec cette technique tu ne pourras pas détecter un arrêt/redémarrage de la pompe, ou un démarrage/arrêt, mais tu pourras juste détecter le changement d'état.

Oui en programmation on passe notre temps à traiter des erreurs et cas particuliers... Effectivement si le statut de la pompe change pendant que la box est arrêtée, c'est problématique... donc dans le onInit, vérifier si le statut est le même que celui connu précédemment, ou pas. On pourrait aussi imaginer détecter un temps anormalement long, qui pourrait indiquer que la box est restée indisponible pendant plusieurs heures, jours ?

Hum.... là comme ça non désolé pas d'idée précise.... car je n'ai pas eu le courage de lire tout le code pour en comprendre la logique. Mais à lire ton commentaire, peut être mémoriser l'heure dans une variable du QA, qui est persistante, et qu'on peut donc relire au démarrage du QA dans le onInit()

Il faudrait mettre les self:updateProperty() dans les fonctions success(), de sorte que si l'appel HTTP échoue, alors le statut du device n'est pas mis à jour.

Pas sûr que ça change grand chose avec le CPL, qui est tellement dépendant d'autres paramètres (perturbations extérieures types interférences radios, etc) Le truc comme tu l'as rappelé après, c'est que le câble électrique doit être gainé : plastique généralement noir, référence U1000R2V. Moi j'ai tout câblé en monobrin 3G2.5, même si du 3G4 serait encore mieux face aux chutes de tension (ça se calcule.... dépendant de la puissance installée sur le toit et de la longueur du câble) Perso j'ai monté 2 câbles 3G2.5, comme ça le câblage des 2 Q-Relays, correspondant aux 2 champs PV (pente différente) est bien séparé, c'est propre. J'ai mis du 3G2.5 parce que c'est ce qu'on trouve, le 2G2.5 semble rarissime... par chez moi en tout cas.

On peut extraire le code LUA à partir des fichiers FQA en utilisant Notepad++, mais la manip est un peu pénible... J'ai ajouté les fichiers LUA à la fin du tuto.

Avec du "Yellow", une sorte de graisse, ça peut aider à passer l'aiguille dans la gaine

Tu as le lien vers mon QuickApps plus haut sur cette même page. Mais ça ne sera pas applicable dans les VD sur HC2... de plus net.FHTTP ne permet pas de manipuler les headers. Donc obligé de passer par une scène avec httpClient() PS : oui effectivement c'est pour cela que je n'ai pas parlé d'énergie primaire, car là le calcul serait autrement plus compliqué... pour bien faire il faudra faire le calcul pour chaque tranche horaire en fonction du mix énergétique, ce qui est quasi impossible... Réflexion tout aussi valable pour le bois et le gaz, car il faut bien aller le chercher...

Dans le onInit()

Je ne suis pas sûr de bien comprendre la question... tu cherches à passer 2 câbles réseaux dans 1 gaine qui ne permet de passer qu'un seul câble ? Effectivement c'est compliqué.... Dans ce cas il faut trouver un autre chemin. Perso je suis allé jusqu'à démonter des placards pour passer les câbles derrière, percer ma dalle béton, creuser la terrasse pour faire passer les gaines en dessous, et même détuiler la moitié du toit... EDIT : et remplacer les vieux câbles coax dédiés à la TV par du câble réseau.

Je n'ai pas le temps de t'écrire un QA complet, mais voici la façon de faire les requêtes HTTP :