Automate programmable

[jeancoudert]

Bonjour à tous,
Je ne pense pas avoir beaucoup de réponses à ma question qui bien que simple serait probablement très complexe à mettre en œuvre. Je suis Ingénieur automaticien et possesseur d'une box eedomus et je me pose la question, depuis plusieurs mois de savoir si quelqu'un ayant un excellent niveau en PHP et une bonne connaissance de la BOX eedomus pourrait écrire un script PHP étant capable de venir interpréter cycliquement un fichier de commande Texte contenant un genre de programme d'automate programmable et ceci avec tous les actionneurs et capteurs les plus courants Zwave existants.
J'ai déjà écrit ce genre de choses il y a plusieurs années sur un microprocesseur en temps réel en C pour des entrées et sorties numériques d'un vrai automate.
L'idée serait dans un premier temps de ne s'occuper que des entrées numériques (0 ou 1) des capteurs les plus courants comme détecteur de présence, Incendie, Inondation, Ouverture de portes ,etc ... et des actionneurs également le plus courants (Alarme, Volets roulants, Pilotage de lumières, etc ...). L'idée principale et bien de venir lire le fichier de commande Texte du début à la fin et de recommencer en boucle. Si pour la lecture d'une variable d'entrée du premier cycle est relue avec une valeur différente au cycle suivant, on peut en déduire que l'on a eu un front montant ou descendant sur cette variable. Et voilà, le tour est joué car on peut faire des actions uniquement sur un changement de valeur pour réaliser des programmes dits séquentiels (Type Grafcet pour les initiés) ou des programmes combinatoires (pour lesquels la notion temporelle n'est pas utile comme des portes logiques OU/ET)
Je tiens à préciser que ce genre d'outil pourrait profiter à toute la communauté des utilisateurs de cette Box et faciliter CONSIDREABLEMNT la réalisation rapide de toutes les séquences automatiques dont on a besoin pour faire de la domotique avancée.
Voyons si quelqu'un a compris l'idée ? Je tiens à préciser que si une ou plusieurs personnes souhaitent se lancer dans la bataille, je peux écrire une spécification très précise du besoin. Pour la mise en œuvre, je ne maitrise pas le PHP (je bosse en WinDev/WebDev) et n'ai aucune connaissance des actionneurs et capteurs Zwave du commerce et la façon de les piloter ou d'interpréter leurs valeurs envoyées.
Merci de m'avoir lu et Salutations à tous.

[Arno]

Il est possible que je n'ai rien compris (tout à fait envisageable), en tout cas, je ne vois vraiment pas l'intérêt de la chose, encore moins ce que c'est sensé simplifier...

[jeancoudert]

Bonsoir Arno,
Je vois effectivement que vous n'avez rien compris. Et j'en suis désolé...
L'objective etant bien une fois cet outils développé, d'etre capable de programmer la Box Eedomus comme un automate programmable classique. C'est à dire beaucoup plus simplement que ce qui existe aujourd'hui en stanadrd dans la box qui n'est vraiment pas intuitif pour realiser des sequences automatiques séquenrtielles.
J'ai contacté diretement eedomus qui m'ont avoués etre entrain dde travailler pour réaliser un langage de progrrammation basé sur la norme IEC 61131-3 => Langage Ladder, Sequential function chart (SFC), Boîtes fonctionnelles (FBD), Texte structuré (ST), Liste d'instructions (IL). Si vous etes un peu du métier vous devriez connaitre. Mais ce que je propose n'est pas aussi évolué mais va un peu dans ce sens.
Salutations

[stef31]

Même si je me réjouis à l'idée d'avoir la possibilité de programmer comme sur un automate, qui plus est, avec un langage normalisé, je pense que la force de l'EEDOMUS est de pouvoir être configuré aisément par des utilisateurs non spécialiste de l'automatisme.
Même dans le milieu de l'automatisme, on trouve de plus en plus d'outil de configuration spécifique pour faciliter la programmation de certain type d'automate.
La force de l'EEDOMUS réside en plus d'intégrer des fonctionnalités pré-programmées pour réaliser des mini-automatismes. Après je reconnais que l'on touche vite les limites de la box pour réaliser certains scénarios élaborés.
Pour ce qui est de votre demande, ce n'est pas simple de standardiser un programme afin de regrouper et traiter les informations tel que vous le souhaitez car chaque information devrait être collectée via son code API et celui-ci ne permet pas de déterminer le type de l'information (numérique, analogique, entrée, sortie, etc.)
De plus, je ne vois pas très bien en quoi, cela faciliterait "CONSIDERABLEMENT" pour faire de la domotique avancée. Cela ne fera qu'apporter un langage supplémentaire que peu d'utilisateur maitriseront. Par exemple, le langage LUA (plus orienté informaticien) permet également de réaliser des programmations pour de la domotique avancée. L'inconvénient, c'est que les fabricants ne peuvent pas apporter de support technique sur ce type de programmation lorsqu'un utilisateur rencontre un problème de fonctionnement.
Je suis partisan de l'implémentation d'un langage normalisé comme le langage ST ou autre et je pense que c'est une bonne solution pour répondre à certaines limitations actuelles de la box.
Après si quelque chose est dans les tuyaux au niveau des développeurs, autant attendre plutôt que de se lancer dans une programmation PHP (ou autre) qui ne pourrait, à mon avis, être un script intégré à la box.

[Arno]

Jean,

Merci de ne me pas prendre pour plus neuneu que je ne suis.
J'ai assez largement compris ton propos, mon interrogation étant principalement rhétorique...

Un des intérêts principaux de l'eedomus est justement qu'elle permet de faire des actions complexes facilement sans une ligne de code.

Développer un mode de programmation qui parait simple pour un automaticien, mais qui nécessite peu ou prou de l'être pour l'utiliser ne va pas dans le sens de l'amélioration de l'IHM et du développement de la domotique qui, se doit d'être gérable par l'utilisateur final lambda.

[dplein]

En fait si j'ai bien compris, Jean voudrait "transformer" l'eedomus pour ceux qui sauraient écrire dans un certains langage alors que celle ci a été conçue pour monsieur et madame tout le monde ????

[Arno]

Non, je ne pense pas que Jean veuille "transformer" l'eedomus, mais juste pouvoir utiliser une approche de programmation en rapport avec ses habitudes.

Mais comme pour l'informatique, si la ligne de commande permet de faire des chose très "puissantes", l'utilisation domestique des ordinateur n'a pu se développer que lorsqu'on a pu s'en affranchir pour plus de 99% des tâches courantes.

Je pense que la domotique est au stade où c'est son accessibilité au plus grand nombre qui est un frein à son développement, plus que son aptitude à réaliser des choses très complexes.

Les ressources de développement devraient à mon sens se focaliser sur :
- fiabilisation
- ergonomie, accessibilité de la programmation à l'utilisateur "naïf"

[dplein]

Oui Arno, c'est pour cela que j'avais mis transformer entre 2 " ". Je trouvais pas bien le mot adéquat

En fait, il devrait se tourner vers les machines qui supportent le lua tels que la HC2 et la vera....mais avec les inconvénients qui vont avec.

Pourquoi compliquer un truc qui a été simplifié ?? Pour faire des scénarios plus complexe?? du genre ???

[jeancoudert]

Grafcet

grafcetremplissage.gif (4.11 Kio) Consulté 17220 fois

Bonjour à tous,
Je me réjouis tout d'abord de l'intérêt que soulève mon post et je remercie tout ceux qui l'ont lu et qui y ont amenés leurs commentaires.
J'ai retenu plusieurs points intéressants mais surtout celui qui me fait le plus sourire c'est ceux qui prétendent que la box eedomus actuelle permet de faire des actions COMPLEXES FACILEMENT; alors la je dois dire que je ne suis pas d'accord. Au contraire cette façon de faire oblige à passer un temps fou pour faire des actions complexes, je serais d'accord s’il avait été écrit pour réaliser des action SIMPLES.
Je n'ai pas écrit ceci pour dénigrer la façon dont cette box permet de réaliser des actions simples pour le « Quidam » mais pour faire évoluer cette box en laissant tout ce qui existe aujourd'hui pour ceux qui veulent faire de la Domotique de base et d’y ajouter un Onglet dans Programmation (Par exemple "Automatisme") pour ceux qui veulent faire un petit automatisme simple. Je tiens à préciser ici, que j'ai du réaliser une ouverture automatique de porte d'une trappe, j'y suis arrivé mais quel bidouille pour faire ceci avec le support Eedomus. Alors qu’en Grafcet (je le précise ici, pour ceux qui connaissent, le Grafcet ou SFC n’est pas un langage informatique mais d’automatisme purement graphique accessible à tous) ceci aurait pris pour une personne un peu logique au max 10 minutes.
Le problème de la majorité des réponses reçues c’est que beaucoup d’entre vous se référent à des programmes informatiques, ce qui exactement l’inverse de ce que je propose. L’un d’entre vous à cité le ST (donc quelqu’un qui connait l’un des 5 langages d’automatisme standard) mais justement celui ci, je le laisserai justement de coté car c’est un de ceux qui est un langage informatique (anciennement Pascal pour ceux qui connaissent) dont il faudrait ne pas l’implanter dans une box domotique comme la eedomus. Ma proposition serait de n’en implanté que deux le FDB et le SFC (Grafcet) qui sont purement graphiques/visuels et qui ne demandent aucune connaissance particulière de programmation (aucune ligne a écrire mais du drag and drop d’éléments standard – Voir pièces jointes)
Attention, je ne cherche pas à dire que la box eedomus n’est pas bien, je dis simplement que la domotique de demain doit permettre de s’adresser justement à des non informaticiens. Moi qui connais les deux mondes de l’informatique et de l’automatisme industriel (Je précise que j’ai 60 ans et ai travaillé toute ma vie dans ces deux mondes au combien différents)
Je me permets de revenir sur mon idée première qui aurait été de faire un petit programme interpréter en PHP qui interpréte un fichier Texte, le tout pour faire une faisabilité de ce que je raconte de façon ultra minimaliste du genre :

OU Porte ouverte
OU Détecteur de présence
SLO 100

ET 100
ET Alarme enclenché
SGE Sirène activée

Merci encore pour l’intérêt que vous portez sur ce sujet.
Salutations à tous

[Arno]

Oui je le redis, on peut faire des choses complexes très facilement.

La combinaison règles/états virtuels/macros permet de faire vraiment des choses très puissante de manière très accessible.

Ton exemple :
OU Porte ouverte
OU Détecteur de présence
SLO 100

ET 100
ET Alarme enclenché
SGE Sirène activée

se fait en une seule règle

Le diagramme d'exemple du langage FBD est particulièrement peu vendeur tant il est imbitable !

Le moteur de règle pourrait sans doute être amélioré pour plus de puissance (sans doute au détriment d'un peu de simplicité, quoique), mais je ne vois pas d'exemple d'application courante non réalisable simplement qui le serait par un des langages sus-cités.

[dplein]

Vous me faites peur......

Et je pense parler au nom du gros pourcentage de ceux qui ont du lire ce fil....

H.S.: et moi les automates je m'en sers à mon boulot, alors je veux pas en entendre parler à la maison

[fullpower]

Moi j'ai décroché ...
J'ai l'impression de retomber sur un truc des années 80-90...
Au secours ...


Et de toute façon c'est pas mon truc ....

[anne-marie]

Même si je n'ai absolument rien compris non plus, je trouve que c'est une excellente idée.
L'Eedomus est à la fois à la portée de tout le monde (ou presque ) et permet à d'autres d'aller plus loin.
N'est-ce pas ce que nous faisons jour après jour?
Est-ce que sela répondrait au besoin tant exprimé:
Si evenement Ou/et
Alors...action A
Sinon ....action B
Etc....
Si c'est cela je dis OUI sinon bin oui aussi car je suis curieuse

[jeancoudert]

Rebonjour a tous,
Je vois que le message a du mal à passer mais ce n'est pas grave. La seule chose que j'essaye de faire passer comme message c'est la difficulté énorme de faire des opération séquentiels avec l'eedomus.

1) Combinatoire (FDB) : Le FDB, n'en déplaise à ceratin, est d'une simplicité déconcertante à la portée de tous pour faire des opérations de base combinatoires (ou l'aspect séquentiel n'est pas présent) il s'agit ni plus ni moins que ce que fait facilement la Box Eedomus actuellemnt mais sous forme graphique, les séquences du type:
Si Evénement ALORS ...SINON...FIN sont directement issu de l'informatique et font parti de la préhistoire au profit de choses graphiques comme le FDB qui lui est purement graphique.

2) Séquentiel GRAFCET : Comment faire des automatismes simple et visuel pour faire des séquences qui déclenchent des acions (Alarme, mise en marche d'un moteur, lumiere, etc ...) se suivent les unes aprés les autres en fonctions d'événements extérieres (Fin de course, détecteur de présence, Bouton poussoir, Heure de la journée, etc ...) pouvant aller sur des branches différentes Avec la Eedomus c'est faisable mais rien de graphique (je l'ai fait mais c'est une usine à GAZ) et ca devient rapidement ILLISIBLE lorsque ca se complique.

3) Debuggage : A mes yeux le plus gros repproche lorsque je fais des séquences de programmations avec l'Eedomus (Régles, Macros) c'est l'absence totale d'outil de debugage pour trouver mon erreur, on écrit sa Macro ou et Inchala.... Et aux vus des nombreuses questions que j'ai pu lire sur le Forum c'est bien la ou se trouve le probléme principale. Avec les solutions ci-dessus on sait excatement ou ça coince. Et oui ...

Jevois que je n'arriverai à convaincre personne, mais je vous remercie de m'avoir lu.
Salutations à tous

[stef31]

j'essaye de faire passer comme message c'est la difficulté énorme de faire des opération séquentiels avec l'eedomus.

Je suis 100% d'accord avec vous, c'est vrai que cela pourrait être amélioré. Même si ce n'est pas une difficulté si "énorme".

Si Evénement ALORS ...SINON...FIN sont directement issu de l'informatique et font parti de la préhistoire au profit de choses graphiques comme le FDB qui lui est purement graphique.

Je suis d'accord que les programmations graphiques facilitent la compréhension mais la programmation en langage littérale sur les automates est loin d'être de la préhistoire. Et on trouve encore beaucoup de système que l'on doit configurer en VB.

Je vous rejoint à 100% sur le problème de Debuggage mais c'est malheureusement un problème récurrent qui n'est pas propre à l'EEDOMUS. Et concevoir un outil de debuggage efficace nécessite un travail considérable.

Jevois que je n'arriverai à convaincre personne,

Je pense que sur le forum, nous sommes tous pour l'amélioration des fonctionnalités de l'EEDOMUS.
Après c'est difficile de savoir ce qui apporte une évolution utile au plus grand nombre. Personnellement, je suis favorable à votre proposition mais je suis dubitatif sur la faisabilité de son implémentation dans nos box actuelles.

En tout cas, votre proposition a le mérite de contribuer à faire avancer le débat.

[Thufir]

Je suis également d'accord avec jeancoudert.
Cette possibilité de programmation aiderait beaucoup à la création de scénarios complexes.

Je reconnais que l'on en a pas besoin en permanence, mais il y a certaines choses que je voulais faire et que j'ai laissé tombé.
C'est le principal problème de l'eedomus. Même pour certains besoins simples, il faut avoir recours à des combines avec les règles.
Je me souviens de mes débuts avec l'Eedomus : venant d'un système domotique utilisant HomeSeer, je trouvais la création de règles assez "tordues" on va dire. Créer des règles, ou plutôt des events sous HomeSeer avec des conditions d’intervalles te temps, ou autre critère temporel était vraiment déconcertant de facilité.
Faire la même chose avec l'Eedomus est un casse tête et le plus embêtant est qu'il faut faire des essais en réel pour en vérifier le fonctionnement. Alors si les critères temporels sont sur de longues périodes ... pas trop pratique.

J'accueillerais avec grand plaisir ce type de programmation sur l'Eedomus.
Je n'ai malheureusement pas beaucoup de connaissances en php pour pouvoir aider

[dplein]

Je me souviens de mes débuts avec l'Eedomus : venant d'un système domotique utilisant HomeSeer, je trouvais la création de règles assez "tordues" on va dire.(

T'as pas connu la zibase, toi...

[jeancoudert]

Et bien, je vois que j'ai lancé un débat interssant sur ce sujet et je remercie tous ceux qui y ont partipé, aussi bien ceux qui pensent que c'est inutile, ceux qui sont dubitatifs et ceux qui y sont favorables. On ne peut pas convaincre toit le monde et ce n'était pas mon but d'ailleurs.

J'avoue que si j'étais plus jeune je me serais lancé dans la course pour creer une box regroupant mes idées (enfin peut-etre à la retraite pour m'occuper) ainsi que les bons cotés de chacune de toutes ces Box (je suis Ingénieur Electronicien de l'institut des sciences de l'Ingénieur de Montpeller et ai déjà concu plusieurs cartes éléctroniques complexes poir le compte de plusieurs sociétés, basées en particulier sur des microcontroleurs aussi bien au niveau Hardware que Software). Il se trouve que j'ai essayé plusieurs box domotiques vendues ces dernieres années (sutout par curiosité) et j'ai pu constater que chacune d'entre elles ont leurs avantages et leurs inconvenients. Par exemple la Eedomus est l'une des plus avancée concernant le nombre de périphériques gérés et ceci pour une multitude de fabriqaunts (bravo à l'équipe de eddomus) ainsi qu'une excelente réactivité lors de l'intégartion de nouveaux périphériques.

Enfin l'avenir nous dira si les fabriquants font évoulés leurs box pour les rendre plus facile à programmer aussi bien par le quidam qui veut faire des oprerations de bases que pour le profesionnel qui veut faire une installation complexe le plus rapidement possible (debuggage, maintenance, évolutions, etc ...)

Salutations à tous

[Thufir]

Je me souviens de mes débuts avec l'Eedomus : venant d'un système domotique utilisant HomeSeer, je trouvais la création de règles assez "tordues" on va dire.(

T'as pas connu la zibase, toi...

Non, en effet, ni aucune autre box d'ailleurs en dehors de l'Eedomus.
Mais ceux qui connaissent HomeSeer doivent bien me comprendre

[picatchoume]

Ah ben l'ordre j'ai fait homeseer zibase vera 2 eedomus et branche une homelive 1 heure