Mise à jour IPX800_V5 version 5.4.1

Bonjour,

Autre constat, objet « PUSH » ne remonte pas toute la chaine de retour lors des requêtes :

POST ou GET sur un http://ipx800v3/api/xdevices.json?cmd=10

résultat aléatoire :,« IN22 »:0,« IN23 »:0,« IN24 »:0,« IN25 »:0,« IN26 »:0,« IN27 »:0,« IN28 »:0,« IN29 »:0,« IN30 »:0,« IN31 »:0,« IN32 »:0}
ou
,« IN17 »:0,« IN18 »:0,« IN19 »:0,« IN20 »:0,« IN21 »:0,« IN22 »:0,« IN23 »:0,« IN24 »:0,« IN25 »:0,« IN26 »:0,« IN27 »:0,« IN28 »:0,« IN29 »:0,« IN30 »:0,« IN31 »:0,« IN32 »:0}

Bonjour,
l’objet Push est limité en nombre de caractères pour la réponse, d’où la mise en place progressive de Plugins de communication comme pour la V4 (ça arrivera peut-être aussi pour la V3).

Cependant, les exemples que vous donnez comportent un nombre aléatoire de caractères, ce qui fait penser à des réponses tronquées.
Vérifiez que lorsque vous envoyez une requête à la V3, cette dernière a bien le temps de répondre avant de lui envoyer une autre requête, en d’autres termes, espacez vos requêtes.
bonne journée

Bonjour,
Selon la doc, la réponse est de la forme :

{« product »:« IPX800_V3 »,« IN1 »:0,« IN2 »:0,« IN3 »:0,« IN4 »:0,« IN5 »:0,« IN6 »:0,« IN7 »:0,« IN8 »:0,« IN9 »:0,« IN10 »:0, « IN11 »:0,« IN12 »:0,« IN13 »:0,« IN14 »:0,« IN15 »:0,« IN16 »:0,« IN17 »:0,« IN18 »:0,« IN19 »:0,« IN20 »:0,« IN21 »:0,« IN22 »:0, « IN23 »:0,« IN24 »:0,« IN25 »:0,« IN26 »:0,« IN27 »:0,« IN28 »:0,« IN29 »:0,« IN30 »:0,« IN31 »:0,« IN32 »:1}

Elle contient 304 caractères et dépasse ainsi la limite actuelle des 254 caractères. La réponse est donc corrompue.
Bonne journée

pour moi, la limite était à 512, mais peu importe.
Cette limite n’explique pas tout :smiley: , le nombre aléatoire de caractères par exemple :slight_smile:
Si la limite est à 254, alors la réponse devrait être tronquée à 254 caractères de manière constante, à condition que les requêtes ne s’enchevêtrent pas . Il y a bien un problème de périodicité des Push en plus.

bonjour et bonne fête a tous
je viens d’installer et de mettre a jour la V4 et la V5, le plug in V4 est super.
par contre on ne voie pas les modules associe ex: un X4FP mais cela viendra après , peut être ??

Je viens de faire le test sur ma v3 en utilisant la fonction test de l’éditeur de push et en attendant au moins une minute entre deux activations :

,"IN20":0,"IN21":0,"IN22":0,"IN23":0,"IN24":0,"IN25":0,"IN26":0,"IN27":0,"IN28":0,"IN29":0,"IN30":0,"IN31":0,"IN32":0}

,"IN19":0,"IN20":0,"IN21":0,"IN22":0,"IN23":0,"IN24":0,"IN25":0,"IN26":0,"IN27":0,"IN28":0,"IN29":0,"IN30":0,"IN31":0,"IN32":0}

,"IN21":0,"IN22":0,"IN23":0,"IN24":0,"IN25":0,"IN26":0,"IN27":0,"IN28":0,"IN29":0,"IN30":0,"IN31":0,"IN32":0}

,"IN20":0,"IN21":0,"IN22":0,"IN23":0,"IN24":0,"IN25":0,"IN26":0,"IN27":0,"IN28":0,"IN29":0,"IN30":0,"IN31":0,"IN32":0}

,"IN21":0,"IN22":0,"IN23":0,"IN24":0,"IN25":0,"IN26":0,"IN27":0,"IN28":0,"IN29":0,"IN30":0,"IN31":0,"IN32":0}

L’info la plus longue ne contient que 127 caractères.

Après vérification, vous avez raison, la string réponse est bien de 512 caractères.
J’avais eu le même comportement avec certaines commandes sur la v4 (voir fil Utilisation du parser) :

On note que les réponses aux commandes R,D, VA et XTHL sont tronquées à 512 caractères en partant du début de la réponse et que les commandes VI et VO sont tronquées à partir de la fin. Je me souviens que, dans ces cas, les tailles des réponses n’étaient pas constantes.

En V3,en reprenant les tests, on note :

  • cmd=10 : réponse portant sur les dernières entrées à partir de in19, in20 ou in 21
  • cmd=20 : réponse portant sur les dernières sorties à partir de out18, iout19, out20 ou out 21
  • cmd=30 : réponse complète sur les 16 entrées (dans mon cas, elles sont toutes à 0 et la réponse contient 158 caractères)
  • cmd=40 : réponse complète des 8 compteurs (dans mon cas 92 caractères)

Un nouveau plugin V3 est certainement dans la roadmap de GCE

Bonjour,

Merci pour cette mise à jour.
J’ai tenté d’appairer un nodon mais sans succès, voici le message d’erreur reçu:

Voici le modèle de nodon (2 canaux enocean) que je tente d’appairer (Le EEP se trouve de + dans la liste proposée)

Cordialement,
Thibaut de Sany.

Hello,
J’ai exactement le même problème, avec le même code d’erreur dans les logs.

En 5.4.1, la restauration se fige vers 45%, puis j’ai un msg d’erreur « error during upload » ou qqch du genre, puis si je fais un reboot logiciel j’ai « error during reboot », donc obligé de faire un reboot en coupant le jus.
Dans les logs j’ai le NOINIT_FLASH_BLOCK, mais j’ai aussi un msg GCE_INVALID_FLASH_CONFIG_SIZE.

J’ai bien entendu essayé de réinstaller le firmware (qui s’est réinstallé correctement, bonne version à la fois du firm et du server), de faire des factory reset aussi bien en logiciel qu’avec le bouton réset sous l’IPX, rien n’a marché.

Donc, downgrade en 5.3.0, repush de la configuration : nada, même souci.

La seule chose qui a marché c’est le retour en 5.4.0 (que je n’avais jamais installé), push de la configuration, puis 5.4.1.

Décidément la v5 est bien capricieuse…

Autre truc étrange : aussi bien un factory reset qu’une installation de firmware n’effacent pas les logs système, je me serais attendu à un RAZ total…

Et autre souci, je perds régulièrement l’accès au serveur, obligé de reboot en coupant le jus. Et encore ça ne revient pas toujours. J’ai l’impression que quand ça arrive, l’IPX est occupée à calculer qqch et que ça lui prend toutes ses ressources, un peu comme si elle se faisait un DDOS à elle même…

Bonjour,
depuis la version officielle, il me semble que les mises à jour se passent sans encombre, en tout cas je n’ ai pas rencontré de problème depuis bien longtemps (la dernière fois c’était pendant les Béta)
Vous faites vos mises à jour à partir d’un PC Windows, d’un Mac , d’un appareil Androïd ?
quel navigateur ?

Pour complément d’information, :
pendant la mise à jour, soyez attentif à l’état des DELs sur l’ipx800, elles indiquent les étapes en cours et il faut bien attendre que le premier fichier soit téléversé et installé avant de lancer le second fichier.
Bonne journée

Bonjour,
J’utilise chromé sur Linux mint. Je n’avais jamais rencontré de problème pour sauvegarder ou restaurer.
L’interface web se rafraîchit automatiquement lors d’une mise à jour, donc c’est vrai que je ne regarde pas forcément les led de la V5.
Par contre pour la sauvegarde, led ou pas, ça plante 9 fois sur 10.

J’ai eu un nouveau message dans les logs ce matin au moment du plantage causé par le lancement d’une sauvegarde:

Bonsoir @patam.
Vos problèmes de sauvegarde et de message nouvellement apparu ont été remontés.
bonne soirée

Bonsoir fgtoul,

Mon problème n’est pas un problème de MAJ, c’est un problème de restauration, comme patam.
Les MAJ de firmware se passent bien, c’est quand je veux restaurer une configuration que ça plante (comme patam), depuis la 5.4.1.
Et ça plante vraiment, je regarde effectivement les LES quand ça arrive et elles indiquent effectivement une erreur.

En fait pas vraiment, j’ai fait qques essais avec une configuration minimale avant de reprogrammer sur la 5.4.1, ça marchait. C’est sur ma configuration « complète » (plein de liens, toutes mes extensions déclarées, plusieurs scènes actives, etc.) que le système refuse de restaurer et me parle de « INVALID_CONFIG_SIZE »…

Bonsoir Drepa,

dans certains cas la sauvegarde est corrompue au moment de l’enregistrement. C’est un pb connu et en cours de solution.

Bonne soirée

Il est normal que les journaux soient effacés manuellement et non automatiquement à chaque màj ou hard reset, les 2 tâches sus-citées sont elles-mêmes loguées.

problème connu en cours d’investigation. Non propre à la 5.4.1

Bonsoir,

Ici, ce qui est étrange, c’est que ma sauvegarde (qui a été faite depuis une 5.4 1) ne se restaure pas depuis une 5.4.1, ni depuis une 5.3.0, mais que ça marche si je la charge depuis une 5.4.0.
Si ça marche depuis une 5.4.0, peut-on parler de corruption ponctuelle ?

Idem, c’est AUCUNE sauvegarde qui n’arrive à se charger depuis une 5.4.1… En programmant, je sauvegarde régulièrement à chaque étape une sauvegarde differente (ajout extensions, puis programmation des lumières, puis programmation des volets, puis les capteurs, etc.).
Je les ai toutes essayées, aucune n’a pris.

Bonjour à tous,

J’ai le même problème que vous.
J’ai fini mon programme, j’ai fait plusieurs sauvegardes car la première tentative plantait.
J’ai tenté de restaurer ce programme mais j’ai perdu tous les scénarios + objets.

Du coup, me voila reparti dans l’écriture d’un nouveau programme avec la V5.4.1. Je déclare toutes mes variables et je décide par curiosité de sauvegarder mon programme. Idem, il n’arrive pas à aller jusqu’au bout et l’IPX plante. De même quand j’effectue une restauration. Je suis obligé de redémarrer électriquement l’IPX.

J’ai perdu tous mon programme du coup :frowning:

@drepa, @micou211187
bonjour,
comme l’a annoncé @grocrabe, le problème est connu et sera corrigé.
bonne journée

Bonjour @micou211187 ,
Comme l’a dit @fgtoul , le pb est connu et sera corrigé, en attendant la correction pour faire vos sauvegardes et restaurations vous pouvez débrancher le bus EBX le temps de faire ces opérations :wink:

Hello,

Vue la réactivité de GCE, pas de doute que ce sera corrigé, je décrivais juste pour orienter la réflexion avec des faits précis, si besoin.

Ce serait donc un souci de conflit avec le bus ?