Aller au contenu

Messages recommandés

Posté(e)

Bonjour,

 

Quand je regarde la copie écran je m'aperçois que les variables sont crées dans les prédéfinies. N'y a t'il pas la un petit problème. à‡a n'est il pas plutôt dans les variables globales que l'on doit les créer. Chez moi elles sont bien dans les globales.

Pour le port 80, je ne sais pas si c'est le plus judicieux car beaucoup de système, y compris la box peut utiliser ce port par défaut. Ensuite la freebox peut éventuellement, sur ce port, faire des translations automatiquement ou autres opérations.

Essaye le 8080 ou le 8090, souvent sur cette plage les boxes laissent le champs libre.

Bonne chance.

Séb

Posté(e)

Effectivement, je n'avais pas vu ce point. Les variables doivent être globales, je confirme. Si tu ne peux pas saisir Off, laisse la vide, ça devrait fonctionner malgré tout.

 

De toute façon, je pense que ton problème n'est pas encore là . Tu bloque avant, persuadé que tu as un soucis sur tes paramètres IP / Port. ou alors tes branchements réseaux sont faits de sorte que ta HC2 et ton alarme ne peuvent pas communiquer.

 

La connexion entre la BOX et l'alarme doit se faire par le réseau local, il n'y a donc aucune contre indication à  ce que le port soit le 80. Les redirections de la BOX n'ont lieu que lors d'un acces depuis l'exterieur, en aucun cas depuis l'interieur.

Posté(e)

Coucou me revoilà 

 

Bon ça avance :

j'ai recrée les variables : ok

Changement avec port en 8080 : ok

 

Nouveau message dans log en piece jointe

Par contre malgré le débranchement de l'alarme toujours message session en cours (par contre pas de problème en accès depuis pc pas de session ouverte )

Problème plantage du module virtuel sur configuration en cours impossible en enlever malgré modif en enregistrement ou arret vd off 

 

Mais ça avance !

 

post-3241-0-44372300-1424798502_thumb.png

post-3241-0-07536100-1424798509_thumb.png

Posté(e)

Bonsoir,

 

Pour la session en fait j'ai remarqué que sous Chrome, la session pouvait perduré très longtemps même en rebootant l'alarme.

Essaye sous IE en faisant une déconnexion pour que la session soit bien détruite.

Bonne chance.

Séb

Posté(e)

@Olika21 :

 

En fait la session n'est pas ouverte, mais le device le crois, à  cause des manips faites sur la variable.

Pour te sortie de là , il faut :

  • Que tu clique sur le bouton VD Off afin d'initialiser la variable indiquant que la session est ouverte
  • Que tu sauvegarde à  nouveau le virtual device afin qu'il se réinitialise, car c'est au chargement qu'il effectue les tests de connexions puis de reconaissance de ton alarme. Il faut voir si tu as toujours la même erreur qu'avant ou pas.

La mauvaise nouvelle, c'est qu'on a peut-être pas vraiment avancé.

La bonne nouvelle, c'est qu'on finira par y arriver, il n'y a pas de raison.

 

Fait les manips que j'ai décrit, et dis moi ce qu'il en est de ta log. Si nouvelle erreur, tiens moi au courant. Si c'est toujours la même erreur, je maintient la proposition fait en MP

Posté(e)

OK donc , j"ai réinitialisé mais toujours le même log (pièce jointe)

 

Message du module "installation on going" impossible a enlever malgré un vdoff

 

Obligé d'aller effacer la valeur ON de la variable protexiomvdon dans la table pour réinitialiser 

 

 

 

post-3241-0-52509600-1424839770_thumb.png

Posté(e)

Bonjour,

 

Juste une petite idée comme ça :

Dans le menu Réglage de l'interface de l'alarme tu as mis combien dans Délai d'expiration de la session ?

Réglage du réseau : As tu bien désactivé l'option https seul ?

Pour le délai de session, tu peux le baisser un peu pour les tests, genre 10 mins comme ça tu n'as pas à  attendre trop longtemps pour reprendre la main avec la box :)

 

Séb

Posté(e)

Juste pour être sur, quand tu essayes de te connecter avec ton PC tu as bien une page avec l'image d'un maison dans la pénombre et en dessous tu as 3 champs :

- Compte -> utilisateur1

- Code d'accès (vide)

- Code d'authentification LX (avec L une lettre et X un chiffre)

 

 

 

post-1330-0-98600000-1424857166_thumb.jpg

Posté(e)

En fait, la session n'est pas ouverte sur l'alarme. C'est simplement ce que crois le device virtuel, car les différentes manips on mis le bins dans les variables.

Un appuis sur VDOFF aurait du rétablir la situation.

 

Peux-tu regarder le debug du bouton VDOFF lorsque tu appuis dessus ?

Posté(e)

Je pensais au debug du bouton VDOFF.

D'apres moi il y a une erreur avec la variable ProtexiomToken, censée contenir l'ID de session quand la connexion à  l'alarme est active.

Le code ci-dessous est exécuté par le bouton VDOFF pour stopper le polling et réinitialiser ("vider") la variable protexiom token.

        fibaro:setGlobal('ProtexiomVDOn', "OFF")
        fibaro:setGlobal('ProtexiomToken', "")
        local VdId = fibaro:getSelfId();
        fibaro:call(VdId, "setProperty", "ui.lblState.value", "Virtual device stopped") 
        fibaro:debug("VD Stopped")

D'apres ce que tu drécris et ce que j'observe dans tes screenshots, la variable ProtexiomVDOn passe correctement à  OFF.

Par contre la ligne suivante plante, puisque la session est toujours considérée comme ouverte, et que le label n'est pas mis à  jour.

 

La variable ProtexiomToken existe puisque le main loop y accéde. Donc si tu ne peux pas la réinitialiser par le bouton VDOFF, c'est peut être que c'est une variable avec valeur prédéfinie, et que la valeur vide n'existe pas.

Il faut la recréer en variable globle si c'est le cas.

Posté(e)

Essaye de mettre 0 dans toutes tes variables où il y a NaN tu sauvegardes tout ton panneau et ensuite tu arrêtes la box proprement avec le bouton et tu la rallume.

Le redémarrage va peut être remettre les variables dans le bon sens...

Je me suis déjà  sortie de situation de ce type avec cette manÅ“uvre.

Après il faut voir avec le HC2 Toolkit ce qu'il en est exactement avec le contenu de tes variables. 

Tu verras peut être des éléments que l'interface web ne te montre pas précisément.

Posté(e)

Dans l'adresse IP du virtual device tu as bien uniquement que 192.168.1.230 sans rien d'autre avec le port 8080 ?

Posté(e)

En regardant tes variables, ce qui est bizarre, c'est en appuyant sur VDOff tu devrait avoir OFF dans la variable ProtexiomVDOn et rien dans ProtexiomToken et la il y a toujours 0 dedans...

Posté(e)

Bonjour,

 

Qu'est ce qui coincé ?

Merci du feedback pour que les autres  :60: puissent profiter de l'expérience...

Amicalement

Séb

Posté(e)

Difficile à  dire précisément car je pense qu'il y avait plusieurs choses :

 

Lors de la création manuelle des variables, la présence d'autre chose qu'une chaine vide dans la variable ProtexiomToken laisse penser au device que la session est ouverte alors que ce n'est pas le cas. Cela bloque donc la reconnaissance de l'alarme.

Le bouton VDOFF aurait du réinitialiser la variable ProtexiomToken, mais il tente également de fermer la session et comme il ne connait pas la version de l'alarme, il tente de concaténer une URL vide avec l'adresse IP et plantait avant d'avoir réinitialiser la variable.

 

Bref cette erreur était lié au fonctionnement interne du device. Le code mériterai d'être optimisé pour gérer ce type de situation. Pour bébloquer la situation, j'ai commenté une partie du code qui posait probleme, de façon à  simplement permettre l'initialisation correcte des variable.

 

Concernant l'erreur initiale, où l'alarme semblait non accessible, je n'ai pas d'explication. Le problème ne s'est pas produit. Le virtual device a reconnu l'alarme des que nous avons résolu le problème de variable.

 

Dans tous les cas, si on est dans la situation où des modifs de variables on mis le barzard, le meilleur moyen de rétblir la situation serait :

 

1 - Executer le code ci-dessous (par exemplevia un scene à  executer one shot) :

fibaro:setGlobal('ProtexiomVDOn', "OFF")
fibaro:setGlobal('ProtexiomToken', "")

2 - Redémarrer électriquement l'alarme pour s'assurer qu'il n'y a pas de session ouverte

 

3 - Sauvegarder le virtual device afin de relancer le mainloop, et ainsi forcer un reconnaissance de l'alarme

 

4 - Cliquer sur le bouton VD On afin de connecter l'alarme.

Posté(e)

Bonjour fdp2,

 

Merci beaucoup pour tes explications très complète. Le passe par la création des variables en prédéfini a peut être causé ce phénomène bien que une fois substituée en globale cela aurait du résoudre le problème.

Pour avoir eu quelque soucis dernièrement sur des résolutions de nom de variable, j'ai l'impression que ces dernières se trouve simplement dans la base de données de la box et que la portée des variables globales passe après les prédéfinies.

Il est fort possible que lors du démarrage de la box, les variables sont instanciés à  partir de la base de données et il devait resté quelque chose de la création en prédéfini à  ce niveau.

Il est dommage de ne pas avoir accès à  cette base ou tout du moins à  un outil de déboguage qui permet de voir les variables pas à  pas.

Encore merci, chez moi je suis toujours resté en 3.60 et ton device marche parfaitement.

Amicalement

Séb

Posté(e)

Il y a effectivement parfois des soucis lors de la manipulation manuelle des variables globales.

Je suis moi aussi en V3.6. Dans cette version les variables sont créées automatiquement, il n'y a donc pas de soucis.

 

En V4, ce n'est pas le cas, c'est donc un peu plus laborieux, et on peut se trouver dans des situations que je n'avais pas prévu.

 

Je vais voir s'il est possible de fiabiliser ça simplement.

 

Un fois passer le cap de la première installation, il est normalement fiable.

Posté(e)

Oui je confirme. De temps en temps la box perd la connexion mais c'est un bug de la v3, une fois la box rebootée ça repart correctement.

D'ailleurs cela affecte toutes les requêtes http, je pense que c'est l'interface http ou json qui fini par encombrer la mémoire et la box plante.

Vu l'importance de mon installation aujourd'hui je n'ose pas passer en v4  :blink: .

Peut être quand la v5 sera annoncé...

Merci encore

Séb

×
×
  • Créer...