You don’t really need a rule for each device. One rule should be able to handle all your devices.
But it’s a rule you don’t need to write. Meter Reading II [4.3.0.0;5.9.9.9] on the marketplace handles exactly this situation.
Probably. In OH 5 the previous state is now a property on the Item and independent from persistence. It becomes a little tricky in a profile though because the profile doesn’t have access to the name of the Item that it’s linked to. So you’d have to pass that as an argument.
The Script transformation supports passing arguments to a profile using URL encoding. For example, see Auto scale units.
Another limitation with profiles though is you can have only one on an Item. So if you already have a profile on an Item, you can’t add this as a second profile. That may not be the case but in general it’s something to be aware of.
If your primary concern is redundant code, I recommend the rule template on the marketplace. For you, there’s no code to write at all when using that. You’d just set up the Items and pass them in as properties when creating a instance of the rule from the template.
The next least amount of code would be to write a single rule that handles all your relevant Items. There are lots of approaches to achieve this including Design Pattern: Associated Items, Item metadata, the semantic model, etc. But at a high level what you need to do is be able to create the name of all the relevant Items based on the name of the Item that triggered the rule.
A Script profile would be about the same amount of code but it requires more specific configuration at the Link since you will have to, at a minimum, pass the name of the linked Item into the Script transform. However, it doesn’t require proxy Items which is a different criteria not mentioned.
The rule template above shows the code you’d need. The transformation above shows how to pass into and use a passed in argument in a transformation.