Bonjour Sylvain
Sylvainp a écrit:Salut,
je me pose une question un peu générale sur la façon dont vous construisez vos règles.
De mon côté j’utilise surtout des conditions simples, mais je me demande si certains vont plus loin que le “si A alors B”.
Par exemple, est-ce que vous combinez plusieurs infos pour arriver à une sorte de décision globale, ou un niveau de confiance avant d’agir ? J’ai en tête des logiques où plusieurs paramètres comptent en même temps, avec des priorités qui changent selon le contexte.
Avec l’API, les requêtes HTTP ou des scripts externes, ça semble faisable, mais je me demande si ça reste lisible et maintenable sur le long terme, ou si ça devient vite une usine à gaz.
Bref, vous restez volontairement sur des règles simples, ou certains d’entre vous utilisent des logiques un peu plus “intelligentes” ?
Curieux d’avoir vos retours.
J'ai revérifie hier soir, mon script fonctionne toujours, il y a éventuellement quelques mini modifications à faire.
Décris moi ce que tu souhaiterais faire et je te dirai si ça fontionne ou si c'est facile à modifier :
Pour l'instant, le script de "supercalculator" permet d'effectuer des opérations complexes à partir
d'un script écrit dans les variables VAR1, VAR2 et VAR3.
Cela ressemble assez à une calculatrice programmable :
On peut entrer des expressions mathématiques, logiques, temporelles, textuelles et d'accès aux valeurs des capteurs eedomus : comme on les écrirait sous la forme habituelle
- Code : Tout sélectionner
- Fonctions mathematiques (nombre de parametres, 1 par defaut): 'abs', 'acos', 'asin', 'atan', 'atan2(2)', 'bindec', 'bin2hex', 'ceil', 'chr', 'chs', 'cos', 'cosh', 'decbin' , 'dechex' , 'deg2rad', 'exp', 'floor(1-2)', 'fmod(2)', 'hexdec', 'log(1-2)','log10', 'pow(2)', 'pow10' 'ex', 'rad2deg', 'rand(0-2)', 'round(1-2)', 'sin', 'sqrt', 'tan', 'acosh', 'asinh', 'atanh', 'frac(1-2)', 'hexbin','sinh', 'sqr', 'tanh'.
- Fonctions temporelles : 'microtime','time','date(format)', 'gmdate(format)', 'strtotime(date)', 'mkday0', 'mkhour0', 'mktime', 'mktime_',
date({Y})=>Annee, date({m})=>Mois[1..12], date({d})=>jour_mois[1..31], date({z})=>jour_annee[1..366],'date({w}'=>jour_semaine[0..6(dimanche)], date({W})=>Semaine[1..53], 'date({L}'=>bissextile[0-1], date({H})=>heure_jour, date({i})=>minute_heure
- Fonctions texte : 'chr' , 'ltrim(1-2)', 'ord', 'rtrim(1-2)', 'sprintf(1-6)', 'str_pad(2-4)', 'str_suppr(2)', 'strlen', 'strpos(2-3)', 'strrchr(2-3)', 'strstr(2)', 'strtr(3)', 'strtolower', 'strtoupper', 'substr(2-3)', 'trim(1-2)', 'ucfirst'.
- Fonctions eedomus : 'device'=>'value', 'devtype'=>'value_type', 'devchange'=>'change' (YYYY-MM-DD HH:MM:SS), 'devtime'=>'change' (Entier format unix : secondes), 'devage'=>'change' (temps depuis la derniere mesure : secondes),'devunit'=>'unit','devname'=>'full_name','devtext'=>'value_text','devstate'=>'pending'.
- operateurs utilisables : '*', '/', '+', '-', modulo '%', puissance '**' , et arithmetique '&', ou arithmetique '|', xor arithmetique '^', decalage a gauche '<<', decalage a droite'>>', inf ou egal '<=', sup ou egal '>=', inferieur '<', superieur '>', equivalent '==', different '!=', not '!', et logique '&&', ou logique '||', '.' concatenation), '_', '#' operateurs internes;
Les operateurs '<' et '>' de la version 1.1 devraient etre remplaces par '<=' et '>='. L'operateur puissance normal est '**' et l'operateur 'xor' peut etre '^^'. Pour rester compatible avec les versions anterieures, on peut utiliser le symbole '^' pour la puissance (ext=1, par defaut) au lieu de xor (ext=0).
- Constantes : 'pi', 'e', 'last', 'now', 'sp'=>espace, dg (unite degre), 'ymd','ymd_','hms','hms_','ymdhms','ymdhms_','hm','hm_'.
- Alias : 'argch' => 'acosh', 'arccos' => 'acos', 'arcsin' => 'asin', 'argsh' => 'asinh', 'arctan' => 'atan', 'argtanh' => 'atanh', 'bin2dec' => 'bindec', 'bin2hex' => 'binhex','ch' => 'cosh','dec2bin' => 'decbin', 'dec2hex' => 'dechex', deg' => 'rad2deg', 'hex2bin' => 'hexbin', 'hex2dec' => 'hexdec', 'c' => 'chr', 'ln' => 'log', 'now'=>time(), 'rad' => 'deg2rad','sh' => 'sinh', 'tolower' => 'strtolower', 'toupper' => 'strtoupper'
'='=>'==','@' => '.' (concatenation 1@2 = "1"."2" -> 12); '^^' -> xor; si (ext=1) '^'-> '**' (puissance), sinon '^' -> xor
On peut utiliser des structures de décision
- Code : Tout sélectionner
Position d'une valeur dans une liste : in(val,expr1,expr2,...exprn) => 0 si pas de correspondance, indice dans la suite si identique (premier element 1),
Selection d'une valeur dans une liste : case(val,expr1,expr2,...exprn) [get(val,expr1,expr2,...exprn)] => 0 si round(val)<1>, exprn si round(val)>n,
Position d'une valeur (chaine ou numerique) dans une liste croissante (seuil): thresh(val,expr1,expr2,...exprn) => 0 si val<expr1, sinon 1 si val<expr2, ..., sinon (val>=n),
Si alors sinon :
if(expr) -> 0 si expr=0, 1 sinon,
if(expr,expr1) -> 0 si expr=0, expr1 sinon,
if(expr,expr1,expr2) -> expr2 si expr=0, expr1 sinon,
if(expr,expr1,expr2,expr3) -> expr1 si expr>0, expr2 si expr=0, expr3 sinon (expr negatif),
On peut définir des constantes ou des variables et même des fonctions.
Tout cela s'écrit de manière naturelle, puis est transformé en notation polonaise inverse (RPN) avant exécution. On peut éviter la traduction à chaque utilisation en utilisant directement une écriture RPN Le programme se fait un plaisir de d'afficher la traduction dans la fenêtre de test...
Bref commence par décrire ton souhait et je te dirais si c'est faisable :
Informations d'entrée : capteurs avec les valeurs renvoyées
Traitement des informations : mathématique ou conditionnel
Informations de sortie : on peut en créer plusieurs
Je me suis bien amusé à faire ce script
eedomus+, Zibase V1, RFP1000, RFXcom, RadioDriver CPL 630 X2D, capteurs puissance OWL, thermometres Oregon, téléinfo (USB Linky), detecteurs ouverture X2D, pilotage chauffage X2D, Ecoflow River PRO, PAC Shogun (Atlantic-Cozytouch)
