When I write such a script, the relay starts switching every 1 second, but to make it happen, I first need to turn it on manually. What should I write so that it starts switching only when the device is powered on and keeps doing it continuously?
When I write such a script, the relay starts switching every 1 second, but to make it happen, I first need to turn it on manually. What should I write so that it starts switching only when the device ...
Initial assessment of available information Your two lines register change handlers that only run when Channel1 changes state. At power-up there is no change event yet, so nothing starts until you toggle the relay manually. In addition, each change spawns a new repeating timer, so over time you can accumulate multiple timers fighting each other.
Direct answer to the question Do not create timers inside change handlers. Create one repeating event that toggles the relay itself, and make it start at boot.
Put this in your startup script (autoexec.bat) or run it once and save: addRepeatingEvent 1 0 setChannel 1 toggle
That’s all: it will start on power-up and keep switching every 1 s indefinitely. If you prefer the first toggle to occur after 1 s (not immediately), use: addRepeatingEvent 1 1 setChannel 1 toggle
Detailed problem analysis - addChangeHandler Channel1 == X … runs its action only when Channel1 transitions to X. Initialization to X at boot is not a “change”, so your handlers don’t fire. - setChannel inside addRepeatingEvent is sufficient for periodic behavior; you don’t need handlers for this use case. - Re-adding addRepeatingEvent on every edge creates multiple concurrent timers. That leads to jitter, double-toggles, and hard-to-debug timing.
Why the one-liner works: - addRepeatingEvent T D CMD schedules CMD to execute every T seconds, with an initial delay D seconds after boot (or after the command is registered). - setChannel 1 toggle flips the relay state each time the event fires. One periodic event = clean, stable 1 Hz square wave on the relay output.
Current information and trends For OBK-style scripting, repeating events are designed to run indefinitely until removed or the device reboots. You typically don’t specify a repeat count; you set the interval and optional initial delay. Use a single scheduler for periodic jobs rather than edge-driven chains.
Supporting explanations and details Common variants you may want: - Known initial state, immediate start: - setChannel 1 0 - addRepeatingEvent 1 0 setChannel 1 toggle - Known initial state, first change after 1 s: - setChannel 1 0 - addRepeatingEvent 1 1 setChannel 1 toggle - Asymmetric ON/OFF times (example: ON 1 s, OFF 2 s): - setChannel 1 0 - addRepeatingEvent 3 0 setChannel 1 1 - addRepeatingEvent 3 1 setChannel 1 0
Practical guidelines - Remove the two addChangeHandler lines from your startup script; they are not needed here. - Place the chosen addRepeatingEvent line in autoexec.bat so it runs after power-up. - Reboot the device to verify behavior. - If you previously experimented from the console, a reboot clears in-RAM timers that aren’t in autoexec.bat.
Possible disclaimers or additional notes - Rapidly switching a mechanical relay every second will cause wear. For endurance testing or long-term use, consider a solid-state relay or a GPIO-driven LED for development.
Suggestions for further research - Check your device’s scripting reference for other scheduler features (naming events, removing them on demand) if you plan to start/stop the blinking programmatically.
Brief summary Your script waits for a change that never happens at boot and spawns redundant timers. Replace the handlers with a single scheduler entry: addRepeatingEvent 1 0 setChannel 1 toggle This starts automatically at power-up and continues switching every second.
Questions for the user - Do you want the first toggle immediately at boot, or after the first 1 s interval? - Do you need a way to start/stop the blinking from another input (button/channel)? If yes, we can add a simple enable flag and handlers without duplicating timers.
You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.