I have tried this but the lag was way too long I fond the light would get turned on then back off before it was set to 100%.
I think there is a very long delay for the switch to tell the hub it was turned on.
however this was using default DHT from ST
This is how I get around that lag… But I have a bunch of motion sensors in my house.
Every time a motion sensor goes active my devices refresh.
1 Like
With non-“instant reporting” Switches, this can never be solved for the scenario where SmartThings watches for the physical switch to be turned on and then adjusts the Dim Level.
The Lutron patent is a curse.
If you only use non-physical / indirect triggers (eg, the App, SmartTiles, Minomote, a rule or SmartApp), then the lag should be, mostly sub-second.
Therefore, setting the level on a schedule is required.
If the lag is still too long, then goshdarnit, SmartThings out to add a “silent” setLevel command to all DTHs, so as to make it as close to one message as possible.
Interesting!!!
what exactly is the “Refresh” doing?
I agree with this and is exactly what I was hoping @desertblade could add to his DTH.
If it is even possible?
1 Like
It’s definitely possible… The DTH is generally more likely to be aware of its own state (i.e., “Am I on?”) and can run internal commands based on any available internal criteria.
The problem is that all your possible SmartApps only have “on(), off(), setLevel(level, duration)” options (and hardly any of them pass the duration argument.
Getting them to support an arbitrary new ad hoc added custom Command “silentSetLevel(level)” is impossible, because SmartThings has not provided any mechanism to expand on the definition of a Capability once it has been published!
So if the DTH was enhanced, it would have to assume that “setLevel()” must always be “silent” (i.e., it must immediately return the Switch to the preceding state (on or off). I think that’s reasonable, but it might confuse other people … I don’t know why setLevel() implies turning the light on anyway!! 
1 Like
When refresh is run on a device it’s just the same as tapping the refresh button in the app. The device status is updated. It is very rare that my physical press on my switches takes longer than a second. Usually it’s almost instant because if the refresh piston.
This allows my switches to still run local since I don’t have to use custom code to try and make it report faster.
I would expect that this would only help if the motion sensor went active just after the switch was turned on.
In my case motion would already be active.
However this dose give me an idea.
Thanks to both of you for input.
I thought so at first also, but there is a GE switch that is always refreshed immediately prior to pressing, and it is always very fast…
Let me know what you come up with.
@bamarayne
what I have found is the GE dimmer is very slow at refreshing on its own and clicking refresh dose help but I would need core do a refresh every second or so for this to work!
I’m not sure if this is the best way to do this.
however I did have an idea that should work, at least in my case…
Is there any way to get CoRe to change the dim rate parameters for a GE dimmer?
I am using this DHT https://community.smartthings.com/t/modify-ramp-rate-on-ge-jasco-dimmers/
I see a task in core named " updateSetting(…) " however I do not see how to specify what parameter I want to set?
You cannot predefine a level. The ge switches go to the level with the setlevel command. Looked high and low, tried many different approaches none of them worked.
With motion triggers you can define go to that level on trigger. Core does it as well as smart lighting.
I use smarrlighting for all my motion triggers.
Zwave or ge does not support this command. Before ST can support it it needs to be defined in the specs. I think some switches separate setlevel from on, but not GE.
What about the below? do you have any input on this?
Thank you![quote=“scpickle, post:51, topic:43761”]
however I did have an idea that should work, at least in my case…Is there any way to get CoRe to change the dim rate parameters for a GE dimmer?
[/quote]
It doesn’t matter if the hardware supports it; because SmartThings provides an abstraction layer before the hardware – i.e., the “Device Type Handler”.
The DTH can be coded to run “setLevel()” immediately followed by “off()” (if the switch was previously off). That’s the beauty of SmartThings; it is not limited to the base functionality of the physical device – it can enhance it.
No, as far as I know the settings can not be changed via a smartapp.
I know @Mike_Maxwell was working on a dth fit dimmers at one point, he will have much more insight.
I’m not understanding why you would have to have it refresh so often.
You could set up a moron sense that would detect moron right after it’s pressed, thus updating.
only because I did not want a 5 sec delay, I would prefer instant on.
Yes, I do need a moron sense. 
I think this is what I will need to do, “add another motion detector” and maybe a contact sensor on the door of the bathroom.
That’s just a lot of sensors for a stupid night light.
I built some led night lights for my stairs. I thought about putting them on the system but then I figured out the cost to leave then on all of the time… About $2.25 per year! So, they stay on all if the time.
Here’s the project… Maybe this will work for you.
I did code a DH to work that way. There is a brief flash from the light while it sets level and turn off. The GE switch takes a bit (maybe 50-100ms?) to process the command before it moves to the next.
I also spent a ton of time trying to intercept button presses and have it go to preset levels. While it works it was unreliable and funky. For example it would go to 100% (previous on state) then dim down to 10% about 2-3 seconds later once ST received, processed and sent the SetLevel to the switch. The switch also does not process multiple commands rapidly, the default for the DH is 2 seconds, and I have found anything under 500ms to be unreliable (commands get dropped).
Over the last 2-3 months we started to rely on motion to trigger lights. Using GE Switches and Iris Motion sensors with smartlighting the majority of the turnOn commands execute in 1-2 seconds (a step or two into the room)
1 Like
I wonder if that’s because they get send through the ZigBee or Z-Wave network through different paths.
As mentioned various place, these mesh protocols don’t guarantee sequence of delivery (or other consistency like expected time to deliver). Thus, putting in a 2 second delay in DTH significantly increases the probability of predictable determinant behavior, compared to only a 500ms delay.
1 Like
Thats a good call out. Never thought about the routing. Still believe the switch can’t process commands rapidly. In my tests 2 commands rapid fire worked most the time (90%), the 3+ commands just disappeared into the ether. Must have a small buffer.
The majority of the commands sent from the SH is, turn on light, wait 2 seconds, update status. In the majority of the cases the delay does not matter.
1 Like