Discussion :

[OButterlin]

Pas grave

Maintenant ça fonctionne bien ?

[OButterlin]

Merci pour tout encore une fois

Encore une petite question pour toi OButterlin, lorsque je rentre l'adresse ip de mon automate j'ai un erreur GET :

Pièce jointe 533081

le http.send(); ligne 28 pose soucis

Si tu mets un point d'arrêt dans la servlet et que tu suis le processus, ça se plante dans la classe IPX800V3 ou dès l'appel de la servlet ?

EDIT:
P'tain j'suis con, http.send() c'est le javascript... oups...
Je pense que le problème vient du fait que tu n'as pas mis la bonne url côté javascript... chez moi l'application se nommait "automate", toi non... du coup, il faut modifier l'url ajax

[Gwendal2835]

Je ne suis sur a 100% mais ça se plante lors de l'appel de la servlets

[OButterlin]

Il faudrait mettre ceci

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

http.open("GET", window.location.pathname + "getState?addr=" + adresse, true);

[Gwendal2835]

Il manque un petit "/" non ?

[OButterlin]

Oups, j'ai mal fait mon test...
Mets plutôt

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

http.open("GET", "/ApplicationWebAutomate/getState?addr=" + adresse, true);

[Gwendal2835]

C'est bon, j'arrive a rentrer l'adresse IP cela fonctionne mais lorsque je souhaite lancer l'extraction cyclique :

[OButterlin]

Sans le traitement cyclique ça fonctionne bien ?
Ton automate répond en combien de temps ?
Dans l'application que je t'ai donné, le cycle entre les requêtes est de 5 secondes, c'est peut-être trop juste (en plus de ne pas être super utile)... tu devrais augmenter cette valeur, 30 secondes est déjà assez court...
C'est la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

intervalId = setInterval("reloadData()", 5000);

L'intervalle est en millisecondes

[Gwendal2835]

Lorsque je rentre l'ip et que je clique sur ajouter automate en un peu plus 10 secondes.

J'ai changé le cycle entre les requêtes, j'ai mis comme tu m'as dit "30000". Mais je n'arrive plus à me connecter..

[OButterlin]

Je vois mal comment t'aider, je n'ai pas d'IPX800 sous la main...

Tu peux déjà mettre en commentaire la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

socket.setSoTimeout(10000);

et voir ce que ça donne...

[Gwendal2835]

Je vois mal comment t'aider, je n'ai pas d'IPX800 sous la main...

Tu peux déjà mettre en commentaire la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

socket.setSoTimeout(10000);

et voir ce que ça donne...

Je comprend, tu m'as deja beaucoup aidé.

J'ai l'impression que ça n'arrive pas jusqu’à la classe IPX800.

J'ai ceci dans la console :
Extraction de l'état de l'automate 172.22.55.210 en cours...
java.net.ConnectException: Connection timed out: connectExtraction de l'état de l'automate 172.22.55.210 terminée.
Extraction de l'état de l'automate 172.22.55.210 en cours...
java.net.ConnectException: Connection timed out: connectExtraction de l'état de l'automate 172.22.55.210 terminée.

[OButterlin]

Normalement, c'est une erreur liée à la classe IPX800V3, tu peux mettre un point d'arrêt dans le catch de la servlet, peut-être que tu auras des informations en explorant l'exception.
Tu as bien mis le setSoTimeout en commentaire ?
L'erreur semble venir d'un timeout sur la lecture, donc à priori à la ligne br.readLine().

[Gwendal2835]

Normalement, c'est une erreur liée à la classe IPX800V3, tu peux mettre un point d'arrêt dans le catch de la servlet, peut-être que tu auras des informations en explorant l'exception.
Tu as bien mis le setSoTimeout en commentaire ?
L'erreur semble venir d'un timeout sur la lecture, donc à priori à la ligne br.readLine().

Je regarde :



Oui il est bien en commentaire.

J'ai l'impression que j'accède pas a la requête ou que le programme n'arrive pas a sortir de la fonction getAutomateData..

[OButterlin]

Si tu ne poursuis pas l'exécution, c'est normal. Quand il atteint un point d'arrêt, il s'arrête jusqu'à ce que tu lui dises de continuer (F6 pas à pas, F8 on passe).
Si tu mets le point d'arrêt sur la ligne result = e.toString(); tu auras accès à la variable "e" (l'exception) et tu pourras explorer l'objet...
Mais bon, vu l'exception, c'est que ton automate ne répond pas dans le délai imparti...
Essaye de mesurer le temps par défaut qu'il attend et ensuite, adapte la ligne socket.setSoTimeout(...) avec une valeur supérieure... ou, dans un premier temps, mets la valeur 0 qui veut dire "attente indéfinie".

[Gwendal2835]

Si tu ne poursuis pas l'exécution, c'est normal. Quand il atteint un point d'arrêt, il s'arrête jusqu'à ce que tu lui dises de continuer (F6 pas à pas, F8 on passe).
Si tu mets le point d'arrêt sur la ligne result = e.toString(); tu auras accès à la variable "e" (l'exception) et tu pourras explorer l'objet...
Mais bon, vu l'exception, c'est que ton automate ne répond pas dans le délai imparti...
Essaye de mesurer le temps par défaut qu'il attend et ensuite, adapte la ligne socket.setSoTimeout(...) avec une valeur supérieure... ou, dans un premier temps, mets la valeur 0 qui veut dire "attente indéfinie".

Voici le "e" après le point d'arret :



Est ce normal que le "result" soit vide ici ?

Pour moi c'est bien un problème de socket car au niveaux du " sb.append("\"").append(result).append("\");");" il y a bien le automates.set("172.22.55.210"), mais le "result" est vide : java.net.SocketTimeoutException: Read timed out

Modif : Lorsque je ne met pas de temps dans le setSoTimeout(0), l'extraction de l'automate reste en cour indéfiniment.

[OButterlin]

Ben oui, c'est normal, comme ton appel via socket n'aboutit pas mais lance une exception, l'affectation ne se fait pas. Mais dans le catch, c'est le message lié à l'exception qui est affecté à result...

C'est ton IPX qui ne répond plus, il faudrait regarder dans la documentation si il a besoin d'une commande pour libérer son canal ou je ne sais quoi...
La première commande est bien passée, c'est les suivantes qui ne passe plus si je comprends bien...

[Gwendal2835]

Ben oui, c'est normal, comme ton appel via socket n'aboutit pas mais lance une exception, l'affectation ne se fait pas. Mais dans le catch, c'est le message lié à l'exception qui est affecté à result...

C'est ton IPX qui ne répond plus, il faudrait regarder dans la documentation si il a besoin d'une commande pour libérer son canal ou je ne sais quoi...
La première commande est bien passée, c'est les suivantes qui ne passe plus si je comprends bien...

Salut, désolé j'étais absent la semaine

Oui je me suis rendu compte en relisant que ce n'était pas la question la plus pertinente x).

Voici la doc :

https://www.domotique-info.fr/script/IPX_API_M2M.pdf

Je fais des recherches, je vous tiens au courant si je trouve une solution.

[Gwendal2835]

J'ai trouvé la solution !!!!!!

Voici le résultat :







et voici maintenant la classe IPX800V3 :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
package com.automate.state;
 
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.Socket;
 
public class IPX800V3
{
    public static String test(String adresse, int port) throws Exception
    {
        try
        (
            Socket socket = new Socket(adresse, port);
            BufferedReader br = new BufferedReader(new InputStreamReader(socket.getInputStream()));
            PrintWriter pw = new PrintWriter(socket.getOutputStream());
        )
        {
 
            socket.setSoTimeout(10000);
            pw.println("GetOutputs");
            pw.flush();                           // j'ai donc forcé l'écriture
 
            String result;
            result = br.readLine();
            return result;
        }
    }
}

Voila, maintenant il faut que j'arrive a fermer les sockets car lorsque j'essaye de re-récupérer les données cela m'affiche les mêmes que dans la première requête.

[OButterlin]

Cool, tu avances

Le socket est fermé, le try with resources est là pour s'assurer que ce qui est défini entre parenthèses sous le try soit fermé à la sortie du bloc...

[Gwendal2835]

Cool, tu avances

Le socket est fermé, le try with resources est là pour s'assurer que ce qui est défini entre parenthèses sous le try soit fermé à la sortie du bloc...

Oui grâce a toi

Lorsque je rentre par exemple l'ipx : 172.22.55.210 je reçois donc les 32 0.
Je change l'état manuellement des 5 premières sorties, je devrais donc recevoir : 111110000000000000000.. sauf que je reçois les 32 0.

Donc je me suis dis que je devais sans doute le fermer. Apparemment non

Soucis de mémoire non ?