M2M trame tronqué 3.05.59

Bonjour,

Ma config est la suivante
send data on status change est coché

Sur le push
[attachment]13-06-2015%2019-49-52.jpg[/attachment]

Le contexte:
Un compteur d’eau incrémente le compteur 1

Lorsque je ferme le relais 9
L’IPX envoie une trame a chaque fois qu’il reçois une impulsion ou que le compteur s’incrémente (c’est normal)

Par contre des que j’ouvre le relais 9
L’IPX me tronque la trame en cours et y rajoute la suivante (la c’est pas normal)

Ici la trame est tronqué puis mélangé a la suivante

Pour info en me servant de tcp Client j’arrive au meme résultat (mais pas tout le temps ca doit dépendre du moment ou on envoie l’ordre)

En piece jointe le log complet
Fermeture du relais 9
Ouverture du relais 9
ca a marché la premiere fois normalement
Fermeture du relais 9
Ouverture du relais 9
La trame est tronqué

est ce moi qui ai merdé quelque part ou un beug?
Merci de m’avoir lu.

Gilles

log.txt (12.1 KB)

Voici un élément pouvant aider dans la recherche de solution.
Je m’oriente plus vers un « beug » ou une saturation de la mémoire de la version 3.05.59d

Avec « Send data on status change » de coché

Aucune action extérieur sur l’IPX

Je log les trames envoyé par l’ipx avec tcp client

Essai 1:
Je met en marche mon arrosage
Le compteur 1 tourne
de temps en temps je recois une trame tronqué

Essai2:
Arrosage arrêté
Je click sur l’interface web l’entré du compteur 1
l’IPX me renvoie deux trames
la premiere disant que l’entrée est passé a 1
la deuxieme qu’elle est passé a zero (normal elle est cablé sur zero)
je click plusieurs fois le compteur s’incremente mais l’IPx loupe des trames (il n’envoie rien)
puis envoie une bonne trame suivi d’une trame tronqué

Essai3:
Arrosage en marche
Compteur1 tourne
je clique plusieurs fois sur l’entré 2 (rien n’est branché dessus)
Les trames tronquée arrive plus souvent

Je reste à disposition s’il faut faire d’autre test, ou donner d’autres explications.

Merci
Gilles

Bonjour,

Ce bug nous a déjà été signalé et nous travaillons sur un correctif que nous appliquerons sur la prochaine maj.
Par contre il est normal que l’ipx800 n’envoi pas de push sur des actions trop rapides.
En effet nous avons mis un délai de 200ms entre 2 pushs donc si une entrée commute trop vite le push ne part pas…

Cdt

Bonjour,

Merci de votre réponse.
Je n’utilise pas le push,
J’ouvre une socket en M2M et récupère les infos directement à chaque changement.
Du coup en attendant la prochaine mise a jour, je tri les trames afin d’éliminer les tronquées.

Je suis disponible si vous avez besoin de faire des tests.
Cdt

J’ai effectivement signalé le problème il y a quelque temps.

J’ai moi aussi contourné le problème avec un « hack » dans le code qui permet de traiter les trames incomplètes (pour info : https://github.com/seebag/openhab/blob/ipx800/bundles/binding/org.openhab.binding.ipx800/src/main/java/org/openhab/binding/ipx800/internal/Ipx800DeviceConnector.java#L29:sunglasses:.

Le délai de 200ms est il valable aussi lorsque l’on est en TCP M2M ?
Côté client, je gère des actions de type double appui sur un bouton poussoir (double clic). Je me demande si ce délai ne peux pas faire « perdre » des évenements (je n’ai pour l’instant rien observé de tel).

J’attends la mise à jour avec impatience !