Jour / nuit : stockage de l'info

[poukill]

Bonjour à tous, et Joyeux Noël

Dites moi, je souhaite pour ma part activer le mode jour / nuit en MANUEL, parce que trop compliqué de l'automatiser.
Comme je n'ai pas encore de superviseur, je vais programmer plusieurs boutons pour le faire. J'ai donc plusieurs questions:
1. Comment synchroniser ces boutons ? D'habitude, les actionneurs ont un retour d'état, mais là j'ai pas d'actionneurs en jeu donc... Sinon je mettrai qu'un bouton !
2. Je me demandais si j'aurais besoin d'une sorte de "mémoire cache" pour stocker cet état en centralisé (module logique ABA /S ?). Je suis curieux d'avoir votre retour là dessus. Parce que si un participant "rate" le télégramme jour/nuit, alors où faire un READ pour récupérer cette information plus tard ?

Bonne journée,

[Ives]

Bonjour,

Il ne faut pas confondre le retour d'état de l'actionneur (l'objet utilisé par exemple pour allumer la LED d'un bouton ou pour le superviseur) avec le retour d'état qui permet une synchronisation de plusieurs boutons dans certains cas comme , par exemple, la commande générale de 3 éclairages qui peut générer dans certaines situations à effectuer un double-appui :
BP 1 --> On/Off lampe 1
BP 2 --> On/Off lampe 2
BP 3 --> On/Off lampe 3
BP G ---> On/off lampes 1, 2 et 3
Dans ce cas, imaginons :
- une première commande sur BP1 qui allume la lampe 1 (On)
- une deuxième commande sur BP2 qui allume la lampe 2 (On)
- un troisième commande sur BP G qui envoie un Off général
Les lampes L1 et L2 vont s'éteindre mais si BP 1 et BP 2 n'en pas informés, le prochain appui sur BP1 (ou BP2) enverra un OFF, et il faudra une seconde action pour envoyer un Off.
J'ai expliqué ici comment procéder dans un post en utilisant les flag ( j'ai fait un post plus complet sur le sujet que je ne retrouve pas) 

Ton cas ne semble pas poser ce problème et il suffit de mettre les objets On/Off de chaque bouton dans une même GA.
Pour ce qui concerne le "ratage" éventuel du télégramme, l’émission de celui-ci est suivie d’une réponse codée sur 8 bits indiquant à l’émetteur si le message a été reçu correctement ou non, ou bien encore d’indiquer si le bus est occupé.

[Dibou]

1. Comment synchroniser ces boutons ? D'habitude, les actionneurs ont un retour d'état, mais là j'ai pas d'actionneurs en jeu donc... Sinon je mettrai qu'un bouton !
2. Je me demandais si j'aurais besoin d'une sorte de "mémoire cache" pour stocker cet état en centralisé (module logique ABA /S ?). Je suis curieux d'avoir votre retour là dessus. Parce que si un participant "rate" le télégramme jour/nuit, alors où faire un READ pour récupérer cette information plus tard ?

Pour synchroniser tes boutons, c’est facile, c’est une question de flag… Tu actives le flag W (write) en plus du T (transmit) sur chaque bouton. Comme ça déjà, ils vont tous partager l’info et la conserveront collectivement.
Le U (udate) sera bienvenu aussi car il permettra de mettre à jour un participant qui aurait un peu perdu les pédales, dans une situation où la réponse à un télégramme read circule sur le bus.

Reste que, au retour d’une éventuelle coupure de tension sur le bus, personne ne va être capable de remettre tout le monde d’accord, sauf à avoir un participant un peu mieux équipé que les autres (batterie, mémoire flash), celui-ci pouvant évidemment être un superviseur… Et c’est probablement sur celui-ci (et sur lui seul) que tu activeras le flag R (read).

[Dibou]

Une précision : excepté mon superviseur (Gira Home Server 4, au démarrage) ou ETS je n’ai jamais vu de participant capable d’envoyer un télégramme READ.
Après, je n’en connais bien qu’un infime échantillon.

[Ives]

Une précision importante  : pour chaque adresse de groupe, UN seul objet doit avoir son flag "Lecture/Read" actif, tous les autres objets de cette même adresse de groupe doivent être inactifs, sinon une interrogation de la valeur donnerait plus d'une réponse et on pourrait même obtenir des réponses discordantes.

[pollux06]

Si tu as une sortie "libre" sur un actionneur, tu peux l'utiliser en lui attribuant une GA bidon.Ce sera le retour d'état de cette sortie qui sera la GA J/N

[Dibou]

Si tu as une sortie "libre" sur un actionneur, tu peux l'utiliser en lui attribuant une GA bidon.Ce sera le retour d'état de cette sortie qui sera la GA J/N

Effectivement, bonne idée : la plupart des actionneurs ToR savent se souvenir de leur état avant coupure de la tension bus.
Je ne crois pas que les miens sachent renvoyer leur état immédiatement au retour de la tension bus (peut-être…)… ils savent cependant le renvoyer périodiquement (ça c’est sûr).
Par contre je ne mettrais pas une GA bidon sur l’objet de retour d’état, mais la même que celle des boutons-poussoirs, de façon à ce que l’actionneur remette d’aplomb l’état des BP, si jamais ils se sont perdus. Et c’est sur cet objet d’état que je mettrais le flag Read.

[pollux06]

Oui Dibou ... quand je mettais le qualificatif de "bidon" je voulais dire que cette GA n'avait aucune véritable fonction réelle si ce n'est d'être liée avec l'actionneur qui va envoyer les ordres d'inversion

[Scorpio5]

Pourquoi un fonctionnement manuel ?
Sans utiliser de supérviseur tu peux utiliser :
Une station meteo (crépusculaire)
Une sonde crépusculaire,
Une horloge.
Un detecteurs (et sa fonction lux)
Ou un autre participant capable de voir la luminosité...
Et ce déclencheurs, aura la fonction read...

[poukill]

Bonjour,

Il ne faut pas confondre le retour d'état de l'actionneur (l'objet utilisé par exemple pour allumer la LED d'un bouton ou pour le superviseur) avec le retour d'état qui permet une synchronisation de plusieurs boutons dans certains cas comme , par exemple, la commande générale de 3 éclairages qui peut générer dans certaines situations à effectuer un double-appui :
BP 1 --> On/Off lampe 1
BP 2 --> On/Off lampe 2
BP 3 --> On/Off lampe 3
BP G ---> On/off lampes 1, 2 et 3
Dans ce cas, imaginons :
- une première commande sur BP1 qui allume la lampe 1 (On)
- une deuxième commande sur BP2 qui allume la lampe 2 (On)
- un troisième commande sur BP G qui envoie un Off général
Les lampes L1 et L2 vont s'éteindre mais si BP 1 et BP 2 n'en pas informés, le prochain appui sur BP1 (ou BP2) enverra un OFF, et il faudra une seconde action pour envoyer un Off.
J'ai expliqué ici comment procéder dans un post en utilisant les flag ( j'ai fait un post plus complet sur le sujet que je ne retrouve pas) 

Ton cas ne semble pas poser ce problème et il suffit de mettre les objets On/Off de chaque bouton dans une même GA.
Pour ce qui concerne le "ratage" éventuel du télégramme, l’émission de celui-ci est suivie d’une réponse codée sur 8 bits indiquant à l’émetteur si le message a été reçu correctement ou non, ou bien encore d’indiquer si le bus est occupé.

Hello Ives, c'est très clair. Tu parles du flag Transmit je pense.

Pour synchroniser tes boutons, c’est facile, c’est une question de flag… Tu actives le flag W (write) en plus du T (transmit) sur chaque bouton. Comme ça déjà, ils vont tous partager l’info et la conserveront collectivement.
Le U (udate) sera bienvenu aussi car il permettra de mettre à jour un participant qui aurait un peu perdu les pédales, dans une situation où la réponse à un télégramme read circule sur le bus.

Reste que, au retour d’une éventuelle coupure de tension sur le bus, personne ne va être capable de remettre tout le monde d’accord, sauf à avoir un participant un peu mieux équipé que les autres (batterie, mémoire flash), celui-ci pouvant évidemment  être un superviseur… Et c’est probablement sur celui-ci (et sur lui seul) que tu activeras le flag R (read).

Excellent. Merci pour ces précisions. Je viens de réviser mes flags ici : https://support.knx.org/hc/fr/articles/1...ndicateurs
Et c'est beaucoup plus clair dans ma tête !

Une précision importante  : pour chaque adresse de groupe, UN seul objet doit avoir son flag "Lecture/Read" actif, tous les autres objets de cette même adresse de groupe doivent être inactifs, sinon une interrogation de la valeur donnerait plus d'une réponse et on pourrait même obtenir des réponses discordantes.

Evidemment, clair après tout ça.

Si tu as une sortie "libre" sur un actionneur, tu peux l'utiliser en lui attribuant une GA bidon.Ce sera le retour d'état de cette sortie qui sera la GA J/N

Hé, super idée !

Pourquoi un fonctionnement manuel ?
Sans utiliser de supérviseur tu peux utiliser :
Une station meteo (crépusculaire)
Une sonde crépusculaire,
Une horloge.
Un detecteurs (et sa fonction lux)
Ou un autre participant capable de voir la luminosité...
Et ce déclencheurs, aura la fonction read...

Non, pour moi le mode "nuit" pilote des lumières plutôt calé sur l'horaire de coucher des enfants. En été, ils se couchent à 20h30 tous les volets seront fermés et je souhaite activer ce mode à la main, parce que ça dépend de trop de paramètres. J'avais vu un post ici sur le forum qui disait que c'était un mode pas évident à automatiser suivant les contraintes de chacun. J'envisage également d'avoir un mode nuit pour parents, un mode nuit pour parent/enfant. En fait, je réalise en écrivant que c'est pas tellement un jour/nuit au sens "terrestre", mais bien un mode d'éclairage nocturne. Je pourrais essayer de lui trouver un autre nom...

En résumé, en jouant bien avec les flags, je peux tout à fait synchroniser plusieurs boutons ensemble, mais qui ne résisteraient pas à un reset du bus. J'ai aussi la possibilité d'utiliser une sortie vide d'un actionneur TOR et de mettre ce mode sur le retour d'état, qui lui résisterait au reset du bus normalement.
Bon, j'ai bien avancé. Je pense qu'il faut que je relise un peu mon cours KNX sur les flags, j'en ai besoin.

Un super merci à tous !