From what I’m seeing on the forum here I think discovery is broken? Everyone who says it works is someone who has ‘upgraded’. Everyone who hasn’t had it work is someone who is trying to get it newly integrated.
For reference:
Are you using HA OS version, Supervisor version, or Docker version. I’m on the OS version and while the HACS install is clearly working (the platform: ecoplug doesn’t throw an error in config), the python script for ecoplug has a dependency I’m not so sure about. You can see it pulling from ‘pyecoplug’, but I dont see that script anywhere. Nor do I see the “EcoDiscovery” version. Granted, I’m doing this through file explorer webUI…so maybe I gotta figure out a better way to navigate the filesystem?
Diving a little deeper into the ecodiscovery script on the github repo. What the heck is this? Is it listening for something on an external port we should be forwarding?
Hm, so i see a subnet mask of 255.255.254.0 and an IP starting with 172 if I do ‘ifconfig’ in the HA command line. I’m wondering if that’s causing the issue?
I’ve read that i should ignore the 172.x.x.x ip and that’s just an internal docker thing…but perhaps for a third-party integration like this it is causing a problem?
I access my HA interface using a 192.x.x.x:8123 address, so I assume that devices outside the HA will see it on the correct subnet…am i wrong? (all my other devices are on a 255.255.255.0 subnet.
First, thanks @Scope666 for all their help. Turns out this integration is likely dead for new devices. Discovery is broken in some way that I can’t debug (at least for my pool pump switch). So if you’ve found yourself here looking for a way to manage your DEWENWILS pool pump, you cannot get THE VERSION I LINKED integrated. CHECK THE VERSION.
However, you can get THIS VERSION LINKED INTO HOME ASSISTANT. Be VERY careful that you buy the color version that says it links to either “Tuya”, “Tuya Smart”, or “Smart Life” Apps. These can all be integrated using the LocalTuya HACS integration.
And the instructions for installing & syncing devices for local Tuya.
Took me about 30 minutes to get working. Would have taken only 10 minutes if I didn’t have to troubleshoot getting a user onto the Tuya IoT site (see updated method for Android in the comment linked above).
Supposedly the version I have (ECO) can be flashed with Tasmota. I’m already running Tasmota on a bunch of plugs and dimmers. I might attempt it if Eco continues to be a PITA.
This might not be that useful, but just in case it happens to somebody. Throughout the debugging of making this work, I forgot that this is not an integration that you will see a notification in home assistant that a device has been found. The entity will appear in the entity section with the name switch.the_name_you_gave_in_the_configuration_via_your_phone_or_tablet.
Catching up on this. (I didn’t get any alerts for this thread )
Is there any way to edit the code to put in the IP address manually? I don’t need the discovery feature. Perhaps this will make the integration much simpler.
I’m poking around the switch.py file but can’t see if I can just overwrite and put in an IP. Perhaps changing this:
def setup_platform(hass, config, add_devices, discovery_info=None):
from pyecoplug import EcoDiscovery
discovered = {}
def add(plug):
if not plug.name in discovered:
add_devices([EcoPlugSwitch(plug)])
discovered[plug.name] = plug
def remove(plug):
# Is there a way to remove devices??
pass
disco = EcoDiscovery(add, remove)
disco.start()
def stop_disco(event):
disco.stop()
hass.bus.listen_once(EVENT_HOMEASSISTANT_STOP, stop_disco)
to this:
def setup_platform(hass, config, add_devices, discovery_info=None):
from pyecoplug import EcoDiscovery
discovered = {10.0.1.39} <--- putting the IP in here??
def add(plug):
if not plug.name in discovered:
add_devices([EcoPlugSwitch(plug)])
discovered[plug.name] = plug
def remove(plug):
# Is there a way to remove devices??
pass
I’m LITERALLY learning python during this endeavor. I started a new fork that I’m messing around with print statements trying to figure out what’s going wrong.
I’ve gotten it to find the device. I had it named “pool” in the ecoplug app. There was no way for the python on my computer to know that. And I’m getting this from a few “strategic” print statements:
Printing self.discovered in __init__:
{}
Printing self.discovered in process_packet:
{}
Priting plug in process packet:
('## EcoPlug ##', b'pool')
Add: ('## EcoPlug ##', b'pool')
True
Printing self.discovered in process_packet:
{b'38:2b:78:0b:98:0a': (1678079360.9085553, ('## EcoPlug ##', b'pool'))}
No idea what I’m doing. But I’ll keep poking around at this. If anyone knows python, I’ll happily share my github fork to collaborate on.
Ok so I think it’s because in discovery.py, the from .plug import EcoPlug wasn’t loading right because of an error saying python couldn’t find a relative file. At least from my research on the error I saw.
I copy and pasted everything from plug.py into discovery.py, and then added any missing import commands.
The result was the earlier message that now shows my “pool” plug. I’m wondering if that from .plug import EcoPlug was hanging up the discovery process? Keep in mind I learned python today… and github for that matter.
What I don’t understand is how the my raspberry pi, running HASS at home, knows what discovery.py is. I don’t see it on my file structure in HASS. I only see it on github. Does that mean my HASS has to reach out to github to run discovery.py? If so, how can I make it reference my new github fork to test this?
I have the DEWENWILS model. Version 2.2.5 according to the Eco Plugs Android App.
Based on some Wireshark captures, I think this plug works differently. It may be vendor and/or firmware specific.
The plug broadcasts UDP to port 10228 about every 2 seconds. I think this is part of local discovery, though there is some communication to server1.eco-plugs.net
The App talks to the plug using UDP source port 9090 to destination port 1022. It doesn’t look like any discovery is done, presumably it learns the IP from the port 10228 broadcasts. The data size is 152 not 128. It’s just padded with zeros so probably nothing new added. Responses from the plug are also 152 bytes to UDP/9090 - I think this is also different - looks like it’s expecting 408 bytes.
I’ve have this one bought in 2019, it shows as ECO-780Bxxxx (V:1.7.1) in the app. I have it functioning with Home Assistant at the moment, so could potentially grab debug logs if useful.
Some day I’ll probably flash it with Tasmota if I get up the nerve. (found a template here). I just did this with a Nexx Garage unit, now I’m out of their eco system and local only. They had a major security breach and took my device offline for over 4 days, that was my motivation to flash it.
I was successfully able to flash my Dewenwils switch with Both ESPHome and Tasmota. I just created a write up on ESPHome seen here and also the Tasomta flash from here worked perfectly as well. I will be creating a couple other write ups on ESPHome for other branded ECO-Plugs soon.
Thanks for posting this, you’re giving me even MORE incentive to get up the nerve. Pretty easy to get that board out? Wondering if I can leave the main unit wired in place, and just pull the board, and flash it upstairs.
Yes, this was straight forward, I bench tested everything on an EcoPlug wall outlet plug first. Since my Dewenwils switch is outside I turned off power and was able to solder in the wires without disconnecting the main unit. Once it was hooked up to the USB serial, I was able to create the device in ESPHome via Homeassistant, Add the Yaml to the device config and hit install. You’ll notice the photo in the esphome write up that the main board looks slightly different, however the “ECO-Plug / PAGECO-PLUGS” board is identical.
Hey - I’m trying to flash in a similar manner to you, but I don’t seem to be able to get the board into programming mode. Do you just hold the reset button down or did you do GPIO0 → ground? And for how long or at what step of the process?
)