I have a Screenly OSE installation that works very well and I need to be able to display the playlist even offline. I may use ScreenlyOSE in some place where there is no way to connect the RPi to internet. Is there a way to bypass the hotspot prompt and just run the playlist ? I don’t want a full desactivation of the API since I need it to upload the videos to screenly, if possible with a fake internet connection (a local hotspot for instance).
As a summary:
I need the API to be reachable when the RPi is connected to a local hotspot i.e. no connection to the real world internet. (I noticed that the web gui is requesting some external ressources, can we juste use the raw API ?)
I need Screenly to skip the hotspot prompt and run the playlist already in the database when the RPi is not connected.
I don’t mind if the answer I am looking for implies to change the python code, I can do it.
Thanks.
So the first thing to keep in mind when you run a Raspberry Pi “offline” is that it…generally speaking doesn’t work well…in particular for something like digital signage.
The reason for this is that the Raspberry Pi doesn’t have any onboard Real Time Clock (RTC). This means that if the device has no internet and is power cycled, it will have no idea what time it is (and set the default to 1970). This is obviously a problem for something that depends on scheduling, like Screenly OSE.
The only way you can make this work (reliably) is either to get a physical RTC and attach it to the board, or making sure that you have a local NTP server that the Raspberry Pi can use to configure its time against.
Because these things are normally not true, the default configuration in Screenly OSE is to require a network connection.
It should in theory be possible to bypass say the hotspot and serve all content locally, but I’m not exactly sure what the scope of this would be of the top of my head.
Hi,
Thank you for your quick answer, I managed to tweak the code to bypass the hotspot and everything is fine. Apparently my RPi has a RTC or at least manage to have a decent guess of the time, which is sufficient for my needs.
I have still an issue I will resolve by myself, which is that apparently Screenly do not want to read my wpa_supplicant.conf file and the first connection to my hotspot must be setup via the Screenly balena webgui. After that connection is automatic and works fine.
Hi, just wanted to understand this part… so you are not using the network manager that screenly recommends to be installed? how do you know screenly (or the RPi) is not reading your wpa_supplicant.conf file? because if you use the screenly hotspot resin wifi manager setup, you are essentially using NetworkManager in the backend, this sets up a profile under the NetworkManager directory, not via wpa_supplicant.conf file.
How does you wpa_supplicant.conf file look like?
Sometimes localisation matters, to set a country for proper wifi channels: sudo iw reg set US
Hi,
I just understood what you explain after I wrote my previous post. I have a regular wpa_supplicant.conf file and I fix my issue by using the NetworkManager. I don’t want to use the hotspot resin wifi manager setup since I want to be able to bypass this hotspot when my RPi has no internet connection.
I know that Screenly (or the RPi) is not reading wpa_supplicant.conf because Screenly (or the RPi) fails to connect to my local hotspot. I am sure that my local hotspot works well because once I setup screenly via the resin setup, everything is fine, even after a reboot. The issue is juste for the first connection to a wifi.
I probably messed up with my localisation at some point and don’t know if it had some impact. I will try to identify if the localisation matters and come back to you.
So the localisation configuration has apparently nothing to do with the issue I had. It seems that NetworkManager is the only reliable interface to use in my case.
Well, the proper localization does affect WiFi channels and power settings so I wouldn’t entirely rule this out at first, you should always have proper localization as a general rule of thumb, but yes usually this is not an issue for majority of users…
But going back to the NetworkManager situation, this is recommended since it is easier to use vs editing wpa_supplicant.conf and /etc/network/interfaces, etc…