Régression depuis migration de stretch vers buster sur les commandes infos non historisées de plus de 127 caractères

Utilisation du core de Jeedom
1

Bonjour,

J’ai migré de stretch vers buster sous jeedom 4.0.54.

Depuis les JSON de plus de 127 caractères génèrent des erreurs lors de leurs affectations aux commandes infos.

[WARNING] : exception thrown by MQTT client: [MySQL] Error code : 22001 (1406). Data too long for column 'value' at row 1  : REPLACE INTO history SET cmd_id=:cmd_id, datetime`=:datetime, value=:value

Ce sujet serait déjà connu et aurait déjà été évoqué dans la partie du forum non accessible au commun des mortels (version de mariadb plus restrictive dans buster).

Les versions 4.0.56 et 4.0.57 de jeedom n’ont apporté aucune résolution de ce bug.

Je souhaiterai savoir à partir de quelle version de Jeedom, ce bug sera résolu.

2

Bonjour,
Ce n’est pas un bug il ne faut pas historiser des commandes de type string qui ont des valeurs de plus de 127 caracteres.

On a pas prévu de changer cette limite (ca poserai trop de soucis sur rpi ou machine de ce type)

3

Comme indiqué dans le titre de ce sujet, la commande info est non historisée.

4

L’erreur est dans la table history donc elle est ou a forcement été un jour historisée.

5

Je viens de créer une nouvelle commande info non historisée et même résultat.

Cela fonctionnait très bien sous stretch.

6

Le résultat arrive la nuit donc je comprends pas comment tu peux dire que c’est le meme

7

L’erreur se produit à chaque fois que mosquitto envoi le JSON de plus de 127 caractères au #plugin-jmqtt.

[2020-06-16 17:49:09][WARNING] : exception thrown by MQTT client: [MySQL] Error code : 22001 (1406). Data too long for column 'value' at row 1  : REPLACE INTO history 						SET cmd_id=:cmd_id, 						`datetime`=:datetime,
8

C’est que tu as une commande historisée trop longue sinon il n’y aurait pas d’êrreur

9

Il n’y a pas de commande historisée.

Cela fonctionnait très bien sous stretch en 4.0.54, les JSON de plus de 127 caractères ne généraient pas d’erreur.
Le fonctionnement n’étant plus le même sous buster en 4.0.54. Je ne peux que constater cette régression.
Si j’ai bien compris, le problème viendrait que mariadb sous stretch tronquait les chaînes trop grandes alors que sous buster, mariadb génère une erreur.
Est-ce spécifique au #plugin-jmqtt ? (@domotruc).

10

C’est bien ca mais le soucis de base est forcement une commande qui est historisé (pas le choix sinon ca charge meme pas la class php history donc la table history) qui est trop longue.

11

Toutes mes cases « historiser » sont bien décochées.
Donc, il n’y a aucune amélioration que je puisse faire à mon niveau.

Je vais donc attendre pour voir si d’autres utilisateurs reproduisent ce problème.

12

Je viens de créer une commande info historisée avec le #plugin-virtual.
Avec un bloc action dans un scénario via « event », j’ai modifié plusieurs fois la valeur de la commande info avec des chaînes alphanumériques de moins de 127c et de plus de 127c.
Toutes les valeurs s’affichent bien sur le dashboard.
Aucune erreur n’a été retournée.
Après examen de la table history, il apparaît que les valeurs de plus de 127c n’ont pas été enregistrées dans cette table.
J’en déduis que le #plugin-virtual gère le débordement (overflow) en éliminant ces valeurs.
Il conviendrait de prévenir tous les développeurs qu’ils doivent gérer dans leurs plugins les débordements.
Une manière plus simple serait que le core le gère directement.

13

Le plugin virtuel ne gère absolument rien la dessus il n’est de toute façon pas possible que les plugin fasse quoique ce soit la dessus sinon on aurait bien évidemment prévenu les développeurs en l’indiquant dans la doc

14

Faudrait p-e viser plus haut que le rpi ou arm :stuck_out_tongue:

15

Donc, c’est le core qui gère le débordement lorsqu’il vient du #plugin-virtual et qui ne le gère pas lorsqu’il vient du #plugin-jmqtt ? :thinking:

J’aimerai bien comprendre.

16

Je ne pense pas qu’il y ait un grand intérêt d’historiser des grandes chaînes alphanumériques surtout si c’est des chaînes JSON. Autant extraire et historiser du JSON ce qui est strictement nécessaire.

17

Globalement (j’ai profité du topic pour le dire) . Je transfèrerait bien vers Jeedom (Homeseer), si l’équipe ne se limitait pas à la puissance arm dans leur décisions.

18

Non les deux sont géré pareil il n’y a aucun traitement spécifique en fonction du plugin

@MattL0 jeedom tourne très bien sûr du x64 c’est ma config depuis 5ans

19

A te lire, je comprends que tu ne souhaites pas intervenir pour traiter cette régression du au changement de comportement de mariadb depuis buster.

Pourtant, un simple substr($value,0,127); placé au bon endroit dans le core devrait résoudre cette régression ???

20

Relis mon premier message il n’y a pas de régression juste une erreur masqué qui ne l’est plus. Oui un substr est simple mais dans ce cas ca induit un comportement non attendu l’utilisateur pensera historiser la chaine complete alors que c’est pas le cas il faut donc bien laisser le message d’alerte comme quoi il y a eu un soucis lors de l’historisation

Tu as toute les informations dans le poste je ne peux rien ajouter de plus maintenant.