webCoRE has a per piston setting to enable/disable command optimizations. webCoRE default is to perform command optimizations.
This can be seen in the webCoRE IDE when editing a piston:
- First you need to selection Options -> "Show Piston Settings" so that piston settings are visible in the piston display area:
If you select on "Settings" in the piston view:
- you will see:
and if you select the 'gear' icon you will see:
So what does this mean?
When your piston issues a command to a device (like turn on or off), webCoRE checks if the current attribute value matches the requested setting, and if it does, webCoRE does not issue the command to the device to minimize traffic on your device network (zwave, zigbee or cloud depending on the device).
- If you have logging turned on in the piston, the IDE piston logs will show if command optimization is being performed.
For the most part the default of performing command optimizations is a good thing.
- For example it can simplify logic in your piston to set states you want and not have to worry about overhead of 'sending the same command again'.
But sometimes it may not be what you want:
-
for example if you have an older device that does not accurately reflect state, this optimization may cause problems. In this case for the piston you could disable command optimizations, which will have webCoRE send the command regardless of current device state being reported.
-
another case is if you send a series of commands quickly, there could be lags in device state updates that might impact your automation goal. (In general it may not be a good idea to send a bunch of commands to a device in a short time, ymmv)
Here is what disabling command optimization looks like in the settings portion of a piston:
Here was a case in the webCoRE forum:
Another option shown in the screen shot above is command execution delay
If during a piston execution multiple device commands are issued, if this option is set webCoRE will delay commands to be at least that milliseconds apart for this piston. By default there is no command execution delay. Enabling this can help if you have slower/older devices, cloud devices that may require throttling, or a lot of devices on your network and you want to throttle traffic.
- the side effect of this is that you may create more of a popcorn effect for light changes.
Again logs enabled on the piston will show if command execution delay is being used:
then:
etc...
