dxp4800plus

[tbc0309]

# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         08 -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- -- 
40: -- -- -- -- 44 -- -- -- 48 -- -- -- -- -- -- -- 
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --  

[tbc0309]

# i2cdetect -l
i2c-0   i2c         Synopsys DesignWare I2C adapter     I2C adapter
i2c-1   smbus       SMBus I801 adapter at efa0          SMBus adapter
i2c-2   i2c         i915 gmbus dpa                      I2C adapter
i2c-3   i2c         i915 gmbus dpb                      I2C adapter
i2c-4   i2c         i915 gmbus dpc                      I2C adapter
i2c-5   i2c         i915 gmbus tc1                      I2C adapter
i2c-6   i2c         i915 gmbus tc2                      I2C adapter
i2c-7   i2c         i915 gmbus tc3                      I2C adapter
i2c-8   i2c         i915 gmbus tc4                      I2C adapter
i2c-9   i2c         i915 gmbus tc5                      I2C adapter
i2c-10  i2c         i915 gmbus tc6                      I2C adapter

[miskcoo]

It looks like that the device at 0x3a is occupied by a kernel module. Can you provide the outputs of lsmod and cat /sys/bus/i2c/devices/i2c-1/0-003a/name?

If your system is UGOS, you may find something like leds-mcu-xxxx in the output of lsmod. You can try to unload it using rmmod leds-mcu-xxxx and check the output of i2cdetect again. Otherwise, it is likely that this tool is incompatible with your device.

[shintiger]

My model is DXP 4800, my case is exact same as above I am using TrueNAS

lsmod | grep "leds-mcu" show nothing

cat /sys/bus/i2c/devices/i2c-1/0-003a/name no such file or directory

I have test the 0x3a is changed to UU after I ran ./scripts/ugreen-probe-leds with output I2C devices found ("led-ugreen 0x3a > ..."?) After this, running ugreen_led_cli is always return error code 16: device busy, but disk1,disk2 etc. is appeared in /sys/class/leds/

[miskcoo]

@shintiger The kernel module and the command-line tool are conflict.

• When using the kernel module, you will find LEDs in /sys/class/leds/, and the scripts in scripts directory are written for this case. You need to control the LEDs by writing data to files in /sys/class/leds. For example, to change the brightness of the power LED, run echo 233 > /sys/class/leds/power/brightness.
• If you want to use ugreen_led_cli, you need to unload the module rmmod led-ugreen.

[shintiger]

I got the idea, the issues is while I am using ZFS (TrueNAS SCALE), I copied this as /usr/bin/zpool-leds.sh https://github.com/miskcoo/ugreen_dx4600_leds_controller/issues/1#issuecomment-2143934931 This script is using ugreen_led_cli.

Is there any existing kernel module compatible zpool-leds.sh?

[miskcoo]

No. If you want to use ugreen_led_cli, you must not load any modules that will use 0x3a (i.e., led-ugreen in the repo, and leds-mcu-xxx in UGOS). Just directly run it.

Alternatively, you can change the script. For example,

ugreen_leds_cli ${map[$i]} -color 255 255 255 -on -brightness 128

is equivalent to

echo "255 255 255" > /sys/class/leds/${map[$i]}/color
echo "128" > /sys/class/leds/${map[$i]}/brightness

[shintiger]

So ZFS is not support at the moment?

[miskcoo]

As I mentioned, if you want to use ugreen_led_cli, you only need to unload the unnecessary modules like led-ugreen. Then, you will see that UU in i2cdetect becomes 3a.

If you want to blink the LEDs during disk I/O or network I/O, the current implementation requires using the led-ugreen module, which is not compatible with the script using ugreen_led_cli. A modification, however, is easy to implement.

[Kerryliu]

I have a brief write up here on how to get it running on truenas: https://gist.github.com/Kerryliu/c380bb6b3b69be5671105fc23e19b7e8.

Like @miskcoo mentioned, you can modify the script to blink on I/O activity instead of displaying zfs status. Assuming you use a while loop + sleep you would just leave the script running rather than a cron job (as described in the gist).

When I get the time/motivation, I'll poke at the kernel module and see if it works with TrueNAS in developer mode. By default TrueNAS heavily restricts you on what can/can't be modified.