cause Zigbee2Mqtt firmware is made to send MQTT messages through the Zigbee2Mqtt script, so I guess it would be far easier to add a “wrapper plugin” to quickly add/manage zigbee elements over MQTT than to rewrite the full Zigbee2Mqtt script as a plugin.
Am I wrong ?
to be more precise, from what it have read, the CC2531 can be flashed with ONE of the official firmwares provided by Texas Instruments (there are 3 of them).
Each firmware implements its own security layer :
CC2531ZNP-Pro-Secure_Standard.hex
CC2531ZNP-Pro-Secure_LinkKeyJoin.hex
etc.
Depending on the firmware you flashed, you will be able to adress Zigbee sensors implementing the same security layer… and unfortunately all Zigbee sensors do not share the same security layer.
So you mean it has custom firmware that sends MQTT directly? Ok, but why not just use a standard firmware and then use the ZigBee binding - this seems to be a lot more useful?
I don’t really know what you mean by this? All ZigBee devices use the same security - there are different link keys - maybe that’s what you mean and this is the difference between these versions as far as I know. Most (all) ZigBee HA devices use the standard ZBA09 key at the moment (ZB3 will change that). I’m not sure if the TI firmware has the ability to change the keys via the serial port - other dongles do, and this makes them much more usable (and is really required for ZB3 as well).
As I said, I’m not particularly familiar with the TI dongles, but for sure it possible to use them with the ZigBee binding, and I have personally tested this. If you use custom firmware, then of course it may not work - my suggestion is to just use standard firmware, and if there is an issue with that, then why not try and resolve it?
mhh… interesting…
I was convinced a standard Zigbee key could NOT pair to all kind of Zigbee devices, but only a subset of them (or with the use of a proprietary bridge).
The click event is just send when the button is pressed. All the devices publish their battery, voltage and since some time also the linkquality to the coordinator. These messages do not contain the specialized events.
That is imho not correct. As far as i understood the architecture, the communication with the devices is done via zigbee-shepherd, zigbee2mqtt is a wrapper for that using mqtt.
With the communication module not aware of mqtt, i doubt the firmware is.
ZS currently has tested with Philips Hue, GE light, Netvox sensors/plugs/lights, ASUS sensors, and some other devices from our customer. We’ve tried Xiaomi’s device as well, unfortunately it doesn’t work with ZS for its proprietary encoding. We not yet give it a try with Smart Things devices (and we will).
Xiaomi devices send predetermined attribute reports to coordinator endpoint 1 with profile id 0x0104 (Zigbee Home Automation profile). Zigbee-shepherd at the moment registers the 0x0104 profile to endpoint 2. So to get Xiaomi attribute reports working we need to swap the profile id-s of endpoints 1 and 2 in zigbee-shepherd. That can be done in lib/initializers/init_controller.js
I think this statement is wrong, or you misinterpreted it. Xiaomi devices do work on standard ZigBee networks, but they may not comply with all the rules, and therefore can be problematic. For sure though, they do join a normal ZigBee network and I have tested this with the ZigBee binding.
As far as I can see, that is no “custom firmware”, they’ve just compiled the Z-Stack source for you as described here so that there is no need to download and install the z-stack home package.
I try to get the Xiaomi sensors (WSDCGQ01LM) to work with a cc2531 dongle and the TI stock firmware (CC2531ZNP-Pro-Secure_LinkKeyJoin). They work well with zigbee2mqtt.
When using the Zigbee Binding, the devices get detected and added but without any channels. I also connected Osram Bulbs which work fine.
I would be happy to fix this, but I have no idea where to look at for this. If somebody could hint me to a direction I would check that out.
For anybody else playing around with osram bulbs and zigbee2mqtt, maybe this piece of code to convert from hsv to xyz colorspace is useful:
/**
* hsv2xyz.js Convert OpenHab HSV to xy for Hue/Lightify
* 8/2018 C.Schmidhuber
* @param str string "h,s,v"
* @return json-string
*/
(function(str){
var gamma = function (c)
{
return (c > 0.04045) ? Math.pow((c + 0.055) / (1.0 + 0.055), 2.4) : (c / 12.92);
};
// hsv/hsb to rgb
// h,s,v = [0..1]
var hsvToRgb = function(h, s, v)
{
// @see https://gist.github.com/mjackson/5311256
var r, g, b;
var i = Math.floor(h * 6);
var f = h * 6 - i;
var p = v * (1 - s);
var q = v * (1 - f * s);
var t = v * (1 - (1 - f) * s);
switch (i % 6) {
case 0: r = v, g = t, b = p; break;
case 1: r = q, g = v, b = p; break;
case 2: r = p, g = v, b = t; break;
case 3: r = p, g = q, b = v; break;
case 4: r = t, g = p, b = v; break;
case 5: r = v, g = p, b = q; break;
}
return [ r , g , b ];
};
x = str.split(",");
x = hsvToRgb(x[0]/360, x[1]/100, x[2]/100);
red = x[0];
green =x[1];
blue = x[2];
// gamma
red = gamma(red);
green = gamma(green);
blue = gamma(blue);
// @see https://github.com/mikz/PhilipsHueSDKiOS/blob/master/ApplicationDesignNotes/RGB%20to%20xy%20Color%20conversion.md
// rgb to XYZ
var X = red * 0.649926 + green * 0.103455 + blue * 0.197109;
var Y = red * 0.234327 + green * 0.743075 + blue * 0.022598;
var Z = red * 0.0000000 + green * 0.053077 + blue * 1.035763;
// XYZ to xy
var x = X / (X + Y + Z);
var y = Y / (X + Y + Z);
return JSON.stringify({
'color': {'x':x,'y':y,'brightness':Y} // brightness currently not supported this way by zigbee-shepard
});
})(input)
Color Mqtt_GB4_Color "GB4 Color" <light> {mqtt=">[broker:zigbee2mqtt/0x7cb03eaa00a88dd2/set:command:*:JS(hsv2xyz.js)]"}
Same for me : Zigbee binding does not seem to work straightly with Xiaomi Zigbee devices.
And it does not seems to be specific to the OpenHab Zigbee bridge : standard zigbee support does not seems to handle Xiaomi’s specificities in other domotic software either… what’s why all Xiaomi devices users who want’s to skip the official xiaomi gateway use the zigbee2mqtt.
If xiaomi uses standard zigbee layers, why nobody on any domotic soft has ever tried to implement it ?
The issue as I’ve seen anyway is that these device sleep very quickly after inclusion and you need to keep waking them up for some time after they join the network. I’ve seen the same statements on the SmartThings forum. For me, if I do this, the devices mostly work ok.
My Xiaomi Aqara temperature sensors are all automatically detected perfectly fine by the Zigbee binding. However they all go to sleep after an hour or so and can not be reconnected. This also seems to be a very common issue that also not only appears on openHAB. However I read that this does not occur with Zigbee2mqtt. Having only a Telegesis stick I couldn’t yet verify this.
It would be awesome, if it were possible to sort this issue out.
Still no luck. According to the log, there are checksum erros. It is hard to understand why this is working with zigbee2mqtt but not with the zigbee binding.
2018-08-26 19:49:13.379 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zigbee:device:118bd567:00158d00020d78ab' to inbox.
2018-08-26 19:49:22.166 [ERROR] [531.network.packet.ZToolPacketStream] - Packet parsing failed due to exception.
com.zsmartsystems.zigbee.dongle.cc2531.network.packet.ZToolParseException: Packet checksum failed
at com.zsmartsystems.zigbee.dongle.cc2531.network.packet.ZToolPacketStream.parsePacket(ZToolPacketStream.java:140) [231:com.zsmartsystems.zigbee.dongle.cc2531:1.0.11]
at com.zsmartsystems.zigbee.dongle.cc2531.network.packet.ZToolPacketParser.run(ZToolPacketParser.java:107) [231:com.zsmartsystems.zigbee.dongle.cc2531:1.0.11]
at java.lang.Thread.run(Thread.java:748) [?:?]
Why not try debugging the issue to see if you can find out more. The issue here is in the TI driver, so isn’t a binding issue as such, and as I said, they work for me (I use the Ember coordinator though).
Probably these aren’t used, so it probably doesn’t matter. The driver uses a raw packet for most of the communications, but without checking the documentation, I can’t be sure, so I’d suggest to start there.
I would suggest to start a new thread on that topic though as it’s not related to this.
