Window Sensors

Setup, Configuration and Use Beginners
1

I have all my windows sensored with magnetic switches. An arduino scans the sensors and if there is a change sends a text string to the serial port.

The string looks like:

$sensor:W04:OPEN$

or

$sensor:W05:CLOSED$

The window name W04 and W05 are taken from the building plans and are unique to that window.

Which would be the more correct way to get the sensor state into an OpenHab variable?

option A

Bridge serial:serialBridge:arduinoIngress [serialPort="COM3", baudRate=19200]
{
    Thing serialDevice envIngressOfficeWindow [patternMatch="$sensor:W04:*"]
    {
        Channels:
            Type switch: officeWindow [onValue="OPEN$", offValue="CLOSED$"]
    }
    Thing serialDevice envIngressMasterBedroomWindow [patternMatch="$sensor:W05:*"]
    {
        Channels:
            Type switch: masterBedroomWindow [onValue="OPEN$", offValue="CLOSED$"]
    }
}

Or option B

Bridge serial:serialBridge:arduinoIngress [serialPort="COM3", baudRate=19200]
{
    Thing serialDevice envIngressWindow [patternMatch="$sensor:*"]
    {
        Channels:
            Type switch: officeWindow [onValue="W04:OPEN$", offValue="W04:CLOSED$"]
            Type switch: masterBedroomWindow [onValue="W05:OPEN$", offValue="W05:CLOSED$"]
    }
}
2

Your use of the term “variable” gives me pause and makes me want to recommend reading or reviewing the Concepts section of the openHAB Docs.

In fact, that should give you the answer to your question really. Typically a Thing will represent a single device so your Option 1 would be more in keeping with what the a Thing is supposed to represent. But that doesn’t necessarily mean that one approach is correct and the other is incorrect. Ultimately, your Items and the Semantic Model (should you choose to use the model) is going to have a far larger influence on the usability of your openHAB system than how you define your Things will. Just try to be consistent and do it in a way that makes sense to you now and that you think will make sense to you in the future.

Take pity on future Retro Grade.

3

I’ll put the other case that the Thing represents the Arduino and thusly there can be only one :wink:

However …

That’s going to throw an error when a message W05:OPEN arrives and cannot be matched to on/off suggestions.
Luckily Serial binding supports chained transformations, so you can use the technique (well-known via MQTT examples) of filtering for “W04” by REGEX transformation

4

I am missing something here then. Are you saying I need a separate bridge for EVERY sensor? The arduino for the window/door sensors handles about 38 sensors. Between the 5 planned arduinos there will be over 270 sensors of various types.

Secondly, the holder of the state of the switch will change depending on the state of the outside world. So the value of the holder of the state of the switch varies. This is the definition of a variable.

I can see that I am floundering here. Usually when I set up a new system, especially in a new language, I determine the inputs, find a way to store (in memory or persisted) the values, then find out how to present the inputs to the user. So right now I am (in my mind) methodically walking through the system and trying to get real world values into OpenHAB. BTW, I am a retired systems developer with over 35 years in the industry and have used about 15 computer languages, some formal training, others self-taught.

I know that there are snippets of OpenHAB code here and there, and I am really trying hard to make sense of them so I can write the code for my system. I did ask if there was a page which held the code syntax for OpenHAB and got an answer which included JavaScript, which is NOT native OpenHAB code, as far as I can tell. So I will ask again, is there a place which holds the entirety of the code which OpenHAB parses when it starts?

I am starting to believe this :frowning:

I approached this with the belief that I could simply read through the pages, pick through the examples, modify them and get a system up and running, as I have done many times before. Instead this is giving me a headache as I try to re-align my understanding of what I thought were base definitions of software.

5

No, he’s just outlining that it makes equal sense to have one Thing for the Arduino and each window represented by a separate Channel. In the end, it doesn’t really matter and there are good reasons to do it one way or the other.

As I said, it’s the Items and Semantic Model that will really matter. The Things organization matters less so.

This sentence doesn’t really make sense as written. Perhaps there is just a miss-communication. First of all, drop “variable” from this discussion. The “holder of the state of the switch” is the openHAB Item. The Item doesn’t change, but its state might change based on messages from the device. As far as everything in openHAB is concerned, that Item represents that switch. But the current ON/OFF state of the switch is just one aspect of an Item. An Item is much more than just it’;s current state.

In OH, this is an Item. A variable is something else only applicable when writing rules.

Have you read through the Concepts section of the docs? Have you gone through the Getting Started Tutorial? Most of these concepts, and terms of art are discussed at length, with examples, in those parts of the docs. And the Getting Started Tutorial does follow your path. First you define the Inputs (i.e. the Things_, store them in memory (i.e. the Items), and then present them to the user (i.e. MainUI widgets).

Once you get past that point you have saving the data for historical analysis (i.e. persistence) and when X do Y type automation (i.e. rules, this part is not yet added to the Getting Started Tutorial).

Everyone’s home automation is bespoke. You will not find one end-to-end tutorial that presents everything you need in one coherent and copy-and-paste able thread. Instead, what you will find are a bunch of point tutorials and examples which you’ll have to string together to build your system. But you can’t do that if you don’t understand the openHAB basics, which is why it’s important to review those parts of the docs. If you’ve done that and still have questions please ask for clarification.

If you just try to jump in and copy stuff from here and there without understanding those basics it’s either going to take way longer to learn the system or you’ll just flat out fail.

There isn’t just one. openHAB is basically a development framework. You may as well ask if there is one place that holds the entirety of the code which Linux can run. While openHAB isn’t quite that complex, it’s not just a single application. You have:

  • Things: documented here though you will have to reference the binding docs for specific parameters and options
  • Items: documented here
  • Persistence: documented here
  • Transformations: documented here
  • Sitemaps: documented here

And all that’s before we even get to Rules. For writing rules you’ve a choice between half a dozen different languages, three of which come with openHAB by default: Rules DSL (documented here, Nashorn JavaScript (i.e. ECMAScript 5.1, sort of documented here and absolutely is native OH code, and Blockly whose reference guide is being merged into the docs as I write this, for now see here and which “compiles” to Nashorn JavaScript. If you choose one of the other supported rules languages, see that add-ons’s docs for it’s reference. If you are just getting started, I highly recommend the JavaScript Scripting add-on as the most complete, capable, and completely documented rules language.

And on top of all this, everything (except persistence strategy and transformations) can be done through MainUI where the syntax and language references and such simply doesn’t matter. OH is way easier to learn and set up through MainUI since its a whole lot more self documenting and options and capabilities are made much more apparent. Many even long time users of OH have moved off of text based config files to the UI for just that reason.

But I don’t think that’s your problem. The fact that you’ve figured out how to create MQTT Things from a .things file shows that you are perfectly capable of finding and using these references. Your problem is you don’t yet understand how it all works together. You need the bigger picture view which should come from the Concepts and Getting Started Tutorial.

Anyway, in my extensive experience on this forum, the amount of time waisted looking through the reference docs and fighting syntax errors and such way outweighs and time lost to “point-and-click” in MainUI, especially when you apply OH 3 Tips and Tricks. I would strongly recommend at least using MainUI to learn the OH concepts and how they work together before trying to dive right into fighting config files.

OH isn’t that kind of system. In your mind an Item is just a variable, but in OH it’s much much more than just a variable. If we were to call it a variable that would be stretching the definition beyond the breaking point. So we have a different term, Item. This is why that concepts section of the doc is so very important. If you approach openHAB as if it were just a programming framework and all you need is a reference doc to get buy, you will miss the bigger picture.