Continuing the discussion from [ALPHA VERSION] CoRE (Community's own Rules Engine):
Background: certain DTH erroneously report device/physical action when certain automatic events occur, such as polling the device, which has nothing to do with physical actuation.
http://docs.smartthings.com/en/latest/ref-docs/event-ref.html#isphysical
I know you previously reported that one of the stock device handlers started doing this about 6 weeks ago.
Could you tell us exactly which one? That would make it easier for @slagle to research since it’s not custom code.
I have seen this happen with my ST motion sensor but I am using Pollster which I believe is a bit of a no no.
If Tim or Jodi have time to merge the posts from other threads as indicated, we should have all of the details.
Here is a recent post that I hope will be moved here (the device is stock zwave switch)
https://community.smartthings.com/t/alpha-version-core-communitys-own-rules-engine/48189/223?u=sbdobrescu&source_topic_id=49799This is about misreporting a physical action, such as flipping the switch manually, instead of automatically. I don’t think it applies to motion sensors.
Oh sorry guess I understood. Yesterday, I noticed that when one of the ST motion sensor was polled via Pollster it would create a motion action thus turning on the lights. FYI, this was when no one was at home.
For me, one of the most important things about this is that it’s a change. DTHs that did not do this in January 2016 are doing it now. Including official DTHs.
You can see this in the discussions about the double tap code. Stuff that was working, stopped working.
There have been quite a few platform changes during this time period, including some Z wave firmware changes to the hub. And of course it could be that the DTH code itself was changed.
But regardless of the exact point of change, The fact that there was a change seems significant. This isn’t an artifact of the Z wave protocol or something to do with a particular device. The way in which zwave polling reports are handled by the smartthings platform has apparently changed, and that is breaking some existing code, including some official DTHs.
Several reports in the forums of people trying to open a support ticket on this and support just not understanding what the issue is. that’s why I think it’s important to emphasize that this is happening with official device handlers as well and that it is a change in platform behavior, so it can get past the first line of support responses.
Someone may be seeing a failure in custom code, but the failure is because of a change in platform behavior in how an official DTH reports an event.
I’ve been in contact with Jason from support and it was determined that the GE 12727 (non-dimmer) and 12729 (dimmer) have different methods of reporting digital vs physical interaction with a switch. Currently the DTH source as reported in the IDE is as follows:
12727
Digital - DEVICE /digital
Physical - DEVICE /physical
12729
Digital - DEVICE
Physical - APP_Command, DEVICE
A feature request has been put in to see if it is possible to change the GE 12729 to report similar to the GE 12727. Below is my example in which Jason was able to replicate.
12727 (non-dimmer)
12729 (dimmer)
I just tested my switches and it looks like the 12727 (non-dimmer) has the physical/digital option where as the 12729 (dimmer) does not. Not sure why the DTH would be so different.
12727 (Non-dimmer)
12729 (Dimmer)
Does CoRE work fine with the physical switch? Talking about the Interaction field, is it working fine? I don’t have any device that can report physical events, so I can’t really test that (I can only assume it does). Thank you
Looks like CoRE is working fine for physical interaction. I did a simple test in which I physically turned on a switch to have another switch come on and it worked.
It’s the DTH of the various devices that may have the issue identifying physical vs digital. I’ll put in a ST support ticket to see where there goes.
When writing a Z-Wave DTH, how can you determine if the event sent from the device is physical?
That’s not what I asked…I’m trying to find out how the device tells the DTH that it’s physical so that that the DTH can include it in the event it creates.
Does the zwave.parse method automatically add it to the command map it generates?
Ah,
The platform knows where he command comes from. If we send it, it’s not physical. If we don’t, it is physical.
Thanks for the response, but are you sure about that?
The documentation, that you just posted a link to, says isPhysical is “true if the Event is from the physical actuation of a Device”.
A device reporting its battery level is not a “physical actuation of a device”, but the platform didn’t send it.
Sorry for being difficult, but some DTH seem to report it the way you would expect and others don’t so I’m trying to understand how it’s supposed to work.
And some apps take the documentation as the absolute truth and get mixed results. Double Duty anyone? What a great idea, too bad there isn’t consistency among DTH…and the more recent event, ST’s own Smart Lighting…
@krlaframboise this proves your point
UPDATE: just tried the stock zwave switch DTH and is still not fixed. It is throwing physical without anyone touching it…
is it throwing that just randomly or when the switch is programatically turned on?
