Skip to content
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

No way to distinct bulbs, plugs and switches #6

Closed
OleksandrBerchenko opened this issue Aug 27, 2018 · 12 comments
Closed

No way to distinct bulbs, plugs and switches #6

OleksandrBerchenko opened this issue Aug 27, 2018 · 12 comments

Comments

@OleksandrBerchenko
Copy link

At the moment the library reports all devices as bulbs. According to https://github.com/noctarius/lightify-binary-protocol#device-types it should be possible to distinct them.

See also home-assistant/core#12206 .

Thanks!

@Xaron-Ice
Copy link

Is there any progress on this issue?
I have the same problem with my osram smart+ plugs.

@deisi
Copy link

deisi commented Dec 18, 2018

So I'm looking at it right now, (I promise nothing what so ever), but I wonder, @tfriedel, why is there,

class DeviceType(Enum):
LIGHT = 1
PLUG = 2
MOTIONSENSOR = 3
SWITCH = 4
id_to_devicetype = defaultdict(lambda: DeviceType.LIGHT)
id_to_devicetype.update({10: DeviceType.LIGHT, 16: DeviceType.PLUG,
32: DeviceType.MOTIONSENSOR, 64: DeviceType.SWITCH,
65: DeviceType.SWITCH})

Why do we translate the device type numbers in the first place. What is wrong with https://github.com/noctarius/lightify-binary-protocol#device-types? We cold just pass on the numerical device types or? I mean 10 is as good or bad as 1.

Why are these already parts of the Luminary class? I don't know for sure, but judging from the protocol, there should be lights that have fixed temperature and fixed rgb, so there is no point in having a set function for them.

def set_temperature(self, temp, time):
"""
:param temp: color temperature in kelvin.
typically between 2200 and 6500
:param time: transition time in 1/10 seconds
:return:
"""
temp = min(MAX_TEMPERATURE, temp)
data = self.__conn.build_temp(self, temp, time)
self.__conn.send(data)
def set_rgb(self, r, g, b, time):
""" set the color
:param r: amount of red. range 0-255
:param g: amount of green. range 0-255
:param b: amount of blue. range 0-255
:param time: transition time in 1/10 seconds
:return:
"""
r = min(r, MAX_COLOR)
g = min(g, MAX_COLOR)
b = min(b, MAX_COLOR)
data = self.__conn.build_colour(self, r, g, b, time)
self.__conn.send(data)

@deisi
Copy link

deisi commented Dec 18, 2018

I started to think, if a rewrite would be the right way here. The thing with the python-lightify right now is, that it works quite different from the underlying protocol. Probably we are better off with a library that closely sticks to the protocol itself. The advantage would be:

  • future proofness. Osram will not change the protocol but rather add device classes. Having a library that sticks close to the protocol will make life easier.
  • maybe less code, because we actually do less
  • hopefully less bugs, well again we do less

@tfriedel
Copy link
Owner

well the devicetype is not used for anything yet I think. the library only really supports Lights and Groups currently. if you were to add support for the other device types or for debugging purposes, it's nice to have an enum or something more humanly understandable.

regarding temperature/rgb in Luminary, your observation seems reasonable. I would tend to agree, it doesn't make much sense.

Note that I'm not the original author of this stuff but basically only fixed/rewrote some parts that needed to be changed. So I can't help with you everything. Also with the homeassistant side of things (osramlightify.py ) I can't help you at all.

A rewrite would maybe make some things easier. However as far as I know at lot of features are not accessible at all, like getting notified about the press of a switch. Of course it's possible that the HOW has not yet been reverse engineered. I suspect that these features are just only available inside the gateway unfortunately.

So for me this platform is not worth putting much effort in it. It would probably more useful to make all the hardware (lights, switches, sensors) work with a better gateway.

@deisi
Copy link

deisi commented Dec 18, 2018

Also with the homeassistant side of things (osramlightify.py ) I can't help you at all.

Okay, that is fine, would come later anyways.

However as far as I know at lot of features are not accessible at all, like getting notified about the press of a switch

Oh I didn't know this, but how sure are you?
I was just checking with https://github.com/noctarius/lightify-binary-protocol#lightify-commands and from when I checked available information on the protocol last time, a lot has improved

@deisi
Copy link

deisi commented Dec 18, 2018

Thinking about a class structure, I'm not quite sure what is the best way. I could either create a class per DeviceType, or try to combine the 4 Bulbs (id 1-4) into one class and also the switches into one class.

Right now I think it would be clearer if there is one class per device type. This would allow for a clean structure, no matter what Osram does with the DeviceTypes.

@tfriedel
Copy link
Owner

Well I did spend probably a day looking into it.
What is possible is get the state of the motion detector. It uses the red channel of RGB so you can poll it and check if it is was triggered. It's however quite wasteful because if you want it to work semi-real-time you would have to poll every second or more.
To the best of my knowledge it's not possible with the normal switches. Nothing in the protocol documentation makes me think it's possible. No other software (official lightify app, alexa, other reverse engineering efforts for other systems like HASS) has any support for the switches.
You could of course send the lightify engineers a mail, maybe they could give a hint.

I think what would really be needed from the gateway would be a push notification system. But since it was designed to only trigger the lights they just made an app that allows you to configure the connection between lights and switches and all the magic is happening inside the gateway.

So I'm 90% sure that it's not possible. To make the switches usable, you would have to program your own gateway or deal with them on the zigbee level. A custom firmware for the osram gateway would be something :)

@deisi
Copy link

deisi commented Dec 18, 2018

uff, not too good news here. A custom firmware is clearly out of my scope for now. Also the zigbee protocol level itself is nothing I have experience with.
However, I give it a little try. If I come up with something that can use the Power Plugs, Bulbs and also the groups, it would be enough for now. I will also leave some room for the switches. maybe at some point they will work.

@tfriedel
Copy link
Owner

tfriedel commented Jan 2, 2019

There's also this project: https://github.com/Koenkk/zigbee2mqtt
it's a custom zigbee gateway that says it supports osram lightify, hue and others (including switches). Hardware costs are about 20$. I'm going to try this.

@deisi
Copy link

deisi commented Jan 3, 2019

Year, I know there are other ways, but in particular for HomeAssistant it is useful if it just works with whatever people have at home.

@OleksandrBerchenko
Copy link
Author

Well, after a closer code inspection it turned out that the library actually exposes device type (LIGHT, PLUG, MOTIONSENSOR or SWITCH), it was just not used by Home Assistant.

Closing this particular bug, please open new bugs as needed.

Thanks!

@Xaron-Ice
Copy link

Awesome news, thanks for your work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants