A few questions have been asked whilst I was off on vacation. Sorry for the delay.
You should not need to use the phone app to enroll a lamp onto the bridge. The timing between switching on power to the lamp and hitting the enroll button is critical. I can only suggest retrying until you get the confirmation flashing of the lamp.
The plugins will never ask for login information. That is only required for access to the Bridge’s built-in server for initial set up.
Sadly there is no way to confirm that a UDP datagram was received by the Bridge - other than seeing the lamp change.
Hamish, it seemed to me that there were independent brightness levels for the disco modes as well as white and RGB. The MiLightCU plugin resets the brightness level of the lamp to match the setting on the dashboard slider whenever the mode is changed.
I’m loving this plugin and use it to give a visual indication of my security system status. I found a wireless RGB strip controller on eBay that appeared to use the same frequency/controller as the LED bulbs (search item number 160994718580 on ebay). I finally got around to testing it with the wifi adapter/vera plugin and it works perfectly. It’s a great option for those who want to integrate vera with RGB led strips!
does anyone know if the RGB lamp can be triggered to take a preset Color via UDP ?
its very much toy-like if have to zapp trough the colors … and the vera does not really “see” the active color as well due missing Eye’s and Status response.
Thanks for the great work on the plug-in. I have a silly question. Would this lamp be useless on a light controlled by a regular wall switch? For example, if someone flips the wall switch off that powers a lamp with these bulbs, then no app, vera call, or remote will be able to control the light…is that correct? So the use case here is an installation into a socket that is ‘always on’ or one where one can not/should not use the wall switch? Just considering the WAF in this solution.
thats is correct.
the downside of permanent power is, that on a power failure ALL The lights will get “on” since the bulbs are designed to be on a switch.
howewer in a Automated envioment it makes little sense to have them on a switch.
they not really thinked trough. the “automation via apps/remotes/wifi” was just added to the lamps. with the point of sale of 1 lamp + 1 Remote in mind.
but they cheap (5 usd or so each) … so its worth the down sides.
i have some of them in my office room, where i use a fibaro modul on a switch to switch all the Screens, printers and other things, the LED is connected there as well.
if Vera detects the Devices as been turned on it sends 3 secounds later the reset commands to the LED to make sure they got the settings i want.
since there is also no way of knowing what state they are in.
Thanks. So these are better (for my household) to use where lamps are not wall switch controlled. The price point is attractive, but I am seeing them at $16 ea, not the $5 you mention. Where are you seeing them for $5 ea?
well if you have somethings to Trigger a reset (like another switch or so) the downsides are not so bad.
i have a lua startup command on my Vera to turn off all LED lights on startup (startup means the power was out)
and in day by day operation they triggered by other switches or scenes.
you can find alot of this LED lights on HongKong/China Based companies where they actually produced.
but it’s a bit tricky to select the real manufacturer (most companies just making copies, and have no clue about the technology, they just glue them together.
also warranty is a issue.
i live in Thailand, so the shipments are not a issue for me.
so 16Bucks at limitelessLED is quite a Fair Price, since they deal with mindless Chinese for you, provide the support and give you warrany as well. (both things are alien words to chinese peoples )
If you look at the first post in this thread you will see links to four different plugins. Each set of plugin files includes instructions on installation and operation.
The plugins are:
[ul][li]MiLightW - Emulates the White lamp remote - really a discovery and debugging tool[/li]
[li]MiLightRGB - Emulates the RGB lamp remote - really a discovery and debugging tool[/li]
[li]MiLightWU - Provides a dimmable-light device for one zone of White lamps [/li]
[li]MiLightCU - Provides a dimmable-light device for RGB lamps [/li][/ul]
You probably don’t need the discovery and debugging tool plugins unless you plan on building your own disco scenes. :o
I have no immediate plans to publish these plugins. I still consider them to be in beta-test.
oh one more thing, if switch a lamp off (White and RGB) the lamp goes off but the LoadLevel percentage stays …
some apps consider this as “ON” even the lamp is not …
yeah i got that far already .. but somehow the lamp does not always do that .. sometime it switches to RED ...
very annoying ...
its most likely a communications problem …
i send now all commands twice, seems to work now. (not perfect, but cheap)
There is no command to directly set the effects mode to 1 so I have to step it down from where I last set it. A comms issue could cause this to go awry… Try setting newEffectsMode to 0. This will cause the plugin to resync the mode by stepping it down 20 times which should guarantee you get “white” light.
oh one more thing, if switch a lamp off (White and RGB) the lamp goes off but the LoadLevel percentage stays ...
some apps consider this as "ON" even the lamp is not ...
That is deliberate. It allows the lamp to be turned back on at the same dim-level it was at when turned off. If you don't want this, turn it off by setting the dim-level to 0.
i can live with all this things …
but what really does annoy is that you can never trust the commands are really being executed.
but that is sure not the fault of the plugin, just the 1980 style communication the wifi controller uses i guess.
i found out that there seems some sort of “sleep” … i added in all scripts the first command twice with a 1,5 sec. delay … this sortet the issue that the first command will be ignored.
also i do always first set a color … this seems to reset somehow the arrangements of modes and plays alot more smooth.
one short question do i have:
does the plugin respect the command delays ?
or do i have to do this via luup.sleep myself ?
but that is sure not the fault of the plugin, just the 1980 style communication the wifi controller uses i guess.
I think you are correct. Once in a while a command gets [i]lost[/i]. I experimented with using TCP instead of UDP for interface with the bridge but it made no improvement and slowed everything down. It probably depends on how busy the 2.4GHz band is at your location and, of course, the proximity of the bridge to your lamps.
i found out that there seems some sort of "sleep" .. i added in all scripts the first command twice with a 1,5 sec. delay .. this sortet the issue that the first command will be ignored.
I haven't noticed that on my system. It responds almost instantly however I trigger the actions. Have you installed [i]MiLightRGB[/i] plugin? It would be interesting to see if the lamps also ignore the first simple [b]On[/b] or [b]Off[/b] command from that. [i]MiLightRGB[/i] does not attempt to track the state of the lamps - it just sends the commands when you click the buttons.
also i do always first set a color .. this seems to reset somehow the arrangements of modes and plays alot more smooth.
Yes that forces a re-sync of the effects mode. Setting the mode to 0 will do the same thing but leave it set on "white".
does the plugin respect the command delays ?
Yes - all the inter-command delays are included where required.
also i do always first set a color … this seems to reset somehow the arrangements of modes and plays alot more smooth.
Yes that forces a re-sync of the effects mode. Setting the mode to 0 will do the same thing but leave it set on “white”.[/quote]
yes you suggested that some place else … but it never worked really smooth … well that may be a combination with my other discovery of the sleep-effect.
oh btw, yes i have the RGB module as well … same thing … its sure a communication issue,
if it works … the lamp does react instantly … (with both plugins or via luup.action)
i suspected the range as well … since the RGB lamp is in the first floor … but my Controllers are all downstairs … so i moved the lamp and sit for hours in front of it with my notebook … same thing.
does the plugin respect the command delays ?
Yes - all the inter-command delays are included where required.
i noted that if i have serval commands in a row .. they also messing up
with the 1.5-2 sec delay between the first command and the repeated command and a 500 ms delay between all following commands it works smootly (well sort of)
it makes the whole action extremly slow … but well, why should i care … its all scene-controlled so nobody will know there is a 5-10sec. delay
)
