Headless Raspberry Pi support #313
Comments
|
This is right around the corner, but it will for now require that you clone the repository and follow the developer guide, and not start it via the normal prebuilt packages. |
|
Did you make this @haakonnessjoen ? |
willosof
added
Enhancement
|
There is a alpha version in the source repo: headless.js. But currently it isn't that straightforward to use for the end user, since you would need to install node, and run the update scripts before you can use it. So I think we need to do something clever before we close this, and also more testing. |
|
What would be the easiest way to import the configuration for the headless mode instance? |
|
On raspberry pi? Try cp ~/.config/companion/db ~/companion/ if I don't remember wrong. The most user friendly way would be to start it normally, export the full config as file, and then run headless and import it again, using the gui. |
|
Getting the headless mode to run requires:
|
|
After all that I got the headless.js running. With osc data updates coming in every 30ms from clock-8001 the update rate on buttons with variables lags 1-4 seconds behind and after about 1,5 minutes something just gives up and the stream deck goes all black. In the all black state pressing a button on the stream deck causes it to return to the logo display after a small delay. The companion code continues to run and still prints osc updates and button gfx generation messages into the console but everything is just dead on the stream deck side. |
|
Deleting all but the depili-clock-8001 module seems to improve the stability considerably. Now at over 6 minutes and counting where as before it never stayed stable for 2 minutes. The updates still lag behind and arrive in clumps with the display often skipping some second display updates. |
|
People have reported that installing the raspian lite image makes usb stable with stream deck using headless.js. Not sure about latency though. |
|
It seems that the memory needs are really marginal on the pi. After the module deletion and running only one module and 3 pages of buttons, of which 2 are updating from variables, one showing seconds and one minutes, the free memory on the pi hovers at around 70-65M running with rasbian lite. Edit: the stream deck updating stopped at 20min instead of 2 min, but still not usable |
|
I don't like that when the updates cease and the stream deck goes black no error what so ever gets reported on the console nor does companion exit (with non-zero exit status preferably), so any kind of stability measurement or restart logic is impossible to implement. |
I have been using rasbian lite from the start. |
|
I was having problems with the StreamDeck going black/disconnecting. It could be reconnected by rescanning USB from the surfaces tab. I believe this was due an under-rated power supply to the Pi. The 3 B+ draws more power than previous models, added to the power draw needed by the Streamdeck, it is possible to overload smaller PSUs. Check /var/log/kern.log for messages like |
|
Apparently the stability problem was indeed power related, one of my
trusty anker cables seems to be failing.
So will integrate a decent 5V 6A power supply into an enclosure with the
stream deck and the pi and feed the power in from the GPIO pins.
Still leaves something to be desired on the update rate of the stream deck
buttons. The rpi cpu is barely doing anything, so the bottleneck is
somewheere else, load average is at 0.52 at most for 1 minute average.
Memory usage also seems to be in control with only one companion module
included in the three, leaving most of the memnory free running on the
raspbian lite. Free memory seems to average about 570Mb.
|
|
Testing with a 6A 5V power supply and a 4700uF smoothing capacitor
actually yields worse results, the stream deck goes away in under a minute
:/ no under voltage alerts in the log and no dmesg messages about usb
devices disconnecting or re-enumerating. Weird...
|
|
I've had good success so far, switching from a 1A to 2A USB power supply. Haven't done any extensive soak testing yet, but it seems to have fixed the problems for me. |
|
Will need to bring my laptop next time to troubleshoot further and verify
that the unit is working with the macbook, starting to think that it might
have a fault in the cable or something like that.
Tried to give 5,2V to the 5V rail and it is still unstable for the stream
deck, the web interface works just fine and rescanning re-aquires the
stream deck just fine until it disappears again. (no kernel messages about
renegotiating the usb link or anything like that.
|
|
Continued testing with the latest head 9a404b0 button updates are steady but the stream deck still disconnects from companion after a short while. I have two different stream decks to test with currently and both are showing the same behaviour. Running with raspberry pi 3b+ and stretch lite. Next up: testing with rpi 3b |
|
And same results with rpi3b :/ |
|
Depili - I'm trying this too, albeit using Irisdown Countdown Timer 2, which only provides feedback every second. My circumstances for disconnection are as follows:
I'm using a Pi 3b (non +) Rescanning in control panel finds it again. Is this what you see? |
|
Pretty similiar, don't have the exact logs. My gut tells me this might be
a timing issue, where the graphics generation takes enought time that it
blocks some usb transactions that end up timing out because of it.
This is plausible since nodejs executes code in one event loop per process
and if processing one event is ongoing all others are blocked until that
event finishes. The Pi being quite bit slower means the event loop is
blocked for longer periods of time and the likelihood of timing collisions
because of that increases greatly.
The companion code itself seems to be smart enough that it only updates
the graphics when they actually change and not on each feedback update (if
the data stays the same), which helps as my current implementation sends
the osc feedback on each frame.
Will need to test this by having a setup with no feedback at all, and thus
no button graphics regeneration, and see if it alters the stability. I
should also have access to more powerful bananapi board soonish to test.
If it indeed is caused by the event loop timing issues I don't know what
could be done other than trying to separate the gfx generation and usb
into diffirent nodejs processes. I haven't even tried to look into the
companion codebase to find out what kind of multiprocessing, if any, it
already does.
|
|
With regards to your further testing comments - if the Stream Deck is
showing a page without feedback (ie buttons are on Page 1, Stream Deck is
showng Page 2) then it's stable.
Likewise if the same buttons are shown without making use of the feedback
text.
(I had 3 buttons showing remaining hours, minutes and seconds of my
countdown timer.)
I also feel this is almost a separate issue and might want splitting off from #313.
…On Sat, 16 Feb 2019 at 00:04, depili ***@***.***> wrote:
Pretty similiar, don't have the exact logs. My gut tells me this might be
a timing issue, where the graphics generation takes enought time that it
blocks some usb transactions that end up timing out because of it.
This is plausible since nodejs executes code in one event loop per process
and if processing one event is ongoing all others are blocked until that
event finishes. The Pi being quite bit slower means the event loop is
blocked for longer periods of time and the likelihood of timing collisions
because of that increases greatly.
The companion code itself seems to be smart enough that it only updates
the graphics when they actually change and not on each feedback update (if
the data stays the same), which helps as my current implementation sends
the osc feedback on each frame.
Will need to test this by having a setup with no feedback at all, and thus
no button graphics regeneration, and see if it alters the stability. I
should also have access to more powerful bananapi board soonish to test.
If it indeed is caused by the event loop timing issues I don't know what
could be done other than trying to separate the gfx generation and usb
into diffirent nodejs processes. I haven't even tried to look into the
companion codebase to find out what kind of multiprocessing, if any, it
already does.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#313 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/APZxOdsyUTur-U5sCeskQ8aHsuVyzxcGks5vN0scgaJpZM4X_0FJ>
.
|
|
I'm having the button blacking out issue too. Raspberry 3B+, fresh install of Lite, latest git head, Official wall wart PSU. |
|
I've cleaned up the debug stuff a bit now. Headless is default silent now, and when it comes to the normal "npm run start", it is now "yarn dev" (electron launcher + console debug) or "yarn prod" (electron launcher, no debug) (In the companion 2.0 branch (nopagebuttons)) |
|
I'm running a RPI 3B+ with streamdeck on 1.4.beta since today and experience this disconnection issue you are discussing above. Where do I need to change your fixing code and recompile then, so I get my Deck stable for now...? |
|
The file you're looking for is
Where you see this code block... elgato.prototype.draw = function(key, buffer) {
var self = this;
buffer = self.handleBuffer(buffer);
try {
self.streamDeck.fillImage(self.reverseButton(key), buffer);
} catch (e) {
self.system.emit('elgatodm_remove_device', self.devicepath);
}
return true;
}...replace it with this block... elgato.prototype.draw = function(key, buffer) {
var self = this;
buffer = self.handleBuffer(buffer);
try {
self.streamDeck.fillImage(self.reverseButton(key), buffer);
return true;
} catch (e) {
console.log(e)
// failed to redraw, try again
setTimeout(self.redraw.bind(self), 20);
}
}
elgato.prototype.redraw = function(key, buffer) {
var self = this;
buffer = self.handleBuffer(buffer);
try {
self.streamDeck.fillImage(self.reverseButton(key), buffer);
return true;
} catch (e) {
self.log('Error drawing:', e);
self.system.emit('elgatodm_remove_device', self.devicepath);
return false;
}
} |
|
thanks jarodwsams! |
|
If you still notice drops (I did, but only once when I was making a lot of changes all at once) try replacing my code block with the one from @Towerful. Mine tries it again just once after 20ms. His adds a retry counter (up to twice) after 20ms. elgato.prototype.draw = function(key, buffer, attempts = 0) {
var self = this;
if(!attempts){
buffer = self.handleBuffer(buffer);
}
attempts++;
try {
self.streamDeck.fillImage(self.reverseButton(key), buffer);
return true;
} catch (e) {
if(attempts > 2) {
self.log('Error drawing:', e);
self.system.emit('elgatodm_remove_device', self.devicepath);
return false;
}
setTimeout(self.draw.bind(self), 20, key, buffer, attempts)
// alternatively a setImmediate() or nextTick()
}
} |
|
With your code replaced (with the redraw sectionI) I got it crashing again quite fast after a few minutes playing around with my hyperdeck mini, Thanks! |
|
If you haven't already, you should read the note at the top of the raspberrypi.md document.
|
|
Code from @Towerful runs stable on my pi 3B+ with "regular" streamdeck so far. |
|
I keep getting an error with line 54 anyone know what it could be and how to fix it? |
|
@Coachwest2019, we need some more info, and a screenshot or two. |
|
|
|
@Coachwest2019 Since your issue is not related to the topic of this post, please create a new issue report. You can do that by clicking this link: https://github.com/bitfocus/companion/issues/new/choose. You'll be given a bug report template to fill out to make sure the community has all the information needed to assist you. |
|
But, can we close this ticket? I'd say we've had rpi headless support after headless.js was introduced :) |
I'd think so. Aside from the lag (known issue with the hardware) it's been working quite swimmingly at church for several weeks now. |
|
I still suspect that there is a package installed in rasbian or a udev
rule or something like that which is the root cause of the write errors to
the streamdeck. We fixed that with the retry logic, but it would be nice
to find out what is causing the problem.
One idea would be to use raspian-ua-netinst to install a really minimal
environment and see if that also needs the retries. See
https://github.com/FooDeas/raspberrypi-ua-netinst
|
|
@depili Honestly I wonder if the issue isn't so much what the software is doing, but the fact that the Ethernet runs over the USB bus on the RPi3. I've seen a lot of reports claiming that the RPi4 runs smooth as butter (at least on the 2GB version, unknown on the 1GB), and aside from an OS update the biggest relevant change is that the Ethernet was pulled off the USB bus. I'm hoping to get a 4 4GB here soon and will be able to confirm the accuracy of those reports. I'd like to be able to get all 3 versions of the 4 (1GB, 2GB, 4GB RAM) to test side-by-side, but I don't think I'll be able to do that. |
|
Housekeeping on the open issue here. We do have headless support... how is it working for you guys? Stable/recommended on pi4 only? |
|
working well on headless RPi4 for me. |
|
I would call it stable, with the caveat that you should not leave it always-on. Either shut down the Pi when it's not in use, or implement some method to have it automatically reboot on a regular schedule (I'd recommend daily). It is strongly recommended to not run Companion on a Pi 3, even a Pi 3 B+. Performance is terrible and laggy and not suitable for production. My personal recommendation is at minimum a Pi 4 2GB. All of that said, I'd echo @alatteri. It works quite nicely under proper working conditions. |
…, as discussed in #313. (Fixed bug)
|
Headless is working. The disconnection problem in RP3 should also be fixed now. |
|
I setup a pi 4 for pihole, then some other server function and companion. The thing is, I need the pihole running most of the time while I would like to be able to remotely start Companion when I need it and shut it down when I am done. Is there a mechanism to accomplish this? a ssh script or something that I can create on Windows or Mac to remotely control it? Companion is constantly trying the connect to the device instance and that's wasted bandwidth when none of the media activity is going on. But wonderful job on the raspberry repository, loved it! |
|
@jimyehoo there’s a new internal action in Companion to close it out. Assign that action to a button and then you can trigger that a number of ways. The easiest is probably curl/http. As far as opening Companion on schedule/trigger, it’s pretty easy to SSH and start a process. |
|
I actually have issues with Pi 4 install, the db copying says file is not found, it worked on Pi 2, but not on Pi 4. I installed the Pi 4 several times and on many installs, it just doesn't work. The install process doesn't report error but the db is always not there to be copied. I am not sure if this is the cause, but I saw the compiled yarn is for armv7 and not armv8 which the Pi 4 cpu is on? I have the Pi 4 doing lighting control and mumble chat, and the only thing I need on this Pi 4 is the Companion. |
|
If you're talking about this error, I regularly see that as well. I had it when my production unit was a Pi 3 B+, as well, but I never saw any actual issues caused by it. This specific bug actually is just a timing issue that shouldn't have any real impact on performance. I reported it back in June: #679 |
|
yes, that warning comes up, too. But I am talking during the installation process where if I just installed the Companion and run it the first time, I enter this command to copy the db... |
|
@jimyehoo Ok, let's deal with that on an individual issue/bug report. Open a new report, with screenshots or log files if you can, with as much detail as possible, and tag me in it so I see it. I'll take a look at it as soon as I can. New Issue/Bug Report: https://github.com/bitfocus/companion/issues/new/choose |
Starting Companion on boot of a Raspberry PI without the need for a display connected or logging in to a VNC or SSH session.
Preferably this would be enabled via a systemd service.
Some basic config options exposed to the command line such as setting the network interface
The text was updated successfully, but these errors were encountered: