Kasa EP10 in EU version

[PoulKlemmensen]

Hi.

I am trying to build a solder free version of your freezer control, but am having problems finding an eu version of the EP10 smart plug. Do you have any idea of what to look for ?

I have bought a P110 plug, but the discovery part does not work. Not way that I have figured out. Do I load any alternative firmware onto it ??

[thorrak]

Hey there!

The existing "smart plug" integration only works with TP-Link's Kasa line of WiFi smart plugs, unfortunately. Although TP-Link manufactures the P110, that is released under their "Tapo" brand, which apparently uses a completely different control mechanism than the Kasa switches I built/tested for.

Although I don't have an alternative to recommend to you just yet, in researching some alternatives just now I saw a handful of generic brands which come pre-flashed with the Tasmota firmware. Without making any promises for the future, I just ordered one from CloudFree which appears to have a EU-plug analogue. More to come!

[PoulKlemmensen]

I have been playing around with mine, a P110. And I have found a piece of Python code, that looks like something running locally, and I can turn on and off my plug. Not sure if that can be used for anything?

It requires you to create a cloud profile, and defining your plug in that. But besides this, it seems to be running complete locally.

The basis is this here: https://github.com/fishbigger/TapoP100

[thorrak]

It can absolutely be done, the issue I have is just building a module that supports another type of “custom” encryption/protocol when the manufacturer can (hypothetically) come lock it down with a firmware update at any time. Tasmota is open source/free, so if I can get that working, it should work forever — in theory.

Unfortunately for me, I received my Tasmota plug yesterday, and am now realizing that there doesn’t seem to be a good solution for non-MQTT auto discovery. I much prefer “plug everything in and it ‘just works’” to having to hope users can figure out how to assign static IPs to their relays — or worse, not, and risk their beer being uncontrolled after the next power outage. I haven’t given up yet, but more to come soon.

[thorrak]

I have officially given up on Tasmota. There are four methods Tasmota supports for autodiscovery best I can tell, none of which are ideal for this project:

• HAST Autodiscovery - This seems to be something MQTT-based, but specifically designed for integrations with Home Assistant. I can't find much documentation on it, but the fact that it seems to be MQTT-based best I can tell means that it's not really an option, as I don't want to force users to run an MQTT broker on their network, and don't want the overhead of building one into BrewPi-ESP.
• MQTT Autodiscovery - Same drawbacks as above, but better documented. Unfortunately, it has the added drawback of not being present in default Tasmota builds, and thus I can't assume off-the-shelf devices running Tasmota will support it.
• mDNS Autodiscovery - Although this would be my preferred way to locate devices, similar to MQTT Autodiscovery it isn't present by default in Tasmota builds, and flashing new firmware isn't trivial -- at least for the device I own. You could theoretically try to flash OTA, but if the device dies mid-flash I don't want users coming back and blaming me for it. ;)
• SSDP (UPNP) via Belkin Wemo or Phillips Hue Emulation - This is what I was hoping I could get to work, but it sounds like there are SEVERE performance hits to the Tasmota plug from enabling this due to the amount of noise SSDP generates on a network.

[PoulKlemmensen]

Think that I am trying the Tasmota one. The discovery I am not afraid of, I do have MQTT anyway. Will give it a try.

[thorrak]

Think that I am trying the Tasmota one. The discovery I am not afraid of, I do have MQTT anyway. Will give it a try.

The problem is that the BrewPi doesn't have MQTT, so even if the Tasmota relay can interface with your MQTT broker, BrewPi doesn't. :(

[PoulKlemmensen]

But the Tasmota do have an open and straight forward API, as I have understood it, right ? Then you just need to figure out what IP or what name the device have. Would it be possible to set a certain port on the device, then scan a certain range for that port.... Know that this might be a hack, but .... Or simply put in the name of the device.

Know that you don't want to work with IP, but autodiscovery on a network with more devices, you will in most cases end up having to figure it out anyway. What is what...

Further, I have made a small change, that delay the stop of the internal fan, meaning that I might need two devices pr. freezer.

Just ideas....

[kaigoh]

I've asked a question in a separate issue, and found this thread afterwards. I'll reference this issue in my new one, so that at least the two are linked if anyone finds this via Google.

I have worked on another project that made use of Tasmota, which definitely revealed some of the drawbacks of certain design choices, which means MQTT is basically the only real choice. With that in mind, could you embed something like uMQTTBroker directly in the firmware, as we are likely only going to be managing a maximum of two plugs? Or give the user the option of an external broker?

[thorrak]

You hit the nail on the head, unfortunately. Autodiscovery - especially on networks with dynamic IP assignment - is a difficult (and necessary!) problem to solve with the way that the firmware has been built.

Although adding MQTT support is an option, it introduces a number of difficulties with ongoing maintenance. This is something I experience most recently with Prometheus support which I’ve since had to disable in order to create the web-based interface that exists now. As a result, absent, compelling reason to do so, my view at the moment is to avoid introducing a new dependency.

I am very open to adding additional outlet types if one can be found that doesn’t require the overhead of something like MQTT - but at the moment, I don’t think that Tasmota is it.

[kaigoh]

Just a bit of an update with this...

In my travels working on other projects, I came across a similar need - m2m communications but without being able to run an MQTT server. I needed a hub and spoke layout, with a central server and many clients, both being either ESP32 or ESP8266. I can't guarantee that the final environment can run an MQTT broker, so I've been scratching my head.

What I've come up with is effectively an "abuse" of MDNS service TXT records. Now you can't exactly store much data in there, but for my needs it worked out nicely. As long as you are sensible with read / write frequencies, it works well.

It will require custom firmware on the plugs, but that isn't a huge issue if you're already flashing ESPs anyway?

Just an idea...

[PoulKlemmensen]

I can totally understand thorrak and his statements about support and so on. And I don't want to relate to that, that is totally his call.

But I have made my own version of his firmware, where I use a local MQTT server, one that I have in the house anyway. My take is, that MQTT is made for situations like this and have build-in features for handling communication errors and reboots etc...

[thorrak]

What I've come up with is effectively an "abuse" of MDNS service TXT records. Now you can't exactly store much data in there, but for my needs it worked out nicely. As long as you are sensible with read / write frequencies, it works well.

How are you abusing mDNS? Pretty sure that’s what it was meant to do - though I would use service records, myself. ;)

mDNS would actually be my preferred method of doing things. The BrewPi-ESP firmware already advertises a “_brewpi” service via mDNS to help locally hosted Fermentrack instances detect and set up new controllers - I’d just assume use the same technology to set up plugs on the network if I could.

It will require custom firmware on the plugs, but that isn't a huge issue if you're already flashing ESPs anyway?

The issue is that someone would have to build and maintain the custom firmware, and I don’t have time to add another project like this.

Although it would be simple enough to build a very basic image for an ESP32 that exposes a service via mDNS and does nothing but allow you to set a relay state, at that point you’re building custom hardware which kind of defeats the purpose. A big part of the attraction is that you can buy something self-contained rather than having to cobble something together.

Building custom firmware for any manufacturer’s hardware is another option - but that then again requires someone to maintain it as they update things (and most packaged relays don’t have easily accessible programming pins, unfortunately).

[kaigoh]

How are you abusing mDNS? Pretty sure that’s what it was meant to do - though I would use service records, myself. ;)

I'm updating the TXT records far more often than you'd "normally" do, that's about as far as my abuse goes :)

Regarding the need for additional custom firmware, I agree and understand your position. I just wanted to point out that I'd found a way in case anyone wanted to carry the torch forward or implement it in their own projects. As for supported hardware, my custom firmware using the approach is happily purring along on a flashed (ex-)Tasmota smart plug.

[thorrak]

I just searched, and things may have changed since we started our discussion: https://github.com/arendst/Tasmota/discussions/15579#discussioncomment-9579074

It sounds like mDNS may now be reenabled by default on ESP32-based Tasmota devices. I don't have a Tasmota device handy, but if you have some spare time and don't mind reflashing the stock firmware, would you mind seeing if that works (assuming yours is ESP32 based)?

[kaigoh]

It sounds like mDNS may now be reenabled by default on ESP32-based Tasmota devices. I don't have a Tasmota device handy, but if you have some spare time and don't mind reflashing the stock firmware, would you mind seeing if that works (assuming yours is ESP32 based)?

Seems that's not the case :( https://github.com/arendst/Tasmota/blob/645ce4a1ee0a68eb98b1a6e715da922760e770bc/BUILDS.md#L25

Just to be sure, I flashed the latest OTA firmware and no MDNS advertising. I wonder if there is a straightforward way of building a customised firmware with the flag set using GitHub actions or something similar?