I have only had to reset one of these once. ( I have 6 of them total) . Yes they do drop off, but I just hit replace in the app, THEN tap the button 8-10 times really fast until the led flashes. It takes a couple minutes, but the app shows successfully replaced and logs them as active. I have them drop off Zigbee as often if more often than the Z-wave drops off. Zigbee I unplug the wart, put ST in inclusion and then hold in the button while I plug it back in, once light stops blinking it is included again. Back out of inclusion in the app and trigger it a few times to make sure.
The Daughter has had a friend staying with her the last couple months, so I have not been able to regularly maintain all the devices on her side of the house. Her guests just can not grasp the concept of automation and insist on playing with the light switches, unplugging the wall modules rather than just asking Alexa to turn it on, or using the control panels or minimotes.
I use the stock ST smartplug DTH for outlet and generic z-wave device for the repeater.
I just happened to look at my activity using this app. Itās updating like crazy. 16 entries per min. Goes back and forth from power to elapsed time. Anyway to turn this off?
Iām using 3 of these switches and pulling up the activity feed just shows constant updated between all three of them. I do not think I had this issue before updating them from the email Smartthings sent out.
That sounds about right. I donāt have IDE open to look, but is the official ST device made by centralite. Same wart with the exception of the added Z-wave which is a separate device anyways. I was actually using that DTH before the email, just to attempt local control. .
Iām thinking spikes or tazers.
Taping over the wall switches, taking the chains off ceiling fan, knobs off lamp was not a deterrent. Some people are just determined to be ignorant.
You get a new message every time the power reading changes OR every 10 min, whichever comes sooner. In your case if you are getting 10 min, that means the power reading hasnāt changed for the past 10 min.
The messages could be removed from the activity tab if you edit the source code to say ādisplayed: falseā instead of ādisplayed: trueā in a few places where sendEvent() is called.
I just merged a pull request from @kicko to fix energy accumulation and reduce the number of messages the plug will send. Please let me know if you see any issues or errors in your live logs.
Is this less chatty than the SmartThings SmartPower Outlet handler now? I think Iāll go back to this since it has the Energy Used field now. Looks like min report of 1sec but is it grouping reports and sending less frequent, or is it just 1 sec if changes happen?
There is no grouping or anything like that. All the messages get sent when they happen. They just wonāt show in the activity log.
Iām not sure I understand your question about the 1 sec frequency. I think I explained it 3 posts above - the plug sends new power message every time the power measurement changes or every 10 min if the measurement stays constant. If it looks to you like it sends every 1 second, that means the power measurement changes every second. We donāt have control over how often the plug sends us messages.
We do however have control over the energy and time elapsed messages and I was thinking how I can decrease their frequency. The thing is - if we donāt send them, the values wonāt update in the UI. We can send them once every minute or every 10 min I guess. Maybe I can make it a parameter that you can set up.
Ok, gotcha. The 1 sec I saw in the code, I guess thatās just the absolute minimum interval it will report? Like if the power changes a few times a second, only one report per second would actually come through?
Ah, you are talking about the powerConfig() method. That part of the code comes form the standard device handler and I havenāt touched it and I have no idea how it works.
def powerConfig() {
[
"zdo bind 0x${device.deviceNetworkId} 1 ${endpointId} 0x0B04 {${device.zigbeeId}} {}", "delay 200",
"zcl global send-me-a-report 0x0B04 0x050B 0x29 1 600 {05 00}", //The send-me-a-report is custom to the attribute type for CentraLite
"send 0x${device.deviceNetworkId} 1 ${endpointId}", "delay 500"
]
}
Find the 0x29 1 600 in thereā¦ 1 is the minimum report interval in seconds, 600 is the maximum, also seconds. Iāve changed mine to be 0x29 30 600 to make the device less chatty. Perhaps I should add a config parameterā¦
@blebson, you have a pull request with configurable parameters also took the liberty of making the min interval 30s by default - less strenuous
We will probably lose accuracy that way, because when we accumulate the energy we do it with the assumption that it was constant since the previous message.
I donāt know if the reported power is an average over the last reporting interval, or instantaneous power at that particular time, if the latter is the case, yes. But from experience (I modified my ST outlet to measure energy too) I can tell you that either way, weāre not very accurate either way: and itās all got to do with timing and the inherent event delays with ST. For those who need accuracy, they can go to 1s, but if you want to use this with CoRE, youāll trigger that piston every one secondā¦ lots of load on the system, better off with 30s reports. But to deny your statement: youāre right
EDIT: Oh, also, there are some parameters in there that override the 30s min interval if the power change was larger than X%. I can look it up and find which one, maybe we make that one configurable too?
Itās the {05 00} - I think that means 5% change
Some explanation, but the { } part doesnāt fit this device:
I added your merge but am on travel so canāt thoroughly test it. Let me know if you start seeing issues.
2 Likes
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
381
Okā¦ Hereās my questionā¦
If Iām using this dth hoa are these parameters going to affect the load sensing? Will miso piston fire when the power changes? Or will it be ten minutes later when the devices finally reports?
Large-changes are reported immediately
Small-changes are not reported more often than the minimum interval (which by default was 1s)
No-changes are reported every maximum interval (10min)
also took the liberty of making the min interval 30s by default - less strenuous
