Pine Script y alertas de TradingView

alertcondition() expone condiciones de un indicador, alert() permite mensajes dinámicos y las estrategias también proporcionan eventos de ejecución de órdenes útiles para la automatización.

Comprueba la instancia de alerta del servidor y no solo el gráfico actual. Las alertas utilizan una copia guardada. El repainting, la caducidad, los errores de ejecución y los límites de frecuencia también pueden impedir una alerta.

TradingView ejecuta la copia guardada en el servidor del script, los parámetros, el símbolo y el marco temporal existentes cuando se creó la alerta. Los cambios posteriores en el gráfico no actualizan esa alerta; créala de nuevo cuando cambien su lógica o contexto.

Once Per Bar puede reaccionar durante una vela en tiempo real; Once Per Bar Close espera a la actualización de cierre. Utiliza velas confirmadas cuando la estrategia requiera confirmación y comportamiento intrabar solo si la lógica se diseñó y probó expresamente para actualizaciones en tiempo real.

Repainting significa que los resultados pasados o mostrados históricamente pueden diferir de lo que existía en tiempo real. Para automatizar, hay que saber si los datos exactos que activaron la alerta en vivo pueden cambiar después o no reproducirse en velas históricas.

Con calc_on_every_tick=true, una estrategia se recalcula con cada actualización en tiempo real y no solo al cierre de la vela. Las velas históricas no contienen el mismo flujo completo de ticks, por lo que el comportamiento en vivo puede diferir tras recargar el gráfico.

Las alertas de ejecución se activan cuando el emulador de bróker de TradingView ejecuta una orden de estrategia y suelen representar mejor esas ejecuciones. alert() ofrece más flexibilidad para lógica arbitraria en tiempo de ejecución y mensajes dinámicos.

TradingView detiene automáticamente una alerta normal o basada en script si se activa más de 15 veces en tres minutos. La lógica de alta frecuencia debe controlar la frecuencia de las alertas y no asumir que seguirán activas indefinidamente.

Usa cambios de estado explícitos, periodos de espera y una frecuencia de alerta adecuada en vez de suprimir mensajes sin criterio. TradingView puede detener una alerta de script si se activa más de 15 veces en tres minutos, por lo que los sistemas de alta frecuencia necesitan un diseño deliberado de eventos.

Crea y verifica la alerta de sustitución antes de retirar la anterior, pero evita que ambas puedan ejecutar al mismo tiempo. Las alertas de TradingView funcionan como instantáneas guardadas; modificar el script del gráfico no actualiza una alerta existente.

Sí. Crear una alerta nueva no elimina automáticamente la alerta anterior del servidor. Si ambas apuntan a la misma ruta de ejecución, pueden activarse por separado y generar comandos duplicados.

Asigna versiones explícitas a las entregas de la estrategia, las instancias de alerta y los esquemas del webhook. Así, el soporte y los registros de auditoría pueden demostrar qué lógica produjo una señal en vivo y evitar incompatibilidades silenciosas tras cambiar el script.

A veces, pero solo si el comportamiento en tiempo real es intencionado, está documentado y se ha probado. Un script que repinta puede ser válido en vivo aunque los gráficos históricos o backtests no sean una prueba fiable de lo ocurrido en tiempo real.

request.security() puede devolver en velas en tiempo real valores no confirmados de una temporalidad superior que cambian al confirmarse. TradingView documenta un patrón HTF sin repintado con un desplazamiento de una vela y barmerge.lookahead_on.

barstate.isconfirmed es verdadero en velas históricas y en la actualización final de una vela en tiempo real. Permite retrasar una señal de la temporalidad del gráfico hasta su confirmación, pero TradingView indica que no funciona como mecanismo de confirmación dentro de request.security().

calc_on_order_fills hace que una estrategia vuelva a calcularse tras una ejecución y pueda reaccionar de inmediato a cambios simulados de posición. También puede producir un comportamiento histórico irreal, por lo que exige comparar cuidadosamente el resultado en vivo con el backtest.

process_orders_on_close permite que el emulador de bróker de TradingView ejecute una orden de estrategia en el tick de cierre de la vela de señal, en vez de esperar a la siguiente vela disponible. TradingView advierte que la ejecución externa en vivo puede no reproducir ese fill, sobre todo al cerrar la sesión.

Los marcadores del gráfico, la evaluación de alertas y la ejecución real del bróker pueden referirse a momentos y precios distintos. Las actualizaciones en tiempo real, el momento del fill, el spread bid/ask, la latencia y el slippage pueden causar una diferencia legítima.

Tras recargar, las velas en tiempo real se convierten en históricas y pierden su secuencia original de actualizaciones intrabar. La lógica sensible a ticks, que repinta o exclusiva del tiempo real puede mostrar por ello un comportamiento histórico diferente.

varip conserva valores entre ejecuciones dentro de la misma vela en tiempo real y escapa al rollback normal de Pine. Las velas históricas no pueden reproducir esa secuencia intrabar, por lo que los backtests dependientes de varip pueden resultar engañosos.

Bar Magnifier usa datos de una temporalidad inferior para mejorar las suposiciones históricas de fills del emulador de bróker. Puede resolver secuencias intrabar ambiguas, pero sigue sin reproducir la ejecución de un bróker real.

Pyramiding controla las adiciones sucesivas de strategy.entry() en la misma dirección. Si cada alerta resultante se convierte en una entrada nueva en vivo, el pyramiding intencionado o accidental puede multiplicar la exposición en cTrader.