Lazer

@henri-allauch effectivement le graph par défaut est limité... jamais eu le temps d'ajouter le graph daily. Normalement la table domocharts_cpu_day devrait être populée, donc il faut construire le graph à la main, par exemple en faisant un export des données CSV dans Excel, ou bien attaquer la base SQL directement avec Grafana pour faire un graph perso. Dans les tables tu trouveras aussi le détail des coeurs du CPU (peu utilse dans le problème qui nous concerne, mais pour info)

@TonyC Je pense comme toi, la charge CPU n'est pas la cause des plantages. Mais rien n'interdit de penser que ça soit un facteur amplificateur. Quant à la température, on pourrait le penser aussi, mais j'en doute. Ma box de prod (serial 13000), très chargée (nombreux modules Z-Wave et QuickApps, cependant le CPU reste inférieur à 10% hors pointe exceptionnelle) est dans un placard technique (avec le serveur, la Freebox, etc), donc au chaud, et pourtant elle est ultra stable. Mais box de test (serial 300), peu chargée (aucun module Z-Wave, juste quelques QA), est dans mon bureau, et en ce moment, il y fait 17 la nuit, et 19° quand j'y suis.... et présente des plantages depuis les 2 derniers firmware beta, alors qu'elle ne m'avais jamais fait ça avant. Donc soit un défaut hardware est apparu sur la box de test comme par hasard avec la dernière série de firmware, soit ils ont introduit un nouveau bug non documenté dans le changelog J'attends le prochain plantage (statistiquement cette nuit ou la prochaine), puis je fais un retour arrière sur le firmware stable, et on verra comment elle se comporte.

Si tu as DomoCharts, tu peux regarder le graph CPU, tu verras si la charge processeur a diminué entre avant/après ta modif.

C'est de pire en pire, maintenant un festival de messages d'erreur différents : Le système a récupéré d'une erreur inattendue Erreur lors du démarrage du système

Non, chez OVH tu peux prendre un nom de domaine seul, sans hébergement, et créer autant de sous-domaines que tu veux. C'est ce que je fais. https://www.ovhcloud.com/fr/domains/

Ah, merci, il a fallu attendre pour que quelqu'un rebondisse dessus

Avec Apache, tu peux faire un reverse proxy, mais perso je ne suis pas fan de cette solution. Je préfère utiliser HAProxy en frontal Web, qui joue le rôle de Reverse Proxy, c'est donc le seul qui écoute sur le port public 443. Et ensuite HAProxy réémet le requêtes en interne, soit vers la box domotique, soit vers le vrai serveur Web Apache hébergé sur la même machine, mais qui écoute sur un autre port que le 443. De la sorte, tous les flux sont protégés par le reverse proxy, et peuvent ainsi bénéficier des certificats signés. Et de préférence bannir le port 80 HTTP simple non sécurisé, il n'y a plus vraiment de raison de l’utiliser de nos jours, sauf cas spécifique.

C'est pour ça qu'il faut un reverse proxy, car c'est lui qui présente le certificat signé. En résumé de tes expériences, l'ouverture/redirection de port ça permet d'accéder à sa box à distance via le Web, mais ça ne permet pas d'utiliser l'application mobile Yubii.

Bienvenue sur le forum

les doigts mouillés, les pieds dans la baignoire

use the break instruction

Je pense que c'est normal, car tu n'utilises pas de certification signé par une autorité de certification reconnue. Avec ton certificat autosigné (tu as l'alerte dans ton navigateur), l'application mobile Yubii ne peut pas confirmer que l'hôte est authentique, donc elle refuse la connexion. En local ça marche car elle doit se contenter du HTTP/80 simple sans sécurité, considérant que c'est suffisant. Mais pas via le WAN. Donc il te faut un vrai certificat, Let'sEncrypt c'est très bien et gratuit. Par contre il faut impérativement un nom de domaine je pense, car je ne suis pas sûr que ça fonctionne avec les DynDNS.... à tester.

Cramer un module c'est possible, surtout le FDG-211, tu devrais le tester sur une table d'essai avec un montage basique : un interrupteur, et une lampe, des fils courts, et c'est tout. Déjà vérifier qu'il fonctionne correctement pour un cas simple. Puis après tu ajoutes de la complexité.

Tu n'as peut être pas identifié les box câbles... ça arrive parfois quand les câbles passent par des boites de dérivation intermédiaires, du coup la couleur aux 2 extrémités n'est peut être pas la même... bref c'est galère pour ça les vieilles installations électriques.

La dernière version permet de passer l'authentification OAuth 2.0 que Netatmo devait imposer à partir du mois d'octobre. Comme l'OAuth 2.0 n'est pas possible depuis les box Fibaro, son auteur gsmart a proposé une solution permettant d'héberger une page sur son site.

Ah oui tiens, effectivement, et en plus c'est indiqué dans le descriptif sur le market Fibaro, merci pour le rappel De mon coté je ne suis pas (encore ?) passé à cette nouvelle version, vu que Netatmo n'a finalement pas (encore ?) coupé l'accès à l'ancienne API, du coup j'utilise toujours mes tokens générés directement sur le site de Netatmo.

Il faut te créer tes identifiants/token sur le site Netatmo Developers : https://dev.netatmo.com/ Je crois bien qu'il y a déjà quelques screenshots qui expliquent comment faire ici, sur ce topic ou un autre dédié à Netatmo.

User eXperience je suppose. Ce sont des termes pipomarketing dans l'ère du temps...

It is only a measured (average temperature) from selected sensors, it does not affect the logic behind climate panel - presentation purpose only. You will find it (temperature value) in: - sidebar of any thermostat assigned to a climate zone - climate zone sidebar in climate dashboard - zones list in settings Source : https://forum.fibaro.com/topic/64458-climate-added-possibility-to-assign-temperature-sensors-for-climate-zones/?do=findComment&comment=260813

Bon, et bien rebelote Le système a récupéré d'une erreur inattendue Et dire que cette box que j'ai depuis le tout début (numéro de série dans la centaine 300) ne m'avait jamais fait ces erreurs, alors qu'elle a subit toutes les mises à jour sans exception, beta, stable, etc... et depuis les 2 dernières beta, apparition de ce message Je crois que ma box de prod va rester très longtemps en version 5.120, la dernière vraie stable.

Désolé non, je détester les vas et viens, c'est trop compliqué pour moi à câbler, et trop compliqué à utiliser (une fois sur 2, l'interrupteur (bistable par définition) se retrouve dans la position inversée). Lorsque j'ai connecté mes modules domotiques, j'ai remplacé les bistables par des monostables, et j'ai effectué un câble de type télérupteur, c'est à dire que chaque interrupteur se comporte maintenant comme un simple poussoir, et c'est le module domotique qui joue le rôle de télérupteur. Avantage, le câblage est plus simple (on peut ajouter autant d'interrupteurs qu'on veut, pas seulement 2), on peut faire varier la luminosité (par appui long), etc Sinon tu attends que @Did passe par ici, c'est notre exert électricien

Non, j'ai indiqué que c'est un index qui s'incrémente perpétuellement. La base de données refusera de repartir de l'index 0, sauf à faire une manip spéciale. Clairement pas ce qu'à prévu Fibaro. Et on ne connait pas la taille de cet index, si c'est du 16 bits, c'est 65536 possibilités. Si c'est du 32 bits, c'est plus de 4 milliards...

Attention certaines box opérateurs (dont les vieilles Livebox, est-ce encore le cas pour les récentes ? ) ne permettent pas le routage en loopback. Ce qui signifie que l'adresse IP publique est bien joignable depuis l'extérieur, mais pas depuis l'intérieur. Le problème c'est que l'application mobile va utiliser l'IP publique, donc elle pourrait se connecter à distance, mais pas en local, ce qui est bloquant. A vérifier selon votre box internet.

C'est une base de données, avec un index qui s'incrémente perpétuellement. C'est la façon qu'ils ont choisi de gérer les modules... C'est propre et sans risque, mais c'est pénible pour nous car impossible de récupérer un ID existant. Il aurait fallu qu'il garde l'index en incrément perpétuel, et qu'ils assignent un autre ID aux modules... mais ce n'est pas le choix qu'ils ont fait. C'était déjà comme ça sur HC2.

Plouf ! C'est 443 pour le https, pas 453