C’est toujours bien niveau ouverture et tarif, mais le pb reste à mon sens la connectivité wifi: Niveau conso, association (WPS obligatoire? Chez moi il est systématiquement désactivé, dommage!)… A la limite, pour des modules qui sont tous à brancher je préférerais les voir sur un réseau CPL dédié avec un module prise à brancher sur son réseau qui gère les accès au CPL Shelly. On pourrait même revenir à des normes assez anciennes/stables et moins consommatrices. Pour passer un ordre ou remonter une info/état de temps en temps, cela suffirait bien.

scadinot a dit:

Par contre, quand le tableau électrique est ancien, que peut-on mettre comme switch Ethernet sur un rail DIN ? (a un prix raisonnable)

Normalement, on n’est pas censé mélanger courants faibles (le réseau en fait partie) et forts: Même si la NFC ¹⁵⁄₁₀₀ donne à ce sujet quelques raisons de sourire (genre gaines séparées avec 5cm de séparation en horizontal et 30cm en vertical??!! Le champ magnétique serait-il sensible à la pesanteur!!!), surtout que le 1er élément en face d’un RJ45 avant le transceiver et le controleur, c’est un transfo d’isolement… mélanger les deux dans un tableau électrique ne serait pour le coup pas très avisé.

Là, pour le coup, il n’y a que la radio qui permette de satisfaire aux contraintes réglementaires.

ForceRouge a dit:

Pourquoi vouloir virer le zwave?

Je ne le ferais pas non plus, en l’état de la concurrence, mais il y a objectivement quelques raisons d’y penser quand on n’a pas trop de périphériques et que des alternatives existent: En tout premier lieu, un open-zwave à l’abandon depuis 9 mois et le retrait du principal (voir seul, hors babioles et fichiers de config) contributeur, qui manquait encore de maturité dans sa version actuelle (plantages réguliers au démarrage ou à l’inclusion, voir simple changement de config et réveil d’un module à pile pour prise en compte ; heureusement, hors ces cas là c’est stable sur des semaines d’uptime).

Il semblerait que sigma design pousse d’ici la fin d’année une librairie open source plus simple à intégrer que Z-IP… Mais pour l’instant l’avenir est un peu sombre. Sans compter le temps de portage des domoticz/jeedom et autres, temps de stabilisation + conséquences ensuite sur l’intégration de son système.

Certes, il reste des points forts comme l’interopérabilité (vs zigbee par exemple) et la basse conso même pas en rêve avec du wifi (rendant les modules à pile viables). Mais la situation actuelle n’est pas très rose comparé à il y a seulement 1 an.

brazomyna a dit:

La lib openZwave est à l’abandon, mais elle fonctionne toujours aussi bien chez moi. Et elle a surtout été poussée à la retraite par ZWave-JS qui est déjà adoptée divers soft domotiques, le très connu Home Assistant en faisant partie.

Deux choses me déplaisent avec zwave-js:
-Intégration en plugin, comme avec python et tout ce qui est interprété donc sans besoin de (cross-)compilation native: A la clef des emmerdes récurrentes aux changements de version de l’interpréteur, des déstabilisations peu reproductibles (et debuggables) du soft domotique qui fera tourner cela…
-Le JS: Clairement, ce langage n’a pas du tout été fait pour contrôler du matériel mais pour du web dynamique côté client (pendant de php côté serveur). Ca permet peut-être de faire un truc qui marche plus rapidement dans un écosystème ou les développeurs web sont plus nombreux que ceux typés OS/plateforme, mais dans le temps cela va être un foutoir à maintenir et sans doute pas sans effet sur les performances.

Surtout que z-wave est parfaitement standardisé/stable niveau protocole: Aucun besoin d’y toucher sans arrêt, contrairement à un zigbee bardé de spécificités OEM et ou des langages interprétés peuvent alors combler par leur souplesse les défauts inhérents à leur fonctionnement.

Je pense qu’il faut que silabs prenne le taureau par les cornes, sinon le z-wave est mort pour tout ce qui est DIY (les box spécialisées s’appuyant sur les SDK du constructeurs des puces z-wave seront incontournables, mais c’est pas la même clientèle!).