A19 bulb not visible

[zenoran]

I have everything working with other bulbs but I have one A19 bulb which doesn't seem to recognize. I verified the IP and within the router and tried restarting it a few times but no luck getting it to recognize within node-red. I noticed it might have been added recently within the lifx-lan package so does something have to be done on this end to recognize the bulb as well?

[ristomatti]

Could you check the model name and firmware version from the app? Is it the only A19 bulb you got or one of multiple you've bought at the same time?

[zenoran]

Ya, I only have one of them but it seems to work fine from the App. I had it working with the Hubitat addon as well but was trying to avoid using that since I think it's clouding my hub with too much activity.

Firmware: v2.8 Model: LIFX (A19)

On Thu, Oct 28, 2021 at 2:57 PM Ristomatti Airo @.***> wrote:

Could you check the model name and firmware version from the app? Is it the only A19 bulb you got or one of multiple you've bought at the same time?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ristomatti/node-red-contrib-node-lifx/issues/14#issuecomment-954115414, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABV75BIHYU4OGARJVLPEZELUJGTKFANCNFSM5G5SUEAA .

[ristomatti]

You might be correct in that it appears I have forgot to explicitly upgrade the lifx-lan-client dependency and that the newer version has an up-to-date products.json. However a semantic version is used for the lifx-lan-client dependency, so "^1.0.3" should automatically install the newest version in this case. This of doesn't happen automatically of course.

Before doing anything, could you try running npm ls lifx-lan-client under your Node-RED home dir (~/.node-red typically)?

[ristomatti]

It should show the version of lifx-lan-client currently in use. If it's 1.1.0, then you're already running the newest version. If it's older, I belive it should get updated if you just reinstall this package with npm install node-red-contrib-node-lifx.

[zenoran]

Ya, it did install the correct version. It shows 1.1.0 on my node-red container. Also worth noting I was having difficulty getting the auto discovery to work for the other bulbs. I'm assuming it's because of docker though? As long as I put the bulb IPs in the server config the others seem to work fine... it's just this one which won't recognize. I've even tried putting the MAC address in the ID field but no go. I can probably try using lifx-lan-client directly to see if it works but I haven't gotten as far as trying to figure out how to do that.

On Thu, Oct 28, 2021 at 3:19 PM Ristomatti Airo @.***> wrote:

It should show the version of lifx-lan-client currently in use. If it's 1.1.0, then you're already running the newest version. If it's older, I belive it should get updated if you just reinstall this package with npm install node-red-contrib-node-lifx.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ristomatti/node-red-contrib-node-lifx/issues/14#issuecomment-954130428, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABV75BKYOPXI6DOZGQPHUMTUJGV35ANCNFSM5G5SUEAA .

[ristomatti]

You could try if lifx-lan-client detects the light when broadcast packages can get through (Docker could very well block them). I've created a CLI client for my personal use that also uses lifx-lan-client. It will immediately run the autodiscovery and list the lights it finds. You can install the latest version with npm install -g ristomatti/lifxsh#dev (it's also on npm but this will install a newer version from my GitHub dev branch).

You'll find the rest of the instructions here https://github.com/ristomatti/lifxsh/tree/dev

[ristomatti]

...note that if you've got firewall enabled on your computer, it can also block the broadcast packages. In case you do, you'll need to open UDP port 56700 for incoming packages (or allow the app specifically).

[zenoran]

...note that if you've got firewall enabled on your computer, it can also block the broadcast packages. In case you do, you'll need to open UDP port 56700 for incoming packages (or allow the app specifically).

Thanks I'll try the CLI out that looks a bit easier to work with.

I do realize the docker setup is breaking auto discovery since the local docker network isn't the same subnet as my lights are on. I wasn't sure how to fix that issue so I've been adding the IPs manually. If there was a firewall issue I'm sure the other lights wouldn't be working either?

I'll have some more time to play around with it tomorrow and I'll report back if I find anything. It's just very strange this one model of light is the only issue.

Thanks!

[ristomatti]

I do realize the docker setup is breaking auto discovery since the local docker network isn't the same subnet as my lights are on. I wasn't sure how to fix that issue so I've been adding the IPs manually.

I believe running Docker with the --network host switch (or setting network: host in a docker-compose.yml file) should do the trick. It will run the container on the host's IP address/network. Caveat: It has it's downsides thought, you then won't be able to connect as easily to other containers you're possibly running on the same network. It probably has some security implications also if you're running the container on a host that's accessable from the internet.

Also, if you happen to be running Node-RED on a Home Assistant OS, I have no clue if you can even change that.

Personally, I run pretty much everything related to my home automation in Docker containers but I prefer running Node-RED directly on the host. I guess it's mostly to give a bit more direct access for experimenting things.

[zenoran]

I appear to have resolved the issue. Thank you for the discovery client; that helped troubleshoot. My issue was directly related to my AP/router (UniFi) which was apparently blocking multicast capabilities as a default setting.

[ristomatti]

Thanks for the update.