Cool, glad you kept trying and it’s now working!
1 Like
Yes and thank you for pointing me to a better DTH
1 Like
Sometimes when you change from cloud to local dth, the smart lighting app for your automation will remain running in cloud. Usually you just need to go into the rule and save it to get it switched.
1 Like
SmartPower Outlet seems to not report ‘kw power used’ and also reports current wattage at 10% of the expected value. Ok for me as I process the value with Home Assistant and I just multiply the value by 10. Anyone have any workarounds?
Yes! This is exactly the same problem I’m having. I had to change my device handler back to the original Zigbee Metering Plug as I need correct wattage values for my automations in ST. It doesn’t matter so much about the power used figure as I calculate that with grafana anyway. It’s just that this device handler is cloud executed.
As @Inge_Jones said, i’m also 99% sure that the Zigbee metering plug was locally executed. It lead me to purchase more of them after only buying one to see how it functioned.
2 Likes
Just for the record, I also tried the ‘Zigbee Switch Power’ and that works locally but has the same problem as the SmartPower Outlet and reports 10% of the value. I’m no programmer but it looks like the decimal point is in the wrong place.
This reminds me of the problem I had with the Salus SP600 and Hive Active Plug (both made by Computime) some time back. I gatecrashed a discussion on GitHub about a commit to fix the issue and, as the discussion involved @tpmanley and Steven Green, it meant it involved people who knew what they were talking about. To cut a long story short, although the device handler was making assumptions about the value of the divisor, it was actually the devices returning values that were ten times too low according to Zigbee specifications.
1 Like
@tech2urdoor, what do you see in the live logging for that device with the zigbee metering plug?
Have you tested the plug with a known load. Ie some old 100W bulb?
UPDATE: Never mind, I have found this:
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:
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).
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?