Reprise du message précédent :
J'utilise un PI3 (1Go de RAM) avec le serveur MQTT sur mon NAS.
Je pilote en MQTT :

• Mes lumières (23) qui sont sur un IPX V4 (automate dans le tableau électrique)  
• Mon poêle Palazzetti Ines

Et en natif :

• Spotify
• Ampli Marantz
• Freebox
• Prises Shelly
• Google Home Mini

Je n'ai jamais senti de ralentissement perso...
 
Par rapport à Jeedom, je dirais que :

• C'est plus joli (subjectif) et on peut facilement agencer les éléments sur un dashboard
• Assez léger, ne consomme pas beaucoup de RAM (installation conteneurisé)
• Tous les plugins sont gratuits
• Bien documenté (mais en Anglais)
• Fun, ça m'a motivé à me mettre à Python pour mon poêle et l'IPX

J'aimerais bien automatiser les lumieres chez moi au niveau du tableau mais je vois pas trop comment faire ca.
Tu as branché ton IPX directement sur le tableau ?

désolé de répondre si tard.
 
alors en fait : non.
on ne peut pas utiliser le code d'une télécommande physique... car ça impliquerait de ne plus utiliser cette télécommande physique comme c'est basé sur un code tournant.
 
le bout de code cité vise juste à "écouter" les impulsions sur les télécommandes physiques, pour mesurer le temps écoulé entre les instructions et ainsi "simuler" le positionnement des volets.
(ça ne fonctionne plus chez moi suite à la dernière MAJ de Hass.io : ils ont cassé un truc dans le plugin. Je suis revenu au fonctionnement "classique", où j'ai accès aux actions UP/DOWN/STOP, mais je n'ai plus de simulation de leur position)

oui, chaque volet supporte plusieurs télécommandes, donc pas de pb pour conserver la télécommande physique
+ y associer une télécommande "virtuelle" pilotée par le RFLink

 
Oui, il y a des X8R et XDimmer (modules pour IPX) qui sont branchés comme des télérupteur. Pour cela il faut que chaque point lumineux revienne au tableau.
L'inconvénient c'est que ça fait beaucoup de câble à tirer et qu'il fut prévoir au moment de la construction ou rénovation lourde. L'avantage c'est que c'est assez facilement remplaçable par une autre solution si besoin.

Drap

merci pour la confirmation

Je viens d'ajouter également la prise en charge de mes volets Bubendorff avec le iDiamant, via l'API en ligne. Plus d'infos ici pour ceux que ça peux intéresser : https://github.com/LeClubber/iDiamant2Mqtt

Hello

J'ai intégré idiamant via homekit sous ha
Tu as pu comparer les 2 méthodes ?

A vrai dire je l'ai jamais fais avec Homekit, mais ici l'avantage c'est que ça gère le « STOP » du volet (mais toujours pas de position intermédiaire directement).
Le désavantage c'est que ça passe par une API internet, alors que Homekit reste en local il me semble.

J'avoue ne pas avoir fait le test de couper le net et voir si je conservais le pilotage des volets. J'essaierai à l'occasion !

Tu as aussi le retour d'état lorsque c'est piloté avec la télécommande ? C'est le cas avec homekit
Mais je ne gère pas le stop (et c'est dommage !) ni le positionnement...

Je n'ai pas traité le retour d'état (qui est dans l'API) car dans un premier temps c'est les commandes qui m'intéressaient, et surtout le stop qui est un indispensable.
Je testerai plus tard.

Un comportement que je ne comprend pas dans HA : j'ai des groupes d'interrupteurs et de lumières.
Le groupe de lumières est créé dans configuration.yaml.
Le groupe d'interrupteurs est géré de la façon suivante : des interrupteurs physiques (séparés dans les options Shelly pour qu'ils n'actionnent pas directement le Shelly) actionnent un interrupteur virtuel qui lui actionne les Shelly.
Tout fonctionne très bien sauf quand je redémarre HA ou le wifi.
Là certains éléments clignotent brièvement ou s'allument sans raison au moment où HA démarre ou à la restauration du wifi.
 
Comment empêcher ce comportement ?  

Quelle version de HA ? C'est quoi ton inter virtuel ? Un boolean ?
 
Contrairement à ce qu'on peut penser, un input_boolean peut avoir 3 états    On/Off et unavailable notamment au démarrage.
 
Et pareil dans une version récente (2021.12 ? pas sûr), ils ont ajouté cet état inconnu dans les binary_sensor.

J'ai reçu mon Pi4, mis à jour le firmware, priorisé le boot USB et mis l'image de hassio sur SSD, et ça marche au poil.
J'ai rajouté les modules nodered, samba, phpmyadmin, dbmaria sur lequel j'ai transféré les enregistrements du recorder.
 
Me manque plus que la clef conbee et les objets connectés

 
Ca démarre plus vite ?
 

En dehors des intégrations servant à piloter des des éléments (volets, moteurs etc.) ou capter des informations (capteurs de fumée, de lumière, de position, d'humidité etc.), quelles sont les intégrations que vous trouvez essentielles ? (Serveur multimedia, alarme, météo, transports etc.)

 
J'ai pas vraiment d’élément de comparaison, première fois que j'installe Hassio sur un RPI.
J'ai surtout fait ce choix dans un soucis de stabilité et disponibilité du système vu son importance (à terme), les cartes SD ont tendance à planter assez rapidement avec de l'écriture de logs en continu.
(ou alors il aurait fallu à minima déporter la base de données sur une autre machine pour limiter les écritures)

Ahhh c'est surement ce troisième état qui fait tout déconner au démarrage !
 
Est-ce qu'en mettant deux trigger comme ça c'est bon ? Ca se comporte comme un "ou" entre les deux ?    
 

 
 
Un seul trigger suffit à lancer l'automation. On peut pas vraiment dire que c'est un "ou" dans les triggers, il faut le voir comme un évènement qui apparaît et disparaît aussi vite.
Tu fais une liste, et n'importe lequel va lancer l'exécution.
 
Par contre, je ne comprends pas la logique de la condition. Car pour le 1er trigger (off to on), je comprends que tu vérifies que la lampe est bien éteinte (et encore, si tu fais deux fois "on", le second n'aura aucun effet), mais pour le cas 2 (on to off), tu veux aussi allumer ?
Ce que je comprends de ton automatisation, c'est que tu ne vas que allumer la lampe par là, jamais l'éteindre.

Dans une vidéo de tuto sur Z2M et Nodered j'ai vu la personne se faire chier à aller configurer le .yaml avec les actions et sensors disponibles sur le device qui venait d'être reconnu par Z2M.
Je fais rien de tout ça à part l'appairage dans Z2M et Home Assistant semble bien reconnaître les entités.  
Du coup je passe à côté de quelque chose ou c'est une technique obsolète ?
 
 
Deuxième question, dans NodeRed j'arrive à allumer une lampe en lui donnant un paramètre supplémentaires de luminosité, pour ça je renseigne {"brightness":20} dans le champ data.
Mais comment faire pour lire la valeur de brightness, pour en faire une condition par exemple ?
 
Merci

 
Je suppose qu'il ne doit pas utiliser l'auto-discovery MQTT, et ainsi qu'il configure à la main une à une les entités MQTT qu'il souhaite utiliser. Le seul avantage de ça est d'éviter la création automatique de toutes les entités possibles y compris certaines inutiles.
Perso je suis de la team à moitié faignant, auto-discovery et je désactive quand-même sans HA toutes les entités que je n'utilise pas.
 
 

 
Tu récupéres l'état de ta lampe tu testes la valeur de luminosité. Je n'ai pas accès mon NodeRed là mais y'a rien de sorcier.
 
Tu créées un mini flow de test : tu mets un inject puis un noeud qui récupère l'état de ta lampe, et enfin un noeud debug derrière et tu regardes dans le debug où se trouve l'info dont tu as besoin, surement un truc du genre payload.data.brightness ou un truc approchant.

En fait je dissocie l'interrupteur physique de l'interrupteur virtuel.
Il y a le bouton sur lequel j'appuie, qui a la valeur "input" dans HA et l'interrupteur du Shelly qui a la valeur "switch" dans HA.
S'agissant d'un interrupteur à bascule, il peut passer du on vers off ou off et avoir en face un switch on ou off... d'où mon automatisation.
Je sais pas si je suis très claire.
En tout cas je pense que le problème venait bien de cet état unavailable, je vais poursuivre mes tests.

 
 
Merci  
 
Pour la 2ème question je procédais bien comme ça mais dans le debug j'avais beau demander le complete message je ne voyais rien d'autre que "payloas:on"... forcément je n'ai pas pensé à dérouler data dans la fenêtre de debug  
 
Du coup j'arrive à mes fins avec un current state de la lampe suivi d'un switch sur msg.data.brightness

 
Ok, je comprends que si tu appuies sur un inter, et que la lampe est off, quel que soit l'état de l'inter, tu allumes.
En symétrique, si la lampe est on, tu appuies, tu éteins.
 
Le unavailable est pas très intuitif et ça peut faire des surprises. Mais même avec un "vrai" capteur, tu peux avoir cet état transitoire, donc en général, il vaut mieux mettre le changement d'état complet (from/to) plutôt que juste la cible.

J'ai essayé de passer sur le plan annuel Nabu Casa à 65USD en passant par un VPN US sans succès, quelqu'un a tenté ?

ça fait très longtemps que je n'ai pas regardé, mais à l'époque je n'avais pas trop saisi l'intérêt...
 
un reverse proxy se configure facilement/rapidement (aller, en moins de 2h c'est plié si on s'y prends bien), et peut s'occuper correctement de tout ça

Avec l'abonnement Nabu Casa tu n'as besoin d'aucune ouverture de port sur ton routeur. Si HA est ton seul besoin par exemple c'est un peu plus secure.
Dans certains cas (le mien) ça peut aussi permettre de bypasser certains proxy un peu violent comme celui de ma boite.

Tu fais comment pour BlueIris ?

Hello,
 
J'ai un aqara button que je souhaite placer sur une action de fermeture de volets. J'aimerais n'utiliser que le button press pour ouvrir ou fermer en fonction.
J'ai placé ca qui marche bien :
 

 
J'aimerais placer une condition sur le type ou placer close si c'est ouvert et inversement, mais je vois pas comment ordonner cela et je me demande meme si c'est possible en fait. QQun aurait une astuce ?

Pourquoi ne pas passer par un toggle plutôt qu'un close ? Ça va automatiquement changer la consigne à chaque action

Toggle n'est pas possible sur une automation justement :  
['close', 'close_tilt', 'open', 'open_tilt', 'stop']

T’as le retour d’état de tes volets ?

Comme Shaad le proxy taf est très restrictif où même l'accès à Nabucasa était bloqué jusqu'à la semaine dernière mais il vient d'y avoir du changement, mais surtout c'est l'intégration avec Google Home qui m'intéresse tellement c'est simple à mettre en place par le lien Nabucasa.

 
Je ne fais pas. Blue Iris fait sa vie, je n'y accède pas depuis l'extérieur. Je reçois des notifs en cas d'alerte.
Si je veux consulter mes cameras je ne peux le faire que via Home Assistant.
 
Sinon j'ai un accès VPN que j'utilise depuis mon smartphone ou mon laptop perso dès que je ne ne suis pas au taf, mais inutilisable depuis le boulot.

nan j'ai pas donc je comprends le soucis je vais rester sur le 1 click + 2 clicks pour faire ce que je veux tant pis.

Bonjour,
 
Après avoir configuré Duck DNS et ajouté la règle NAT qui va bien dans ma box, j'ai donc mon_domaine.duckdns.org:8123 qui fonctionne bien (de l'extérieur et de l'intérieur) en https.  Cependant en local (homeassistant.local:8123), évidement, j'ai un soucis avec le certificat SSL...
 
Et ca pose aussi soucis avec l'application sur android :
- sur l'appareil qui a une SIM, il faut configurer l'url de duckdns... et passer par la 4G. En Wifi ca fonctionne aussi, sauf si plus de fibre !
- sur celui qui est sans SIM (tablette), même réglage.
 
Mais voilà, mon FAI génère souvent des coupures des fibres (merci l'installation sous dimensionnée dans la résidence), et donc l'accès en local avec l'application ne fonctionne plus depuis l'application (même avec l'adresse locale).
 
J'ai fait un truc tout "con" dans la box, définir une règle DNS de mon_domaine.duckdns.org sur l'IP de mon HA. Ca marche impeccable en HTTPS... et même si le WAN est HS, ca marche encore ^^.
Pas besoin de passer par NGINX. C'est débile comme solution ou pas ?

La nouvelle intégration du soleil fonctionne chez vous ?
Je n'ai pas d'entité   :
 

Ouep, j'ai eu qq soucis avec une carte qui ne fonctionnait plus suite à MAJ, mais mettant la carte à jour, c'est parti.

Pas tout compris.
Quand j'ajoute le Soleil dans les intégrations, je n'ai pas d'appareils ou d'entités qui se créer.

J'utilise la carte "type: custom:sun-card" : c'est là que j'ai vu que j'avais un soucis.

C’est un module HACS ça, aucun lien avec la nouvelle intégration native non ?