Zigbee binding

chris · September 4, 2018, 5:10pm

Probably it needs to be decrypted - please take a look at the guide that I produced. It explains how to set the keys and if you don’t do this, you don’t see much.

Domi · September 4, 2018, 7:14pm

Did that already, still shown as IEEE 802.15.4. I can see the MAC/Network addresses from the lights and I see them communicating with the controller but no ZigBee details.

Only on controller startup I see a few ZigBee packages. Gonna try again on a different machine to see if I get different results.

chris · September 5, 2018, 9:39pm

Looking at the latest log you sent, it shows the initialisation of the lumi.sensor_magnet.aq2 and it doesn’t report that it supports the power configuration cluster which is where the battery status is reported -:

You can see above that it only supports servers for BASIC, IDENTITY and ON_OFF, and a private cluster 65535 that I guess is Xiaomi specific functionality.

nibi79 · September 7, 2018, 6:01am

Thank you for your investigation and your explanation!

Yesterday I get some other Xiaomi Aqara devices:

For me it seems that they all send the a private cluster with Xiaomi specific data/functionality (I sent the log to you). For example the water sensor has only 2 channels Battery and voltage…

Am I right because Xiaomi send specific data/functionality they are not 100% compatible with the binding?

chris · September 7, 2018, 6:35am

Yes, clearly if a device doesn’t stick to the standards, then it can’t be compatible. As a minimum, there would need to be some documentation to allow the devices to be implemented, however at the moment, the binding is only implementing the ZigBee standards.

chris · September 7, 2018, 6:54am

Are you able to get a sniffer log of what is happening? If not, I’m not really sure how I can help you.

nibi79 · September 7, 2018, 7:27am

Ok!
You already mentioned this in this discussion:

Unfortunately, that’s a reason to give zigbee2mqtt a chance… although I would rather use the binding directly.

chris · September 7, 2018, 7:45am

Yes, unfortunately there’s no magic. If a device doesn’t stick to standards, then it can’t magically be supported .

Kergilo · September 7, 2018, 11:02am

Hello,
I have spent many days trying to set up a Zigbee network but I can’t include any device. I looked for any solution in the forum but I didn’t find any so I ask here for help.

I’m using the CC2531 dongle with the firmware CC2531ZNP-Pro-Secure_Standard.hex, like it says in the documentation.
I have tried with Openhab 2.3 - Zigbee addon 2.3 and with Openhab 2.4 - Zigbee addon 2.4
I have configure the dongle in PaperUI setting the COM port and baudrate=57600. It shows that it’s online.

image.png820×771 29.7 KB

When I look for Zigbee devices through PaperUI or HABmin and press the network buttom on the device it doesn’t appear in Openhab. Here is the log:

Thank you.

chris · September 7, 2018, 11:25am

I’m afraid it’s not easy to comment without seeing a log of whats happening, and also knowing what device you are trying to get to join the network. If you can provide a log then I’ll have a look to see what I can see.

Kergilo · September 7, 2018, 11:37am

Sorry. Maybe you are referring to that?

I’m trying to discover a wireless magnetic switch to doors/windows. I have also tried with a temperature/humidity sensor but it doesn’t either works.

chris · September 7, 2018, 12:06pm

I’d like to see the actual log. These very short snapshots as images are really difficult to understand. However, from this I can see that he permit join is sent, but no devices are apparently joining, so the binding isn’t really able to do anything.

What is the actual device - can you provide the model, or a link to the manufacturers website or something?

puzzle-star · September 7, 2018, 3:43pm

Hi @chris,

I opened an issue in github (Support non-standard / devices with wrong ZigBee implementation #247) a few days ago, related to this.

I have these Xiaomi non-standard devices working with some patching I would like to merge into the binding (not ready yet for a PR), if you would support this.

Nothing specific for Xiaomi on the code, just changes for this:

Support overriding the reported set of clusters in the static thing definition xml
Updating the ZigbeeNode from the binding to add the customized set of clusters
Suport regex in the discovery properties file (just to i.e. allow several models to fit into the same device description)

This would allow the binding to support some non-standard devices in general provided a static thing definition is given

As an enhancement. I am also trying to skip discovery / rediscovery for devices with such static descriptions.

Would you be OK with these changes?

Best Regards,
Pedro

chris · September 7, 2018, 4:28pm

Yes, but there’s still no magic. Unless someone documents the unknown clusters, they still can’t magically appear. (presumably you have worked this out though ).

I’m certainly happy to look at it - depending on how it’s implemented. I guess it’s an extension to the static thing definitions? I have some ideas on how I think it could be done in a “non-invasive” way. Clearly this is nice to have, but it needs to fit properly in the binding…

I think if there’s a static description, it skips the discovery anyway doesn’t it? Again though - I’m very happy to look at suggestions for improving things and I know some of this discovery code is far from perfect

Sure - create a PR and let’s discuss further.

puzzle-star · September 8, 2018, 8:44am

Well, I have the definition for one Xiaomi device, but more could be provided. Would it make sense to allow these definitions (discovery.txt and xml files) to be provided out of the jar file? Updating the jar is easy, but not for people just installing the binding and expecting to use it as-is.

My idea (what I have done, indeed), is allowing for this in the xml in the static definition file (note the zigbee_input_clusters property):

                    <channel id="temperature" typeId="measurement_temperature">
                            <properties>
                                    <property name="zigbee_endpoint">1</property>
                                    <property name="zigbee_input_clusters">1026</property>
                            </properties>
                    </channel>

And adding some code in ZigBeeThingHandler.doNodeInitialization to handle this:

        // We already have the correct thing type so just use the channels
        nodeChannels = getThing().getChannels();
        logger.debug("{}: Using static definition with existing {} channels", nodeIeeeAddress, nodeChannels.size());

        // Add statically defined clusters <-- This is the newly added code
        for (Channel channel : nodeChannels) {
            // Process the channel properties
            // ...
        }

I have some strange behaviour with the node initialization, which seems not to be excactly due do these changes, as they also happen with the the SNAPSHOT version without modification: the device created with a static definition gets the name “zigbee::xxxxx” instead of “zigbee:typeUID:xxxxx” (I have fixed it also, but not sure it is the expected behaviour). But also these devices keep on appearing in the inbox as standard devices till a rediscovery determines they are indeed the statically create one.

This is why I think it is not ready for PR (till I check the above), but you can check in the diff on my forked branch if the changes are “as you would like them” so that I can fix them even before PR.

Of course, if you prefer I can PR and follow the dicussion there. Just I am not too much used to GitHub and I prefer not to mess too much with the commits and PRs there

Also, once everything looks fine I will move all propery strings to ZigBeeBindingConstants

Not in my case. Rediscovery seems to be happening. Checking why.

Pedro

chris · September 8, 2018, 8:52am

Yes - I would expect that we end up with an extension to the current static definitions to include this. If we’re going to add this, then it’s not a good idea to have people messing with the JAR.

Ok, maybe I misunderstood the issue with Xiaomi. I thought from the above discussion that they were sending information such as battery and temperature using their private cluster. If this is the case, then what you propose doesn’t work I think… So, from your proposal, it seems that the Xiaomi are using standard clusters (at least for most things?), but simply aren’t listing all clusters in the simple descriptor? Is that correct?

I will take a look at this.

I’m happy to discuss here - whatever is easiest

puzzle-star · September 8, 2018, 9:01am

Correct, at least for the round lumi.sensor_ht.

It looks like when a device is created with an empty type it never gets “corrected” in the name even if after the type is provided. In one of the commits in my brach you can see that fixing it is quite straight-forward (if this is the expected behaviour, of course)

chris · September 8, 2018, 9:03am

Ok, thanks for the clarification. This indeed makes things much easier .

puzzle-star · September 9, 2018, 7:07pm

Hi @chris,

I have been playing further with the static definitions, and I think there is a slightly better approach than the one I was taking.

Do we really need a new type of device for each new device we want to define statically?

So I think it may be better to just provide some configuration parameters to allow overriding the discovery in a standard “zigbee:device” in the ZigBeeThingHandler class. Please have look at the two things below, defined in a “.things” file:

Thing zigbee:device:523a066c:00158d000163e591 "Xiaomi Two Button Switch" (zigbee:coordinator_telegesis:523a066c) [ zigbee_macaddress="00158D000163E591", zigbee_nodedescriptor="logicalType=END_DEVICE;frequencyBands=FREQ_2400_MHZ;macCapabilities=REDUCED_FUNCTION_DEVICE;manufacturerCode=4151", zigbee_endpoints="1:6;2:6;3:6" ]
Thing zigbee:device:523a066c:00158d0002379093 "Bedroom Temperature Sensor" (zigbee:coordinator_telegesis:523a066c) [ zigbee_macaddress="00158D0002379093", zigbee_nodedescriptor="logicalType=END_DEVICE;frequencyBands=FREQ_2400_MHZ;macCapabilities=REDUCED_FUNCTION_DEVICE;manufacturerCode=4151", zigbee_endpoints="1:1026,1029" ]

BTW, the configuration above is working for me, of course with the corresponding changes to ZigBeeThingHandler . I am using the “.things” files as they are faster to change / update while testing, but it should also work with the UI.

It is still “ugly”, as I would like to add the possibility to create a file with definitions to avoid duplicating these, i.e. something like:

aqara.twobuttonswitch zigbee_nodedescriptor="logicalType=END_DEVICE;frequencyBands=FREQ_2400_MHZ;macCapabilities=REDUCED_FUNCTION_DEVICE;manufacturerCode=4151", zigbee_endpoints="1:6;2:6;3:6"
lumi.sensor_ht zigbee_nodedescriptor="logicalType=END_DEVICE;frequencyBands=FREQ_2400_MHZ;macCapabilities=REDUCED_FUNCTION_DEVICE;manufacturerCode=4151", zigbee_endpoints="1:6;2:6;3:6"

And then define the things like:

Thing zigbee:device:523a066c:00158d000163e591 "Xiaomi Two Button Switch" (zigbee:coordinator_telegesis:523a066c) [ zigbee_macaddress="00158D000163E591", zigbee_descriptor="aqara.twobuttonswitch" ]
Thing zigbee:device:523a066c:00158d0002379093 "Bedroom Temperature Sensor" (zigbee:coordinator_telegesis:523a066c) [ zigbee_macaddress="00158D0002379093", zigbee_descriptor="lumi.sensor_ht" ]

Would it make more sense?

If so, which would be the right way to place such a configuration file out of the jar?

Kergilo · September 10, 2018, 8:30am

openhab log.pdf (720.7 KB)

This is my “openhab.log”. I couldn’t upload the .log file so but I uploaded the pdf.

My devices are these:

Feibit ZigBee Temperature and Humidity Sensor (https://mysmahome.com/product/5830/product-introduction-feibit-zigbee-temperature-and-humidity-sensor/)
Feibit Zigbee door/window sensor (Smart Door And Window Opening Sensor Zigbee Smart Home Use - Buy Window Sensor,Electromagnetic Door Opener,Door And Window Sensor Product on Alibaba.com)

I would like to ask you a few more questions:

I have CC2531ZNP-Pro-Secure_Standard version 2.6. It isn’t a problem isn’t it?
CC2531ZNP-Pro-Secure_Standard is for HA 1.2 Zigbee protocol right?
If I use CC2531ZNP-Pro-Secure_Standard I need to set the dongle baud rate in PaperUI to 57600 right?
Is there a list of devices that fully work with openhab? I would like to buy one of these to test if the problem is the dongle or my devices

Thank you again and sorry for reply too much. I’m new in this