It's not connecting, just shows the window with nothing in it.

[Reid29]

I have an elgato key light and even after resetting it still won't show up, I can connect to the wifi network but that still doesn't make any difference. I'm on pop-os 20.10 with an Nvidia 1050 ti on 510.54 drivers, It's probably just some stupid setting on my end but if you don't mind any help would be greatly appreciated.

[justinforlenza]

Hello,

Just to confirm, which model of key light are you using?

Additionally are you running any sort of firewall on your system? Someone had a similar issue in #16, and it had to do their firewall settings

[thestonewell]

I debugged a similar problem (and it may actually be the same problem). No lights where showing up for me. It turns out that it is an issue where the underlying problem start me having a dual stack of IPv4 and IPv6. Both me local PC that I want to use as the controller as well as the key lights have v4 and v6 IP addresses.

From the shell avahi-browse _elg._tcp lists the lamps, e.g.

+ enp3s0 IPv4 Elgato Key Light Air 8DB4                     _elg._tcp            local
+ enp3s0 IPv6 Elgato Key Light Air 8DB4                     _elg._tcp            local
+ enp3s0 IPv4 Elgato Key Light Air 7318                     _elg._tcp            local
+ enp3s0 IPv6 Elgato Key Light Air 7318                     _elg._tcp            local

Note that this was a positive result and the lights responded on v4 AND v6.

More often then not I found that they just respond on IPv6, e.g. just

+ enp3s0 IPv6 Elgato Key Light Air 8DB4                     _elg._tcp            local
+ enp3s0 IPv6 Elgato Key Light Air 7318                     _elg._tcp            local

This then turns out to be the root cause as the library bonjour used in the code a) sends the query on both IP stacks, but b) just listens for responses on IPv4 not IPv6. You could argue that is a bug in the lights and they should always respond on both stacks but since we cannot change the lights firmware we have to change this code.

I have further tried different implementations of bonjour (also called ahavi, mdns, zeroconf). Unfortunately, neither

"multicast-dns": "^7.2.4",
"@gravitysoftware/dnssd": "^0.5.3",
"bonjour": "^3.5.0",

listen to IPv6 responses.

Giving up for now to solve this with Node.

as hint, using Python and modified version of https://github.com/jstasiak/python-zeroconf/blob/master/examples/browser.py I can reliably find the lights all the time. Looks like:

from zeroconf import IPVersion, ServiceBrowser, ServiceStateChange, Zeroconf, ZeroconfServiceTypes

class MyListener:

    def remove_service(self, zeroconf, type, name):
        print("Service %s removed" % (name,))

    def add_service(self, zeroconf, type, name):
        info = zeroconf.get_service_info(type, name)
        print("Service %s added, service info: %s" % (name, info))

    def update_service(self, zeroconf, type, name):
        info = zeroconf.get_service_info(type, name)
        print("Service %s added, service info: %s" % (name, info))

zeroconf = Zeroconf(ip_version=IPVersion.All)
listener = MyListener()
browser = ServiceBrowser(zeroconf, "_elg._tcp.local.", listener)
try:
    input("Press enter to exit...\n\n")
finally:
    zeroconf.close()

[aaroncampbell]

I'm having the same issue of an empty window showing even though my light seems like it should be discoverable:

aaroncampbell@Campbell:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.10
Release:    22.10
Codename:   kinetic
aaroncampbell@Campbell:~$ avahi-browse _elg._tcp
+   eno1 IPv6 Elgato Key Light Air 1D8B                     _elg._tcp            local
+   eno1 IPv4 Elgato Key Light Air 1D8B                     _elg._tcp            local