This is a great tutorial but I don’t think it’s a DP. A DP is really for a common way to solve lots of different problems where as this is really only applicable to thermostats. So I wouldn’t worry about trying to turn it into a DP.
In a tutorial like this, you should check for NULL which appears to be the case. But don’t forget UNDEF too. Be sure to log out a meaningful error message or warning when a NULL or UNDEF Item is encountered preventing the Rule from successfully running.
Please explain why not RRD4J. I assume it’s because it can’t handle UoM?
As a general rule, seeing a Rule that runs every X seconds is a code smell. OH is an event driven system so it is usually more appropriate to trigger the rule based on events instead of on a fixed polling period. For example, when temperatures change and when the target temperatures change. If there are no changes there is nothing for the Rule to do, so why run it just because ten seconds have passed?
Everyone has their own coding style, but the most common style has constants named with all caps. And this particular constant probably should be a global val, though that too is more of a style thing.
Do you really need to run the Rule for all rooms every time? If you moved your triggers to trigger on temp and target temp/mode changes then you can use triggeringItem.name.split... to get the name of the room that changed and only run the Rule for that room. That will simplify the Rule a bit.
Log a warning at least here to indicate why the Rule didn’t do anything. It’s not as big of a deal when you are not running the rule every ten seconds.
logWarn("smart heating", "Setting {} to OFF and {} to 0 because modeItem is {}", valveItem.name, modeItem.name, modeItem.state)
Review Design Pattern: How to Structure a Rule. In a Rule like this typically you have a bunch of if statements or case statements that all do the same thing but with different values. So instead just calculate the values but actually make the changes (e.g. postUpdate, sendCommand) once at the end of the Rule. This can simplify the Rule, reduces duplicated code, and make it easier to maintain and change later when you decide the Rule needs to do something else.
To make it easier for users to adopt the Rule, make “influxdb” a constant the user can set to their own database in one place.
Please provide a “theory of operation” where you describe in prose what these Rules do, step by step. Especially for long and complicated Rules like this it helps one figure out what the Rule does more easily. I admit, I really don’t know how this Rule works or what it’s really doing. Perhaps it’s described in the link. It might help to add some comments to the major sections of the complicated Rule that explains at a high level what that section is doing.
That’s all I have right now. I don’t have time to really look into the rule for logical errors or edge cases. I was only able to look at it from a shallow perspective.
Thanks for posting! It looks like a useful tutorial that I’m sure others will find useful.