PJLink Power Status Polling: Show Warming, Cooling and Unknown Correctly

PJLink power polling should report the projector's observed state, the time of that observation and whether a command is still pending. Keep warming and cooling separate from fully on and standby. If a query times out, mark the observation stale or unknown rather than changing the projector to off.

This distinction matters during a venue opening. An operator needs to know whether a unit is progressing normally, has stopped responding or is ready to display content. A green button that merely reflects the last command hides all three situations.

Model the observation, not just the button

The Epson EB-PU series PJLink table defines the power query values as 0 for standby, 1 for on, 2 for cooling and 3 for warm-up. This is documented model-family behavior, not a timing guarantee for every projector. Keep the response interpretation and allowed transition times in the device profile.

A power-on response does not establish that the correct source is visible. Check input and signal separately when the show depends on them.

Choose a polling policy you can explain

Start with the manufacturer's communication guidance and observe response times during a bench test. Use faster, bounded polling during transitions and a slower steady-state interval when nothing changes. These intervals are commissioning choices, not universal PJLink constants.

Serialize transactions when the device or driver requires it. A new timer tick should not create another outstanding query while the previous one is pending. Bound the queue and record skipped polls so a slow projector does not accumulate minutes of stale requests.

TCP supplies an ordered byte stream, but it does not identify which application observation your UI should show. Associate each query with its session and request time. Discard a delayed result from a retired connection rather than allowing it to overwrite newer feedback.

Separate three timeout decisions

A transport timeout decides when a request is considered unanswered. A freshness timeout decides when the last valid state is too old to present confidently. A transition deadline decides when starting or stopping has taken longer than the project's allowed window. Document each independently.

If the projector remains in warm-up beyond the approved deadline, show a transition fault while preserving the last observed warm-up state. Do not invent a standby response. If communication fails during cooling, keep downstream power isolation conditional on a separate approved shutdown policy.

Prove the behavior before handover

Run a normal on/off cycle and log the query times, raw replies, displayed labels and completion conditions. Then disconnect the network during warm-up, reconnect it, and verify that the panel recovers from unknown to the actual current state without replaying old commands.

Also test power changes from the projector's own remote. The panel must update from observations even when the last user action occurred elsewhere. Restart the controller while the projector is already on and confirm it learns the current state instead of assuming standby.

Measure the delay from a local power change to its appearance on the panel. Record it separately from projector warm-up time: the former reflects observation latency, while the latter reflects equipment behavior. Agree an acceptable observation window with the operator. This makes a later complaint about a slow interface diagnosable without immediately changing transition deadlines or increasing traffic. Include the timing observation in the site record so later driver updates have a useful comparison.

For wider source and power integration, see the projector control guide. Review the required transition policy with your integration partner; actual device timing and driver feedback capabilities must be validated on the installed equipment.