Issue with rgb_color / DHCP with multiple bulbs

[johanjongsma]

When you change the color of a light to eg red using:

  - data:
      entity_id: light.office_1
      color_name: red
      brightness_pct: 100
    service: light.turn_on

and then change it back to white using:

  - service: light.turn_on
    data:
      entity_id: light.office_1
      kelvin: 4000
      brightness_pct: 100

the rgb_color still reports
(255,0,0)
as if the light is still red, although it will be daylight.

Thank you guys for this great work; I use it in my whole house.

Johan

[sbidy]

I don't get it :)... If the light is red and you trigger "Kelvin 4000" it will be stay on red? Can you please explain the issue more granular :D...

Thank you for the support and feedback!!!

[johanjongsma]

Hi, Let me give you some background. I'm monitoring a computer and if it is offline, I switch the light to red and when it is back up, I switch it back to 'white'. If I just change the color_name to white, it has a funny color; I like the Kelvin 4000 much better. To avoid running my warning multiple times (it also says 'ALARM system is down on my tablets') I check the color of the light. And the problem is there. When I switch the color back to 4000k, the light is white again (exactly what I want), BUT the light still reports its rgb_color being (255, 0, 0). Hope you understand now. Best, Johan ps. Do you think you could report the MAC address back to HASS? I lost my IP-numbers once, because my DHCP was lost and it was quite painful to reassign all 100 lights .... ps2: you asked for hardware: What would you like to have, I'm happy to get you some.

[sbidy]

@johanjongsma sorry for the delay.
I think there is a problem with the status update - I'll try to reproduces this issue with a similar setup.
Today I released a new version of the support lib (pywizlight) and it will now support to report the MAC address back. Additionally a auto-discovery will also be introduced. This will helps you to trigger a discovery via ConfigFlow in the web interface and this should be assign the (100) bulbs automatically to the HA/SS.

[johanjongsma]

Sounds great. I'm travelling, I will be able to test & try it all only in three weeks. Something else what I would also like to be able to do would be to change the color of the lights WITHOUT switching them on. So, when the sun sets I want to change the color to a warmer tint; when somebeody then switches the room on, it would be in the softer tint. Of course the same feature in the morning. Do you think that is possible, or should I create a template for each light? Best, Johan ps. Do you need more hardware? I'm happy to pitch in. [Johan Jongsma - Chat @ Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=q135e) [q135e] On October 11, 2020 at 16:38 GMT, Stephan Traub <[email protected]> wrote: [@johanjongsma](https://github.com/johanjongsma) sorry for the delay. I think there is a problem with the status update - I'll try to reproduces a similar setup. Today I released a new version of the support lib (pywizlight) and it will now support to report the MAC address back. Additionally a auto-discovery will also be introduced. This will helps you to trigger a discovery via ConfigFlow in the web interface. — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](https://github.com/sbidy/wiz_light/issues/38#issuecomment-706731971), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AKWAGIA2NXYQCACMR2LZFVLSKHNRLANCNFSM4R7424ZQ).

[johanjongsma]

Hi, I got some bad news; my Unifi Dream Machine Pro crashed AGAIN, and I lost all DHCP IP assignments (AGAIN). They are not being back-upped by Ubiquiti. None of this involves you, but I wonder if you could make the config file based on MAC-address instead of IP. That would at least prevent this issue from happening for a third time. Do you think it can be done? Thanks, Johan

[sbidy]

To switch to MACs is not possible because of the UDP connection to the bulb. But I've added the discovery function to the pywizlight 0.3.4. In the next (v 0.1) version a auto-discover of the bulbs will be introduced. But currently there are some problems with the HA ConfigFlow.

For now you can run this as an python script. This script should return all IPs of all bulbs in your Network (layer 3 boundary).
This should help you to setup your environment again:

First made a pip install asyncio-dgram pywizlight

import asyncio
from pywizlight import discovery, wizlight

async def test():
  bulbs = await discovery.find_wizlights(discovery)

  for bulb in bulbs:
      print(bulb.ip)

asyncio.run(test())

This should return a list with all IPs of all bulbs.

[johanjongsma]

I was more referring to some reverse lookup, where you would match the IP corresponding to the MAC-address and then use that for the UDP connection. [Johan Jongsma - Chat @ Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=qfros) [qfros] On October 19, 2020 at 7:26 GMT, Stephan Traub <[email protected]> wrote: To switch to MACs is not possible because of the UDP connection to the bulb. But I've added the discovery function to the pywizlight 0.3.4. In the next (v 0.1) version a auto-discover of the bulbs will be introduced. But currently there are some problems with the HA ConfigFlow. For now you can run this as an python script. This script should return all IPs of all bulbs in your Network (layer 3 boundary). This should help you to setup your environment again: First made a pip install asyncio-dgram pywizlight import asyncio from pywizlight import discovery, wizlight async def test(): bulbs = await discovery.find_wizlights(discovery) for bulb in bulbs: print(bulb.ip) asyncio.run(test()) This should return a list with all IPs of all bulbs. — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](https://github.com/sbidy/wiz_light/issues/38#issuecomment-711748632), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AKWAGIDUCNNP23ERJ27GNFTSLPSY3ANCNFSM4R7424ZQ).

[sbidy]

No, this makes no sense to me if I can get the IPs/MAC via discovery. If I configure the bulb manually I should know the IP or made a reservation in the DHCP.
If you need such a kind of lookup you can implement this by your own with the pywizlight and a ARP implementation for python.

[johanjongsma]

Please look at this from a distance: I have over a 100 lights, which I control using their IP-number. BUT now I lost the IP-numbers again, and it is a lot of work to match each light to their new IP, where the MAC is still stable. That's why it is more stable to reference to a light using its MAC instead of the IP. The discovery makes it somewhat easier, although I could already get a list of all the IPs of the Wiz devices in my router. The problem is the match between the IP and the light. Best, Johan [Johan Jongsma - Chat @ Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=qgwdh) [qgwdh] On October 19, 2020 at 15:40 GMT, Stephan Traub <[email protected]> wrote: No, this makes no sense to me if I can get the IPs/MAC via discovery. If I configure the bulb manually I should know the IP or made a reservation in the DHCP. If you need such a kind of lookup you can implement this by your own with the pywizlight and a ARP implementation for python. — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](https://github.com/sbidy/wiz_light/issues/38#issuecomment-712252917), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AKWAGIBBJBISK3XF2KMKSB3SLRMWVANCNFSM4R7424ZQ).

[sbidy]

OK, fair argument. So I will looking forward to push souch a function in the next version.
The idea is that you can define a Mac or IP in the config.yml.

P.S.: you should consider a new DHCP server system 😉

[johanjongsma]

Totally agree on the DHCP; I already did some research but cann't really find something. ISC DHCP is still a LOT of manual work, even with webmin. Any suggestions? DHCP's generally give the same IP to a device over and over; but - as far as I can find - they don't back that up. [Johan Jongsma - Chat @ Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=qgzy8) [qgzy8] On October 20, 2020 at 6:19 GMT, Stephan Traub <[email protected]> wrote: OK, fair argument. So I will looking forward to push souch a function in the next version. The idea is that you can define a Mac or IP in the config.yml. P.S.: you should consider a new DHCP server system 😉 — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](https://github.com/sbidy/wiz_light/issues/38#issuecomment-712621469), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AKWAGIBEK2FFUOD5RWZKYT3SLUTYNANCNFSM4R7424ZQ).

[johanjongsma]

Stephan, I dont know what the H*CK happened, but nothing works anymore, even the command: echo '{"method":"getSystemConfig","params":{}}' | nc -u -w 1 $line 38899 returns nothing on all my lights! The app still works; all the light have an IP of maximum 8 hours ago. Any idea? Please help; it is very important to me. Johan WhatsApp +17272252475 [Johan Jongsma - Chat @ Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=t3zg8) [t3zg8] On October 20, 2020 at 6:19 GMT, Stephan Traub <[email protected]> wrote: OK, fair argument. So I will looking forward to push souch a function in the next version. The idea is that you can define a Mac or IP in the config.yml. P.S.: you should consider a new DHCP server system 😉 — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](https://github.com/sbidy/wiz_light/issues/38#issuecomment-712621469), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AKWAGIBEK2FFUOD5RWZKYT3SLUTYNANCNFSM4R7424ZQ).

[ChrisLizon]

@johanjongsma I find that on my system NC does not work as expected with the echo command. Instead, I run the command

nc -u -w 1 $line 38899

and then paste in the value I want to send to the bulb.

{"method":"getSystemConfig","params":{}}

I would ensure that the IP address that $line refers to is responding via ping first.

Probably not of much value to you, but I run Active Directory on my home network, it does DHCP and DNS really well 😁

DHCP servers will only re-assign the same IP address if the device requests an IP during the original DHCP lease expiry window. On my server that is 11520 minutes or 8 days. If your device is offline for longer than the DHCP lease timeout (or your database gets wiped out) there is no guarantee that the device will get the same IP address.

You should look at setting a DHCP reservation on your server, that way you guarantee that the device will always get the same IP unless your dream machine gets factory reset for some reason.

If you are looking to switch and use another device for dhcp, I have had good success using dnsmasq for dhcp and dns on my network before I set up AD.

I personally also have a spreadsheet of all my network devices, their MAC addresses, and my desired IP address.

[sbidy]

@ChrisLizon thanks for the feedback. We also implement a discovery function to the pywizlight library. I'll lock forward to have this as "auto discover" feature in HA do trigger a IP address walk thorough the network.

Hint: Have a look into the pywizlight CLI - here you can do an discovery via CLI

[johanjongsma]

This is NOT a DHCP related problem; it was the only way to get in contact with you.

AGAIN: the app works fine; the integration (and the command line) does not return anything.

Maybe my lights were updated by Wiz/Philips?!

Johan

[ChrisLizon]

@sbidy discovery will be a nice feature for sure, but from what I can see it will only support the local subnet. Great for 99% of users, but not for us oddballs who run their IoT devices on a seperate subnet/vlan/SSID from the Home Assistant Server. Hopefully with the new ConfigFlow and UI configuration it will still be possible to list IP addresses, or specify a subnet to scan.

[ChrisLizon]

@johanjongsma It's possible it's still a DHCP issue. From what I can tell, when you bulb connects to your WiFi it will phone home to the Wiz mothership in the cloud and check in, this will include the local IP address I would assume. (Everything is encrypted with TLS, so I'm not 100% sure). When your app connects to the cloud, it can get the new local IP addresses for your bulbs in order to maintain local control. So that may be why your phone app is working, but your integration is not.

Are your bulbs responding to Ping on the expected IP addresses?

[johanjongsma]

@ChrisLizon Please see the screenshot. This is one of my over 100 lights. It can still be controlled by the app; it does not respond to ping on the IP-number. Note that Group ID and Last sync are empty.

Johan

[johanjongsma]

I did a full reset of my whole network; Some lights are coming back now. Maybe it was related to Unifi.

[ChrisLizon]

I am not sure what would cause that. I suppose an OTA update is possible.

You should check in the settings for your Wiz Home settings and make sure that "Allow Local Communication" did not get disabled accidentally.

I do not know if it is of value, but my group number and Last Sync values are blank on both of my bulbs as well.

[Seba-VT]

Hi, first of all, thanks for creating this amazing integration. You are making a great contribution to the community.

I'm having the same issue as @johanjongsma with the color mode report.
This is what is happening:

• The light is on "color_temp" mode and Home Assistant is reporting the brightness and temperature as it should, if any of those values changes, Home Assistant updates the changes to the UI.
• If I change from "color_temp" to "hs" mode, Home Assistant reports the change and also updates the values if those are changed.
• Now if I change from "hs" to "color_temp" the bulbs change as they should BUT, Home Assistant will continue to report the last value from "hs" mode.
• The only way to get Home Assistant to report the "color_temp" mode again is rebooting the server.

I'm creating dynamic scenes and I need to know if the lights are being changed by external sources (like the app, remote or lovelace) in order to stop the scenes. I'm able to detect if the lights are being changed while they are in "hs" mode, but if they are changed to "color_temp" mode I'm not able to do that anymore.

Is there any way to work this around?

thanks!

[Seba-VT]

I found that @emichael fixed the issue here: https://github.com/emichael/wiz_light/tree/patch-1 if some one still looking for the solution.