Livebook and its possible uses

[marcoherbst]

Consider including https://livebook.dev/ as part of our package. (Or offering instructions for a user to do this themselves)

Some possible uses:

• Create livebook templates (playbooks) to do common or device specific tasks that are not in the UI
• A playground for technical people to try some functionality or to familiarise themselves with ExNVR internals or to create small Proof of Concepts
• As above, the easy ability to share scripts for less common use cases e.g. local snapshot extraction.
• Run https://github.com/acalejos/merquery as a way to explore with APIs on the camera.
• Enable or disable WiFi on the device ( This is a an example playbook here: https://nerves-project.org/ ). This would allow the Pi to access internet without using a modem.
• (Experimental) features on a modem. Connect/Disconnect, Send SMS,
• Restart ExNVR Reboot and or Restart #357
• Reboot the Pi Reboot and or Restart #357
• Set Camera NTP settings Ability to fix Camera time to have correct recording time. #34
• Update ExNVR to latest version
• Run an inference model on images
• Tutorials for computer vision https://gist.github.com/ChristianAlexander/256f18818055494cbe4483390dd65314
• Interactive ExNVR Documentation
• Billal's "introduction to video" talk.
• https://github.com/membraneframework-labs/ex_vision
• A Playbook to explore all OnVIF functionality
• Proof of Concept: Read MPTT USB like we currently do on the router.
• Run a series of camera configuration API calls

[the-prksh]

Hey 👋 ,

I am currently integrating livebook ~> 0.13.3 and I have encountered a problem with dependency resolution. Livebook depends on phoenix_live_view ~> 1.0.0-rc.5, while another project dependency, flop_phoenix, depends on phoenix_live_view ~> 0.20.4. flop_phoenix does not have upgrades available that support the required phoenix_live_view.

I am struggling to find a way to resolve this conflict. Can anyone provide some insight on how to address this issue?

I added the following lines to mix.exs in the deps function:

      {:livebook, "~> 0.13.2"},
      {:kino, "~> 0.13.2"},
      {:vega_lite, "~> 0.1"}

Here is the output of mix deps resolution:

. . .
Because your app depends on livebook ~> 0.13.2 which depends on phoenix_live_view 1.0.0-rc.5, phoenix_live_view 1.0.0-rc.5 is required.
So, because your app depends on phoenix_live_view ~> 0.20.0, version solving failed.

After upgrading the phoenix_live_view from 0.20.0 to 1.0.0-rc.5

. . .
Because flop_phoenix >= 0.22.7 depends on phoenix_live_view ~> 0.20.4 and flop_phoenix >= 0.21.2 and < 0.22.7 depends on phoenix_live_view ~> 0.19.0 or ~> 0.20.0, flop_phoenix >= 0.21.2 requires phoenix_live_view ~> 0.19.0 or ~> 0.20.0.
And because your app depends on flop_phoenix ~> 0.22, phoenix_live_view ~> 0.19.0 or ~> 0.20.0 is required.
So, because your app depends on phoenix_live_view ~> 1.0.0-rc.5, version solving failed.
** (Mix) Hex dependency resolution failed

[gBillal]

I don't think including livebook as a dependency is a good idea. It's better to run a standalone livebook, creating the livebooks and connecting it to a running instance of ex_nvr to do the actual job.

If you still want to include it directly, either:

• Upgrade the other dependencies to meet the requirements.
• Or find an older version of livebook that doesn't cause conflicts with the actual dependencies.

[the-prksh]

Running a standalone node locally and connecting it to a running instance of ex_nvr on a Raspberry Pi is not possible because ex_nvr runs on Elixir 1.15, while for Livebook the node must run Erlang/OTP 26 and Elixir 1.16.3 (or later).

Either elixir or deps needs to be upgraded.

Here's a screenshot for reference:

[gBillal]

Unfortunately we cannot upgrade elixir to the latest version on ex_nvr for legacy reasons. However you can downgrade livebook to meet the requirements.

[the-prksh]

May I know the legacy reasons?

I have upgraded the Elixir version in the Dockerfile to hexpm/elixir:1.17.2-erlang-27.0-alpine-3.18.7 and everything seems to be working fine.

[the-prksh]

I have deployed and checked in Raspberry Pi as well, and it is working fine there as well.

@gBillal Would you like to have a look?

[the-prksh]

When it comes to the Standalone livebook node in local machine and connecting runtime with edge device,

It won't function on edge devices because the device doesn't have mix installed. Due to this, we are unable to install dependencies dynamically using Mix.install/1.

You might be curious about how nerves_livebook addresses this issue. They tackle it by including all the livebook related dependencies as part of the release image and tweaking the Mix.install/1 functionality. Here is the code for that - https://github.com/nerves-livebook/nerves_livebook/blob/main/lib/nerves_livebook/mix_install.ex

[marcoherbst]

Do I understand correctly, that to use Livebook on a Pi, any dependencies would have to have been included in the firmware build?

Is that true only if we were using nerves? (which at the moment we're not), or is this some other limitation related to a Pi that even with a regular OS (Debian, PiOS), Mix cannot be used?

[the-prksh]

It is true when integrating using an Attached Node or Embedded Mode, but only partially true when integrating using a Standalone Node.

It has nothing to do with nerves. The Pi OS will be trimmed compared to a regular OS. In our case, the Production release of ex_nvr will not contain Mix and other development dependencies.

This blog contains the difference between an Attached node and a Standalone node. https://news.livebook.dev/remote-execution-smart-cell---launch-week-2---day-1-m3dv2

I said partially true because in Standalone node, The livebook node will run on the local machine and connect to the ex_nvr node. The notebook's dependencies will be installed on the local machine. It will use erpc to call functions of ex_nvr. However, it will not work with hardware functionalities such as Pi's peripherals, WiFi configurations, etc. To enable this functionality, an API needs to be developed in the firmware or the related dependencies should be added as part of the ex_nvr release.

[the-prksh]

I prefer using embedded mode. Nerves has used this approach to integrate Livebook. All dependencies will be included in the ex_nvr release, so there's no need to install anything on your local machine. Just use the link to open Livebook.

[gBillal]

Hi
The legacy reasons I'm talking about is that we're using devices (rasberry pi) with old debian versions. If we use Elixir 1.17.x to create the releases it'll include dependencies that'll not work on old versions (however an old version works fine on newer versions).

For livebook with attached mode, you cannot install dependencies, however you can do the following:

• Include the dependencies you need in exnvr itself and then use attached mode in livebook
• Or use smart cell (remote execution) to only get the data you need from exnvr and then use the livebook runtime to process that data. In this case you can use System.cmd or System.shell to execute commands on the remote machine (e.g. turn on/off wifi)

[the-prksh]

Hello @gBillal ,

Are you saying that some of the production kits contain old Debian versions that may cause issues?

We are not changing the Debian version, only upgrading the Elixir/Erlang version. So, I don't think there would be any issue in that case. Is there any way we can test that?

Also, in attached mode, atleast elixir >= 1.16 is required.

[the-prksh]

• Or use smart cell (remote execution) to only get the data you need from exnvr and then use the livebook runtime to process that data. In this case you can use System.cmd or System.shell to execute commands on the remote machine (e.g. turn on/off wifi)

This will be possible in "Standalone Mode", but for that, a livebook has to be set up on the laptop. @marcoherbst explained that he expects to integrate the livebook into the ex_nvr dashboard. This will not be possible if we go with Standalone Mode.

[gBillal]

We are not changing the Debian version, only upgrading the Elixir/Erlang version. So, I don't think there would be any issue in that case. Is there any way we can test that?

Elixir 1.17 docker images are all based on the newer debian version and if that image is used to build arm64 releases, the external dependencies (like ex_dtls, libsrtp2, ..) will depend on newer version of GLIBC which will not be loaded on old version of debian. I already tested this.

Anyway you can work on a new branch, upgrade elixir and any dependencies you need and create a release from there. Unfortunately we cannot upgrade right now.

[the-prksh]

@gBillal Is it possible to upgrade Elixir to version 1.16 in that case? or Can you share the Debian version?

[gBillal]

As I said above, this work won't make it to the main branch. So you're free to work on a branch, upgrade to any version and create a release from there where we can test it on some devices.

we'll upgrade Elixir once we're no longer using old raspbian version on our side.