Jeedom avis sur le plugin

[domotiqa]

Petit oubli il faut faire

export LD_LIBRARY_PATH="/usr/local/lib"
sudo ldconfig

[Mika-nt28]

Ok je l'ajoute dans le script

[domotiqa]

salut et encore félicitation pour le taf réalisé.

Pour mes retours:
- j'ai parfois (rare) des petits de soucis de retour d'état non pris en compte. par exemple, j'allume une lampe et elle ne s'allume pas ou alors l'état n'est pas mis a jour. Du coup on se retrouve avec une lampe que l'on ne peut plus allumer ou eteindre car c'est toujours le même ordre qui est envoyé, il n'y a plus de toggle. Cela pourrai être par exemple judicieux de faire qu'un appui long renvoi un 0 par exemple. Plusieurs fois il a fallut aller au bouton physique pour renvoyer le bon ordre et après Jeedom était de nouveau synchronisé.

Cela reste assez rare quand même.

Au niveau du principe de Jeedom, quelques notions n'était pas expliqué et j'avoue avoir passé du temps et des tests pour comprendre.

Par exemple comme le fait que l'on défini d'abord les actionneurs knx avec comme adresse la vraie adresse physique de l'actionneur. Et on ajoute a celui ci tous les retours d'états uniquement.

Dans un deuxième temps on crée des objets qui doivent représenter des pièces. On crée par exemple une pièce armoire elec pour mettre les actionneurs et qui sera cachée. Après on crée par exemple un objet bureau avec un nouvel équipements qui sera cette fois l'action sur nos lampes/volets... Et en gros on par du principe que l'on copie un interrupteur existant on lui donne la même adresse knx réelle et on définit les bouton. Dans la case état on prend les états définis dans l'actionneur précedemment crée.

Cela nous permettra de créer une structure par pièce...
C'est pas mal mais je préfére l'affichage vue. Ce dernier nous permet de créer une vue avec les périphérique qui nous interresse ou que l'on utilise le plus.
Lors de la création de vue on peut groupper les équipements choisit ce qui est pratique. Les couleurs dépendront du type d'équipement (automatisme,multimédia...). Ces couleurs sont paramétrables dans la section affichage et dans le profil. On peut donc facilement dire que lors du lancement de l'appli Ipad, on tompe direct sur la vue. Cela permet d acceder rapidement au lancement de l'application aux équipements voulu et c'est super bien foutu, simple mais efficace.

Il y a aussi le plugin widget et script a installer directement. Le widget permet d'avoir un affichage de lampe avec un retour d'état graphique. On appui sur la lampe et l'image change pour une ampoule allumée.

Perso, je suis embalé par le projet Jeedom, qui, a mon sens est loin devant Openremote, Knxweb...
Ce côté ouvert vers l'internet des objets, Sarah, le Hub harmony, google agenda... la facilité de modif de création... le côté plugin ouvert et sharable permet de faire plein de choses rapidement. Et cerise sur le gateau le mode design permet de créer des visu personnalisées (juste a adapter en fonction du device cible)

Pour les habitués cela parait simple, mais lors du démarrage cela fait perdre un temps précieux pour certains comme moi.

En un mot bravo pour tout le taf réalisé. Jeedom a remplacer Openremote, Lmachine, homelynk and co. Manque a mon sens encore un bon plugin DLNA/UPNP.

[Mika-nt28]

Merci pour ton retour,

Pour ce qui concerne l'apprentissage du plugin, il serait certainement intéressante d'integerer un, ou plus d'info.
Mais comme tu l'as dit quand on connais les choses cela parait tellement simple que l'on n'y pense pas forcement

[Atounmotique]

Bonjour Mika-nt28

J'annule mon message, je viens de trouver sur le forum de Jeedom, tes échanges et préconisation que je vais suivre.

Merci
Bonne journée

[vf62]

Bonjour,

Après avoir compris à peu près le principe de créer les commandes de type "info" sur les actionneurs et ensuite créer les commandes de type "action" sur les interrupteurs, j'arrive à commander les points lumineux (merci domotiqa et le wiki )

J'ai tenté l'import ETS qui a rapidement planté sur un nom en double mais au final, je préfère refaire from scratch car je n'ai pas forcement besoin dans le superviseur de toutes les configs existantes dans ETS.

Un point que je ne comprends pas est pourquoi est il nécessaire de renseigner les adresses physiques des équipements ?
En fait, plus globalement, je ne vois pas pourquoi dans un superviseur, on est obligé de se rattacher à des éléments physiques ?
Cela n'est pas nécessaire dans linknx où seules les adresses de groupe sont utilisée.

Je suis peut être trop formaté linknx ou j'ai du loupé un truc dans le mode de fonctionnement de jeedom mais j'aimais bien cette souplesse de ne pas forcement reproduire l'infra physique dans le superviseur.
Car du coup, il y a des chose que je n'arrive pas à faire:

• Comment créer une commande pour allumer la lumière des WC alors que physiquement, je n'ai pas d’interrupteur ?
  
• Dans la même idée, comment créer un équipement "virtuel", qui n'existe pas physiquement ?
  
• Toujours dans le même ordre d'idée, comment créer séparément un équipement de commande des volets roulants et un autre de commande de point lumineux alors que physiquement, je le fais depuis un même interrupteur à plusieurs boutons
  
• Et enfin, comment, avec cette adhérence à l’adresse physique, gérer le fait que plusieurs boutons physiques commandent le même point lumineux ? Car si on "écoute" uniquement les GA sur le bus comme linknx, alors pas de problème, s'il existe un listener, on le met à jour.
  Dans le plugin, en lançant le bus monitor, il voit passer des commandes d'allumage d'un point lumineux émis par un équipement non déclaré dans jeedom et affiche du coup "aucune commande trouvée" alors que j'ai un autre équipement sur lequel j'ai associé cette commande et son retour d'état.
  

Si quelqu'un peut m'éclairer ?

Vincent

[domotiqa]

Un point que je ne comprends pas est pourquoi est il nécessaire de renseigner les adresses physiques des équipements ?
**c est un principe de fonctionnement, l'idée, je penses, est que lors de l'apprentissage des GA, on va vers un interrupteurs, on appui sur les touches, et du coupsur la supervision on a la même chose... je suis pas fan non plus

En fait, plus globalement, je ne vois pas pourquoi dans un superviseur, on est obligé de se rattacher à des éléments physiques ?
Cela n'est pas nécessaire dans linknx où seules les adresses de groupe sont utilisée.
**je dirai même que c'est assez deroutant, une fois que l on utilise le module design libre, ou la le principe d'equipement ne fonctionne plus pour avoir qq chose adapté a chacun.


[*]Comment créer une commande pour allumer la lumière des WC alors que physiquement, je n'ai pas d’interrupteur ?
**tu cre un faut equipement avec une adresse bidon, ou tu le met dans l equipement actionneur avec les retour d'etat

[*]Dans la même idée, comment créer un équipement "virtuel", qui n'existe pas physiquement ?
**faut installe le module optionel de programation (u aur script et virtuel en plugin) depuis le market

[*]Toujours dans le même ordre d'idée, comment créer séparément un équipement de commande des volets roulants et un autre de commande de point lumineux alors que physiquement, je le fais depuis un même interrupteur à plusieurs boutons
**tu feinte avec des boutons et de adresses virtuelles, ou tu utilise le plugin virtuel

[*]Et enfin, comment, avec cette adhérence à l’adresse physique, gérer le fait que plusieurs boutons physiques commandent le même point lumineux ? Car si on "écoute" uniquement les GA sur le bus comme linknx, alors pas de problème, s'il existe un listener, on le met à jour.
Dans le plugin, en lançant le bus monitor, il voit passer des commandes d'allumage d'un point lumineux émis par un équipement non déclaré dans jeedom et affiche du coup "aucune commande trouvée" alors que j'ai un autre équipement sur lequel j'ai associé cette commande et son retour d'état.
**perso je me suis pas interressé a ce point
[/list]

Si quelqu'un peut m'éclairer ?

Vincent

ci dessus mes reponses

[Mika-nt28]

Pourquoi est il nécessaire de renseigner les adresses physiques des équipements ?

Car le bus monitor me renvoi les informations Adresse physique et GA.
Pour gagner du temps et de l'efficacité il est plus rapide de chercher l’équipement en question puis son GA.
Sinon il est nécessaire de cree une boucle qui va parcourir tous les équipements configurer et toutes les GA. ce qui peut etre long dans de grosse installation.
Ce rattachement est donc utile uniquement pour les info. toute commande emise par jeedom peut être mis comme on le souhaite.
Attention cependant, je travail actuellement sur une interface KNXnet qui aura besoin d'une adresse physique pour formé ca trame.

Comment créer une commande pour allumer la lumière des WC alors que physiquement, je n'ai pas d’interrupteur ?

Comme expliqué au dessus aucune importance pour les actions.

Perso je met mes commandes dans le même équipements que l'info.
Cela permet de retrouvé facilement la commande et organise les widgets sur le dash d'une maniere logique

Dans la même idée, comment créer un équipement "virtuel", qui n'existe pas physiquement ?
Si ce que tu souhaite faire c'est une passerelle entre 2 Protocol, tu crée une équipement bidon (attention de ne pas utilisé une adresse physique ou des GA qui existe deja) et tu fait une pont avec un scénario

Toujours dans le même ordre d'idée, comment créer séparément un équipement de commande des volets roulants et un autre de commande de point lumineux alors que physiquement, je le fais depuis un même interrupteur à plusieurs boutons
Tu peux crée plusieurs équipement qui porte la même adresse physique.
Cela va cree génére une petite boucle, mais attention a ne pas avoir les meme GA dans chaque equipement

Et enfin, comment, avec cette adhérence à l’adresse physique, gérer le fait que plusieurs boutons physiques commandent le même point lumineux ? Car si on "écoute" uniquement les GA sur le bus comme linknx, alors pas de problème, s'il existe un listener, on le met à jour.

L'ideal est de surveiller ton actionneur et pas les interrupteurs.
Perso j'utilise les info des interrupteur uniquement pour des scenario et les retours d'etat des actionneur pour les info des jeedom


Tes questions me semble interresante et pas forcément bien compris par tous.
Je me permet de les ajouté dans la FAQ de la doc

[fredblabla]

Bonjour,

Je vais bientôt installer sur un raspberry pi 2. Ca remplacera surement mon module ephemeride que j'avais fait en java

[Paqueuc]

Attention cependant, je travail actuellement sur une interface KNXnet qui aura besoin d'une adresse physique pour formé ca trame.

@Mika-nt28

Bonjour,

Léger déterrage de post pour savoir si tu as avancé sur cette interface KNXnet, STP ?

Je vais donner sa chance à cette visu prochainement et aimerais partir sur quelque chose de propre. Vu que je n'ai pas (encore) EIBD, l'interface KNXnet me conviendrait bien... Mais est-ce au programme bientôt ou vaut-il mieux capitaliser sur une install EIBD ?

Merci pour ta réponse,

Paqueuc

[Ziki]

Je remonte aussi ce sujet pour savoir si quelqu'un a une idée sur le meilleur moyen d'implémenter un thermostat "classique" dans Jeedom. Donc, avec affichage de la température, gestion de la consigne et du mode?

Cyrille

[Mika-nt28]

Je remonte aussi ce sujet pour savoir si quelqu'un a une idée sur le meilleur moyen d'implémenter un thermostat "classique" dans Jeedom. Donc, avec affichage de la température, gestion de la consigne et du mode?

Cyrille

Je ne comprend pas trop ce que tu veux.
Perso, mes thermostat sous jeedom gere tous ca

[vf62]

Bonjour Mika,

De mon côté, mon principal frein pour essayer jeedom est de devoir redéclarer tous mes devices / GA, etc ...
Y'a t'il un moyen d'éditer les objets sans passer par l'interface graphique ?
par exemple, pour linknx, j'édites directement le fichier xml de config ce qui permet de faire du copier/coller facilement.
merci,

Vincent

[maisonkydie]

Y'a-t-il des personnes qui essai Jeedom ?

[fredblabla]

Bonjour

J'utilise Jeedom en complément. La V2 à l'air d'être plus stable que la V1. Je l'utilise uniquement en complément. L'avantage est qu'il y a plein de modules gratuit ou pas du tout cher.
Du coup je n'ai pas tout redéfini dans Jeedom mais seulement les GA utilisés dans Jeedom, et puis parfois j'en ajoute un pour le plaisir

a+
Fred

[kamigaz]

J'ai gentiment essayé la dernière v1, j'attends que la v2 se stabilise avant d'essayer.
En ce moment je joue avec ma Loxone.

[Joffrey]

J'essaie Jeedom aussi. Il y a quelques défauts de jeunesse, mais Mika, notamment sur son plugin KNX, est super réactif pour les corriger
Bravo à lui pour son implication.
Mon avis perso est que Jeedom sera chez moi un très bon second/troisième superviseur, uniquement d'arrière plan, pour gérer des scénarios ou des cas de figures un peu tordus mais non essenciels (interactions avec ma Welcome, avec les sons et sqeezebox, arrêt/réveil de mes PC sueprviseurs, etc).

[maisonkydie]

Ok, hier j'ai essayé d'installer une version de tester avec VMware hier, et j'ai donc téléchargé l'image Jeedom sur leur site dédié à VMware, mais impossible de le faire marcher en 32 ou 64 bits.

Sinon, j'entends aussi parler de Domoticz que j'ai pu installer sur mon Nas Synology. Le pb est que le plugin KNX s'installe avec FHEM (non compatible avec ma version de Nas), et là ça sent encore la bidouille !

Est ce que vous avez essayer la solution Gira x1 ?

[fredblabla]

Je conseille Jeedom sur un Raspberry pi 2. comme le dit joffrey pour le moment c'est bien pour un deuxième superviseur