[ERROR] Model invalide > undefined

battousai90 · Novembre 8, 2020, 11:56

Résultats des tests suivants avec la pièces Entrée qui est la source des problèmes.
Cette pièce a trois périphérique, un détecteur d’ouverture Porte d’entrée, un ampoule porte d’entrée et une ampoule Hall d’entrée.
Sortie des trois périphériques de la pièce depuis abeille et mis dans aucun, activation de la pièce Entrée dans Homebridge = OK
Placement du détecteur d’ouverture dans la pièce Entrée = KO invalid model
Placement d’une ampoule = KO invalid model

Ce qui est bizarre dans d’autres pièces les détecteur fonctionne et les ampoule aussi.
Pour l’accès au Jeedom je ne sais pas trop comment on fait ca.

nebz · Novembre 8, 2020, 12:06

Tu ajoutes un utilisateur et tu me donnes ton url externe ou bien si tu me fais pas super confiance (et je ne t’en voudrai pas) via teamviewer sur ton ordi pour contrôler ce que je fais, mais d’ici 1h si tu veux bien, je vais seulement manger

nebz · Novembre 8, 2020, 2:21

j’ai trouvé

ton équipement 227 (Lumière Hall ENT), la commande « nom » elle bug…

@kiwihc16 hello, il semble y avoir un problème chez lui… sur la commande nom :

c’est pour une ampoule ikea :

mon plugin homebridge utilise la methode du core : $cmd->exportApi() que tu peux consulter ici :

github.com

jeedom/core/blob/alpha/core/class/cmd.class.php#L2211


      
          				'cmd' => $cmdname,
          				'cmdId' => $this->getId(),
          				'cmdname' => $this->getName(),
          				'genericType' => $genericName
          			);
          			$valueArray = [];
          			if ($valName != '') {
          				$valueArray[$valName] = $value;
          				$value = null;
          			}
          			if ($_timestamp == '') {
          				$point = new InfluxDB\Point($cleanName, $value, $tagArray, $valueArray);
          			} else {
          				$point = new InfluxDB\Point($cleanName, $value, $tagArray, $valueArray, $_timestamp);
          			}
          			log::add('cmd', 'debug', 'Push influx for ' . $this->getHumanName() . ' : ' .  json_encode($tagArray, true));
          		} catch (Exception $e) {
          			log::add('cmd', 'error', __('Erreur computing influx sur :', __FILE__) . ' ' . ' commande : ' . $this->getHumanName() . ' => ' . $e->getMessage());
          		}
          		return $point;
          	}

la première partie fonctionne bien (le o2a), par contre ici on a une commande de type info, donc après il fait un execCmd sur la commande, qui est sensé donner la valeur de la commande en cache et là ca plante complet… j’ai pas de log, mais pas de résultat.

ca peut être confirmé directement dans la liste des commandes en appuyant sur « Tester » aucun bandeau qui s’affiche avec la valeur de la commande.

j’arrive à reproduire le même problème chez lui sur tous les éléments abeille… pas moyen de recevoir la valeur dans la liste des commandes.

tu as une idée ?

kiwihc16 · Novembre 9, 2020, 7:17

Salut,
La commande nom est créée par defaut lors de la création de l objet. Elle est initialisée plus tard quand on recoit l’information.
On peut faire plusieurs tests:
1 - Supprimer juste la commande nom et voir si Homebridge est content. (On peut supprimer dans Abeille la commande nom, elle n est la que pour info pour l utilisateur).
2 - Envoyer un nom à la commande et voir ensuite si HomeBridge est ok avec.
3 - Faire la création d’un objet vide et voir comment cela ca se passe (Je vais essayer de faire ce test)

Est ce que Homebridge a besoin de cette commande ? Je suppose qu’elle a un type generique NULL pour qu’elle ne soit pas prise en compte par homebridge. Est ce bien le cas ?

nebz · Novembre 9, 2020, 7:43

Il a fait le test et ça fonctionne

Non pas besoin, mais lors de la sérialisation des commandes avec exportApi (avant donc de consulter son type générique) ça plante.

Je couvre certains oublis de types génériques avec mon plugin… donc je dois pouvoir sérialiser toutes les commandes.

nebz · Novembre 9, 2020, 7:44

Il a remarqué aussi un problème de caractère spécial à la fin du nom (je pense qu’il a fait une issue sur github). Si le core ne gère pas bien ce caractère ça pourrait être la cause…

kiwihc16 · Novembre 9, 2020, 9:36

Je pense plutot pour cette option de caractere special (Hex) dans la commande qui fait que la serialisation plante. Il y longtemps on avait eu ce soucis pour une autre commande.

nebz · Novembre 9, 2020, 10:25

c’est vraiment la ligne execCmd qui plante, tu peux le voir en cliquant sur « tester » dans la liste de commandes. donc meme pas la sérialisation en elle même, plutot l’appel à la valeur dans le cache…

kiwihc16 · Novembre 9, 2020, 5:20

Demain une beta sera dispo donc on pourra essayer.

rroblik · Novembre 10, 2020, 9:57

Hello

J’ai le même soucis mais j’utilise Zigate parcontre sans le plugin Abeille.

Du coup en lisant le topic je ne suis pas sur de ce qu’il faut faire…

Merci

nebz · Novembre 10, 2020, 10:04

Hello,

Il faut isoler une seule pièce et un seul équipement, puis ajouter les équipements un par un pour détecter le fautif (probablement un zigate). (En relançant le demon entre chaque)

Puis il faut cliquer sur « tester » sur chaque commande de type info de l’équipement fautif, et déterminer la commande fautive (celle qui ne fera pas de bandeau vert avec la valeur de la commande). Ensuite il faut voir avec le dev pourquoi cette commande info ne retourne rien…

rroblik · Novembre 10, 2020, 10:05

Ok oui j’ai recoupé avec Homebridge erreur getAccessoryValue - #3 par olive je suis dessus …

@nebz tu es le dév homebridge c’est ça ?

nebz · Novembre 10, 2020, 10:08

Oui du plugin homebridge (pas de homebridge en lui même ;-))

nebz · Novembre 10, 2020, 10:08

Dans une prochaine version j’ajouterai un log pour détecter tout de suite la commande fautive

rroblik · Novembre 10, 2020, 10:10

Tu m’enlève les mots de la bouche
Super boulot en tout cas mais j’en profite oui pour suggérer :

catch de l’exception et remonté dans les erreurs jeedoms (santé du plugin surement) et désactivation auto dudit élément à problème
bouton « sauvegarder et redémarrer le daemon » directement dans la configuration du module pièce par pièce

nebz · Novembre 10, 2020, 10:13

Non pas d’erreur justement… juste un listing de commande vide…

Redémarrer le demon non je préfère que ça soit géré par le core nativement pour éviter tout probleme

rroblik · Novembre 10, 2020, 10:18

Le plugin génère bien une exception donc je suppose qu’on peut la catcher (je suppose oui mais vu le log…)

Plus que 3 pièces, toujours KO

nebz · Novembre 10, 2020, 10:20

Elle est déjà catchée à mon niveau d’où le message. Mais c’est niveau plus haut juste après la commande du core que je peux afficher un message. Car l’exception une fois qu’elle arrive dans le demon ne donne aucune information, juste que l’info json que je reçois est invalide, mais je dois remonter plus haut juste derrière la commande core qui pose problème pour indiquer la commande exacte qui est problématique… mais bon à la base c’est pas à moi de faire ça…

rroblik · Novembre 10, 2020, 10:23

Hummm perdu !

J’ai trouvé l’erreur : une pièce avec 2 éléments non activés. Je l’ai désactivé puis réactivé et sa a suffit…
Un device fantome peu etre ?

Merci pour l’astuce et désolé @battousai90 pour la petite polution

battousai90 · Novembre 11, 2020, 9:06

Pas de soucis, un post est la pour ca.
Par contre je suis désolé de ne pas avoir posté mes solutions, je suis en parallèle sur le Github d’abeille.
En supprimant la commande ‹ nom › des abeilles tout fonctionne, de plus cette commande n’a pas l’air utile ca tourne très bien comme ca dans Homebridge.
Après remonter une erreur Jeedom avec le périphérique mise en cause peut aider, au moins pour le sortir et empêcher Homebridge de démarrer.