Comments (30)
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,
Felix
from zigbee-herdsman.
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.
from zigbee-herdsman.
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.
from zigbee-herdsman.
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...
from zigbee-herdsman.
In this case, the cluster should be renamed, e.g. manuSpecificPhilipsUbisys
, as id's cannot be duplicated.
from zigbee-herdsman.
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?
from zigbee-herdsman.
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).
from zigbee-herdsman.
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.
from zigbee-herdsman.
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.
from zigbee-herdsman.
@felixstorm great! Maybe I misunderstood but as mentioned in #4 (comment) I cannot merge this extensions.
- Either wait for #4 (comment)
- Or as a temp workaround: #4 (comment)
from zigbee-herdsman.
Sorry - this really seems to be a misunderstanding. I thought it would be helpful to keep everything self-contained inside ubisys.js
? From my side, there is currently no need anymore to have the ubisys manufacturer specific clusters or attributes inside zigbee-herdsman since they are only needed to configure the devices and this is now all inside ubisys.js
.
Or do you think that ubisys.js in general is too much code to take into zigbee2mqtt? But I hardly see another way to configure the devices. Or is there any other interface I could use to communicate with zigbee2mqtt on a low level so I could put the ubisys configuration code into a separate project?
from zigbee-herdsman.
All configuration code can be put here: https://github.com/Koenkk/zigbee-shepherd-converters/blob/master/devices.js#L571
from zigbee-herdsman.
Maybe that was not clear, but the whole stuff inside ubisys.js
is for one-time-configuration.
An example: the shutter controller needs to know how many seconds the blinds take to go from fully open to fully closed and also for the other way around (which sometimes differs a bit) in order to be able to go to a specific position, e.g. to close the blinds 80 percent. Therefore there is a one-time calibration procedure that can be controlled by setting specific attributes, moving up and down in a predefined order and in the end setting the attributes back to normal.
Another example: The dimmer can work with spring loaded buttons or with a normal rocker switch and can potentially have separate up and down buttons or just one - this can be configured by means of attributes in the manufacturer-specific cluster...
from zigbee-herdsman.
@felixstorm the two examples you mention can be done perfectly fine in the toZigbee
converters, this seems similar to me as e.g. setting a sensor sensitivity (https://github.com/Koenkk/zigbee-shepherd-converters/blob/master/converters/toZigbee.js#L903). Note that you can also very easily address non-standard clusters there (just put the hex number as show in the link).
from zigbee-herdsman.
@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.
And in case other people should show interest for the calibration stuff in the future, then just drop me a note and we can then figure out what the best way is to implement it.
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.
from zigbee-herdsman.
@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.
from zigbee-herdsman.
@Koenkk basic calibration sequence is as follows:
- send command "open"
- wait 60 seconds (or better: regularly read (or monitor (previously configured) reporting) attribute to get notified when the motor stops at the top)
- write some (manufacturer specific) attributes
- send command "down"
- wait 5 seconds
- send command "up"
- again wait 10 secs or until motor has stopped at the top again
- send command "down"
- again wait 60 secs or until motor has stopped at the bottom
- send command "up"
- again wait 60 secs or until motor has stopped at the top
- write some (manufacturer specific) attributes
Just some ideas:
- If the converters in
toZigbee.js
would somehow get access to thezigbee
-object then calibration could be handled in there. - A more advanced version that would probably make the code cleaner might be if the converters could return - as an alternative to the current array of result objects - an array of promises (or similar) which would then be executed sequentially by
DevicePublish.onMQTTMessage
(but they would still need thezigbee
-object).
from zigbee-herdsman.
Option 2 sounds great, I think we can also do it without the zigbee object by passing the result of the previous action?
from zigbee-herdsman.
@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.
from zigbee-herdsman.
@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.
from zigbee-herdsman.
@Koenkk I did a first implementation:
felixstorm@bd0a8e0
felixstorm/zigbee-herdsman-converters@f306327
Does this look ok for you or would you like me to make some changes (console.log
is just in there as a placeholder, it's definitely not meant to go into production 😉)?
There are some open questions where I could use some advice from you:
- Cluster
manuSpecificUbisys
: I have just added it to the list of clusters, but it has the same id asmanuSpecificPhilips
, so it will probably not work on incoming stuff from Zigbee. Is this ok for now and you will modify this further or would you like me to make some changes to it? - Logging: The calibration can be a rather lengthy process, so IMHO it would be helpful for the user to get some feedback in between. Maybe passing a logger along as part of
meta
would be a way to solve this - what do you think? - Configuration output when reading from Zigbee: I am not really sure if it is helpful to return the read configuration data as a normal state since when being used with Home Assistant, this information is being retained and passed to HA again and again. Also, it's not really a state - again a logger might be a way to solve it?
from zigbee-herdsman.
- Yes, just make this PR and I will continue with that.
- OK with that
- Can't we abstract this to a higher level? e.g. it might be useful to the user at which point it has been calibrated.
from zigbee-herdsman.
- Thanks!
- Thanks again!
- To be honest, I do not think that reading the configuration parameters is of much use besides troubleshooting or verifying that everything is configured correctly. It might be an idea to have some sort of repository similar to
state.json
were various (configuration) parameters from all devices can be saved for reference (potentially with a timestamp likeLastRead
or so), but I did not deem it important enough at the moment to justify the effort...
from zigbee-herdsman.
- I agree, just remove the
convertGet
for now.
from zigbee-herdsman.
- Couldn't we just leave
convertGet
in there and use a logger to output the results? Then there would be at least some possibility to read the attributes in order to verify that the calibration has generally succeeded for a specific device. I would have no problem streamlineing the logger output for readability a bit more than just raw JSON...
from zigbee-herdsman.
Also ok with that!
from zigbee-herdsman.
Ok, thanks - then I'll wait for the logger to become part of meta
and then file a PR for the ubisys stuff, or would you like me to also file a PR for adding a logger to meta
?
from zigbee-herdsman.
@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,
};
from zigbee-herdsman.
Necessary changes are applied so I assume that this can be closed now.
from zigbee-herdsman.
Thanks! Will open a PR for it now...
from zigbee-herdsman.
Related Issues (20)
- Ember driver : Error while parsing received frame, status=NO_RX_SPACE. HOT 1
- Ember driver: SET "APS_UNICAST_MESSAGE_COUNT" TO "32" with status=ERROR_OUT_OF_MEMORY. HOT 1
- State of ZiGate support HOT 17
- [Cluster Type] Align cluster definition for 'name' attribute HOT 1
- Silabs Zigbee EmberZNet 8.0.0.0 (and Silicon Labs Gecko SDK 5.0.0.0) announced and to be released in Q3 2024 HOT 1
- Waitress timer is being set at the wrong time HOT 16
- Make waitress timeout configurable HOT 1
- Lower bound of "turnsOffAtBrightness1" ignored by "brightness_move" & "brightness_step" commands HOT 1
- Issue with serialport v12 and node > v20.2.0 HOT 1
- Get strange error in latest z2m with the latest zigbee-herdsman HOT 6
- [Task] ZCL definition update HOT 4
- Want better endpoint.writeStructured() HOT 3
- Z2M 1.35.2 stops with "Adapter disconnected, stopping" after few minutes of uptime (Sonoff-E / EZSP v12 / FW 7.3.2.0 build 212) HOT 3
- Load additional manufacturer-specific clusters from device converter HOT 4
- [Proposal] Removal of "forever" Permit Join HOT 11
- Adapters hardware flow control issues HOT 30
- Ikea Motion Sensor E1525/E1745 not updating properly HOT 6
- proposal: deprecation of legacy clicks HOT 1
- Move special readResponse out of zhc/src/index.ts (fixes legrand pairing issues) HOT 8
- Changes to payload when sending zclData to a device breaks iobroker.zigbee function
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zigbee-herdsman.