utiliser persistent-data

[pierrotori]

Bonjour

je viens d'ajouter dans le globaldata , 3 valeurs en json qui sont mises à jour une fois par jour
mon script qui utilise ces datas les exploite, mais en utilisant cette fonctionnalité je trouve que la cpu de mon RPI a augmenté légèrement.

Avez vous cosntaté cela en utilisant les persistent-data dans globaldata ?
Pierrotori

[pierrotori]

De mon point de vue il faut vraiment garder le globaldata pour des données globales, à tous les scripts comme présence ou chauffage etc.... utilisable par tous les scripts

ici
J'ai un module autoclose qui stock les timer id des volets à partir d'un script de type timer
J'ai un script de type device par ouvrants des portes (ici 3 ouvrants donc 3 scripts) correspondant à chaque volet et qui consulte les globaldata généré par le script de type timer. au total 4 scripts
-> fonctionnalité globale: mettre le timer off du volet si la porte est ouverte afin de ne pas se retrouver dehors

je vais donc tout regrouper sous un script de type timer et device et utiliser le persistent data du script, donc 1 script
le but étant de faire le moins d'appel à la fonction openurl lorsque l'on a besoin de l'information des timerID

Du coup est ce plus rapide de lire le data persistent du script que d'aller lire la valeur du dispositif, je fais un test ce soir pour évaluer cette durée de lecture entre dz.device(<nomdevice>).value ou dz.globaldata.valeur

[Keros]

Merci de poster vos sujets dans les sous-forums dédiés.

[pierrotori]

test de lecture d'une donnée dans persistent data et lecture d'une donnée d'un dispositif

Code : Tout sélectionner

2024-03-27 08:24:31.695 Error: dzVents: Error: (3.1.8) TEST v1.0: variable data : 17
2024-03-27 08:24:31.695 Error: dzVents: Error: (3.1.8) TEST v1.0: Fin data : 9.0ms
2024-03-27 08:24:31.752 Error: dzVents: Error: (3.1.8) TEST v1.0: variable dispositif : Rain
2024-03-27 08:24:31.752 Error: dzVents: Error: (3.1.8) TEST v1.0: Fin dispositif : 46.0ms

on se retrouve avec un rapport de 5 environs, conclusion si on a une valeur qui doit être stockée soit pour le script ou en global, il faut la stocker dans les persistent data au lieu de relire le dispositif

pour mon test les persistent-data sont en RAM

pour la question de départ sur la CPU , je vais faire un test en persistent-data local au script pour voir la différence

[Flying Domotic]

On peut aussi utiliser les userdata (variables utilisateur), qui sont stockés dans la base.

[pierrotori]

je l'avais fait aussi mais ca reste lent comme un dispositif

[pierrotori]

le globaldata c'est bien pour des données qui changent peu sur une journée comme le statut d'un chauffage, sur des dispositifs comme une porte , il faut mieux utiliser les persistents-data du script

[Flying Domotic]

Ah bon ! Ben je devrais changer mes scripts (dont une large partie ont étés écrits avant dzVents) ...

Il faudrait que je fasse des tests pour voir la différence de charge sur la bécane.

[pierrotori]

j’utilise les variables uniquement en tant que données persistantes car tous mes scripts utilisent des datas persistantes mais en ram donc volatiles du coup j’ai tres peu de variables en base
j’ai remarque que quand un script utilise les datas persistantes a travers le globaldata celui-ci est mis a jour a chaque accès donc si il est gros que tous les scripts y accèdent et avec des fréquences rapprochées ca fait monter la cpu
la variable permettra de voir la valeur a travers l’interface web si besoin