MQTT : taille maximale d'une valeur reçue?

Cartes Ethernet IPX800
1

Bonjour à tous, je suis nouveau sur ce forum et je débute avec une IPX800V5 (j’ai déjà joué avec une IPX800V3 il y a quelques années).
J’essai de récupérer des informations en MQTT d’une tête thermostatique MOES avec l’aide de zigbee2mqtt. J’ai suivi les différents tutoriels (merci beaucoup aux auteurs) et tout fonctionne sauf un point. Après avoir fait plusieurs tests, je me suis apercu qu’une valeur très longue telle que:

"programming_mode": "06:00/20°C  11:30/21°C  13:30/22°C  17:30/23°C  06:00/24°C  12:00/23°C  14:30/22°C  17:30/21°C  06:00/19°C  12:30/20°C  14:30/21°C  18:30/20°C"

empêche l’enregistrement des toutes les données du message. Cette valeur rentre théoriquement dans un STR256 donc ce n’est pas un problème de variable. Le plus embêtant c’est que toutes les autres clés et valeurs incluse dans le message sont ignorées…

Est-ce que quelqu’un a déjà eu ce problème, y a t’il une solution ?

Merci d’avance !

2

Bonsoir @Seb12 et bienvenue sur le forum,

Intéressant votre cas d’utilisation! Cela va donner des idées!

l’exemple que vous proposez comporte 164 caractères (espaces et " compris) donc oui cela peut rentrer ds une STR256 ou STR512.
Pour la recueillir ds une topic SUB, je ferai:

image
image756×388 23 KB

Je me pose néanmoins la question de l’exploitation ds la V5 d’une telle donnée… Je pense que cela aurait plus de sens ds un datalogger sur un NAS à coté qui pourrait tracer des courbes de variation de température en cours de journée et faire tout un tas de stat sur les valeurs en journées.

3

Bonjour @Jweb,

C’est exactement ce que j’ai fait mais ça ne fonctionne pas (ça fonctionne sur d’autres données).
Mon plus gros problème c’est que la vanne envoi toutes ses données dans un seul message contenant une dizaine de clés. Et cette clé qui contient ce long message m’empêche de récupérer toutes les autres. J’ai reproduit l’erreur en créant un message contenant plusieurs clés, si une clé contient un texte suffisamment long, l’IPX semble ignorer le message complet …

Je souhaite récupérer des données pour vérifier que la vanne à bien appliqué les commandes que j’ai envoyé auparavant, et aussi pour récupérer des modifications qui auraient été appliquée manuellement sur la vanne. Ce n’est pas du dataloging.

Pour plus de précision, voilà le message complet recu:

"battery": 91,
"boost_heating": "OFF",
"boost_heating_countdown": 4,
"boost_heating_countdown_time_set": 300,
"child_lock": "UNLOCK",
"current_heating_setpoint": 21,
"eco_mode": "OFF",
"eco_temperature": 5,
"last_seen": "2021-11-18T08:32:01.314Z",
"linkquality": 87,
"local_temperature": 20,
"local_temperature_calibration": -2,
"max_temperature": 25,
"min_temperature": 5,
"position": 25,
"preset": "manual",
"programming_mode": "06:00/23°C  11:30/21°C  13:30/22°C  17:30/23°C  06:00/24°C  12:00/23°C  14:30/22°C  17:30/21°C  06:00/19°C  12:30/20°C  14:30/21°C  18:30/20°C",
"window": "CLOSED",
"window_detection": "OFF",
"update_available": null

Le meme message généré manuellement sans la ligne « programming_mode » (ou en la raccourcissant) est bien géré par l’IPX. Mais ce message complet n’est pas géré, impossible de récupéré la clé « current_heating_setpoint » par exemple.

4

Essayez un topic SUB avec uniquement 4 variables (ou moins) que vous souhaitez récupérer, avez vous un message d’erreur ?

5

Essayez vers un str256 puis manuellement avec le « porgramming_mode » avec une chaine vide et augmenter pour voir a partir de quelle taille ou valeur cela plante

6

J’ai déjà fait ces 2 tests. Dans tous les cas je n’ai pas de message d’erreur (ou alors je ne sais pas où le chercher), simplement les données ne sont pas récupérées.

Pour la longueur maximale ce n’est pas bien clair. Je suis quasiment sûr d’avoir fait un test positif avec la moitié de la chaîne de caractères récalcitrante mais ensuite impossible de le répéter. Par contre avec « 06:00/23°C 11:30/21°C » cela fonctionne systématiquement.

7

Bonjour @Seb12
Avez-vous la possibilité d’avoir un topic moins fourni en terme de paramètres ?
Vos retours me font penser que le topic est trop fourni et la v5 ne peut pas le recevoir car trop grand et comme il n est pas complet alors la v5 ne peut pas l interpréter car non proprement fini…

Je ne comprends pas ce que vous voulez dire

8

Ce n’est pas le nombre de paramètres qui pose problème :

  • J’ai fait des tests avec seulement 2 clés et le problème est le même dès qu’une valeur associée à une des clés est très grande
  • J’ai fait des test avec un grand nombre de paramètres mais sans valeur aussi longue et cela fonctionne

C’est peut-être la taille totale du message qui compte, je referai un test mais pour le moment tout mes essais concordent sur le fait que c’est cette valeur très longue qui est la seule responsable du mauvais fonctionnement.

La valeur « 06:00/23°C 11:30/21°C » est suffisant courte pour que l’IPX800 lise les messages.

9

Je viens de faire quelques tests:

Ce message fonctionne:

{
  "battery": 91,
  "boost_heating": "OFF",
  "boost_heating_countdown": 4,
  "boost_heating_countdown_time_set": 300,
  "child_lock": "UNLOCK",
  "current_heating_setpoint": 21,
  "eco_mode": "OFF",
  "eco_temperature": 5,
  "last_seen": "",
  "linkquality": 87,
  "local_temperature": 20,
  "local_temperature_calibration": -2,
  "max_temperature": 25,
  "min_temperature": 5,
  "position": 25,
  "preset": "manual",
  "programming_mode": "01234567890123",
  "window": "CLOSED",
  "window_detection": "OFF"
}

Ce message fonctionne (suppression du dernier paramètre)

{
  "battery": 91,
  "boost_heating": "OFF",
  "boost_heating_countdown": 4,
  "boost_heating_countdown_time_set": 300,
  "child_lock": "UNLOCK",
  "current_heating_setpoint": 23,
  "eco_mode": "OFF",
  "eco_temperature": 5,
  "last_seen": "",
  "linkquality": 87,
  "local_temperature": 20,
  "local_temperature_calibration": -2,
  "max_temperature": 25,
  "min_temperature": 5,
  "position": 25,
  "preset": "manual",
  "programming_mode": "0123456789012345678901234567890123456789012",
  "window": "CLOSED"
}

Ce message fonctionne (diminution de la longueur de la dernière valeur):

{
  "battery": 91,
  "boost_heating": "OFF",
  "boost_heating_countdown": 4,
  "boost_heating_countdown_time_set": 300,
  "child_lock": "UNLOCK",
  "current_heating_setpoint": 22,
  "eco_mode": "OFF",
  "eco_temperature": 5,
  "last_seen": "",
  "linkquality": 87,
  "local_temperature": 20,
  "local_temperature_calibration": -2,
  "max_temperature": 25,
  "min_temperature": 5,
  "position": 25,
  "preset": "manual",
  "programming_mode": "012345678901234567890123456789012345678901234567",
  "window": "C"
}

Mais si j’augmente la longueur de « programming_mode » de un caractère, ca ne marche plus.

Cela semble donc être lié à la taille totale du message et pas au nombre de paramètres ni à la taille d’une valeur.

10

Bonjour,
Pour info, dans vos exemples, il y a une constante : :face_with_monocle:la taille totale est limitée à 512 caractères si on enlève l’espace après le < : > qui est certainement ajouté par la couche présentation
On semble limité à la taille du string512 :straight_ruler:

11

Bien vu !

Bon ça ne m’arrange pas, il va falloir que je contourne ce problème. J’ai déjà des idées, je vous ferai part de la solution que j’ai retenu…

12

Pour discriminer « programming_mode » laissez le tel quel quand il fonctionne et augmentez « window » par exemple à « CD » cela vous permettra de voir si l’erreur se porte sur la totalité du message ou « programming_mode » seulement ! Mais comme dit @Michel94 c’est probablement le fait que vous soyez au taquet du str512 :wink:

13

C’est ce que j’ai fait entre les 2 derniers essais que j’ai publié en fait. Mais je n’ai pas publié chaque itération ^^
C’est bien la totalité du message qui pose problème.

Il va falloir que je réduise le message:

  • soit a la source (en me renseignant un peu plus sur le fonctionnement de zigbee2mqtt)
  • soit en recevant le message par ailleurs puis en le découpant et le renvoyant découpé (node red semble pouvoir faire ça)
14

Vous avez en fait 3 solutions

Si les 2 premières sont pas réalisables faire une demande d’évolution à @GCE pour des str1024 !
Mais avec node-red pas de souci c’est sur ! :wink:

15

Petit retour d’expérience (après presque un an…)
Au final j’ai vu que zigbee2mqtt inclu une fonction de filtre pour les messages. J’ai donc filtré la partie « programming_mode » et le message est lu par l’IPX…