Do you need someone to take over the project?

[Sawtaytoes]

From looking at the Git branches, there was work done to create a newer version in 2017. This work was never completed, and any merged pull request since 0.8.0 haven't been deployed to npm.

I use this software to control the lights on my home network and still think it's the best solution out there. Sadly, without these changes, updates, and security fixes, the library will eventually become useless.

Either I could take over this project myself, or I could create my own. You've gone through a considerable effort building out this library, I think rewriting it myself would be a waste of time when you've already produced a substantial amount of work.

[ristomatti]

@Sawtaytoes Agree with the state of the repository. @MariusRumpf said to me he does not have time to maintain the project ~2 years ago and gave me the rights to merge PR's, but I cannot publish any update to npm so it is quite pointless. I have considered forking and creating a compatible npm package with a new name but unfortunately I would not have time to maintain it at the current time anyhow.

When considering forking this I believe it would be important to try to maintain backward compatibility as much as possible. Based on the list of dependents https://www.npmjs.com/browse/depended/node-lifx I think it would be beneficial if the forked version could be used as effortless replacement (at least initially).

But if you do consider doing this, I suggest basing the work over my branch es2015-dev here https://github.com/ristomatti/node-lifx/ ... It has many of the open pull requests merged and to my knowledge is the most up-to-date substitute for this. I use it myself on my Node-RED based home automation setup with my fork of https://github.com/jdomeij/node-red-contrib-node-lifx (as node-red-contrib-node-lifx also seems to be abandoned).

[Sawtaytoes]

@ristomatti Thanks for your response. The only way that'd be possible is if we had publishing rights to npm. Otherwise, we would need to publish this as a brand new library on npm.

npm supports creating "organizations". That way, any number of people on that team can publish it:

You don't even need to change the npm name. I was able to add lifx-halloween to that organization:

It's also possible to invite maintainers for a single package:

[steve2507]

Myself, I have moved to the https://github.com/futomi/node-lifx-lan package . It support promises, and is much faster when updating lights.

Turning multiple lights on simultaneously with the node-lifx package ended up with delay between each light for me. With node-lifx-lan, I have no such issue.

[ristomatti]

@Sawtaytoes I also agree that the proper way these days in overtaking maintenance of an open source project is to create a GitHub (and a NPM organization if applicable). This would however require the npm publish rights for the node-lifx package.

@steve2507 I've also been watching the repo although I haven't had the time or need to test it as the current combination of node-lifx and node-red-contrib-node-lifx (my own fork of both) works almost perfectly to my purposes at the moment. I agree the API is nicer and the developer seems active so I definately would recommend using it as the basis for new projects. The problem is node-lifx is still widely used so it'd be nice to get it up-to-date.

BTW. PR #60 solves node-lifx's delay when switching multiple lights at once. @MariusRumpf had missed the fact in the protocol specification that the minimum delay between each packet sent is per device and not per sender. Changes done there create a separate sending queue for each light.

Another PR #61 allows stopping the discovery process when each of the lights predefined in the initialization have been found. This helps with lights "going offline" when the constantly running discovery process might not occasionally get a response from all lights.

I've also done some prototyping with multicast sending allowing to change all lights at once (similarly as how the official app does) and got it working but lost my interest in completing it as a properly implemented feature as I saw many of my old PR's waiting but also as changes done on #60 made changing all lights enough in sync to not bother me too much.

[Sawtaytoes]

@ristomatti My suggestion is to push up your version as node-lifx-rebirth (or whatever name you want) so people can just swap their old package with your new one.

If you eventually get access to node-lifx on npm, then you can update both.

[Kyry11]

I just discovered this thread.. after spending past 5 days fixing issues and making improvements to the published version on my local environment. I also discovered the single message queue issue and also introduced ability to stop/prevent discovery process.

One thing I don't believe that's been addressed by your work @ristomatti, is in multiple places there are calls to splice() on an array inside the forEach() callbacks on the same array. This will cause side effects. Also, using socket binding (socket.on('message', )) as main trigger to process all handlers seems a bit too coupled. I was about to start introducing an 'incomingMessages' queue which would act as a buffer and have separate processing flow that wouldn't reply on receiving messages on the socket.

And then I discovered this thread :)

In my use case this library is used by the homebridge-lifx-lan package.

[ristomatti]

@Sawtaytoes Like I already mentioned, I have thought about it more than once but I haven't done it as since I last contributed to this project, my interests have expanded from automating lights to learning electronics (from scratch) to create all kinds of automation/monitoring related projects. I've managed to gather interest to so (= too) many different topics I'm trying to learn and do at the same time that it'd be nearly impossible for me to give enough time to maintain a specialized library such as this.

If you or someone else is interested in taking off from where I left, please do so. I was merely expressing my wish to continue from that point instead of the state of this repository. Also since @MariusRumpf seems to want to keep distance to the repo, if I see some convincing effort from someone's fork, I can for example help spreading the word and push a deprecation notice on the README.md suggesting to shift attention to a another repo/package which can be used as a drop in replacement. This is of course if my collaborator rights are still valid by then.

Also if such a fork is setup, I want to express my wish to become a collaborator but only if it is set up under a dedicated GitHub organization to reduce the risk of the project being abandoned again. I've been playing around with an idea of an organization account which could also possibly take care of maintenance of projects depending on node-lifx such as jdomeij/node-red-contrib-node-lifx and similar. I have no idea what @jdomeij thinks about this but I remember him also commenting the lack of time maintaining his module.

[ristomatti]

@Kyry11 To be perfectly honest, I never felt very comfortable doing changes to this repo as I had difficulties understanding the architecture as a whole. Since then I've worked full time with (among other things) TypeScript and also done some personal projects involving UDP packetes so not sure if I would be so uncomfortable anymore. But if I would have continued my work, I would have most likely converted the project to TypeScript and start refactoring the internal engine into something that made more sense to me.

Shortly put - there's a ton of things that could be improved, simplified and made easier to understand (subjectively at least). It would be fun to do so, but currently the other stuff I'm working with come first. With this said, LIFX products are still play a big role (and are the most used) part of my automation setup. I have around 20 lights in total, covering the whole EU product line (except for the Beam which I am not interested in). I am not 100% happy on how reliable the setup is but with the modifications I've done on node-lifx, it's much more common for the other parts interacting through it that cause the issues.

If I was asked what I personally would like to see improved in node-lifx (from the user perspective) is to allow to completely override the discovery process with a predefined list of IP's/MAC addresses of the available lights. I believe this way the lights would instantly available for use without the delay caused by the discovery process. I've noticed that even though a certain light might not appear online to node-lifx, it will still work fine from the mobile app. Sometimes it's vice versa. Since there's no session or authentication in the UDP messaging, any device can send a packet to any light without checking if it's available or not.

As a tip: a lot can be learned by looking at the source of actively maintained mclarkk/lifxlan. There is (or was) for example a feature to send a color change multiple times in a quick sequence to make sure all the target lights get the message. Since UDP has no acknowledgement of the packets, this could be one approach to improve the likelihood lights even on the edge of WiFi coverage would respond to the change.

Other core features that are missing are sending multicast packets (to change all lights at exactly the same time with a single packet) and the ability to address the predefined groups.

The predefined groups seem to me a very obscure thing to be part of the actual hardware design as the protocol documentation itself says the client application is responsible for sending each message individually. What this means is that the groups seen on the app are basically an articial limitation at the current time. I have been in contact with LIFX support countless times to suggest improvements on the app (some of which you might have noticed if you've had LIFX products for several years). One suggestion that has not been implemented is the ability to have virtual groups of lights. I still use the app a lot myself but would like to be able to create groups not only based on roosm for example but also by the type of light or the physical location (on the ceiling, indirect light directed on the walls etc.)

During the years a lot of such ideas have been floating inside my head waiting for the time and inspiration to start implementing them. One of my recent ideas has been to create a dedicated remote control for the lights using encoders, sliders and multi step switches. I've built some prototypes using MQTT messages which are processed in Node-RED (and send via node-lifx). This setup has many failure points though and introduces unnecessary delays, so I've been looking at sending the UDP packets directly from the ESP32 microcontroller. This project is on hold likely until winter though as during the summer I like to spend time improving automation setup at our family summer cottage. 😎

[Sawtaytoes]

@Kyry11 @ristomatti Between the two of you, who's got the most up-to-date repo?

I'll copy your repo and create a brand new one. Then I'll create an npm org to take care of it as well as a GitHub org if I can. That way, we can finally have a newer version for everyone's use.

If was going to write this myself, the code would look completely different, and I would only add the features I need. To save me a ton of time rewriting my own code to make UDP calls, I'll rely on whomever's node-lifx library provides the best fork.

The license is MIT, so all I have to do is credit @MariusRumpf and link back to this version as the archived version. Then @ristomatti can refer everyone to the new package on npm.

What do you guys think?

[Sawtaytoes]

Actually here, it's done: https://github.com/node-lifx/node-lifx-rebirth

@ristomatti Invited you to the GitHub org node-lifx. There are two PRs to merge. One is your es2015-dev branch and the other is one where I updated all npm vulnerable dependencies.

If those get merged into master, I'll go ahead and deploy version 1.0.0 to npm.

[ristomatti]

I didn't realize I have access to close the issue. The forked project can be found at https://github.com/node-lifx/lifx-lan-client. It's currently primarily maintained by myself. However, help would be needed there as well. I don't have access to any of the newest devices to test nor do I have a lot spare time.