Tried to integrate with Alexa. Alexa detects a single device.
And only Switch one can be controlled via Alexa.
Is this a limitation of Wemo that only one friendly name for one IP address?
If so, is it possible to implement Hue Emulation like in Tasmota where there can be multiple friendly names, therefore multiple devices within a single IP address?
You are correct. The multiple wemo integration is on the TODO list. I was going to do it some time ago, but my tester with Alexa was not available. Do you have some free time and are you willing to test if it works (most likely several times) and potentially help debug issues with that? The Wemo protocol is known, but I don't have Alexa myself so I don't really know how to test it myself.
As a workaround to make the 3-gang switch fully controllable from Alexa, I did the following:
1. Switch 1 could be directly integrated with Alexa using Wemo driver (StartDriver Wemo)
2. Used a smart plug running Tasmota with Hue Bridge Multiple Device Emulation
a. Defined two Dummy Relays using spare GPIOs. b. They appear in Hue emulation page and gave some names
Now the additional two devices can be discovered in Alexa.
On Tasmota device, using scripting language, detected the POWER status of these Dummy Relays and triggered MQTT publish commands towards OpenBK 3-Gang switch for switch2 and switch3.
So until Wemo Multi Device Driver is implemented I have a working setup for the 3-gang switch.
You are correct. The multiple wemo integration is on the TODO list.
I've been playing with the OpenBeken Wemo driver in an attempt to get multiple 'plugs' to be independently controllable from one physical device. I can get as far as detection of all configured rel/btn channels, but Alexa will always just toggle controls for the first channel.
It can advertise multiple controllees, and Alexa will happily list multiple 'plugs', each with its own name. The problem shows up at the control layer: whichever plug I press in Alexa, the HTTP/SOAP requests arriving at OpenBeken always resolve to device/channel 1, so everything ends up toggling the first relay.
I tried to distinguish devices by URL path (/wemo/2/..., /wemo/3/...) and making each virtual device present its own setup.xml and control URLs. That makes the XML look correct, but still Alexa seems to collapse control to a single endpoint when everything shares the same IP:port.
That's when I took a look at how Tasmota does it. Their line is basically - use Wemo emulation for single relay devices, and for anything with multiple relays / lights, use Hue emulation instead. Their multi-Wemo approach isn’t different URL paths on one port — it’s separate TCP ports per virtual device.
To replicate with OpenBeken I don't know what would mean for http listener, sockets, memory use etc - development beyond drv_wemo.c I assumed, and maybe not worth the effort. Hue should probably be developed instead.
So instead I refocused on making single-device Wemo emulation as correct and faithful as possible, because that is still genuinely useful for a lot of simple plug/relay devices.
Changes I've tried to make to the Wemo driver:
-Fixed up setup.xml so fields like serialNumber and presentationURL are correct and consistent
-Made SSDP replies more “Wemo-ish” and tolerant for scanners by responding to both:
urn:Belkin:device:** and
urn:Belkin:device:controllee:1
-Improved SOAP parsing for GetBinaryState / SetBinaryState so it’s not relying on one very specific substring.
-XML-escaped the friendly name so labels don’t break XML.
-Kept the classic level state variable in eventservice.xml for better compatibility.
-implemented stop/start function
So the driver now will only present one device for discovery - the selection logic is this:
Scan channels from lowest index upwards (Channel 1, then 2, then 3…).
Pick the first channel that is considered a relay, i.e. it matches either:
CHANNEL_IsPowerRelayChannel(idx) or
h_isChannelRelay(idx) (relay-ish channel type)
If no relay channel is found, fall back to the first channel of type ChType_Toggle.
If nothing matches, Wemo effectively has no controllable channel (no “plug” state).
Upgrade from general release doesn't seem to affect operation. If the channel has a label when added to Alexa, that name will be used.
I don't have Alexa to try but if it works better, then I can merge.
divadiow wrote:
It can advertise multiple controllees, and Alexa will happily list multiple 'plugs', each with its own name. The problem shows up at the control layer: whichever plug I press in Alexa, the HTTP/SOAP requests arriving at OpenBeken always resolve to device/channel 1, so everything ends up toggling the first relay.
I tried to distinguish devices by URL path (/wemo/2/..., /wemo/3/...) and making each virtual device present its own setup.xml and control URLs. That makes the XML look correct, but still Alexa seems to collapse control to a single endpoint when everything shares the same IP:port.
Is it even possible to do it on single port? I mean, supported by protocol? Or straight up impossible?
divadiow wrote:
That's when I took a look at how Tasmota does it. Their line is basically - use Wemo emulation for single relay devices, and for anything with multiple relays / lights, use Hue emulation instead. Their multi-Wemo approach isn’t different URL paths on one port — it’s separate TCP ports per virtual device.
To replicate with OpenBeken I don't know what would mean for http listener, sockets, memory use etc - development beyond drv_wemo.c I assumed, and maybe not worth the effort. Hue should probably be developed instead.
I think this using TCP socket instead of HTTP server is very, very simple. I assume they don't fragmentate packets? Still, separate sockets is the easiest part for me.
HTTP header can be parsed just with few lines, there is not match there, sockets can be kept in array, and with enough luck, you can use single buffer for received and sent data - no need for separate buffers. I know that OBK HTTP server has separate buffers, but I would try with single buffer first. It should work as long as packets are not long...
I could help more with it if issue arise, depending on free time, currently I am finish ESP32 support for flasher.
I could also try to make a minimal "multi port server demo"... I mean, I don't know Wemo protocol, but if you are asking just about HTTP overheat, then I think it's very low. I wouldn't worry about this extra layer. You basically create TCP socket, and for read and write operations, you just handle HTTP Header.
✨ The OpenBeken DS-101JL 3-Gang Switch was successfully flashed with OpenBeken firmware and integrated with Alexa using the Wemo driver. However, Alexa only detects and controls one switch due to Wemo's limitation of supporting a single friendly name per IP address. The user inquired about implementing Hue Emulation, similar to Tasmota's multi-device support, which allows multiple friendly names and devices on one IP. The developer acknowledged the Wemo multi-device integration is planned but requires testing, as they lack Alexa hardware. As a workaround, the user employed a Tasmota-based smart plug with Hue Bridge Multiple Device Emulation, creating dummy relays that appear as separate devices in Alexa. These dummy devices trigger MQTT commands to control the additional switches on the DS-101JL. Subsequent posts requested updates on Wemo multi-device or Hue Emulation support, but no progress was reported.
