Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support extra configuration on Legrand / BTCino with Netatmo devices #733

Open
pgaufillet opened this issue Jan 24, 2022 · 13 comments
Open

Comments

@pgaufillet
Copy link
Contributor

pgaufillet commented Jan 24, 2022

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:

  • enable/disable Led in Dark: zigbee write <node>/<endpoint> 0xfc01 1 [true|false] BOOLEAN
  • enable/disable Led if On: 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.

@cdjackson
Copy link
Contributor

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
Copy link
Contributor Author

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:
image

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

Hi,

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

@pgaufillet
Copy link
Contributor Author

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants