I am noticing since I migrated the app to the new one, my GE Smart Motion Dimmers are not detecting motion. This is every light switch in my home (about 20). I see some of you have had some success getting the motion to detect, but do not see anything where anyone has pinpointed the steps they took to get there. Does this sound right, or am i missing something? I did call Smartthings and they told me that they “used to support this device, but they no longer do in the new app”. Hmmmm
I recommend going into the settings and toggling every setting to ensure you are tapping “save” to ensure the switches get programmed properly. If you are using the new SmartThings app I found that editing the device name in the IDE seems to get the motion to show up in the app.
As @nathancu says below, all of this assumes you are using my DTH…there is no native DTH for these devices.
These devices will detect motion on board with or without SmartThings if they’re setup correctly.
So first thing, whomever gave you that info gave you bad info. This device has always required a custom device handler to work properly in SmartThings. SmartThings has always allowed but not provided support for custom device handlers.
This has not changed with the new app. And because the application you use is only a window into the back end system that glues all of this together changing the app wouldnt change how the device behaves it would only change how youre able to automate it. What has changed so far is the user interface.
Make sure you are using Michael’s custom device handler for this and do what he said above to ensure its initialized correctly. Soon he or someone will be able to also add a user interface closer to classic.
I updated these DTHs to 1.0.9. Unless someone discovers a bug, this will probably be the final version of these DTHs in the Groovy version. I do NOT plan to transition them to the API service, instead, I am hoping/asking SmartThings to support these directly…including the programming interface to allow you to change settings with apps like WebCore.
If your DTHs are working fine. THERE IS NO REASON to upgrade. The ONLY change was to revert back to the Boolean (on/off) switches for certain settings instead of using a pull down. Previously, the new ST app did NOT support Booleans in the setting for devices; the latest version does!
IF YOU DO UPGRADE AN EXISTING DTH…you MUST go into every device and set the settings as you previously had them. THE SETTINGS WILL NOT CARRY OVER from 1.0.8. This is a minor inconvenience that could not be avoided.
As always, please take every opportunity to share your NEED for these DTHs in this thread; it is being looked at at SmartThings, and I will get more vocal as we see the IDE sunsetted. These devices are the key to great automation in my house and I may have to jump ship if they are not supported (Hubitat DOES support these with a version of my DTH someone converted).
Hello, I’m not seeing the type of interaction getting reported correctly in WebCore. It gets reported as physical interaction even when there’s only motion and I haven’t touched the switched.
What I’d like to do is to have the light switch turn on (to different brightness during different times of day) when motion is detected and turn-off after a while when motion stops. However, if the button is physically pressed then behave like a dumb switch i.e. don’t turn-off automatically.
Thus, in order to do this, I set the switch to always be in manual-mode and put all the logic to handle this in WebCore. I was trying to use the condition “switch physically changes” in WebCore to distinguish identify, well, physical interaction but that doesn’t seem to be behaving as expected and it reports even motion sensor activity as physical interactions.
Are there any plans to correctly report physical v/s programmatic interactions?
This is one of the limitations of the device. When the motion detector detects motion, it PHYSICALLY (on device) turns on the light (in Occupy mode). This is by design of the device and the DTH can not differentiate it between a physical (human) touch. I have tired
There are different ways to accomplish what you are attempting, however. For example, you could have a WebCore Piston that does an hourly check, and then sends the default dimmer level to a certain level depending on the time time of day. You could then leave the device in Occupy mode and then no one would need to touch it and it would come on in variable levels throughout the day. To accomplish the “don’t turn off part”, you could use a little math logic. For example, if your original WebCore Piston above does not ever reach 100 (maybe you have it max out at 98). If you physically hold and push the dimmer it will go to 100 (or actually 99). You could have a web code key off of the dimmer going to >98 and then send the Manual() command to prevent it from going off.
Just a thought, but you are out of luck distinguishing between a physical push and one that is done via the physical device.
Samsung depricated support for code v. Physical interaction a number of years ago (even though it still shows in WebCoRE)
The spec technically allowed for it but not enough manufacturers supported it well or at all for it to be useful so ST pulled it out of the supported spec.