This is an excellent candidate for a rule template. If you made this into a rule template you can use properties to allow the end users to define their own Item names. That makes it easier to adopt for the end users. In addition, end users can just install and instantiate the rule and don’t need to copy/paste/edit.
If you went down this path you could use sendHttpGetRequest instead of the HTTP Thing to further reduce the dependencies and amount of work the end users would need to do to use this capability. It would then be able to use a cron trigger for that first rule and eliminate the raw Item entirely.
Where it gets awkward is the fact that you have three rules. But that could be managed by testing the event Object for what triggered the rule and doing the right action based on the rule trigger (i.e. if cron triggered pull down the data, if triggered by the power Item send ON or OFF, and if triggered by the speed Item. I use this technique successfully in several of my rule templates. Unfortunately only one rule
If you need help with how to do that I can answer any questions but it’s not super hard. See How to write a rule template for details.
Assuming you didn’t go down the rule template path, if you keep the Thing anyway, I recommend creating Channels for each value and move the REGEX transformation to the Thing. The HTTP binding allows for chaining transforms so you could do a REGEX and chain that to an inline JS transform to replace the commas with dots, though I think that could be done in the REGEX itself. That would enable the end users to pick and choose which values they actually care about and all they’d have to do to use it is link to the proper Channel. That will make the HTTP Thing behave more like a representation of the device, which is what Things are for.
In fact, your power and speed rule too could be implemented in the Channel config.
So you could implement this purely as a Thing with no rules required, or as a rule with no Things required. Either approach I think is better.
For the power rule you could simplify it if you made the trigger more specific. Add one for when it receives command ON and another when it receives command OFF. Then the action could be as simple as:
actions.HTTP.sendHttpGetRequest('http://10.220.30.100/?power='+event.receivedCommand.toLowerCase());
Just a one liner.
One thing that helps users manage a copy/paste/edit of rules like this is to create variables/consts at the very top of the code for everything that the user may need to customize (e.g. URL to the device). I like to put Items there too.