Does udev have an issue with the 'hwmon' subsystem?

I have a temp/humidity sensor connected to the i2c-0 interface on a Raspberry Pi: Rpi OS ver 'bookworm'. It works fine, and I can read sensor values from the files in /sys/class/hwmon/hwmon2 (or equivalently in /sys/bus/i2c/devices/0-0044/hwmon/hwmon2 or /sys/devices/platform/soc/3f205000.i2c/i2c-0/0-0044/hwmon/hwmon2) using a bash script:

#!/usr/bin/bash
dev_folder='/sys/class/hwmon/hwmon2'
humid_r=$(To minimize the risk of breaking users of sysfs, which are in most cases low-level userspace applications, with a new kernel release, the users of sysfs must follow some rules to use an as-abstract-as-possible way to access this filesystem. The current udev and HAL programs already implement this and users are encouraged to plug, if possible, into the abstractions these programs provide instead of accessing sysfs directly.

I take this to mean that instead of accessing the sensor data directly from sysfs - as I'm currently doing in my bash script - I should be using udev.  

I've also read a bit on udev. *My current understanding of udev* is that **one way** udev might help me is to *"translate"* the **variable** sysfs folder name into a **fixed** one (or at least a fixed symlink). This is apparently done on the basis of .rule files that contain a series of *device attributes* used as *filters* (aka **match keys**), followed by a *command* (aka **assignment key**). The *device attributes* I used were selected from the [output of this command](https://pastebin.com/VGLxA5vp) :

bash udevadm info --attribute-walk --path=/sys/bus/i2c/devices/0-0044/hwmon/hwmon2

I created the following udev *rule file*:

# filename: /etc/udev/rules.d/80-local.rules ACTION=="add", SUBSYSTEM=="hwmon", ATTR{name}=="sht3x", KERNELS=="0-0044", SUBSYSTEMS=="i2c", NAME="sht30", SYMLINK+="i2c_sht3x"

This rule was derived from a variety of sources, and guesswork using a *trial-and-error* approach. The *filtering* part of the rule seems to work: I've tested the rule using a script to create a /tmp file. However, the NAME="sht30" and SYMLINK+="i2c_sht3x" fails to create a corresponding entry in my /dev folder as I expected (hoped) it would. 

I've also tried *variants* of this rule that attempted to create a symlink in sysfs; i.e. /sys/class/hwmon/hwmon_sht3x. But this didn't work either - it seems the symlinks are restricted to the /dev folder?? And I've looked at man udevadm for something I overlooked, but found nothing that helped me. 

Persistence often pays, and so I modified the above rule as follows:

# filename: /etc/udev/rules.d/80-local.rules ACTION=="add", SUBSYSTEM=="hwmon", ATTR{name}=="sht3x", KERNELS=="0-0044", SUBSYSTEMS=="i2c", RUN+="/bin/sh -c 'ln -s /sys$devpath /dev/hwmon_sht3x'" ``` And this rule actually works! (so far at least): It creates the symlink /dev/hwmon_sht3x to /sys/devices/platform/soc/3f205000.i2c/i2c-0/0-0044/hwmon/hwmon2 - **OR** to the folder currently assigned by the kernel. I've tested it several times by forcing a change to hwmonX, and it (so far) hasn't failed. So, the question is: #### Why will the matching rule not create the SYMLINK+="i2c_sht3x"?