BK7231N Tuya Smart Plug: Ping Watchdog Delayed Start & Detection Issues

Question

I'm experimenting with using ping watchdog to monitor a device and reboot it when it becomes unresponsive - a common task. I'm using one of the older 7231 based Tuya smart plug devices. The strategy I'm taking is: - turn the relay on at startup - configure ping watchdog target and frequency -...

p.kaczmarek2 · Answer

I've configured non existent IP:

And restarted the device, after an initial delay designed to give things time to settle I get:

Now you can use:


// events to run when no ping happens
addChangeHandler noPingTime > 600 reboot

to run an event

PS: Here is a delayed start condition:

Did you restart your device after configuration change?

tinkertechie · Answer

Hi, thanks for the amazingly quick reply!

Yes, restarted after every code modification.

Your log perfectly demonstrates the problem I'm concerned about. If the device hasn't completed its startup for whatever reason (just slow?) and can't reply, it's possible that noPingTime could become quite large before the script sees its first reply. The script could then assume that the device needs to be rebooted, but the script just needs to wait longer.

I think I've got enough to work on from your reply, so I'll try something out and get back to you.

Thanks again!

p.kaczmarek2 · Answer

I am not sure if I understand. Can you elaborate? Which device? OBK or a target device? The whole idea is that you choose a certain margin, like a 30 seconds, and you just assume if 30 seconds should be enough for the device boot, and trigger event when noPingTime exceeds 30 seconds. How long does it take for your target device to reboot? Is your target device uptime so crucial that you are trying to optimize the downtime by choosing as small as possible noPingTime threshold? I can update SDK per your request to suit your needs but I need to get a better understanding of your use case.

tinkertechie · Answer

>>20931042
I might have found the problem I'm facing...

Basically, I want to be certain that the device has come up before I proceed. So if I delay for 15 seconds, THEN wait until secondsWithNoPing is below 10, I know for a fact that the device has actually responded at least once. I've been using

"SetChannel 9 noPingTime"

to try to see its value, but regardless of what the log is showing for secondsWithNoPing, Channel 9 is always being set to 0.

Is noPingTime only exposed to AddChangeHandler, or is it also exposed to WaitFor, If statements, SetChannel, etc?

ie: are any of the following valid?

WaitFor noPingTime > 1

If (noPingTime > 1) then goto xyz

SetChannel 9 noPingTime

Do I HAVE to craft this hold for a short ping time by establishing an AddChangeHandler? That's ok, I can do it, but it's a little cumbersome.

p.kaczmarek2 · Answer

WaitFor syntax does not require a comparison sign, it should work in your case. I have updated our sample codes list in a reply to your request:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md
I've added a sample for WaitFor:


// Example autoexec.bat usage
// wait for ping watchdog alert when target host does not reply for 100 seconds:

// do anything on startup
startDriver NTP
startDriver SSDP

// setup ping watchdog
PingHost 192.168.0.123
PingInterval 10

// WARNING! Ping Watchdog starts after a delay after a reboot.
// So it will not start counting to 100 immediatelly

// wait for NoPingTime reaching 100 seconds
waitFor NoPingTime 100
echo Sorry, it seems that ping target is not replying for over 100 seconds, will reboot now!
// delay just to get log out
delay_s 1
echo Reboooooting!
// delay just to get log out
delay_s 1
echo Nooow!
reboot

Would the following approach suit your needs, or shall we try exposing noPingTime more?

EDIT: It sounds like you're looking a for an inverse waitFor....

Added after 4 [minutes]:

The idea to support comparison in waitFor seems very interesting:


WaitFor noPingTime > 1

I think I could make this work before tomorrow. I like that, from what I can see, it would require just few more lines of code.

Can you wait?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

tinkertechie · Answer

Yes, that's almost exactly what I'm hoping for!

The example for the AddChangeHandler for noPingTime includes a comparison - specifically ">".

In testing it seems that it doesn't actually use this. I have tried clearing handlers and making a second call of "AddChangeHandler noPingTime < 10 SetChannel 10 2" but it doesn't seem to work. However, it MAY have been because, when I added the handler, noPingTime was already less than 10. Thus there was no change to trigger it.

But, the ability to use WaitFor noPingTime < 10 would make some of what I'm trying to achieve a LOT easier.

To reply to your previous request for clarification - yes, if the target host is slow to boot. I want to be 100% certain that the host has come up, so I don't somehow attempt a power cycle when the target is actually behaving itself! This is all prompted by a site where I'm waiting on a bug fix from an OEM who I don't want to embarrass publicly. But there are two devices on site that are affected. One is the router/AP and the other is an internal device that, for unknown but apparently related reasons, is also occasionally locking up.

I am trying to reboot the devices when they lock up. I'll lose WiFi if the router/AP locks up, but for the other device I don't want to unnecessarily reboot it if the cause for loss of ping is the loss of router/AP WiFi. So I need to be able to differentiate. I suppose I can do that by inspecting WiFiState.

Perhaps one solution would be to give expansions for noPingTime and WiFiState etc along the lines of $noPingTime and $WiFiState which would allow them to be used in "if" statements?

As for waiting - well, obviously I'm able to wait because I can't do anything else

The client is getting very irritated, but I'll be there tomorrow trying to pursue proper fixes rather than workarounds, which will keep them happy. But I'm not optimistic about that, so whenever you're able to get to this it would be fantastic. But I respect your situation and that this is presumably not your income source, so I don't want to make any demands!

p.kaczmarek2 · Answer

I think that change handlers by design are called only when the threshold is passed, just as you guessed. As in the title, the change has to occur. Ok, here it is, just remember, it only supports those 3 operators I listed in docs. Implementation: Self test: Docs: Copy of above: Code: text Expand Select all Copy to clipboard // Waitfor syntax samples // WaitFor can support following operators: // - no operator (default, it means equals) // - operator  (more) // - operator ! (not requal) // default usage - wait for NoPingTime to reach exact value 100 waitFor NoPingTime 100 // extra operator - wait for NoPingTime to become less than 100 // (this will be triggered anytime variable changes to value less than 100) waitFor NoPingTime  100 // extra operator - wait for NoPingTime to become different than 100 // (this will be triggered anytime variable changes to value other than 100) waitFor NoPingTime ! 100 In this particular case, the waitFor will act a bit different than change handler, because change handler occurs only when a condition changes from false to true, and waitFor will trigger for any value that meets condition. I can do that as well, altough, the mechanism behind the expansions is different than the event system. Events are cast when something happen, and expansion happens per-request in place. You always have a second option, you can just draft a simple driver in C, we have online builds, you can build on Github, there is no need for even setting up a compiler on your machine. Yes, it's a fully non-profit project, and donations are rare, even if 1 of 10 people reading this posts were to donate some $ to our paypal it would already make a big difference and allow more development.

tinkertechie · Answer

Thanks for the changes and the advice. I'd be happy to do a few test builds, so I'll have to learn more about how to do that on GitHub. I've got the repository cloned locally so I can look through the code more easily, and I'll have to play to see how the expansion might be achieved. It would be very useful. Another useful feature might be a timeout for WaitFor. I'll look into how to achieve that. Added after 1 [hours] 13 [minutes]: >>20933018 I don't think it's quite working, or I'm doing something wrong. I can't find a way to directly inspect the value of noPingTime though for debugging so it's hard to tell. As you can see, Channel 8 never gets set to '2' - the code doesn't seem to advance past the WaitFor noPingTime > 1. The Channel 10 mechanism you see is how I was trying to implement this using addEventHandler. It's still in place for the final reboot, but we never get that far. You'll have to forgive me for not yet knowing how to drive the editor here properly, but this is the script, followed by the log: ---------------8 1 // drop a mark in the log SetChannel 8 2 // Once pings are working, wait 15 seconds so we know we've tried to ping at least twice delay_s 15 // now wait until we see that the target is up WaitFor noPingTime < 10 // drop a mark in the log SetChannel 8 6 // now that we know the target is up, set up the event to reboot myEvents addChangeHandler noPingTime > 30 SetChannel 10 9 SetChannel 10 0 sleepy9: delay_s 2 // drop a mark in the log SetChannel 8 7 if 9==$CH10 then goto restarttarget goto sleepy9 // Turn off the power to the target, then reboot after 5 seconds. The power is turned on again when this // script restarts. There seems to be a bug where the delay is ignored if it is the last step in the script. // Need to investigate that further. restarttarget: SetChannel 1 0 delay_s 5 SetChannel 1 0 reboot ---------------8

p.kaczmarek2 · Answer

Oops, it seems a call from frontend was missing. I've checked and fixed that. My self tests missed that because they are injected a bit later in the call chain.

Added after 14 [seconds]:

Please update and recheck. Remember to backup your scripts.

tinkertechie · Answer

Yep, that worked! Awesome. I feel bad adding to this, but I may have found another bug. Please forgive me if I have misunderstood documentation, but I couldn't find where this is handled in the source code. I think I found the parser, but I've looked at so many different bits of unfamiliar code today my brain is fzzzzt... I've had a bit of a play with trying to get a non-blocking version working, essentially expanding the sleepy part of the end of the script I pasted previously (ie: rolling my own waitfor with a way to have a timeout). It makes it a lot easier to handle states that have multiple exit conditions. I have hit a problem though. Should this work?: addChangeHandler noPingTime < 10 SetChannel 10 3 What I'm doing is setting up the handler when I know the ping time has become bigger than 10, making sure CH10 is 0, then looping (with delays) until I see CH10 change to 3. The technique below works elsewhere when the addChangeHandler relation is >. I have verified that the ping is greater than ten at the time I set up the handler, but then when the ping time drops below 10 it doesn't fire. Here are two level 6 log fragments that show the problem. Before this I've had an addChangeHandler noPingTime > 10 SetChannel 10 2 line that works: ---------------8

p.kaczmarek2 · Answer

You are correct. It seems there was an oversight, the change was not called while ping time was reset back to 0. It seems no one ever needed it before. I've pushed a fix, can you check? This should work with the new fix: Code: text Expand Select all Copy to clipboard addChangeHandler noPingTime

tinkertechie · Answer

>>20934740I lost the need for this, but I believe I tested this change and it was OK. I'll endeavor to do so shortly. I have another question that I'll raise as a new topic. Thanks again for your incredibly prompt replies.

BK7231N Tuya Smart Plug: Ping Watchdog Delayed Start & Detection Issues

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Topic summary