added multicast reception in the udp effect #675

Merged
merged 24 commits into from Jun 4, 2016

Projects

None yet

3 participants

@penfold42
Contributor

the default udp.json will listen to unicast on port 2391 (as it used to)

the new udp-mcast.json will listen on multicast 239.255.28.01:2801 (but can be changed easily)

penfold42 and others added some commits Apr 2, 2016
@penfold42 penfold42 Merge pull request #9 from tvdzwan/Beta
updating
750e3d7
@penfold42 penfold42 Removed -HUP so the default -TERM signal is sent instead.
- hyperiond only listens for TERM and INT. HUP is often used to get an exe to reread its config

Changed pgrep to add '-x' so it wont partial match on the exe name.
- I have multiple instances with multiple hyperiond-instance1 names
- this ensures the service script only kills the right process
006f49d
@penfold42 penfold42 reversing errant change to hyperion.systemd.sh dc12495
@penfold42 penfold42 Merge pull request #10 from hyperion-project/Beta
updating from Beta
736b369
@penfold42 penfold42 Merge pull request #11 from hyperion-project/master
Updating
18ed83b
@brindosch brindosch Merge remote-tracking branch 'refs/remotes/origin/Beta' 21a4f0c
@penfold42 penfold42 Merge pull request #12 from hyperion-project/master
updating
882be0a
@penfold42 penfold42 Merge pull request #13 from hyperion-project/Beta
updating from Beta
2aefc0c
@penfold42 penfold42 Merge pull request #14 from hyperion-project/Beta
Updating from Beta
658be7d
@penfold42 penfold42 cleaned up a couple of compiler warnings e9ac1da
@penfold42 penfold42 moved bitpair_to_byte initialiser to (hopefully) work with older GCC 46de806
@penfold42 penfold42 compiler warning in udp driver
removed some tabs in ws2812b.cpp
ba84e85
@penfold42 penfold42 formatting - spaces to tabs d676703
@penfold42 penfold42 Merge pull request #15 from hyperion-project/Beta
updating from Beta
62c511a
@penfold42 penfold42 moved rpi_281x to tag sk6812-v1.0 9ac9450
@penfold42 penfold42 moving to my fork of rpi_281x 95d75e1
@penfold42 penfold42 Merge pull request #17 from hyperion-project/Beta
updating from Beta
2e80c1a
@penfold42 penfold42 Merge pull request #18 from hyperion-project/Beta
Updating
0ab494a
@penfold42 penfold42 Merge pull request #19 from hyperion-project/Beta
updating from Beta
9383da4
@penfold42 penfold42 removed dos line endings 9518ba2
@penfold42 penfold42 Found some more "dos" line ending files c82b9ca
@penfold42 penfold42 Added multicast support to the udp listener "effect" 8791f1d
@penfold42 penfold42 the default udp.json will listen to unicast on port 2391 (as it used to)
the new udp-mcast.json will listen on multicast 239.255.28.01:2801
ec9f6f6
@penfold42 penfold42 Merge pull request #20 from hyperion-project/Beta
updating from Beta
d4c2e78
@brindosch
Collaborator

Thank you, can´t wait to see what we will get next :)

@brindosch brindosch merged commit 5c76fab into hyperion-project:Beta Jun 4, 2016
@brindosch
Collaborator

@penfold42
another question, makes it sense to add these udp listener to the booteffect array at the config (and Hyperion)? You can´t use both. Maybe to add a additional array would make sense?
Not sure where are the programming edges here.

@penfold42
Contributor

I'm not sur I understand your question

@brindosch
Collaborator

ah!
this is like the receiver from proto/json just for udp and you will se also a booteffect at this device if the "sender" sends it?

@penfold42
Contributor

Yep

It effectively turns Hyperion into a UDP driven led device just like my ESP8266 based wifi receiver.

I had 3 Pi's running the multicast effect and a perl script running on a 4th device sending 3 bytes per led (RGB) data over multicast to all Pi's at the same time.

My perl script/4th box could just as easily be a another Hyperion set up to use the UDP led device type

@brindosch
Collaborator

@penfold42
the idea is to refactor this to a UDP receiver (like "Boblight Server")
As part of a cleanup - this is a "misused" option (booteffect array)

@penfold42
Contributor

I don't know what a booteffect array is.

We could write a native built in QT based UDP receiver if there's enough demand.
It could be implemented as a boblight level thing or we could consider it as a grabber

@brindosch
Collaborator

you use this

    "bootsequence" : 
    {
        "color" : [0,0,0],
        "effect" : "Rainbow swirl fast",
        "duration_ms" : 3000,
        "priority" : 700
    },

Which is a little bit "misused"
A general udp receiver component like this:

    "udpServer" : 
    {
        "port" : XXXXX
    },

would be cleaner

@penfold42
Contributor

I havent been using it as a boot effect (although you could)

I've just been using Hyperion-remote when I need the UDP listener running

@brindosch
Collaborator

Yeah the handling could be "better" :)

@redPanther
Contributor
redPanther commented Jun 5, 2016 edited

hope to clear this conversation a bit:

current state of "udp listener":
its implemented as effect. This means it is absolutely OK to use it on every place where effects are usable - that includes the bootsequence of course.
If this effect should have some different handling than the other effects (e.g. own section in config), than we build an inconsistency in effect handling. I'm voting against that special treatment!

But yeah something is wrong here:
an effect uses setcolor/setimage to tell hyperion how the leds should glow. The udp effect is be definition an effect, but it does to much. It takes network input and then send it to lights. If we wouldn't have json- proto- boblight server, I would say all things are right.
But we have already codeparts that makes network to light. The new "network to light" function for udp protocols should be implemented in the way how any other "network to light" stuff in hyperion.
=> @penfold42 realized this already

It could be implemented as a boblight level thing

and have the right solution (please don't do this as grabber, thx). Thing is, doing this in python as an effect is much faster (to develop), then doing this the clean way as own hyperion network service.

@brindosch brindosch modified the milestone: V1.03.0 Jun 10, 2016
@brindosch brindosch added the TESTED label Jun 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment