Skip to main content

Update/Restore using Type-C

IMPORTANT NOTIFICATION FOR USERS WITH "BRICKED" DEVICES

Some users experienced a a "bricked"  device after updating over any method (Type-C / SD-Card or through the web UI). This issue appeared because of U-Boot changes introduced in version version 0.2.0, when the Robust Auto-Update Controller ("RAUC") was introduced.
Users who experienced that were able to recover their "bricked" device by flashing back back 0.1.2 via Type-C (because it did not contain the new RAUC changes [by the way, it is here here smhub-os-v0.1.2]) and then updating directly to a 0.3.x  version via Type-C.

Below is a simple explanation of what happened and how it was fixed.

When the device turns on, the very first piece of software that runs is called called U-Boot. You can think of it like the the “starter” or  or boot manager  of the device. Before anything else loads, U-Boot reads some some settings  (called “environment variables”) from the internal storage (the MMC). These settings tell it it how to start the system.

At some point,  RAUC  (stands for "Robust Auto-Update Controller" -  the Linux update system on SMHUB) accidentally accidentally damaged/corrupted those settings. When U-Boot tried to read them, it got confused and didn't know how to continue booting properly, and the device failed to boot - which looked like it was “bricked.” (for regular start, or for Type-C/SD-Card updates).

What Was Changed:

To prevent this from ever happening again, we made two fixes:
1.  Automatically reset U-Boot's settings  whenever they are detected as corrupted. In simple terms: If U-Boot sees that its configuration is broken, instead of crashing or getting stuck, it will throw away the bad settings and restore working default settings - before any damage happens.
2. We also corrected how RAUC marks a software update as “successful.” It will now only do that that after an update actually happens, instead of doing it on on every boot. The old behavior is likely what caused the corruption.

Simple Analogy:
- Imagine a PC that reads its BIOS settings when it powers on.
- If the BIOS settings get corrupted, the PC might not start.
- The fix is to detect the bad BIOS settings and and automatically reset to “factory defaults”  so the computer can continue to boot normally.
This is exactly what we are doing here, but for an embedded device.

The good news: starting from SMHUB-OS OS v0.3.2, the fix is now built-in. You can simply update and recover your device via Type-C / SD-Card.
(See details below below https://smlight.tech/support/manuals/books/smhub/page/smhub-os-release-notes#bkmrk-smhub-services-v0.1.-1)

Your device is now:
- More robust
- Self-recovering
- Protected  from this type of failure in the future

Flashing over Type-C

🎥 Video Walkthrough Introduction

Before you begin, we highly recommend watching the the video walkthrough — it shows the entire flashing process from start to finish in real time. In the video, you’ll see exactly what happens on screen and on the SMHUB device

image.png

⚙️ What You’ll Do

  1. Download the ZIP file with firmware

  2. Unzip it

  3. Install the driver

  4. Open CMD as Administrator

  5. Go to the folder with flash.bat

  6. Run flash.bat

  7. Only then connect SMHUB to the PC

  8. Wait for flashing to finish

  9. Wait for first boot (LED cues)

🚫 Before You Start

You’ll need:

  • Windows 10 or 11 PC with administrator access (we did tests on Win11)

  • USB-C data cable (not just charging)

  • The firmware ZIP file (from the link below)

Do NOT:

  • Connect the SMHUB before starting flash.bat

  • Skip the driver installation

  • Run CMD without Administrator rights

🔴 Common user errors:

  1. Connecting SMHUB before flash.bat starts

  2. Not installing the driver

  3. Not running CMD as Administrator

1) Download the factory firmware file

2) Unzip the archive

  • ight-click the ZIP file →  Extract All… → choose a simple path (e.g., C:\SMHUB\firmware\)
    (Avoid paths with non-Latin characters or very long names.)

  • You should now see these files/folders inside the extracted directory:

    • driver\smhub-driver.exe

    • rom\emmc.img

    • rom\fip.bin

    • rom\partition_gpt.xml

    • usb_dl.exe

    • flash.bat

    • cv_dl_magic.bin

image.png

3) Install the driver

  1. Open the driver folder.

  2. Double-click smhub-driver.exe.

  3. Complete the installation wizard. Allow the installer in Windows security prompts if shown.

  4. When it says Finished, close the installer.

If Windows asks for permission to install device software, click Install.

image.png

image.png

4) Open Command Prompt as Administrator

  • Press Win key, type cmd.

    image.png

  • Right-click Command Prompt → Run as administrator.
    image.png

  • The title bar must say Administrator: Command Prompt.

    image.png

You’ll know it’s correct if the window title says Administrator: Command Prompt.

5) Go to the extracted folder

In the admin CMD, change directory to the folder with flash.bat. For this purposes, type cd C:\SMHUB\firmware  and press Enter.

Hint: if your path is long for typing, copy it, and in CMD enter cd + do right click. This will insert Clipboard content into CMD window.

image.png

6) Start the flashing script

Important: Do not connect the SMHUB yet. The script need to be run first.

Run:  
flash.bat

By typing this command flash.bat  and pressing Enter button.

image.png

7) Now connect the SMHUB

When flash.bat is running, connect SMHUB to the PC via USB-C (Type-C port on the back of SMHUB, near Ethernet port)


The script will detect the device and begin flashing automatically. You’ll see progress output in the CMD window.

If nothing happens for ~a while, try another USB port or USB-C cable, but keep the script running while you reconnect the cable.

image.png

8) Wait for “Flashing completed” (script finishes)

  • When the script completes, it will show a success message and return to the prompt or close.

    image.png

  • You can now safely disconnect the SMHUB from the PC and power it normally (via its regular power supply), or leave USB-C connected if it provides power.

8-b) IF THE FLASHING PROCESS DOES NOT START

In some cases, removing the PoE add-on may help to start the flashing process successfully. If your device does not start flashing using either the Type-C or SD-Card method, please follow the steps below:

  1. Open the enclosure (no screwdrivers are required, as the enclosure is screwless).

  2. Physically disconnect the PoE add-on.

    image.png

  3. To be even more secure, please remove 4G and Z-Wave addons if you have them installed.

  4. Start the flashing process again.

Try to boot without the add-on first. Once the device flashes and boots successfully, you can reinstall the add-on.

9) First boot and LED cues (what “ready” looks like)

First start takes longer than subsequent boots. This is normal.

When the SMHUB starts up after flashing, the LEDs show you exactly what’s happening.
Here’s what to watch step by step:

  1. Power ON indicator:
    As soon as you plug in the SMHUB, the small green LED near the buttons (not the Ambilight LEDs) turns ON.
    → This simply means the device is receiving power. If you can't power your device - check this bug.

    image.png

  2. Blue chase effect (Ambilight):
    Right after powering on, you’ll see a moving blue light (chase effect) running around the Ambilight LEDs.
    → This means the system is booting — please wait.
    smhub-rotating.gif

  3. Blue effect stops:
    When the blue chase effect stops, it means the core system has finished booting and SSH access is available.
    → From this point, advanced users can connect via SSH if needed.

image.png

  1. Green Ambilight turns on:
    After a short delay, all green Ambilight LEDs will light up at once.
    → This means that Web UI and all apps are fully loaded and ready to use.

    image.png


    The green lights will stay on for about 1 minute, then turn off automatically.

💡 In simple words:

  • Blue moving lights = starting up

  • Blue stops = system ready for SSH

  • Green lights = Web interface ready to use

10) (Optional) Quick post-flash checks

Web UI:

  • Open a browser and go to: http://smhub.local/ (or your device’s IP).


    image.png

      

SSH (from Windows using built-in OpenSSH or PuTTY):

  • Hostname: smhub.local (or your device’s IP)

  • Username: smlight

  • Password: smlight

Troubleshooting

A) The script doesn’t detect my device

  • Most likely cause: Device connected before flash.bat.
    Fix: Close the script, unplug SMHUB, re-run steps 4–7 exactly: admin CMD → flash.bat → then connect SMHUB.

  • Try a different USB port or another data-capable USB-C cable.

B) Driver didn’t install or Windows blocked it

  • Re-run driver\smhub-driver.exe as admin.

  • Approve any Windows prompts.

  • Reboot Windows if the installer requests it, then try again.

C) “Access denied” or “cannot open port”

  • You’re likely not in an Administrator CMD. Close CMD, re-open as Administrator, repeat from step 5.

D) Flashing stops or errors out mid-way

  • Leave the CMD window open; wait a bit to ensure it’s not still working.

  • If it clearly failed, unplug SMHUB, close the CMD, reopen admin CMD, start flash.bat again, and only then plug SMHUB back in.

E) SSH/Web UI doesn’t come up after flashing

  • Give the device more time on the first boot.

  • Watch the LEDs:

    • Blue ambilight LED stopped running → SSH should be ready.

    • All ambilight greens lit → Web UI should be ready.

  • If still nothing, power-cycle the SMHUB and check your network/DHCP (try accessing by IP, not by hostname).

Back to top