Correct, with Rules DSL there are no out of box anything. But there are tons and tons of examples posted to the forum.
No, you want to create Rules. For Rules you have a choice of:
- Rules DSL: Current default, very simple domain specific language, has the most examples and support on this forum, inflexible if you are a programmer used to bending a language to your will instead of bending yourself to the language’s will.
- JSR223 Jython: Python 2.7 environment that will support anything that can be done in Rules DSL and then some.
- JSR223 JavaScript: JavaScript Nashorn environment that will support anything that can be done in Rules DSL and then some.
- JSR223 Groovy: Groovy environment that will support anything that can be done in Rules DSL and then some.
- HABApp: An external Python 3 Rules server that interacts with OH through it’s REST API.
- NodeRed: A graphical pipes type rules engine that has an openHAB plug-in.
- Experimental Next Generation Rules Engine: Uses the same execution engine as the JSR223 languages but presents a web based UI for building the Rules. The UI is primitive at best right now.
For the JSR223 languages, there is an extensive Helper Library that includes a Community section where users submit reusable Rules and libraries for building up their Rules. This is just getting off the ground so there are not many submissions yet.
You will find it easiest I suspect to use one of the JSR223 languages with the Helper Libraries.
You are looking in the wrong place. But what you say somewhat applies to Rules DSL Rules. There is no nesting, limited support for arrays and maps, and really no good way to load config data from a file in Rules DSL. And that is by design. That sort of information should be represented as Items, not config files. See the Topics tagged designpattern postings for best practices for coding Rules DSL Rules.
I think before you get too far down the road on this you should review How to get started (there is no step-by-step tutorial) and follow those links to get a better understanding of what OH as a platform actually is, how the various parts work, and how to migrate your existing code to the new platform.
You can’t. OH is an event based system. Event occurs, get’s put on the Event Bus, and various parts of OH react to those events, including the triggering of Rules or causing Bindings to reach out to the devices to cause something to happen.
Having said all of that, I’ll repeat a thought Marcus expressed on another thread. For something like heating, you really want it to be able to perform at least basic functions autonomously. You don’t want your pipes freezing because your home network went down while you are away from home. At a minimum it should try to maintain the last supplied target temp. Given that, perhaps the solution is somewhere in the middle where you keep a simplified version of your Perl script which maintains the last commanded target temp, add an API (MQTT is popular) and have OH implement your heating control Rules. But all OH is adjusting is the target temp, not actually directly calling for heat.
But no matter how you look at it, migrating this to OH is going to require a fundamental rethinking of how this all works. You will not be just simply porting your existing script to a new language. It’s a whole new platform which will require assembling your solution in a whole new way.