Differences

This shows you the differences between two versions of the page.

--- supported_modules:hs-wd100 [2018/09/07 13:07] – fixed codes James Sentman
+++ supported_modules:hs-wd100 [2023/02/13 14:52] (current) – external edit 127.0.0.1
@@ Line 65: / Line 65: @@
 ===Set Data===
-via the [[dictionary:unitcontrol:setdata|Set Data]] verb it is possible to set various parameters in the switch. Note that the parameters of the WD100 are different than the [[supported_modules:hs-wd200|WD200]]. This is a grid of the most useful parameters that can be set for the WD100+ note that this might change in future firmware versions or hardware revisions so you should verify against the latest version of the user manual that comes with your specific unit before issuing the command. It is entirely possible to brick a dimmer if you issue the wrong commands to the wrong addresses.
+via the [[dictionary:unitcontrol:setdata|Set Data]] verb it is possible to set various parameters in the switch. Note that the parameters of the WD100 are different than the [[supported_modules:hs-wd200|WD200]]. This is a grid of the most useful parameters that can be set for the WD100+ note that this might change in future firmware versions or hardware revisions so you should verify against the latest version of the user manual that comes with your specific unit before issuing the command. It is entirely possible to brick a dimmer if you issue the wrong commands to the wrong addresses. It’s nice to note however that the WD100 an WD200 share the same parameter number for orientation, and then the WD200 parameters start at 11 so if you confuse the 2 device types when setting data they happily ignore the out of range parameters and do not do anything damaging. if you confuse them with switches from other manufacturers then things could be unpredictable.
 ^Parameter^Description^value^Example^Default^
@@ Line 77: / Line 77: @@
-===Known Issues===
-As of XTension 9.4.6 the central scene events may be sent more than once. This is a known issue and as soon as I can figure out how to filter repeats of them I will do so. Until then your scripts may run more than once. This isn’t generally a problem as turning on or off a device that is already at the same level doesn’t cause any trouble except extra commands to the systems. If you wish you may be able to check the time delta of the unit and ignore a central scene event if it is less than say 2 seconds since it changed state. Or save off the current date in the central scene handler to a local script variable and compare that script variable with the current date when it’s called. If it’s less than 2 or 3 seconds since it last handled a central scene command then ignore it.