OPEN-SOURCE SCRIPT
State Machine Entry Debugger
State Machine Entry Debugger - CoffeeKiller
State Machine Entry Debugger - CoffeeKiller is a development and diagnostic indicator designed to make a strategy's long-entry process visible on the chart.
Many strategies do not enter immediately when one condition becomes true. Instead, they move through a sequence of internal states. That sequence may include detecting a setup area, validating filters, waiting for confirmation, checking execution permission, and finally producing an entry signal.
These internal stages are normally invisible. A developer may see only the final strategy order and assume the entry was delayed without knowing which part of the logic caused the delay.
This indicator turns that hidden process into a visible chart timeline.
Important
This is not a standalone trading system.
The included EMA, ATR, pullback, and breakout conditions are placeholders used only to demonstrate how the debugger operates. They are not intended as production trading signals.
The current example is designed for long-entry debugging only. It does not contain a separate short-side state machine.
Entry Sequence
The debugger tracks the following sequence:
Touch
Price reaches or interacts with the defined setup area.
ARM
The setup passes its required filters and becomes eligible to wait for a trigger.
Trigger
The strategy's confirmation condition becomes true.
Entry Signal
All setup, filter, trigger, and final permission requirements have passed.
Reset
The example state machine returns to its idle state and waits for another setup.
Why This Tool Exists
A strategy may appear to enter late for several different reasons:
Without a debugger, these situations may all appear to be the same problem: a late entry.
This script separates those possibilities.
Confirmed-Bar State Transitions
The state machine advances only when the candle is confirmed:
Pine Script®
This means a state transition is committed only after the candle closes.
This behavior is intended to match strategies that evaluate their entry logic at bar close.
Without confirmed-bar gating, a condition may temporarily become true while the realtime candle is forming. Touch, ARM, Trigger, or Entry labels could then appear, disappear, or move before the candle closes.
That can make an indicator appear to react earlier than the strategy it is supposed to diagnose.
By waiting for candle confirmation, the debugger provides a more consistent comparison with bar-close strategy logic.
A strategy that intentionally calculates intrabar requires a debugger configured to reproduce its execution behavior.
Relevant strategy settings and behaviors may include:
The debugger and the strategy must use equivalent assumptions before their results can be compared accurately.
Entry Signal Versus Strategy Fill
The green Entry Signal marker identifies the bar where the state machine determines that all entry requirements have passed.
It does not necessarily represent the strategy broker emulator's actual fill bar or fill price.
Under the normal strategy execution model, an order created after a bar closes is generally filled at the next available tick. For a bar-close strategy, that commonly means the open of the next bar.
The chart may therefore show:
That one-bar difference is not automatically a bug.
A strategy using the following setting may instead process an order at the close of the signal bar:
Pine Script®
When comparing the debugger with a strategy, determine whether you are comparing:
These events are related, but they are not always identical.
One Transition Per Bar
The example state machine intentionally allows only one transition per confirmed bar.
A completed sequence may therefore appear as:
This occurs because the transition logic uses an if / else if structure.
Even when several conditions are already true, the state machine cannot move through multiple stages during the same bar. It must begin the bar in the required prior state before it can advance.
This behavior is useful for exposing structural delays.
For example, the market may satisfy the setup filters and breakout condition on the same candle, but the state machine may still require separate bars for Touch, ARM, Trigger, and Entry Signal.
In that situation, the apparent delay is caused by the state-machine architecture rather than by the market conditions.
This design is intentional for debugging purposes.
A strategy that permits multiple transitions on the same bar requires a different transition structure.
What the Debugger Displays
The script can display event labels for:
It can also display blocked-condition labels for:
A blocked label identifies the first condition preventing the current state from advancing on a confirmed bar.
A blocked condition does not automatically mean the strategy is malfunctioning.
For example, while an armed setup is waiting for confirmation, the trigger condition should normally remain false. A Waiting Trigger label may simply indicate that the state machine is operating as designed.
Timeline Measurements
The debugger measures the number of confirmed bars between the major state transitions:
These measurements help distinguish between:
The debugger also tracks:
State Background
Optional chart-background colors show the current internal state:
The green state represents the debugger's logical Entry Signal state. It should not automatically be interpreted as the strategy's broker-emulator fill.
Debug Table
The on-chart table shows the latest state and condition information, including:
Conditions are displayed as PASS or FAIL.
A FAIL value means only that the condition is currently false. Whether that is expected depends on the current state.
The table displays condition values for the latest chart bar. On a forming realtime candle, those values may continue to change, but the state machine will not advance until the candle closes.
Data Window Values
The indicator also sends its internal values to the PulseWire Data Window.
This allows developers to inspect individual historical bars and compare the debugger with the original strategy.
Available values include:
Boolean values appear as:
Placeholder Logic
The included conditions exist only so the indicator can compile and demonstrate its operation.
The main placeholder variables are:
Pine Script®
Replace these variables with the exact conditions from the strategy being diagnosed.
For an accurate comparison, developers should also reproduce the strategy's:
Suggested Implementation Process
Start with a duplicate of the strategy you want to diagnose.
Assign the condition that begins the setup to:
Pine Script®
Assign the setup-validation requirements to:
Pine Script®
Assign the actual confirmation event to:
Pine Script®
Assign final execution restrictions to:
Pine Script®
Then compare the debugger's Touch, ARM, Trigger, and Entry Signal markers with the strategy's signal condition, order creation, order marker, and broker-emulator fill.
Do not assume that the debugger's Entry Signal and the strategy's fill marker should always appear on the same bar.
Recommended Debugging Method
First reproduce the strategy's existing behavior exactly.
Do not begin by removing filters or forcing earlier entries.
Once the debugger and strategy agree, change one part of the logic at a time.
This helps determine whether an entry delay comes from:
The goal is not simply to make the strategy enter earlier.
The goal is to understand why it entered when it did.
Current Design Limitations
This version uses long-side placeholder logic.
It does not contain an independent short-side state machine.
Although the placeholder conditions can be replaced with bearish conditions, a complete two-direction debugger should normally use independent long and short state machines. This prevents one direction's setup from overwriting or blocking the other direction's state.
The example resets immediately after reaching the Entry Signal state.
A production strategy should replace that behavior with its actual:
The debugger intentionally permits only one transition per confirmed bar.
Because this script is an indicator rather than a strategy, it does not simulate:
Labels may become crowded across long historical ranges. The recent-bars setting can be used to reduce chart clutter.
Final Purpose
State Machine Entry Debugger converts an invisible decision process into a visible chart timeline.
Instead of seeing only the final strategy entry, developers can inspect:
This makes complex state-machine behavior easier to test, explain, and improve.
Disclaimer
This indicator is intended solely for educational, informational, diagnostic, and software-development purposes.
It is not a trading system and should not be interpreted as a recommendation to buy or sell any financial instrument.
The included conditions are placeholders and are not presented as a profitable or complete trading methodology.
Trading involves substantial risk of loss. Historical behavior, simulated performance, and strategy results do not guarantee future performance.
Always perform your own analysis, thoroughly test all strategy logic, account for realistic execution conditions, and consult a qualified financial professional when appropriate before risking real capital.
State Machine Entry Debugger - CoffeeKiller is a development and diagnostic indicator designed to make a strategy's long-entry process visible on the chart.
Many strategies do not enter immediately when one condition becomes true. Instead, they move through a sequence of internal states. That sequence may include detecting a setup area, validating filters, waiting for confirmation, checking execution permission, and finally producing an entry signal.
These internal stages are normally invisible. A developer may see only the final strategy order and assume the entry was delayed without knowing which part of the logic caused the delay.
This indicator turns that hidden process into a visible chart timeline.
Important
This is not a standalone trading system.
The included EMA, ATR, pullback, and breakout conditions are placeholders used only to demonstrate how the debugger operates. They are not intended as production trading signals.
The current example is designed for long-entry debugging only. It does not contain a separate short-side state machine.
Entry Sequence
The debugger tracks the following sequence:
Touch -> ARM -> Trigger -> Entry Signal -> Reset
Touch
Price reaches or interacts with the defined setup area.
ARM
The setup passes its required filters and becomes eligible to wait for a trigger.
Trigger
The strategy's confirmation condition becomes true.
Entry Signal
All setup, filter, trigger, and final permission requirements have passed.
Reset
The example state machine returns to its idle state and waits for another setup.
Why This Tool Exists
A strategy may appear to enter late for several different reasons:
- A setup filter remained false.
- The trigger occurred several bars after the initial touch.
- The setup expired before confirmation.
- Entry permission blocked execution.
- The state machine required each stage to begin on a separate bar.
- The strategy waited for the candle to close.
- The debugger and strategy used different realtime calculation behavior.
- The strategy created an order on one bar but filled it on the next.
- Reset or cancellation logic removed the setup.
Without a debugger, these situations may all appear to be the same problem: a late entry.
This script separates those possibilities.
Confirmed-Bar State Transitions
The state machine advances only when the candle is confirmed:
This means a state transition is committed only after the candle closes.
This behavior is intended to match strategies that evaluate their entry logic at bar close.
Without confirmed-bar gating, a condition may temporarily become true while the realtime candle is forming. Touch, ARM, Trigger, or Entry labels could then appear, disappear, or move before the candle closes.
That can make an indicator appear to react earlier than the strategy it is supposed to diagnose.
By waiting for candle confirmation, the debugger provides a more consistent comparison with bar-close strategy logic.
A strategy that intentionally calculates intrabar requires a debugger configured to reproduce its execution behavior.
Relevant strategy settings and behaviors may include:
- calc_on_every_tick
- calc_on_order_fills
- process_orders_on_close
- Wick-based versus close-based confirmation
- Higher-timeframe data behavior
- Session filters
- Time filters
The debugger and the strategy must use equivalent assumptions before their results can be compared accurately.
Entry Signal Versus Strategy Fill
The green Entry Signal marker identifies the bar where the state machine determines that all entry requirements have passed.
It does not necessarily represent the strategy broker emulator's actual fill bar or fill price.
Under the normal strategy execution model, an order created after a bar closes is generally filled at the next available tick. For a bar-close strategy, that commonly means the open of the next bar.
The chart may therefore show:
Debugger Entry Signal on the current bar
Strategy fill on the next bar
That one-bar difference is not automatically a bug.
A strategy using the following setting may instead process an order at the close of the signal bar:
When comparing the debugger with a strategy, determine whether you are comparing:
- The signal bar
- The order-creation bar
- The broker-emulator fill bar
- The recorded fill price
These events are related, but they are not always identical.
One Transition Per Bar
The example state machine intentionally allows only one transition per confirmed bar.
A completed sequence may therefore appear as:
- Bar 1: Touch
- Bar 2: ARM
- Bar 3: Trigger
- Bar 4: Entry Signal
This occurs because the transition logic uses an if / else if structure.
Even when several conditions are already true, the state machine cannot move through multiple stages during the same bar. It must begin the bar in the required prior state before it can advance.
This behavior is useful for exposing structural delays.
For example, the market may satisfy the setup filters and breakout condition on the same candle, but the state machine may still require separate bars for Touch, ARM, Trigger, and Entry Signal.
In that situation, the apparent delay is caused by the state-machine architecture rather than by the market conditions.
This design is intentional for debugging purposes.
A strategy that permits multiple transitions on the same bar requires a different transition structure.
What the Debugger Displays
The script can display event labels for:
- Touch
- ARM
- Trigger
- Entry Signal
- Touch expiration
- ARM expiration
- State reset
It can also display blocked-condition labels for:
- Trend filter
- Quality filter
- Extension filter
- Trigger condition
- Entry permission
A blocked label identifies the first condition preventing the current state from advancing on a confirmed bar.
A blocked condition does not automatically mean the strategy is malfunctioning.
For example, while an armed setup is waiting for confirmation, the trigger condition should normally remain false. A Waiting Trigger label may simply indicate that the state machine is operating as designed.
Timeline Measurements
The debugger measures the number of confirmed bars between the major state transitions:
- Touch to ARM
- ARM to Trigger
- Trigger to Entry Signal
- Touch to Entry Signal
These measurements help distinguish between:
- Filter delay
- Trigger delay
- Permission delay
- State-sequencing delay
- Timeout behavior
The debugger also tracks:
- Bars since Touch
- Bars since ARM
- Bars since Trigger
State Background
Optional chart-background colors show the current internal state:
- Blue: Touched
- Orange: Armed
- Purple: Triggered
- Green: Entry Signal reached
- No background: Idle
The green state represents the debugger's logical Entry Signal state. It should not automatically be interpreted as the strategy's broker-emulator fill.
Debug Table
The on-chart table shows the latest state and condition information, including:
- Current state
- Last event
- Last blocking condition
- Touch condition
- Trend filter
- Quality filter
- Extension filter
- Trigger condition
- Entry permission
- Bars since Touch
- Bars since ARM
- Bars since Trigger
- ATR extension distance
- Confirmed-bar status
- Realtime-bar status
- Current bar index
Conditions are displayed as PASS or FAIL.
A FAIL value means only that the condition is currently false. Whether that is expected depends on the current state.
The table displays condition values for the latest chart bar. On a forming realtime candle, those values may continue to change, but the state machine will not advance until the candle closes.
Data Window Values
The indicator also sends its internal values to the PulseWire Data Window.
This allows developers to inspect individual historical bars and compare the debugger with the original strategy.
Available values include:
- State number
- Touch condition
- Trend filter
- Quality filter
- Extension filter
- Trigger condition
- Entry permission
- ATR extension distance
- Bars since Touch
- Bars since ARM
- Bars since Trigger
- Same-bar transition checks
- Confirmed-bar status
- Realtime-bar status
Boolean values appear as:
1 = true
0 = false
Placeholder Logic
The included conditions exist only so the indicator can compile and demonstrate its operation.
The main placeholder variables are:
Replace these variables with the exact conditions from the strategy being diagnosed.
For an accurate comparison, developers should also reproduce the strategy's:
- Price sources
- Wick or close confirmation rules
- Session restrictions
- Time restrictions
- Higher-timeframe requests
- Position-state restrictions
- Pyramiding behavior
- Cooldown rules
- Cancellation logic
- Rearm logic
- Order-processing settings
Suggested Implementation Process
Start with a duplicate of the strategy you want to diagnose.
Assign the condition that begins the setup to:
Assign the setup-validation requirements to:
Assign the actual confirmation event to:
Assign final execution restrictions to:
Then compare the debugger's Touch, ARM, Trigger, and Entry Signal markers with the strategy's signal condition, order creation, order marker, and broker-emulator fill.
Do not assume that the debugger's Entry Signal and the strategy's fill marker should always appear on the same bar.
Recommended Debugging Method
First reproduce the strategy's existing behavior exactly.
Do not begin by removing filters or forcing earlier entries.
Once the debugger and strategy agree, change one part of the logic at a time.
This helps determine whether an entry delay comes from:
- The market setup
- A filter
- The trigger
- Entry permission
- A timeout
- State sequencing
- Bar-close confirmation
- Intrabar calculation
- Order-fill timing
- Reset or cancellation behavior
The goal is not simply to make the strategy enter earlier.
The goal is to understand why it entered when it did.
Current Design Limitations
This version uses long-side placeholder logic.
It does not contain an independent short-side state machine.
Although the placeholder conditions can be replaced with bearish conditions, a complete two-direction debugger should normally use independent long and short state machines. This prevents one direction's setup from overwriting or blocking the other direction's state.
The example resets immediately after reaching the Entry Signal state.
A production strategy should replace that behavior with its actual:
- Position-entry handling
- Exit handling
- Setup cancellation
- Rearm rules
- Cooldown period
- Opposite-signal behavior
The debugger intentionally permits only one transition per confirmed bar.
Because this script is an indicator rather than a strategy, it does not simulate:
- Strategy orders
- Position sizing
- Pyramiding
- Commissions
- Slippage
- Broker-emulator fills
Labels may become crowded across long historical ranges. The recent-bars setting can be used to reduce chart clutter.
Final Purpose
State Machine Entry Debugger converts an invisible decision process into a visible chart timeline.
Instead of seeing only the final strategy entry, developers can inspect:
- Where the setup began
- When it became armed
- Which condition delayed it
- When the trigger occurred
- When the logical entry signal became valid
- Whether the setup expired or reset
- Whether the apparent delay came from state logic or order-fill timing
This makes complex state-machine behavior easier to test, explain, and improve.
Disclaimer
This indicator is intended solely for educational, informational, diagnostic, and software-development purposes.
It is not a trading system and should not be interpreted as a recommendation to buy or sell any financial instrument.
The included conditions are placeholders and are not presented as a profitable or complete trading methodology.
Trading involves substantial risk of loss. Historical behavior, simulated performance, and strategy results do not guarantee future performance.
Always perform your own analysis, thoroughly test all strategy logic, account for realistic execution conditions, and consult a qualified financial professional when appropriate before risking real capital.
Open-source script
In true PulseWire spirit, the creator of this script has made it open-source, so that traders can review and verify its functionality. Kudos to the author! While you can use it for free, remember that republishing the code is subject to our House Rules.
Disclaimer
The information and publications are not meant to be, and do not constitute, financial, investment, trading, or other types of advice or recommendations supplied or endorsed by PulseWire. Read more in the Terms of Use.
Open-source script
In true PulseWire spirit, the creator of this script has made it open-source, so that traders can review and verify its functionality. Kudos to the author! While you can use it for free, remember that republishing the code is subject to our House Rules.
Disclaimer
The information and publications are not meant to be, and do not constitute, financial, investment, trading, or other types of advice or recommendations supplied or endorsed by PulseWire. Read more in the Terms of Use.