0.83H beta03 – Erreur d’analyse XML : mal formé data.cgx

Serveur WES Forums Serveur WES Mises à jours (Firmware et HTML) 0.83H beta03 – Erreur d’analyse XML : mal formé data.cgx

Mots-clés : 

Vous lisez 9 fils de discussion
  • Auteur
    Articles
    • #8410
      phil
      Participant

      Bonjour,

      Je viens de d’effectuer la mise à jour 0.61D vers 0.83H beta03. Cependant je n’arrive plus à extraire les fichiers fichiers data.cgx, tic1.cgx et tic2.cgx

      Rapport d’erreur avec firefox;

      Erreur d’analyse XML : mal formé
      Emplacement : http://192.168.xxx.x/data.cgx
      Numéro de ligne 1, Colonne 437 :

      Du coup le programme de parser XML en  python ne fonctionne plus:

      xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 1, column 436

      Merci, Philippe

    • #8411
      cdlog2
      Participant

      Bonjour,

      Le fichier Data.cgx de la version 0.83H comporte quelques changement dans son contenu par rapport au fichier Data.cgx de la version 0.61D

      Les Identifiants et formats des Values rendues en Réponse à une requête avec le nouveau fichiers Data.cgx de la version 0.83H sont restés compatibles avec ceux du fichier Data.cgx de la version 0.61D. Par contre de nouveaux Identifiants ont été rajoutés dans le nouveau fichier Data.cgx crée spécifiquement pour la version 0.83H

      Ce qui à surtout changé dans le Data.cgx de la version 0.83H concerne le format de certaines Commande WES, qui n’ont plus le même format des Commandes du Data.cgx de la version 0.61D.

      Ce qui pourrait provoquer votre erreur est d’utiliser l’ancien fichier Data.cgx de la version 0.61D dans la version 0.83H.
      Si cela est le cas ?, il faut absolument utiliser le fichier Data.cgx de la nouvelle version 0.83H.

      De même pour les autres CGX, la plus part des commandes (requêtes Wes) interne au CGX ont changées de format. Donc si vous avez personnalisé certains Cgx, il faut les réadapter avec les nouvelle Cdes de la version 0.83H

      Exemple : vue partielle du Data.cgx au début des Définitions des TIC

      Data.cgx version 0.83H
      ——————————-
      t <tic1>
      c es1 <ADCO>%s</ADCO>
      c eo1 <OPTARIF>%s.</OPTARIF>
      c eS1 <ISOUSC>%d</ISOUSC>
      c Tn1 <PTEC>%s</PTEC>

      Data.cgx version 0.61D
      ——————————
      t <tic1>
      c e a <ADCO>%s</ADCO>
      c eo1 <OPTARIF>%s.</OPTARIF>
      c e c <ISOUSC>%d</ISOUSC>
      c T p <PTEC>%s</PTEC>

      Cdt

    • #8412
      cdlog2
      Participant

      Je constate chez moi, dans la Réponse du WES à la requête Data.cgx en vers. 0.83H, une erreur dans le décryptage de l’Identifiant DEMAIN pour tous les 3 groupes TICs. Le résultat rendu par mon WES pour cet Identifiant ne respecte pas la règle des Balises du format CGX.

      Je constate que cet Identifiant est rendu comme suit : <DEMAIN/>. Ce format peut ne pas être bien interprété par votre Parser XML Python
      Les commandes WES pour ces Identifiants dans le fichier Data.cgx sont formatées ainsi pour les groupes Tic1, Tic2, Tic3:

      c Td1 <DEMAIN>%s</DEMAIN>
      c Td2 <DEMAIN>%s</DEMAIN>
      c Td3 <DEMAIN>%s</DEMAIN>

      Par contre la réponse à une requête data.cgx rendu par mon WES en 0.83h et pour les 3 Cdes Tics est le suivant : <DEMAIN/>
      Normalement le WES devrait rendre une réponse avec une <balise d’ouverture>, Value , une </balise de fermeture> , <DEMAIN>…</DEMAIN>

      Si vous lancez une requête data.cgx via votre navigateur ( http://192.168.x.x/data.cgx) et que vous constatez le même défaut que moi concernant la balise <DEMAIN> dans les Groupes <TICx> , alors il y a une forte chance que votre problème provienne de cela.

      Si cela est le cas chez vous, Supprimer provisoirement ces 3 lignes (voir les 3 Cdes ci-dessus) de votre fichier Data.cgx, cela devrait corriger votre problème en principe ?!..

      réponse partielle de mon WES à la requête Data.cgx :
      <tic1>
      <OPTARIF>Pas dispo.</OPTARIF>
      <ISOUSC>0</ISOUSC>
      <PTEC>NON Dispo !</PTEC>
      <PAP>0</PAP>
      <IINST>0</IINST>
      <IINST1>0</IINST1>
      <IINST2>0</IINST2>
      <IINST3>0</IINST3>
      <TENSION1>0</TENSION1>
      <TENSION2>0</TENSION2>
      <TENSION3>0</TENSION3>
      <IMAX>0</IMAX>
      <IMAX1>0</IMAX1>
      <IMAX2>0</IMAX2>
      <IMAX3>0</IMAX3>
      <PEJP>0</PEJP>
      <DEMAIN/>                                      // ici la réponse n’a pas un format correct CGX standard
      <BASE>000000000</BASE>

      Cdt

    • #8414
      cdlog2
      Participant

      Re : j’ai oubliez de vous dire et précise que je n’ai pas vérifié ce qui suit !,  mais peut être utilisez vous la version python 2.7 ? qui peut être ne reconnaît le format des Balises Uniques XML <à vérifier />, si votre problème vient bien de cela. Mais le WES devrait rester cohérent dans les formats classiques, même sur des balises vides.

       
      <h5 id= »r-les-balises-uniques » data-claire-element-id= »194966″></h5>

    • #8418
      nicolas_cartelec
      Maître des clés

      Je vais corriger pour la couleur du lendemain (si c’est pas le tarif en cours)

    • #8419
      cdlog2
      Participant

      Génial Nicolas. En version V0_7G2, le data.cgx me renvoie <DEMAIN>…</DEMAIN>, texte vide.

      Cdt

    • #8526
      phil
      Participant

      Bonjour,

      Oui la version 2.7 de python génère des erreurs pour les fichiers XML data.cgx, tic1.cgx et tic2.cgx, cela fonctionne bien pour pulse.cgx. Je ne peux pas mettre à jour la version python qui tourne sur une version de OpenWRT 14.07.

      Est-il possible de corriger pour obtenir des fichiers compatibles au standard XML (pas d’erreur de lecture avec les navigateurs de Firefox et Chrome par exemple) ?

      Merci,

      Philippe

    • #8527
      cdlog2
      Participant

      Bonjour,

      Il me semble que vous êtes actuellement en version WES 0.83H.

      Avez vous un contrat type « couleur du jour du lendemain » avec EDF ?

      Si Oui, normalement l’erreur décrite concernant le Champs <DEMAIN> devrait ne pas exister pour le TIC x en relation à votre compteur EDF et vous ne devriez pas avoir de problème dans la lecture du xml pour le TICx EDF.  Par contre si vous avez déclarer un autre Compteur avec un type de contrat différent de  » la couleur du lendemain « , il est évident que vous aurez le problème pour le ou les TIC x concerné.

      De même si vous n’avez pas ce type de contrat EDF pour vos compteurs ?, alors normalement vous devriez constatez l’erreur depuis votre navigateur.
      Si vous lancez une requête data.cgx via votre navigateur ( http://192.168.x.x/data.cgx) et que vous constatez le même défaut que moi concernant la balise <DEMAIN> dans un des Groupes <TICx> , alors il y a une forte chance que votre problème provienne de cela.

      réponse partielle de mon WES pour le TIC1 à la requête Data.cgx :  Voir le commentaire pour la balise <DEMAIN> à la fin du résultat rendu

      <tic1>
      <OPTARIF>Pas dispo.</OPTARIF>
      <ISOUSC>0</ISOUSC>
      <PTEC>NON Dispo !</PTEC>
      <PAP>0</PAP>
      <IINST>0</IINST>
      <IINST1>0</IINST1>
      <IINST2>0</IINST2>
      <IINST3>0</IINST3>
      <TENSION1>0</TENSION1>
      <TENSION2>0</TENSION2>
      <TENSION3>0</TENSION3>
      <IMAX>0</IMAX>
      <IMAX1>0</IMAX1>
      <IMAX2>0</IMAX2>
      <IMAX3>0</IMAX3>
      <PEJP>0</PEJP>
      <DEMAIN/>              // ici erreur du format XML 1ere génération, la balise <DEMAIN> n’est pas fermée par </DEMAIN>
      <BASE>000000000</BASE>

      Si vous n’avez pas besoin de lire cette Balises <DEMAIN> pour chaque TIC x alors supprimer dans votre ficher data.cgx les lignes ci-dessous qui font références ces champs <demain> dans TIC1, TIC2 et TIc3 :

      c Td1 <DEMAIN>%s</DEMAIN>     supprimer cette ligne des Options TIC1
      c Td2 <DEMAIN>%s</DEMAIN>     supprimer cette ligne des Options TIC2
      c Td3 <DEMAIN>%s</DEMAIN>     supprimer cette ligne des Options TIC3

      Ensuite sauvegardez le fichier data.cgx du WES  . Normalement votre problème ne devrait plus exister si c’est bien cela qui vous pose problème.

      Nicolas va apporter un correctif dans sa prochaine release.

      Cdt

    • #8528
      cdlog2
      Participant

      Re : pour être un peu plus précis :

      c Td1 <DEMAIN>%s</DEMAIN>     supprimer cette ligne des Options TIC1 si le contrat du TIC1 CPT1 n’est pas « couleur du lendemain »
      c Td2 <DEMAIN>%s</DEMAIN>     supprimer cette ligne des Options TIC2 si le contrat du TIC2 CPT2 n’est pas « couleur du lendemain »
      c Td3 <DEMAIN>%s</DEMAIN>     supprimer cette ligne des Options TIC3 si le contrat du TIC3 CPT3 n’est pas « couleur du lendemain »

      lignes à supprimer du fichier data.cgx pour les TIC x correspondant et qui ne sont pas sous contrat EDF « couleur du lendemain »

    • #8529
      cdlog2
      Participant

      RE: Je vous envoie en pièce jointe une archive ZIP qui contient le fichier data.cgx avec les options <DEMAIN> supprimées pour les 3 groupes de TIC1, TIC2 et TIC3.

      Afin de vous éviter de modifier votre propre fichier, renommer simplement pour test, votre ficher data.cgx en org-data.cgx par exemple et copier mon fichier data.cgx dans la carte mémoire du WES.

      Normalement votre problème de XML python pour les TICs devrait être corrigé, bien sur s’il n’y a pas d’autres incohérence du même type avec d’autres Option Tic x.

       

       

      Attachments:
      You must be logged in to view attached files.
Vous lisez 9 fils de discussion
  • Vous devez être connecté pour répondre à ce sujet.