How to use the node for receiving Art-Net packets? about go-artnet HOT 10 CLOSED

Nothing too helpful; I'm seeing the same error (unexpected EOF) with an MA system @jsimonetti, guess the changes we made to the packet parsing weren't enough to support all cases, although we're kind of strictly following the specs (Protocol v4).

First thing I found, the artnet package running inside of the DMX Sequencer isn't implementing the full spec and doesn't implement ArtPoll & ArtPollReply packets: https://github.com/hobbyquaker/artnet/blob/master/lib/artnet.js
But the ArtDmx packet in the js lib seems to be okay.

from go-artnet.

I made WireShark package captures of both use cases (GitHub allows uploading .txt only so please rename after downloading: *.pcap.txt -> *.pcap):

mqtt-dmx-sequencer.pcap.txt

qlcplus.pcap.txt

MQTT DMX Sequencer seems to be more buggy:

Beside the errors I'm still searching for an example on how to use this module to extract the DMX data received over Art-Net.

Thanks!

from go-artnet.

Does the error unknown packet type with Q Light Controller Plus come from:

... where the packet.ArtDMXPacket case is not handled and QLC+ sends ArtDMX packets?

Am I right that in order to extract the DMX data I need to implement my own node?

from go-artnet.

I've extended the handlePacket() to call a custom callback with the DMX data (see https://github.com/NIPE-SYSTEMS/go-artnet/commit/8ef30c3e4cf5db7f70bcecb7f25654da3cbdfa53).

What do you think? Should I make a pull request? Or do you want some other way to extract the data? I'm not sure If mine is a good approach...

from go-artnet.

Hi,

Your approach is similar to how I envisioned it to be when I built this package.
I never got around to actually creating the Node side of things as I have only used the controller part.

I did want to make the callback more general and add a map[Opcode]NodeCallbackFn where type NodeCallbackFn func(p *artnet.Packet) error.

This will make the implementation more robust and even allows overriding the built-in OpPoll and OpPollReply methods.

If you feel like you could contribute such a thing I would be very happy to merge it.

Cheers,
Jeroen

from go-artnet.

Just as another idea, would passing over a channel chan *artnet.Packet be a bit more flexible? In this case the node itself doesn't have to think about whether to call the callback async with go callback() or synchronously, right?

from go-artnet.

@jsimonetti Thanks for your answer, your more general approach is a good idea! Maybe I find time in the next days to improve my code and request a pull.

@apinnecke With chan *artnet.Packet, then the user switch-cases the packet type? What about channel capacity and blocking/non-blocking writing? What might be a sensible default for ignoring user packet handling? A mix between your both ideas might be a map of channels?

from go-artnet.

@apinnecke I really dont like APIs that exposes channels. It forces the lib to do to many things and be smart where it shouldnt (buffered vs unbuffered channel, how big a buffer, etc)

If we have a map of callback functions, all that logic can be done in the users code, if it is applicable for the OpCode. For example, pushing a firmware upgrade might block all other processes for a reason, but a simple artdmx packet should not.block

So I really prefer using a map where the library users just hooks into at spots where it wants too. The map can be made readonly (using a callback register function) once the node is started, so we dont need any locking with a mutex or a goroutine.

As for the actual call to the callback we do that sequentially in the handlePacket() function. If the library users want asynchronous behaviour, it can launch a goroutine itself. If it wants a blocking operation, it can do so aswel, so we leave that choice up to the library user. (If the library launches the callback in a seperate routine, we make blocking callbacks imposible).

from go-artnet.

That makes perfect sense for me, the different handling of opcodes is more than reasonable. Thanks for clarification! 💪

from go-artnet.

I think the unexpected EOF error is due to the way we unmarshal ArtDMX packets. We use the binary.Encoder implementation from the stdlib and assume an ArtDMX packet always contains all 512 channels. In reality, the ArtNet4 Spec allows for smaller ArtDMX packets where only the first changed channels can be sent.
The length of the ArtDMX channel data is specified using a LengthHi and a LengthLo bit.

In the case of MQTT DMX Sequencer the length is said to be 512, but it actually only contains 16 channels. So when it comes to that example, the packet is just malformed (too short).

Fixing go-artnet to actually do correct unmarshaling of ArtDMX packets would not have fixed this specific example. It will also require a fix in MQTT DMX Sequencer to produce correct packets.

from go-artnet.