Proposition optimisation remontée d'évènements

[philippe]

C'est pas plutôt car tu as coché la non répétition des actions ?

bien vu loic , c’était un test je voulais voir si tu suivais
dsl , j'avais oublié cette fonction

Merci

[Marquis]

Je pense avoir trouvé la derniere beta (1.191) devrait corriger

Merci, je regarde ce soir si cela corrige les choses, suis au boulot....

Bonsoir

@Loic : effectivement la mise à jour 1.191 corrige le soucis, fonctionnement attendu avec et sans "autoriser la repetition...."
et la commande ON remonte 1 et pas 100 dans les logs

Merci

[rosty]

Petit problème pour ma part avec cette fonction

J'ai un simple scénario qui allume une prise via une télécommande Chacon (bouton I et O).

1.Si la prise a été éteinte par autre chose que la télécommande (Virtuel, Impérihome, etc...) ou coupure de courant bah impossible de rallumer la prise via la télécommande car sont état a elle est resté à 1

J'ai exactement le même problème dans la chambre des enfant, faut faire OFF sur la télécommande (même si la prise est déja OFF) puis ON pour que ça s'allume

2. Scénario similaire qui commande ma TV (Télécommande et prise identique) et la une fois que j'arrive a allumer la TV, 5 seconde après la prise se coupe

C'est pas que mais là c'est madame qui rale car peut pas voir la TV...

Au passage, j'ai pas trouvé ou désactiver cette nouveauté

Merci

[loic]

Dans ton cas il faut désactiver cette fonction sur les périphérique qui pose soucis, j'ai du le faire aussi sur un inter. Pour la désactiver c'est dans générale affichage puis tu choisis ta commande info 2eme onglet tout en bas

[rosty]

Ok, je vais le faire sur un bon paquet du coup car j'ai ce problème sur pas mal de périph.
Je viens aussi de remarque (mais pas sûr car pas pu retester) que c'est pareil pour les virtuel commandé via un scénario
Merci

[rosty]

Dailleurs, dans le cas d'un détecteur de fumée qui n'envoi qu'un seul état (typiquement un détecteur KD101) on risque de ne pas être alerté si il la dernière info est 1 (le test a faire chaque semaine normalement renvoi 1).
Je pense que c'est un point important a souligné

L'idéal serait que par défaut ce soit comme avant et qu'on ai la possibilité de cocher une case pour activer cette amélioration
Une case un peu moins discrète qui pourrait être directement dans la conf du module.

[loic]

Pour ce genre de détecteur il faut effectivement le faire à la main. Enfaite 90% des modules devrait être sur le nouveau système donc il est plus logique de faire comme actuellement. Mettre dans les plugins c'est trop lourd d'où cette page qui me permet de mettre de la conf commun à toutes les commandes

[rosty]

Ok, ça confirme ma crainte, suffit de le savoir
Merci

[loic]

J'ai fait un léger retour arrière sur cette fonctionnalité car elle posé beaucoup de soucis au final :
- maintenant les événements sont répété mais tous ce qui est date de collect, ajout a l'historique et mise à jour de l'interface ne l'ai pas en cas de même valeur

[Marquis]

et donc conserve t-on la possibilité de cocher une case "ne pas répéter" au besoin ? pour ne pas déclencher un événement si valeur inchangée ?

[loic]

Non vu que c'est revenu comme avant déclenché a nouveau

[Marquis]

OK, je prends en compte....

personnellement je trouvais la modification proposée logique, du moment que l'on pouvait inverser le fonctionnement sur les commandes le nécessitant, dans un but de diminuer la charge .... ou de pouvoir laisser une case à cocher par commande comme sur la 1.191 initiale permettant d'empercher un événement en cas de valeur identique..."événement sur changement" pour éviter d'avoir a comparer avec une ancienne valeur au niveau des scénarii

[loic]

La deja je limite plus l'impact des événements répété ca devrait quand même légèrement diminuer la charge sur le system

[jbval]

De mon côté pas d'impact négatif pour le moment.
La charge système semble stabilisée entre 2 & 2.2 sur une mini avec tout ce que j'ai mis.
Ces modifs + les dernières modifs Rfxcom&co semblent avoir un effet positif sur les déclenchements des scénarios et leur vitesse à se lancer, ça me parait donc bien tout ça!

[Bipbip41]

J'ai un petit soucis de mon côté : En fait j'utilise des télécommandes DIO, à 6 boutons.

Pour gagner des fonctionnalités, j'avais fais des scénarios pour utiliser qu'un seul bouton pour chaque objet : un appuie sur le bouton 1 allume la lumière par exemple, un second l'éteint, avec un système de variable qui s'incrémente. Ca me permettait de contrôler 6 objets ou scénarios au lieu de 3.

Du coup, ça ne fonctionne plus ^^

EDIT : je précise : les 6 boutons fonctionnent 2 par 2, comme pour beaucoup de télécommandes. Donc, Je ne peux plus faire un appuie sur 1ON par exemple, et un second pour eteindre, mais 1 appuie sur 1ON, un sur 1OFF pour changer la valeur, et là je peux rappuyer sur 1ON. Du coup ca me déclenche autre hose avec 1OFF ^^

[loic]

Remet a jour j'ai fait un retour arrière donc plus de régression maintenant

[Bipbip41]

Oki, merci de ta réponse.

Mais ta fonctionnalité était intéressante, est-ce qu'il ne serai pas possible d'exclure certains modules du traitement de la répétition, et laisser les autres par défaut (avec une case à cocher dans la conf du module par exemple) ? Car à part pour les télécommandes, tout le reste fonctionnait impec, et je pense qu'on est beaucoup à avoir juste un petit truc qui ne fonctionne plus. Après, au niveau dev, je ne sais pas si c'est compliqué...

[loic]

Ca pose problème aussi au plugin meteo après je peux faire l'inverse c'est dire pour celui la pas de répétition du tout mais pour moi c'est pas très interessant

[domos]

Il y eu un "retour" arrière sur cette fonctionnalité, donc ?

Dommage car effectivement cela pouvait aussi réduire les écritures en base pour des équipements un peu trop bavards.
Il y a des sondes Oregon qui "causent" toutes les ~40s et c'était pratique pour limiter les données.


Pas possible de garder la fonctionnalité en option ?

[loic]

Je viens de l'ajouter en option mais pour tous ce qui est rfxcom c'est intégré au démon deja