Je suis en train de revoir mes scénarios un peu pour le fun dans l’optique d’être le moins gourmand en ressource pour mon RPI 3…
J’ai des scénarios qui on un cron toutes les minutes pour réaliser diverse actions ou non.
ex : si la TV est allumé, et qu’il fait nuit, j’allume une lampe.
Je me demande si je met des évenements sur l’état de la TV et l’état de la journée si c’est pas moins gourmand en ressource que de vérifier toutes les minutes.
Après toutes les minutes j’ai une log que de l’autre j’en ai moins juste au changement d’état…
C’est peut être plus ou moins pareil, mais je n’ai pas vu d’indication dans la documentation : Documentation Jeedom
J’ai eu le même problème de ressources, et je suis passé au mode provoqué c’est en effet beaucoup plus léger.
dans ton cas programmé sur l’état de la tv:
tu commences par une condition pour vérifier l’état de la journée avant de lancer l’action et c’est réglé!
Dans mon cas, je vérifie si une prise connecté se met a consommer (une lampe) et le scénario se lance et allumes d’autres lampe) et pareil quand j’éteint la lampe cela éteint le reste !
Pour gagner encore plus, je mets même ma condition dans le déclencheur
ex pour ta prise: #puissance# > 10 (par ex) → action: autres lampes ON. Ainsi il ne rentre dans le scénario que quand cette condition est vraie (donc encore moins de ressources car moins de test de conditions)
Bon ok, je chipote peut-être un peu mais je trouve ca plus… léger
vérife par toi même via le log « provisoirement »
utilisation de plus de ressources = scenario plus longtemps à evalué/enclenché
sur des provoqué tu peux faire plusieurs evaluation (avec tous un tas de fonction jeedom)
sur les cron « optimisation via la fonction code » en 0.20 secondes recherche de 10 info dont collecdate avant mise en marche du circulateur (prend en compte si inférieure à 10mn et une dif entre la temp et consigne > 0.3)
et un autre scenario « automatisme » qui a différent cron qui va vérifier « temp exterieur<interieur » pour arret ou mise en marche du scenario « actu » et surtout arrêt chaudière.
Merci a tous pour vos retours, ça me conforte dans mon idée d’utiliser le moins possible les programmations.
C’est surtout mes anciens scénario que je dois reprendre.
L’idéal dans nu système domotique c’est bien d’agir /réagir en fonction d’un changement d’état plutôt que d’aller voir toutes les minutes si ce dit état a changé.
Si tout est bien fait, il n’y a même plus besoin d’intervenir sur l’interface de Jeedom, le truc tourne et vis sa vie.
Pas besoin d’aller aussi loin dans mon cas, l’info de puissance est MAJ s’il y a mini 20% d’écart, donc le scenario se lance :
Quand j’allume la lampe
Toutes les heures si la lampe est allumée (quand il y a de la conso, l’info puissance remonte une fois par heure), ce qui me permet d’allumer + de lampes en fonction de l’heure de la journée
Quand j’éteins la lampe
Si j’utilise la condition, je n’aurai plus un lancement une fois par heure si la lumière est allumée.
De rien, fais attention de ne pas mettre trop de condition dans le déclencheur, c’est quand même un peu plus limité que dans un Si et je me suis fait avoir 1 ou 2 fois donc je mix un peu les 2…
Mais déjà un etat==1 sera moins gourmand que état → si alors sinon…
Pour du chauffage j’ai un scénario qui tourne toutes les heures, pour évaluer si je dois chauffer (ou refroidir en été) et quel type de chauffage je dois appliquer et où, sachant que selon l’heure je vais aussi changer le type de chauffage. (s’il fait pas très froid clim le jour, la nuit radiateur électrique pour les chambres, s’il fait très froid uniquement les radiateurs jour et nuit) le tout paramétrable avec un virtuel pour gérer les seuils de déclenchement.
Sur 6 pièces avec des sondes qui varient à 0.1°C, j’ai bien moins de déclenchements avec un scénario toutes les heures que si je provoque en fonction d’un changement d’état sur les 6 sondes.
Bon après il est fort possible que je ne maitrise peut être pas assez les conditions dans le déclencheur pour gérer ce cas autrement
Pour le chauffage c’et sur que si tu gères en fonction de la sonde c’est pas top !
Par contre arrêter le chauffage si temperature > x ou le démarrer si < x
Donc c’est sûr si tu déclenches toutes les 6sec en fonction de la sonde, c’est juste que le déclencheur est mauvais.
tous dépends du besoin, machine.
regarde le nombre de plug qui tourne avec un cron.
un scénarios remplace certains plug avec en plus la possibilité de les arrêtés. donc se que certains considère comme une usine à gaz tourne depuis 4,5 ans sans y touché sur carte sd. avec toutes ma confiance. (pas d’arrêt brutal)
hs
pour moi la première verification (utilisation inappropriée de resources) serait la verif système donc des log système. donc avant jeedom
exemple
pour ceux qui n’utilise pas les pack jeedom « dns » de voir toutes les tentatives d’intrusion rejeté par fan2ban.
En regardant le fichier de log syslog, je constate que j’ai la ligne suivante qui se répète plusieurs fois par seconde :
Nov 30 07:50:21 dom kernel: [762847.513599] Bluetooth: hci0: Frame reassembly failed (-84)
Est-ce que quelq’un aurait une idée de quoi cela proviendrai ?
J’utilise le Bluetooth de mon raspbery pi3B avec les plugins plugin-blea et depuis peu plugin-phone_detection. J’ai regardé dans l’historique, j’avais déjà ces messages bien avant le plugin phone_detection.
Sinon pour revenir au sujet de ce fil de discution, j’ai une question concernant la donnée Charge de l’onglet Santé. Savez-vous si c’est la charge du serveur et a quoi correspond cette valeur ?
