jeedom a un gros avantage: il a fait partie des pionniers dans le petit monde des soft domotique ouvert et multi-protocole. et il a su fédérer une communauté qui l’a enrichi au point d’être sans doute un (ou le ?) soft qui supporte le plus de protocoles.

Mais le revers de la médaille c’est qu’il traine une stack technique très datée et totalement déphasée avec le besoin initial.
Un serveur domotique c’est un démon qui doit communiquer avec d’autres entités, réagir à des événements et en initier lui même (scénarios, …). Et accessoirement, proposer une GUI pour les interactions avec l’utilisateur.m, entre autre.

Or jeedom a d’abord été pensé en tant que GUI avec une stack techno en rapport: Apache, php, mysql. Un truc dont le concept de base est de répondre à une requête faite par un utilisateur depuis son browser. D’où les contorsions inextricables pour faire rentrer les autres besoins au chausse pied dans cette stack pas faite pour. Genre:

• Un plugin jeedom zwave, c’est un démon python qui va appeler des pages php à chaque fois qu’un événement se produit, et se fera appeler en retour par le php pour initier des actions.





• Un scénario qui doit se déclencher à intervalles réguliers, c’est une tâche cron qui va appeler une page php pour initier une action. etc…

Le problème, c’est que comme la plus grosse force de jeedom c’est la somme des plugins et contributions passées, c’est pas demain la veille que jeedom pourra initier un big bang pour changer pour une stack adaptée. Et en attendant il va continuer à accumuler les pansements sur les jambes de bois avec une efficience de plus en plus douteuse.

Perso, si je dois conseiller un soft de domotique saupoudré d’open source et d’un poil de diy, je proposerai sans doute jeedom pour son écosystème. Mais à titre personnel, j’ai fini par le dégager et me coder mon propre soft aux petits oignons.

fofo9012 a dit:

Je ne vois pas où est le pb d’appeler du PHP en ligne de commande, c’est parfaitement fonctionnel et plutôt adapté.

Exemple simple: j’ai un jeedom (soit un site Apache/Mysql/PHP + un plugin zwave (un démon tiers en Python, donc). Je suis l’utilisateur j’ai ouvert mon browser sur une page de jeedom qui me montre l’état des lampes de ma maison. Je ne fais aucune action dans le browser.

Tout à coup, quelqu’un appuie sur un interrupteur, une lampe s’allume ; la page web doit me refléter ce changement d’état et m’afficher le status de la lampe allumée.

Question: comment fait jeedom pour faire ça ; quel est le temps de réponse ; quelle a été la charge induite inutile sur le serveur ?

Réponse: Le démon zwave en pyhton va appeler un script PHP, qui va traiter l’event et le stocker quelque part. Puis le script se termine.
Un peu plus tard, la page web côté browser qui fait du polling avec une requête toutes les 2 ou 3 secondes va appeler la page (core/event.ajax.php) qui recharge complètement le contexte, ré-applique l’authentification de l’utilisateur, etc… etc… Il va ensuite rechercher s’il s’est passé quelque chose depuis ma dernière demande et me renvoie une liste d’évents des changements intervenus dans l’intervalle.

Et si, pas de bol, l’event est arrivé quelques ms après ma dernière reqûete ; je vais attendre 1 ou 2 secondes / la prochaine requête de polling avant d’être informé.

Question efficience et charge serveur, 99 fois sur 100 on aura réveillé le serveur (refait l’auth du user, rechargé le contexte etc… etc…) tout ça pour répondre “nan, y’a rien de nouveau qui s’est passé”.

Niveau 1) latence et 2) efficience, on est au niveau zéro.

A contrario, un petit démon (style nodejs, dans mon cas, ou autre) va tourner en permanence ; je garde tout le contexte en mémoire, pas besoin de le reconstruire à chaque requête toutes les 2 secondes, (ré-authentifier le user, etc…) j’ai une connexion websocket avec le browser ; quand j’ai à le notifier d’un event, on fait du push, le client le reçoit dans la milliseconde qui suit. Et quand il ne se passe rien, la charge serveur est de zéro.

fofo9012 a dit:

Apache est de fait un démon, que le code soit en PHP, Python ou js.node, n’est pas plus inadapté qu’un démon bash habituel.

Que le code soit en PHP, Python ou nodejs, c’est juste un langage, on est d’accord.

Par contre, Apache est un démon qui a un fonctionnement pensé pour réagir quand on lui envoie une requête web, et ne peut pas se ‘réveiller’ de façon spontanée pour faire quelque chose tant qu’une tierce partie ne l’a pas trigger.

fofo9012 a dit:

la charge est côté browser javascript : https://developer.mozilla.org/en-US/docs/Web/API/notification

Tu me sors la notification API ? really ?

Ok, tu ne comprends pas plus de quoi je parle, ni même ce que toi-même tu quotes.

fofo9012 a dit:

Le fonctionnement est strictement identique

Ou pas. Mais tu ne sembles pas comprendre de quoi tu parles toi-même.

On va en rester là.

David_L a dit:

On se calme un peu. On peut être en désaccord sans être foncièrement désagréable

Ce n’est pas une question de désacoord, le bonhomme exprime un avis en agumentant totalement à côté de la plaque.

Parler de web-notif API quand on est dans le sujet de l’update en push/pull vie des websockets ou du polling en ajax, c’est pas un ‘désaccord’, c’est un non sens.

Si demain tu expliques dans un article que la RAM est un facteur important pour faire tourner plein de VMs sur une machine et qu’un gars arrive en te disant “super pas, tiens v’la un lien, ça passe sans stresser si la carte graphique elle a 4Go de RAM”., tu acquiesces ?

David_L a dit:

Désaccord ou non sens, ce n’est pas une raison pour monter dans les tours comme ça ;)

Si pour toi dire “vu ta réponse totalement décalée je préfère abréger plutôt que partir dans une discussion stérile” c’est “être désagréable” et “monter dans les tours”, pour moi on est dans le registre de l’hyper-sensibilité.