Forum Domoticz en français

Bonjour à tous,

pour pouvoir profiter de nouvelles fonctionnalités (plugin zibgeefordomoticz entre autres), je viens de faire une grosse migration :
buster -> bulseye (et donc python3.9)
domoticz 2022.1 (de mémoire) vers 2023.2

Et depuis, j'ai des soucis avec les quelques plugins que j'ai développés : en python, tous à base de mqtt (je me suis inspiré du ShellyMQTT.

Tout fonctionnait très bien avant cette migration, mais maintenant mes plugins plantent au démarrage avec l'erreur : J'essaie de trouver la cause, mais si quelqu'un voit une solution évidente, je suis preneur.

Merci d'avance pour votre aide

Quand tu parles de migration, tu as fait un update de buster vers bullseye ou tu as fait une réinstallation ?

J'ai fait une migration (update de buster vers bullseye et pas réinstall), en mettant à jour la liste des paquets, et en faisant les update/upgrade. J'ai cherché et suivi ce qui semblait être la bonne façon de faire, et ça a l'air de marcher à peu près.

Reste qu'il y a peut-être des soucis au niveau de l'install python (même si domoticz semble utiliser la version 3.9.2 qui est celle du système.

Update : j'ai essayé de voir s'il y avait des incohérences entre versions 32 et 64bits

"getconf LONG_BIT" renvoie 32 : bullseye semble être en 32bits
"file domoticz" renvoie ELF 32-bit LSBexecutable
"file python3.9" aussi

A priori, tout est bien en 32bits.

Salut,
Sans doute un problème de compatibilité entre les versions de python.
Par contre, sans le code, difficile d'aider.
J'ai quelques plugins MQTT aussi qui tournent

Je vais faire des tests, écrire un plugin "bateau" avec presque rien pour voir si le problème est reproductible (compatibilité versions de python...) ou lié aux plugins déjà présents (caches, fichiers pré-compilés, ...).

J'ai plus ou moins réussi à identifier l'endroit où survient le problème : c'est l'objet "Domoticz.Connection" dont je me sers pour le MQTT. La création fonctionne, mais l'appel à la méthode Connect fait planter le plugin.
Pour info, ce fichier "mqtt.py" se retrouve dans de nombreux plugins utilisant un client mqtt, et je l'ai repris à l'identique.

Si je commente cet appel (plus de MQTT), le plugin fonctionne correctement (mais sans MQTT, forcément). J'utilise les notifications pour communiquer en interne dans domoticz, et cette partie fonctionne sans problème.

C'est donc la connexion qui plante. Ca me fait une belle jambe : je sais où est le problème, mais je ne sais toujours pas comment le régler.

J'y retourne.

Nouveaux tests : j'ai remplacé la connexion MQTT par une connexion HTTP, même problème au moment de se connecter (connect pour le MQTT, listen pour le HTTP).

J'ai trouvé ici, sur le forum anglais, une personne qui avait un problème similaire, il a recompilé domoticz pour afficher les erreurs python.

Je pense que je vais finir par faire ça. A suivre.

Après recompilation, j'ai un peu plus de messages d'erreur : suivi d'une 'UnicodeDecodeError'. Ca ne m'avance pas beaucoup plus.

AchilleTalon a écrit : 08 oct. 2023, 22:29 j'ai essayé de voir s'il y avait des incohérences entre versions 32 et 64bits

Niveau OS, la commande uname -a dira si de ce côté on est en 32 ou 64 (Bullseye 64bit/aarch64 sur mon PI3B depuis une réinstall complète au passage de la 2022.2 en fin d'année dernière): De toutes manières, je n'ai pas connaissance sur ARM d'un paquet multiarch (anciennement ia32-libs) qui comme sur Intel permettrait de lancer un applicatif compilé 32 bits sur un OS 64bits. AMHA, il serait impossible de lancer domoticz si incohérence.

Maintenant, dans un contexte ou tout ou presque est passé en 64 bits, à mon sens rester trop longtemps en 32 risque de faire de plus en plus souvent sur des problèmes propres à une compilation 32 bits (de manière similaire à tous ces cast de pointeurs mal pensés que l'on s'est pris dans la figure, à l’exécution, sur les portages 32->64 ces 15/20 dernières années), qui se retrouvent de moins en moins testés (voir testables un jour, cf la suite).

C'est une des raisons pour lesquelles j'avais fait le saut quelques mois après que Raspberry ait enfin proposé une version 64 bits de leur distribution, 6 ans après le premier PI (le 3) compatible...

Puis ARM avait de ce point de vue très mal pensé son jeu d'instruction 32 bits (contrairement aux architectures PowerPC ou à part la taille des registres internes, peu de choses avaient changé) et a en conséquence du en faire un totalement nouveau: A un moment, cela va faire un peu tâche pour une architecture visant l'efficacité énergétique de traîner dans son silicium généralement 3 jeux d'instruction: 32bit, Thumb (un jeu 32 bit avec taille d'instruction variable et non fixe, permettant un code compilé plus petit mais imposant un décodage plus complexe) et 64bit. Et encore, Jazelle (visant à exécuter nativement du bytecode Java, au coeur de l'écosystème applicatif Androïd) était tombé en désuétude vu que Google (qui a évité le piège de se lier pieds et poings à ARM) n'a pas utilisé cette possibilité d'accélérer sa machine virtuelle Java. Sinon cela aurait fait 4!

Probable qu'un de ces jours un grand ménage ait lieu pour ne conserver que le 64 bits...

C'est bien ce que je me dis, mélanger du 32bits et du 64bits, ça va forcément générer des soucis. Tout est pourtant bien en 32bits. Il doit rester un morceau de machin quelque part, difficile de trouver ce dont il s'agit.

Du coup, en parallèle j'ai recommencé en partant de zéro. Bookworm est trop frais (encore des soucis notamment avec VNC), donc je suis parti sur une install Bullseye toute fraiche.

D'autres soucis (pas mal de soucis en fait), mais au moins mon installation python est propre et les plugins fonctionnent.