Je me demande s'il ne faudrait pas avoir une approche plus générale.
Le routeur a déjà de nombreuses possibilités de contrôle, en incluant des paramètres venant d'autres routeurs. Il y a même les informations Tempo (et on a vu la difficulté à maintenir l'accès à l'information).
Pourtant, on voit régulièrement apparaitre des nouveaux besoins.
L'ajout de nouveaux paramètres rend l'interface graphique plus complexe, au point qu'il y a maintenant un mode "expert" pour masquer tout ce qui est complexe.
Une solution pourrait être d'ajouter une variable dans le code qui serait utilisée pour modifier le comportement.
Cette variable (ou des variables?) non typée serait sous le contrôle d'un service de domotique. A chacun ensuite d'envoyer ce qu'il veut dans cette variable.
Reste à définir comment une telle variable viendrait influencer le comportement du routeur.
Actuellement, la fonction byte Action::TypeEnCours() dans Action.cpp agit comme un "désactivateur" de la fonction principale.
Je mets le code ici:
Dans cette fonction on pourrait avoir des tests supplémentaires sur des variables générales modifiées par une logique externe.
Ca rejoins l'idée de contrôler directement l'ouverture du triac via la domotique. Point soulevé ici:
https://f1atb.fr/forum_f1atb/thread-1219.html
Le routeur a déjà de nombreuses possibilités de contrôle, en incluant des paramètres venant d'autres routeurs. Il y a même les informations Tempo (et on a vu la difficulté à maintenir l'accès à l'information).
Pourtant, on voit régulièrement apparaitre des nouveaux besoins.
L'ajout de nouveaux paramètres rend l'interface graphique plus complexe, au point qu'il y a maintenant un mode "expert" pour masquer tout ce qui est complexe.
Une solution pourrait être d'ajouter une variable dans le code qui serait utilisée pour modifier le comportement.
Cette variable (ou des variables?) non typée serait sous le contrôle d'un service de domotique. A chacun ensuite d'envoyer ce qu'il veut dans cette variable.
Reste à définir comment une telle variable viendrait influencer le comportement du routeur.
Actuellement, la fonction byte Action::TypeEnCours() dans Action.cpp agit comme un "désactivateur" de la fonction principale.
Je mets le code ici:
Code :
byte Action::TypeEnCours(int Heure, float Temperature, int Ltarfbin, int Retard) { //Retourne type d'action active à cette heure et test temperature OK
byte S = 1;
int16_t Tempx10 = int(Temperature * 10.0); //Température en dixième de degré //Equivalent à Action Off
bool ConditionsOk;
for (int i = 0; i < NbPeriode; i++) {
if (Heure >= Hdeb[i] && Heure <= Hfin[i]) {
ConditionsOk = true;
if (Temperature > -100.0) {
if (Tinf[i] < 1500 && Tsup[i] < 1500 && Tinf[i] < Tsup[i]) { // on applique un hystérésis dont les valeurs sont Tinf et Tsup
if (Tempx10 > Tinf[i] && Tempx10 > Tsup[i]) Tseuil = Tinf[i];
if (Tempx10 < Tinf[i] && Tempx10 < Tsup[i]) Tseuil = Tsup[i];
if (Tempx10 > Tseuil) { ConditionsOk = false; }
} else {
if (Tinf[i] <= 1000 && Tempx10 > Tinf[i]) { ConditionsOk = false; }
if (Tsup[i] <= 1000 && Tempx10 < Tsup[i]) { ConditionsOk = false; }
}
}
if (Ltarfbin > 0 && (Ltarfbin & Tarif[i]) == 0) ConditionsOk = false;
if (SelAct[i] != 255) { //On conditionne à une autre action
if (Hmin[i] != 0 && (Hmin[i] > ExtHequiv || ExtValide == 0)) ConditionsOk = false;
if (Hmax[i] != 0 && (Hmax[i] < ExtHequiv || ExtValide == 0)) ConditionsOk = false;
if (Ooff[i] != 0 && ((int(Ooff[i]) >= ExtOuvert && Retard != 100) || ExtValide == 0)) ConditionsOk = false; //Inferieur au seuil bas
if (O_on[i] != 0 && ((int(O_on[i]) > ExtOuvert && Retard == 100) || ExtValide == 0)) ConditionsOk = false; //Inferieur au seuil haut et pas encore ouvert
}
if (ConditionsOk) S = Type[i];
}
}
if (tOnOff > 0) S = 2; // Force On
if (tOnOff < 0) S = 1; // Force Off
return S; //0=NO (pas utilisé),1=OFF,2=ON,3=PW,4=Triac
}Dans cette fonction on pourrait avoir des tests supplémentaires sur des variables générales modifiées par une logique externe.
Ca rejoins l'idée de contrôler directement l'ouverture du triac via la domotique. Point soulevé ici:
https://f1atb.fr/forum_f1atb/thread-1219.html