Metaissue: Devices responding with an unknown serial number (UNKWN*) or 0% battery #2122

lah7 · 2023-09-09T11:21:18Z

There are few identical issues popping up with the same root problem. This issue will link them.

Cause

The daemon responds with a serial number like UNKWN00000000XXXX or battery status as 0%. This might be random or consistent.

Command timed out appears in the kernel log:

dmesg | grep razer

Symptoms

After reboot, persistent settings are not applied - like poll rate, brightness or effect.
Battery notification incorrectly says the device reached 0% battery.
Battery % is incorrect in applications.
Rarely, some items (e.g. DPI) reports the wrong value.

Workarounds

(a) For incorrect start-up settings, write a script like the following, mark as executable and add it to your start-up applications.

#!/usr/bin/python3
import time
import openrazer.client
devman = openrazer.client.DeviceManager()

# Optional - wait for 2 devices
while len(devman.devices) < 2:
    time.sleep(0.5)
    devman = openrazer.client.DeviceManager()

for device in devman.devices:
    if "Basilisk" in device.name:
        device.dpi = (400,400)
        device.fx.misc.logo.wave(1)

    if "Huntsman" in device.name:
        device.fx.static(0, 255, 0)  # Green static

(b) Turn off persistence in razer.conf if the device is capable of retaining settings across power cycles and you don't dual boot.
(c) Run openrazer-daemon -r and any re-open applications connected to the daemon. The device might report the right serial this time.

Future Solution

At the moment, it's because the device didn't send a valid response, so the driver generates a dummy serial to prevent applications and scripts from crashing. It's theoretically possible that a handful of devices are incapable of reading their serial number, or are unreadable under certain connections (e.g. wired vs wireless)

In future, the driver will introduce a retry mechanism to send the request again.

To check

cat /sys/bus/hid/drivers/razer*/*1532*/device_serial

Serials should not start with UNKWN. If you're affected, please let us know which devices are intermittent or always wrong - just in case there is a problem with that device's implementation.

There is one Razer device with a serial that literally said As printed in the D cover.

Handle "Default string" serial number (Razer Blade) #192

Affected Devices

Basilisk Ultimate
- Settings not persisting after reboot on PopOS 22.04 LTS polychromatic/polychromatic#523
DeathAdder V2 X Hyperspeed
- Settings won't apply correctly after reboot #2048
DeathAdder V3 Pro
Naga Pro
Orochi V2
Viper Ultimate
- saving issue #2076
Viper V2 Pro
- Viper V2 Pro Polling rate reverting on reboot polychromatic/polychromatic#493

Related Issues

Persistence issue: Devices spontaneously reset to Spectrum if serial is incomplete #1367

The text was updated successfully, but these errors were encountered:

h0x32 · 2023-12-24T03:52:21Z

I can confirm same behavior on Orochi V2:
1532:0094 Razer USA, Ltd Orochi V2

Adam-Englebright · 2024-01-31T19:44:26Z

I had this issue using the DeathAdder V3 Pro (Wireless). However, for me the issue only occurs if I don't touch my mouse during boot up (so it is sleeping), then move the mouse once I am at the desktop. If I continually move my mouse during boot up, so that it tries to connect to the USB dongle as soon as possible, I seem to avoid this issue.

Debian Bookworm using the openrazer-meta package from the stable repo, version 3.5.1+dfsg-2.

z3ntu · 2024-02-09T12:44:28Z

@Adam-Englebright That's some interesting info, I wonder if we can somehow check if the device is responding during init (or asleep) and delay initialization until we have connection.

pdf · 2024-02-15T09:18:29Z

Device: 0003:1532 RazerViperUltimateWireless / RazerViperUltimateWired

When both the wireless dongle and the wired cable are connected (e.g. when charging), only one of the devices reports a serial number via sysfs, the other is blank.

When plugging in the second device, the daemon throws an exception:

openrazer-daemon[1423]: Exception in thread Thread-14 (_collecting_udev_method):
openrazer-daemon[1423]: Traceback (most recent call last):
openrazer-daemon[1423]:   File "/usr/lib/python3.11/threading.py", line 1045, in _bootstrap_inner
openrazer-daemon[1423]:     self.run()
openrazer-daemon[1423]:   File "/usr/lib/python3.11/threading.py", line 982, in run
openrazer-daemon[1423]:     self._target(*self._args, **self._kwargs)
openrazer-daemon[1423]:   File "/usr/lib/python3.11/site-packages/openrazer_daemon/daemon.py", line 605, in _collecting_udev_method
openrazer-daemon[1423]:     self._add_device(d)
openrazer-daemon[1423]:   File "/usr/lib/python3.11/site-packages/openrazer_daemon/daemon.py", line 530, in _add_device
openrazer-daemon[1423]:     razer_device = device_class(device_path=sys_path, device_number=device_number, config=self._config,
openrazer-daemon[1423]:                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
openrazer-daemon[1423]:   File "/usr/lib/python3.11/site-packages/openrazer_daemon/hardware/device_base.py", line 136, in __init__
openrazer-daemon[1423]:     super().__init__(object_path)
openrazer-daemon[1423]:   File "/usr/lib/python3.11/site-packages/openrazer_daemon/dbus_services/service.py", line 57, in __init__
openrazer-daemon[1423]:     self.add_to_connection(bus, object_path)
openrazer-daemon[1423]:   File "/usr/lib/python3.11/site-packages/dbus/service.py", line 579, in add_to_connection
openrazer-daemon[1423]:     connection._register_object_path(path, self._message_cb,
openrazer-daemon[1423]: KeyError: "Can't register the object-path handler for '/org/razer/device/PM1234H12345678': there is already a handler"

So it seems the daemon does see the serial.

Subsequent (frequent) battery notifications display 0% , with timeouts in dmesg.

Plugging in only wired or only wireless dongle results in the single device successfully reporting a serial correctly.

z3ntu · 2024-03-03T11:40:51Z

openrazer-daemon[1423]: KeyError: "Can't register the object-path handler for '/org/razer/device/PM1234H12345678': there is already a handler"

We don't support connecting a device two times, as you can see it breaks some assumptions OpenRazer has. We probably need to fix this in the future but it's not a simple fix as everything relies on the serial number being unique.

NeilGirdhar · 2024-05-13T17:59:14Z

Linking related PR: #2248

chuckie987 · 2024-07-10T02:20:57Z

Hi Team,
Having this issue, not with the battery % but the polling rate, DPI and colour settings never being persistent and creating a new "UNKWN" serial number every boot

Viper Ultimate (Wireless)
Running Mint 21 and/or Mint 22

[UNKWN000000003042]
dpi_x = 1400
dpi_x = 1400
poll_rate = 1000
logo_active = True
logo_brightness = 75
logo_effect = spectrum
logo_colors = 0 255 0 0 255 255 0 0 255
logo_speed = 1
logo_wave_dir = 1

[UNKWN000000002007]
dpi_x = 1400
dpi_x = 1400
poll_rate = 1000
logo_active = True
logo_brightness = 75
logo_effect = spectrum
logo_colors = 0 255 0 0 255 255 0 0 255
logo_speed = 1
logo_wave_dir = 1

CKr0nzz · 2024-07-10T13:04:45Z

I'm having the same issue with Razer Basilisk Ultimate, settings are not persistent. I have to manually reset the poll rate and brightness level at every reboot.

Adam-Englebright · 2024-07-10T13:19:11Z

@chuckie987 @CKr0nzz
Have you tried moving the mouse around when booting? This still "fixes" the issue for me using the DeathAdder V3 Pro (Wireless). If I first move the mouse after booting up and logging in, then I'll get an UNKWN serial and default settings.

chuckie987 · 2024-07-11T04:10:54Z

@chuckie987 @CKr0nzz Have you tried moving the mouse around when booting? This still "fixes" the issue for me using the DeathAdder V3 Pro (Wireless). If I first move the mouse after booting up and logging in, then I'll get an UNKWN serial and default settings.

I tried giving this a go constantly moving the mouse before during and after boot but didnt help with my Viper Ultimate, Currently Running Mint 22
Daemon 3.8.0
DKMS 3.0.11

CKr0nzz · 2024-07-11T12:42:10Z

That's regardless if the "restore software settings" is checked or not.

I also noticed that the mouse keeps the settings from the previous shutdown, it only resets when the daemon boots up. Uninstalling might be the solution haha.

m0mosenpai · 2024-07-24T13:10:21Z

Can confirm the issue happens on DeathAdder V3 Pro Wireless after a reboot. (openrazer-driver/3.8.0, 6.10.0-arch1-2, x86_64). Disconnecting and reconnecting the dongle seems to fix it for the rest of the session. You can see it get the malformed serial number in the logs till you reconnect and the errors stop.

While it's in the malformed state, the mouse will goto sleep almost instantly, once you stop using it. Moving it again for a couple of seconds gets it connected again and working fine, but only as long as you keep moving it.

Adam-Englebright · 2024-07-27T16:39:06Z

I've just discovered that this issue occurs if I switch from wired mode (for charging) to wireless mode during general PC usage, causing my ~~DPI~~, polling rate etc. to be reset to defaults (edit: it seems only polling rate and low power mode threshold get reset, to 500Hz and 0%. DPI and sleep mode timeout are persistent). However, the issue does not occur when switching from wireless mode to wired mode. When connecting the mouse directly via wire, even when hot plugging, the correct serial is identified and the appropriate settings applied.

Now on Arch using v3.8.0.

lah7 added bug help wanted not stale Label for issues the Stale bot shouldn't close labels Sep 9, 2023

lah7 pinned this issue Sep 9, 2023

lah7 mentioned this issue Sep 9, 2023

Viper V2 Pro Polling rate reverting on reboot polychromatic/polychromatic#493

Closed

lah7 mentioned this issue Sep 19, 2023

Razer Baslisk Essential - DPI Speeds Are Fast #2132

Open

TriMoon mentioned this issue Oct 16, 2023

Razer Naga Pro (Wired) shows up twice #2101

Open

lah7 mentioned this issue Feb 3, 2024

random popups on debian testing (xfce) for razer pro click with wrong information #2203

Closed

burd1 mentioned this issue Apr 5, 2024

Razer DeathAdder V3. Wrong pooling rate after reboot. #2223

Open

z3ntu mentioned this issue May 10, 2024

Spurious battery level notification #2247

Closed

2 tasks

lah7 mentioned this issue Jul 30, 2024

Settings not persisting after reboot on PopOS 22.04 LTS polychromatic/polychromatic#523

Closed

lah7 mentioned this issue Aug 23, 2024

Unable to Retrieve Battery Level (Always Returns 0%) for Razer Basilisk Ultimate Mouse #2290

Open

11 tasks

lah7 mentioned this issue Sep 1, 2024

Mouse DPI resetting on every boot polychromatic/polychromatic#528

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Metaissue: Devices responding with an unknown serial number (UNKWN*) or 0% battery #2122

Metaissue: Devices responding with an unknown serial number (UNKWN*) or 0% battery #2122

lah7 commented Sep 9, 2023 •

edited

Loading

h0x32 commented Dec 24, 2023

Adam-Englebright commented Jan 31, 2024 •

edited

Loading

z3ntu commented Feb 9, 2024

pdf commented Feb 15, 2024

z3ntu commented Mar 3, 2024

NeilGirdhar commented May 13, 2024

chuckie987 commented Jul 10, 2024 •

edited

Loading

CKr0nzz commented Jul 10, 2024

Adam-Englebright commented Jul 10, 2024

chuckie987 commented Jul 11, 2024

CKr0nzz commented Jul 11, 2024

m0mosenpai commented Jul 24, 2024 •

edited

Loading

Adam-Englebright commented Jul 27, 2024 •

edited

Loading

Metaissue: Devices responding with an unknown serial number (UNKWN*) or 0% battery #2122

Metaissue: Devices responding with an unknown serial number (UNKWN*) or 0% battery #2122

Comments

lah7 commented Sep 9, 2023 • edited Loading

Cause

Symptoms

Workarounds

Future Solution

To check

Affected Devices

Related Issues

h0x32 commented Dec 24, 2023

Adam-Englebright commented Jan 31, 2024 • edited Loading

z3ntu commented Feb 9, 2024

pdf commented Feb 15, 2024

z3ntu commented Mar 3, 2024

NeilGirdhar commented May 13, 2024

chuckie987 commented Jul 10, 2024 • edited Loading

CKr0nzz commented Jul 10, 2024

Adam-Englebright commented Jul 10, 2024

chuckie987 commented Jul 11, 2024

CKr0nzz commented Jul 11, 2024

m0mosenpai commented Jul 24, 2024 • edited Loading

Adam-Englebright commented Jul 27, 2024 • edited Loading

lah7 commented Sep 9, 2023 •

edited

Loading

Adam-Englebright commented Jan 31, 2024 •

edited

Loading

chuckie987 commented Jul 10, 2024 •

edited

Loading

m0mosenpai commented Jul 24, 2024 •

edited

Loading

Adam-Englebright commented Jul 27, 2024 •

edited

Loading