tacocow

@Schubi05 I tested your update that includes initial iDX6011 Pro support. Here are my findings. Also, thank you for the super quick response and support addition. Note: I'm arcmodo. I changed my username. On testing the Identify on each drive. They all worked except disk3 for some reason. ERROR: disk3: invalid status block. Disks 1, 2, 4, 5, 6 identify and blink and 2, 4, 5, and 6 stop blinking on stop command, but bay 1 keeps blinking even with stop command. The disk3 error was because it was set to black. After resetting it to match the other disks (white for empty bays), it now pulses appropriately. After manually setting disk1 back to static/white, it stopped the pulsing. Next time I tried to identify and stop, it worked, but the first time the stop changed it from my setting of green to a default white. I reset it to green, then did identify and stop and it reverted to the original green color after the identify white pulse. Network LED by link speed is detecting the proper link speed (2.5G), but it isn't changing the LED color to match. It's sitting on the blue set in the LED settings above instead of changing to green for 2.5G. When I changed default mode from Manual to Status-based, the Network LED color did apply at that point. That really just looks like the Network LED by link speed only applies if you're using status-based mode. I just noticed the message, "with 'Manual’ its own colour applies", so that makes sense, but maybe some wording more specifically that the Network LED by link speed only applies in status-based mode? Other than the above, it's working great! Thank you for the super quick update to add support for the iDX6011 Pro. For reference, I tried the new plugin, and it's missing the case view image and says there isn't one available, but in the ugreen-led-control plugin, it shows the proper 6-bay image, albeit without the LED display on the right, but that's not a big deal unless you start supporting the LED display. I would suggest sticking with the 6-bay image until you can find/create one with the LED display included. I’ll mess around more with the new plugin shortly.

Any plans to support the iDX6011 Pro or variants? It almost works as-is. It's detecting the NAS, but it's listing 8 drive bays instead of the 6 that are actually there. It also doesn't reset the "MCU hardware marquee" where it cycles the drive bay LEDs 1 through 6 when you don't have UGOS running. There's a specific iDX6011 plugin, (GitHub) but it doesn't have the beautiful GUI you've created. I also realize the output below says 8 bays, but that's not actually true. My drives are in bays 1 and 2, and your plugin shows them in 3 and 4. Also, it can read the LED status because it reflects the drive bay LEDs cycling accurately. This is what Google claims: The standard ugreen-led-control plugin communicates via the "DXP-style" protocol (i2c_smbus_write_i2c_block_data), whereas your iDX 6011 Pro requires a strict SMBus block-write protocol with a count byte to break out of the MCU hardware marquee. Output of the commands: root@Unraid:~# /usr/local/emhttp/plugins/ugreen-led-control/backend/ugreen-led-ctl status { "ok": true, "foreign_monitor": false, "model": "iDX6011 Pro", "bays": 8, "kernel": "6.18.58-Unraid", "mapping": "guessed", "mode": "manual", "daemon": false, "fx": "", "fx_leds": "", "identify": [], "sync_action": "", "sync_percent": 0, "sync_enabled": true, "sync_color": "0 120 255", "standby_mode": "dim", "standby_level": 30, "smart_enabled": true, "error_enabled": true, "activity_enabled": true, "smart_color": "255 140 0", "disk_color_mode": "own", "netdev_status": "activity", "alert_enabled": false, "alert_level": "warning", "alert_color": "255 59 48", "shutdown_blink": true, "shutdown_color": "255 140 0", "shutdown_effect": "blink", "alert_count": 1, "alert_active": false, "fx_speed": 2, "fx_reverse": false, "fx_idle": false, "night": false, "disk_error_color": "255 59 48", "saved_brightness": {}, "network_device": "eth0", "netdev_speed": 2500, "network_ports": [{"name": "eth0", "link": true, "speed": 2500, "max": 10000}, {"name": "eth1", "link": false, "speed": 0, "max": 10000}], "netdev_speed_enabled": false, "netdev_speed_colors": {"10": "255 59 48", "100": "255 140 0", "1000": "255 214 10", "2500": "0 200 83", "5000": "0 200 200", "10000": "0 120 255"}, "controller": "ugreen-led-i2c", "i2c_bus": 0, "i2c_address": "0x3a", "leds": ["power", "netdev", "disk1", "disk2", "disk3", "disk4", "disk5", "disk6", "disk7", "disk8"] }root@Unraid:~# /usr/local/emhttp/plugins/ugreen-led-control/backend/ugreen-led-ctl smbus SMBus adapter: /sys/bus/i2c/devices/i2c-0/name:SMBus I801 adapter at 0000:00:1f.4root@Unraid:~# /usr/local/emhttp/plugins/ugreen-led-control/backend/ugreen-led-i2c probe { "address": "0x3a", "bus": "/dev/i2c-0", "leds": [ "power", "netdev", "disk1", "disk2", "disk3", "disk5", "disk6", "disk7", "disk8" ] }

In the latest version, 2026.03.28, my immich stack suddenly appears as stopped with no containers. However, immich is clearly actively running as I can access it. I upgraded from the previous plugin to Compose Manager Plus a couple versions prior to 2026.03.28, and it showed the stack fine. Since it's detected as "stopped", I cannot send a stop command through the plugin, and if I send a start command, it fails because the stack is already running. I'm hesitant to try the beta to see if it fixes this unless someone can confirm that it does. There is also an update to immich, so I tried the plugin button "check updates", which said there were no updates. I was able to click on the stack icon for immich and click check for updates, which it found that way. When I try to do the update, I run into the same issue that starting the stack, which is already running, has, which is the following error: Error response from daemon: Conflict. The container name "/immich_redis" is already in use by container "34381196eaf6025ce55cd4adfc4ccd9386a532cd6f52c83edffa210dd4a5380b". You have to remove (or rename) that container to be able to reuse that name.