-
-
Notifications
You must be signed in to change notification settings - Fork 16
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
Request: "Keepalive" Interval #191
Comments
To be honest this sounds more like a new plugin as moving all the logic to the device basically removes the need for all the other bits. Your keep alive watchdog is basically recreating the idle timer on device. |
I'm not looking for idle shutdown. Idle shutdown kills power when not printing. I want power killed when the system fails to check in due to a failure or lock up which your plugin can't detect, and absolutely not when merely idle. Please read the entire message. I know it's a lot but it very carefully explains what I need and why, as well as what it adds, and it solves two open issues. If I implemented a plugin to do what I want, it would include about 75% of your plugin as well, and idle shutdown is completely counter to my desires. That's a lot more than two additional options on timers you're already running to send commands to devices you're already supporting via methods you already have in place, and the features I'm requesting compliment your features without either re-implementing or contradicting existing features in any way. |
I'll try to pitch this one other way. Let's say your Pi locks up. Doesn't matter why. What does your plugin do? Nothing. My suggestion is security through regular checkin. Watchdog, keep-alive, whatever you want to call it. My suggestion requests power for a safe duration; shorter while hot and printing, longer while idle/cold. If safe duration passes without check in, power is disabled. This adds safety to existing features, because if a power brown out or surge kills your Pi and your printer MOSFET at the same time - which is not unlikely - it gets shut down assuming the Tasmota device survived. The other features offered are still desirable and in some cases required, such as your existing temperature runaway. I'm aiming to add lockup/watchdog protection to that. |
I see your point about not being a separate plugin now. If you could provide the rulesets and what not to set this up on a tasmota device that would be helpful for me for development purposes. If you could provide how to also add the ruleset via API calls that would be a huge help as well, because I do like the idea of being able to click a button in the settings and have them automatically added to a device. |
Sweet, no problem. Glad to hear the idea interests you! On the Tasmota device, it's shockingly easy - for ESP8266 devices. ESP32 devices use Berry scripting instead of Rules, but I feel like 90% of power-control related devices are ESP8266. If you want ESP32 support, I could be convinced to write one up and test it. I'm also happy to guinea pig any changes or testing branches, if that helps. Manual set-up;
For API-based setup, the commands are the same, just sent to the HTTP API endpoint as a query. I don't speak Python but I believe that's A quick breakdown of the rule, and how it works (in case you don't speak Tasmota Rules);
Interacting with this rule is cake;
Obviously if the watchdog is running when the user shuts down their Pi, it will power down. This is actually a plus, BUT if their Keepalive is set too short, the Pi might take longer to shutdown than provided. May want to limit the lower end of that setting, or warn of this. Also, a user could NOT enable the watchdog during print/idle, but trigger it explicitly before shutting down, to use it as -only- a "shutdown poweroff" function. That's how mine is used right now, lol, since I don't have a plugin to poke it regularly. Sorry if this was a lot of ramble, I'm trying to be thorough. I'm more than willing to provide anything else to help. |
Oh also; to trigger the rule manually from a proper command line, in case you're less familiar with using Curl to test API endpoints; You can check the running rule timers during development by just sending |
I enjoy this plugin and its intended function, but I would like to go one step further and design a watchdog system.
I would like this plugin to periodically (configurable) send a "keepalive" command (also configurable) to a Tasmota device. On said device, I will write a ruleset to shut off power if the "keepalive" command is not received for several intervals.
All I need is the ability to send a configurable web request at a configurable interval. The specific web request I will send is
event KEEPALIVE=1
in the format ofhttp://<ip>/cm?cmnd=Event%20KEEPALIVE=1
but allowing it to be user-configurable is also of merit.Alternatively, having two keepalive options (one during print, the other while idle) would allow for different intervals/sensitivity IE
Event KEEPALIVE=125
re-sent every 30 seconds would prevent shutdown for ~120 seconds while idle but allow three missed triggers before powering off, andEvent KEEPALIVE=35
sent every 15 seconds would prevent shutdown for ~30 seconds but allow two missed triggers before failsafe. (The stated interval/keepalive durations here are hypothetical and not intended implementation.)My target is to run the command a few times per minute, which will reset a countdown timer in a watchdog ruleset which I will write and store on the Tasmota device itself.
This will terminate power to the system if;
If you like, I could even share my ruleset with you, and the plugin could also transmit the watchdog ruleset to the Tasmota device on request, allowing any* user to enable a printer safety watchdog.
The text was updated successfully, but these errors were encountered: