Passer sur un truc type nuc (ou équivalent a 200€) ca changera tout et tu devrais avoir beaucoup moins de soucis de stabilité c’est sur.
Après regarde aussi les autres solutions pour l’avoir fait récemment c’est pas mieux ailleurs malheureusement :
HA : très bien, dashboard sympa, interface réactive. Sur les automatisations et historique c’est un cran en dessous de jeedom je trouve par contre (mais c’est subjectif). Niveau stabilité pas vu de différence (c’est de toute façon le même moteur zigbee, zwave). Niveau intégration il y en a plus et ca marche la plupart du temps mais pas toujours (exemple de enphase avec le passage en v7 ou chez eux ils ont mis 3 mois pour le gérer, chez jeedom dans la semaine qui a suivi le passage en stable de la v7 chez enphase c’était bon)
Google home : c’est trop cloud j’ai pas du tout aimé
Alexa : pas testé mais c’est cloud aussi
Homekit : c’est pas si mal en vrai, c’est ultra réactif (quand ca marche) la dessus Jeedom ou HA peuvent pas rivaliser, l’interface est vraiment bien je trouve (limité mais bien pensé) par contre ya du bugs… Le pont hue en matter ya un soucis quand ya trop de notification (je suis avec leur technicien dev depuis plusieurs semaine sur ce soucis), suite a une maj des fois des trucs qui marchent plus (changer la température d’une vanne si une lumière s’allume). Et niveau automatisation c’est assez vite limité. Néanmoins je m’en sers comme interface principal et j’ai quelques scénarios dessus (les plus critiques vu que je dev sur mon jeedom de production).
Globalement tout ca pour dire que l’herbe est pas plus verte ailleurs et ca montre bien que le faite qu’il y ait autant d’acteurs pour piloter une simple lampe même si il y a des standards ben ca coince quand même. Pas de solution miracle si ce n’est faire au plus simple, j’ai remarqué avec le temps que j’avais enormement de scénario très complexe pour géré des trucs ou finalement soit je pouvais simplifier le scénario soit j’en avais tout simplement pas besoin. J’essaye maintenant de plus en plus de faire des interconnexion entre les systèmes mais a faire en sorte que les composants de ces systèmes discutent directement entre eux sans passer par une intelligence centralisée. Truc con par exemple avant je détecté les mouvements sur les cameras pour allumer les lumières a l’avant si besoin, j’ai simplifié pendant les soldes en achetant un détecteur hue, mis des lampes hue et maintenant c’est hue qui gère. La même si Jeedom ou autre chose tombe ca ca marchera toujours. Et j’essaye d’appliquer ce principe de partout maintenant.
Bonjour ,
Ce n’est pas Jeedom le problème , ( ou avec HA ou autre système domotique )
oubli le RPI ,c’est bien , performant , mais vite en limite lorsque tu veux exploiter pleinement Jeedom .
J’ai un mini PC core I5 , 16 G ram . et si je continu à vouloir tous domotiser j’ai passerai au level au dessus .
(je garde aussi au maximum les commandes filaires en parrallèle du système : volet , inter … au cas où…)
Bonjour,
Je suis passé sur RPi après avoir testé au départ sur PC, et honnêtement, je ne m’en plains pas.
Ceci dit, outre l’aspect stabilité qui est très important (et une base Linux est parfait pour cela), il y a aussi un autre paramètre qu’il faut prendre en compte : c’est la consommation électrique.
En effet, un système domotique doit tourner H24, 7/7, tout comme un NAS d’ailleurs. Or un RPi4B avec 1 clé USB et 1 ventilo, considérant une charge à 75% (qui est une moyenne plutôt haute…) et qui tourne 24/7, c’est à peu près 6 à 10W en instantané, soit ~50kWh/an.
Mais un PC avec un i5, outre le volume qu’il occupe même au format mITX, c’est au minimum 50 à 60W (et sans doute plus s’il n’est pas optimisé pour) soit ~450kWh/an. Ce qui fait tout de même pas loin de 400kWh de différence ! Sauf à avoir des panneaux solaires et vu l’augmentation des tarifs actuels, je vous laisse calculer le coût annuel d’un tel confort…
Oui, tout à fait… Je parle bien d’un PC ‹ standard › de récupération par exemple, détourné de son usage normal pour en faire un PC dédié à la domotique…
Il y a un sujet qui en parle d’ailleurs : Comparatif de consommation (box, nas, nuc, diy, ...)
25W + solaire =
Ma remarque n’est évidemment pas dirigé contre quiconque, c’est juste pour souligner que faire de la récup, qui peut sembler être une bonne idée à la base, peut parfois s’avérer être un mauvais calcul à long terme…
Pas de soucis ,
J’ai commencé avec un RPI 3 , 2 lampes , 3 prises et puis la fièvre Jeedom à pris le dessus
Maintenant , une centaine d’équipement en tous genres , et une multitude de scénario et autre .
Donc forcément un upgrade du hardware .
J’ai mis HA sur le RPI 3 pour test de fonction ou APP
Perso je ne pense pas que le RPI soit coupable ; chez moi avec un RPI4, clé mémoire EMMC et une alimentation de qualité c’est fiable.
Maintenant pour en revenir à la question de base il n’ y pas 36 solutions:
jeedom permet une grande versatilité en interconnectant/intégrant plein de systèmes et de protocoles variés ; c’est sa force et c’est passionnant
mais tu restes à la merci des incompatibilités suite aux évolutions non coordonnées de ces différents écosystèmes ; jeedom etant à la croisée de tout cela
Si tu veux de la fiabilité au max, tu choisis un système propriétaire tout intégré, tu n’achètes que des éléments homogués par la marque, et tu fais une croix sur l’évolutivité.
Sinon, la démarche expliquée par @Loic est je pense la bonne:
tu choisis des sous-systèmes qui peuvent fournir seuls des fonctionnalités de base
tu utilises jeedom pour ajouter une couche supérieure apportant plus d’intelligence, mais tu fais attention à ce que les fonctions de base n’aient pas besoin de cela.
exemple: moi j’évite de toucher trop souvent à mon sous-système zigbee : je fais pas mises à jour de firmware de la clé, de zigbee2mqtt ou de jeezigbee, ni j’ajoute pas des devices et j’ai utilisé au max le binding direct entre mes télécommandes et mes actionneurs
pareil j’ai des capteurs mysensors faits main, beaucoup communiquent directement entre eux sans besoin de scénario.
Maintenant, il faut bien se rendre compte que la domotique est en perpétuelle évolution et donc instable.
J’avais fais un petit post y’a pas longtemps sur ma vision de l’utilisation de Jeedom qui partage le point de vue de certain post au-dessus :
"Personnellement je ne voulais pas devoir intervenir toute les 30 secondes sur Jeedom pour régler des problèmes, je voulais quelque chose de simple et efficace. Mais surtout je voulais une solution de secours en cas de défaillance de Jeedom (software ou hardware). Du coup j’ai fait le choix d’abandonner les solutions type Zigbee via Conbee II qui se mettent en place en dehors des passerelles constructeurs.
J’essaye systématiquement de faire des intégration à Jeedom sans couper la solution constructeur et en utilisant leurs box. Certains vont crier au sacrilège mais je n’ai pas trouvé de meilleure solution pour garder une domotique pérenne dans le temps. Cette manière de procéder permet de garder l’accès aux APP et CLOUD constructeur. Et de se raccorder aux assistants vocaux sans passer par Jeedom.
Ainsi même en cas de panne totale ou partielle de Jeedom, ma domotique reste fonctionnelle et contrôlable à minima, avec évidemment une perte d’interconnexion et d’automatisme. Cette solution demande des sacrifices sur les appareils choisis pour éviter de multiplier les box et une réflexion plus importante au moment du choix des appareils connectés, mais est de mon point de vue plus souple à l’usage. J’essaye donc de choisir des appareils qui peuvent être connectés localement à Jeedom, tout en ayant un accès Cloud.
Pour donner des exemples, j’utilise beaucoup AQARA en Zigbee, pour des capteurs, des prises, des interrupteurs, des boutons, etc… Pour mes volets roulants c’est du BUBENDORFF connecté en local à Jeedom et à l’app Legrand. Idem pour mes caméras REOLINK. Etc… J’utilise aussi le très bon plugin WifilightV2 pour les appareils Tuya, Smartlife et autres qui fonctionnent sans box directement en Wifi.
Jeedom est donc pour moi un grand CONCENTRATEUR dont le rôle principal est de faire parler entre eux LOCALEMENT mes pareil connecté. Son second rôle est de gérer la présence. Et enfin il me sert à afficher un design sur une tablette murale dans mon salon. Une bonne partie des automatismes est aussi gérée par Jeedom, via la présence, l’heure, la luminosité, etc… Sauf quand je peux le faire localement dans une app constructeur. Je contrôle aussi beaucoup mes appareils à la voix avec Alexa via le Cloud ou Matter."
Pour ton cas particulier, je te conseille aussi de passer sur un hardware plus solide.
Je vous remercie pour vos différentes retours, il y a beaucoup de bon sens et d’informations à retenir tel que privilégier un support hardware de meilleure facture, de simplifier au mieux les construction de scénario et l’association des solutions constructeurs dans Jeedom (dans mon cas je pense aux applis hyper fonctionnelles Netatmo et Eufy par exemple). Je suis également en phase sur le fait que l’herbe n’est pas forcément plus verte ailleurs. Je vais prendre le temps de réfléchir à tout cela. Je vais aussi jeter un œil aux solutions hardware envisageables.
N’hésitez pas à compléter ces échanges au besoin.
J’ai 2 jeedom qui tourne en DIY
Une sur un RPI4-8Go et l’autre sur une VM hebergée sous Unraid qui tourne sur un J5040.
J’ai aucun problème de stabilité.
Par contre je n’utilise aucun protocole domotique, je fais tout en http puisque de base c’est sur ça que repose jeedom (c’est un serveur apache… donc un serveur web) ; même le MQTT me donne des boutons (il n’a pour moi AUCUN intérêt dans un système domotique centralisé comme Jeedom, de base il n’a pas été conçu pour ça)
Je vais rester plus basique que mes confrères : le RPI a son système d’exploitation debian et Jeedom sur une carte SD, Les écritures continues des historiques, log etc… fatigue la carte SD. Je changerais déja la carte SD, prendre une marque « Fiable » genre Scandisk. Pour ma part j’ai un NUC I5 avec Proxmox , Jeedom est installé en VM. J’historise énormément de données, le voyant du SSD clignote en permanence ce qui montre une activité d’écriture importante.
Salut, concernant les modules zigbee ça m’est arrivé aussi et chez moi ça n’arrive quasi okus depuis que j’ai figé le canal du wifi de mon routeur. Parfois le routeur changeait de canal ce qui perturbait le zigbee
Un Raspberry Pi, qu’il soit 3B+ Zero 2W (oui, même celui-ci limité à 512 Mo) ou 4, est très fiable à partir du moment où on le fait fonctionner avec un SSD et du courant stable (pas d’alim chinoise apacher + onduleur si la qualité du courant livré ne vaut pas tripette).
Le Zigbee, en revanche, je suis désolé, mais ça ne vaut rien de bon. Certes, c’est pas cher et sur le papier c’est génial, mais dans la pratique c’est un nid à emmerdes. Depuis que j’ai viré tout le Zigbee pour le remplacer par du Zwave et du EnOcean, je n’ai plus de problèmes. Depuis que j’ai abandonné l’idée de violer les systèmes propriétaires pour ne me servir de Jeedom que comme un chef d’orchestre, je n’ai plus de problèmes.
Vire le Zigbee, ou, à tout le moins, ne l’utilise qu’à travers de l’interface propriétaire d’origine. Ce sera beaucoup plus stable. Mais vire ce protocole dès que l’occasion se présente, le faible prix d’achat se paye au centuple sur le temps de maintenance. J’ai une dizaine de Jeedom en prod et des centaines de capteurs. Le Zigbee m’a couté une fortune en temps de maintenance. Bien plus que l’économie effectuée sur le prix d’achat par rapport à un vrai protocole domotique stable.
D’ailleurs, tu le dis toi-même, tes problèmes viennent du Zigbee. Du constat à la solution, tu n’as plus qu’un pas à franchir.
C’est vrai qu’avec zigbee il y a du bon et du mauvais car il y a des devices qui ne respectent pas la norme:
utilisation de clusters propriétaires
routeurs qui ne routent pas tout le monde
binding direct entre devices qui ne marche pas toujours d’une marque à l’autre
et la qualité est très variable, mais les prix aussi…
d’ailleurs dans les grandes marques reconnues (genre lergand, philips, etc), les prix du zigbee se rapprochent du zwave
et il faut quand même dire que les prix des devices zwave refroidissent sévère, surtout pour un particulier qui a moins en vue le coût de la maintenance dans un contexte non professionnel
Là, tu jettes l’eau du bain, le bébé, la maman et toute la salle de bain !!!
Le zigbee est une norme PROFESSIONNELLE. Tu confonds le PB avec des modules zigbee chinois pas cher et la norme zigbee et des matériels de qualité !
Ce genre d’affirmation ne peut qu’induire ceux qui arriveraient sur ce genre de posts en erreur.
Tu conclus de généralités d’une expérience personnelle ==> biais de représentativité
Le zigbee est bien plus développé que le zwave, c’est peut être que ça fonctionne
Bonjour,
J’ai une installation avec une box Atlas et 95 objets en zigbee répartis sur plus de 400 m² en intérieur et extérieur.
Je suis particulièrement impressionné par la stabilité de Jeedom du moment qu’on la protège des coupures intempestives. Linux n’est pas fait pour redémarrer toutes les 5 minutes et souvent son pire ennemi est entre la chaise et le clavier !
Pour le réseau zigbee, encore avec l’ancien plugin, il faut juste comprendre que les modules doivent être appairés à l’endroit où ils doivent fonctionner et qu’il ne faut pas les déplacer. Lorsqu’on déplace un routeur, il faut par conséquent non seulement réappairer le routeur mais aussi les modules sur pile qui lui était liés. De même, il ne faut pas hésiter à changer les piles dès la première installation.
Je parle bien d’un PC ‹ standard › de récupération par exemple, détourné de son usage normal pour en faire un PC dédié à la domotique…
