Missing Web Interface

[ryanriccio1]

The web interface fails to be installed properly when doing my own build. I'm trying to make some of my own changes, and regardless of the branch I build (0.10, master, release) and whether or not I actually rebased my changes in, there seems to be no web interface in /usr/share/olad/www. The build succeeds and ola runs fine but I cannot configure it from the UI. I have tried manually copying the files, but none of the JS scripts seem to be able to pull info from the daemon. Running this on an RPI4 with the latest version of raspberry pi os.

I built it with these:

cd repo
git checkout <test branch>
autoreconf  -i
/.configure
make -w -j 4 all
sudo make install
sudo ldconfig
olad -l 3

common/http/HTTPServer.cpp:793: Missing file: /usr/share/olad/www//new/index.html

pi@OpenLightingArchPi:~ $ ls /usr/share/olad
ls: cannot access '/usr/share/olad' : No such file or directory

In the docs, it was using protobuf lite 10, and the latest is lite 17, or at least that's what's in the Raspbian apt sources, so that's what I used.

[peternewman]

The web interface fails to be installed properly when doing my own build. I'm trying to make some of my own changes

Out of interest are they changes the rest of us would benefit from? If so, please open a Pull Request with them when you get a chance.

regardless of the branch I build (0.10, master, release) and whether or not I actually rebased my changes in, there seems to be no web interface in /usr/share/olad/www.

Are you trying to use a locally tweaked web UI with a deb installed olad? I really wouldn't recommend it, as I think you'd just get in a big mess, but if you did, you'd need to set some prefixes with configure to get them to install to the same place. I'd suggest instead if you don't want to recompile olad (although you probably already have) you could just point olad to a different web UI folder.

The build succeeds and ola runs fine but I cannot configure it from the UI. I have tried manually copying the files, but none of the JS scripts seem to be able to pull info from the daemon. Running this on an RPI4 with the latest version of raspberry pi os.

So do you mean they load, but don't talk to it, that doesn't match the log snippet.

In the docs, it was using protobuf lite 10, and the latest is lite 17, or at least that's what's in the Raspbian apt sources, so that's what I used.

Yeah that should be fine.

Can you clarify are you trying to modify olad or the web UI?

Can you do a locate for app.min.js to try and find out where (or if) they have been installed?

Can you share a full olad -l 4 log so we can try and see what's happening: https://www.openlighting.org/ola/get-help/ola-faq/#How_do_I_get_olad_-l_4_logs

You may also need to share the output of make install too.

Ideally pushing your changes somewhere might simplify troubleshooting.

I also can't see anything that would introduce that pattern of double-slashes within the URL: https://github.com/OpenLightingProject/ola/search?q=www_datadir

[ryanriccio1]

Out of interest are they changes the rest of us would benefit from? If so, please open a Pull Request with them when you get a chance.

Just messing with trying to get WS2811/2s to work. If it ends up working will try to submit a PR.

Are you trying to use a locally tweaked web UI with a deb installed olad? I really wouldn't recommend it, as I think you'd just get in a big mess, but if you did, you'd need to set some prefixes with configure to get them to install to the same place. I'd suggest instead if you don't want to recompile olad (although you probably already have) you could just point olad to a different web UI folder.

No I'm not trying to tweak the UI and I did at a previous time have a deb installed olad on the pi but I apt purge'd it. I'm making changes to the SPI plugin so I'm perfectly fine with recompiling it.

So do you mean they load, but don't talk to it, that doesn't match the log snippet.

Well olad -l 3 runs fine and loads the plugins just fine, but the web interface is either not installed at all, or it can't find it, haven't figured out which one yet. I copied the olad/www file from the build folder directly to where it's looking for it, and the web interface runs except all of the data is just things like {{universe.id}} or something like that.

Can you clarify are you trying to modify olad or the web UI?

olad

Can you do a locate for app.min.js to try and find out where (or if) they have been installed?

I could not locate it and I manually copied it.

Can you share a full olad -l 4 log so we can try and see what's happening: https://www.openlighting.org/ola/get-help/ola-faq/#How_do_I_get_olad_-l_4_logs You may also need to share the output of make install too.

I will later not near the pi rn.

I also can't see anything that would introduce that pattern of double-slashes within the URL: https://github.com/OpenLightingProject/ola/search?q=www_datadir

Ya that's weird. I might just try to use the apt package and try to get WS2811 out with the OPC method.

Is there a specific branch I should be using to test all of this with? I know that travis cl says that the 0.10 branch compiles fine. I'm guessing I should just stick with the .tar.gz release right? Even without making any changes, I still get these errors when compiling myself.

[ryanriccio1]

I also was trying to add entries to the enum and Personalities vector in SPIOutput.h/.cpp and was not sure how to test those without the web interface working. I added a function in the .cpp that gets called in the switch statement but whenever I changed the spi personality to 11 (or whatever was the next number in the enum), it would just reset it back to 1 after restarting OLA.

[peternewman]

Just messing with trying to get WS2811/2s to work. If it ends up working will try to submit a PR.

Cool, I assume you've seen #578 and the PR #1382 ?

No I'm not trying to tweak the UI and I did at a previous time have a deb installed olad on the pi but I apt purge'd it. I'm making changes to the SPI plugin so I'm perfectly fine with recompiling it.

That's good. It would be worth checking dpkg -l | grep -i ola to confirm you purged ALL the OLA packages.

So do you mean they load, but don't talk to it, that doesn't match the log snippet.

Well olad -l 3 runs fine and loads the plugins just fine, but the web interface is either not installed at all, or it can't find it, haven't figured out which one yet. I copied the olad/www file from the build folder directly to where it's looking for it, and the web interface runs except all of the data is just things like {{universe.id}} or something like that.

Sounds like you're talking about the new web UI. It also needs the compiled JS in https://github.com/OpenLightingProject/ola/tree/master/olad/www/new/js which it should have also copied. What does your web browser console/network tab show, are files missing?

Does e.g. /debug work or /help ?

Can you clarify are you trying to modify olad or the web UI?

olad

Can you do a locate for app.min.js to try and find out where (or if) they have been installed?

I could not locate it and I manually copied it.

So you could only find it where you copied it from and to?

Can you share a full olad -l 4 log I will later not near the pi rn.

Great thanks, that will answer a lot of the above.

Is there a specific branch I should be using to test all of this with? I know that travis cl says that the 0.10 branch compiles fine. I'm guessing I should just stick with the .tar.gz release right? Even without making any changes, I still get these errors when compiling myself.

If you're adding a new feature like this, targeting our master branch would be best, but the release .tar.gz or 0.10 branch should also work as expected.

[peternewman]

I also was trying to add entries to the enum and Personalities vector in SPIOutput.h/.cpp and was not sure how to test those without the web interface working.

So you could also use ola_rdm_get and set: https://docs.openlighting.org/ola/man/man1/ola_rdm_get.1.html https://docs.openlighting.org/ola/man/man1/ola_rdm_set.1.html

Once you'd discovered their UIDs: https://docs.openlighting.org/ola/man/man1/ola_rdm_discover.1.html

I added a function in the .cpp that gets called in the switch statement but whenever I changed the spi personality to 11 (or whatever was the next number in the enum), it would just reset it back to 1 after restarting OLA.

This bit is probably the cause of that: https://github.com/OpenLightingProject/ola/pull/1382/files#diff-d9d0132f535683b86aca95e0ac2d726bf66a07e9af70d3280345a8229edd7f4aR264-R278

i.e. you haven't expanded the range it's checking, so it rejects your 11 although it's in the case statement.

[ryanriccio1]

I've seen #578 but I haven't seen #1382. I'm gonna reflash the pi and start over again just to make sure I don't have any OLA things from a previous apt install. Hopefully that fixes the web interface thing too. Completely skipped past my problem solving that the app.min.js needed to compile too. I like #1382 better than my implementation so I'm just going to try to rebase that with the OLA master on my own fork.

This bit is probably the cause of that: https://github.com/OpenLightingProject/ola/pull/1382/files#diff-d9d0132f535683b86aca95e0ac2d726bf66a07e9af70d3280345a8229edd7f4aR264-R278

Ah yes! That's what I needed. Really wish it was already merged but seeing how @Ph0N37Ic5 dropped off the map all of the sudden I guess I'll just do it myself locally.

[peternewman]

I've seen #578 but I haven't seen #1382.

Ah, sorry about that.

I'm gonna reflash the pi and start over again just to make sure I don't have any OLA things from a previous apt install. Hopefully that fixes the web interface thing too.

Cool, you and @Ph0N37Ic5 do seem to have lots of weirdly similar issues despite your independent work...

Completely skipped past my problem solving that the app.min.js needed to compile too.

Sorry, I didn't phrase that very well, we store the compiled JS code in the repo, so people like you and I making C++ (or Python) changes don't need to have the JS toolset, but if you were making web UI changes (which you aren't), you'd need to compile the JS to see your changes in action.

I like #1382 better than my implementation so I'm just going to try to rebase that with the OLA master on my own fork.

Cool, sounds good.

This bit is probably the cause of that: https://github.com/OpenLightingProject/ola/pull/1382/files#diff-d9d0132f535683b86aca95e0ac2d726bf66a07e9af70d3280345a8229edd7f4aR264-R278

Ah yes! That's what I needed. Really wish it was already merged but seeing how @Ph0N37Ic5 dropped off the map all of the sudden I guess I'll just do it myself locally.

That's awesome news. Unfortunately the test run has disappeared from Travis, but I think the tests were possibly passing, so it may just be some cosmetic tweaks and then actually testing it out in the real world (which I think was still outstanding). Let us know if you need any help with it, lots of people are clearly keen to get this in judging by the issue!

[ryanriccio1]

Hey just changed a whole bunch of stuff and reinstalled the OS and everything works. Still haven't tested WS2811b on physical hardware but everything on the software side seems to work! Thank you so much for your help @peternewman.

[peternewman]

Hey just changed a whole bunch of stuff and reinstalled the OS and everything works. Still haven't tested WS2811b on physical hardware but everything on the software side seems to work! Thank you so much for your help @peternewman.

Excellent, glad you got it sorted!

Pondering further (for future people as much as anything), my best guess would be you still had libola installed, which I think would be what would direct it to /usr/share rather than /usr/local for the HTTP stuff, but because you'd installed into /usr/local via make install it couldn't find them.

[ryanriccio1]

@peternewman

Still a WIP, and please do ignore my prototype PCB files, this project was for one of my friends, but here is a python script I wrote using the adafruit neopixel library. Takes in sacn and will output to WS2811/2b I'll put more info in a README later.

https://github.com/ryanriccio1/rpi-sacn-neopixel

[ryanriccio1]

https://github.com/ryanriccio1/rpi-sacn-neopixel

Currently, it's setup to possibly in the future allow the patch to change during runtime and have a pretty sweet web UI, just haven't had the time with school yet.

[peternewman]

That's cool @ryanriccio1 . Although as you've done, you're probably better off posting in #578 given you'd closed this, and it's titled, and primarily about issues building OLA's web UI.

Out of interest, did you try the code in #1382 ? If so, did it work? I don't think there was too much clean-up to get that PR merged, I just personally lack the kit to test it.

[ryanriccio1]

@peternewman I did try #1382 and although the software side of things went well, when it outputted to the WS2811, it would flicker and the first LED in the strand would not have the correct color. I assume it works well with WS2812b just fine but haven't tested it as it isn't my use case. I also don't have the know-how to debug it on that low of a level and I don't have a scope.

[peternewman]

@peternewman I did try #1382 and although the software side of things went well, when it outputted to the WS2811, it would flicker

Ah that's a shame. Was there constant flickering?

and the first LED in the strand would not have the correct color.

Was it always a static colour for the first LED, or offset relative to the others or?

I assume it works well with WS2812b just fine but haven't tested it as it isn't my use case. I also don't have the know-how to debug it on that low of a level and I don't have a scope.

The tests will be with the WS2812b. From what I can see from the data sheets the WS2811 uses the same protocol, but I have none I can test with.

Originally posted by @Ph0N37Ic5 in https://github.com/OpenLightingProject/ola/issues/1382#issuecomment-368270649

[ryanriccio1]

Was there constant flickering

No very inconsistent.

Was it always a static colour for the first LED, or offset relative to the others or?

Some sort of offset. When I ran a rainbow chase on the strand, the first led seemed to change colors to the color of the led it was "writing to". Kind of hard to explain.

From what I can see from the data sheets the WS2811 uses the same protocol, but I have none I can test with.

From what I've read, there are a few minute differences, as well as some differences in the speed specifications. Most of the time, these differences should not affect it, but sometimes it can, and I think #1382 was the edge case where it didn't work for both.