-
Notifications
You must be signed in to change notification settings - Fork 298
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
[Question] Strategy for manufacturer-specific attributes in standard clusters? #4
Comments
Also the answer to #5, I would just add them zcl-id/zcl-packet and prefix it with ubysis. The aim of zigbee-herdsman is more on "real world usability" instead of the "perfectly follows ZCL specification" part. |
Ok, I'll check that - but are you sure that adding a new cluster with the same numeric id as an existing one (see #5 ) is a good idea? I would be a bit worried when it comes to reverse lookup on incoming Zigbee packages... |
In this case, the cluster should be renamed, e.g. |
Ok, but then we will be in trouble again as soon as we hit duplicate attribute ids (ubisys uses e.g. 0 and 1). I would rather go for clearer definitions, and I only need the additional clusters and attributes for configuring the devices inside the ubisys extension where I anyway have my own read and write attribute functions. Would it therefore be ok for you if I define them as suggested above with the manufacturer id prefixed and only parse them inside my own code without touching anything general? |
My biggest struggle with https://github.com/felixstorm/zigbee2mqtt/blob/f41f754135f918a9b60ad14501311e48f5ae1114/lib/extension/ubisys.js#L166 is that it is a lot of code (= extra maintenance) while adding very less feature wise (only for ubysis users, which you are the only reported one now). |
As I'm currently completely refactoring zigbee-herdsman anyway, I'm thinking it maybe nice to have 'conditional' manuf specific clusters, e.g. only when the manufcode matches. This would solve your problem and keep all parsing inside zigbee-herdsman. |
Great, sounds very good to me! If you find a way to also take care of manufacturer-specific properties inside standard clusters that would sure be helpful as well (so we won't get in trouble in case of duplicate attribute ids either). I'll then go ahead with my personal implementation for now and will update it to the new spec as soon as it is available. Thanks, |
Ok, I have done some more work and implemented everything inside the ubisys extension: https://github.com/felixstorm/zigbee2mqtt/blob/master/lib/extension/ubisys.js My JavaScript knowledge really is a bit rusty and I need to get used to promises, but I like it really a lot better than Python (used to play around with https://github.com/zigpy/zigpy also) 😉 If you have any comments or suggestions, please feel free to do so. I need to do some more testing (especially binding an input module C4 to dimmers or shutter controllers) and might also implement the metering part and then I will do a PR. By the way, I can really recommend the ubisys devices. They are not cheap, but small, work very reliably, are very well documented (e.g. Shutter Control J1 Technical Reference) and provide a lot of different functions directly on the Zigbee level. I have around 15 of them in my house for 2 years now and I am perfectly satisfied. |
@felixstorm great! Maybe I misunderstood but as mentioned in #4 (comment) I cannot merge this extensions. |
Sorry - this really seems to be a misunderstanding. I thought it would be helpful to keep everything self-contained inside |
All configuration code can be put here: https://github.com/Koenkk/zigbee-shepherd-converters/blob/master/devices.js#L571 |
Maybe that was not clear, but the whole stuff inside |
@felixstorm the two examples you mention can be done perfectly fine in the |
@Koenkk that was exactly the route I had taken in the first place, but then did not find a way to insert the necessary delays to wait for a complete run up or down (60-90 seconds) during shutter calibration. Therefore I had then switched to implementing an extension instead. Anyhow I am fine for the ubisys extension to not be merged into the mainline currently if there apparently is no demand for it besides myself (I can simply keep and maintain it in my repo for now). As support for ubisys devices in general does not depend on the extension, I will test it a bit more in my environment and then (probably in a few weeks when I am back from vacation) open a PR for it excluding the extension. Thanks again for spending your time and effort on creating and maintaining this great ZigBee solution and feel free to close this issue if there is nothing more to add from your side. |
@felixstorm could you provide me a bit more context on how such a calibration is done? We can look into the possibilities of adapting zigbee-shepherd-converters. |
@Koenkk basic calibration sequence is as follows:
Just some ideas:
|
Option 2 sounds great, I think we can also do it without the zigbee object by passing the result of the previous action? |
Sorry for the delay, just came back from vacation. Option 2 without the zigbee object could probably work if the array returned from the converters is allowed to contain both objects to publish to zigbee as well as promises which would then all be processed sequentially so that we can write an attribute, wait, send a command, wait etc. |
@felixstorm zigbee-herdsman has now landed in the zigbee2mqtt dev branch, you should be able add the calibration to https://github.com/Koenkk/zigbee-shepherd-converters/blob/zigbee-herdsman-converters/converters/toZigbee.js. Could you also make a PR with the manufacturer specific clusters? I will then modify this further. |
@Koenkk Cool, looks good, thanks! I am a bit busy at the moment, so it might take a few days until I get to it, but I will let you know as soon as I have added the calibration. |
@Koenkk I did a first implementation: There are some open questions where I could use some advice from you:
|
|
|
|
|
Also ok with that! |
Ok, thanks - then I'll wait for the logger to become part of |
@felixstorm you can also file a pr for that, it shouldn't be more than changing https://github.com/Koenkk/zigbee2mqtt/blob/dev/lib/extension/entityPublish.js#L137 const meta = {
endpoint_name: topic.postfix,
options,
message: json,
}; to const meta = {
endpoint_name: topic.postfix,
options,
message: json,
logger,
}; |
Necessary changes are applied so I assume that this can be closed now. |
Thanks! Will open a PR for it now... |
As already mentioned in my last pull request, I am implementing support for some ubisys devices at the moment. To e.g. calibrate their shutter controller to the run-time from fully open to fully closed, they use quite a lot of manufacturer-specific attributes within standard clusters (e.g. attributes 0x1000 and up in
closuresWindowCovering
).Currently, I have these implemented as numeric values in code but thought it might be nicer to have them somewhere in a central location, but could not really figure out an obvious way to do it. One idea is to implement them in additional clusters that have numerical ids with the manufacturer id as upper bytes, e.g. for ubisys (manufacturer id is 0x10f2) and the cluster
closuresWindowCovering
(258 = 0x102) it would be 0x10f20102 = 284295426. But even this would mean that I will need to touch quite some central code inside zigbee-shepherd and zigbee2mqtt to implement it correctly...Do you have any opinion or suggestions for me or should I rather stick with the way I have it implemented currently?
Current implementation in my code: https://github.com/felixstorm/zigbee2mqtt/blob/f41f754135f918a9b60ad14501311e48f5ae1114/lib/extension/ubisys.js#L166
ubisys documentation (if interested): https://www.ubisys.de/wp-content/uploads/ubisys-j1-technical-reference.pdf
Thanks,
Felix
The text was updated successfully, but these errors were encountered: