Can OpenBeken’s Wemo emulation control multiple relays from Alexa on one device, or do I need Hue emulation like Tasmota?
OpenBeken’s current Wemo emulation only exposes one controllable device per physical IP, so Alexa will discover one switch and usually control only the first relay; multi-device Wemo support is still on the TODO list [#20583903][#21837104][#21837455] Alexa can list multiple virtual plugs, but control still collapses to channel 1 when everything shares the same IP:port, and Tasmota’s multi-Wemo approach uses separate TCP ports per virtual device rather than just different URL paths [#21837104] The current OpenBeken Wemo driver therefore behaves as a single-device integration and picks the first relay-like channel it finds [#21837104] As a workaround, one user made switch 1 work directly with Wemo, then used a Tasmota device with Hue Bridge Multiple Device Emulation and dummy relays for the extra Alexa devices, forwarding those relay states to OpenBeken via MQTT for switch 2 and switch 3 [#20623298]
AI summary based on the discussion. May contain errors.
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 discussion concerns integrating an OpenBeken-flashed DS-101JL 3-gang switch with Alexa using the Wemo and SSDP drivers. Alexa initially discovers only one device, and only the first relay can be controlled, suggesting a limitation in the current Wemo implementation for multiple channels per IP/device. Multiple-device Wemo support is identified as a TODO item, and testing with an Echo Dot is requested. As a workaround, a Tasmota smart plug with Hue Bridge multiple-device emulation is used to expose additional virtual devices to Alexa, then MQTT and scripting are used to control the remaining OpenBeken switch channels. Later posts report continued attempts to make OpenBeken’s Wemo driver advertise multiple independently controllable plugs, but Alexa still routes control to channel 1 even when multiple endpoints and setup.xml entries are exposed. Development notes indicate the Wemo/SSDP code was optimized for size but remains limited to one Wemo device per physical OpenBeken device. AI summary based on the discussion. May contain errors.
