J’envisage de plus en plus sérieusement de migrer mon installation domotique actuellement sur une box Veraplus (ezlo anciennement micasaverde) vers Jeedom.
Mais avant de commencer ce grand chambardement qui me fait un peu peur, je souhaiterais avoir quelques infos de base sur le fonctionnement de Jeedom.
Mes principales motivations sont:
1/ marre de payer une fortune chaque module zwave supplémentaire sans pouvoir utiliser de modules zigbee (alors que ma box est sensée pouvoir le faire !)
2/ être totalement dépendant du devenir commercial de la boite qui commercialise ma box. Et de son bon vouloir en général (firmware qui évolue une fois par décennie).
Mon utilisation personnelle de ma box actuelle était très très basique et très simple et me satisfaisais complètement.
Je codais tout de A à Z en lua/luup (le langage privilégié de l’api) et ne me servais de l’interface graphique que pour manipuler directement mes modules zwave et SURTOUT PAS pour programmer quoi que ce soit.
En l’occurrence, la box lançait un gros script en lua/luup à chaque démarrage dans lequel:
1/ je déclarais et initialisais des variables globales.
2/ décrivais toutes mes fonctions de rappel (callbacks)
3/ déclarais toutes les variables de modules à surveiller (déclencheurs) + quelques timers
Ce fonctionnement présentait pour moi deux énormes avantages:
1/ une programmation personnalisée à l’extrême
2/ une centralisation de tout mon code dans un minimum de fichiers de script.
Et basta !
Voici mes questions:
1/ est-il possible de retrouver un fonctionnement similaire sous jeedom (et surtout ne pas éparpiller des bouts de codes un peu partout via l’interface graphique)
2/ est-il possible de réutiliser mon code lua/luup autant que possible au moins dans un premier temps (je ne maîtrise pas ou plus ni python ni php). L’idéal serait de n’avoir qu’à traduire toutes les méthodes d’api qui vont bien. (donc très peu de choses en fin de compte)
3/ où regarder précisément dans la documentation en ligne de jeedom (définition de l’api en particulier) ?
J’avoue que pour le moment jeedom vu de l’extérieur ressemble pour moi à une grosse usine à gaz et c’est ça qui m’effraie. Et à première vue avec tous les défauts que j’ai toujours voulu fuir (éparpillement du code en particulier)
Un gros code monolith avec des variables globales c’est vraiment une gestion d’une autre décennie (voir deux ou …).
Séparer les fonctionnalités logiquement est la base pour pourvoir justement maintenir plus facilement et réutiliser.
Je pense que vous confondez « séparation des rôles et responsabilités de chaque fonctionnalité » qui doit donc être du code isolé offrant une interface claire et « éparpillement du code ».
Non vous ne pourrez pas faire cela.
vous pourrez certainement exécuter du code lua mais à vous d’installer l’interpréteur qui va bien (il doit pouvoir s’installer sur une debian) et ensuite d’utiliser le plugin script.
commencez par les premières page de doc, les concepts etc. Mais vous allez devoir changer radicalement de point de vue.
Merci pour ta réponse mais tu n’as pas compris ma demande. Je n’ai jamais dit qie mon code était monolithique ni procédural. Mon code est orienté objet et événementiel.
Tu es en train de demander à un développeur de métier d’arrêter de penser comme un développeur ?!
Je vais formuler les choses autrement: je voudrais savoir où est la doc qui décrit l’API de Jeedom, peu importe le langage pour le moment (php, python ou autre), je n’arrive pas à mettre la main dessus.
OK merci. C’est très succinct, aucun exemple, aucune explication mais bon.
A la limite, je n’aurais besoin que d’une seule chose:
Comment fait-on pour dire à Jeedom qu’à chaque fois que tel module (par exemple un actionneur zwave on/off) change d’état, je veux qu’il exécute telle commande système. (Pour le reste, il a l’air possible d’interagir par des requêtes http, donc ça peut aller.)
Est-ce que ça doit se faire manuellement en utilisant l’interface de Jeedom (ce que je ne veux pas faire) ou est-ce qu’il est possible de mettre tout ça dans un script et de le faire exécuter quand jeedom démarre ?
Dans un premier temps, j’aurais juste besoin de ça même si c’est pas optimal.
La réponse sur le « comment » est dans la doc et pour le reste j’ai déjà répondu:
Vous ne pourrez pas reproduire votre solution actuelle telle quelle sur jeedom, ce n’est pas comme cela que ca fonctionne.
Oui il sera possible d’exécuter un script au démarrage mais votre script n’aura pas la charge de surveiller vos capteurs et autres infos et faire des actions en conséquences, c’est un non-sens complet, c’est le core (jeedom) qui s’occupe de ca.
J’ai un doute sur le fait que vous ayez lu les concepts de bases sinon vous ne poseriez pas cette question je pense.
Ca me parait étonnant et très décevant si c’est vraiment le cas que Jeedom n’offre aucune possibilité de faire ça. (j’aurais l’impression de passer de Linux à Windows pour donner une image)
Salut
J’ai moi aussi une VeraPlus (et Vera3 juste avant), Jeedom n’est pas du tout pensé comme Vera.
Ce que je peux conseiller c’est de l’installer et voir comment il fonctionne a travers les Doc et les posts sur le forum.
Il peut effectivement envoyer des requêtes http, utiliser des script, etc… Mais pas de la même manière que le startluup de la Vera. Essayez le, c’est une autre vision que Vera et Ezlo
Je pense qu’il doit être alors possible d’utiliser jeedom pour tous les modules (en particulier zigbee) que veraplus ne prend pas en charge.
Et interagir depuis Jeedom avec autant de modules virtuels sous Vera à coup de requêtes http.
C’est loin d’être idéal mais ça pourrait le faire.
Oui Jeedom prends en charge le zigbee, il faudra, une fois de plus, rechercher dans les posts et les docs pour faire un choix sur l’antenne et le plugin a utiliser.
Avis perso : je reste sur le matériel et plugin officiel pour ne pas être embêté et surtout pas perdre plus de temps. Voir le blog Domadoo il y a plein de tests de matériel qui permettront de voir les compatibilités et en fonction du plugin choisi la prise en charge de certains matériels.
Il existe aussi un plugin sur le market Jeedom qui sert a récupérer les info d’une Vera lite vers Jeedom, de mémoire, si je ne dis pas de bêtises.
Pour te donner un exemple de la façon dont les éclairages de mes pièces fonctionnent, (relativement quand on est développeur) facile à implémenter sous Vera mais très difficile voire impossible à implémenter sous Jeedom au vu de ce que j’ai pu comprendre de son fonctionnement.
Dans mon salon, je pilote toutes les lampes en même temps via un device virtuel (jusque là j’ai vu qu’il existe un plugin Jeedom pour faire ça) mais:
1/ pour un niveau de gradation global donné, chaque lampe ne varie pas de la même façon: exemple: A 50% global, certaines lampes variables seront allumées à 50%, d’autres à 30%, d’autres à 80%.
2/ j’utilise plusieurs règles de gradation: par exemple, une règle « cinéma », une autre « normale », une autre « repas » etc.
3/ les règles incorporent également des configurations différentes qu’il est possible de modifier: certaines restent éteintes si elles étaient déjà éteintes mais suivent la règle si elles étaient déjà allumées, d’autres suivent la règle en vigueur mais ont plusieurs modes par exemple (maximum, normal, minimum); très pratique pour prendre une note au téléphone ponctuellement.
Dans ma cuisine adjacente au salon:
La règle de gradation suit celle du salon. Mais seulement, si aucune lumière n’était déjà allumée. Auquel cas, la cuisine conserve sa règle de gradation précédente.
L’idée est que je ne veux pas sortir du salon avec les yeux habitués à une semi-obscurité et me retrouver ébloui en entrant dans la cuisine pour chercher quelque-chose. Mais si quelqu’un était en train de manger à table dans la cuisine, il est idiot de faire passer la cuisine en mode « cinéma » parce que le salon est passé en mode « cinéma ».
Par ailleurs, touts les ampoules variables varient progressivement. Il est hors de question de passer brusquement de 10% à 100% Ca se fait en plusieurs étapes.
Bref, je vois mal comment tu peux implémenter ce type de fonctionnement sous Jeedom avec ce cahier des charges. Ou si c’est possible, ça doit être une sérieuse prise de tête. Et par ailleurs impossible à faire évoluer et à maintenir (bouts de pseudo-codes éparpillés partout dans l’IHM). Une horreur !
Voilà. Cela dit Jeedom a l’air très sympa, du moins tant que tu restes dans des fonctionnements basiques.
Je me trompe ?
je crois que tu ne comprends pas la manière dont fonctionne jeedom, tout ça on peut le faire les doigts dans le nez, plein des mécaniques que tu décris font partir du core et sont implémentées par défaut … après il existe des éléments virtuels que tu peux faire fonctionner comme tu le veux et compléter l’ensemble par un déclenchement de script php (code php + macro-commandes interprétées) qui t’évitent u boulot de développeur totalement inutile et te permettent de te concentrer sur le fonctionnement de l’ensemble. en complément si besoin de piloter des éléments externes, tu peux appeler des scripts externes http et .sh.
je pilote ma gradation via un scénario avec une temporisation comme toi. 5 lignes de codes et c’est tout, c’est déclenché quand la demande d’allumage est générée via les interfaces ou les interrupteurs physiques. tu peux créer X modes et allumer ce que tu veux comme tu veux. Après si ça te conviens pas, tu peux aussi coder tout en php et déclencher ça sans t’occuper de la pile de protocole, zigbee, zwave, etc… tout est géré par le core.
installe le truc et teste un peu pour voir, ça évitera des critiques mal placées sur c’est possible / pas possible. il faudra penser ta domotique de manière différente, c’est tout et c’est normal d’un produit à l’autre.
Effectivement, je n’ai pas encore testé. Ce que tu dis est plutôt rassurant. J’aimerais bien pouvoir à terme me passer de la Vera et tout migrer sous Jeedom mais sans sacrifier mon cahier des charges.
Par contre la doc de l’api PHP ne fournit que les interfaces des méthodes mais n’explique rien de ce qu’elles font. Il n’y a rien de plus détaillé de son fonctionnement ?
non c’est le souci avec ce produit, c’est très orienté pour les end users… après il faut par exemple, charger des plugins et regarder le code. J’ai appris comme ça, et depuis j’ai adopté car en quelques minutes on arrive à ses fins pour des actions orientées domotique. Tu verras aussi notamment la mécanique de démon (cron) et du plugins qui permettent d’étendre les fonctions spécifiques. ça peut permettre dans un premier temps de faire une passerelle entre ton ancien et nouveau système.
