I changed the number of LEDs to 129, it didn’t do anything. I am able to understand that the grabber is causing a problem, but why only some of the LEDs are lit in the menu?
i tried on raspberry pi 4 with hyperbian. The grabber “works”, the LEDs are on, but even with bright colors, the LEDs are white or pale blue. The flickering of the LEDs is also a problem, even with a static image.
One more thing, before the OSMC (raspbian) update, I am sure that the Hyperion control plugin was working. Now the plugin does not find the Hyperion server at all.
So as yet the hardware hasn’t worked fully on any previous setup?
I can’t see what the issue is based on the logs.
I’m beginning to suspect that now we have the software installed/compiling and running that you will need to refer to Lightberry product support or the Hyperion forum for further advice.
Currently the grabber does not work at all. Video played on Vero works fine. The menu is already working (I had to change the resolution to 4k in Vero itself: /). Currently I have the following problem: I would like the LEDs to go out to zero during the pause, with the active screen saver and during sleep. This should be done by hyperion.control, unfortunately it doesn’t.
During the pause, the kasna LEDs stay on for 3s and stay on for 3s and so on
During the screen saver and during sleep, the LEDs dim, but do not go out completely.
Is there any way to change it manually? Can you change this in the configuration file? If so, where is he?
Has there been a change with the last Vero Update?
Since then my Hyperion is not working anymore… 
service - Hyperion ambient light systemd service for user osmc
Loaded: loaded (/etc/systemd/system/hyperion.service; enabled; vendor pres Active: active (running) since Thu 2020-12-10 20:06:55 CET; 1h 56min ago
Process: 6401 ExecStartPre=/bin/sh -c exec sh /usr/share/hyperion/bin/drmct Main PID: 6434 (hyperiond)
Memory: 12.3M
CGroup: /system.slice/hyperion.service
`-6434 /usr/bin/hyperiondDec 10 22:02:06 osmc hyperiond[6434]: “No carrier”
Dec 10 22:02:16 osmc hyperiond[6434]: “No carrier”
Dec 10 22:02:26 osmc hyperiond[6434]: “No carrier”
Dec 10 22:02:36 osmc hyperiond[6434]: “No carrier”
Dec 10 22:02:46 osmc hyperiond[6434]: “No carrier”
Dec 10 22:02:56 osmc hyperiond[6434]: “No carrier”
Dec 10 22:03:06 osmc hyperiond[6434]: “No carrier”
Dec 10 22:03:16 osmc hyperiond[6434]: “No carrier”
Dec 10 22:03:26 osmc hyperiond[6434]: “No carrier”
Dec 10 22:03:36 osmc hyperiond[6434]: “No carrier”
There has been no change in conf or hardware…
I even repulled and reinstalled Hyperion from hissingsharks repo.
That looks ok to me.
What isn’t working?
The LEDs cannot be controlled by the frame grabber or the remote.
I looked into it right now again and after 3 hours of restarting the service there was this in the log:
2020-12-10T21:07:50.063Z [hyperiond WEBSOCKET] (DEBUG) (JsonAPI.cpp:1041:handleLoggingCommand()) log streaming deactivated for client ::ffff:192.168.0.105
2020-12-11T00:41:33.226Z [hyperiond LEDDEVICE] (ERROR) Device disabled, device 'adalight' signals error: 'Rs232 SerialPortError: No such device'
I didn’t change anything to the hardware or such - what could it be?
Are they lighting at all? i.e, physically working?
It’s odd it took 3 hours for that error to show, so not convinced that is the culprit. Is your selected serial device visible under /dev?
You’d get more detailed information running hyperiond --debug. If there is some show stopper it should be immediately apparent.
Yes they’re working - If I restart the service with it works again…
But I don’t know, whats causing the problem, that the Vero looses the connection to the Arduino, controlling my leds.
When I’m home this afternoon I’ll dig into this depper
I cannot explain this to myself-after Hyperion stopped working I tried to see if it was still in /dev directory and it was…
Is there another way to check if the Arduino is still accessible?
Edit:
I finally got some time to look into it but it seems the Arduino is getting disconnected for several times:
osmc@osmc:~$ dmesg | grep -i USB
[22609.348979] usb 1-2: USB disconnect, device number 10
[22609.639345] usb 1-2: new full-speed USB device number 11 using xhci-hcd
[22609.780974] usb 1-2: New USB device found, idVendor=2341, idProduct=0043
[22609.780985] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[22609.780991] usb 1-2: Manufacturer: Arduino (www.arduino.cc)
[22609.780996] usb 1-2: SerialNumber: 95233353131351810102j
[22609.781252] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[22609.871946] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[23810.482259] usb 1-2: USB disconnect, device number 11
[23810.782402] usb 1-2: new full-speed USB device number 12 using xhci-hcd
[23810.923929] usb 1-2: New USB device found, idVendor=2341, idProduct=0043
[23810.923941] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[23810.923946] usb 1-2: Manufacturer: Arduino (www.arduino.cc)
[23810.923952] usb 1-2: SerialNumber: 95233353131351810102
[23810.924212] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[23811.023907] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
Edit 2:
2020-12-14T21:21:53.077Z [hyperiond JSONSERVER] (DEBUG) (JsonServer.cpp:121:closedConnection()) Connection closed
2020-12-14T21:40:22.464Z [hyperiond LEDDEVICE] (DEBUG) (ProviderRs232.cpp:95:close()) Close UART: ttyACM0
2020-12-14T21:40:22.465Z [hyperiond LEDDEVICE] (ERROR) Device disabled, device ‘adalight’ signals error: 'Rs232 SerialPortError: No such device
Seems like the Vero is disconnecting the Arduino? Or vice versa?
Hello @hissingshark.
I just installed Hyperion.ng using exactly your github instructions and the “Install from binary” option.
Then, I run “sudo systemctl start hyperion.service”
However, when I try to open the web configuration page, I get a “connection refused” error.
If I run “sudo systemctl status hyperion.service” I get the following:
hyperion.service - Hyperion ambient light systemd service for user osmc
Loaded: loaded (/etc/systemd/system/hyperion.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Thu 2020-12-17 12:25:24 -03; 509ms ago
Process: 4449 ExecStopPost=/bin/sh -c exec sh /usr/share/hyperion/bin/drmctl.sh stop (code=exited, status=0/SUCCESS)
Process: 4446 ExecStart=/usr/bin/hyperiond (code=exited, status=127)
Process: 4416 ExecStartPre=/bin/sh -c exec sh /usr/share/hyperion/bin/drmctl.sh start (code=exited, status=0/SUCCESS)
Main PID: 4446 (code=exited, status=127)
Dec 17 12:25:24 Vero4K systemd[1]: hyperion.service: Failed with result ‘exit-code’.
If I try to run “hyperiond --debug”, I get:
hyperiond: error while loading shared libraries: libpython3.7m.so.1.0: cannot open shared object file: No such file or directory
Do you know how I can solve this?
Thanks in advance!
I’m also using a USB/Adalight/Arduino setup.
Certainly it looks like you’re getting disconnections. Definitely nothing physical going on here?
I ran mine for a full day and didn’t reproduce the disconnection errors. Currently I’m testing 4.9 for what it’s worth, but I think I was still on 3.14 after the update.
Sorry for the delay. I seem to have stopped receiving email notifications from the thread. And thank you for the concise bug report.
You are just missing a library. An easy fix, but you should be getting that already from libpython3.7 in the installer.
Can you apt-cache policy libpython3.7 to check that it installed ok?
If it did, can you instead try checking/installing python3.7 and see if that fixes it?
Thanks.
Thanks for mentioning that. That will be caused by an IP address change for the forum server and me forgetting to update postfix on the mail server to allow the new IP.
Emails should trickle in now as expected.
Weird…
I now decided to switch to a WLED Wemos Setup, hardware should be here the next days…
The disconnection problem was going on the whole time with no solution in sight 
Maybe the arduino is at the end of its lifespan?
Since yesterday Hyperion will not send the UDP stream after rebooting OSMC. The hyperion service is actually started on bootup, as the web UI is available after the boot.
I re-installed Hyperion using hissingsharks installer, but it did not fix the problem. Also replaced the DNS name of the WLED controller with its IP address in Hyperion’s config. That did not help.
I can remediate by restarting the hyperion service after a OSMC reboot, but that is annoying.
I did not change anything on the WLED controller, also no config changes in Kodi or OSMC…
Any ideas what could be the reason for this happening or how to fix it?
Have you experienced an update or any other possible trigger? What errors, if any, from the debug log when it has failed?
What happens if you disable the service and start it manually after Kodi is up? Is it a delay that is needed, rather than a restart?
No updates since some more days.
I don’t think Kodis debug log will help in any way, since Hyperion runs independently of Kodi. I grep’ed through /var/log but no “hyper” keywords there.
not sure why a startup delay would now be necessary, it was not needed a few days ago and I am using it for months now.
I tried that though. After disabling the service and manual restart after boot hyperion works as expected. One could suspect it needs a delay before it starts, not sure why that would now be necessary.
How could that be done with systemctl services, I would try that.
I meant the debug log in Hyperion. You can enable it in the webgui. Then we might see what it is objecting to.
I realise the delay wasn’t required before whatever has caused this, but it this just helps to narrow down the cause. You could add an “after” clause to the systemd unit file. Maybe to start after mediacenter. But better if we can discover the actual issue.
Ok I adaptated /etc/systemd/system/hyperion.serviceas follows:
After=network.target mediacenter.service
Now it works. You might want to consider using this also for the next release of your installer.
Thanks for you help, merry celebrations and a healthy start into 2021!