Plugin for WIFI controlled LED light (IWY-Light)

---

@philip1986 said:

About color fading option, I am not really sure what it really means. I guess it is supported by the devices itself. I saw some e.g RedGradualChange or BlueStrobeFlash. @leader21 Did you mean this?

yes, that’s it. some gradual change from several colours where you can set the dimming speed yourself - e.g. beginning with 0 then dimm up to full red dimming down again to 0 going over to dimm up to full blue then and so on. (or maybe stay at one colour and dim that up and down like pulses). the strobe flash is annoying imho

I would like to have tow drivers (one for IWY and WIFI370 and one for Milight) with an equal interface. So the user can decide via the config which driver resp. device type he like to use.

imho if the functionality is the same, why not use the same plugin with different devices - with iwy and wifi370 it seems to work. and as icesory said - maybe rename the plugin to a more common name then…

@philip1986 said:

Oh yes, unfortunately “npm install pimatic-iwy-light-master” does not fetch to hole repo. I`ll try to fix it. @hyperx could this also be the issue in your case?

About the color picker topic, I am open for any changes to improve the UX, but at this point I don`t know that is the best way to do it. Some help would be awesome.

About color fading option, I am not really sure what it really means. I guess it is supported by the devices itself. I saw some e.g RedGradualChange or BlueStrobeFlash. @leader21 Did you mean this?

@Fjux what are your concerns about merging the stuff? I would argue that the functionalities from the users point of view are the same. So the difference is just the way commands are send to the device. And this problem we can abstract into the drivers. I would like to have tow drivers (one for IWY and WIFI370 and one for Milight) with an equal interface. So the user can decide via the config which driver resp. device type he like to use.

Yes that is exactly what i want.

and just now i realized that we can do that if we use seperate device classes ^^
i was thinking of getting the gui part in the main Pimatic application, but for now a integration sounds good.

lets continue the details in PM’s

that is the right way guys. Co operations.

When your plugin in is on the way, we can move the colorpicker to the mobile-frontend.

@Fjux We should avoid doing the same thing twice. I have already started to some work on pimatic-iwy-light-master to integrate milight by using your fork of node-milight. May be you spend some time on fixing and improving node-milight?

@philip1986 Can you please enable “Issues” on the github project, please? I think it is disabled because the project was a fork previously. You should be able to enable “Issues” by clicking on “Settings” on the right hand side of the github project page. Thanks!

Issues are enabled now.

I changed the plugin name to pimatic-led-light and solved the npm install issue. It is now published under https://www.npmjs.com/package/pimatic-led-light.

@sweetpi can you please update this on the homepage as well.

Nice, homepage and plugin list updated.

@Fjux Ok I got your point and I agree this is the better solution.

Can you please create the PR agin against the branch ‘feature/support_mutiple_devices’ . I like to merge it, polish it up a bit to make it work for the current devices. And you can start to implement the wrapper class MilightLed.

@philip1986 and @Fjux: I have created a fork yesterday and published pull request today for the separation into multiple device types and the integration of Milight. See comments on https://github.com/philip1986/pimatic-led-light/issues/5

btw. Milight as part of pimatic-led-light basically works Just the recovery of the power state from DB does not work properly. Note, it is not possible to query the state from a Milight device (comms is one-way).

Milight has some more functions which are probably not supported by IWY-Master and Wifi370. To give you an idea what it is, have look at the demo video of the openHAB Milight Binding.

Some Mobile GUI Dimmer and Color Picker variations:

Will this color picker device be integrated in to pimatic? So i can call it in other plugins?

I can send rgb hex codes to my moodlight (mysensors).

For a dimmer i call env.devices.DimmerActuator, will this be possible for a color picker too?

I found some code with many more Wifi RGB versions! https://github.com/herrmannj/wifilight http://www.fhemwiki.de/wiki/WifiLight#on_.2F_off

The HX version of the WF200 (wifi370) controller is interesting, it’s a wifi370 clone and normally can only be controlled in it’s own wifi network. It’s called LW12HX in the code. I saw that @leader21 and @Icesory got these controllers, I got three of them.

Oh and maybe we can merge the two topics? This is a bit confusing :P.

closed the other threat http://forum.pimatic.org/topic/372/mi-light-iwy-ect-and-wifi-370-integration
let’s discuss things here.

@Fjux and @mwittig I managed to have a deeper look into your PRs and I created a new one based on your ideas. So please have a look into it and tell me what you think. https://github.com/philip1986/pimatic-led-light/pull/7

I also split the code into different files in oder to provide a better structure for implementing new devices. So sorry for potential merge conflicts.

@mwittig said:

Milight has some more functions which are probably not supported by IWY-Master and Wifi370. To give you an idea what it is, have look at the demo video of the openHAB Milight Binding.

Iwy has also some “bulid-in programs” and a music mode see here
https://www.youtube.com/watch?v=G0sGrnOunTE (from at 1:55)

I considered those features as less important for a first implementation, but we can defiantly thing about how we can implement those features into pimatic.
There are also LED which doesn’t have a color mode, just withe white with dimming functionality, or others which only run in color mode. We should thing how to deal with devices that provide not all features we support and disable/hide UI elements in those cases.

@philip1986 OK thanks, I’ll have a look

There are also LED which doesn’t have a color mode, just withe white with dimming functionality

Same with Milight btw. and there are at least four different versions of the controller. For the Milight case this can be handled well by providing different device types and I guess it can be done similar for IWY, e.g. provide a device type for DualWhite bulbs (with Milight it does not make much sense to mix RGB and Dual-White bulbs in a single zone, btw.)

Regarding the special features like night mode and disco mode I agree this is perhaps less important. However, it would be nice to provide some Actions which will allow users to use RGB bulbs as sort of visual feedback as part of their rules, e.g. “If a new e-mail has been received then flash RGB lamp1”.

I did a quick review. I like the new structure and will give it a try later.
Here is a shortcut to see commit changes

I just checked out the code, and it looks great!

i really like that it is split up in different file’s. That makes everything a lot clearer

But i’m wont have a lot time next couple of weeks to work on it…
Normal work doesn’t seem to stop for these nice projects