Bug sur condition apparu récemment
#1
Bonjour,

Je viens de passer de la version 1.4.126 à la version 1.4.129.
Depuis j'ai un automate qui ne fonctionne plus. Celui-ci tombe en erreur sur une condition qui prend la forme d'un OU sur plusieurs contacts en testant la valeur "est déclenché ?"
Si je fais le test sur la valeur d'un seul des contacts ça marche. C'est avec le OU que ça coince.
[ATTACH=CONFIG]561[/ATTACH]
A l'avance merci à la Team de jeter un coup d'oeil parce que c'est assez gênant...
@+
Thierry


Pièces jointes Image(s)
   
Répondre
#2
Bonjour,

Petit up pour la team LifeDomus....
Pourriez vous jeter un coup d'oeil svp vu qu'il s'agit clairement d'une régression (et qu'en plus elle m'embête bien car elle touche à l'automatisme lié à une alarme...)
A l'avance merci !

Thierry
Répondre
#3
J'ai un soucis équivalent sur des contacts de fermeture placés sur portes et fenêtres.
Chez moi le problème semble venir de l'état retourné par les contacts après un redémarrage de la box LD qui n'est actualisé que lors de l'ouverture/fermeture.
Après différents essaies par ETS ou LD la seule solution qui marche le mieux c'est de faire le tour de la maison et d'ouvrir/fermer les portes et fenêtres, effacer les logs du ou des automates en erreurs et ensuite ça marche.

Le soucis est aussi apparu depuis la mise à jour vers la version 1.4.129 ...

A défaut d'une correction rapide de la part de la team LD, j'espère que ça pourra aider un peu ...

Hervé
Lifedomus v2.0.143
CS Windows 7
DS Windows 7, Linux Wine, Ipad, Android
Répondre
#4
Bonjour,

Dans la mise à jour 1.4.128 , nous avons fait le choix de vider les états connu lors d'un redémarrage. Dans votre cas, un des détecteur doit être mal initialisé au démarrage.

Suite a des recherches, nous allons faire quelque chose pour vous puisque dans votre cas, il s'agit d'un OU est donc même si les états des autres ne sont pas connues nous devons passer a true si l'un d'eux l'est.

Cela sera fait dans la prochaine mise à jour bêta.

Julien
Répondre
#5
Julien a écrit :Bonjour,

Dans la mise à jour 1.4.128 , nous avons fait le choix de vider les états connu lors d'un redémarrage. Dans votre cas, un des détecteur doit être mal initialisé au démarrage.

Suite a des recherches, nous allons faire quelque chose pour vous puisque dans votre cas, il s'agit d'un OU est donc même si les états des autres ne sont pas connues nous devons passer a true si l'un d'eux l'est.

Cela sera fait dans la prochaine mise à jour bêta.

Julien
Bonjour,

J'ai fait quelques essais supplémentaires suite à vos deux messages, Hervé et Julien.

J'avais simplifié le test en posant un OU sur 2 contacts. Toujours le même problème.
Comme dit, j'avais aussi effectué le test sur 1 seul de chacun des 2 contacts, sans OU, et ça fonctionnait.
Je viens de le refaire sur les 2 contacts avec un OU. Même problème.
J'ai ouvert et refermé les 2 contacts et ça refonctionne.
J'ai reéssayé avec le OU sur tous les contacts et ça refonctionne aussi.

Par contre je me suis rendu compte en parallèle que les états des contacts affichés dans le DS n'étaient pas tous corrects (bien que mon test fonctionne à nouveau). Certains sont présentés comme étant ouverts alors qu'ils sont fermés, et d'autres sont affichés sous la forme d'un carré rouge. J'ai essayé d'aller ouvrir et fermer les contacts concernés. Dans certains cas ça rétablit un affichage correct, dans d'autres non, sans que je parvienne à identifier une logique à tout cela.

Par ailleurs je ne comprends pas / ne maîtrise pas cette histoire d'état non connu au démarrage. Il ne faudrait pas qu'à chaque redémarrage de la box je doive aller ouvrir et fermer toutes mes portes et fenêtres pour que ça fonctionne correctement (en admettant que cela suffise, ce qui n'est comme dit pas le cas...).

Merci à vous deux de votre aide passée et future !
@+

Thierry
Répondre
#6
Bonjour,

Si vos détecteur sont en KNX il faut vérifier que les adresses est bien le flag read pour être bien initialisé lors du démarrage et donc non normalement pas besoin de bouger les détecteurs. Vous pouvez lancer le debugger et vérifier si les trames sont bien émise au changement d'état.

Julien
Répondre
#7
Julien a écrit :Bonjour,

Si vos détecteur sont en KNX il faut vérifier que les adresses est bien le flag read pour être bien initialisé lors du démarrage et donc non normalement pas besoin de bouger les détecteurs. Vous pouvez lancer le debugger et vérifier si les trames sont bien émise au changement d'état.

Julien
Bonjour Julien,
Je ne réponds que maintenant car j'étais en déplacement pendant quelques jours... à Villeneuve d'Ascq...
Mes détecteurs sont bien en KNX. J'ai vérifié comment ils étaient paramétrés. Le flag read n'est pas positionné sauf pour l'un d'entre eux. Il se trouve que celui-ci pose toujours problème d'affichage, comme quelques autres, sans que je ne parvienne à en comprendre la logique. Au niveau de CS ils sont tous paramétrés de la même façon. Au niveau d'ETS itou, sauf pour ce flag positionné pour un seul.
Par ailleurs, depuis mon dernier mail, l'affichage d'un certain nombre de contacts est à présent correct sans qu'ils aient été ouverts. Je ne comprends pas grand chose à tout cela...
Enfin désolé mais impossible de (re)trouver comment accéder au debugger ni dans la doc ni dans le forum après 20 minutes de recherches... à défaut de doc, pourriez vous me dire comment on fait ?
à bientôt,
Thierry
Répondre
#8
Bonjour

Si le flag read n'est pas positionné, lors du démarrage du serveur lorsque Lifedomus va lire l'adresse de l'état du détecteur, celle-ci ne répondra pas et nous ne connaîtrons donc pas son état (widget rouge).
C'est donc pour cela qu'il faut les bouger pour qu'ils envoient leurs état. Il est recommandé d'utiliser le flag read.

Pour ce qui est du debugger, il est accéssible sur n'importe quel équipement KNX dans le CS en cliquant sur la petite bête à côté du nom du connecteur ou en cliquant sur cette même petite bête dans la page gestion des connecteurs. Cela ouvre une pop-up qui ressemble au moniteur de groupe KNX.

Julien
Répondre
#9
Julien a écrit :Bonjour

Si le flag read n'est pas positionné, lors du démarrage du serveur lorsque Lifedomus va lire l'adresse de l'état du détecteur, celle-ci ne répondra pas et nous ne connaîtrons donc pas son état (widget rouge).
C'est donc pour cela qu'il faut les bouger pour qu'ils envoient leurs état. Il est recommandé d'utiliser le flag read.

Pour ce qui est du debugger, il est accéssible sur n'importe quel équipement KNX dans le CS en cliquant sur la petite bête à côté du nom du connecteur ou en cliquant sur cette même petite bête dans la page gestion des connecteurs. Cela ouvre une pop-up qui ressemble au moniteur de groupe KNX.

Julien
Bonjour Julien,
J'ai positionné les flag read, redémarré le serveur LD et c'est bon.
Par contre, j'ai remarqué que depuis quelques temps, le redémarrage de la box a pour effet d'éteindre les lampes alors que cela ne le faisait pas avant. Une explication ?
@+
Thierry
Répondre
#10
Bonjour,

Pour extinction des lampes, je vous renvois vers le journal d’événement et d'analyser quel automatisme (je suppose) les éteins.

Julien
Répondre


Sujets apparemment similaires...
Sujet Auteur Réponses Affichages Dernier message
  Supprimer un équipement (utilisé dans une condition) fredblabla 5 9,164 07-07-2017, 10:49 PM
Dernier message: bizniouf
  Problème sur condition & v1.4.131-rc2 Gurvan 2 4,928 12-06-2015, 11:27 PM
Dernier message: Gurvan
  Automate : mauvaise évaluation de la condition fredblabla 2 4,943 09-15-2014, 08:50 AM
Dernier message: Julien
  Problème déclencheur avec condition sur le jour de la semaine buildy 1 4,350 04-14-2014, 02:42 PM
Dernier message: Julien
  Condition: créer une plage horaire AucuneID 9 12,328 01-25-2014, 10:27 PM
Dernier message: laurent
  Automate - Créer la condition "Si le soleil est levé, true" melck 4 7,633 09-23-2013, 07:00 PM
Dernier message: CS Domotic
  Condition : plage horaire coyotus 4 7,050 07-22-2013, 04:29 PM
Dernier message: Julien



Utilisateur(s) parcourant ce sujet : 1 visiteur(s)