Support extra configuration on Legrand / BTCino with Netatmo devices

[pgaufillet]

Support extra configuration on Legrand / BTCino with Netatmo devices

[cdjackson]

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.

[pgaufillet]

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.

[cdjackson]

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.

[pgaufillet]

Thank you for your help Chris!

I'll try to implement a preliminary support for this non standard cluster 0xfc01 in the coming weeks.

[cdjackson]

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 :) ).

[pgaufillet]

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?

[cdjackson]

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.

[pgaufillet]

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?

[cdjackson]

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?

[pgaufillet]

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.

[pgaufillet]

Hi,

I see com.zsmartsystems.zigbee 1.4.4 is released. It would be great to move to it now.

[pgaufillet]

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?

[cdjackson]

It looks like support will need to be added to the low level library for this.