Wyze Outdoor Plugs ESPHome Power Loss Behavior

Automation Central Automation Hardware
#1

So I got a set of Wyze Outdoor Plugs for Christmas lights outside and after a bit of cursing, inhaling of soldering fumes and almost ripping out a trace (thanks wyze for not putting through hole contacts and only having pads), I got ESPHome onto each of them working as expected using this yaml as a baseline (modified to use core default yamls):

Everything seems to be working as expected, but I just noticed that the default behavior when there is a power loss event is for both relays to turn on. This is less than ideal since I am also using these to power a fountain pump that is not always in use/drained. Unfortunately the pump does not have run dry protection so I think you guys can see why this is an issue.

Any ideas on how/if it is possible to configure the power loss behavior (on/off would be fine, but previous would be better)?

Edit: I found this but I am not sure if it is actually related:

Edit 2: I think I found the right setting, there is an on_boot setting

#2

I can give a complete example later today if needed:

on_boot is probably the way to go to set to off when rebooting and then handle restore to current state in NR by checking for the device coming online and then sending the current state as kept in NR.

1 Like
#3

One thing to keep in mind, if you send on/off as a retained message that will be read and used on boot as soon as the device connects to MQTT.

#4

So I just did some further testing and the power loss behavior is actually weirder than I thought (but I feel like it is somewhere in the yaml doing it because no way this is default).

The default action when they experience a power loss event is to toggle from the previous state. So if both relays were off, cut the power put the power back, both are on, and if both are on when power is lost, when they come back they are both off.

Also this does not seem to be the case when you initiate a software reboot, which results in the same state of the relay as before the reboot.

Looking through the yaml nothing jumps out other than all of the inverted true and false. I have not made sense of why some are true and why some are false.

#5

The only thing I see which could potentially cause this is if those switch.toggle entries are activated during boot. You could try commenting out that whole section.

#6

what is the best way to do this since I do not want to modify the generic yamls and those are what contain the esphome: section?

#7

Unfortunately I don’t remember without checking that, I can check later today.

1 Like
#8

No worries, it’s raining currently so there is no use for a fountain anyway and now that I know about this I can monitor/unplug to make sure the pump isn’t at risk.

#9

Just monitor for new online messages and send off to the pump outlet when one is received, that should solve it for now at least. Then later you can find the proper firmware based fix.

1 Like
#10

I also found a restore_mode setting as part of the switch component which I am adding to always off, we will see if it starts working as intended.

1 Like
#11

Quick question about handling firmware for multiple devices:

I am assuming you follow the framework of the generics, where you have just a main firmware for a given device and then you have the actual device that includes that main code plus and specific configs like name or mqtt location correct?

If so what is the normal process for making sure those new changes are applied downstream? I assumed when I saved the “template” wyze plug all of the others would not say that there is an update available and to please install, but to my surprise they did not. Do I just have to force an install and hope it recompiles the correct code and doesn’t just reload the old compilation?

Also any idea why only the IP monitor from the generic yamls is coming in but not the restart switch, uptime, wifi signal, or status?

#12

This is getting really weird. Somehow the below code results in a always off when power is lost even though it clearly should be always on, and I tried the always off option and it always turned it on. I really hate inverted logic…

switch:
  - platform: gpio
    name: ${device_name} Relay1
    restore_mode: ALWAYS_ON
    pin:
      number: GPIO15
      inverted: false
    id: relay1
    on_turn_on:
      - light.turn_on: relay1_led
    on_turn_off:
      - light.turn_off: relay1_led
  - platform: gpio
    name: ${device_name} Relay2
    restore_mode: ALWAYS_ON
    pin:
      number: GPIO32
      inverted: false
    id: relay2
    on_turn_on:
      - light.turn_on: relay2_led
    on_turn_off:
      - light.turn_off: relay2_led
#13

I think the inverted logic is due to this:

binary_sensor:
  - platform: gpio
    internal: true
    pin:
      number: GPIO18
      mode: INPUT_PULLDOWN
      inverted: True
    name: ${display_name} Button1
    on_press:
      - switch.toggle: relay1
  - platform: gpio
    internal: true
    pin:
      number: GPIO17
      mode: INPUT_PULLDOWN
      inverted: True
    name: ${display_name} Button2
    on_press:
      - switch.toggle: relay2

Comment that part out. I’ll look at the other questions later, not at my computer today.

1 Like
#14

Initial tests with this seem positive, it seems to be preserving the previous state properly.

Commenting this section out disabled the use of the onboard buttons which is not good, but at least we are making progress on the logic front.

#15

At least now it’s clear where the issue is, which was the point of disabling that block. You could try to enable that block and changing “inverted: True” to False on both locations, then try if the state remains correct and if the buttons still work. If not there are other ways to filter this, but for that I’d need to check on my own configs at my computer.

1 Like
#16

So far so good. Upon thinking about it, why would a button input ever need to be inverted?

#17

If it was a closed circuit by default (NC) and pressing opened it (NO)? It should work, so if the behaviour is correct now you should be done :slight_smile:

1 Like
#18

Thank you so much Markus for helping to fix this. I feel like someone should put a PR in so it gets updated for anyone in the future:

Also just a reminder for you or someone else later: I still have a few secondary questions outstanding (generic yamls monitors not showing up and how to handle yamls for multiple of the same device)