Belkin WeMo plugin

[quote=“SM2k, post:120, topic:175071”]So it appears that Mr Coffee has made a WEMO enabled coffee maker. (My $12 coffee maker plus appliance switch solution from last year ended abruptly when the heating element in the coffee maker wouldn’t shut off. fire hazards have low WAF…)

I don’t own any WEMO devices to date so forgive my ignorance in this area, but I’m just trying to gauge how much complexity would be involved in getting this working with vera.

Do WEMO devices need some sort of central hub on the LAN or are they all standalone?

I assume the WEMO plugin would need to have coffee maker specific code added to it?[/quote]

No central hub for WEMO devices, they just attach to your network.

I don’t think the plugin would need anything different for the coffee maker necessarily - it’s probably got similar upnp to the outlet and the wall switch. So it’d just show up as an on/off device that you could create a scene for.

[quote=“strohlde, post:121, topic:175071”][quote=“SM2k, post:120, topic:175071”]So it appears that Mr Coffee has made a WEMO enabled coffee maker. (My $12 coffee maker plus appliance switch solution from last year ended abruptly when the heating element in the coffee maker wouldn’t shut off. fire hazards have low WAF…)

I don’t own any WEMO devices to date so forgive my ignorance in this area, but I’m just trying to gauge how much complexity would be involved in getting this working with vera.

Do WEMO devices need some sort of central hub on the LAN or are they all standalone?

I assume the WEMO plugin would need to have coffee maker specific code added to it?[/quote]

No central hub for WEMO devices, they just attach to your network.

I don’t think the plugin would need anything different for the coffee maker necessarily - it’s probably got similar upnp to the outlet and the wall switch. So it’d just show up as an on/off device that you could create a scene for.[/quote]

Well, I’ve ordered one, so I can let you know. This device is a little more complex than a simple on/off switch, but not by much. After all, it does have the concept of “ready to brew/brewing/idle” that is also relevant

I have the same problem…

Here is the setup.xml for the Belkin coffee maker. It looks like a few new events exist. @futzle, do you still dabble with this plugin? If you do, I’d be happy to be a guinea pig if you’re interested in supporting this device.

<?xml version="1.0"?>
<root xmlns="urn:Belkin:device-1-0">
  <specVersion>
    <major>1</major>
    <minor>0</minor>
  </specVersion>
  <device>
<deviceType>urn:Belkin:device:CoffeeMaker:1</deviceType>
<friendlyName>CoffeeMaker</friendlyName>
    <manufacturer>Belkin International Inc.</manufacturer>
    <manufacturerURL>http://www.belkin.com</manufacturerURL>
    <modelDescription>Belkin Plugin Socket 1.0</modelDescription>
<modelName>CoffeeMaker</modelName>
    <modelNumber>1.0</modelNumber>
    <modelURL>http://www.belkin.com/plugin/</modelURL>
<serialNumber>hidden</serialNumber>
<UDN>uuid:CoffeeMaker-1_0-hidden</UDN>
    <UPC>123456789</UPC>
<macAddress>hidden</macAddress>
<firmwareVersion>WeMo_WW_2.00.7284.PVT</firmwareVersion>
<iconVersion>1|49154</iconVersion>
<binaryState>1</binaryState>
<DeviceID>hidden</DeviceID>
<DeviceFWVersion>MC13805-140715</DeviceFWVersion>
<brandName>MrCoffee</brandName>
    <iconList>
      <icon>
        <mimetype>jpg</mimetype>
        <width>100</width>
        <height>100</height>
        <depth>100</depth>
         <url>icon.jpg</url>
      </icon>
    </iconList>
    <serviceList>
      <service>
        <serviceType>urn:Belkin:service:WiFiSetup:1</serviceType>
        <serviceId>urn:Belkin:serviceId:WiFiSetup1</serviceId>
        <controlURL>/upnp/control/WiFiSetup1</controlURL>
        <eventSubURL>/upnp/event/WiFiSetup1</eventSubURL>
        <SCPDURL>/setupservice.xml</SCPDURL>
      </service>
      <service>
        <serviceType>urn:Belkin:service:timesync:1</serviceType>
        <serviceId>urn:Belkin:serviceId:timesync1</serviceId>
        <controlURL>/upnp/control/timesync1</controlURL>
        <eventSubURL>/upnp/event/timesync1</eventSubURL>
        <SCPDURL>/timesyncservice.xml</SCPDURL>
      </service>
      <service>
        <serviceType>urn:Belkin:service:basicevent:1</serviceType>
        <serviceId>urn:Belkin:serviceId:basicevent1</serviceId>
        <controlURL>/upnp/control/basicevent1</controlURL>
        <eventSubURL>/upnp/event/basicevent1</eventSubURL>
        <SCPDURL>/eventservice.xml</SCPDURL>
      </service>
      <service>
        <serviceType>urn:Belkin:service:deviceevent:1</serviceType>
        <serviceId>urn:Belkin:serviceId:deviceevent1</serviceId>
        <controlURL>/upnp/control/deviceevent1</controlURL>
        <eventSubURL>/upnp/event/deviceevent1</eventSubURL>
        <SCPDURL>/deviceservice.xml</SCPDURL>
      </service>
      <service>
        <serviceType>urn:Belkin:service:crockpotevent:1</serviceType>
        <serviceId>urn:Belkin:serviceId:crockpotevent1</serviceId>
        <controlURL>/upnp/control/crockpot1</controlURL>
        <eventSubURL>/upnp/event/crockpot1</eventSubURL>
        <SCPDURL>/jardenservice.xml</SCPDURL>
      </service>
    <service>
        <serviceType>urn:Belkin:service:jardenevent:1</serviceType>
        <serviceId>urn:Belkin:serviceId:jardenevent1</serviceId>
        <controlURL>/upnp/control/jardenevent1</controlURL>
        <eventSubURL>/upnp/event/jardenevent1</eventSubURL>
        <SCPDURL>/jardenservice.xml</SCPDURL>
      </service>
      <service>
        <serviceType>urn:Belkin:service:firmwareupdate:1</serviceType>
        <serviceId>urn:Belkin:serviceId:firmwareupdate1</serviceId>
        <controlURL>/upnp/control/firmwareupdate1</controlURL>
        <eventSubURL>/upnp/event/firmwareupdate1</eventSubURL>
        <SCPDURL>/firmwareupdate.xml</SCPDURL>
      </service>
      <service>
        <serviceType>urn:Belkin:service:rules:1</serviceType>
        <serviceId>urn:Belkin:serviceId:rules1</serviceId>
        <controlURL>/upnp/control/rules1</controlURL>
        <eventSubURL>/upnp/event/rules1</eventSubURL>
        <SCPDURL>/rulesservice.xml</SCPDURL>
      </service>

      <service>
        <serviceType>urn:Belkin:service:metainfo:1</serviceType>
        <serviceId>urn:Belkin:serviceId:metainfo1</serviceId>
        <controlURL>/upnp/control/metainfo1</controlURL>
        <eventSubURL>/upnp/event/metainfo1</eventSubURL>
        <SCPDURL>/metainfoservice.xml</SCPDURL>
      </service>

      <service>
        <serviceType>urn:Belkin:service:remoteaccess:1</serviceType>
        <serviceId>urn:Belkin:serviceId:remoteaccess1</serviceId>
        <controlURL>/upnp/control/remoteaccess1</controlURL>
        <eventSubURL>/upnp/event/remoteaccess1</eventSubURL>
        <SCPDURL>/remoteaccess.xml</SCPDURL>
      </service>

      <service>
        <serviceType>urn:Belkin:service:deviceinfo:1</serviceType>
        <serviceId>urn:Belkin:serviceId:deviceinfo1</serviceId>
        <controlURL>/upnp/control/deviceinfo1</controlURL>
        <eventSubURL>/upnp/event/deviceinfo1</eventSubURL>
        <SCPDURL>/deviceinfoservice.xml</SCPDURL>
      </service>

      <service>
        <serviceType>urn:Belkin:service:smartsetup:1</serviceType>
        <serviceId>urn:Belkin:serviceId:smartsetup1</serviceId>
        <controlURL>/upnp/control/smartsetup1</controlURL>
        <eventSubURL>/upnp/event/smartsetup1</eventSubURL>
        <SCPDURL>/smartsetup.xml</SCPDURL>
      </service>

      <service>
        <serviceType>urn:Belkin:service:manufacture:1</serviceType>
        <serviceId>urn:Belkin:serviceId:manufacture1</serviceId>
        <controlURL>/upnp/control/manufacture1</controlURL>
        <eventSubURL>/upnp/event/manufacture1</eventSubURL>
        <SCPDURL>/manufacture.xml</SCPDURL>
      </service>

    </serviceList>
   <presentationURL>/pluginpres.html</presentationURL>
</device>
</root>

I don’t, but if all you want is for your coffee machine to appear as an on/off device in Vera then it’s a simple edit of the L_WeMo1.lua file. Towards the top there’s a list of device types that the plugin recognizes. Just add another row for “urn:Belkin:device:CoffeeMaker:1”. If it reacts to the “BinaryState” basic event then it should Just Work.

Controlling other aspects of the coffee machine would be a bigger undertaking: you would need a new device JSON file for the UI buttons, additional actions in the I_WeMo1.xml file, and extra functions in the L_WeMo1.lua file. The latter two will be largely copy-and-paste from the existing handleSetTarget() function.

Thanks! I’ll poke around. The device may or may not respond as a binary switch; given that Crock Pot and Mr Coffee are Jarden brands, my guess is that GetJardenStatus and SetJardenStatus will be events I need to worry about. I probably won’t get around to messing about with this for several weeks yet, but I’ll post code to this thread if I ever manage to get something I expect others will be able to benefit from.

I can’t seem to find an answer for this question anywhere so I thought I’d try here… Are there any known concerns with regards to using a wemo light switch to turn on and off a Hue bulb??

I’m particularly worried about dimming the hue bulb from the hue app… Will that have any negative effects on the wemo light switch?

The reason I ask is because I still want to be able to turn on the hue bulb from my iPhone/tablet etc without leaving the (standard) light switch in the always on position.

Thanks for any advice you can provide

Anyone have this working with a demo insight switch? I have UI7 and the switch set to a static IP. The plugin will not automatically find the device and when I use the static IP the device is created but will not turn on or off.

Any idea if this product from Wemo could or would be supported with this plugin under UI5?

[quote=“Pseudomizer, post:129, topic:175071”]Any idea if this product from Wemo could or would be supported with this plugin under UI5?

I’m almost certain the crock pot will not work with the current plugin. The Belkin coffee maker (also a Jarden branded product) does not respond as a binary switch (it simply responds that it’s state is now “Error” if you try). Commands for crockpot state are mixed in with commands such as GetJardenStatus etc under the jardenevent interface, so I assume the coffee maker and crockpot are very similar from an API perspective.

I spent some time poking at my coffee maker a bit ago, and eventually managed to poll the status of the coffee maker (I assume I could subscribe to events and have the coffee maker report its status instead of polling it, but haven’t gotten around to doing that). I was unable to actually instruct the coffee maker to brew coffee.

I’m trying to get my WeMo motion sensors to work. The problem is I’ve added them using this plugin and the uPNP plugin. However when I try to execute a scene using the motion sensor as a trigger it doesn’t work. So when I try to do is click on the wrench and pole or automatically configure the device but what I get is device is not ready or cant communicate with the vice. The issue is that I try to add and remove the multiple times but cannot get it to work. any help would be appreciated

Sent from my iPhone using Tapatalk

[quote=“Bboy486”]I’m trying to get my WeMo motion sensors to work. The problem is I’ve added them using this plugin and the uPNP plugin. However when I try to execute a scene using the motion sensor as a trigger it doesn’t work. So when I try to do is click on the wrench and pole or automatically configure the device but what I get is device is not ready or cant communicate with the vice. The issue is that I try to add and remove the multiple times but cannot get it to work. any help would be appreciated

Sent from my iPhone using Tapatalk[/quote]

I found out the cause. It seems I was getting a lua error on one of the WeMo devices. This caused the other devices to not respond for some reason. Well I added two of the devices and it has been working for a few hours.

Sent from my iPhone using Tapatalk

Vera keeps losing the ability to control my wemo light switch and appliance switch. I had it setup through Vera for about 6 months now and I’ve had to uninstall /reinstall the wemo plugin twice now… This will be the 3rd time.

I also have those two wemos part of my outdoor lights scene where all my outdoor lights would turn on at dusk and off at 11pm. They usually work well but randomly they would fail to turn on… All the other GE zwave switches work flawlessly. It’s not a big deal… Just wondering if that could be fixed as well.

I don’t mean to offend anyone but is problems like this par for course when it comes to 3rd party plugins?

I’ve given my wemo devices a static IP address , would that have anything to do with it?

Thanks

There is no one to fix it. This plugin is no longer maintained. I am the original author of the plugin but I have no WeMo equipment any more. I believe that MCV has a couple of bits of WeMo equipment, and they’ve recently patched the plugin to make it function on UI7, but they haven’t shown a lot of enthusiasm over taking over active maintenance of the plugin. I guess that WeMo compatibility isn’t high on their list of priorities.

Anyone who wants to take over development and maintenance of the plugin is welcome to do so. I’ll happily hand over the keys to the repository.

I don't mean to offend anyone but is problems like this par for course when it comes to 3rd party plugins?

Well … yes. It is. A lot of free* software takes pains to remind its users that the software is supplied as-is, without any warranty and without any implied fitness for purpose. There’s a great deal of Managing User Expectations in developing software. In the Vera community, it’s harder than average because there are users without any technical expertise rubbing directly up against developers, with almost no common ground except that both happen to own Veras. The users are frustrated because they’ve been led to believe (perhaps with MCV’s tacit approval) that plugins meet some unstated standard of quality. Developers are frustrated because they can’t get useful support from MCV (such as an easy way for nontechnical users to supply logs of failing plugins) and can’t help users to fix their problems. Users themselves may be under pressure from other members of their family, particularly if the user has sold them the concept of automation based on high WAF. (Developers are under the same pressure, FWIW.)

In the specific case of the WeMo plugin, the plugin environment (LuaUPnP) struggles to keep communication up with WeMo devices in the face of restarts. Fixing this would have required MCV to make architectural changes to LuaUPnP, such as letting plugins run multithreaded code. Add to this that WeMo devices themselves have memory leaks and eventually refuse to communicate over the UPnP protocol until they are rebooted. (Perhaps Belkin has fixed this now.) WeMo automation was just never going to be as rock-solid as a lower-level protocol like Z-Wave.

I've given my wemo devices a static IP address , would that have anything to do with it?

Static IP is recommended in the setup instructions.

  • The WeMo plugin is Free-as-in-beer and Free-as-in-speech.

Thank you very much for the detailed reply… I can certainly see what your saying with regards to end users v. Developers, we speak different languages and with Vera advertising the vast plugin library, which sold me, you would expect it to work as intended.

Thank you very much for supplying this plugin to the community, it’s plugins like yours and many of the others that no doubt bring ppl to Vera in large numbers. There should be some for of compensation or official help provided from Vera.

There is no one to fix it. This plugin is no longer maintained. I am the original author of the plugin but I have no WeMo equipment any more. I believe that MCV has a couple of bits of WeMo equipment, and they’ve recently patched the plugin to make it function on UI7, but they haven’t shown a lot of enthusiasm over taking over active maintenance of the plugin. I guess that WeMo compatibility isn’t high on their list of priorities.

Anyone who wants to take over development and maintenance of the plugin is welcome to do so. I’ll happily hand over the keys to the repository.

I don't mean to offend anyone but is problems like this par for course when it comes to 3rd party plugins?

Well … yes. It is. A lot of free* software takes pains to remind its users that the software is supplied as-is, without any warranty and without any implied fitness for purpose. There’s a great deal of Managing User Expectations in developing software. In the Vera community, it’s harder than average because there are users without any technical expertise rubbing directly up against developers, with almost no common ground except that both happen to own Veras. The users are frustrated because they’ve been led to believe (perhaps with MCV’s tacit approval) that plugins meet some unstated standard of quality. Developers are frustrated because they can’t get useful support from MCV (such as an easy way for nontechnical users to supply logs of failing plugins) and can’t help users to fix their problems. Users themselves may be under pressure from other members of their family, particularly if the user has sold them the concept of automation based on high WAF. (Developers are under the same pressure, FWIW.)

In the specific case of the WeMo plugin, the plugin environment (LuaUPnP) struggles to keep communication up with WeMo devices in the face of restarts. Fixing this would have required MCV to make architectural changes to LuaUPnP, such as letting plugins run multithreaded code. Add to this that WeMo devices themselves have memory leaks and eventually refuse to communicate over the UPnP protocol until they are rebooted. (Perhaps Belkin has fixed this now.) WeMo automation was just never going to be as rock-solid as a lower-level protocol like Z-Wave.

I've given my wemo devices a static IP address , would that have anything to do with it?

Static IP is recommended in the setup instructions.

  • The WeMo plugin is Free-as-in-beer and Free-as-in-speech.[/quote]

Would there be a way in Vera to set a scene to reboot all wemos on the lan? Wouldn’t that help to restart the process?

Sent from my iPhone using Tapatalk

I have a WEMO switch that works via the WEMO app on my iPhone, but when I downloaded the Vera app and assigned the static IP, I get a “Lua Failure” notice on the device and cannot control the device via Vera. I can still control it via the WEMO app on the phone, or by manually pressing the green power button on the switch.

I know the developer does not support the Vera plugin, but has anyone faced the same issue and have a resolution?

Thanks in advance.

I’m in the middle of moving, so will not be able to look at messing with the wemo plugin until mid summer at the soonest, but thought I’d pass on some successful reverse engineering with respect to the belkin wemo coffee maker. the following curl command will start a brew cycle on your coffee maker if it’s ready to party (port is 49153):

curl -0 -A '' -X POST -H 'Accept: ' -H 'Content-type: text/xml; charset="utf-8"' -H "SOAPACTION: \"urn:Belkin:service:deviceevent:1#SetAttributes\"" --data '<?xml version="1.0" encoding="utf-8"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:SetAttributes xmlns:u="urn:Belkin:service:deviceevent:1"><attributeList>&lt;attribute&gt;&lt;name&gt;Brewed&lt;/name&gt;&lt;value&gt;NULL&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;LastCleaned&lt;/name&gt;&lt;value&gt;NULL&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;ModeTime&lt;/name&gt;&lt;value&gt;NULL&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;Brewing&lt;/name&gt;&lt;value&gt;NULL&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;TimeRemaining&lt;/name&gt;&lt;value&gt;NULL&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;WaterLevelReached&lt;/name&gt;&lt;value&gt;NULL&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;Mode&lt;/name&gt;&lt;value&gt;4&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;CleanAdvise&lt;/name&gt;&lt;value&gt;NULL&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;FilterAdvise&lt;/name&gt;&lt;value&gt;NULL&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;Cleaning&lt;/name&gt;&lt;value&gt;NULL&lt;/value&gt;&lt;/attribute&gt;</attributeList></u:SetAttributes></s:Body></s:Envelope>' -s http://$IP:$PORT/upnp/control/deviceevent1

This command can be used to poll the coffee maker for its current state:

[code]curl -0 -A ‘’ -X POST -H 'Accept: ’ -H ‘Content-type: text/xml; charset=“utf-8”’ -H “SOAPACTION: "urn:Belkin:service:deviceevent:1#GetAttributes"” --data ‘<?xml version="1.0" encoding="utf-8"?><s:Envelope xmlns:s=“http://schemas.xmlsoap.org/soap/envelope/” s:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”><s:Body><u:GetAttributes xmlns:u=“urn:Belkin:service:deviceevent:1”></u:GetAttributes></s:Body></s:Envelope>’ -s http://$IP:$PORT/upnp/control/deviceevent1

<s:Envelope xmlns:s=“http://schemas.xmlsoap.org/soap/envelope/” s:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”><s:Body>
<u:GetAttributesResponse xmlns:u=“urn:Belkin:service:deviceevent:1”>
&lt;attribute&gt;&lt;name&gt;Mode&lt;/name&gt;&lt;value&gt;5&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;ModeTime&lt;/name&gt;&lt;value&gt;13&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;TimeRemaining&lt;/name&gt;&lt;value&gt;0&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;WaterLevelReached&lt;/name&gt;&lt;value&gt;1&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;CleanAdvise&lt;/name&gt;&lt;value&gt;0&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;FilterAdvise&lt;/name&gt;&lt;value&gt;0&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;Brewing&lt;/name&gt;&lt;value&gt;1428161452&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;Brewed&lt;/name&gt;&lt;value&gt;1428161604&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;Cleaning&lt;/name&gt;&lt;value&gt;0&lt;/value&gt;&lt;/attribute&gt;&lt;attribute&gt;&lt;name&gt;LastCleaned&lt;/name&gt;&lt;value&gt;0&lt;/value&gt;&lt;/attribute&gt;
</u:GetAttributesResponse>
[/code]

The interesting value inside that xml-escaped list is Mode. Mode is one of these values:

0|Refill
1|PlaceCarafe
2|RefillWater
3|Ready
4|Brewing
5|Brewed
6|CleaningBrewing
7|CleaningSoaking
8|BrewFailCarafeRemoved

I don’t expect that anybody will pick up this plugin any time soon, but I haven’t been able to find any reference to the above in any public forum so it’s important to record it somewhere at least :slight_smile:

That’s good stuff. It looks like Belkin hasn’t significantly changed the UPnP implementation that they are using, so it may be as easy as adding actions for the new serviceId (urn:Belkin:service:deviceevent:1) and the new command (SetAttributes). See the plugin’s handleSetTarget() function for the code you’d need to copy and modify.

Hope someone figures out how to get this to work soon. Would certainly be willing to help fund the solution.