Lazer

Mais tu comptes rester sans accès Internet ? Dans ce cas il est préférable de concevoir une domotique totalement indépendante du cloud, ce qui exclue le pont Hue, ainsi que la grande majorité des produits connectés grand public.

Mettre ta SIM dans un routeur 4G connecté en Ethernet sur ton Switch/routeur. Huawei en fait par exemple, on en trouve d'occasion à pas trop cher sur eBay qui viennent des autres pays d'Europe. Je ne sais pas s'il y a d'autre solution simple. Brancher le téléphone sur un PC imposerait d'utiliser Linux pour faire du routage des paquets, c'est tout de suite beaucoup plus compliqué.

Si ça se trouve, sur HC2 ils ont fait comme sur HC3.... c'est à dire la suppression de la possibilité de rebooter la box via le code LUA. Je n'ai plus d'HC2, donc je ne pourrai pas investiguer d'avantage.

De mon coté, non désolé pas encore.

Désolé trompage de topic, j'ai effacé mon message et reposté au bon endroit avant que tu ne postes Pour ta réponse, sache que tu peux découvrir toute l'API en utilisant les outils de dev du navigateur (avec F12) quand tu es sur l'interface Web de la HC3. Puisque tout passe par l'API, c'est très pratique. Après tout se passe comme d'habitude avec fibaro.call() (ou hub.call() sur les firmwares récents si tu préfères) : fibaro.call(123, "setThermostatMode", "Auto") fibaro.call(123, "setHeatingThermostatSetpoint", 20) fibaro.call(123, "setCoolingThermostatSetpoint", 22) fibaro.call(123, "setThermostatFanMode", "Auto") Sinon pour connaitre les actions et les valeurs de propriétés acceptées par le thermostat, il faut regarder dans son JSON via /api/devices/<ID> Il y a tout ce qu'il faut. Exemple pour le Remotec ZXT-600 : Et là où c'est le plus fort, c'est que si tu crées ton propre QuickApp de type thermostat, tu peux définir tes propres valeurs autorisées, c'est à dire les modes Auto/Heat/etc, les bornes de consigne min/max, etc. Exemple (à mettre dans le onInit() du QuickApp) : self:updateProperty("supportedThermostatModes", {"Off", "Auto", "Heat"}) self:updateProperty("supportedThermostatFanModes", {"Auto", "Low", "Medium", "High"})

Je viens de regarder avec les outils de développement du navigateur en passant par le cloud Fibaro Les requêtes ne sont pas évidentes du tout, il y a toute une encapsulation qui est faite autour de l'API documentée que l'on connait. Exemple pour allumer un Binary Sensor, c'est du style : POST https://home.fibaro.com/newProxyLite?user=1234&hc=HC3-00056789&temp=XXXXXXXXXXX_XXXXXXXXX-XXXXXXXXXXXXXXXXXXXXX&req=/api/devices/100/action/turnOn Sachant qu'il y a également des données dans la requête : {"args":[56,"turnOn"]} Et également un cookie passé dans les en-têtes de la requêtes (cookie probablement issu lors de la phase d'authentification sur la page Web) Bref, c'est chaud, vraiment chaud.  Pas certain que ça vaille la peine de passer des heures à comprendre le fonctionnement pour le reproduire, sachant que c'est sans garantie de succès, ce n'est pas documenté, et que Fibaro est susceptible de changer ce proxy cloud à tout moment. Une alternative pourrait être de sniffer les requêtes émises par la nouvelle application mobile Yubii, vu qu'elle passe par le cloud. Mais pas forcément plus simple que la méthode précédente... Bref, par ordre de simplicité, je dirais : - ouvrir et rediriger un port sur le routeur vers la box domotique - établir un VPN - monter un reverse proxy (avec HAProxy, ou Ngynx, etc) - reverse engineering via l'une des 2 méthodes exposées plus haut. L'ouverture de port étant la moins sécurisée, le VPN la plus sécurisée, et le reverse proxy quelque part entre les 2 selon la configuration mise en place. 

ça dépend de ce que tu appelles "de suite", tu remarqueras que je n'ai pas encore édité la 1ère page

Dans ce cas, pas certain que la HC3 permette d'écouter les broadcast du réseau, je ne pense pas que ça soit prévu. J'avais bien vu dans ton log que l'erreur provenant du receive(), mais c'est justement parce que la HC3 considère qu'elle ne reçoit rien (malgré les paquets envoyés précédemment) que tu as cette erreur. Tant que ta PAC enverra en broadcast, tu ne recevras rien dans ton code LUA, car ce n'est pas une réponse à un paquet destiné à la HC3. Mais si tu dis que tu peux communiquer en TCP, pourquoi ne pas utiliser ce protocole ?

Je les mets tous dans la même pièce du module, et je cache ceux font je n'ai pas besoin (c'est à dire la majorité en fait) Comme sur ton screenshot. Sinon plutôt que le support Fibaro, tu peux tenter le forum officiel, c'est parfois plus réactif, et les intervenants (salariés Fibaro) plus compétents que le support.

ça te défrise Je vais l'ajouter, mais en temps normal on s'en fout en fait, puisqu'il n'y a de toute façon aucun graph à visualiser le premier jour, le temps que les données s'accumulent.

1. Je n'ai eu aucun problème pour lancer les mises à jour.... demande au support Fibaro 2. Tous mes modules RGBW remontent la consommation sur le module principal, je n'ai jamais eu de consommation sous chaque module enfant. Il faudrait que tu arrives à faire les mises à jour de firmware, puis peut être refaire une exclusion/inclusion pour uniformiser tout ça. 3. La télécommande permet d'utiliser facilement les déclencheurs de .... scène justement ! Perso je n'utilise pas les scènes, les modules sont cachés, donc je ne les vois plus. Si Fibaro les affiche dans les scènes, c'est justement à raison. 4. C'est un comportement "normal" sur HC3 (comprendre : c'est tout le temps comme ça), mais je ne trouve pas ça normal, perso je préfère les repasser systématiquement en polling régulier, ça permet de détecter les éventuels noeuds morts. Mais attention, c'est consommateur de bande passante, c'est pour ça que Fibaro préfère désactiver le polling par défaut sur HC3. Si tu le réactives, il faut bien faire attention à augmenter le paramètre général d'intervalle de polling.

Merci @jojo, du coup petite mise à jour du graphique :

Tous les dimanches pour être précis, pas tous les jours. Mais je ne sais pas si ça a une incidence, certains utilisateurs évoquent un plantage dans les moins de 24h qui suit le redémarrage.

C'est comme pour l'ancien Domocharts sur HC2, le GetDevices est exécuté automatiquement chaque nuit. Par ailleurs si tu veux appuyer manuellement sur le bouton, tu peux le faire autant de fois que tu veux, c'est sans danger. Mais inutile d'aller dans l'Edition du QuickApp, c'est accessible directement depuis la vue du QuickApp sur le dashboard principal : quand tu cliques sur la loupe, ça ouvre un panneau à droite. Les variables NAS_User et NAS_Password elles servent si tu as un mot de passe qui protège les pages Web. Ce n'est pas le cas si tu suis le tuto, mais pour quelqu'un qui hébergerait DomoCharts sur un serveur Web public, c'est conseillé.

Retrouvé, c'est @jang qui a donné le bout de code sur le forum officiel : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/19/#comment-206686

D'après la capture du trafic, on voit que ta PAC ne répond pas au broadcast (255.255.255.255) Donc enlève : broadcast = true, dans ton code LUA

Non, en effet, il n'y avait aucune propriété disponible dans le JSON du QuickApp pour y stocker la source. Et on ne peut pas créer nos propres propriétés personnalisées. Du coup.... à priori pas d'autre solution que de devoir aller lire la valeur de la source directement dans le label. Je ne sais pas comment tu comptais récupérer cette valeur, ou plutôt comment la traiter ? On a parlé très récemment sur le topic du Support GEA de comment lire le label avec GEA. Mais si tu veux le faire en LUA directement, c'est un peu plus compliqué, car il n'y a pas de méthode directe. L'astuce était passée sur le forum, il faudrait la retrouver, mais le principe c'est d'aller interroger la "view" du QA, puis de parcourir les éléments jusqu'à trouver le bon label : /api/plugins/getView?id=123

ça m'embête un peu cette mise à jour, je vais devoir rebrancher la HC2 juste pour pouvoir trinquer un coup

En complément : comme tu l'as indiqué dans la MAJ de ton message, le label des QuickApp prend maintenant le texte complet, avec les émojis, le descriptif traduit dans la langue qui va bien, etc... et pas uniquement la valeur qu'on veut y afficher. C'est encore une autre bonne raison de ne pas utiliser les labels, car tous mes QuickApps sont maintenant multi-langue, et on est pas à l'abri que lors d'une prochaine mise à jour, l'intitulé change, ou bien les emojis qui servent à faire joli. Par conséquent tes scripts (GEA ou autre) qui dépendent du label ne fonctionneront plus. En allant lire directement les propriétés du QuickApp, tu es certain que ça fonctionnera en toute circonstance.

Comme dit de nombreuses fois sur le forum, il ne faut pas lire les labels dans les QuickApp, ce n'est pas prévu pour ça. Les labels sont juste un moyen d'afficher de l'information pour l'utilisateur via la page Web ou l'application mobile, ça s'arrête là. Il faut arrêter de raisonner comme sur la HC2 où l'on avait de très nombreuses limitations, si bien qu'on utilisait les labels comme un moyen de stocker de l'information, autant que pour la présenter à l'utilisateur ou bien pour transmettre de l'information entre différents modules virtuels et scènes. Tout cela n'est plus possible, ou plus précisément c'est toujours possible mais bien plus compliqué, et surtout bourré de limitations, à commencer par le fait que les labels ne sont pas persistants. Mais surtout, la HC3 propose tout ce qu'il faut en natif pour la communication entre les QuickApp et scènes, donc autant utiliser les bons outils. Alors tu n'as peut être pas regardé au bon endroit, en tout cas ce n'est pas dans GEA qu'il fallait chercher, mais sur la page du tuto du QuickApp, toutes les informations y sont : Ce qui t'intéresse toi, c'est précisément ceci : Les propriétés suivantes peuvent être lues dans le JSON du module : power : boolean : true|false -- Statut d'alimentation de l'appareil  Ensuite, tu vas dans la doc de GEA et tu cherches comment on peut lire les propriétés d'un module.... facile, c'est avec "Property". Du coup ça donne un truc comme ça, tout simplement, pour lire la propriété power, et vérifier si elle est à true : GEA.add({"Property", id["VD_RXA780"], "power", true}, 0, "", {"TurnOn", id["WP_MiniDSP"]}, "ON MiniDSP")

Ça me rappelle Imperihome.

Ah tiens, je ne connaissais pas, tu nous feras un retour ?

OK donc 25A pour le disjoncteur c'est bon. Tu peux te mettre dans ton tableau, si et seulement si tu as de la place disponible... ce qui n'est pas le cas du tableau que tu as montré. Et interdiction d'utiliser un différentiel existant, c'est impérativement un différentiel et un disjoncteur dédié pour l'installation photovoltaïque. Regarde les schémas d'Oscaro, ils sont clairs. @Nico ah oui en effet, donc pas de souci, tu peux chauffer le ballon à l'infini, c'est top ça, car ça te garantie un taux d'autoconsommation de 100% et par conséquent zéro-injection

Peu importe pour le différentiel, la norme n'impose pas de type particulier (j'ai cherché, rien trouvé). Si tu mets du HPI c'est mieux, mais tellement cher, et surtout inutile, donc tu mets le moins cher, type A ou AC, mais qui est en stock surtout, en ce moment c'est pas toujours gagné. Il faut évidemment du 30 mA, et 40A. Pour le disjoncteur, du 20A ou 25A normalement (et non pas du 32A comme tu le demandais plus haut)

Non 1 seul fil de terre Celui avec le câble 3G6 tu ne le branches pas. Celui qui doit être branché, c'est le câble de terre 6mm² à part. Cherche pas à comprendre la logique.... je ne sait pas trop d'où sort cette règle, les voies du Consuel sont impénétrables