SmartThings Community

Local Processing

#1

Does anyone have any experience when it comes to what should and shouldn’t work when switching Device Handlers?

The reason I ask is this:
I have a button configured to switch a garden floodlight (via a z-wave switch), but sometimes in the evenings there is lag as they are cloud based handlers, which means people end up pushing the button multiple times, so eventually when things catch up you get disco lights based on the number of pushes…

I have a number of PowerNode outlets which have some extra functions that I don’t really use…all I need is the ability to switch on/off and use the metering, so the Z-Wave Metering Switch handler works fine for that.
However, these devices flash like crazy if you use that handler, so using codersaur’s handler allows me to configure a timeout so this doesn’t happen.
Is there any reason I can’t use the custom handler to configure the settings i.e. timeout, then switch back to the stock handler to retain local processing?
It appears to work, but I’ve not left it long enough to see if I get any weird behaviour or if the timeout flashing reoccurs

I’ve also tried this with a Xiaomi button (Zigbee) and switched it to a standard Zigbee Button handler…but this does not appear to work…so I’m guessing there’s more to it than I’ve considered?

Does anyone have any thoughts/ideas?

Phil

(sidjohn1) #2

If you want to to know the difference between any 2 DTH you will have to go through the code as they change regularly.


As far as the flashing leds on your outlets, I’m sure this is configurable through a zwave parameter. The user manual or contacting the vendor should be able to expose the zwave parameter to disable the led and then you can use the zwave tweaker DTH to set it the parameter to disable the led and then change back the default Zwave DTH or you can just tape over the led till it stops bothering you.

Right now most of those super cheap Xiaomi devices don’t support enough Zigbee to work well with smartthings any other Zigbee hub other than their own. This is by design, but if you really like the buttons this tread will get you going.

(Bryan) #3

Is it really a lag, or is the event not firing with a single push? I found that I had that issue with an Aon WallMote. I solved the problem by firing the event via webCore with command optimization disabled. My theory is that ST does not always know the true state of what you are trying to trip and therefore does not always send the command.

I haven’t had a single hiccup since coding via webCore on several WallMotes. There is still a very small lag, but it’s less then a second and multple pushes are never needed.

#4

Under most circumstances its usually under a second, so not really an issue…but when its not <1 sec it tends to be nearer 10+…
A few times I’ve done it myself…assuming I fumbled the button push and pressed it only for the light to come on then go off again.

Realistically, I’m not sure how much time i’d save with local device handlers as the over all execution for the light is via a WC piston (as it’s a switch for a floodlight with either a button push or motion turn on/off)
Motion (during night time hours) or a button push turns the light on and keeps it on for a couple of mins, whereas a long button push is an override to turn on and keep on.
It works a treat, just the occasional lag on the button pushes…
(Piston import code if interested: 0ejfj)

#5

To go back to your original question, there’s no problem at all with using one DTH to configure the firmware in a Z wave device and then switching to a different DTH for every day operations. That’s because the configuration parameters are stored in the device’s own firmware. So this is exactly what people do when, for example, they use the Z wave tweaker to set the parameters.

I’m not sure about zigbee on the SmartThings platform, though. It depends on whether they force a new configuration when you change the DTH or not.

#6

Thanks all for the responses
I’ll have a play and if I notice any perceivable difference over time I’ll report back

From an architectural standpoint is execution time likely to vary based on the number of cloud based elements in the chain? input -> process -> output
Or is it just whether the process would work at all in the event of an internet outage

i.e. Button DTH (Cloud) -> WebCore (Cloud) -> Switch DTH (Cloud) ?Slowest - internet dependent?
versus
Button DTH (Local) -> WebCore (Cloud) -> Switch DTH (Local) ?Slow - Internet dependent?
versus
Button DTH (Local) -> SmartLighting (Local) -> Switch DTH (Local) ?Fastest - works with internet unavailable?

#7

You would think the cloud-based options would run slower, but they have been multiple reports that sometimes the DTHs running noticeably slower, maybe because the hub gets busy?

We don’t really have the tools to trace exactly what’s going on, so it’s hard to say.

But yes, I think most people are looking for local operations in order to have continuity of service during a cloud or Internet outage.

(sidjohn1) #8

This works for Zigbee devices too, I have a temp device handler to set how frequently power is reported by “smart power outlets”. The .1w resolution was way too much for my AV system, but 20w and every 4 hrs works very well.