SmartThings smart plugs - suddenly cloud connected?

I changed the name and self published.

@djsat2, Iā€™ve tried it. And it letā€™s you save it. But it smells fishy. So I changed one of my ST motion sensorā€™s custom DH to run locally. When I changed it, it started to execute something else. The temperature values reverted back to integers instead of float what I prefer.

Iā€™ve tried with an IKEA motion sensor too. Changed to local, even I did a rule for it with Smart Lighting and that was local too. But I have doubts that this is by any chance not a mistake somewhere in the IDEā€™s code.

@Brad_ST, since when the IDE allows to save custom DHs with runLocally:true? As it is now actually allowing it.

Could you please advise? Is it a (nasty) bug?

What is happening here is that when it attempts to run locally it isnā€™t going to find the corresponding DTH to run and consequently it will fall back to default local handling. In most cases that is going to be essentially the same as what our standard DTHs do (with a few minor differences here and there). So while you can set that flag, it likely wonā€™t result in the behavior you want. And certainly making changes in the groovy DTH you are self publishing will have no affect on the locally executing device.

3 Likes

Thanks @Zach_Varberg! It sounds interesting, but what about those devices, like the above mentioned zigbee metering plug, what hasnā€™t got a local running DH, but there are another 2 similar DHs with local execution?
Will it fall back to ā€œdefaultā€ metering and local on/off execution? (What is the default for the metering values?)
Nice improvement but a bit misleading if you donā€™t know how it is working.

Yes, it will fall back to handling for those Zigbee messages (the simple metering and electrical measurement values) and convert those to device capability events. But in doing so, it will use a default ā€œdivisorā€ for converting those values from the raw value reported by the device, to the normal way people would discuss them. In the case of these devices that default will incorrectly be 10 (as that has been the most common value we have seen from devices). So even if you make the change in the cloud and mark it to run locally, you will likely continue to get incorrect values.

The ability to set the flag was originally done because people wouldnā€™t be allowed to save self published versions of our official DTHs because the flag was set and it would reject them, which was very confusing for users. Letting it be set allows people some limited (and now deprecated) control of display options while still getting local execution, but as youā€™ve stated produces some pretty confusing behavior if you arenā€™t an employee and canā€™t read the code directly. It probably should have been handled differently.

In terms of a ā€œfixā€ for this issue, I canā€™t really make any comments about that as Iā€™m an engineer and I donā€™t dictate prioritization or scheduling of work. But I have made people aware of the issue and the fact that it has been a negative experience for users.

2 Likes

Thanks again @Zach_Varberg. It is definitely confusing, but I understand the logic behind the change as the true flag with STā€™s DHs stopped the saving.
Might be a banner on the top of the edit page should do the job, to change that flag to false, if you want run your custom code, when you hit save. :slight_smile:

The disappointing thing in your sentence, that this device is the new ST Zigbee metering plug and not following the most common valueā€¦ (what the previous versions did) :man_facepalming:

:laughing:

Anyhow, thanks for the detailed answers! It is good to know these changes, before somebody runs on it and spends time and to debug some code. :+1:

1 Like

Yep, very disappointing :cry:
I knew these plugs were too good to be true. An energy metering zigbee smart plug here in Australia for $50 was unheard of. For comparison, the Hue smart plug was recently released here and sells for $70 with no energy metering but they might execute locally :wink: Well I guess these would as well if I could deal with an incorrect energy reading.

Hmmā€¦so runLocally is yet another value that isnā€™t of any use? I thought Local Execution meant that all logic needed to run without Internet was in the Smartthings hub, like some other Home automation controllers haveā€¦so that is not the case here then??

1 Like