danielolson13
commented
8 years ago I contemplated adding name support too, but like you said it's not in the database. If you add ID 50393095 to the zigbeeAttributes variable will it return anything?
What bulb is this you're using? I'll pick one up and test it out.
I'm totally open to contributions of any kind. I cobbled this together for my own use and know it could use work.
On Sun, Sep 18, 2016 at 7:29 PM Ryan Spicer notifications@github.com wrote:
First off, awesome project! And thanks for updating it to support 2.68's new weirdly-changing tmp file database -- I went to fork it to add this support, and said "wow, someone already fixed it!"
This is not a trouble ticket, more a "brainstorm how to achieve a thing in a way that doesn't break other peoples' use cases and could eventually get merged" ticket.
I'm using this on a Wink hub to communicate with a RPI-based home automation system to do some time-of-day-based control of Osram Lightify color-temp controllable bulbs (Zigbee ID 50393095, according to aprontest -l -m(#)). I manually edited wink-mqtt.js to allow me to read/write this property.
Aprontest -l -m(#) also exposes a named list of properties and a flag for read-only or read-write.
Looks like this isn't in the apron db, only available through aprontest itself. Might be possible to parse the output of aprontest with a regex or similar to scrape property names and read/write status. Naive thought is "why not expose all r/w properties?" Two potential problems:
1) my lightify bulbs expose several properties that are meaningless (hue/saturation/red/green/blue -- guess maybe OSRAM uses the same firmware for their more expensive RGBW bulbs too?) 2) Some people may want to use zigbee switches, which might expose state as a read-only property.
In the case of potential problem 1, there's a promising read-only property called ZB_ColorMode (value: 2) that might be used to specify which type of bulb it is, but that's a solution only to my specific Lightify use case, not the general case. Potential problem 2 is a bit less tractable -- maybe it's worth cooking up a new config file to let me configure the endpoints I want for each device?
If I built that, would it be likely to get merged, or is it too much silly complexity for an edge case?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/danielolson13/wink-mqtt/issues/12, or mute the thread https://github.com/notifications/unsubscribe-auth/AEs5GLE36Y3dFv234bgyh1W5eoeOUmmZks5qrclxgaJpZM4KADPb .
alterscape
First off, awesome project! And thanks for updating it to support 2.68's new weirdly-changing tmp file database -- I went to fork it to add this support, and said "wow, someone already fixed it!"
This is not a trouble ticket, more a "brainstorm how to achieve a thing in a way that doesn't break other peoples' use cases and could eventually get merged" ticket.
I'm using this on a Wink hub to communicate with a RPI-based home automation system to do some time-of-day-based control of Osram Lightify color-temp controllable bulbs (Zigbee ID 50393095, according to aprontest -l -m(#)). I manually edited wink-mqtt.js to allow me to read/write this property.
Aprontest -l -m(#) also exposes a named list of properties and a flag for read-only or read-write.
Looks like this isn't in the apron db, only available through aprontest itself. Might be possible to parse the output of aprontest with a regex or similar to scrape property names and read/write status. Naive thought is "why not expose all r/w properties?" Two potential problems:
1) my lightify bulbs expose several properties that are meaningless (hue/saturation/red/green/blue -- guess maybe OSRAM uses the same firmware for their more expensive RGBW bulbs too?) 2) Some people may want to use zigbee switches, which might expose state as a read-only property.
In the case of potential problem 1, there's a promising read-only property called ZB_ColorMode (value: 2) that might be used to specify which type of bulb it is, but that's a solution only to my specific Lightify use case, not the general case. Potential problem 2 is a bit less tractable -- maybe it's worth cooking up a new config file to let me configure the endpoints I want for each device?
If I built that, would it be likely to get merged, or is it too much silly complexity for an edge case?