SmartThings smart plugs - suddenly cloud connected?

The DH for this device is quite new, just a few month old. It does read the power (W) value straight (1) and energy (kWh) value with 100 divider.

It might be that being Zigbee 3.0, but no sign of any comments regarding local processing.

@steven.green, @tpmanley as this is the official DH for the new metering plugs is there any plans to make this device local in the near future?

1 Like

Are we talking about the Salus plugs that get paired to zigbee-switch power? In theory I added in some code to the DTH that hooks into our local execution to allow it to use a multiplier/divisor set by the DTH. Default is multiplier of 1, divisor of 10. There’s code in the handler to set the divisor for Salus devices to 1 (https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/master/devicetypes/smartthings/zigbee-switch-power.src/zigbee-switch-power.groovy#L126). Understandably this isn’t exactly the right response (which would be querying the device for the value and setting it that way).

If that divisor or multiplier is wrong and you want me to change it let me know.

Thank you for that link. It seems like the same problem. It looks like he found a solution making a custom handler. I’ll try that. It’s just so disappointing that I have to go through all that they can’t even get their branded products to run locally out of the box with their default handlers. If it didn’t have ‘smartthings’ written on the box I wouldn’t be so upset.

The thread was discussing ST Smart Plugs and mention had been made of two DTHs reporting power values ten times too low. Whether this was with that plug isn’t clear to me.

I mentioned Salus (and Hive) as an example of plugs I’d seen reporting ten times too low in the now relatively distant past, as back then I’d made the mistake of thinking it was the Zigbee Switch Power DTH not handling them correctly, whereas actually the DTH was reporting correctly and the plugs were just plain getting it wrong.

I was really just trying to suggest that it might be another case of the plug not implementing the standards correctly, rather than the DTH being at fault per se. I suspect I probably confused the issue though …

1 Like

@steven.green, please excuse me, I should have been more clear with the previous post.

The topic was about the latest SmartThings zigbee plug (GP-WOU019BBDWG) with power metering. It uses by default this DH:

https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/master/devicetypes/smartthings/zigbee-metering-plug.src/zigbee-metering-plug.groovy

But this DH being quite new, hasn’t made it yet to local execution. All the other official DHs with local execution reports the power value as 10th of the value from the zigbee-metering-plug. Which is all good as it is, as those DHs were not made for these new plugs.
But the plug being a SmartThings product, people would assume that it would run locally.
So the options at the moment are to use the DH with correct metering value, but it is cloud executed, or use one of the DHs which has local execution, but it reports the 10th of the real value.
The question was really about that the new SmartThings Zigbee metering plug’s DH (zigbee-metering-plug) is planned to make to the local execution list or if anyone wants to run things locally then they need to accept the 10th of the value with the other DHs.

Otherwise it is quite interesting to see how the Zigbee standard is misinterpreted by different manufacturers for power metering.

Thanks for the help!

1 Like

@tech2urdoor, custom code cannot run locally (yet). You are at the same position with a custom handler as by the zigbee-metering-plug (for now).

@steven.green If you could shed any light on this, that would be very much appreciated :pray:

I took the code from the Github link and created a customer DH in the IDE adding the "executeCommandsLocally: true, runLocally: true " to the definition part. Saved, published and changed one of my 2019 ST sockets to use the new handler. Left it 10 mins it’s now listed as executing locally. I’m at work right now so doing all this remotely but the socket is connected to a lamp so turned it on using the ST app and got the expected readings for power consumption etc so i think it might be working as desired.

I thought I had read that any custom DTH you publish to yourself always runs in the cloud because it isn’t downloaded to to hub? Are you sure it’s not just saying that because you told it to, if you see what I mean?

TBH you could be right i dont know enough about the inner workings, it deffo says local execution in the IDE though. Maybe when I get home tonight i pull out the modem and see what happens haha!

1 Like

Usually if you leave the runLocally: true then you cannot save the DH.
Have you changed the name of your changed custom DH? Or just kept as it was? Have you chose the Self published?

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