OctoDash Failure to initialise after updating to OctoPi 0.18.0 & OctoPrint 1.8.3

Hi all.

I updated my three Raspberry Pi4 octopi installations yesterday to Octoprint 1.8.3 (OctoPi 0.18.0).

On the two installations where OctoDash wasn't connected to the printer, OctoDash failed to pass the initialisation screen when the system was restarted.

On the installation where OctoDash was up and running and had been connected to the printer before upgrading Octoprint, it was displayed 'port is dead', and when I rebooted that installation, it then got stuck on the initialisation screen like the other two.

Octoprint functions as per normal and I can print just fine via OctoPrint, but OctoDash is now broken and won't ever finish initialising.

In all cases I used the prompt in octoprint to update to the latest version.

Has anyone else had this issue and/or have a fix?

Here's part of the system info bundle for one of the installs. There's all identical setups. Happy to provide whatever other data/info is required.

browser.user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36
connectivity.connection_ok: True
connectivity.enabled: True
connectivity.online: True
connectivity.resolution_check: octoprint.org
connectivity.resolution_ok: True
env.hardware.cores: 4
env.hardware.freq: 1500.0
env.hardware.ram: 3960369152
env.os.bits: 32
env.os.id: linux
env.os.platform: linux
env.plugins.pi_support.model: Raspberry Pi 4 Model B Rev 1.2
env.plugins.pi_support.octopi_version: 0.17.0
env.plugins.pi_support.throttle_check_enabled: True
env.plugins.pi_support.throttle_check_functional: True
env.plugins.pi_support.throttle_state: 0x0
env.python.pip: 22.0.4
env.python.version: 3.7.3
env.python.virtualenv: True
octoprint.last_safe_mode.date: unknown
octoprint.last_safe_mode.reason: unknown
octoprint.safe_mode: False
octoprint.version: 1.8.3
printer.firmware: Prusa-Firmware 3.10.1 based on Marlin
systeminfo.generated: 2022-09-21T19:46:37Z
systeminfo.generator: zipapi

Are you using a global API key or application keys (or user-specific api keys)?

There seems to be a bug with using a global API key to get a websocket session in 1.8.3, so if you are using that then I would recommend switching to an application key.


Thanks, Charlie. That fixed it. I was using a global api key rather than individual application api keys.

For others with this same problem, following Charlie's steer, I resolved the issue as follows:

  1. I set up an application key for OctoDash in OctoPrint,
  2. I updated the OctoDash config via SSH with that new key,
  3. I rebooted the system and OctoDash initialised just fine.
1 Like