Commande message() retourne une erreur SQL dans scénario

Bonjour à tous,

je rencontre un souci avec la commande/fonction « message » dans mes scénarios.
(C’est la fonction pour forcer un message Jeedom).

Je viens de m’apercevoir que cette commande retourne une erreur dans les log du scénario et ne s’execute pas.

Voici la ligne de l’erreur SQL :

[2024-02-05 20:14:21][SCENARIO] [MySQL] Error code : 22001 (1406). Data too long for column ‹ logicalId › at row 1 : INSERT INTO message SET id = :id, date = :date, logicalId = :logicalId, plugin = :plugin, message = :message, action = :action, occurrences = :occurrences

L’erreur se produit et le message ne se lance pas quelque que soit le scénario utilisé.

Voici mon de test (on ne peut plus simple):
Si je met « popup » à la place de message le popup fonctionne.
C’est vraiment la fonction message qui génère l’erreur et qui ne s’execute pas.

J’ai bien effectué toutes les étapes de vérification correction du système

Cependant il persiste une erreur dans la table « cmd » malgré bouton corriger plusieurs fois.
Pourtant le status est indiqué comme OK.

logicalID ALTER TABLE cmd DROP INDEX logicalID; CREATE INDEX logicalID ON cmd (logicalId ASC);

Pourriez-vous me venir en aide afin de comprendre la source de cette erreur et rétablir le fonctionnement message dans les scénario ([MySQL] Error code : 22001 (1406)… voir plus haut) ?

Merci à tous

ps : version 4.4.2 depuis 2 jours

Bonjour
Il serait bien de préciser la version du core pour avoir de l’aide

Bonjour,
merci pour l’info, je suis passé en version 4.4.2 depuis 2 jours :crazy_face:.

Donc je demande juste ici je fais pas de ticket Jeedom (pas de support officiel en beta).

Merci à tous.

Au vu de ce que tu décris c’est un pb core pas un souci de scénario.

ok c’est vrai!
Merci pour la modification

Je ne reproduis pas

Ni en beta ni en alpha.

Je suis pas sur que ce soit pas ta bdd qui aie pris une coup !

Merci pour le test et le retour.

En effet j’irai bien explorer et comparer la base de données.

Sauriez-vous comment je pourrais explorer la base de données à la manière de phpmyadmin plutôt qu’avec la page web jeedom ?

avec adminer

Super simple apparemment, merci.

Sinon tu peux déja utiliser la fonction « DESCRIBE matable » sur l’admin SQL de jeedom si tu veux comparer la structure de ta table.

Après effectivement adminer fonctionne très bien :wink:

Top je fais aller voir ca.

Pour info j’ai refais un passage de 4.3.22 à 4.4.2 (à l’aide de VM) et résultat :

  • l’erreur vérification de base de données apparait suite à la mise à jour 4.4.2
  • par contre les messages fonctionne juste après la mise à jour.

J’ai donc deux souci qui sont peut-être lié ou pas :crazy_face:
-1) Erreur vérification de base qui apparait suite à la mise a jour et dont j’ai des traces aussi dans les logs de mise a jour du Core.

-2) Erreur fonction message qui est encore à creuser…

Je vais voir avec vos conseils et outils.

Merci

1 « J'aime »

Bizarrement les messages marche dans ce scénario test :

Mais pas dans mon scénario original

La je sèche, c’est surement dans le core en effet ou dans la base suite au passage en 4.4.2…

Je ne comprends pas comment est constitué le [logicalId] qui apparait dans la table message pour un scénario.
Autant pour une commande, cette info existe nativement mais sauf erreur de ma part ça n’existe pas pour un scénario, à voir comment le core le crée et si ça à changé en 4.4

Bon ne cherchez plus et merci pour avoir repondu.

J’ai simplement renommer le scénario et la fonction message re-fonctionne!:partying_face:

Oui juste raccourcie le nom puis testé le message qui à fonctionné puis j’ai remis le nom d’avant et sa fonctionne toujours.

Quand j’ai relu le message d’erreur qui disait « Too long », j’ai pensé au nom de mon scénario (Garage : Interrupteur Double) puis j’ai fait la manip expliqué au dessus.

Incroyable quand même.

Par contre j’ai toujours l’affichage d’une erreur dans la vérification de la base de données :
(Je vais surement ouvrir un autre sujet dédié à cette erreur)

Hello,

Ce n’est pas « résolu », c’est juste « planqué »…

Donne nous le nom du scénario avant et après modif, il y a peut être un caractère ou la taille qui coince, ça ne devrait pas générer d’erreur.

Et tu as encore un message d’erreur, as-tu essayé de cliquer sur corriger ?

Bad

Hello,

oui toujours l’erreur affiché dans la page vérification de base de données et CORRIGER ne change rien :

Pourtant l’index existe dans la base de données :


Et quand je supprime l’index et que je fais Réparer tous, l’index est bien re-créé mais j’ai toujours l’erreur d’affichée

D’ailleurs quand je fais une vérification générale j’ai des logs qui parle de cet Index.

[START CONSISTENCY]
[START CHECK AND FIX DB]
Fix : ALTER TABLE `cmd` DROP INDEX `logicalID`;
Fix :
CREATE INDEX `logicalID` ON `cmd` (`logicalId` ASC)[END CHECK AND FIX DB]
Check jeedom package...
OK
Check jeedom database...
Fix : ALTER TABLE `cmd` DROP INDEX `logicalID`;
Fix :
CREATE INDEX `logicalID` ON `cmd` (`logicalId` ASC)OK
Check crons...
Check filesystem right...
OK
Flush cache widget...
Check jeedom object...
OK
Check jeedom cmd...OK
Set cache hour...OK
Check composer...OK
Check nodejs...
Hit:1 http://security.debian.org/debian-security bullseye-security InRelease
Hit:2 http://deb.debian.org/debian bullseye InRelease
Get:3 http://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Hit:4 https://deb.nodesource.com/node_18.x nodistro InRelease
Fetched 44.1 kB in 1s (31.1 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
apt-utils is already the newest version (2.2.4).
build-essential is already the newest version (12.9).
git is already the newest version (1:2.30.2-1+deb11u2).
lsb-release is already the newest version (11.1.0).
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
[Check Version NodeJS actuelle : v18.19.0 : [  OK  ]
[Check Prefix : /usr and sudo prefix : /usr and www-data prefix : /usr : [  OK  ]
OK
[END CONSISTENCY]

artworks-000263873957-4xy7f3-t500x500

Hello,

Et peux-tu faire aussi des captures complètes des scenario qui marchent et ne marche pas ?
Ainsi que les logs où tu vois d’autres choses ?

Bad

Bonjour,
Le soucis vient du calcul du champs logicalId qui donne quelques chose de trop long. Je ne sais pas trop pourquoi tu as ca, aucune raison que le champs soit trop long d’un coup (le calcul est toujours le meme) peut etre qu’avant la db laissait passer et plus maintenant.

Dans tous les cas j’ai poussé un truc en alpha ca devrait corriger le soucis.

1 « J'aime »