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

Request: "Keepalive" Interval #191

Open
codefaux opened this issue Nov 15, 2022 · 6 comments
Open

Request: "Keepalive" Interval #191

codefaux opened this issue Nov 15, 2022 · 6 comments
Labels
enhancement New feature or request

Comments

@codefaux
Copy link

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 of http://<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, and Event 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.

@jneilliii
Copy link
Owner

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.

@jneilliii jneilliii added the enhancement New feature or request label Nov 15, 2022
@codefaux
Copy link
Author

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.

@codefaux
Copy link
Author

codefaux commented Nov 15, 2022

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.

@jneilliii
Copy link
Owner

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.

@codefaux
Copy link
Author

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;

  • Pull up Tasmota UI, click Console
  • Add the keepalive rule. There are three rule slots. I'm using slot 1 for the keepalive, rule2 and rule3 are in use for other functions, in my setup -- might be wise to allow the user to pick which rule slot it targets, or at minimum warn them about klobbering.
    rule1 ON Event#KEEPALIVE DO RuleTimer1 %value% ENDON ON RULES#Timer=1 DO Backlog Power1 Off; Power2 Off ENDON
  • The only way to check if the rule exists (easily) is to query it with no rule, IE, rule1 -- it should return a JSON packet containing the rule, as well as other data;
    02:01:24.234 RSL: RESULT = {"Rule1":{"State":"ON","Once":"OFF","StopOnError":"OFF","Length":104,"Free":407,"Rules":"ON Event#KEEPALIVE DO RuleTimer1 %value% ENDON ON RULES#Timer=1 DO Backlog Power1 Off; Power2 Off ENDON"}}
  • Make sure Rule1 is enabled; rule1 1
  • (Optional; advised) Make sure Rule 1 is not set to One-Shot mode; rule1 4

For API-based setup, the commands are the same, just sent to the HTTP API endpoint as a query.
For example http://<ip>/cm?cmnd=Event%20KEEPALIVE=1 is the same as sending Event Keepalive=1 from the device's Console.

I don't speak Python but I believe that's requests.get('http://<ip>/cm',params={'cmnd':'Event KEEPALIVE=1'}) -- though I seriously doubt that's exactly accurate.

A quick breakdown of the rule, and how it works (in case you don't speak Tasmota Rules);

  • ON Event#KEEPALIVE DO RuleTimer1 %value% ENDON -- When the unit receives the command "event KEEPALIVE " it will trigger this rule, setting the first rule timer to whatever number it received.
  • ON RULES#Timer=1 DO When the first rule timer triggers Backlog Run a sequence of commands instead of just one Power1 Off; Power2 Off I'm using two channels (one for each 24v power supply) ENDON End of command
  • To change the rule slot, obviously rule2 or rule3
  • To change the timer slot, the command RuleTimer<x> and the trigger RULES#TIMER=<x> must be updated. There are 8 available timers on Tasmota firmware. They can be set from 0 to 65535. Set to 0 to clear without triggering.
  • https://tasmota.github.io/docs/Commands/#rules
  • https://tasmota.github.io/docs/Rules/

Interacting with this rule is cake;

  • Send Event KEEPALIVE=120 and it will stay on for 120 seconds. I recommend sending MUCH more often than required, in case a packet gets dropped for whatever reason. My intent was to run the timer for ~125sec and send it every ~30sec. This means it can miss checking in three times, with a 5 second variance window, before the unit shuts off power. Paranoid users may wish to shorten these windows, but I feel the "worst case" will take much more than two minutes.
  • Send Event KEEPALIVE=0 and it will disable the watchdog. It will -not- turn off power if a watchdog timer is already running. This could be used for Maintenance work, or to ensure the watchdog only runs while printing if that's the desire.

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.

@codefaux
Copy link
Author

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;
curl http://<ip>/cm?cmnd=Event%20KEEPALIVE=120

You can check the running rule timers during development by just sending ruletimer -- reset all timers with ruletimer 0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants