Wemo dimmer switch not auto-detected

As I wrote in my last post, please uninstall throgh PaperUI and then put the jar into addons folder

It worked for me. I was able to switch the dimmer on/off! Thank you, good sir!

Hi guys,
i uploaded a new version of the binding here.
It should now read the attributes of the WeMo DimmerSwitch every two minutes and write the result as info into the logfile.

May I ask you to do the following test:

Stop openhab and remove the binding from your addons folder (if older testversion was installed, otherwise uninstall through PaperUI). Place the new binding version into addons folder.

After a restart of openhab, the WemoDimmerHandler should be created and openHAB logfile shouldshow an entry like

Creating a WemoDimmerHandler V0.2 for thing  ....

If it does respond as V0.1, you need to clear your cache folder for openhab to use the new version.

When everything is ok, please change youd WeMoDimmeSwitch to a certain dimming level and wait for about 3 minutes.
Now change the Dimmer to a different level. and wait again.

You should now have at least two blocks in your log beginning with

Attribute response

Please send me those log entries as PM together with the dimming levels you have set.

Hi guys,
I just uploaded a new version (V0.3) which writes more information into the log file.
Please try again as described in my last post.

Best
Hans-Jörg

Should we use the link to Google Drive from your last post?

Yes, the link will stay the same, just the file got updated.

Hi,
i uploaded version V0.4 here.

Changelog:

  • Added methods for channel “brigthness”

Please add the channel as a dimmer item and check if it is working and gets synchronized with the brightness value shown in your WeMo app.

Please report any issues here :

New Version V0.5 is uploaded.

Changelog:
Removed recalculation of brightness values
Some changes in command handling and logging settings.

Everything works now! However, in iPhone app, when I click on the switch lights go off, but the immediately switch changes its state to ON icon, but the lights remain off. When I click on it again, it changes to OFF state and stays that way. Also, when I change the brightness with the dimmer when the lights are OFF, the lights switch icon changes to ON, but the lights stay off. Weird stuff.

Does this happen in iPhone appp only, or can you reproduce it in Basic/Classic UI ?

I can confirm this same behaviour happens for me in iOS app and also in the “control” section of PaperUI. The basic UI works perfectly for me.

Sample video in action. (that’s in the ‘control’ of paperUI). Unfortunately, screen capture doesn’t catch my light going on and off.

With original WeMo app, what happens when you change brightness while switched off ?

The percentage changes but the software switch remains off (and light of course stays off).

Same behaviour as basic ui

So the dimmer reacts the same way within Belkin app, openhab iOS app, Paper/Classic/Basic UI ?
If I understand right, there is just an issue with state shown for switch.

I will call the controls the switch and the dimmer. In BasicUI (and wemo app) things behave as expected. The switch turns light on/off. The dimmer adjusts the percentage brightness (which is only visible when the switch is on).

In the openHAB iOS app and the ‘control’ section of PaperUI: when you switch the light switch from “on” to “off” it immediately turns itself back to “on” position (though the light remains off). If you then turn it to “off” (while light is off) it will stay in “off” position. While in off position, if you adjust the dimmer percentage, the switch turns back to the “on” state (though the light stays off). Only changing the switch from “off” to “on” will turn light on again. Is that clearer?

I included the screen-capture but it wasn’t as helpful as I hoped when I realized you couldn’t see the light going on/off.

edit: I don’t have classic UI installed.

I added subtitles to the video to try to clarify things, if they’re not clear already.

Ha… I had thought there was something more because it had been (I thought) working in the BasicUI for me. But today I am left scratching my head and wondering whether I’m going crazy because BasicUI is same as Paper and iOS app.

Bottom line: you are correct. It seems to be an issue with state for the switch in iOS app, BasicUI and PaperUI. The slider indicating dimming persists state properly it is just the switch (which flips on again after turning off, or flips on for any adjusting of slider).

I’ll continue in the issue-tracking thread on github to see if I can help further there.

Hi guys,
i uploaded a new version here.
Thanks to Brian for the logs.
This new version is a first try of implementing support for fader and nightMode.

Fader : State reading fully implemented, switching working for “OFF” only atm.
NightMode : State reading implemented, no command handling in this version.

Please have a try and post your comments to github issue.

Hi hmerk! I don’t know if i need to open new topic?
I don’t have a WeMo device but i have make a Java program that emulate WeMo switch (just for testing, and, late, i want to make a faux WeMo device, based on fauxmo from makermusings and witnessmenow/esp8266-alexa-wemo-emulator, on github).
Everything works great, but I found one problem in subscribtion on WeMo switch event. I see a strange behavior (in papper UI) when my faux switch send a NOTIFY: openHAB make state of switch always ON, regardless what i send in BinariState tag. I always send a 0, but state of switch is always ON. If i turned him OFF (form openHAB) and send a NOTIFY which sayed that switch is OFF, strangtly, openHAB change state of switch to ON! ???
This is what i send from Java:

NOTIFY /upnpcallback/dev/Socket-1_0-221517K0101707/svc/Belkin/basicevent1/event/cb HTTP/1.1
HOST: 192.168.1.105:8080
CONTENT-TYPE: text/xml; charset="utf-8"
CONTENT-LENGTH: 140
NT: upnp:event
NTS: upnp:propchange
SID: uuid:904bfa3c-1de2-11v2-8728-fd8eebaf4929
SEQ: 1

<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
 <e:property>
    <BinaryState>0</BinaryState>
  </e:property>
</e:propertyset>

and openHAB response:

HTTP/1.1 200 OK
Date: Wed, 30 Aug 2017 00:37:25 GMT
Content-Type: text/xml
Content-Length: 0
Server: Jetty(9.2.19.v20160908)

What I missed?
Dejan

I don’t have a clue.
JUPnP passes the property “BinaryState” and its value to the WeMo binding, which then translates it to ON or OFF.

So you should enable DEBUG or TRACE mode for WeMo binding and JUPnP transport to see what is arriving at openHAB.

And Yes, you should open a new conversation for this topic.