Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG]: Delayed GCODE off should be ignored if GCODE on sent #335

Open
ttabi opened this issue Apr 15, 2023 · 4 comments
Open

[BUG]: Delayed GCODE off should be ignored if GCODE on sent #335

ttabi opened this issue Apr 15, 2023 · 4 comments
Labels
enhancement New feature or request solved workaround documented or fix applied
Milestone

Comments

@ttabi
Copy link

ttabi commented Apr 15, 2023

I have the following in my custom GCODE:

@TPLINKON 192.168.1.22/3 ; Lights
...
@TPLINKOFF 192.168.1.22/3

That is, the lights turn on when the print starts, and they turn off when the print stops. However, I have "GCODE Off Delay" set to 60 seconds. 60 seconds after the print stops, the lights turn off. So far so good.

However, if i start another print (with the same GCODE commands) within 60 seconds, the lights will still turn off even though a new print has started. That is because the 60-second delay for "@TPLINKOFF 192.168.1.22/3" is still running, even though I already sent a new "@TPLINKON 192.168.1.22/3".

So when there is a delayed TPLINKOFF still waiting, the plugin should delete that TPLINKOFF timer if it gets a matching TPLINKON before the delay expires.

My Python passable, but I have to admit the plugin code is a bit confusing for me. However, I believe the fix is to change tplinksmartplugPlugin::turn_on() so that it checks if there is an existing turn_off() timer running, and if so, kill the timer.

@jneilliii
Copy link
Owner

My Python passable, but I have to admit the plugin code is a bit confusing for me. However, I believe the fix is to change tplinksmartplugPlugin::turn_on() so that it checks if there is an existing turn_off() timer running, and if so, kill the timer.

you followed it proper, that would be the correct way to counter this issue. thanks for the report.

@jneilliii jneilliii added the enhancement New feature or request label Apr 15, 2023
@jneilliii
Copy link
Owner

The only caveat is that it should only cancel an off timer for the same ip and not all of them, although now that I'm looking at the code, this will probably take a good amount of reprogramming to make those timers accessible outside of the processAtCommand function.

@jneilliii
Copy link
Owner

A workaround that you can use to get around this issue for now is if you enable warn while printing option on the light and a print has started it won't trigger the off command.

jneilliii added a commit that referenced this issue Apr 16, 2023
…n on trigger is sent within the delay period, #335
@jneilliii
Copy link
Owner

added timer tracking in the above commit and is available as version 1.0.4rc1. change the release channel for the plugin in OctoPrint's Software Update settings to Release Candidate and upgrade when prompted.

@jneilliii jneilliii added the solved workaround documented or fix applied label Apr 16, 2023
@jneilliii jneilliii added this to the 1.0.4 milestone Mar 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request solved workaround documented or fix applied
Projects
None yet
Development

No branches or pull requests

2 participants