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.
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.
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?
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.
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.
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.
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?
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.
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
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):
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.
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?
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)
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:
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:
Sorry, but I need this as a log file - the PDF can’t be processed using the tools I have. If you can provide it as a log file, but rename the filename to PDF? Alternatively, maybe you can put it somewhere like dropbox?
I don’t use the CC2531 so am not in a good position to advise on this other than what is written in the documentation. Maybe someone else can answer this.
On what is in the documentation, but it is not complete as it relies on people providing this information.