Open pgaufillet opened 2 years ago
Attribute Dimmer mode cannot be changed because its data type (0x09 / DATA_16_BIT) is not supported in OpenHAB.
All ZCL data types are supported by the Z-Smart Systems libraries, so they all should be supported by the binding.
I am far from being an expert of this library so I am probably wrong :-)
This assumption is based on a simple search of DATA_16_BIT
in its repository:
You can see that in the method parseValue()
the corresponding case is commented out.
And zigbee write <node>/<endpoint> 0xfc01 0 0 DATA_16_BIT
in OpenHAB returns Error: Exception during command execution (IllegalArgumentException): Data type DATA_16_BIT is not supported.
You're right, there is no serialisation defined for this data type. I will add that to the library and it will be available in a few weeks or so, but if you want support for these device I suggest to please try and add it to OH if you can.
Thank you for your help Chris!
I'll try to implement a preliminary support for this non standard cluster 0xfc01 in the coming weeks.
Just to note that if this is implemented "properly" - ie the device implements the ZCL on this cluster and these are just standard attributes, then all that is needed is a static definition - ie an XML file needs to be added. You don't need to add code.
Unfortunately it's not documented very well but maybe the following recent thread on the forum helps -:
https://community.openhab.org/t/sinope-zigbee-thermostat-th1123zb/129479/20
If you wanted to produce a short "how to" section on this, it would be really appreciated. It's something I keep meaning to do but am very busy with other stuff (and I know just writing the doc would probably be quicker than repeating myself each time :) ).
I am facing a subtlety: the vendor name and model id contain special character \x1f:
legrand_dimmer_without_neutral,vendor=\x1f Legrand,modelId=\x1f Dimmer switch w/o neutral
Is it supported in discovery.txt?
I'm not sure to be honest - I would suggest to try. If required we can change the format of this file - either just changing the way it is read back - eg using a different character set might (??) resolve this, or alternatively we'd have to add a processing stage to filter this out when the file is parsed.
Echoing \x1f into discovery.txt just works. But it is not good in terms of maintainability, as this character is invisible: future maintainers might forget about it, remove it unwillingly and silently break the discovery.
What about using Apache commons text Java escape/unescape methods (described here) to explicitly handle it?
I'd prefer not to add this dependency just to remove (well, handle) this character. There must be a simple way with (eg) a regex that allows unprintable characters to be translated to a space, or underscore, or just removed. I'm sure I've done this sort of thing before, but I'm not sure if it will work for characters that are "below" 32 in the ASCII table?
Ok.
Can you please have a look to this XML thing file?
<?xml version="1.0" encoding="UTF-8"?>
<thing:thing-descriptions bindingId="zigbee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:thing="https://openhab.org/schemas/thing-description/v1.0.0"
xsi:schemaLocation="https://openhab.org/schemas/thing-description/v1.0.0 https://openhab.org/schemas/thing-description-1.0.0.xsd">
<thing-type id="legrand_dimmer_without_neutral" listed="false">
<label>Legrand with Netatmo Dimmer</label>
<description>Legrand with Netatmo Dimmer without neutral</description>
<channels>
<channel id="switch_onoff" typeId="switch_onoff">
<properties>
<property name="zigbee_endpoint">1</property>
</properties>
</channel>
<channel id="switch_level" typeId="switch_level">
<label>Level Control</label>
<description></description>
<properties>
<property name="zigbee_endpoint">1</property>
</properties>
</channel>
</channels>
<config-description>
<parameter name="zigbee_macaddress" type="text" readOnly="true" required="true">
<label>MAC Address</label>
</parameter>
<parameter name="attribute_01_in_fc01_0001_10" type="boolean">
<label>Led in Dark</label>
<options>
<option value="false">Disabled</option>
<option value="true">Enabled</option>
</options>
<default>false</default>
</parameter>
<parameter name="attribute_01_in_fc01_0002_10" type="boolean">
<label>Led if On</label>
<options>
<option value="false">Disabled</option>
<option value="true">Enabled</option>
</options>
<default>false</default>
</parameter>
</config-description>
</thing-type>
</thing:thing-descriptions>
The first test results look good. Of course, it should be generalized a bit as it should also work for plugs, etc. And a binary input channel is missing.
Hi,
I see com.zsmartsystems.zigbee 1.4.4 is released. It would be great to move to it now.
Hi,
I have just tested with com.zsmartsystems.zigbee 1.4.5 the DATA_16_BIT argument, and it can be read:
openhab> zigbee read 38022/1 0xfc01 0 Reading endpoint 9486/1, cluster server cluster (FC01), attributes Attribute 0 Response for cluster 0xfc01 Attribute 0 UNKNOWN DATA_16_BIT 257
but it cannot be written:
openhab> zigbee write 38022/1 0xfc01 0 0/0x0101 DATA_16_BIT Error: Exception during command execution (IllegalArgumentException): Data type DATA_16_BIT is not supported.
Am I missing something?
It looks like support will need to be added to the low level library for this.
The devices of this manufacturer offer optional behaviors (LED, dimmer). It should be possible to configure them.
As of OpenHAB 3.2, the following commands works in OpenHAB console:
zigbee write <node>/<endpoint> 0xfc01 1 [true|false] BOOLEAN
zigbee write <node>/<endpoint> 0xfc01 2 [true|false] BOOLEAN
Attribute Dimmer mode cannot be changed because its data type (0x09 / DATA_16_BIT) is not supported in OpenHAB.
More information at Domoticz-Zigate-Wiki.