Citation :@filou59, l'automate WAGO ne revient pas plus cher qu'un truc basique quand même ?

(26/03/2019, 16:44:23)vf62 a écrit : Hello,

J'avoue que j'ai un peu de mal à comprendre ton besoin et la configuration que tu exposes (on double le nombre de GA par action ?)
As tu un exemple concret ?
Ex : GA 1/1/1 Pression BP1 + GA 1/1/2 ON/OFF Lampe 1 -> Le superviseur reçoit l'info de pression, traite l'info avec d'autres données et actionne GA 1/1/2 au besoin.
2 GA pour une action. En KNX pur, ca donne du BP vers l'actionneur GA 1/1/2 ON/OFF, sans avoir le GA de pression BP.
 
Pourquoi utiliser des GA différents pour le superviseur que ceux en place en "pur knx" ? Sinon, on bypass le superviseur...

De mon côté, je suis parti sur le principe que les fonctions core d'une maison comme allumer une lumière ne doit pas être totalement géré d'un superviseur, ou tout au moins, qu'un simple appui sur un bouton d'un interupteur permet d'allumer cette lumiere. Le superviseur est dédié aux fonctions de confort et d'automatisation qui, en cas d'indisponibilité, sont gênante mais n’empêche pas de pouvoir vivre dans la maison. D'ou mon interrogation. Mais si la pression d'un interrupteur doit passer par une logique, il faut passer par le superviseur...
Du coup, le superviseur ne vient qu'en surcouche et utilise les GA standard et n'intervient pas en coupure complète comme tu le présente (1 GA vers le superviseur et 1 GA du superviseur vers l'actionneur par exemple). Comment le mettre en surcouche ? Pour moi, une surcouche c'est une couche au dessus, qui devrait donc avoir les même fonction, mais avec plus de finesse.

Mais peut être que je suis hors sujet et n'ai pas compris ton besoin (et retour au debut de mon post )

(26/03/2019, 18:02:45)filou59 a écrit : Meme un simple crénaux horaire je ne le gère pas par le superviseur. Je dispose d'une horloge KNX hardware avec 8 sorties. Mon superviseur en dispose de 50.
Les 8 sorties sont pour les choses plus essentiel, celles du superviseur pour le confort. Mais 8, c'est clairement pas assez si on veux se passer de superviseur.

Comme je l'ai dit dans un autre post, la logique que certains mettent en oeuvre dans un superviseur peut très bien se faire via de l'apparaillage KNX. Oui et non. Mon superviseur calcule la courbe du soleil et actionne les stores en fonction. (une station météo peut le faire aussi, je sais)

-Un automate WAGO / Logo avec module KNX
-Un Raspberry avec Codesys et la couche KNX. Le rasberry est un outil de développement, pas de production. Il dispose de contrainte de coût qui en font un produit fragile. Donc un point faible, comme un superviseur "commercial".
-Des Horloges et modules logiques qui vont bien. Je pense que le module logique de ABB ABA/S 1.2.1 dispose également d'un petit OS, donc également sensible... Et je suis totalement opposé à la dispertion des modules logique via divers participant qui embarquent cela. C'est du dépannage.


Un raspberry pourra etre considéré comme peu fiable a cause des prb lié au carte SD, mais en prenant les précaution adequat on peut être tranquille pendant des années. 
Après pour quel euros, on peut facilement avoir un backup de la carte SD mise en prod, ce qui permet de redémarrer en cas de prb sur une config saine en moins de 30s si besoin.

L'avantage du superviseur, c'est la simplicité de mise en oeuvre comparé aux solutions que je propose a base d'automate.

(26/03/2019, 18:47:44)cocothebo a écrit : Alors moi j'ai (encore) aucune implémentation KNX mais pour répondre à vf62, je pense que Jonathan parle de 2 GA par action pour que quand tu appuies sur l'interrupteur le superviseur fait son processing complexe puis actionne ce qui va bien avec d'autres GA. Voilà...
Ca permet de séparer les processing du superviseur des actionneurs.

Sinon pour la question initiale, si je voulais faire cela, j'utiliserais un module logique (à voir si ça marche dans ce cas) pour appliquer un masque de GA. Masque dépendant de la reception d'un "heartbeat" du superviseur.
En choisissant bien les masques, on peut faire que sans preuve de vie du superviseur, on renvoie les même type de GA que celles du superviseur  ou des GA spécifiques du mode "dégradé" (ou si c'est possible faire une table de mapping etc.). Ouais, mais cela retarde les actions car le heartbeat ne se ferait pas à fréquence élevée sinon surcharge du bus. Ce qui va créer des latences... Par ailleurs, je ne pense pas que les participants puissent attendre un heartbeat pour renvoyer ou pas leur commande.
A moins que l'on joue sur le fait qu'il n'y ait pas de ACK. Mais je ne voit toujours pas comment dévier l'ordre initial vers un second GA...

Le gros moins de cette solution (si c'est possible de faire ça avec un module logique), c'est qu'on recentralise tout ce qui est dépendant du superviseur sur le module logique qui devient donc critique.


Une autre solution serait d'utiliser des "capteurs" (quoi n'importe quel module de commande, je sais plus si ça a un nom) intègre un peu de logique pour envoyer des GAs différentes suivant la réception du heartbeat, mais je ne crois pas avoir croisé ce genre de matos (du moins du côté des interrupteurs par ex)


@filou59, l'automate WAGO ne revient pas plus cher qu'un truc basique quand même ?

Citation :Le rasberry est un outil de développement, pas de production. Il dispose de contrainte de coût qui en font un produit fragile. Donc un point faible, comme un superviseur "commercial".

Citation :Je pense que le module logique de ABB ABA/S 1.2.1 dispose également d'un petit OS, donc également sensible... Et je suis totalement opposé à la dispertion des modules logique via divers participant qui embarquent cela. C'est du dépannage.

(27/03/2019, 11:03:15)Kevlille a écrit : Salut Jonathan,

Je ne comprends pas trop ta logique des GA pour le superviseur.

Si tu lis ta GA d'action et ta GA de retour d'état vers le supervisieur (dans le cas d'un switch), il n'y a pas besoin de créer d'autre GA spécifiques pour le superviseur, non?

Le superviseur à juste besoin du retour d'état pour mettre à jour la visualisation et de la GA d'action pour déclencher l'action depuis le superviseur (simulation de l'appui sur le BP)...

Je dis des conneries?

(27/03/2019, 13:30:16)vf62 a écrit : si je prends un exemple concret avec mon couloir qui comporte un détecteur de mouvement, 2 circuits de lumieres : un pour les plafonniers et un pour les balises led en bas de mur.
Effectivement, je n'ai pas de GA direct entre le détecteur et les sorties des 2 circuits, le superviseur (jeedom) est entre les 2 et évalue selon des conditions (mode nuit par exemple) si il faut allumer les plafonnier ou les balises.
Mais si jamais le superviseur est HS, en secours, il y a un bouton à chaque bout du couloir qui permet d'allumer les plafonniers en pur knx.
et si le bouton est utilisé alors que le superviseur est en fonction, avec les retours d'état, il est très simple pour lui de gérer ce cas.

Et si pas de BP par exemple vu qu'il y a un capteur de présence ? Car dans ce cas, je peux tout dédoubler. Les BP qui communiquent avec le superviseur et ceux au cas ou, en pru KNX. Ce n'est pas l'idée. Certaines pièces n'ont pas de hardware en backup. Je cherche une solution plus "universelle". Mais tu as cerné la problématique.

(27/03/2019, 13:37:11)Kevlille a écrit : @Cocothebo

Avec les RPI 3B+, plus besoin de SD on peut booter direct sur un support branché en USB.

J'en ai un qui tourne H24 depuis quasi un an (avec un SSD M2 sur une carte fille branché en USB) et aucun plantage.... DOnc la solution RPI peut être robuste ;-)
Laisse moi faire un tour près de ton RPi avec un appareil photo... 
Juste a voir la partie alimentation, on voit que c'est light... Surtout si le RPi chauffe un peu. Ca peut fonctionner pendant qques temps mais ce n'est pas écrit noir sur blanc, contrairement à du matériel conçu pour un usage intensif.
Un peu comme pour les HDD RAID et Green...

(27/03/2019, 17:32:25)Kevlille a écrit : @Jonathan:

Des utilisations "pro" des raspberry existent:  https://proknx.com/fr/product/realknx-air-fr/  preuve que niveau robustesse ce n'est pas si mal ;-)