Reprise du message précédent :

Personne ?
 
J'ai un peu creusé, globalement :
- pour les images il n'y a rien d'adapté à Proxmox ( https://www.home-assistant.io/hassio/installation/ )
- si j'ai bien capté, ils déconseillent (disons ne conseillent pas vraiment) l'installation sur un linux séparé et recommandent de privilégier une solution ou home assistant pilote tout l'OS (c'est bien ça la différence entre hass.io et home assistant tout court ? C'est pas clair leur truc).
 
Bref vous recommandez quoi pour se faire une instance sous proxmox ?

Si ça peut te rassurer, je tourne dans une VM proxmox depuis 1 an, c'est stable, aucun soucis.  
Les mises à jour passent, etc...
 
Je suis parti de ça: https://github.com/whiskerz007/proxmox_hassos_install

Comment on sent que tu maîtrise la technique et saisi bien la différence de notion de cloud indispensable genre qui veut dire que si tu n'as plus accès a ce cloud tu ne sais pas du tout piloter tes devices avec un cloud qui ajoute des fonctionnalités qui complètent ta solution mais qui reste entièrement pilotable en local
Sinon si vous nous présentiez vos solutions domo ?
 
Et pour la partie data :
Remote connection to your instance to control Home Assistant while being away. We will use end-to-end encryption to ensure that the cloud can’t read your data. Powered by Home Assistant Cloud so you just have to log in and it will work. This is the next feature to be worked on for the cloud

merci beaucoup ça a fonctionné du premier coup (faut avoir confiance dans le script, mais en regardant rapidement je n'ai rien vu de douteux)
Test en cours, je vais déjà voir ce que je peux faire avec MQTT...

 
Les attaques ad hominen, j'adore tjs .  
Que ca soit l'un ou l'autre (Saas ou extension de service), le fond ne change pas. L'auteur commence son introduction pour dire que la solution d'avoir sa domo dans le cloud c'est mal, mais propose un service d'extension de sa propre solution dans le cloud ... Ca me parait antagoniste comme position (même si je la comprends pour les raisons évoquées).  
 
Après, mon objectif n'est pas de polémiquer, je comprends parfaitement comme il l'indique d'ailleurs qu'il ouvre sa boite pour se professionnaliser et faire vivre sa solution. Ca me parait même sain comme démarche. Mais le business modèle n'est plus tout à fait le même. Comme le disait tonou, nous verrons bien dans quelques années.

j'ai lu en diagonale, mais pour moi il y a 2 concepts bien distincts.
 
les solutions :
1 - basées sur le cloud, où tout transite par l'extérieur avec Google Home / Alexa.
2 - stand-alone qui offrent un connecteur vers le cloud.
 
dans le 1 : tout transite par le cloud, y compris quand tu es chez toi et que tu demandes d'allumer l'ampoule située à 2m.
si tu n'as plus de connexion internet, tu n'as plus accès à rien.
niveau confidentialité, c'est zero puisque tout est hébergé sur le cloud
(ex. la Gateway Xiaomi... qui s'amuse à bazarder toutes tes infos sur un obscur serveur chinois)
 
dans le 2 : tout fonctionne de base en local
si tu n'as pas de connexion internet, ta domotique fonctionne toujours
le connecteur cloud permet d'exposer certaines API à des services cloud genre Google Home / Alexa / Siri... et tu décides toi même précisément de ce que tu exposes à ces services (c'est pas Open Bar).
 
bref, les deux approches me paraissent diamètralement opposée... à part qu'il y a en effet le mot "cloud" dans chacune d'elles

 
Hé ben c'est pas gagné, j'ai créé un nouvel user dans HA (mqttadmin) avec un pass, en espérant (d'après la doc) qu'il soit accepté par mosquito sans qu'il y ait besoin de configurer autre chose, ... ben ça n'a pas l'air de marcher j'ai loupé un truc ?
 

 
192.168.1.33 c'est l'esp8266 relié à ma PAC mitsubishi qui lit/poste en MQTT avec le user mqttadmin et le passe qui va bien.
J'ai redémarré tout des 2 côtés sans que ça ne change rien.
 
Edit : bon en forçant le login/pass en clair dans la config du plugin mqtt de hass c'est passé. Bizarre cette histoire.

cool
 
Bon on va passer à l'étape suivante : comment je peux requêter en http HASS pour recevoir /envoyer des commandes ?

Je test un peu Node Red sur Home Assistant, ça semble très puissant !
 
Par contre à priori impossible de "désactiver" ou mettre en "standby" un Workflow ... bizarre non ?
Comment vous faire pour gérer ça de votre coté ?

Bah sorry mais non ce que tu dis est faux
Il explique que des devices qui dépendent du cloud pour être pilotés c'est de la merde mais que ça changera pas car les fabricants de ces dits devices ce qu'ils veulent ce sont tes data.
Pour cette raison il a créé hass.
Ensuite il ont décidé pour financer le projet une extension naturelle du truc avec un service cloud, service qui ne voit pas ce que tu fais/commande car encrypte de bout en bout.
Service qui n'est pas indispensable pour piloter ta domotique qui reste accessible en local si cloud pas dispo.
Donc non y a absolument rien d'antagoniste la dedans.
Et voir la derrière l'arrivée de service indispensables et payants voir d'un store a la jeedom si c'est pas pour polémiquer j'ai du mal a saisir l'intérêt.  
 
Sinon t'as pas répondu, c'est quoi ta config ?
 

 
j'ai la même config que dd_pak  et elle tourne parfaitement

@the_big_poulet
Dis moi t'as pas de soucis avec Max home automation qui tourne dans docker? Chez moi il freeze tous les 6-10 jours environ... Je fais un restart du conteneur et ça repart mais c'est étrange, rien dans les logs...

 
Double-clic sur l'onglet, tu accès aux propriétés du flow et en bas tu as une checkbox pour desactiver.
Sinon même principe sur n'importe quel noeud, la même checkbox pour désactiver rapidement un noeud.

Bon je vais tester zigbee2mqtt (pour le coté opensource et parce que je n'aurai pas 36000 devices), et en profiter pour acheter quelques accessoires. En plus l'association directeur actionneur-capteur pourra me permettre de résoudre un problème de lumière dans un couloir (2 points de lumière qui ne sont pas actionnés par les mêmes interrupteurs)
Des marques à privilégier pour les capteurs (aqara/mijia, ikea j'imagine) sur les sites chinois (ali ou BG) ?
 
En passant, en configurant MQTT sur Hass.io en docker sur synology, je ne vois pas les shelly remonter dans l'onglet "integration", alors qu'ils sont bien remontés sur le broker. je suis obligé de les ajouter via le fichier confiiguration. C'est normal ?  
 
Merci
 

tu as bien activé l'ajout automatique des devices MQTT ?
 
 
ACTIVER LE RAJOUT DES DEVICES DEPUIS MQTT
1> aller dans la gestion des intégrations (bandeau "Configuration", tab "Intégrations" )
et cliquer sur "MQTT : Mosquitto broker".
2> activer l'intégration des entités MQTT.
cette option permettra aux éléments détectés par MQTT d'être automatiquement rajoutés sur Hass.io
 

 
Attention "l'association directeur actionneur-capteur" n'est pas possible sur tout les appareils, pas sur les Xiaomi par exemple (hormis le dernier opple).

 
Merci pour les explications, c'est très clair.    
Dans le cas numéro 2, cas qui est proposé par HA, il demeure que ca m’apparaît équivalent, phylosophiquement parlant, à des plugins que tu pourrais avoir dans certaines solutions concurrentes, hébergés à la maison et fonctionnant en local mais qui utilisent ces plugins en se connectant à des services externes chez des prestataires extérieures ?
 

 
D'accord, c'est clair et merci pour l'effort de synthèse/réponse . Par ailleurs, je rejoins complètement le fait que la solution domo doit être le plus possible indépendante de services extérieurs.
 
Mais je ne comprends quand même pas quel est la plus value à choisir cette extension cloud ?  
C'est un simple proxy entre ta solution et des services externes ? Et ces services externes, tu ne peux les avoir qu'en prenant leur extension ou tu peux bidouiller de ton côté ? HA me semble destiner, de l'extérieur (je rappelle que je connais pas) à un public averti, qui va tester et prendre du temps. En particulier, en suivant les derniers échanges, j'ai compris que ca bougeait pas mal donc ça doit nécessitait de mettre à jour régulièrement.  
Ce public visé est largement capable (à priori), si on lui donne les add-on, de connecter directement sa solution avec ses services externes (pilotoge ASR Alexa/Google, gateway sms, appli mobile sympa directement connecté à sa solution plutôt qu'à son cloud proxy, etc.) Il y a quand même quelques choses que je saisis pas dans le modèle.  
A moins que ces services ne soient pas/plus aisément maintenables dans le temps, par la communauté ,"forçant" d'une certaine manière l'utilisateur a payer ce service pour en bénéficier. (encore une fois, c'est pas un mal, mais je pense qu'il faut quand même être conscient du risque que ça puisse arriver. Ca serait pas les premiers à faire ça en tout cas, et faire payer une version premium via des services hébergés chez eux)
 
Pour ma solution, je n'ai pas répondu puisque tu m'as tutoyé puis vouvoyé donc je n'ai pas compris (ou pas voulu comprendre  ) que la question s'adressait directement à moi ou à l'auditoire !
Je suis un noob dans la domo (un peu moins dans l'info ). J'en ai marre de me faire piquer par les moustiques et cette année j'ai décidé de faire de l'arrosage automatique. Je suis depuis 2 mois sur une jeedom virtualisé avec un controleur gen5 en pass-through usb, quelques modules switch chez fibaro contrôlant les EV mis en place récemment (5) et un pluviomètre. J'envisage de basculer complètement sur HC3 dès qu'une promo s'approchera des 500 balles puis domotiser au fil du temps l'intégralité de ce qui peut l'être, à l'intérieur comme à l'extérieur, en zwave exclusivement.

Oui c'est bien le cas, je viens de vérifier.
Le device est aussi decouvrable

J'essaierai demain avec un autre module pour voir si ça fonctionne

C'est noté merci ! J'y ferai attention

j'ai un soucis sur zigbee2mqtt : impossible d'ajouter de nouveau device
j'ai tenté avec 3 différents (xiaomi button , porte et mouvements) mais toujours pareil.

J'ai supprimé avec succès un de mes capteurs mais pas possible de le rajouter à nouveau.

Vous avez déjà eu ce soucis ? des idées pour le résoudre ?

edit : j'avais tenté le reboot via ssh sans succès mais après un bon reboot hard ça remarche

avec le plugin zigbee2mqtt de hassio et z2massistant, j'appairage n'est valide que pendant 20 min, et de désactive ensuite automatiquement.
 
 
 
ATTENTION : dans le Plugin Zigbee2Mqtt assistant, aller sur l'onglet "Status" et cliquer sur "ALLOW NEW DEVICES TO JOIN NETWORK"

 
 
je prépare un tuto pour l'installation de Hass.io sur une install débian fraiche, plus installation de quelques modules (Mosquitto, SSH, FileEditor, Portainer, Zigbee2Mqtt, Zigbee2MqttAssistant).
Je dois peaufiner tout ça avant de le poster.... peut être dans un topic dédié pour éviter de perdre ça dans les méandres du topic (et de faire chier tous ceux qui ne sont pas sous Hass.io )

 
Hé ben pas compliqué finalement
 
C'est nickel merci !  

 
IKEA ça marche bien.
Je suis assez content de mes devices Konke en test depuis quelques semaines. Ils font le même taf au même prix que les Xiaomi mais me semblent plus intelligent dans le routage en cas de perte de leur routeur Zigbee attribué.

Comme je pense que big_poulet m'incluait dans le vous je vais me permettre de répondre. Aujourd'hui ma domotique est basée à 95% sur du z-wave. J'ai environ 70 modules.

Le tout est géré par un contrôleur jeedom sur un z83 depuis environ trois ans.

J'ai utilisé Jeedom depuis quasiment cinq ans sans discontinuer. Honnêtement au niveau des fonctionnalités, la solution Jeedom couvre tous mes besoins sans mettre la main au portefeuille. J'ai acheté un pack jeedom pour les supporter dans leurs efforts plus que par besoin. Je paie 12€ par an pour les accès aux assistants vocaux exactement pour la même raison, alors même que je serais capable de faire sans.

Si on retrace l'histoire de Jeedom, on se rend compte qu'elle est très proche de celle d'home assistant. Les deux solutions sont parties d'une personne qui  ne se retrouve pas dans les solutions existantes et décide de mettre les mains dans le cambouis. L'un et l'autre mettent naturellement en ligne leur code sans comprendre au départ dans quoi ils mettent le doigt. Assez rapidement, les projets trouvent leur public et attirent d'autres développeurs talentueux. Le projet prend de l'ampleur et devient chronophage. Ils décident pour accélérer les projets de monter des équipes de dev. Pour se faire, ils cherchent à monétiser leur solution. Jeedom le fait avec la solution à la mode à ce moment là : un store d'apps. Que ça plaise ou pas à ce moment de l'évolution de Jeedom, les solutions pour monétiser la solution étaient peu nombreuses. Ils explorent ensuite une autre piste : les box et les packs. Le problème étant que ces deux produits ne créent pas de récurrent et ne permettent pas d'engager des ressources sur la durée sereinement. Jeedom ajouté également une activité de service et de formation auprès des pros, sûrement pour aller vers un modèle générant plus de récurrent. La dernière étape est commune aux deux solutions et apporte enfin une source de récurrent : les services cloud. C'est pour moi une avancée majeure puisque c'est ce qui peut apporter à ces solutions un financement pérenne.

Tout ce pavé pour dire que je crois que les philosophies de Jeedom et Home Assistant sont très proches pour ne pas dire identiques. Là où je te rejoins big_poulet c'est que la dynamique est clairement du côté d'home assistant, au moins pour l'instant. Par contre Home Assistant est à un tournant, le projet doit élargir sa clientèle pour assurer les rentrées d'argent nécessaires au financement des équipes de dev car le public originel n'a pas forcément besoin de payer pour avoir les fonctionnalités offertes par Nabu Casa. Il va donc falloir forcément qu'ils offrent des fonctionnalités un peu premium s'il veulent maximiser l'adhésion à leurs offres cloud au sein du public actuel. Honnêtement en l'état, Home Assistant est très loin de pouvoir attirer autre chose que des geeks déjà bien atteints (j'en fais partie, no offense). Il va leur falloir un effort immense pour faciliter l'adhésion par des personnes normales. Si on compare un peu avec l'histoire de Jeedom, cette période correspond au passage à la V3 en 2017, version dans laquelle beaucoup d'utilisateurs historiques se sont sentis lésés (dont moi). Cette version était une version de fiabilisation et de simplification. Elle supprimait notamment le mode esclave qui était très pointu et coûteux. Elle arrivait juste après l'application Android et iPhone qui est arrivée il y a moins de 6 mois chez hass si je ne m'abuse.

Pour finir mon pavé, je vais juste parler du peu d'expérience que j'ai avec Home Assistant. J'ai fait trois essais de Hass depuis le départ. A chaque fois je bloque sur un truc. La première fois il y a presque deux ans je crois c'est l'install qui avait eu raison de ma patience. C'était vraiment le bordel. Il y a un an j'ai refait un test l'install s'est cette fois ci passée correctement, j'ai installé directement hass.io. par contre l'intégration z-wave était un peu à chier. Déjà elle était basée sur une vieille version d'openzwave qui ne supportait pas les sévices récents et beaucoup de command class ( la version d'openzwave datait je crois d'avant la diffusion par sigma de tous les documents de la norme z-wave, donc entièrement basée sur du rétro engineering). Il y a environ quatre mois j'ai décidé de refaire un test de Hass suit à ce thread : https://community.home-assistant.io [...] ve/148541. En Gros Hass serait en train d'évoluer vers un découplage z-wave Hass via mqtt. Cela permettrait de pouvoir modifier la conf de Hass sans redémarrer le z-wave (eh oui on est là sur Home Assistant), mais surtout de permettre à Hass d'utiliser une version totalement à jour d'openzwave, ce qui permettrait de rattraper une bonne partie du retard qu'ont les produits open source par rapport à des box comme les fibaro en matière d'intégration z-wave. Je suis donc le projet car c'est pour moi très prometteur et pourrait me faire basculer, mais honnêtement ça marchotte, mais on est très loin de pouvoir parler de mettre ça en prod.

Cette année je commence à ressentir que je suis à un tournant. Je ne sais pas quel virage je vais prendre. Soit je vais vers plus de geekerie en migrant tout sur Hass, soit j'achète une HC3, soit Jeedom se sort les doigts sur le z-wave qui est un peu à l'abandon depuis presque deux ans (mais fonctionne). En gros la question est : vais je me faire hyper par Lazer ou Shaad cette année ?

tu les trouves où les devices Konke ?

ah oui, ils sont pas les seuls à avoir cette idée et à l'implémenter de la sorte.
la pluspart des solutions domotiques geek/open source sont sur ce concept : un système autonome, et un connecteur "cloud" pour pouvoir rattacher ça aux services des Gafas
 

J'avoue que j'ai du mal à voir le business model là dedans...
Hass se destine aux geeks, qui veulent avoir une solution domotique OpenSource, communautaire, et locale.
 
Le gars qui souhaite un truc tout en un, il prends une Somfy Tahoma, une Box Leroy Merlin ou un truc du genre...
si il est capable de flasher la SD de son RPi avec une distrib de Hass.io, il saura faire les connecteurs cloud lui même.
 
Je ne sais pas pourquoi personne ne se tourne vers une monétisation "pro" : les hotels, sites de conférences, espaces de coworking, locaux d'entreprise & cie ont besoin de domotique.
les solutions actuelles sont (très) chères.
et une offre de services basée sur un soft domotique pourrait bousculer ce marché.
 
Je ne connais que Eclipse Smarthome (sur lequel est basé OpenHAB) qui a une déclinaison pro :
https://www.eclipse.org/smarthome/

 
   
 
Viens, on part sur Hubitat, on boucle une install+conf rock-stable en 2-3 jours et après on profite de tout ce nouveau temps libre pour  
 
EDIT : enfin, du temps libre ce n'est pas pour tout de suite... je viens de mettre encore les doigts dans un golden engrenage en remplaçant mon serveur ESXi par un cluster Promox...    

 
Aliexpress.
J'ai un interrupteur, un capteur température/humidité et un capteur PIR.

Une VM dédiée (debian) + suivre : https://www.home-assistant.io/hassi [...] linux-host
 
Édit : ok j'avais pas lu tous les.messages du topic avant de répondre !  

 
Un bâtiment commercial ce n'est pas une maison. Les attentes ne sont pas les même, le hardware n'est pas le même non plus.
C'est un monde dominé par les automates programmables    
 

Nope franchement jamais eu ce souci, le seul truc que j'ai parfois c'est que au restart du container il se connecte pas tout seul au cube.
En fait ça arrive surtout si j'ai un full restart serveur après une coupure de courant.
ou si je déconnecte le cube pour une raison X ou Y
Sinon c'est très stable.

C'est déjà le cas et c'est pour ça qu'lis ont pensé a ce service cloud au départ a mon avis.
Tu ne peux pas piloter une application/des devices sans passer par une intégration autorisée et validée par google qui passent donc par les serveurs clouds de la dite intégration => nabu casa.
La solution qui permet d'intégrer ghome a hass sans nabucasa c'est de la bricole avec une application en "test" du coté ghome.
 

Petite précision la version IOS de l'app existe depuis nu bail sur hass, c'est la version officielle android qui vient d'arriver (meme si il en existait déjà de très efficaces avant).
 
Perso je reste mitigé sur cette vision de philosophie partagée entre hass et jeedom.
Ce que je reproche au store d'app avec version payantes c'est que ça n'est pas du tout compatible avec la notion d'open source et de communauté.
Le dev peut arrêter le support de son plugin du jour au lendemain, personne ne peux lui proposer de patch ou autre car pas d'accès a son code.
Et la on parle de ce qui tourne chez toi sur ta bécane et qui donc peut rendre ta solution obsolète du jour au lendemain en fonction de ta dépendance ou pas à ce dit plugin.
 
Et ça pour moi c'est pas un projet qui m'intéresse, après oui effectivement ils n'ont peut etre pas eu le choix à l'époque pour trouver du finnancement, mais moi lorsque j'ai commencé ma domotique il y a 2 ans j'avais bien le choix et ça a largement fait partie de ma décision (et non pas du tout la hype hass car j'étais a peu près le premier sur ce topik   )

Je vois que ma question est un peu passée a la trappe...
Personne ne s'en souviens ?
Si au moins j'ai un pseudo je peux faire une recherche dessus quoi

mooms l'a fait en guise d'horloge électrique lors d'un passage HP/HC vers le forfait de base.

C'est ce que je veux faire , mais a la place d'un contacteur (ça s'appelle comme ça ?) Et je suis en HP/HC. Je veux juste savoir quel modèle prendre, est ce que la version 10A suffit ? ( https://m.banggood.com/SONOFF-Basic [...] tent=rambo )

 
 
Voilà un schéma de l'installation de mon couloir :

 
J'imagine 2 solutions :  
 

• Solution 1 - la plus propre :

Dans l'idéal je souhaiterais conserver le va-et-vient en "dur". Est ce que vous savez s'il existe un équivalent zigbee du Fibaro FGD-211 ou 212 pour réaliser ce montage http://tutoriels.domotique-store.f [...] vient.html ? CàD un module sans neutre, capable d'interpréter un switch provenant d'un inter en impulsionnel.
 
Sinon je bidouillerai un truc avec un shelly1, je devrais pouvoir amener assez facilement la phase au niveau de l'ampoule, pour tomber sur un montage comme celui-ci : http://bozothegeek.blogspot.com/20 [...] -avec.html
 
 

• Solution 2 - ça marche aussi :

Admettons que je remplace les 3 interrupteurs par des aqara par exemple :
- via HA je les pilote ensemble ;
- si mon serveur est HS je garde le fonctionnement manuel, avec 1 seul inter fonctionnel pour la ligne de droite
solution qui me conviendrait.
 
Du coup reste à trouver le switch sans neutre équivalent au fibaro mais en zigbee ou wifi, si vous avez une idée

La t'arrives sur un point intéressant. Tu parles de compatibilité du market Jeedom avec l'Open source, et plus particulièrement la licence gplv3.
Déjà Jeedom a une vision très particulière de l'Open source. Ils utilisent beaucoup de projets open-source, forkent les projets mais ne te restent que très peu. Le meilleur exemple, c'est openzwave. Ils ont forké il y a un moment pour inclure de nouvelles command classes, mais n'ont jamais poussé leurs devs dans la lib originelle. Ça c'est le premier point.

Le second point c'est que normalement les plugins présents sur le market sont tous sous licence GPL puisque basés sur un projet original sous licence gpl. Le code est donc libre et doit donc être disponible pour diffusion, et sur ce point ils entretiennent le flou. Le prix que tu payes sur le market est censé être une rémunération du mode de diffusion plus que du contenu. Depuis un moment pour démerder les situations que tu evoquais, je le ont même rajouté une clause instaurant les plugins legacy, en gros si en tant que dev tu ne maintiens pas ton code, ils s'autorisent à le reprendre à ta place sans compensation aucune.

Tu auras bien compris que je ne suis vraiment pas fan de leur système de plugin, même si il a permis à Jeedom de se structurer un petit peu, et ça pour le coup c'est indéniablement une bonne chose.

 
Est ce que c'était ça ? https://opendomotech.com/chauffe-eau-jeedom-esp-easy/

Switch ou micro module ?
On voit tres souvent la meme demande, en switch zigbee sans neutre il y en a chez legrand, Xiaomi, zemismart, Tuya, surtout pas livolo, et il y a des modeles allemand et chinois qui marchent pas mal mais je les connais pas de tête, trouvable avec google.

Jamais vu en wifi sans neutre (Zemismart, mais pas de retour dessus)

Oula  
Ça ma l'air beaucoup trop compliqué !  
JE voulais juste mettre le sonoff sur le ça le d'alim juste avant le ballon , c'est pas possible ?

 
Ce qui est dit c’est que généralement les sonoffs, bien que calibrés pour 16A acceptent généralement moins (10A).. et que c’est plutôt conseillé qu’ils servent juste de contact pour la partie puissance..  
 
J’ai acheté un disjoncteur 2A et un relais de la marque Lexmann  
Disjoncteur: https://www.leroymerlin.fr/reflm/69839945 8.99€  
Relais: https://www.leroymerlin.fr/reflm/69840386 29€  
 
Total: moins de 40€. Et je pense que je serais plus en sécurité qu’en mettant un sonoff en partie puissance..

Mon souci c'est que je n'ai pas de disjoncteur dédié au ballon dans le tableau électrique et je ne m'y connais pas assez en électricité.  
Si trop compliqué, peut être une simple minuterie mécanique serait plus adaptée ? Ou le souci est le même ?

 
Mon vocabulaire n'est peut être pas le bon, par switch j'entendais "interrupteur intelligent", donc effectivement il y en a plein  
 
Dans le premier lien en zigate, il s'agit d'un micro module sans neutre, disposant de 2 entrées S1 et S2 pour "connecter deux interrupteurs bi-stables sur deux entrées différentes, que les interrupteurs puissent être reliés à la phase et que ce module puisse interpréter cela comme du va-et-vient (fonction logicielle)" dixit le tuto. Je cherche l'équivalent, c'est là où j'ai plus de mal
 
Sinon tant pis    
 

Je viens de faire le test, le Shelly ne remonte pas sur HA, alors que le plugin mqtt détecte la nouvelle connexion.

Bizarre...