Sonoff POW + Hardware Watchdog

Moderators: Voyager, BertB, rtenklooster, Stuntteam, grovkillen, TD-er

Post Reply
Message
Author
DimOkIdE
Normal user
Posts: 15
Joined: 13 Oct 2018, 19:46

Sonoff POW + Hardware Watchdog

#1 Post by DimOkIdE » 03 Apr 2019, 15:38

Hi there.

I have the POW (R2) + mega-20190315 (ESP_Easy_mega-20190315_hard_SONOFF_POW_4M).

I've initialized it via "factory reset" and using pre-defined config "Sonoff POW-r2".

It works correctly (I hope :) ), measures voltage, current, power. But sometimes it's resetting with reason "Hardware Watchdog".
Sometimes it happens 2-5 times a day.

I saw the similar topics whith main idea that it's the WiFi issue. My POW right now is near my AP (Mikrotik hAP lite configured via CAPSman if it can help) - 802.11N (RSSI -39 dB).

But my question is not about the watchdog.

Q: Is it possible to store the last state of the GPIO-12 somehow to use it after such a reset (or is it a reboot?) to have POW on/off (depending on which one was before the watchdog killed it)? Right now I have to add "gpio,12,1" into my rules. It works correctly. But what to do when it was "off" before reset?

Maybe there is any way to keep the state of this gpio-12 in the POW's memory to check it after reboot and make the on/off command?

ThomasB
Normal user
Posts: 222
Joined: 17 Jun 2018, 20:41
Location: USA

Re: Sonoff POW + Hardware Watchdog

#2 Post by ThomasB » 03 Apr 2019, 19:14

Maybe there is any way to keep the state of this gpio-12 in the POW's memory to check it after reboot and make the on/off command?
This is possible because the last known User Variable values are saved in RTC memory. And they are restored on a warm boot. So this feature can be used to create your solution.

(1) Use the Generic Dummy Device Plugin and create a variable to hold the state of your GPIO.
(2) In your rules that change GPIO-12's state: Save a copy of the state in the dummy var.
(3) On warm boot: Check the dummy var and use its value to restore the GPIO state.

Keep in mind that this only works for your warm reboots. The dummy var is lost on a power reset, so write your rules to handle this as you wish.

- Thomas

DimOkIdE
Normal user
Posts: 15
Joined: 13 Oct 2018, 19:46

Re: Sonoff POW + Hardware Watchdog

#3 Post by DimOkIdE » 03 Apr 2019, 19:56

Thomas, thank you for your advice!

Would you be so kind to clarify a little?
This is possible because the last known User Variable values are saved in RTC memory
Is this applies to all "devices" or Dummy only?

I mean, I have the "Switch input" device with the gpio-12 state. And thus I can use it after such a warm reboots? Or I have to add another one (dummy) device?

Actually, POW has the built-in rule

Code: Select all

on Button1#state do
  if [Relay1#state]=0
    gpio,12,1
  else
    gpio,12,0
  endif
endon
Button1 - gpio-0 - the POW's button (switch input device)
Relay1 - gpio-12 - it's relay (switch input device)

I think the problem can appear because Button1 and Relay1 are always "0" after reboot (I think :) ). So it's better to create this new Dummy device.

Thank you greatly, I'll try this.

DimOkIdE
Normal user
Posts: 15
Joined: 13 Oct 2018, 19:46

Re: Sonoff POW + Hardware Watchdog

#4 Post by DimOkIdE » 03 Apr 2019, 20:01

Don't you know - is it possible to use smth like "SendToHTTP" but for HTTPS?

ThomasB
Normal user
Posts: 222
Joined: 17 Jun 2018, 20:41
Location: USA

Re: Sonoff POW + Hardware Watchdog

#5 Post by ThomasB » 03 Apr 2019, 20:26

Is this applies to all "devices" or Dummy only?
It applies to the user variables assigned to the various device plugins. But GPIO is not a user variable and its state is not saved.

So the workaround is to use a dummy device's user variable to store your GPIO's state. Or if applicable, you can use your existing plugin variables to determine the relay state on the warm boot. Or you can write rules that query your mqtt broker that restores the GPIO state and all the other things that you care about. So depending on your rule creation skills you can choose many different solutions.
is it possible to use smth like "SendToHTTP" but for HTTPS?
HTTPS is not supported.

- Thomas

DimOkIdE
Normal user
Posts: 15
Joined: 13 Oct 2018, 19:46

Re: Sonoff POW + Hardware Watchdog

#6 Post by DimOkIdE » 07 Apr 2019, 18:54

ThomasB wrote:
03 Apr 2019, 20:26
It applies to the user variables assigned to the various device plugins. But GPIO is not a user variable and its state is not saved.

So the workaround is to use a dummy device's user variable to store your GPIO's state. Or if applicable, you can use your existing plugin variables to determine the relay state on the warm boot. Or you can write rules that query your mqtt broker that restores the GPIO state and all the other things that you care about. So depending on your rule creation skills you can choose many different solutions.
May be I'm doing smth wrong, but it seems doesn't work :(

I have the "Generic - Dummy Device" (ID #6) named "RelayState" with the custom value "LastState".

In my Rule 1 I have the following part:

Code: Select all

On System#Boot do
	TaskValueSet 5,1,0
	TaskValueSet 5,2,0
	TaskValueSet 5,3,0
	TaskValueSet 5,4,0
if [RelayState#LastState]=0
   gpio,12,0
else
   gpio,12,1
endif
	TimerSet,1,30

EndOn
And I set this value in my Rule 4:

Code: Select all

On Time#Initialized do
   TimerSet,2,60
EndOn

on Rules#Timer=2 do  					
	if [Relay1#state]=0
          TaskValueSet 6,1,0
       else
          TaskValueSet 6,1,1
      endif
	TimerSet,2,60
endon
So it checks the relay_state once a minute and change the "RelayState#LastState" to 1/0.

But this value becomes 0 after the "warm reset" (hardware wachdog or exception (sometimes this is the reason of such a reset)). When I refresh the Device tab after such a reset, I see the LastState = 0.

It seems like it doesn't save this value to the RTC memory :(

ThomasB
Normal user
Posts: 222
Joined: 17 Jun 2018, 20:41
Location: USA

Re: Sonoff POW + Hardware Watchdog

#7 Post by ThomasB » 07 Apr 2019, 19:23

That is interesting. I experience watchdog timeouts too (it's a persistent issue) and my user vars are retained on the reboot.

As a rule/configuration validation test: (1) Perform a warm reboot using the Tools menu (click Tools=Reboot button). (2) Immediately after reboot, compare the user vars to their previous state. Do you see that your user vars are restored?

- Thomas

DimOkIdE
Normal user
Posts: 15
Joined: 13 Oct 2018, 19:46

Re: Sonoff POW + Hardware Watchdog

#8 Post by DimOkIdE » 07 Apr 2019, 23:06

ThomasB wrote:
07 Apr 2019, 19:23
That is interesting. I experience watchdog timeouts too (it's a persistent issue) and my user vars are retained on the reboot.

As a rule/configuration validation test: (1) Perform a warm reboot using the Tools menu (click Tools=Reboot button). (2) Immediately after reboot, compare the user vars to their previous state. Do you see that your user vars are restored?
Unfortunately, this test failed :(

Before: https://i.imgur.com/apWl5m6.png
After: https://i.imgur.com/FLoDFTE.png

Both devices (#5 and 6) with custom values have zeros after Tools -> Reboot.

May be it can be fixed from settings somehow?

ThomasB
Normal user
Posts: 222
Joined: 17 Jun 2018, 20:41
Location: USA

Re: Sonoff POW + Hardware Watchdog

#9 Post by ThomasB » 08 Apr 2019, 01:50

That is unexpected. For a sanity test I just checked my mega-20180714 Sonoff and the user vars are restored on warm boot.

- Thomas

DimOkIdE
Normal user
Posts: 15
Joined: 13 Oct 2018, 19:46

Re: Sonoff POW + Hardware Watchdog

#10 Post by DimOkIdE » 08 Apr 2019, 08:54

ThomasB wrote:
08 Apr 2019, 01:50
That is unexpected. For a sanity test I just checked my mega-20180714 Sonoff and the user vars are restored on warm boot.

- Thomas
Thomas, thank you greatly for your help! Will try another (elder) version.

Wiki
Normal user
Posts: 99
Joined: 23 Apr 2018, 17:55

Re: Sonoff POW + Hardware Watchdog

#11 Post by Wiki » 08 Apr 2019, 14:19

Hi,

with your first rule you will loose the data of the task "Calculation" anyway, System#Boot will be triggered on warm boot, too.

Instead of setting the variable for the relay state depending on a timer you should use the event Relay1#State which is fired by changing the relay state to save the setting immediately. Otherwise you will loose the change of the relay state if the reboot happens during your loop time of one minute:

Code: Select all

On Relay1#State Do
  TaskValueSet 6,1,[Relay1#State]
EndOn

DimOkIdE
Normal user
Posts: 15
Joined: 13 Oct 2018, 19:46

Re: Sonoff POW + Hardware Watchdog

#12 Post by DimOkIdE » 08 Apr 2019, 20:24

Wiki wrote:
08 Apr 2019, 14:19
with your first rule you will loose the data of the task "Calculation" anyway, System#Boot will be triggered on warm boot, too.
Hi!

Yes, I know this. The "Calculation" is another device and used for Domoticz mainly. And setting it to zeros at startup is OK.

And I want to keep the #6 device "RelayState" after warm reboot.
Wiki wrote:
08 Apr 2019, 14:19
Instead of setting the variable for the relay state depending on a timer you should use the event Relay1#State which is fired by changing the relay state to save the setting immediately. Otherwise you will loose the change of the relay state if the reboot happens during your loop time of one minute:

Code: Select all

On Relay1#State Do
  TaskValueSet 6,1,[Relay1#State]
EndOn
I already have such a rule

Code: Select all

on Button1#state do
  if [Relay1#state]=0
    gpio,12,1
//TaskValueSet 6,1,1
  else
    gpio,12,0
//TaskValueSet 6,1,0
  endif
endon
which was the default built-in rule for EspEasy firware.
As you can see - I've also had the lines for changing my #6 device "RelayState" value when button is pressed. But I think that this rule could be triggered after reboot when both #1 "Button1" (gpio-0) and #2 "Relay1" (gpio-12) are resetting to 0 automatically. Actually, I've tried this scheme before creating this topic (and it doesn't work for me). Thus I've decided to set #6 "RelayState" every 60 sec to avoid setting it to 0 automaticaly after reboot.

Wiki
Normal user
Posts: 99
Joined: 23 Apr 2018, 17:55

Re: Sonoff POW + Hardware Watchdog

#13 Post by Wiki » 08 Apr 2019, 21:00

Hi, sorry, but no, you havn't a logic like the one i posted. In your case you still depend on an event outside of the relay state, on the button. If you switch the GPIO 12 over network or however you won't notice this by using the button event.
But never mind if you already tried a similar way which didn't work for you and its fine that you figured out that a timer event solves your problem.

DimOkIdE
Normal user
Posts: 15
Joined: 13 Oct 2018, 19:46

Re: Sonoff POW + Hardware Watchdog

#14 Post by DimOkIdE » 08 Apr 2019, 22:20

Wiki wrote:
08 Apr 2019, 21:00
Hi, sorry, but no, you havn't a logic like the one i posted. In your case you still depend on an event outside of the relay state, on the button. If you switch the GPIO 12 over network or however you won't notice this by using the button event.
But never mind if you already tried a similar way which didn't work for you and its fine that you figured out that a timer event solves your problem.
I caught your idea. Actually, I have almost the same right now (the main difference is the timer which I'm using because I'm afraid that "On Relay1#State" will always make my custom value = 0 after reboot (if I could have my custom value saved afer warm boot - I'd try to figure out either it's true or not)).

And right now this timer doesn't solve my problem because all the values are resetting :( Will try another FW version tomorrow to see if it's possible to keep them after a warm reboot.

Wiki
Normal user
Posts: 99
Joined: 23 Apr 2018, 17:55

Re: Sonoff POW + Hardware Watchdog

#15 Post by Wiki » 09 Apr 2019, 11:41

Probably you shouldtry the actual nightly build. Looks like there happened something:
[RTC user var] Store read values in RTC memory to survive crash

DimOkIdE
Normal user
Posts: 15
Joined: 13 Oct 2018, 19:46

Re: Sonoff POW + Hardware Watchdog

#16 Post by DimOkIdE » 09 Apr 2019, 20:57

Wiki wrote:
09 Apr 2019, 11:41
Probably you shouldtry the actual nightly build. Looks like there happened something:
[RTC user var] Store read values in RTC memory to survive crash
Oh, Wiki, thank you greatly for advice - it really works now with the todays build.

The custom values are now saved at warm boot. And the watchdog issue is no longer a problem for me :)

As the bottom line:
My devices: https://i.imgur.com/ey0CGhJ.png
Rule #1:

Code: Select all

On System#Boot do
 ....other_stuff_not_related_to_the_watchdog....
 TimerSet,2,10
EndOn

....other_stuff_not_related_to_the_watchdog....

on Rules#Timer=2 do
 if [RelayState#LastState]=0
   gpio,12,0
 else
   gpio,12,1
 endif
endon
Rule #2:

Code: Select all

On Time#Initialized do
	TimerSet,3,30
EndOn

On Rules#Timer=3 do
	if [Relay1#state]=0
		TaskValueSet 6,1,0
	else
		TaskValueSet 6,1,1
	endif
	TimerSet,3,30
endon
And now it works as expected (turns ON my POW after the watchdog reboot if it was ON before). The only issue is that Button1#State (gpio-0) will be 0 after that, but it's nothing :)

PS:
I've also tried:

Code: Select all

On Relay1#State Do
	TaskValueSet 6,1,[Relay1#State]
EndOn
but it doesn't work :( It sets my custom value to 0 at reboot.

PPS:
btw, can anybody point me where to find the following:
When I use the Rules without "Old Engine" checkbox:
  1. may I create more than 4 events?
  2. "Event name" - what's this? Should I name it Rule1/Rule2/etc? And what this "name" is used for?

Wiki
Normal user
Posts: 99
Joined: 23 Apr 2018, 17:55

Re: Sonoff POW + Hardware Watchdog

#17 Post by Wiki » 09 Apr 2019, 21:16

The new engine is still in development. But you can fill every rule set up to 2048 bytes with event handlings. In the past there has been an issue with corrupting the rule set while saving if its bigger than app. 1K. So have a look if the rules are saved correctly.

DimOkIdE
Normal user
Posts: 15
Joined: 13 Oct 2018, 19:46

Re: Sonoff POW + Hardware Watchdog

#18 Post by DimOkIdE » 09 Apr 2019, 21:50

Thanks, got it. good luck!

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 2 guests