Erreur MySQL "Data too long"

[nerixs]

Bonjour,

J’ai l’erreur suivante qui revient régulièrement:

[MySQL] Error code:22001 (1406). Data too long for column ‹ value › at row1: REPLACE INTO history SET cmd_id=:cmd_id,‹ datetime ›=:datetime, value=:value

Sur le lien suivant:

Jeedom V4 monitoring NAS

Merci pour tes indications. J’ai réglé le problème mais en modifiant le code du plugin. C’est pas top. Donc effectivement si on pouvait revenir à la situation initiale ça éviterait de perdre du temps. Encore merci pour ton aide

Il semblerait que ce soit un paramètre par défaut sur la version de mysql sous buster qui est plus strict.

Voir: STRICT_TRANS_TABLES

Sur cet autre lien:

Probléme Melcloud Lunarok

Name cmd. L’erreur est pas sur le nom de l’équipement mais sur une commande. Toutes les commandes créés par défaut sont ok en longueur. Donc soit tu as toujours le problème de corruption (car au lieu de repartir avec une sauvegarde saine tu aurais injecter celle déjà corrompue) Soit tu as renommer une/des clés Mais le plugin n’y est pour rien

Il est fait allusion à un problème de taille de nom de commande (Max 45) qui est présent sur tout plugin

Je ne sais pas trop comment diagnostiquer la cause.

Pourriez-vous me conseiller / guider?

Bien cordialement

[Loic]

Bonjour
Le soucis est corrigé en v4

[nerixs]

Bonjour,
Je suis en v4 depuis le début (environs 2 mois).

[Loic]

Remet a jour alors et fait une verification de la base de données

[Loic]

a mais c’est pas dans cmd mais dans history value ben la faut voir avec le dev du plugin pk il a besoin d’un truc aussi long

[nerixs]

Je suis novice en la matière, avant d’aller plus loin au niveau dev.

Ce nom trop long, est un nom que j’aurais défini?

[Loic]

Non c’est la valeur d’une commande historisée

[nerixs]

Merci pour cette info,

Ya-t-il un moyen de récupérer « simplement » le nom de cette commande?

Si je ne fais pas fausse route, d’après ma capture, ce n’est pas un widget qui pose problème, mais une commande de script.

[jpty]

Si votre commande est le résultat de l’interrogation du serveur Viessmann, la valeur en json fait 300ko.
Inutile d’historiser, ça change chaque minute.

[nerixs]

Bonjour jpty,

Merci d’intervenir dans cette discussion.

Pourriez-vous détailler un peu la requête?

En utilisant par exemple le php « GetAllInformationLocalJeedom » d’origine sans modification autre que les ID virtuelles cela passe par les valeurs json?

[jpty]

Dans le fichier example/GetAllInformationLocalJeedom.php de l’API de @thetrueavatar , vous avez un exemple de la façon de procéder pour faire une seule requête au serveur Viessmann et en extraire toutes les informations contenues.
L’exemple contient l’extraction de la temperature du bruleur, de la temp extérieure et du mode de fonctionnement.

Tout est dans le json. Il faut juste ne pas historiser le résultat de l’exécution du script.

[nerixs]

Oui, c’est bien ça.

Je m’étonnais d’avoir ce message d’erreur MySQL seulement avec une requête toutes les 5 minutes sur seulement 3 extractions.

[nerixs]

Pensez-vous qu’il soit possible de descendre à une requête toutes les 2 minutes sans risquer le ban vu que tout est récupéré en une fois?

[jpty]

Si vous avez mis dans credentials.properties, les installationID et gatewayID , oui c’est possible.
Si vous n’envoyez pas de commandes à la chaudière, c’est même possible de le faire chaque minute.
(1440 requêtes sur les 1450 autorisées par 24h)
Si bien sûr, vous ne vous connectez pas avec Vicare.

[Jeandhom]

@jpty

Tout est dans le json. Il faut juste ne pas historiser le résultat de l’exécution du script.

Il y a une réelle régression.
Depuis mon passage de stretch vers buster, je ne peux plus affecter à une commande info non historisée un JSON de plus de 127 caractères.
Jeedom 4.0.56