Poste mal deine config (z.b. via pastebin). Da is definitiv die colorOrder falsch. Die muss wahrscheinlich bgr sein.
Da das ändern der colororder von dir keine wirkung hat, ist da bestimmt irgendwo nen tippfehler.
Denn das ändern dieses wertes hat immer eine sehr auffallende wirkung
You have to close connection after receiving.
... but be aware, there is less/no/faulty documentation and hypercon won't work, you have to compile and install by your self ... and user support is limited. If you want to develop, then you have to use h.ng, otherwise ... you can try, but if you want it easier, take stable hyperion ...
LedCount is more or less a 'nerd' option.
I only want to clearify that, so nobody tries 'leds' and than it doesn't work ....
We will update wiki when we realease hyperion.ng. Before it is sensless, because config could change to often. Thatswhy my hint to the schema files, so anybody get a clue whats possible.
When finished we will have a good doc ...
And yes it is good to write only things you need on your config. Missing params get default values
breite/höhe in dem fall ist die Größe des bildes welches der grabber liefern soll.
Also:
Jede Led hat einen bereich der in der config angegeben wird. Dieser Bereich wird nicht durch "harte pixel" sondern relativ angegeben. z.B. wenn du eine led den bereich 0.00/0.00 - 1.00/1.00 zuweist, dann nimmt diese led die durchschnittsfarbe von links oben bis rechts unten vom bild (also alles).
ein ledbereich von 0.00/0.00 - 0.50/0.50 ist das linke obere viertel des bildes. Es macht also schon sinn da nich 64x64 reinzuschreiben, sondern das an seine leds anzupassen.
in theory it could work (depending on how many leds you want and which bluetooth standard you use)
Zitat
Bluetooth 3.0 up to 24 Mbits/s (3 MB/s)
Bluetooth 2.0 up to 3 Mbits/s (400 KB/s)
Bluetooth 1.0 up to 700 Kbits/s (less than 100 KB/s)
my experience with arduino ethernet (via spi) was very bad - regarding transfer speed. It was absolutly ok to query sensors or so, but transfering high speed led data was a bad experience. Perhaps I done something wrong ...
anyway I'm cured from using arduino-ethernet+leds ...
> Maybe its handy to hardcode a --clear statemenat if we run --sourceoff
it's not handy, - in general - if "clear" calling is neccesary then there is a bug. Such workarounds you suggest will hide the real bug.
I don't know if you understand how the hyperion priority stack works ... here a basic introduction:
(picture from wiki)
there several input generators. E.g. every effect, grabber or static color is a input generator. This genrates a list of colors per led (led colors). The led-colors are put into another list. The list has 2147483647 slots for led-color lists. When no specific input is selected, the first list of led-colors is shown. (first means the list with lowest index).
"sourceOff" simply means show led-colors in slot 2147483647 The is the last led-color list and it contains black values.
I can reproduce the behaviour you discovered. This is definitly a bug. When a static color is set input source switching wont work as expected. (regardless if you want to switch to "off" source or e.g. "grabber" source)
when your setup is working, can you give feedback here? I'm interessted in how to setup the linux things, arduino code, the hardware you use and if the overall result is accaptable ...
you can create a serial port device from your bluetooth connection
e.g.: http://unix.stackexchange.com/…ooth-serial-port-on-linux
then use e.g. /dev/rfcomm0 as serial device and as type "adalight". Then for arduino use the adalight sketch
https://github.com/hyperion-pr…ino/adalight/adalight.ino
and modify it to use your bluetooth device ....
"leds" paramter is not correct. It is "ledCount" and is a general parameter that defines amount of physical leds. As penfold already said, this is only needed when you have more leds than configured in leds section.
If you have more leds than configured, then this option ensures that additional not used leds stay off and don't flash randomly due to electrical noise
If you want to know which options are valid look in schema files:
https://github.com/hyperion-pr…rion/hyperion.schema.json
and the leddevice section:
https://github.com/hyperion-pr…/libsrc/leddevice/schemas
... as addition, the args string must be in valid json form. If you get errors you can validate your string with a online json validator
hyperion-remote --effect 'name' --effectArgs '{ the whole args block without newlines and with your mofifications. }'
E.g.
--effectArgs '{ "speed" : 1.0, "fadeFactor" : 0.7, "color" : [0,255,0] }'
Kannst du nich einfach hyperion-remote mit farbe schwarz und priority 0 aufrufen? Zum wieder aktivieren einfach nen clear auf prio 0. Das kannst dir dann auf deine fernbedienung legen, und/oder nen kleines shell script schreiben welches die gennanten befehle aufruft. (Z.b. zeitgesteuert)
Just a hint:
Use protobuf for sending image data (screen grabbing)
And json for all other things.
Json api is not fast enough for image data and in proto no hyperion control commands are available.
Hyperion is based on cmake, python and qt. This works on windows too. All hardware led drivers and grabbers wont work. Except network and serial as penfold already mentioned.
(Libusb based drivers should work to)
A grabber for windows already exists. So in theory it should be possible to grab windows screen and drive your leds via adalight/arduino.
The problem is we dont have the people to do this. Giving support for another platform is to much work and we cant handle that atm.
just to be clear, you got hyperion.ng working? If so great! and congratulations! You can follow the github issues in hyperion.ng if there call for testers or you have a hint, then let us know ...
hyperion.ng: https://github.com/hyperion-project/hyperion.ng
hypercon wont work with hyperion.ng
The hyperion.config.json has also changed a lot, you have to write your own config. There is a default config in that repo, this you can use as starter.
But as I already mentioned, this version is more for developers, not for users! The documentation provided there (if any) is not always correct.
If you not familiar with linux, git and compilers, you should wait some month until hyperion v2.0 (aka hyperion.ng) is released
after removing the priority setting in framegrabber
removing a setting means "default value" is used. When you look here:
https://github.com/hyperion-pr…eriond/hyperiond.cpp#L284
you will see the default prio value is "900". If other input sources (grabber, effect, color, network servers(e.g.boblight)) on that prio or a prio value lower that value you won't get problems seeing the framgrabber at 900.
I compared your output. If you remove the "forwarder" settings, the messages on terminal are the same between your old and new config version.
There is one difference. in output of "new" it is written "PROTOSERVER INFO: New connection". You must have started some external programm to send data to hyperion (perhaps hyperion-x11? because this is the only proto sender that makes sense on x86 machines). To be clear, this messages means, that something connect to hyperion over network!
To prevent question regarding hypercon - I never used it, I always install and configure hyperion manually ... so I'm not able to answer questions about that
When more leds available then configured, the extra leds never set by hyperion. They are in an indefined state. Electrical noise can set the leds randomly.
In hyperion.ng, next big release (unknown when we release date is) we will have a general solution with that problem.
In current hyüerion you wont have a good solution for that
