nerves-livebook / nerves_livebook Goto Github PK

See https://github.com/elixir-circuits/circuits_quickstart

Perhaps full on when network connected and blinking if no network. The goal is to give users some indication that the thing is working.

@jjcarstens reports that this has only been observed on KOOTION MicroSD cards and quite a few other brands have been tried:

ERROR!!! [Livebook] could not start distributed node: {{:shutdown, {:failed_to_start_child, :auth, {'Too short cookie string', [{:auth, :init_no_setcookie, 0, [file: 'auth.erl', line: 293]}, {:auth, :init_setcookie, 3, [file: 'auth.erl', line: 345]}, {:auth, :init, 1, [file: 'auth.erl', line: 144]}, {:gen_server, :init_it, 2, [file: 'gen_server.erl', line: 423]}, {:gen_server,[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed
 :init_it, 6, [file: 'gen_server.erl', line: 390]}, {:proc_lib, :init_p_do_apply, 3, [file: 'proc_lib.erl', line: 226]}]}}}, {:child, :undefined, :net_sup_dynamic, {:erl_distribution, :start_link, [[:livebook_3yqogwzo, :shortnames, 15000], false, :net_sup_dynamic]}, :permanent, false, 1000, :supervisor, [[   30.566840] watchdog: watchdog0: watchdog did not stop!
:erl_distribution]}}

It is consistent on these cards. Here's what they look like:

Note: Jon is sending me a couple to see what is happening since I could not reproduce on any brand MicroSD card that I had.

This will let users without wired Ethernet or USB gadget boards use it.

Description
Create a example using hardware PWM to dim an led or control a servo.
@mnishiguchi already put together a great example of this on Dev.

This happens even with saving automatically.

To reproduce:

1. Open a notebook
2. Change it
3. Save it
4. Unplug the board

Sometimes the file will be corrupt.

Now that the WiFi regulatory domain defaults to only allow globally acceptable WiFi frequencies, we should add an option to the WiFi configuration to set the country code.

Currently Mix.install isn't supported, but it would be great to make it possible pull in some dependencies. Nerves doesn't include C compilers, headers, etc. to compile any native code, so that's not an option. However, it seems like pure Elixir and Erlang projects should build.

To try Mix.install, you'll need to add :mix and :hex to the mix.exs's :extra_applications so that they're included. You'll also need to comment out -mode embedded in the vm.args.eex file. However, there are more issues:

1. Dependencies of dependencies are compiled even if they're available. For example, most Nerves libraries have a dependency on some library with native code so you can't try those. (I don't think this is a blocker since there are still many libraries left)
2. It seems like you get one Mix.install error and then you need to reboot. I'm not sure what's going on here.

I have the raspberry pi 4 running the latest version of raspberry pi OS, I have it paired with an iclever tri-folding keyboard model bk08, and with the device being near the pi at less than 1.5 foot away its signal becomes weak or sluggish, It's not an issue with the keyboard as it works fine on other devices just fine, does anyone think it might be an issue with whatever Bluetooth drivers pi os uses? and if anyone has a fix for this please let me know.

Hey! I found, that recent releases does not work with Rapsberry pi zero w 2.
Latest version, that works is v0.10.1 with rpi3a target.
v0.11.1 and v0.12.0 does not boot with black screen and blinking cursor.
I tried both rpi3a and rpi0_2 targets.

Not sure what changed, but it does not work :(

Currently nerves_livebook is not published as a Hex package; thus the Hexdocs links are broken. In a way, it is expected but I am wondering if we can possibly publish a package for the sake of the documentation.

It should include:

• RingLogger
• RamoopsLogger.dump()
• dmesg
• erlinit's shutdown report

More Livebook features are available in Elixir 1.12, so upgrade to it.

Per reports from NervesConf, all of the Windows users had trouble with USB gadget mode. Both Connor and I have checked Windows, but I think we both may have unknowingly installed the fix. This issue is to look into what is preventing the USB gadget interface from working with Windows with Nerves Livebook, and then either fix it or document the steps to make it work.

I periodically reach for an IEx prompt especially when debugging a Livebook. I currently ssh into the device for the IEx prompt, but it would be nice to click on an icon that would open up a browser tab with an IEx prompt.

See extty and what's done on NervesHub for this feature for possible help.

I'm not sure if this is an issue for nerves_system_grisp_2, vintage_net_wifi or just a docs issue for this repo.

While following the setup guide for the grisp 2 from the readme I can VintageNetWifi.quick_configure. However, I kept getting these warnings and errors in the console:

13:55:25.536 [error] wpa_supplicant: Process exited with status 255
13:55:25.540 [error] GenServer #PID<0.3828.0> terminating
** (stop) :error_exit_status
Last message: {#Port<0.47>, {:exit_status, 255}}
13:55:26.621 [error] wpa_supplicant: Process exited with status 255
13:55:26.622 [error] GenServer #PID<0.3832.0> terminating
** (stop) :error_exit_status
Last message: {#Port<0.48>, {:exit_status, 255}}
13:55:27.731 [error] wpa_supplicant: Process exited with status 255
13:55:27.732 [error] GenServer #PID<0.3836.0> terminating
** (stop) :error_exit_status
Last message: {#Port<0.49>, {:exit_status, 255}}
13:55:27.771 [warn] RouteManager: new set_connection_status wlan0 -> :disconnected (ifdown)
13:55:27.793 [warn] RouteManager: new set_connection_status wlan0 -> :disconnected (Elixir.VintageNet.Interface.start_configuring/3([file: ~c"lib/vintage_net/interface.ex", line: 669]))

Enabling debug logs proved to be more helpful:

13:58:41.280 [debug] wpa_supplicant: Line 6: invalid key_mgmt 'SAE'
13:58:41.289 [debug] wpa_supplicant: Line 6: failed to parse key_mgmt 'WPA-PSK WPA-PSK-SHA256 SAE'.
13:58:41.291 [debug] wpa_supplicant: Line 11: failed to parse network block.
13:58:41.292 [debug] wpa_supplicant: Failed to read or parse configuration '/tmp/vintage_net/wpa_supplicant.conf.wlan0'.

Seems like wpa_supplicant isn't happy with the config created by quick_configure

%{
  type: VintageNetWiFi,
  vintage_net_wifi: %{
    networks: [
      %{
        mode: :infrastructure,
        psk: "xxxx",
        sae_password: "VERYSECRET",
        ssid: "MY_SSID",
        ieee80211w: 1,
        key_mgmt: :wpa_psk,
        allowed_key_mgmt: [:wpa_psk, :wpa_psk_sha256, :sae]
      }
    ]
  },
  ipv4: %{method: :dhcp}
}

After calling VintageNet.configure/2 and building the config manually things work fine now, but I think we should probably at least add a hint to the Readme?

Hello everyone,

I have a Raspberry Pi Zero 2W without any pins soldered on to it. I was hoping to try some Livebook Nerves on it, but have been unsuccessful. I falsh my SD card with v0.12.2 nerves_livebook_rpi0_2 and when I connect it to power (I have tried different power supplies because I saw it as an issue somewhere on the internet) the Pi just blinks the LED in what I can only describe as a repeatable pattern.

I cannot connect to nerves.local. I assume there is a problem with the Pi connecting to the WiFi. Yes, I am trying to connect to my 2.4GHz WiFi.

The command I use to flash the SD card is the one The Underjord uses in his video https://www.youtube.com/watch?v=-b5TPb_MwQE

sudo NERVES_WIFI_SSID='2.4GHz_network_name' NERVES_WIFI_PASSPHRASE='password' fwup ./nerves_livebook_rpi0_2.fw

I assume the settings do not get written successfully. People manage to access this post-flash and fix the configuration of the WiFi, but I have neither a cable to do so, nor the pins soldered on at the moment. Is there a solution for me, that I could try?

It would be really interesting to get BLE support in a Livebook, but it requires config.txt and fwup.conf changes for the Raspberry Pi. These change the UART, so it would be nice to be able to enabled or disable it at runtime.

I don't see any way without changing the config.txt file. The conditionals don't look expressive enough.

Here's a nerves_livebook fork that works with Bluetooth: https://github.com/axelson/nerves_livebook

Currently there's a firmware update livebook, but Nerves also supports delta firmware updates. These are updates where the differences from the currently running firmware are downloaded instead of the full image. These updates can be quite a bit smaller and are interesting to users with devices connected over metered connections especially.

The work that needs to be done:

1. On CI when building the firmware image, download the previously released firmware image. (Only support deltas from the most recent version)
2. Run xdelta3 to compute the delta firmware. The script to do this is in the nerves_hub_web source tree.
3. Name the delta firmware z-<UUID>-<target>.fw where UUID is the firmware UUID of the previously released firmware image. The target part isn't needed, but seems useful for humans looking at the files. The z prefix should hopefully sort the deltas at the end of the GitHub Release file list.
4. Post the delta firmware file with the full image one.

The Livebook can be similar to the current firmware download Livebook. Some of the details can be trimmed at the UUID of the currently running image will need to be retrieved. It might be necessary to modify the firmware update livebook to be able to load a specified release rather than always use the latest for convenience. Nerves.Runtime.revert() will also be useful.

The idea is to implement a livebook that does a firmware update.

Here's how it would work:

1. Use the GitHub API to figure out the latest release version. This would be something like making a request to https://api.github.com/repos/elixir-circuits/circuits_quickstart/releases/latest. (I used Elixir Circuits since CI isn't set up here yet, but the desire is to make it work the same.)
2. Call Nerves.Runtime.KV.get_active("nerves_fw_version") to get the current firmware version
3. Show those to the user so they know whether there's a new release
4. Use Nerves.Runtime.KV.get_active("nerves_fw_platform") to figure out which release in the GitHub API results is the right one and then pluck out URL of the firmware update.
5. Download the .fw file to /tmp (it doesn't really matter)
6. Run fwup on the file
7. Reboot

This is the non-optimal download and then run fwup rather than pipe directly to fwup and don't store anything. That feels easier to explain. I also think it should require very little code and should feel very accessible.

The default is short names and this only works on WiFi and wired Ethernet when using a router running dnsmasq. It would be good to get nerves.local running.

See livebook-dev/livebook#1560 (comment).

When updating to Livebook > 0.7.2 we need is to change this:

https://github.com/livebook-dev/nerves_livebook/blob/7904a83b2ab236c651635aeb45a866ea5687f590/lib/nerves_livebook/dependencies.ex#L48

to:

dependency: %{dep: {app, "~> #{version}"}, config: []},

This needs to wait for the next Livebook release. As of livebook-dev/livebook#1081 we have a dependency search. For the default runtime it searches on Hex. For the embedded runtime there is a configuration option that allows for listing predefined dependencies, it works like this:

config :livebook, Livebook.Runtime.Embedded,
  load_packages: {NervesLivebook.Dependencies, :packages, []}

defmodule NervesLivebook.Dependencies do
  def dependency_entries() do
    # Return dependencies in this format:
    [
      %{
        dependency: {:kino, "~> 0.5.2"},
        description: "Interactive widgets for Livebook",
        name: "kino",
        url: "https://hex.pm/packages/kino",
        version: "0.5.2"
      }
    ]
  end
end

Building the firmware directly from the source following the steps below results in the RPI 4 to continue blinking but not connecting to the WIFI (seen from network scan)

# Set the MIX_TARGET to the desired platform (rpi0, bbb, rpi3, etc.)
$ export MIX_TARGET=rpi4
$ mix deps.get
$ mix firmware
$ MIX_TARGET=rpi4 NERVES_WIFI_SSID='$WIFI' NERVES_WIFI_PASSPHRASE='$PASS' mix burn
I tried option 2 as well after booting the compiled install as well but it disconnects from the ip address and does not run the process at port 80
# Option 2: Upload to an existing Nerves Livebook device
$ mix firmware.gen.script
$ ./upload.sh [email protected]

The [compiled release] (https://github.com/livebook-dev/nerves_livebook/releases/download/v0.5.7/nerves_livebook_rpi4.fw ) works great but I can't modify the mix.exs to include a phoenix client library I need to directly communicate to websockets

At the moment, the mix.lock file is set to cowlib 2.9.1 and this version works. Something changed with cowlib 2.11.0 that causes rebar3 to not build any cowlib .beam files. You can see this by updating to 2.11.0 (mix deps.update --all is easiest) and then looking in _build/.../lib/cowlib/ebin. Only the .app file is there. Since this is not an error, firmware is made, but it will fail to boot since modules can't be loaded.

Building with Elixir 1.11.4 and cowlib 2.11.0 works fine.

The original thought was that this was due to using an old version of rebar3. This was the case, but updating it did not fix the issue:

$ rebar3 --version
rebar 3.14.4 on Erlang/OTP 23 Erts 11.2

I'm able to reproduce this on OSX and Linux computers and I have cleared both of all rebar3 binaries that are not 3.14.4. The only ones left are the ones installed by mix local.rebar.

So far I have been unable to reproduce this issue on smaller projects. I was suspecting that it might have something to do with Mix targets, but that doesn't seem to be the case. The only other hint may be that Nerves sets some environment variable that interferes with whatever changed in mix's invocation of rebar3.

Currently, the welcome.livemd mentions in the "Limitations" section:

Installing hex dependencies is not supported.
Nerves Livebook includes many libraries as a convenience, though.

I'm not sure of the correct way to introspect on this from a nerves installation (this is my first time playing with one), if any (as Mix.Project.config()[:deps] obviously doesn't work in this context).

I think a better approach anyhow would be to document the full list of the added convenience libraries, though, with outbound links to their hex docs, and maybe a synopsis of their utility, straight in the welcome page.

Show the basics of logging in over ssh and copying files using sftp. It might be nice to add the one liner to do a firmware update over ssh (see ./upload.sh) for the one liner.

I'm not sure what device to use, but it would be cool to get a simple tutorial that shows how to detect a device and doing doing something simple with it.

Currently the livebook code isn't tested for regressions. I am not sure this is possible for Nerves livebooks, but it would be useful to know that all of the livebooks in the samples continue to work. I think that it's worth some thought.

Notes:

• Livebooks do support unit tests: https://github.com/elixir-nx/livebook/pull/153/files
• I'm not sure how to run a Livebook offline

Cloned, installed deps, ran with MIX_ENV=prod mix phx.server and get the following stacktrace:

➜  nerves_livebook git:(main) ✗ MIX_ENV=prod mix phx.server
[Livebook] Application running at http://Brians-MacBook-Pro.local:8080/
[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed
{"Kernel pid terminated",application_controller,"{application_start_failure,livebook,{bad_return,{{'Elixir.Livebook.Application',start,[normal,[]]},{'EXIT',{function_clause,[{'Elixir.Livebook.Hubs',to_struct,[#{hub_emoji => <<240,159,143,160>>,hub_name => <<\"My Hub\">>,id => <<\"personal-hub\">>,secret_key => <<\"VPWFZp_IVJA7dpKu7-d7nZfbYStjOHDnDNvPx_OlYTBCkY5sucwxKb-eSvDDB61sPuRloddV8O_91UwsbnZ2gA\">>}],[{file,\"lib/livebook/hubs.ex\"},{line,147}]},{'Elixir.Livebook.Hubs','-get_hubs/0-fun-0-',2,[{file,\"lib/livebook/hubs.ex\"},{line,21}]},{'Elixir.Enum','-reduce/3-lists^foldl/2-0-',3,[{file,\"lib/enum.ex\"},{line,2468}]},{'Elixir.Livebook.Hubs',get_hubs,0,[{file,\"lib/livebook/hubs.ex\"},{line,20}]},{'Elixir.Livebook.Hubs',connect_hubs,0,[{file,\"lib/livebook/hubs.ex\"},{line,170}]},{'Elixir.Livebook.Application',start,2,[{file,\"lib/livebook/application.ex\"},{line,57}]},{application_master,start_it_old,4,[{file,\"application_master.erl\"},{line,293}]}]}}}}}"}
Kernel pid terminated (application_controller) ({application_start_failure,livebook,{bad_return,{{'Elixir.Livebook.Application',start,[normal,[]]},{'EXIT',{function_clause,[{'Elixir.Livebook.Hubs',to_struct,[#{hub_emoji => <<240,159,143,160>>,hub_name => <<"My Hub">>,id => <<"personal-hub">>,secret_key => <<"VPWFZp_IVJA7dpKu7-d7nZfbYStjOHDnDNvPx_OlYTBCkY5sucwxKb-eSvDDB61sPuRloddV8O_91UwsbnZ2gA">>}],[{file,"lib/livebook/hubs.ex"},{line,147}]},{'Elixir.Livebook.Hubs','-get_hubs/0-fun-0-',2,[{file,"lib/livebook/hubs.ex"},{line,21}]},{'Elixir.Enum','-reduce/3-lists^foldl/2-0-',3,[{file,"lib/enum.ex"},{line,2468}]},{'Elixir.Livebook.Hubs',get_hubs,0,[{file,"lib/livebook/hubs.ex"},{line,20}]},{'Elixir.Livebook.Hubs',connect_hubs,0,[{file,"lib/livebook/hubs.ex"},{line,170}]},{'Elixir.Livebook.Application',start,2,[{file,"lib/livebook/application.ex"},{line,57}]},{application_master,start_it_old,4,[{file,"application_master.erl"},{line,293}]}]}}}}})

The idea is it should be possible to write a short program in Elixir that runs indefinitely in Nerves Livebook. For an Arduino, this would be filling in setup() and loop() functions. I am not sure how this best maps to Elixir, but I think that it would be pretty neat.

If anyone has ideas, feel free to add to this issue or link to a proof-of-concept.

When the regular Livebook got a new release, the update banner in Nerves Livebook gets triggered.

Since Livebook and Nerves Livebook don't have matching version numbers and release dates, this is misleading and confusing.

The update check happens in this GenServer:
https://github.com/livebook-dev/livebook/blob/main/lib/livebook/update_check.ex

A simple solution would be to make the github release url and the application name configurable using application config so that Nerves Livebook can set its own values.

@fhunleth pointed out that it would also be nice if the user can interact with the update banner to trigger a firmware update.

Currently the firmware update script is hardcoded to "latest". It should be easy to change a variable to point it at a specific version just in case the "latest" doesn't work well.

The home page Explore section should include /data/livebooks/welcome.livemd to direct the first-time user to Nerves Livebook specific information.

Create a live book with a manifest of hardware. Maybe in a format similar to

It seems like it should be possible to stream video to a Livebook with picam.

Fun features would be:

• Changing the filter
• Changing sizes
• Text overlays

Picam can be set to stream a motion JPEG so a web page with an image tag is sufficient to show the results. I'm not sure how to put the image tag in the Livebook page so that it works, though. It might be that a separate browser window is needed where the user can hit reload for they start and stop whatever GenServer is streaming the image to the image tag.

I haven't looked into this, yet, but if you click on the Nerves explore notebook and then try any of the links in it, they won't work. The links are all relative ones and it looks like there either needs to be a way to specify a base path or they need to be made into absolute ones.

After following the normal instructions and verifying my versions locally.

when running mix firmware (from main), the process errors out with this error:
(Mix) Nerves encountered an error. %IO.Stream{device: :standard_io, raw: true, line_or_bytes: :line}

to fix, i edit in my mix.exs and change the nerves_bootstrap version to be 1.9 and it works fine.

i'm not sure if 10 is working & is live or not. but I couldn't get it to work and would like to if someone could help with this.

x86_64 board is Qemu.
nerves_livebook v0.11.0

$ git clone https://github.com/nerves-livebook/nerves_livebook.git
$ cd nerves_livebook
$ export MIX_TARGET=x86_64
$ mix deps.get
$ mix firmware.image

start script

"C:\Program Files\qemu\qemu-system-x86_64.exe" -drive file="nerves_livebook.img",if=virtio,format=raw -m 4098 -net nic,model=virtio -net user,hostfwd=tcp::10022-:22,hostfwd=tcp::80-:80 -serial stdio

doesn't work module

• Kino.Mermaid
• Kino.Download
• kino.Tree
• kino.DataTable
• socket
• explorer
• maplibre
• vegalite

Our BMP280 example added in #21 has a bunch of images that are adopted from Wikipedia etc. Ideally we want to take our own images and keep them in the local file system.

#21 (comment)

I'm not sure what the most user friendly way of doing this will be. Perhaps something like this:

/data/livebooks/readme.livemd - An intro
/data/livebooks/examples - Symlink to the readonly example Livebooks in the priv directory

If the symlink ends up making it annoying to save your own livebooks, then perhaps the right answer is to copy the example livebooks over and mark the directory and files read-only to avoid overwriting user modifications.

Hi!
Thanks for Nerves Livebook🚀🚀🚀
I like it!

nerves_livebook_rpi4.fw(v0.5.0) does not show a graph.

Environment

• nerves_livebook_rpi4.fw
• v0.5.0

Current behavior

1. I download and burn into microSD: fwup nerves_livebook_rpi4.fw
2. Run Raspberry Pi 4 with microSD burned nerves_livebook_rpi4.fw
3. http://localhost:4000
4. EXPLORE > See all > Plotting with VegaLite
5. Evaluate, Evaluate
6. Evaluate Basic concepts

It does not show a graph.

Expected behavior

It shows a graph.

• Livebook 0.5.1 works well.
• Nerves Livebook v0.4.2 works well.

It should talk about:

• The default start time and how it's more recent than 1970 (Unix time zero)
• NTP
• Timezones - pull in nerves_timezones so that it's possible to get local time on the device

Description

Not the first time I've seen some buzz around NeoPixel LED's.

A basic single strip example would probably suffice the first time around.

Would recommend using the library blinkchain by Greg Mefford's as a starting example.

Maybe a future book would be to use i2c on a leader/follow setup to control more than 2 pwm channels.