Closed zonak closed 10 years ago
mrose17
commented
10 years ago just to chime in - @zonak is doing the heavy lifting on the zwave support for @TheThingSystem and its turning out pretty well. my hope is that we'll have a dozen or so classes implemented by year's end!
but, we need a more generic call to avoid a proliferation of device-specific calls, e.g., meterThis(), meterTat(), windowShadesScrollLeft(), windowShadesUpAndDownUntilAnnoyed(), etc.
jperkin
commented
10 years ago Ok, try 0.0.29 with e.g. zwave.setValue(nodeid, 0x70, 90, true);
zonak
commented
10 years ago Hi Jonathan,
I was able to test with 0.0.29 and use setValue to turn a device on and off but going through the device data I stumbled upon a case like this:
<CommandClass id="39" name="COMMAND_CLASS_SWITCH_ALL" version="1" request_flags="4">
<Instance index="1" />
<Value type="list" genre="system" instance="1" index="0" label="Switch All" units="" read_only="false" write_only="false" verify_changes="true" poll_intensity="0" min="0" max="0" vindex="3" size="1">
<Item label="Disabled" value="0" />
<Item label="Off Enabled" value="1" />
<Item label="On Enabled" value="2" />
<Item label="On and Off Enabled" value="255" />
</Value>
</CommandClass>which is of a type list where we are not setting a value attribute but a vindex one.
This led me to look around a little bit more and saw these combinations of value types and attribute names:
For the most part, they all have value attributes with the exception of list which has a vindex attribute and button which I am not sure how to handle, I guess we can try and do some research.
zonak
commented
10 years ago I think we should reopen this issue just so we have something to go by ...
In addition to vindex not being supported for writing, the propagation of this field when reading out information from a device is not being handled as well.
For example, if we peek into zwcfg.xml for an example we can see the following:
<CommandClass id="39" name="COMMAND_CLASS_SWITCH_ALL" version="1" request_flags="4">
<Instance index="1" />
<Value type="list" genre="system" instance="1" index="0" label="Switch All" units="" read_only="false" write_only="false" verify_changes="true" poll_intensity="0" min="0" max="0" vindex="3" size="1">
<Item label="Disabled" value="0" />
<Item label="Off Enabled" value="1" />
<Item label="On Enabled" value="2" />
<Item label="On and Off Enabled" value="255" />
</Value>
</CommandClass>this is an example of a list type value with a vindex field, but when there is a value changed event fired, the information we are getting is:
{ type: 'list',
genre: 'system',
instance: 1,
index: 0,
label: 'Switch All',
units: '',
read_only: false,
write_only: false,
min: 0,
max: 0,
value: 0 }As we can see in the example we are getting a default value of 0 but what we really need to get is a value of 3 for vindex or maybe something like the label from the list.
Hope this information helps.
ekarak
commented
10 years ago We also need the _instance part (for multi-instance devices such as the double-relay Fibaro FGS-221) in values...
The current write support allows us to use binary and multilevel switches by utilizing
switchOn,switchOffandsetLevel. But these methods are tied to specific classes such as0x20and0x26.We have a lot of use cases where we need to write to other classes as well. A good simple example is configuration - a lot of the devices have configuration options that we cannot utilize without the write support for it. For example, the Aeotec Smart Energy Switch has the following configuration class (
0x70):where a lot of the values have writing enabled.
Configuration is just one example, but the support to writing to different classes would be very useful in a lot of other cases.
Is there a way to extend the write support by implementing a more generic solution. Something like a method that would accept the following parameters:
All the values even have attributes that can validate whether writing is allowed or what type of value is expected that can be used for a validation step. This can obviously be done as a second phase but the basic write support would add great value.
If we have something like this in place then methods like
switchOncan be modified as abstraction over the generic write support.