SHARKRULE / Aprender

Datos desactualizados en un bot: comprueba cuándo ocurrieron y cuándo se usaron

Un precio recibido ahora puede corresponder a un evento de mercado anterior. Antes de interpretar la señal de un bot de trading, comprueba qué representa el valor, cuándo ocurrió el evento, cuándo lo recibió la herramienta y cuándo lo evaluó la regla. Un dato antiguo puede demostrar que una condición se cumplía antes; por sí solo no demuestra el estado actual del mercado. Si falta un dato necesario, el resultado es desconocido: no equivale a un precio de cero ni demuestra que la condición sea falsa.

SharkRule · Revisado

Distingue el evento de mercado, la recepción y la evaluación

La hora del evento corresponde a un hecho registrado por la fuente. La hora de recepción indica cuándo la herramienta registra su llegada. La hora de evaluación es cuando la regla utiliza el dato. Con relojes sincronizados y comparables, recepción menos evento da el retraso aparente de llegada; evaluación menos recepción da la espera local; evaluación menos evento da la antigüedad del evento al decidir. El retraso de llegada puede incluir procesamiento en origen, transporte y errores de reloj: no mide únicamente la demora de la red.

Comprueba la definición de cada campo antes de restar horas. El flujo de operaciones Spot de Binance distingue la hora del evento E de la hora de la operación T; en el flujo de velas, k.T es la hora de cierre de la vela. Son significados distintos. La herramienta debe registrar su propia hora de recepción. Si la fuente no proporciona la marca de tiempo que necesitas, esa parte del diagnóstico sigue siendo desconocida. Una recepción reciente no permite fechar por sí sola la observación original.

El precio de la última operación, los precios actuales de compra y venta del libro y el cierre de una vela terminada responden a preguntas diferentes. Un cierre reciente resume un intervalo; no garantiza que alguien vaya a operar a ese precio ahora. Compara el mismo exchange, par Spot y campo de precio antes de concluir que dos pantallas se contradicen.

Ejemplo: recibido hace poco no significa observado hace poco

Todos los precios y horas de este ejemplo son hipotéticos. En un mercado Spot sin identificar, una regla comprueba si el precio observado es igual o inferior a 100. Este ejercicio solo acepta observaciones cuya antigüedad desde el evento no supere cinco segundos al evaluarlas, con relojes sincronizados. Cinco segundos es un límite inventado para el ejemplo: no es una recomendación, una exigencia del exchange ni un ajuste de SharkRule. En este ejercicio no se envía ninguna orden.

En la primera fila, el retraso aparente de llegada es de 4 segundos y la espera local de 5 segundos: la antigüedad total es 4 + 5 = 9 segundos. Aunque 99 es inferior a 100, la observación incumple el requisito de vigencia del ejemplo. No demuestra que la condición se cumpla ahora.

Registro hipotético; horas en UTC y precios en unidades de la moneda de cotización
Hora del eventoRecepciónEvaluaciónPrecioAntigüedad del eventoInterpretación
12:00:0012:00:0412:00:09999 segundosDemasiado antiguo para el ejemplo; condición actual desconocida
12:00:1012:00:1112:00:121012 segundosSuficientemente reciente para el ejemplo; 101 ≤ 100 es falso
12:00:0312:00:1312:00:139810 segundosEvento anterior recibido con retraso; no es una observación más reciente del precio actual

Recuperar datos permite volver a comprobar, no ejecutar una señal antigua

En la segunda fila, el retraso de llegada es de 1 segundo y la espera local de 1 segundo: el evento tiene 2 segundos de antigüedad. El ejemplo ya permite volver a evaluar la condición, que resulta falsa. Recuperar datos utilizables no significa actuar con el antiguo valor de 99. En la tercera fila, el último mensaje recibido describe un evento ocurrido siete segundos antes que el de la segunda fila. Consérvalo como histórico; no sustituyas sin advertencia la observación más reciente por ese dato anterior.

Comprueba por separado la validez del dato y la comparación de precios. Aquí puede haber evidencia insuficiente, evidencia utilizable con condición falsa o evidencia utilizable con condición verdadera. Incluso este último resultado exigiría comprobar los permisos, límites y demás requisitos de la regla. La cronología enseña a razonar sobre observaciones; no describe el algoritmo interno de consulta o recuperación de SharkRule.

Una vela ausente y una vela sin terminar requieren comprobaciones distintas

Una vela actualizada hace poco puede seguir en formación. A la inversa, una vela cerrada puede llegar tarde. El flujo de velas de Binance indica el cierre por separado mediante k.x; sus registros REST de velas se identifican por la hora de apertura. Comprueba el intervalo y sus límites antes de contar registros. Si el cálculo necesita tres velas consecutivas de un minuto y tienes aperturas a las 12:00, 12:01 y 12:03, esas tres filas no aportan tres minutos consecutivos: falta 12:02.

Un hueco puede deberse a un fallo de recogida, una respuesta incompleta o la forma documentada en que el exchange trata los intervalos sin operaciones. Por ejemplo, Upbit indica que no genera una vela de minuto si no hubo operaciones durante ese intervalo. Es una regla de Upbit; no describe Binance ni demuestra una conexión de SharkRule con Upbit. Verifica el criterio de la fuente antes de atribuir el hueco a una interrupción.

Mantén visible cualquier hueco sin explicar. Sustituirlo por cero inventa un precio; copiar el cierre anterior inventa una observación. Ambas cosas pueden alterar el cálculo de la regla. Recupera, cuando sea posible, los registros necesarios del mismo mercado e intervalo, y deja constancia de cuáles se observaron realmente y cuáles se reconstruyeron. Un gráfico visualmente continuo no demuestra que su serie de datos esté completa.

Qué revisar cuando una regla espera datos de mercado

Usa esta lista para preparar un breve registro del diagnóstico. No todas las herramientas muestran cada hora o ajuste: anota desconocido cuando no haya evidencia. No aumentes el presupuesto ni suavices la condición de precio solo para conseguir que una regla en espera actúe.

  1. Identifica exchange, par Spot, versión de la regla y dato necesario: última operación, precios de compra y venta, cierre de vela o indicador. Mantén la misma fuente de datos.
  2. Anota el significado, las unidades y la zona horaria de la marca de tiempo original, además de las horas de recepción y evaluación disponibles. Segundos y milisegundos no son intercambiables. Comprueba la sincronización de los relojes antes de interpretar una antigüedad negativa o inesperadamente grande.
  3. Revisa por separado la conexión y la última actualización de mercado utilizable. Un mensaje de conexión o una solicitud correcta no demuestra que haya una observación reciente del precio. Un mercado con poca actividad puede no registrar nuevas operaciones aunque la conexión funcione.
  4. Para las velas, revisa los límites de los intervalos, el cierre, los duplicados y los huecos de toda la ventana que necesita la regla. Una última fila reciente no repara un dato anterior ausente.
  5. Registra el motivo real de la espera y la última observación válida. Vuelve a comprobar la regla guardada con datos actuales y completos, sin cambiar los límites; no intentes ejecutar después todas las oportunidades aparentes de la interrupción.
  6. Si ya se envió una orden real, revisa por separado esa orden original y sus ejecuciones. Recuperar datos no resuelve un envío de resultado desconocido, no cancela una orden abierta ni autoriza otra de sustitución.

Error frecuente: confundir una conexión activa con un precio actualizado

Binance documenta que su API es asíncrona y que el retraso de actualización puede variar entre fuentes de datos. Por tanto, recibir una respuesta correcta no certifica la vigencia del dato. Tampoco una hora antigua de la última operación demuestra que el flujo esté averiado: primero distingue un mercado tranquilo de actualizaciones perdidas, según el comportamiento documentado de la fuente. No existe una antigüedad máxima universal adecuada para todos los datos y reglas.

Repetir solicitudes sin control puede dificultar el diagnóstico. Respeta los límites de solicitudes y las instrucciones de reintento del exchange; un reintento para obtener datos no debe convertirse en una orden duplicada. Binance advierte de que agotar el tiempo de espera de una orden puede dejar su ejecución sin confirmar. Aclara esa orden en vez de interpretar que un flujo de precios activo demuestra que falló. En SharkRule, un envío a Binance sin resolver debe seguir bloqueando nuevos envíos a Binance.

Disponer de datos utilizables no reserva un precio de ejecución. Siguen existiendo comisiones, deslizamiento, ejecuciones parciales, órdenes sin ejecutar e interrupciones del exchange; los activos pueden perder valor mientras la regla espera. Una simulación no demuestra cómo se ejecutarán órdenes reales futuras. Esta guía explica el funcionamiento, no recomienda activos, distribución de capital, tamaño de posición ni estrategias. SharkRule es software independiente, no asesoramiento financiero o de inversión, y no está afiliado a los exchanges ni cuenta con su respaldo.

Siguiente paso: compara el motivo de espera con la hora de los datos

Abre la guía en español del simulador de SharkRule enlazada en Fuentes. Explica cómo revisar la marca de tiempo de los datos y esperar información reciente cuando faltan los datos necesarios. Usa esa explicación para revisar la condición, la actividad y la hora de datos disponible de un Shark compatible, junto con su presupuesto virtual, antes de decidir si inicias una simulación. La guía no confirma un límite de cinco segundos configurable por el usuario ni promete un tiempo de recuperación.

La simulación utiliza fondos virtuales y no autoriza órdenes reales en el exchange. Cualquier configuración posterior con dinero real exige su propia revisión y un inicio explícito; la disponibilidad depende del panel actual, la cuenta y la ubicación.

Preguntas frecuentes

La página acaba de actualizarse. ¿Su precio es actual?

No necesariamente. La actualización de la página, la recepción del mensaje y el evento de mercado tienen horas distintas. Revisa la marca de tiempo original y su significado. Una página recién actualizada puede mostrar un valor guardado antes.

¿La falta de datos equivale a una condición falsa?

No. Para declarar falsa una condición hacen falta datos utilizables para esa comparación. Si falta el dato necesario o es demasiado antiguo según el criterio definido por la regla, ese dato no permite establecer si la condición se cumple ahora. Registra aparte el motivo de espera.

¿Una vela de minuto ausente siempre indica un fallo de conexión?

No. Comprueba el mercado, el rango solicitado y el criterio de la fuente. Algunos exchanges omiten los intervalos sin operaciones; otros pueden representarlos de otra manera. No apliques el criterio de un exchange a otro ni inventes una vela para ocultar el hueco.

¿Los datos recientes garantizan que se ejecutará una orden?

No. La validez del dato, el permiso para actuar y la ejecución en el exchange son cosas distintas. Tras recibir información reciente puede haber movimientos de precio, comisiones, ejecuciones parciales o ninguna ejecución. Tampoco aclara el resultado de una orden enviada anteriormente.

Fuentes oficiales

Elaborado con ayuda de IA a partir de la documentación oficial enlazada. Los ejemplos son hipotéticos; no se realizaron pruebas con cuentas reales ni comparaciones de rentabilidad.