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.
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.
Hi Hans,
First of all thanks so much for this binding. It’s unfortunate that Openhab doesn’t provide this already. I’m still having an issue with your latest binding though. The issue is that if the dimmer is switched off, there is no way for Openhab to turn it on and dim/brighten the lights. However, once the switch is on I have control over the dimmer. Any idea on what’s causing that? I know this is an old thread, maybe you’ve done some work on it since. Anyways, any response would be great, thanks.
When did you download the Binding ?
I received a Dimmer switch in December and was able to implement missing functionality, so from my perspective, my latest uploaded version should support the Dimmer completely.
Sorry, I feel I am using an older version of your binding. Let me have a
look at the entire thread discussion tonight and I’ll try again.
I would like to thank you for all your hard work on this. I read the whole thread and saw what you needed to do and followed it exactly. And, there they were in my inbox! Just like that. I had my two WeMo dimmer switches recognized in openHAB2, and they worked just as expected. Now, I am trying to get some Leviton Decora switches recognized. I hope I can find a thread regarding those switches that is as good as this one. Keep up the good work, and thanks again.
Thanks for your reply. Glad to hear that it works as expected.
I am still working to get it into the distribution, but hardly find the time for it.
hello, what is the difference between the 0.9 snaptshot and the 2.4.0 in paper ui? I notice in the openhab doc that dimmer are working, but when I installed 2.4.0 instead of 0.9, my dimmer binding stop working.
thank you
0.9-snapshot is the internal Eclipse Smarthome version of the Binding. So actually, openHAB 2.4 shows ist as a 2.4 Binding, but in fact it is 0.10-snapshot version.
With the actual reintegration of Eclipse Smarthome into openhab, there will be no more differences between versions. this should happen with upcoming openHAB 2.5.
I removed the 2.4 Wemo Binding using PaperUI. Then I added org.eclipse.smarthome.binding.wemo-0.9.0-SNAPSHOT.jar to /usr/share/openhab2/addons. What am I supposed to do next ? I went to Paper UI - Add-ons and under binding it is still the Wemo 2.4 binding that is listed. In Configuration - Things my 3 existing Wemo light switches are not working and when I try to discover new items the dimmer doesn’t show up. What am I missing here ?
Did you download it from my earlier post?
What firmware is your Dimmer-Switch running?
I went on github page for assistance and found that installing sonos binding would solve problem. now it works. thank you!
Hi all,
I’m grateful for this post, as it solved my issues detecting the Wemo dimmer. However, I’ve since noticed that my openhab.log file is getting inundated with log messages from the dimmer. I’ve set up filters on both the events and openhab logs, but these messages refuse to to be filtered no matter what strings I add to the filters:
19-03-05 19:38:38.551 [INFO ] [nding.wemo.handler.WemoDimmerHandler -
GetNightModeConfiguration response '<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body>
<u:GetNightModeConfigurationResponse xmlns:u="urn:Belkin:service:basicevent:1">
<nightMode>1</nightMode>
<startTime>0</startTime>
<endTime>23400</endTime>
<nightModeBrightness>8</nightModeBrightness>
</u:GetNightModeConfigurationResponse>
</s:Body> </s:Envelope>' for device 'wemo:dimmer:Dimmer-1_0-xxxxxxxxxxxxxx' received
I used “wemo:dimmer:Dimmer-1_0-xxxxxxxxxxxxxx” as the filter string, and I know it’s working because it removes all of the other Wemo dimmer log messages. The only thing I can think of is that this message is being treated differently because of the line breaks. But even then, I would think that any lines that match the filter would be left out.
Any help with this would be much appreciated! These messages are popping up every two minutes, so there are a ton of them in the log.
In KARAF Console enter
log:set WARN org.eclipse.smarthome.binding.wemo
This will filter those info messages. Please note that this binding Version is experimental.