Ah ! Doublon avec falex 
Merci pour ton témoignage
j ai toujours l appli web dÍG dans un coins avec la fenêtre des position ouvertes pour vérifier ce qui se passe, et je ferme toujours d abord la L3 puis verif sur ig que aucune position ne traine puis je me delogue puis je coupe le pc
jamais trop prudent avec sont capital.... bretelle et ceinture
jamais trop prudent avec sont capital.... bretelle et ceinture
Il serait interessant d'avoir le fichier log si c'est possible. Si tu es avec la dernière version il est dans le répertoire /Logs/Debug-datedujour.log. Il m'arrive aussi de ne pas recevoir les updates ig. Je le suis toujours demandé si c'était mon code ou leurs serveurs qui buggaient.
En tout cas content que cela se soit bien terminé
En tout cas content que cela se soit bien terminé
Manu ton histoire reflète bien une des limites de l'api :
Les ordres dont envoyé en REST mais l'update se fait en STREAM.
Dans ton cas la partie REST était fonctionnelle
Et le STREAM non ...
Faut être clair ce programme s'est vraiment comme une voiture de course dans ESP ni ABS : c'est à vous de garder le contrôle et la trajectoire
Les ordres dont envoyé en REST mais l'update se fait en STREAM.
Dans ton cas la partie REST était fonctionnelle
Et le STREAM non ...
Faut être clair ce programme s'est vraiment comme une voiture de course dans ESP ni ABS : c'est à vous de garder le contrôle et la trajectoire
Comme darth j'ai toujours la plateforme web connecte sous le coude au cas où.
Merci pour l'explication Falex je désactive l'écran de veille par sécurité et rajouter demain un warning sur la page présentation
Merci pour l'explication Falex je désactive l'écran de veille par sécurité et rajouter demain un warning sur la page présentation
Perso j'ai eu la même expérience que toi manu (L3 visuellement non réactive mais qui obéit bel et bien) mais en démo donc pas de soucis, par contre je précise que mon ordi ne se met jamais en veille donc ça peut survenir à tout moment. J'ai donc pris pour habitude si il ne semble rien se passer lorsque je presse une touche de ne jamais represser la touche, d'abord parce que si c'est pour un signal scalp, les 3 secondes que je réalise que rien ne se lance le cours a pu largement décaler et périmer mon intention, mais aussi cela me laisse le temps de vérifier sur ig web si quelque chose tourne hors L3. Je trouve que c'est plus sage ainsi.
Bonjour,
Je suis reparti à zéro pour la couche réseau, car j'aime bien comprendre.
Je ne connais pas vraiment python et wxwidgets, donc je ne peux pas vous aider directement, mais voici quelques remarques à propos de ces déconnexions de LightStreamer :
- C'est une surcouche qui simule une connexion continue au dessus d'une connexion http, or celle ci n'a pas été conçue pour cela à l'origine, d'où les coupures fréquentes.
- Ils ont prévu des mécanismes de contrôle qui permettent de surveiller assez facilement l'état du réseau.
Méthode 1 : Quand tout va bien, le serveur envoie des infos en permanence (ticks, positions). S'il n'a rien à dire pendant plus de x secondes, il bouche le trou en envoyant un message PROBE (x est paramétrable à la connexion).
Donc, si on ne reçoit rien pendant plus de x secondes (ni tick, ni position, ni PROBE), c'est que la connexion est coupée.
Il faut alors la relancer (uniquement la partie STREAM, en gardant les identifiants obtenus en REST).
Solution : mettre un timer qui déclenche une exception toutes les x+1 chouilla secondes, que l'on remet à zéro chaque fois que l'on reçoit quelque chose (PROBE ou info, peu importe). Ainsi il ne se déclenche que si l'on ne reçoit rien pendant trop longtemps, et on peut alors relancer la connexion, ou au moins avertir l'utilisateur du problème.
Méthode 2 (complémentaire de la 1) : même quand tout va bien, la connexion STREAM est coupée délibérément par le serveur de temps en temps (quelques heures ou quelques minutes, ça dépend de son humeur). Mais comme il est gentil, il prévient, en envoyant un message LOOP quelques secondes avant.
Il faut donc veiller l'arrivée des LOOP, et relancer la connexion quand ça arrive.
Je ne sais pas comment on fait ça en python (je programme en c++ avec qt pour l'interface), mais je suis à peu près sûr que c'est possible.
En espérant avoir été un peu utile,
Bonne nuit aux couche-tard et bonjour aux lève-tôt !
Je m'amuse à développer ma propre application de trading simplifié, plus adaptée à mes limites de tradeur désespérément balourd (et puis pendant ce temps je ne perds pas).falex a écrit :Manu ton histoire reflète bien une des limites de l'api :
Les ordres dont envoyé en REST mais l'update se fait en STREAM.
Je suis reparti à zéro pour la couche réseau, car j'aime bien comprendre.
Je ne connais pas vraiment python et wxwidgets, donc je ne peux pas vous aider directement, mais voici quelques remarques à propos de ces déconnexions de LightStreamer :
- C'est une surcouche qui simule une connexion continue au dessus d'une connexion http, or celle ci n'a pas été conçue pour cela à l'origine, d'où les coupures fréquentes.
- Ils ont prévu des mécanismes de contrôle qui permettent de surveiller assez facilement l'état du réseau.
Méthode 1 : Quand tout va bien, le serveur envoie des infos en permanence (ticks, positions). S'il n'a rien à dire pendant plus de x secondes, il bouche le trou en envoyant un message PROBE (x est paramétrable à la connexion).
Donc, si on ne reçoit rien pendant plus de x secondes (ni tick, ni position, ni PROBE), c'est que la connexion est coupée.
Il faut alors la relancer (uniquement la partie STREAM, en gardant les identifiants obtenus en REST).
Solution : mettre un timer qui déclenche une exception toutes les x+1 chouilla secondes, que l'on remet à zéro chaque fois que l'on reçoit quelque chose (PROBE ou info, peu importe). Ainsi il ne se déclenche que si l'on ne reçoit rien pendant trop longtemps, et on peut alors relancer la connexion, ou au moins avertir l'utilisateur du problème.
Méthode 2 (complémentaire de la 1) : même quand tout va bien, la connexion STREAM est coupée délibérément par le serveur de temps en temps (quelques heures ou quelques minutes, ça dépend de son humeur). Mais comme il est gentil, il prévient, en envoyant un message LOOP quelques secondes avant.
Il faut donc veiller l'arrivée des LOOP, et relancer la connexion quand ça arrive.
Je ne sais pas comment on fait ça en python (je programme en c++ avec qt pour l'interface), mais je suis à peu près sûr que c'est possible.
En espérant avoir été un peu utile,
Bonne nuit aux couche-tard et bonjour aux lève-tôt !
Bonjour Jized,jized a écrit :Quand tout va bien, le serveur envoie des infos en permanence (ticks, positions). S'il n'a rien à dire pendant plus de x secondes, il bouche le trou en envoyant un message PROBE (x est paramétrable à la connexion)
Connais-tu la valeur par défaut de x ?
Merci pour l'explication jized.
- regardes qwt ou qcustomplot, ça peut te convenir.
A+
- regardes qwt ou qcustomplot, ça peut te convenir.
A+
Sujets similaires
