VL.KiNet

catweasel · January 8, 2026, 4:55pm

This is like artnet but for Color Kinetics lighting fixtures, its not fully featured, but is functional, with so far tested 500+ power supplies. No discovery, sync, or decoder, send only.

catweasel · January 9, 2026, 10:52am

Ah, I am getting issues when the remote host is not found, is there any way to avoid this?

When I use a more direct method than the one used by artnet it works, whether the receivers are there or not, I’d not like the patch to crash if a psu goes offline.

Is there a way of detecting whether a connection is made, like ping ( but not that, as it doesn’t like being called hundreds of times, or should I use an asyn loop/task for it?)

SocketException: “The requested address is not valid in its context.”StackTrace:System.Net.Sockets.Socket+AwaitableSocketAsyncEventArgs { private void ThrowException(System.Net.Sockets.SocketError error, System.Threading.CancellationToken cancellationToken) { … } }System.Threading.Tasks.ValueTask`1+ValueTaskSourceAsTask+<>c { internal void <.cctor>b__4_0(object state) { … } }System.Runtime.ExceptionServices.ExceptionDispatchInfo { public void Throw() { … } }System.Runtime.CompilerServices.TaskAwaiter { private static void ThrowForNonSuccess(System.Threading.Tasks.Task task) { … } }System.Runtime.CompilerServices.TaskAwaiter { private static void HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task task, System.Threading.Tasks.ConfigureAwaitOptions options) { … } }VL.Lib.IO.Socket.DatagramSender+<>c__DisplayClass7_1+<b__2>d { private virtual void MoveNext() { … } }

System.Net.Sockets.SocketException (10049): The requested address is not valid in its context.at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)— End of stack trace from previous location —at VL.Lib.IO.Socket.DatagramSender.<>c__DisplayClass7_1.<b__2>d.MoveNext()

tgd · January 9, 2026, 11:48am

maybe put it in a try catch region?

catweasel · January 9, 2026, 12:20pm

Good suggestion, unfortunately it stills throws errors. I do wonder whether its because it is using channels, I think they can’t be removed? I’ll try that, however on longer term usage with my dumber version, I get another error about the sufficient buffer space or queue being full, I’m guessing this might be a @Joreg question

SocketException: "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full."
    StackTrace:
        System.Net.Sockets.Socket+AwaitableSocketAsyncEventArgs { private void ThrowException(System.Net.Sockets.SocketError error, System.Threading.CancellationToken cancellation
Token) { ... } } 
        System.Threading.Tasks.ValueTask`1+ValueTaskSourceAsTask+<>c { internal void <.cctor>b__4_0(object state) { ... } } 
        System.Runtime.ExceptionServices.ExceptionDispatchInfo { public void Throw() { ... } } 
        System.Runtime.CompilerServices.TaskAwaiter { private static void HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task task, System.Threading.Tasks.Configur
eAwaitOptions options) { ... } } 
        VL.Lib.IO.Socket.DatagramSender+<>c__DisplayClass7_1+<<Subscribe>b__2>d { private virtual void MoveNext() { ... } } 


System.Net.Sockets.SocketException (10055): An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
   at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
--- End of stack trace from previous location ---
   at VL.Lib.IO.Socket.DatagramSender.<>c__DisplayClass7_1.<<Subscribe>b__2>d.MoveNext()

catweasel · January 9, 2026, 1:12pm

Thought a patch might help, click the Old/New Iobox to show the issues with the new version

KinetIssues.zip (150.7 KB)

joreg · January 9, 2026, 10:28pm

i’m afraid i find this a bit hard to follow havig never heard about “Color Kinetics lighting fixtures” (is there a spec of their protocol? what does set them apart from artnet?)

what makes me wonder from your patch though: the ArtNet Send node has an option input of Remote Host and Port which you removed. i think this is exactly what you want to use. the ArtNet/KiNet node is not meant to be used in a loop since it binds to a local socket. so leave that main node out of the loop and then use the Send node with the optional Remote Host/Port inputs inside the spread.

does that help?

catweasel · January 10, 2026, 9:42am

Color Kinetics used to own the patent for RGB led lights, and KiNet was their propriety protocol for controlling them. They are still a big name in architectural lighting. I’m trying to rebuild a patch I made for an installation n 2014 that generated an image to be pixel mapped by a hardware pixel mapping box they made, the installation has gone through 2 of the hardware controllers, while my patch remained fully functional, hats off to vvvv beta! The installation in being refreshed as some of the power supplies and pixels have also failed, and I now need to talk directly to the power supplies. Kinet is different from artnet in that you can send less than a full universe of pixels, and also each power supply can have 2 outputs, called helpfully also called ports.

I do have the spec’s but don’t have a link as it was provided by my client, via CK.

TBH I removed the select target while trying to get it working, and once I had forget that I’d removed it, and having opening the artnet help patch I can see my mistake with the node outside of the loop. Thanks!

It has stopped complaining about the sockets from the start, but Unfortunately after 5-10mins the patch does start to complain about the socket again and then crashes.

KiNet_issues_2.vl (392.0 KB)

antokhio · January 10, 2026, 10:41am

Is there any pdf or link with protocol description?

catweasel · January 10, 2026, 8:05pm

@antokhio there is, but it wasn’t an online link, so I dont think I can share it publicly. The protocol works though, and having had thought that I hadn’t tested this many artnet universes I just swapped to artnet and I get the same socket error, I’d previously tested upto 300 artnet universes and this is 628. (also just tried halving the universe count, and it seems to work fine, then creating a whole copy of the halved count, so splitting the networking in 2 to see if having it run twice would fix things, and it doesn’t same error)

So it could be there is a hard limit, or it needs a different approach, but I think it will need one of the master magicians to exorcise the demons!

Why Does SO_SNDBUF Size Double? Explaining setsockopt and getsockopt Behavior in UDP Sockets — linuxvox.com leaving this here for reference

antokhio · January 11, 2026, 9:20am

Not sure if it’s a socket problem, you can try copy paste that somewhere:

And try play with socket on lower level…

catweasel · January 14, 2026, 12:08pm

Ok the problem is solved, by default both artnet and this kinet will send to the wifi as well as the dmx IP addresses, which is where the buffer issues come into play. There is a hidden pin for Local Address which needs to be made visible and set to your network adapters IP when you have a lot of universes!