c’est RPI3 B+
Bizarre, c’est bien un 64 bits, ça ne correspond pas avec ton widget « Mon système ».
Les raspbian sont en 32bits… (OK j’ai pas vérifier buster)
Buster aussi est en 32bits même sur un RPI4
Tu m’a fait peur 
Bon sinon je ne vois pas cette erreur interne 500 ! D’où elle peut venir !
Un widget de la V3 qui ne passe pas bien ?
Je n’avais pas remarqué ça sur ma version de test.
Je vais passer les éléments un à un en invisible pour voir si cela change quelques choses. Je sens l’opération longue.
Sinon ce matin les volets ce sont levés comme il faut à l’heure, le mail des poubelles est bien partie aussi
Hello,
Tout comme toi j’ai fait ma migration vers la v4 il y a plusieurs mois, sauf que j’ai décidé de repartir à zéro suite à une migration v3 vers v4 décevante, certain truc ne fonctionnait plus comme je le voulais, l’avantage c’est que j’avais un rpi d’avance donc j’ai repasser mon serveur de prod en v3 et en parallèle j’ai monter un nouveau serveur sous buster en v4 et refaire tout depuis zéro, c’est fastidieux mais cela permet de voir rapidement ce qui est compatible ou pas, ce qui fonctionne ou pas.
Oui je comprends bien mais ce qui m’agace à faire c’est pas de repartir à zéro c’est de refaire le réseau zigbee avec mes volets Profalux c’est chiant à faire avec du câblage électrique à inverser.
Si j’avais une solution pour garder les inclusions zigbee dans ma clé ZiGate je le ferais certainement.
@kiboost a déjà suggéré (et je pense la même chose), un plugin (ou un widget) qui fait un appel vers object.ajax.php.
Si un plugin, je parie sur kikasa, livebox, netatmopro, sigri linky ou zigate (parce que je ne les connais pas alors que je suis certain que les autres sont compatibles)
tu peux chercher un fichier dans ton répertoir /var/www/html qui contiendrait cette chaine.
un truc du genre devrait faire l’affaire (je n’ai pas testé, juste tapé cela à l’instant)
cd /var/www/html/; grep -R "object.ajax.php" *
Par la même occasion tu peux trouver les (autres) plugins qui ne seraient pas compatibles:
cd /var/www/html/plugins; grep -R "object::" *
Oui je comprend, je ne possède pas encore de volets électrique mais j’ai cru comprendre en lisant un peu partout qu’avec les Profalux c’était chiant.
Sinon chez un ami qui a rejoint Jeedom il y a peu au départ nous avions choisi le plugin Zigate que nous avons finalement abandonné pour Abeille car trop de problème de perte d’équipement, de stabilité, etc.
Autrement comme le signal @Mips et @kiboost regarde si tous les plugins que tu utilise sont bien compatible v4.
Ah, ok, c’est l’OS qui est en 32 bits.
Y a-t-il une raison pour que Raspbian n’exploite pas le processeur 64 bits ?
Je dirais plutôt: y a-t-il une raison pour l’exploiter?
mais sinon les raisons:
- volonté de garder une seule distrib (plus simple pour l’utilisateur et la maintenance)
- retro-compatibilité total avec les premiers pi (on trouve ca bien ou pas mais faut avouer qu’avoir un pi première version et pouvoir encore installer un buster dessus, c’est pas tous les jours que l’on voit ca en IT)
- la charge de travail pour eux de migrer vers 64bits (ils sont une petite équipe apparemment) et la complexité de dialoguer avec le GPU qui est en 32bits si l’os est en 64bits (dixit eux, je ne l’invente pas et ne m’en demande pas plus)
mais on s’écarte du sujet initial
1 « J'aime »
Merci pour ce point de regard et merci @iPapy pour votre aide je lance les recherche dans ce sens ce soir et je vous tiens au courant.
J’ai rien vu venir sur mon RPI de test grrr vive la mise en production
Résultat de la recherche
cd /var/www/html/; grep -R "object.ajax.php" *
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
desktop/js/administration.js: url: "core/ajax/object.ajax.php",
desktop/js/object.js: url: 'core/ajax/object.ajax.php?action=uploadImage&id=' +_id +'&jeedom_token='+JEEDOM_AJAX_TOKEN,
et en faisant l’autre je trouve
cd /var/www/html/plugins
$ grep -R "object::" *
Monitoring/desktop/php/panel.php: $object = object::byId($_SESSION['user']->getOptions('defaultDashboardObject'));
Monitoring/desktop/php/panel.php: $object = object::byId(init('object_id'));
Monitoring/desktop/php/panel.php: $object = object::rootObject();
Monitoring/desktop/php/panel.php:$child_object = object::buildTree($object);
Monitoring/desktop/php/panel.php: $allObject = object::buildTree(null, true
J’ai toujours l’erreur qui est présente et je supprime ce dont je ne me sers plus.
Je regarde coté widget ce qu’il faut changer ou mettre à jour mais là je ne comprends pas tout
et maintenant j’ai ceci :
2020-01-29 20:00:37 jeedom Erreur curl sur : https://market.jeedom.com/core/api/api.php. Détail :Failed to connect to market.jeedom.com port 443: Connection timed out
Celle-la c’est rien on l’a tous de temps en temps.
il y a déjà des posts la dessus.
Ok d’accord
Je suis tellement au aguets sur les erreurs suite à ma migration que j’avoue n’avoir pas chercher celle ci en particulier.
C’est un truc de fou quand même je compare mon installation test et prod car elles tournent toutes les 2 en V4 à partir d’un sauvergarde V3 récente et je n’ai pas la même chose !
Je sens fort que je vais devoir refaire une installation de 0
L’os est t’il le même ?
Pour moi oui mais je vais contrôler cela évitera la certitude erronée
Je me permets de re-sortir ce topic, car il ne semble pas avoir trouvé de réponse, et j’ai moi aussi le problème depuis mon passage en V4 hier.
J’ai donc fait les deux commandes proposées plus haut, et j’obtiens une liste un peu plus longue que celle de jerome6994 :
Pour
cd /var/www/html/; grep -R "object.ajax.php" *
j’obtiens ça :
core/i18n/id_ID.json: "core\/ajax\/object.ajax.php": {
core/i18n/fr_FR.json: "core\/ajax\/object.ajax.php": {
core/i18n/en_US.json: "core\/ajax\/object.ajax.php": {
core/i18n/de_DE.json: "core\/ajax\/object.ajax.php": {
core/i18n/ja_JP.json: "core\/ajax\/object.ajax.php": {
core/i18n/ru_RU.json: "core\/ajax\/object.ajax.php": {
core/i18n/it_IT.json: "core\/ajax\/object.ajax.php": {
core/i18n/pt_PT.json: "core\/ajax\/object.ajax.php": {
core/i18n/es_ES.json: "core\/ajax\/object.ajax.php": {
core/i18n/tr.json: "core\/ajax\/object.ajax.php": {
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
core/js/object.class.js: paramsAJAX.url = 'core/ajax/object.ajax.php';
desktop/js/administration.js: url: "core/ajax/object.ajax.php",
desktop/js/object.js: url: 'core/ajax/object.ajax.php?action=uploadImage&id=' +_id +'&jeedom_token='+JEEDOM_AJAX_TOKEN,
Et pour
cd /var/www/html/plugins; grep -R "object::" *
j’obtiens ça :
Monitoring/desktop/php/panel.php: $object = object::byId($_SESSION['user']->getOptions('defaultDashboardObject'));
Monitoring/desktop/php/panel.php: $object = object::byId(init('object_id'));
Monitoring/desktop/php/panel.php: $object = object::rootObject();
Monitoring/desktop/php/panel.php:$child_object = object::buildTree($object);
Monitoring/desktop/php/panel.php: $allObject = object::buildTree(null, true);
nissan_leaf_connect/desktop/php/nissan_leaf_connect.php:foreach (object::all() as $object) {
pushbullet/desktop/php/pushbullet.php: foreach (object::all() as $object) {
Je vois que dans le second listing ça parle de Nissan Leaf Connect, qui bizarrement n’arrive plus à ré-installer ses dépendances depuis mon passage en V4 (mais qui donne néanmoins l’impression de fonctionner correctement, sans doute avec les restes de ce qu’il y avait dans la V3). Est-ce qu’il y aurait une méthode pour mettre en cause ou au contraire hors de cause ce plugin ?
J’ai remonté un autre topic hier à son sujet (NOK dans Santé), mais n’ai pas encore de nouvelles et si ça se trouve il y a peu de monde qui l’utilise, qui plus est en V4…
Salut,
As-tu vérifié que le plugin était compatible V4?
Apparemment non, il faut remplacer dans le code object pas jeeobject.
Alors j’ai creusé un peu par rapport à l’erreur de ce plugin, j’ai mis un commentaire ce matin là :
Et je vais compléter par une petite réponse de ce pas, parce que depuis ça a avancé un peu (installation des dépendances possibles, par contre le problème javascript n’a pas disparu, il se produit quand je vais sur les designs depuis le menu accueil. Par contre aucun problème quand je vais directement sur le design depuis mon téléphone par exemple.