Misleading subdevice type for Osram Lightifiy Smart+ Plug

[hiscorebob]

Home Assistant release (hass --version):
0.62.1 (also prior versions)

Python release (python3 --version):
3.6.3

Component/platform:
osramlightify

Description of problem:
An Osram Smart+ Plug connected to Lightify Gateway gets a misleading entity type. It's discovered as "light.plugname". In the UI, the device also has light controls (brightness, color select etc..) where it should only be treated like a switch (on/off)

Expected:
Should be discovered as switch.plugname. But the component only accepts "light" as platform.
There should be also a "Osram Lightify Switch" component

[ajdezigns]

Hello Does the LIGHTIFY ZigBee 2 Button Wireless Dimmer Switch work with home assistant?

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[hagenuck1]

Hello, I’m using Home Assistant with hassio image since yesterday and the issue with the Osram Smart+ Plug as light is still there.

[hiscorebob]

Issue is still present in 0.76.1

[jcbbas]

The same thing occurs with the lightify dimmer switch in the latest release. The switch shows up as a light that cant be controlled.

[dshokouhi]

the lightify component was initially setup as a light platform so what you guys are asking seems to be more of a feature request as it was never designed to be a switch the upstream library does not have much support for switch and motion sensors so someone will need to submit a PR for this.

https://github.com/home-assistant/home-assistant/blob/master/homeassistant/components/light/osramlightify.py

You guys may want to file an issue in the upstream library because as of now everything seems to be treated as a light in upstream.

https://github.com/tfriedel/python-lightify

[Xaron-Ice]

Is there any progress on this issue?
I have the same problem with my osram smart+ plugs which are shown as lights. Really annoying.

[tfriedel]

I am going to look into this when I have the time.
However I don't think you will be able to make much use of the switches in home assistant since the gateway already triggers the lights and there's no mechanism for home assistant to get notified instantly about state changes. So it has to regularly poll the gateway to get the state.
If the only problem is that the switches appear in the UI as lights, that should be fixable.

[Xaron-Ice]

At the moment is the only problem that the switches appear in the ui as lights. Would be awesome if you could look into this.

[Superheld]

Some here with 0.77something ;)
I can change settings like brightness, color and so on on my two plugs.

[tfriedel]

sorry, it seems I will not have time for this. I looked into it for an hour, but I can't easily figure out how to make switches, motion detectors and plugs known to home assistant as these kind of components. The whole osramlightify.py module is only made for lights and not my own code.
The easiest solution would be to not return non-light objects in the lightify component. However both motion detector and plug still have some functionality if used as a "light" in home assistant. So for those I wouldn't want to do this.

One workaround would be to not let home assistant auto detect all the lights, switches etc (or only once), but naming them explicitly in the configuration. I think then it should be possible to remove all the components you don't want to see.

[tringler]

Hello @tfriedel,

I'm irritated - Why not using your commit tfriedel/python-lightify@a9617a5#diff-6bd9ebefac120a106919b1e2edf720d8, that we can isolate lights as lights and switches as switches (There should be a new switch component needed)

Thanks, Thomas

[deisi]

@tfriedel @tringler
Hey, I'm the one who wrote the code for the lightify groups, but I did so picking up on code already existing in HA. So in other words, the strange class structure @tfriedel saw, is my fault (sorry for that) but I decided doing so because it removed redundant code.

First questions first, I don't think I will/can do all this on my own any soon, so are there people willing to help me out with this?

As @dshokouhi mentioned, the component was only written for lights, because that is all I had up to that point. By now I have also switches, and I started to think about implementing them as well. However, I'm not sure how to do this. As a roadmap, I would suggest doing it in two phases.

1. Implement a new switch/lightigy.py component. (quick and dirty)
2. Rewrite code into some kind of separate component (taking the hue component as a reference)
   I don't know about the full capabilities of the hue component, but I think it handles switches and stuff correctly.

I think the hardest is 1., because we will, as @tfriedel mentioned, need to make python-lightify aware of switches. As far as I remember this is not implemented yet. The good news is binary-protocol has already done the hard work of reverse engineering the protocol itself. Thus we should be able to add the device types to python-lightify.

My vision for 2. is:

• auto detection of lightify bridges
• implementation of all device types
• rewrite of the way we handle groups of lights in HA

Auto detection and implementation of further device classes should be straight forward, but the rewrite of the light groups puzzles me. The problem with the current system is a mismatch between the way HA handles lightify light groups and how lightify handles groups itself. Namely lightify light groups don't have a state. They can't be on or off, you can only switch them on or off, however, HA assigns a state to these groups, by looking at the state of the first light in the group and assuming the state of that light is the same as the group itself. This leads to quite some strange behaviour when dealing with groups of lights.
I started to believe it would be better to remove the state from the lightify light groups as well and not assume anything about it, since it is wrong about half of the time anyways. Of cource this would be a breaking change for some people, because automations using the state of a lightify light group would not work any more.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[stale]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.