Reprise du message précédent :
 

Ben avec : https://www.home-assistant.io/compo [...] hermostat/
 
En gros tu dis a HASS quelle est l'entité sonde de température de ton thermostat, quelle entité est le pilote du chauffage et il va te créer un thermostat avec un réglage de valeur cible.
Tu as pas mal d'options en plus si vraiment tu veux un truc fin (tolérances haute t°/basse t°, mode absence...)
 
Tout simplement ! J'ai mon aquarium géré avec ce composant. Niveau matos c'est un sonoff TH16 flashé avec esphome avec sonde DS18B20.
 
Je vais bientôt passer les radiateurs des chambres avec en sonde un module intérieur netatmo et en pilote radiateur un sonoff basic qui pilote le fil pilote.

 
Thx  

 
Justement, j'utilise Heliotrope aussi (je crois que c'est ça le nom), mais il faut un truc équivalent sous Hass pour lui. A la mimine c'est un peu velu.
Perso j'utilise une mesure de luminosité un peu complexe : je mesure la luminosité extérieure, et intérieure. Pour la luminosité intérieure je retranche les Lux apportés par l'éclairage artificiel qui est allumé (et avec des variateurs c'est pas toujours simple pour obtenir une correspondance propre). Ensuite je mélange tout ça avec l'heure, heliotrope, notre présence,... et j'en déduis l'état d'ouverture du volet.
Après un peu de réglage ça marche au poil. je n'ai pas ouvert ou fermé un volet à la main depuis des mois (sauf une fois en plein nuit pour prendre des photos d'un orage particulièrement violent).
J'ai aussi un autre scénario pour la simulation de présence.
 
Note : dans mon cas actuel c'est plus simple, en appartement sans terrasse, pas de soucis à fermer les volets automatiquement
 

 
C'est pas Hass qui est instable, je n'ai peut-être pas été clair, juste le démon gérant le protocole BLE.    
 
Comme le problème est remonté par pas mal de monde, ce sera bien corrigé un jour.
 
Je maintiens mon idée de passer à Hass + Nodered pour la maison début 2020, ce sera l'occasion de repartir de zéro. A voir.

 
Pour les équipements fibaro je n’ai jamais eu de soucis avec la librairie OpenZwave a part la prise Wallplug que j’utilise, il faut que je trouve une solution pour ça. La qualité est bonne. Et beaucoup de système d’autoréglages à appeler pour un produit « prêt » a l’emploi. Le problème du Zwave étant que c’est relativement cher ce qui m’a fait passer au Zigbee pour les équipements non critique. Beaucoup moins cher.  
 

 
Le composant sun.sun te donne la position du soleil par rapport à la position renseignée sur config.yaml avec un offset selon le coucher de soleil que tu veux. En effet ça ne devrait pas être compliqué à gérer. Je l’avais déjà fait sous Jeedom, je peux le faire sous HA en .yaml
 
Pour ce qui est du BLE, je vais voir en rentrant chez moi. Actuellement j’utilise le Wifi du téléphone. Mais Apple ayant tendance à couper le wifi pour garder de la batterie, je suis obligé de laisser une tempo de 30 minutes pour passer en mode absent.. ce qui me dérange si à l’avenir je met une serrure connectée.  
 

 
Le problème du thermostat HA est qu’il lui faut une sortie contact sec (parfait pour les radiateurs elec) pour la commande de chauffe, or, en chauffage central j’ai des vannes thermostatiques donc non compatible avec HA. L’idéal serait de copier le plugin thermostat de Jeedom et son fameux mode temporel (pas encore les connaissances de programmation pour ça) et en plus, le thermostat HA si je ne dis pas de bêtises, fait du Tout ou Rien.. Ce qui est toujours mieux qu’un radiateur tout le temps en marche mais peut être amélioré non ?  
Ou bien d’acheter la tête thermostatique Eurotronic et un capteur de température Zwave (double achat ce qui me dérange aussi) et laisser la régulation se faire avec le programme de la vanne via la lecture de température déportée. HA n’étant la que pour envoyer une consigne de température.  
 
Je n’ai pas encore mis ça au point donc je ne peux pas faire de retour la dessus mais la position sera gérée par le composant Icloud d’Home assistant et des zones crées dans la map

 
Impressionnant pour les volets, j'en suis pas là !  
 
J'ai l'impression d'avoir trop de cas particuliers pour tout gérer en auto (saison, ensoleillement, sortie pour 1h ou 1 journée)
 
Je vais déménager cet été. Quasi toute ma domotique sera à refaire, donc c'est l'occaz de changer. Bon, dans tous les cas ça sera pas le premier chantier, mais d'ici la rentrée faut que je vois si je reste sous Jeedom, ou si je passe sur HA

Update OK

Pour la version 'simple' de l'ouverture/fermeture des volets, effectivement cela donne qqchose de simple, même en yaml
 
Ma petite contribution, ouverture après 7H/lever et fermeture après 18H/crépuscule civile. Je ne prend pas en compte la luminosité clairement ça simplifie (de toute façon je ne trouve pas mes yeux fibaro suffisamment/précis bon pour le faire).
 

 
@Shaad: perso tout pareil, pas trouvé mieux que de délocaliser la stack BLE que sur un RPI (que ce soit sous Jeedom et même comme cela il y a des soucis, le process qui se spawn un nombre incalculable de fois - ou sous Hass).
Merci pour monitor, je ne connaissait pas

Petite question à ceux qui utilise NodeRed: comment faire simplement l'équivalent d'une condition AND ou OR de hass ?
 
Exemple concret: l'ouverture/fermeture ci-dessus - soleil > dusk AND heure > 18:00 ?
 
Après avoir jouer un peu avec nodered, très puissant/facil, mais je sèche sur de petites chose simples

perso je fais:
OU: deux points d'entrée dans le flow (une sur l'heure, une sur l'événement coucher de soleil)
ET: deux noeuds successifs

T'aurais pas une manière aussi simple pour transformer des persiennes en volets roulants par hasard ? en copro évidemment, sinon c'est moins drôle...

Voila quelques vidéos qui m’ont un peu aidé à comprendre: https://www.youtube.com/playlist?li [...] Wc-_MnFb-y

 
Ah je trouve justement les yeux Fibaro plutôt fiable quand ils sont configurés pour être sensible et remonter régulièrement les variations de Lux.
Bien entendu, lors du traitement sous Jeedom ensuite, je moyenne les données sur plusieurs minutes pour éviter les effets indésirables d'un rayon lumineux, d'un nuage qui passe ou je ne sais quoi.
 
Le plus compliqué pour moi a été de prendre correctement en compte les différentes sources de lumière artificielle. J'ai 5 lampes dans mon séjour, divisées en 2 groupes, dont une lampe sur variateur. Ca m'a pris quelques semaines pour affiner les différents apports de lux de chacune des sources et en particulier celle du plafonnier principal sur variateur en fonction.
 
Sinon j'ai appliqué la même logique que toi : indépendamment de l'heure de lever/coucher du soleil et de la luminosité réelle mesurée, j'applique aussi des bornes horaires pour ne pas ouvrir/fermer avant/après certaines heures fixes. Ces heures changent en fonction de notre mode de présence (week-end, jour travaillé,...).
 

 
Pour ce qui est de Jeedom & BLE, je n'ai en effet aucun démon BLEA local sur ma VM Debian 9 qui héberge Jeedom. Mes VM tournent sur un ESXi et il y a pendant longtemps eu des problèmes avec BLEA sur Debian9 sur ESXi, je ne sais pas où ça en est. J'ai donc 2 antennes BLEA :

• une première dans une VM dédiée qui tourne sous Debian8, sur le même serveur ESXi. RAS. Uptime qui a déjà dépassé 5 mois sans aucun soucis. Aucun plantage. Les seuls arrêts c'est quand je fais une mise à jour de mon hyperviseur.

100% fiable pour moi.

• une seconde antenne hebergée sur un RPi 0W qui n'est pourtant pas un foudre de guerre et qui partage ses ressources avec un démon téléinfo également. Il tourne sur la dernière Raspbian (donc une base de Debian9 je crois, pas sûr). Uptime courant supérieur à 7 mois. RAS. 100% fiable.

 
Tu as réussi sous Hass à avoir une utilisation fiable de BLE ?
 
 
Cette discussion m'a hypé !!!    
Je vais me reprendre un 2e RPi 0W pour redonner sa chance à Hass en utilisant l'usine à gaz Monitor pour la gestion BLE.  

Bah si tu as du esxi, une VM pour hass c'est discret ^^
 
Pour le BLE: alors fiable oui, mais je n'utilise plus que pour récupérer la temp/hygro de thermomètre / de miplant xiaomi et 'piloter' une DOTTI. Via un petit soft en python que j'ai implémenter en utilisant la stack python ble Bluepy.
 
La gestion de présence (via des NUT mini) est pour le moment au point mort. Enfin plus en mode proto car je teste pas mal de combinaison via le WiFi et les composants DDWRT + "présence" de Hass couplé avec une app Appdaemon que j'ai implémenter et qui remonte les coordonnées des iPhones via MQTT (car je trouve que les composants 'officiels' drainent bien trop vite la batterie des téléphones).
 
Oui je vais moi aussi tester monitor, sur le papier ca à l'air pas mal du tout

@ganfoud:
@Kibis: merci pour les liens
@fegre: euh non désolé

@Shaad pourquoi usine a gaz monitor.
Perso j'ai regardé un peu sa doc, j'en ai installé un juste pour test et c'est assez génial comme principe je trouve.

 
J'en ai déjà une (arrêtée pour le moment).  
J'ai testé Hass.io quelques semaines, en parallèle de Jeedom et j'avais d'ailleurs fait des découvertes surprenantes/intéressantes et que je ne m'explique d'ailleurs toujours pas comme le fait qu'on puisse utiliser un même réseau ZWave depuis 2 systèmes domotiques en parrallèles équipés chacun d'une clé Aetoc Gen5 identique (backup de l'une sur l'autre). Ca marche parfaitement : les 2 systèmes peuvent contrôler tous les actionneurs ZWave, et les 2 systèmes sont notifiés de toutes les mises à jours de tous les capteurs.
 

 
Je n'avais en effet aucun soucis avec Hass et BLE quand je ne faisais qu'exploiter mes Mi Plants. Mais dès que je déclarais des Trackers c'était très instable.
 
Je fais aussi du tracking de nos smartphones en exploitant l'API Unifi de mon routeur et de mes AP Wifi. C'est fiable, ça permet de détecter le passage en mode 'Nuit'. Mais il y a toujours un cas particulier qui va arriver une fois par mois et va faire que ma copine va se retrouver dans le noir ou que la télé va s'éteindre ou je ne sais quoi et elle va râler !    
 
Les 3 énormes avantages qui font que je persiste avec BLE par rapport à de la gestion de présence Smartphone :

• 100% fiable depuis 2 ans. Pas un faux positif ou un faux négatif observé. Mon réseau BLE gère mes NUT Mini mais aussi des Mi Flower Plant et autres thermomètres BT Xiaomi.
• Je gère la femme de ménage ou même ma belle-mère exactement de la même manière que nous, alors que je ne me vois pas lui demande d'activer systématiquement le wifi de son smartphone, définir un de mes SSID Wifii comme préféré sur son smartphone, etc...   Un NUT @5 balles chacune accroché au porte-clé avec les clés de notre appart' et ça roule.
• Hyper réactif sur la détection de présence : on est détecté avant d'ouvrir la porte d'entrée et notre absence est détectée en moins de 2 minutes après avoir quitter l’appartement. Ce n'est pas un gros plus par rapport à du wifi que je détecte même depuis la rue.

2 points négatifs :

• Je dois remplacer les piles des NUT tous les 6 mois en moyenne et Jeedom ne remonte pas l'info de batterie. Pour ceux de la femme de ménage et ma belle-mère, je fais donc un roulement de NUT, je change la pile d'un NUT Spare et leur demande de l'échanger avec celui de leur porte-clé et me laisser l'autre à la maison.
• La portée du BLE étant ce qu'elle est, il faut souvent plusieurs antennes pour couvrir un logement. Actuellement 2 me suffisent pour être 100% couvert et notamment très réactif près de la porte d'entrée, mais à l'avenir j'envisage de passer sur au moins 4 ou 5 pour couvrir toute la maison et même le jardin.

 
La page de doc fait plus de 10 écrans de haut sur l'écran 15" de mon portable, et en plus faut du MQTT.==> usine à gaz !    
 
Je plaisante, enfin à moitié, ça ne semble pas si complexe que ça mais peut-être un peu overkill pour mon usage.
 
En tout cas ce plugin avait été très bien accueilli sur les fofos où on en parlait et son auteur n'en est pas à son coup d'essai.
 

Oui d'ailleurs j'avais suivi avec intérêt tes différents feedback !

Pour la portée, je l'avais déjà indiqué ici par le passé, si tu trouves une clé SENA UD100-G03 fonce car en terme de portée c'est vraiment très bon (Dr Sarakha, l'auteur du plugin BLEA de jeedom avais fait une comparaison de différente clé / portée). Ca te permettra sans doute de limiter le hardware (même si à coup de PI Zero c'est pas si important, mais bon maintenance + câblage en plus).

Oui j'ai utilisé les NUT pendant près d'un an avec des scénarios sous Jeedom et le fait de devoir changer les piles un peu trop souvent à fait que lors du passage sous Hass, je ne me suis pas empressé à remonter cette partie du système

Edit: d'ailleurs pour le problème que j'évoquais avec le plugin Jeedom/remote daemon du plugin, il suffit de faire un petit 'ps' et si tu as plus de 2 instance de la ligne de commande BLEA c'est que tu as le soucis du spawn de process. Ca ne semble pas jouer sur la stabilité (je n'ai jamais eu de crash en tant que tel pendant 2ans sous jeedom) mais bon ca bouffe toutes les ressources de l'hôte.

 
Moi mon gros point négatif c'était l'autonomie. Mais il faudra que je teste ta technique de déinstaller l'appli & co. A priori c'est ce qui bouffe les piles.  
 
Pour la portée, perso j'ai déplacé mon antenne proche de l'entrée. Ca me détecte avant que j'ouvre, les clés restent à l'entrée donc pas de soucis. Le Mi Plant est à portée, mais il ne marche pas (le device en lui même, il ne remonte rien, même dans Mi Home). Et j'ai pas de thermomètre BT ... J'avais pas pensé utiliser ça avec Jeedom via BLEA, c'est vachement interessant comme idée    
Je les aime bien les thermomètres ronds avec l'affichage

 
J'avais vu cette clé en effet. J'hésite encore entre changer de clé ou multiplier les Rpi. La maintenance normalement ce n'est pas trop un problème, je n'en fais presque pas à la main, et quand j'en fais c'est à coup de SupperPutty ou équivalent pour envoyer les même commandes à plusieurs hôtes.
Mais oui dans l'idée ça fait tout de même plus de travail, ne serait-ce qu'à installer, configurer, configurer les baux DHCP,...
En tout cas le RPi 0W je n'étais pas forcément convaincu mais quand on a usage précis et qu'il est adapté à cet usage c'est quand-même assez génial pour un coût dérisoire et une conso pratiquement nulle.
 
Merci pour le tip pour le process BLEA, je jetterai un oeil à l'occasion sur mes 2 antennes.    

 
Je ne les utilise que comme remontée d'info domotique, pas comme affichage. La valeur change beaucoup trop fréquemment à l'affichage pour être agréable, ils n'ont mis aucun hysterisis...
Et à choisir je préfère du coup les Mi Flower Plant qui sont mes thermomètres principaux pour la domotique, et notamment ceux utiliser pour gérer le chauffage.
 
Par contre, en terme de thermomètre, les autres thermomètres Xiaomi, ceux non-connectés à affichage encre liquide, sont top. Je suis fan. J'en ai 5.
 
J'ai acheté il y a quelques semaines une "horloge" Xiaomi qui reprend exactement le même design pour tester : un peu galère pour configurer l'heure mais j'adore le rendu :

Bonus : elle est bluetooth, pas encore testé de l'inclure dans Jeedom, je ne sais même pas si elle existe déjà.
 
 
 
 
 
 

MQTT c'est 2 clicks sous hass.io
Par contre je sais pas si il baratine mais son coté low brodcast pour pas polluer ton environnement de signaux inutiles je trouve ça génial, ça se passe comment avec ton système jeedom ?

 
Le Mi Plant comme thermomètre dans la chambre ?
 

Bon, je ne sais pas sur quoi partir!
 
Je souhaite réaliser une lampe avec les caractéristiques suivantes :

• Intégration de toutes les fonctionnalités dans Home Assistant
• Commande indépendante de Home Assistant avec deux touches tactiles (combinaisons à réfléchir pour accéder à différentes fonctionnalités avec les deux touches)
• Deux leds RGBWW (chaud) commandée en PWM de manière simultanée
• Un bandeau de led le long de la lampe, adressable, avec effet "feu"   (et autres effets proposés)
• Une sonde de température
• Alimentation 12VDC

Niveau hardware, je ne me fais pas trop de soucis, et j'ai presque tout déjà dans mes tiroirs. Par contre, niveau software, je ne sais pas comment démarrer...
 
J'ai entendu parler de ESPHome, mais j'ai du mal à juger si je peux faire tout ça uniquement avec ESPHome, notamment le fait de l'utiliser sous Hass.io, mais garder tout de même des commandes indépendantes avec des boutons tactiles.
 
Sinon, j'ai aussi vu un projet sur BRUTH automation, je peux peut être partir là dessus :
https://github.com/bruhautomation/E [...] gital-LEDs
 
Ou alors, en me basant sur les projets de The Hook Up :
https://www.youtube.com/watch?v=PVQhGzo-Dtg
https://www.youtube.com/watch?featu [...] j3UyrBjB4g
 
Bref, comme vous l'avez compris, je ne sais pas sur quelle branche partir!
 
Vous auriez un petit conseil ? J'ai zieuté le topic Arduino, mais on aborde pas ce type de sujet...
 
Merci!

 
Avec Jeedom ça se passe bien.
 
Par contre depuis que j'ai changé de routeur + AP Wifi j'ai régulièrement des alertes me signalant que mon canal wifi utilisé pour la bande 2.4GHz est saturé. J'ai essayé les 3 canaux "standard" en France, et même le réglage Auto qui bascule automatiquement de canal quand un est saturé mais je continue de redevoir ces alertes 2 ou 3 fois par mois. J'ai toujours mis ça sur le compte des nombreuses box Wifi environnantes (et j'en vois un paquet!) mais effectivement ça pourrait aussi venir de mes émetteurs BT qui tournent sur la même gamme de fréquence si je ne dis pas de connerie.
 

 
Oui, et un peu partout même d'ailleurs.
Mais je ne vais pas réexpliquer pourquoi, j'ai déjà fait moult pavés sur le sujet depuis 2 ans.    

Bah c'est exactement ce que le monsieur explique sur les 10 pages de doc de monitor en fait
10 pages qui sont essentiellement composées de grand dessins pour enfaits ²

Du coup je viens de lire en travers très vite fait... OK il utilise finalement le "meilleur des 2 mondes BLE" pour avoir à la fois quelquechose de fiable et pas trop consommateur de BP. Trop fort !    
 
Bravo ! Si en plus j'ai un espoir de réduire les interférences avec mes autres devices Wifi, je me dois encore plus d'essayer... grrrr. Je ne te remercie pas.

vous parlez bien de Monitor l'interface en html5 ? si c'est le cas elle nécessite (comme dit) mqtt mais en websocket, ce qui me mets la pagaille avec tous mes ordres IFTTT (en http), dans ce cas le websocket de MQTT est en conflit avec le http et les ordres http ne passent plus et je n'ai pas trouvé le chemin dans le paramétrage de MQTT pour mettre une exception dessus.

@shaad je n'ai pas retrouvé (si c'est toi) ton post ou tu décris comment faire pour cette duplication , je voudrais tester domoticz et jeedom en parallèle avec mes équipements zwave et je suis preneur de la manip (je pars de domoticz ou ma clé gen5 est déjà en service)
 
donc je suis preneur  
merci

nope de ceci https://community.home-assistant.io [...] tion/68505

 
hello!  
 
merci pour l'astuce!
C'est vraiment fait pour ne pas avoir à s'embêter avec un dyndns pour accéder à jeedom (par exemple) depuis l'extérieur?
 
Merci!

bah non pas du tout tu auras tjrs une ip dynamique que tu devras mettre a jour niveau dns.
De plus je doute qu'ils offrent un service de mise a jour de dns dynamique si tu prends juste un nom de domaine.

Je donne la même réponse que la dernière fois, qui complète big_poulet : si vous voulez la facilité prenez un domaine à 2€ht/an chez ovh, ensuite il y a plein de solutions dispos sur les internets pour maintenir le dns à jour depuis une de vos machines @home. Et il y a pas mal d'avantages connexes à avoir un domaine (que ce soit chez ovh ou autre) Perso mon domaine ovh fait pointer le mx sur gmail (version entreprises gratuite), ce qui veut dire que j'ai un mail hfr@dafunky.fr avec l'interface gmail, d'autre part je gère les sous domaines à outrance : exemples :  
 
dedie.dafunky.fr pointe sur le dédié que je loue
domotique.dafunky.fr pointe sur ma machine virtuelle domotique @home
 
etc.
Ya juste un truc, je ne sais pas comment le faire, c'est :
 
serv1.dafunky.fr pointe sur ma machine virtuelle 1
serv2.dafunky.fr pointe sur ma machine virtuelle 2 qui est sur la même ip publique que la 1
 
Ya moyen de faire ça?

oui avec un proxy nginx / haproxy / traefik / ...  

Vous n'auriez pas un dessin sous paint pour expliquer tout ça?

 
C'est l'utilitaire Aeotec qui doit se trouver sur leur site : ça permet de faire un backup de la clé sous forme d'un fichier sur ton disque dur, et ça permet aussi de restaurer un backup sur une clé.    
Donc à partir de là je te laisse voir comment cloner 1 clé sur une autre.    

 
Avec un Reverse Proxy.
J'utilise Nginx perso. Et ça a d'autres avantages : un point d'entrée unique en https sur tes différentes machines depuis l'extérieur, et la gestion centralisée des certificats https.
 
EDIT : si y'a 2 ans j'avais pensé un jour pouvoir sortir un truc comme ça sans mettre un gros redface en bout de ligne...    

Je viens de trouver sur gogol la même réponse, via un reverse proxy. Il me reste à voir si je mets le reverse sur mon serveur physique (windows) ou sur ma machine virtuelle linux (dans ce cas ce sera nginx).

Chez moi il est sur une VM Debian dédiée.
La raison d'une VM dédiée c'est qu'elle a son VLAN propre et ses règles de routage/firewall assez stricte comme c'est la seule ayant un port ouvert depuis le WAN sur mon routeur.
Car sinon en terme de charge c'est de loin la moins chargée de mes VM, elle est à toujours à 0% de CPU.  
 
Note : c'est actuellement imparfait, je n'ouvre que le port 443 mais tous les 63 mois pour renouveler les certificats letscencrypt je dois ouvrir temporairement le port 80 en plus. J'ai vu le sujet évoqué ici ou ailleurs, avec des histoires de dns ou je ne sais quoi, pas encore pris le temps de m'en occuper. Pour l'instant ça me convient, je reçois une alerte quelques jours avant l'expiration de mes certificats, et la manip me prend 5 minutes tous les 6 mois (le plus long étant d'attendre la prise en compte de l'ouverture ou de la fermeture du port par mon routeur).