That’s what a Channel is in openHAB terminology. Consider a thermostat. The thermostat is the device. It would be represented by a single Thing. However, a thermostat has a bunch of sensors and actuators (current temp reading (sensor), target temp setting (actuator), heating/cooling mode (actuator), etc.). Each sensor and actuator is represented by a Channel.
The current temperature reading is “channeled” from the device (i.e. Arduino) into openHAB and on to the Item linked to that Channel.
Yes, but the current temperature is what’s channeled. I didn’t invent the nomenclature used by OH. I’m not particularly a fan of the terms chosen. But don’t try to take the common dictionary definition for an openHAB term and use that to understand what it means in openHAB.
In openHAB, a Channel represents a single point on a device. That single point might be an actuator (i.e. we can send it a command to cause it to do something). That single point might be a sensor (i.e. all it does is feed openHAB data). But in both cases they are called “Channels” in openHAB.
One very important thing to understand about openHAB is its first and primary job is to make lots of very different technologies work together. To achieve that there are a number of layers of abstraction. By the time we get to the Channel concept, openHAB doesn’t care that you have a DHT22 wired to an arduino that’s being communicated with via a serial connection. All openHAB cares is “this Channel produces Number:Temperature values”. The Item ultimately Linked to that Channel does not and should not have to care where it comes from or how it’s delivered.
That’s not how it works in OH.
You would create a Thing to represent that specific Arduino, give it a meaningful to you the human name, let’s call it “Guest Bedroom Multisensor”.
You would add Channels to that Thing, one for each sensor reading produced by that Arduino and one for each thing you can command on that Arduino. That is where you make the mapping between “WD_02” and “Guest Bedroom Window”. The Channel config is and should be the only thing that knows or cares about “WD_02”. That’s way low level technology specific configuration stuff. So that window sensor Channel would have a meaningful name. Let’s say “Window Sensor”. You already know it’s in the Guest Bedroom because of the Thing it belongs to.
Ultimately you would then create an Item that links to that Window Sensor Channel. This Item is so far removed from the raw stuff delivered by the serial connection that if “WD_02” is mentioned anywhere you are doing it wrong.
There is no such thing. And you shouldn’t need it. That mapping will be captured naturally by the configuration. Once you get out of the Thing and Channel conifiguration, all the names and IDs you deal with should be meaningful to you the human.
Yes. Though be aware that there are some types of errors that can occur that do not make it back up to your rule. It’s possible for an error to occur that throws an exception that kills your rule before a catch or finally clause can be called.
In truth, all rules are something that lives inside of OH’s memory, whether they are created by parsing a text file or directly deserialized into memory from the JSONDB. Once in memory a rule, no matter how its defined will have triggers, optionally conditions (though not all text file languages support separate conditions), and actions. All a text based rules file does is gets parsed and executed when it’s loaded. During that execution it interacts with the OH Java API to build the rule in OH’s memory. A UI rule basically does the same thing only it interacts with OH’s REST API to add the rule. But once in memory, they are all the same.
The “code” part of your rules are the actions. No matter if they are in a text file or defined in the UI, the code is passed to an interpreter to execute. By the time OH gets to that point, it’s all the same.
