Discussion de l'article "Comment s'abonner aux signaux de trading" - page 117

 
Evgeniy Govorkov #:
Oui, j'ai Xauusd+. L'abonné n'a que Xauusd. Est-il exact que la copie est impossible dans ce cas ?

La copie est possible dans ce cas - si toutes les autres conditions du mappage sont remplies.
Mais il y a d'autres facteurs qui affectent le mappage, par exemple (d'après la FAQ) :

L'instrument GOLD est négocié sur le compte du fournisseur, mon courtier possède le même instrument, mais il s'appelle XAUUSD. Dans ce cas, les transactions sur le symbole GOLD seront-elles copiées sur le symbole XAUUSD ?

  • Pour chaque instrument restant, le type de calcul de marge est vérifié - si le type Forex est coché , l'instrument est transféré. Les instruments dont le type de calcul est CFD, Futures, etc. sont écartés.
  • Si, après les vérifications, il ne reste aucun instrument ou si plusieurs instruments sont trouvés, on considère que la comparaison a échoué et qu'il est impossible de copier les transactions du fournisseur sur cet instrument.
  • ----------------------

    Qu'est-ce que cela signifie ?

    • Cela signifie que si vous avez plus d'un symbole sur XAUUSD, la copie est impossible.
    • Et si, dans la spécification du symbole, le calcul de la marge n'est pas Forex, la copie est également impossible.

    ---------------------

    Dans certains cas, toutes les conditions du mappage sont remplies, mais le courtier lui-même limite la copie (et c'est écrit dans le journal Metatrader pour ce symbole). Ces cas sont très rares (mais le dernier cas remonte à quelques jours avec XAUUSD et XAUEUR).

    C'est-à-dire que dans la plupart des cas, il s'agit d'un mapping.

    Je vous conseille de vérifier auprès de votre courtier le mapping des symboles copiés après avoir sélectionné le signal de copie, c'est-à-dire s'il sera copié ou non, puis de vous inscrire :

    Comment sélectionner le broker/signal et avec le mapping : post
    FAQ по сервису Сигналы - Создайте свой Сигнал на MQL5 Com, нужно ли за это платить
    FAQ по сервису Сигналы - Создайте свой Сигнал на MQL5 Com, нужно ли за это платить
    • 2013.02.11
    • www.mql5.com
    На счете провайдера все сделки совершаются объемом в 0. Если же на найденном символе торговля разрешена только частично либо запрещена. Для каждого найденного инструмента проверяется полное разрешение на торговлю
     
    Evgeniy Govorkov #:
    Oui, j'ai Xauusd+. L'abonné n'a que Xauusd. Ai-je raison de dire que la copie n'est pas possible dans ce cas ?
    Yes, see :
    https://www.mql5.com/en/forum/10773#q13
    https://www.mql5.com/en/forum/311109#comment_11375302
    https://www.mql5.com/en/forum/292340#comment_9504099
    Frequently Asked Questions about the Signals service
    Frequently Asked Questions about the Signals service
    • 2013.02.20
    • www.mql5.com
    The most frequently asked questions related to the signals service will be collected and processed in this topic. I do not want to broadcast it anymore. Full permission to perform trading is checked for each detected symbol
     

    En ce qui concerne le problème bien connu de "pas de taux de conversion pour la devise de dépôt du fournisseur" (lorsque le courtier de l'abonné n'a pas de paire de devises entre la devise de base du fournisseur et celle de l'abonné) : J'ai découvert que (au moins sur MT5) non seulement le ratio 1:1 est utilisé comme l'indique le message (ce qui, heureusement, est correct dans mon cas), mais aussi qu'il y a un délai important entre une nouvelle transaction provenant du signal et sa transmission au courtier. Dans mon cas, ce délai est de 1,1 seconde sur un VPS MQL5, et similaire sur mon ordinateur. Pour le signal en question, cela fait une énorme différence car le prix bouge rapidement juste à cette seconde (probablement beaucoup d'autres transactions automatisées se produisent au même moment chez mon courtier ou leur fournisseur de liquidité, faisant bouger le prix). Je ne sais pas exactement pourquoi il y a ce délai - je pense que MT5 demande une nouvelle liste de symboles au courtier avant de procéder à la transaction, pour finalement conclure qu'il n'y a toujours pas de taux de conversion (il enregistre un message le disant, retardé de ces 1,1 secondes).

    Je cherche donc un moyen d'éviter ce délai. J'ai essayé de créer un symbole personnalisé pour la paire de devises manquante, mais il n'est pas pris en compte par cette logique (même en souscrivant au signal localement sur mon ordinateur, sans utiliser de VPS).

    La prochaine étape consiste à contacter mon courtier, mais je doute qu'il soit disposé à créer un symbole pour une paire de devises dont il n'a pas l'équivalent exact.

    D'autres suggestions ?

    Dans mon cas, la devise de base du fournisseur de signaux est l'UST (pour USDT), que mon courtier n'a pas. Si un développeur MT5 lit ceci, merci d'ajouter un moyen de spécifier le taux de conversion manuellement (idéalement utilisable même pour les paires de devises qui existent, en tant que surcharge manuelle), ou au moins d'ajouter UST comme synonyme reconnu de USD. Peut-être aussi supprimer la demande (présumée) d'une nouvelle liste de symboles à l'ouverture d'une transaction (ne le faire qu'une fois lorsque l'on commence à suivre un signal, ou périodiquement, mais pas à nouveau à ces moments les plus critiques). Merci de votre compréhension.

     
    playgold transactions automatisées se produisent au même moment chez mon courtier ou leur fournisseur de liquidité, faisant bouger le prix). Je ne sais pas exactement pourquoi il y a ce retard - je suppose que MT5 demande une nouvelle liste de symboles au courtier avant de procéder à la transaction, pour finalement conclure qu'il n'y a toujours pas de taux de conversion (il enregistre un message le disant, retardé de ces 1,1 secondes).

    Je cherche donc un moyen d'éviter ce délai. J'ai essayé de créer un symbole personnalisé pour la paire de devises manquante, mais il n'est pas pris en compte par cette logique (pas même lorsque je m'abonne au signal localement sur mon ordinateur, sans utiliser de VPS).

    La prochaine étape consiste à contacter mon courtier, mais je doute qu'il soit disposé à créer un symbole pour une paire de devises dont il n'a pas l'équivalent exact.

    D'autres suggestions ?

    Dans mon cas, la devise de base du fournisseur de signaux est l'UST (pour USDT), que mon courtier n'a pas. Si un développeur MT5 lit ceci, merci d'ajouter un moyen de spécifier le taux de conversion manuellement (idéalement utilisable même pour les paires de devises qui existent, en tant que surcharge manuelle), ou au moins d'ajouter UST comme synonyme reconnu de USD. Peut-être aussi supprimer la demande (présumée) d'une nouvelle liste de symboles lors de l'ouverture d'une transaction (ne le faire qu'une fois lorsque l'on commence à suivre un signal, ou périodiquement, mais pas à nouveau à ces moments les plus critiques). Merci de votre compréhension.

    Votre abonnement au signal copie des transactions à partir d'un symbole que votre courtier n'a pas ?

    Honnêtement, je n'ai rien compris à votre message.

     
    Alain Verleyen #:

    Votre abonnement au signal copie les transactions d'un symbole que votre courtier n'a pas ?

    Honnêtement, je n'ai rien compris à votre message.

    @Alain Verleyen Je n'ai vu votre réponse que maintenant, j'espère que le fait de vous taguer vous permettra de voir la mienne plus rapidement. Désolé pour la confusion et merci d'essayer de comprendre. Permettez-moi d'essayer d'expliquer :

    Non, l'abonnement au signal ne copie pas les transactions des symboles que mon courtier n'a pas. Cet article ne concerne pas les symboles utilisés dans les transactions.

    Je parle des devises des comptes - ceux du fournisseur de signaux et ceux de l'abonné. Dans mon cas, le fournisseur de signaux utilise Bybit et la devise de son compte est UST. Mon courtier n'a pas de paire de devises avec l'UST et n'a pas de comptes en UST (il en a en USD). La devise de mon compte est l'AUD (mais il pourrait tout aussi bien s'agir de l'USD - nous aurions toujours le même problème de délai).

    Ce qui se passe, c'est que MT5 (le terminal local et le VPS MQL5 se comportent de la même manière) essaie et échoue à rechercher un taux de conversion pour les devises du compte afin de déterminer l'échelonnement de la taille de la position. Il le fait lorsqu'il commence à suivre un signal, le répète de temps en temps, et le fait également à chaque fois que le fournisseur du signal effectue une nouvelle transaction, avant de transmettre cette transaction à mon courtier. C'est compréhensible - il veut vraiment s'assurer de la bonne taille de la transaction - mais dans ce cas, il échoue toujours de toute façon, causant un retard inutile dans la copie et affectant grandement la rentabilité de certaines stratégies (en particulier, d'un certain EA très populaire auprès des fournisseurs de signaux, ainsi qu'avec des stratégies de breakout où le prix bouge beaucoup à la seconde même).

    Comme cela est connu et documenté, lorsque le mappage des devises du compte échoue de la sorte, la plateforme revient à un ratio de 1:1 entre les devises. Cela signifie que le risque (et la récompense) augmente modérément pour moi avec l'AUD, ce qui me convient dans ce cas. Mon premier problème est donc le délai, et le second l'impossibilité de spécifier le taux de conversion manuellement (ce qui résoudrait également le problème du délai, et serait donc une excellente solution pour les deux problèmes à la fois).

     
    playgold #:

    @Alain Verleyen Je n'ai vu votre réponse que maintenant, j'espère que le fait de vous taguer vous permettra de voir la mienne plus rapidement. Désolé pour la confusion et merci d'essayer de comprendre. Permettez-moi d'essayer d'expliquer :

    Non, l'abonnement au signal ne copie pas les transactions des symboles que mon courtier n'a pas. Ce post ne concerne pas les symboles utilisés dans les transactions.

    Je parle des devises de compte - celles du fournisseur de signaux et celles de l'abonné. Dans mon cas, le fournisseur de signaux utilise Bybit et la devise de son compte est UST. Mon courtier n'a pas de paire de devises avec l'UST et n'a pas de comptes en UST (il en a en USD). La devise de mon compte est l'AUD (mais il pourrait tout aussi bien s'agir de l'USD - nous aurions toujours le même problème de délai).

    Ce qui se passe, c'est que MT5 (le terminal local et le VPS MQL5 se comportent de la même manière) essaie et échoue à rechercher un taux de conversion pour les devises du compte afin de déterminer l'échelonnement de la taille de la position. Il le fait lorsqu'il commence à suivre un signal, le répète de temps en temps, et le fait également à chaque fois que le fournisseur du signal effectue une nouvelle transaction, avant de transmettre cette transaction à mon courtier. C'est compréhensible - il veut vraiment s'assurer de la bonne taille de la transaction - mais dans ce cas, il échoue toujours de toute façon, causant un retard inutile dans la copie et affectant grandement la rentabilité de certaines stratégies (en particulier, d'un certain EA très populaire auprès des fournisseurs de signaux, ainsi qu'avec des stratégies de breakout où le prix bouge beaucoup à la seconde même).

    Comme cela est connu et documenté, lorsque le mappage des devises du compte échoue de la sorte, la plateforme revient à un ratio de 1:1 entre les devises. Cela signifie que le risque (et la récompense) augmente modérément pour moi avec l'AUD, ce qui me convient dans ce cas. Mon premier problème est donc le délai, et le second l'impossibilité de spécifier le taux de conversion manuellement (ce qui résoudrait également le problème du délai, et serait donc une excellente solution pour les deux problèmes à la fois).

    Veuillez fournir les journaux qui confirment ce que vous avez rapporté. Merci de votre compréhension.
     
    Alain Verleyen #:
    Veuillez fournir les journaux à l'appui de ce que vous avez signalé. Merci.

    @Alain Verleyen Voici un extrait de journal d'un VPS MQL5. J'ai caviardé mon numéro de compte et omis quelques lignes non pertinentes. Notez le délai de 1,1 seconde entre 08:07:53.297 et 08:07:54.398 (où cela fait mal puisqu'une transaction était en cours de traitement), et le même délai avait été observé auparavant entre 04:10:43.808 et 04:10:44.908 (où cela n'avait pas d'importance puisqu'il s'agissait simplement d'une reconnexion au serveur d'échange). Il semble donc que la même opération lente soit tentée dans les deux cas. Cet extrait spécifique provient de 20260302.log, que j'ai choisi parce qu'il y a eu un redémarrage du VPS à cette date, pour vous montrer le numéro de build du terminal. Cependant, le même problème s'est produit avec des versions plus anciennes, et a continué à se produire les jours suivants.

    LO      0       00:12:40.488    Terminal        MetaTrader 5 x64 build 5662 started for MetaQuotes Ltd.
    QF      0       00:12:40.493    Terminal        Windows Server 2022 build 20348, 64 x AMD EPYC 7542 32-Core, AVX2, 476 / 511 Gb memory, 1465 / 1677 Gb disk, admin, GMT+1
    ...
    JM      1       00:12:54.656    Signal  '777777': no conversion rate for the deposit currency of provider (UST) and subscriber (AUD), 1:1 ratio will be used
    ...
    ES      0       03:12:52.741    Network '777777': authorized on FusionMarkets-Live through Access Server NY-3 (ping: 0.77 ms, build 5430)
    EO      0       03:12:52.796    Network '777777': terminal synchronized with Fusion Markets Pty Ltd: 0 positions, 0 orders, 248 symbols, 0 spreads
    CL      0       03:12:52.796    Network '777777': trading has been enabled - hedging mode
    PF      0       03:12:52.803    Terminal        '777777': 1 chart, 1 EA, 0 custom indicators, signal enabled
    GQ      0       03:12:54.666    Terminal        '777777': 1 chart, 1 EA, 0 custom indicators, signal enabled, last known ping to Access Server NY-3 is 0.77 ms
    CD      0       03:12:54.702    Network '777777': ping to current access point Access Server NY-3 is 0.76 ms [next point Access Server - NY-NEW-2 is 2.44 ms]
    MG      0       03:12:55.810    Terminal        RAM: 4287 Mb reserved, 59 Mb committed; CPU: EA 0.00% in 1 threads, symbols 0.00% in 1 threads, workers 0.00% in 8 threads, 1624 kb written on disk
    GR      0       04:10:43.808    Signal  '777777': signal provider has balance 15 708.85 UST, leverage 1:500; subscriber has balance 6 877.01 AUD, leverage 1:500
    OM      1       04:10:44.908    Signal  '777777': no conversion rate for the deposit currency of provider (UST) and subscriber (AUD), 1:1 ratio will be used
    JM      0       04:10:44.908    Signal  '777777': percentage for volume conversion selected according to the ratio of balances and leverages, new value 40%
    QR      0       04:10:44.908    Signal  '777777': synchronization finished successfully
    OO      0       04:10:45.878    Signal  '777777': ping to signal server 242.18 ms, to trade server 308.82 ms
    RJ      0       04:12:55.635    Terminal        '777777': 1 chart, 1 EA, 0 custom indicators, signal enabled, last known ping to Access Server NY-3 is 0.76 ms
    II      0       04:12:55.666    Network '777777': ping to current access point Access Server NY-3 is 0.57 ms [next point Access Server - NY-NEW-1 is 2.27 ms]
    HH      0       04:12:56.764    Terminal        RAM: 4287 Mb reserved, 59 Mb committed; CPU: EA 0.00% in 1 threads, symbols 0.00% in 1 threads, workers 0.00% in 8 threads, 279 kb written on disk
    KS      0       05:12:56.628    Terminal        '777777': 1 chart, 1 EA, 0 custom indicators, signal enabled, last known ping to Access Server NY-3 is 0.57 ms
    PR      0       05:12:56.658    Network '777777': ping to current access point Access Server NY-3 is 0.63 ms [next point Access Server - NY-NEW-1 is 2.11 ms]
    PE      0       05:12:57.764    Terminal        RAM: 4285 Mb reserved, 61 Mb committed; CPU: EA 0.00% in 1 threads, symbols 0.00% in 1 threads, workers 0.00% in 8 threads, 3848 kb written on disk
    QJ      0       06:12:52.404    Network '777777': scanning network for access points
    HD      0       06:12:52.449    Network '777777': ping to current access point Access Server NY-3 is 0.74 ms [next point Access Server - NY-NEW-1 is 2.63 ms]
    JH      0       06:12:52.449    Network '777777': scanning network finished
    PL      0       06:12:57.604    Terminal        '777777': 1 chart, 1 EA, 0 custom indicators, signal enabled, last known ping to Access Server NY-3 is 0.74 ms
    FO      0       06:12:57.639    Network '777777': ping to current access point Access Server NY-3 is 0.64 ms [next point Access Server - NY-NEW-2 is 2.43 ms]
    PR      0       06:12:58.737    Terminal        RAM: 4285 Mb reserved, 61 Mb committed; CPU: EA 0.00% in 1 threads, symbols 0.00% in 1 threads, workers 0.00% in 8 threads, 306 kb written on disk
    LE      0       07:12:58.582    Terminal        '777777': 1 chart, 1 EA, 0 custom indicators, signal enabled, last known ping to Access Server NY-3 is 0.64 ms
    HH      0       07:12:58.618    Network '777777': ping to current access point Access Server NY-3 is 0.73 ms [next point Access Server - NY-NEW-2 is 2.44 ms]
    GI      0       07:12:59.726    Terminal        RAM: 4285 Mb reserved, 61 Mb committed; CPU: EA 0.00% in 1 threads, symbols 0.00% in 1 threads, workers 0.00% in 8 threads, 280 kb written on disk
    EL      0       08:07:53.297    Signal  '777777': signal provider performed deal #138115330 acheter 0,16 XAUUSD+ à 5394,41
    EL      1       08:07:54.398    Signal  '777777': no conversion rate for the deposit currency of provider (UST) and subscriber (AUD), 1:1 ratio will be used
    NL      0       08:07:54.398    Trades  '777777': market buy 0.06 XAUUSD sl: 5355.99 tp: 5443.42
     
    playgold #:

    @Alain Verleyen Voici un extrait de log d'un VPS MQL5. J'ai caviardé mon numéro de compte et omis quelques lignes non pertinentes. Notez le délai de 1,1 seconde entre 08:07:53.297 et 08:07:54.398 (où cela fait mal puisqu'une transaction était en cours de traitement), et le même délai ayant été observé auparavant entre 04:10:43.808 et 04:10:44.908 (où cela n'avait pas d'importance puisqu'il s'agissait simplement d'une reconnexion au serveur d'échange). Il semble donc que la même opération lente soit tentée dans les deux cas. Cet extrait spécifique provient de 20260302.log, que j'ai choisi parce qu'il y a eu un redémarrage du VPS à cette date, pour vous montrer le numéro de build du terminal. Cependant, le même problème s'est produit avec des versions plus anciennes, et a continué à se produire les jours suivants.

    Merci. Ce délai devrait être supprimé à partir de la version 5676. Merci de confirmer car je ne peux pas tester moi-même.
     
    Alain Verleyen #:
    Merci. Ce délai devrait être supprimé à partir de la version 5676. Merci de confirmer car je ne peux pas tester moi-même.
    @Alain Verleyen Merci, c'était rapide ! J'ai arrêté de suivre les signaux de Bybit pour l'instant en grande partie à cause du retard, donc je vais devoir suivre à nouveau l'un d'entre eux pour tester. Est-ce que cette version est déjà disponible dans les VPS MQL, que j'utilise, ou quand le sera-t-elle (ou plus récente) ?