Skip to content
Get started

Shelly Wall Display X2i

WebView — Ships with: Chromium 131.0.6778.200 on firmware 2.5.4

Can reach: Chromium 131 — vendor only; no newer Shelly-signed provider available. This major no longer receives Chromium security fixes

Confidence
Photo: Shelly

The Wall Display X2i, firmware codename Jenna, is a 6.9 in 1440×720 panel on a Rockchip RK3326 (four Cortex-A35), Android 11, arm64-v8a. Shelly’s specification names the RK3326-S variant; the chip itself reports only the RK3326 family, which is consistent with that. It is on the modern WallDisplayV2 OTA track alongside the X1i, XL, Maverick and Dayna, and has access to the built-in AppStore.

Panel Assistant runs on it as an ordinary Android app. The measured setup and everyday controls work without root: installing, granting its own permissions, the sensors, brightness, taking over the home screen and, in the forthcoming Panel Assistant 1.0 release, switching the screen fully off and waking it again. The 2.8.2 development checks cover only the operations listed there. Root would still buy a few privileged extras, listed under What this firmware does not have. That makes the X2i the least restrictive Shelly Wall Display documented here and the only one with a confirmed installation path.

Shelly Wall Display X2i, firmware codename Jenna.

SoC RK3326-S per Shelly’s specification; the chip reports the RK3326 family, four Cortex-A35
Display 1440×720, 6.9 in, 240 dpi
Android 11 (API 30), arm64-v8a, user build
WebView Chromium 131.0.6778.200 as shipped, above Panel Assistant’s minimum; vendor only, with no newer Shelly-signed provider, and this major no longer receives Chromium security fixes
Sensors Proximity and ambient light, both ordinary Android sensors needing no permission; no temperature or humidity sensor
Microphone Built in; the wake word and voice commands work close to the panel, and pickup across a room is weak
Relay Interchangeable base: 1 output as standard, optional 2-output base. Confirmed switching without root; direct Panel Assistant control is in development; see Relays
Root None needed. Setup uses USB debugging; see the firmware-dependent developer-mode unlock
Released About December 2025 (est.); Shelly quietly released the X2i in Europe around 22 December 2025 (launch coverage, Notebookcheck, December 2025)

The hidden unlock below was confirmed on an X2i running earlier firmware, including 2.5.4. Its availability depends on firmware: an owner report on 2.8.4 says the About Device sequence no longer opens developer mode. That report does not establish permanent removal or the behaviour of every model. If it is unavailable, ask Shelly for the supported developer-mode procedure for your exact model and firmware before attempting installation.

On the confirmed firmware, open Settings → General → About Device and tap two specific labels in this order:

FW Version:, Hardware Revision:, FW Version:, FW Version:, Hardware Revision:, FW Version:, Hardware Revision:, Hardware Revision:

The X2i’s About Device screen. A Hardware Information card lists serial number, device ID, numeric device ID and hardware revision, with the first three values blanked out in this capture; a Software Information card below it lists FW Version, FW Date, WebView and WebView Version. Two row labels are outlined: Hardware Revision in the upper card and FW Version in the lower one. Below the cards sit a crash reports switch and a Check for update button.

Tap the two outlined labels themselves, rather than the values to their right or the card headings “Hardware Information” and “Software Information”. Correct tap targets do not guarantee that the unlock is available on your firmware.

The screen returns to the home view after a few seconds of inactivity, so tap at a steady pace rather than pausing to check between taps.

On the measured earlier firmware, Developer options and USB debugging then appeared in Settings. A USB-A to USB-C cable connected the panel to adb, with no authorisation prompt to accept on the screen. Those observations do not establish the same setup behaviour on later firmware.

There is no known way to turn on network ADB on the X2i without a computer, so, once USB debugging is available, install it over USB with the browser installer.

The browser installer completed against a factory unit over USB with no root: it sideloaded the app and granted every permission it needs, including accessibility, write-settings and overlay access. From there, Panel Assistant 1.0 finishes setting the X2i up for you:

  • It grants the one extra permission full screen-off needs. Shelly’s firmware keeps the screen on while the panel is powered, and the app needs permission to lift that while the screen is off and restore it afterwards. Panel Assistant grants it at setup and again after every update.
  • It sets the display size and text size that suit this screen, so the dashboard and the panel’s own pages are the right scale from the first boot.
  • It switches off Shelly’s corner overlay, the small Shelly control that the firmware otherwise draws over every app, so the dashboard is clean. Shelly’s own interface stays reachable: the launcher button on Panel Assistant’s navigation bar lists it with the panel’s other apps.
  • It walks you through proximity setup. A few hand movements in front of the panel teach it what near and clear look like, which is what lets a wave wake the screen.

Two setup details are worth knowing before you start:

  • It does not configure Wi-Fi. A boxed panel has no network, and setup continues on the panel’s own screen, which needs one. Join the panel to Wi-Fi in Settings before or after the install.
  • Setup tries to make Panel Assistant the home app and checks the result. Follow any remaining chooser instruction if needed. Setting it as the home app works without root, and it holds home reliably afterwards. Shelly’s return-to-home watchdog does not take it back.

The forthcoming Panel Assistant 1.0 release switches the X2i’s backlight fully off through Shelly’s local Stargate API without root, while Android stays awake. The first wake gesture is consumed so it does not also operate the dashboard. Earlier releases could only dim the screen.

If Shelly’s password protection is enabled, its screen API requires Digest authentication. The current implementation falls back to Android’s own screen timeout. Home Assistant can turn the screen on again through that fallback.

The wake controls are:

  • Touch. A single touch wakes the panel; no double-tap is needed.
  • A wave or an approach. Panel Assistant watches the proximity sensor and wakes the panel when someone comes near. This requires proximity calibration through setup.
  • Home Assistant. Turn the panel’s screen on manually or from an automation.

Proximity calibration also lets the panel stay awake while someone remains nearby. These capabilities were established in the earlier measurements; the 2.8.2 development checks cover injected wake and Home Assistant recovery, with physical touch and proximity checks still outstanding. The X2i has no physical button or lock screen to get past after waking.

Proximity and ambient light are both exposed through the standard Android sensor API and need no permission. Panel Assistant reported reading proximity through its raw Sensortek route rather than the Android sensor, which its own diagnostics name as driver_raw16, and reports it as a ranged signal rather than a near or far flag. Either way it reads them as an ordinary app, with no privilege involved. The proximity sensor is registered as a wake-up sensor, and it keeps reporting while the screen is fully off, which is what makes waking on a wave possible. Both parts are Sensortek STK3A5x devices on the same I²C address.

The X2i has no physical buttons. The XL’s F1–F4 front-button map does not apply to this model.

The X2i has no temperature or humidity sensor, so no room-climate readings are available from the panel itself.

The X2i’s power base exposes /sys/class/strelay/relay1 and relay2, with world-readable and world-writable permissions. Unprivileged writes audibly switched the contacts on the measured unit. Direct Panel Assistant relay control is in development, using these files as an ordinary app when the selected profile declares the route and the running app can read and write it. This is not a capability of the current public release or a claim about every Shelly model.

Two conditions apply to this measured route:

  • Relays are inert while the panel is powered over USB. They need mains through the power base.
  • The unprivileged write succeeds only because this firmware ships with SELinux in permissive mode. A future firmware that enforces policy would block it regardless of file permissions.

For the current public release, drive the relays through Home Assistant’s own Shelly integration.

  • No Recents at all. The firmware ignores the Recents key, and Android’s accessibility Recents action does nothing either, each tested with an ordinary app and with Settings in front. The reason is below both of them: the system logs that the recents task directory does not exist, so no route can produce a task switcher. Panel Assistant offers Back and Home on this panel, and no Recents control.
  • No camera. The firmware declares camera features that no hardware backs, and Android enumerates no camera. Nothing declares a camera in the profile either, so Panel Assistant correctly offers none here.
  • No root. There is no su and no way to become root from the shell. Setting the panel up and using it day to day does not need it, and Panel Assistant installs and updates the app on this panel without it. A few features do stay unavailable: rebooting or switching back to the vendor launcher from the panel. Android 11 or newer can also provide screenshots and taps through the enabled Accessibility service without root; remote taps remain subject to security settings. The onboard relays are a separate matter, covered above.

Firmware, and why the shipped version matters

Section titled “Firmware, and why the shipped version matters”

The unit examined here arrived factory-fresh on 2.5.4, was later updated to 2.7.4, and now runs 2.8.3. The observed 2.7.4 update changed device ownership without interrupting Panel Assistant:

  • On 2.5.4 there is no device owner and no device administrator at all.
  • 2.7.4 installs Shelly’s launcher as the device owner. On the unit examined here that took nothing from Panel Assistant: it stayed the home screen, kept running and stayed online in Home Assistant, and the device owner imposes no restrictions on other apps. Shelly’s launcher cannot be disabled on either firmware.
  • 2.8.3 keeps the same device owner, still with no restrictions. Its ownership files are unchanged from 2.7.4, and Shelly’s launcher does not stop other apps from being installed, using adb or running an accessibility service. On 2026-10-15 a fresh install of a Panel Assistant 1.0 preview build through Home Assistant’s network route completed on 2.8.3, and the panel went on to show its Home Assistant dashboard.

As checked on 2026-10-12, both firmware tracks offer stable 2.8.3, build 20261012-141904/2.8.3-48174502c, with no beta offered. On 2026-10-13, one X2i running 2.8.3, build 20261012-141904/2.8.3-48174502c, was checked with a signed development build for the forthcoming Panel Assistant 1.0 release. The vendor firmware update preserved the app settings, home-screen selection and Home Assistant connection. The measured operations below were also checked on 2.8.2, build 20261008-101206/2.8.2-7bb488885:

  • Settings restore: 84 supported settings restored, with boot-chime suppression and network ADB explicitly unavailable and skipped. No restore failure or rollback failure was reported. An actual restore was checked on 2.8.3 after the vendor update.
  • Updating through Panel Assistant, on 2.8.2 only: a normal in-place update completed through Home Assistant, with Android’s Install confirmation accepted. The app kept its settings and remained the home screen, and Home Assistant reported it healthy afterwards. No reboot, reset or uninstall was needed. This route has not been qualified on 2.8.3.
  • Startup and reboot brightness: the requested brightness survived startup and reboot. After API screen-off and an injected wake, brightness held at 5 and 30 seconds; when brightness commands overlapped, the newest command won. The first injected gesture was consumed rather than opening the dashboard menu beneath it.
  • Screen control: API screen-off worked with Shelly authentication disabled. With password protection enabled, Android sleep provided the fallback and Home Assistant screen-on recovered the panel after password protection was removed. An injected tap did not wake the sleeping panel in that test; physical touch wake with password protection remains unqualified.

These tests cover those operations only, and the fixes belong to the forthcoming 1.0 release. They do not establish full compatibility with either firmware or availability in the current public release. Real-finger touch and paired near/far proximity and ambient-light measurements remain to be qualified. The proximity driver was healthy, but still required calibration. Include your firmware version when reporting a problem after an update.

Since 2.8.0, modern models offer Uninstall all updates to return to their shipped vendor-app version. This unit’s shipped 2.5.4 is older than 2.6.2, so Shelly says that operation also resets factory defaults. Keep separate Panel Assistant and Shelly settings backups first; neither is a complete Android restore image. Preservation of Panel Assistant through the operation has not been verified. See the family recovery notes for the exact limits.

See the Wall Display family page for the OTA endpoints on the WallDisplayV2 track and the firmware version history.

For completeness, and not because Panel Assistant needs any of it:

  • adb reboot loader puts the panel into Rockchip loader mode, where the partition table reads out cleanly. Reads past the first 32 MiB silently return filler while still reporting success, so this route cannot produce trustworthy full-partition images. Check what you read rather than trusting an exit status.
  • Maskrom mode refuses an unsigned loader: the boot ROM enforces a signature.
  • The bootloader reports itself as secure and locked, yet Android Verified Boot is not enforced, which is why the community’s root route is writing a patched boot image rather than unlocking anything. That route overwrites the running boot partition and no vendor image exists to restore it, so it is not reversible.

Shelly Wall Display X2i knowledge base.

Comments

Comments are kept in this page's discussion on GitHub, so loading them connects your browser to GitHub. This browser remembers the choice and loads comments on other pages when you scroll down to them.

We Home Assistant and everything the Open Home Foundation does.

Last updated:

Release notes · Build 439 · b7d569d