Lazer

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

Dans les paramètres de ton routeur (box internet ADSL/fibre) Il y a pleins de tutos sur le net en fonction de la box. Le principe c'est de rédiriger un port externe, vers le port 443 de la HC3. Mais attention, ce n'est pas sécurisé, ça expose la box Fibaro en direct sur le grand méchant internet. Raison pour laquelle Fibaro a toujours déconseillé cette méthode. Ils préconisent de passer par leurs serveurs, qui apportent de la sécurité supplémentaire (filtrage des tentatives de connexion).

Le Figaro attaqué ? Mince alors, c'est Nico qui va être triste Quant à Fibaro, une simple panne est tout aussi probable, vu comme ils sont doués en informatique Remarque, je crois que la partie hébergement est sous-traitée, donc la faute peut revenir à l'hébergeur aussi.

L'astuce avait été donnée sur le forum, sur un des sujets dédiés à l'application mobile Yubii. Lors du 1er lancement, il faut entrer manuellement l'adresse publique, comme si on faisait une connexion locale. Sauf qu'au lieu de choisir 192.168.x.y, on indique l'adresse IP publique du routeur, après avoir fait une redirection de ports. Dans mon cas c'est même encore mieux, puisque j'ai entré mon nom de domain complet, ainsi la connexion passe au travers de mon reverse proxy. Et bien sécurisé en HTTPS. Résultat, l'application mobile est bien plus réactive en usage quotidien, puisqu'on évite un aller/retour inutile vers les serveurs de Fibaro. Et aujourd'hui je peux confirmer que j'ai toujours accès à l'application mobile, alors que les serveurs Fibaro sont injoignables, et cela aussi bien en local (Wi-Fi) qu'à distance (4G)

Bienvenue sur le forum