Our engineering team has provided the facts on this one, and here is the summary on Jasco Dimmer switches manual state changes being reflected in the app:
"There is a Lutron patent that prevents products that haven’t licensed the patent from sending the status of a radio controlled switch when someone physically actuates the device. The Jasco dimmers and switches don’t license the patent so they don’t do that. We’ve worked around this problem in our hub by taking advantage of the fact that these devices do send an association command when you actuate them. When the hub received this command it reads the status of the device (which does not violate the patent) and sends it to the cloud.
This work-around works OK for switches because they change their state right away. So if you click the switch on, it responds to the hub’s read request with an “on” status.
However the dimmers turn on gradually when you click them. So when the hub issues the read the level value is small but non-zero.
Either a refresh or the poll command*, which runs periodically, will cause the proper state to be displayed."
(*Note the “poll command” is sent from our cloud to the hub approx every 5 minutes.)
So just because they work doesn’t mean they work… If it’s an on/off switch and it’s in direct communication with the Hub (ie, not via the mesh) then it generally will work as expected. But if it’s a dimmer, it doesn’t show off correctly. Furthermore, it appear that if the device is communicating over the mesh network then it appears to often not report on or off directly whether a switch or a dimmer.
This is referred to as “Instant Status” by some Home Automation suppliers.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
22
Hmmm…
Best I can tell is that my dimmer “outlets” instantly set on/off up tapping the physical switch, not the current Level (unless asking explicitly for level). So if associate event causes a poll, it will see “on”, not a zero level.
The outlets default on brings the level up to the setting prior to the shut off.
If it’s showing off when you tap it, it sounds like it’s associating… maybe.
What’s happening is this: With an associating switch:
Turn on: The switch/dimmer says to the hub: I’ve been turned on!
Turn off: The switch/dimmer says: I’ve been turned off!
With non-associating:
Turn on switch or dimmer says: Psst… hey Hub. Something happened here. I can’t tell you what happened, I’m not allowed. But something happened and if you ask me, well, that isn’t against the rules. At which point the hub asks the switch: What state are you in? and the switch replies: I’m on! Yeah!
Turning off an “on/off switch” happens much the same way. But…
Turning off a dimmer switch (at least a GE or Evolve dimmer swtich) and this happens:
Psst… hey Hub. Something happened here. I can’t tell you what happened, I’m not allowed. But something happened and if you ask me, well, that isn’t against the rules. At which point the hub asks the switch: What state are you in?. Now here’s the problem. Because the dimmer goes from 99% (or whatever level it was at) down to zero over a period of a second or two, the dimmer switch is still technically on when the hub asks. Maybe it’s only at 30% headed towards zero, but still technically on. So when the hub asks the question, the dimmer switch says: I’m on! Yeah!
So, if your dimmer doesn’t act like the GE or Evolve (ie, dimming from 99% to zero when turned off) but instead just switches straight off, then it should be okay. Or, if it associates, then it’s also okay.
On a side note, where did you get these switches? I tried doing a search for Remotec and found a company selling remotes that work via Z-wave but didn’t see anything about switches or dimmers.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
24
Doh! Now I understand better… the problem is with the “Off” event detection, because of the delay in dimming from any “on-like” level (non-zero) to zero when the state query is sent out as you describe.
Well: I ran the same tests as yesterday, this time modifying “Notify Me When” to subscribe to “.off()” rather than “.on()”. I set one of my Remotec dimmer outlets to 100% to ensure the longest possible dim-to-zero/off time: Result: Still good – The method called from the .off event subscription is fired immediately when I press the on/off toggle (The method, in fact, is called long before the light has finally dimmed to zero).
I wonder how to find out? These outlets are from eBay (link below), so I suspect they are clearance / surplus stock of a discontinued product. There is actually a decent probability that this model was discontinued BECAUSE it violated the patent and was forced off the market! Again… wonder how to find out?
Two points of interest I’d like to point out regarding the behavior of these Remotec dimmer outlets (which may be common on others as well?):
The setLevel method actually takes two parameters, but I have not found the second [optional] parameter documented in SmartThings docs: setLevel( %, [x] ). For these dimmers, it turns out that "x" tells the switch how slowly to change to the specified level (i.e., how slowly to dim or brighten). IF x=0, the new level is set instantaneously. Larger values slow down the process. I think I discovered that x=10 resulted in a speed resembling the default.
So here’s a question / challenge: Is is possible that the default Level change delay can be pushed as a saved configuration parameter to the Device? In other words, for any dimmer switch with this speed of dim/brighten behavior, can the default slowness be changed to 0 (instant on / instant off)? If so, then this would likely solve your use-case, right?
If the speed cannot be saved into the physical Device… too bad, I guess… HOWEVER; when SmartThings adds “Device Parameters” to the ecosystem, I will request that “default dimming speed” be offered as a parameter for all dimming devices. This default level would then apply to all setLevel(%,[x]) commands that do not explicitly specify a value for x. Again: This will not be applicable when the switch is touched physically, as that depends on the physically internal default set speed (which, to repeat the previous paragraph, hopefully can be overridden somehow…).
Due to the smooth (i.e., slow) dim/brighten time of such dimmers, an unexpected risk exists. My dimmers define the Level to use for an "on" event to be the same as the Level was at the time of the last "off" event (i.e., the switches remember what Level you previously set them to before turning off). This is convenient, compared to switches that always start at 100% (my old X10 switches, ewww). This "defined Level" can be manually changed by dimming or brightening the switch physically, or through code or UI, before turning it "off".
What is the unexpected risk? If a SmartApp issues an “off” command too soon after the switch has been turned “on”, the dimmer may not have reached the expected saved brightness Level yet (as it slowly brightens to the saved Level…); and, at least in the case of my dimmers, this causes the switch to update the new default Level to that unfortunate half-assed Level. Actually, I think this behavior is intentional – by design: The same behavior is exhibited when pressing the physical toggle on/off button. This permits the User to change the new default Level of the light by tapping the button during the dimming/brightening process at the point of desired brightness (presuming the process is slow enough and the User fast enough for this to be useful).
They are listed with a good Buy-It-Now prices; but I encourage you to make-an-offer or otherwise negotiate if you are buying several.
PLEASE: If you or anyone reading purchases these based on my referral, please do me a favor and tell the seller that I sent you: Just mention this in your payment notes, giving my eBay ID: 9t9sales and email prefix: tgauch. I really appreciate that – I have not been offered a referral bonus, but perhaps the seller will offer me a free unit or something.
...(The method, in fact, is called long before the light has finally dimmed to zero).
So for this example, the possibilities remain:
(a) this Remotec dimmer switch outlet has licensed or is violating the patent.
(b) the patent does not apply (because it is not a wall switch?).
(c) the switch is only sending a “something happened” event (as permitted), and yet responds to the follow-up status query with “off” even though the dimming process has not yet reached zero.
I think the fact that you’re getting a response before the light is even fully dimmed means it’s sending the communication, not just the association command.
Beyond that… I agree that it’s really hard to know for sure on any of this.
Unfortunately I’m not looking for plug modules like this. I’m trying to do all my lighting with in-wall switches.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
26
Same dealer on those other plug-in modules, but thanks for pointing them out.
I have a lot of plug-in lighting (old house with rather few good “fixtures”, so plugs-in’s add flexibility). I’ve also put one of these into our low-voltage garden lighting main transformer box (technical is “outdoors”, but the transformer box enclosure is big enough for this dimmer controller).
I wonder what makes the “in-wall” versions so expensive, relatively (with dimming capability)? Different market (“installers”) vs. consumers? Cost of licensing the Lutron patent?
Could the solution be ZigBee HA protocol switches that can come up with a legally valid way to circumvent the patent? Should we build a prototype and run a Kickstarter Project?
Or, as I previously mentioned, if the device can be configured to always go “instant Level 0”, then the status query method will probably suffice.
Just looked at that item again CP. That’s a pretty nice module. There appears to be a switch on the back that can switch between dimmer or just on/off. Not bad for $24. I’m very tempted to get some.
Yes, love the idea of a manual switch on ST outlet module with LED showing ON/OFF status, and also module ON/OFF status reporting status back to hub. Wish this was capability of the default/base ST outlet modules.
The new super cool digital products always forget this simple rule, never take away capability/convenience. How frustrating is it to walk up to a lamp, and not be able to turn it on because you don’t have the remote or phone handy! Da.
The “August 13” in the upper right of the previous post was for August 2013, almost 4 years ago. So a lot has changed in that time.
At this point, pretty much all Z wave pocket sockets and most WiFi pocket sockets do have a manual button on the device. Some of the zigbee ones do and some don’t, you just have to look at the individual models.
Please let me know if those buttons are dual function somehow or something but I think their advertised function is to cause the module to join with the ST hub when the device is first configured??? I have not seen them advertised as manual outlet ON/OFF buttons??
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
32
The CentraLite sockets that SmartThings sells definitely have a local physical on/off button.
In fact, I’ve never seen or heard of a socket without one. Lightbulbs are the opposite… I don’t know of a single brand/model of a smart bulb with a physical switch built in.
If it’s an on/off switch and it’s in direct communication with the Hub (ie, not via the mesh) then it generally will work as expected. But if it’s a dimmer, it doesn’t show off correctly. Furthermore, it appear that if the device is communicating over the mesh network then it appears to often not report on or off directly whether a switch or a dimmer.
