Let’s take a step back because I think you may not yet have a good grasp on all the parts of OH and how they work together. I’ll assume you have been through the Beginner’s Tutorial and the Concepts section of the Docs So I’ll try not to repeat too much of what is already discussed there.
OH has a bunch of separate concepts or ways to view your system over all from one perspective. Think of it like a die. You might be looking at only the 1 side of the die, but that 1 side is still all connected to the rest of the sides of the die. You can turn the cube around and see all the other numbers of the die. The concepts of OH are similar in that they provide a way for you to see and work on just one part of your home automation at a time. So what are these concepts in OH?
-
Bindings/Add-ons: These are how OH communicates with a given technology. Configuration for a binding tells OH important information like IP addresses, API user ids, port numbers, serial devices, etc.
-
Things and Channels: Things represent a single device and Thing provides a uniform way for a Binding to represent a Device to OH. Each device may have one or more control point (actuator) and/or one or more sensor value available. Each of these actuators and sensor values are represented as a Channel. Things are only available for OH 2.x version bindings. Things can be automatically discovered, created/managed through PaperUI, or created manually in .things files.
-
Items: Items are how you model your home automation. By defining an Item you are telling OH and yourself that zwave:wqersaret:node12:alarm is a Switch (i.e. can be ON or OFF) and is your main floor smoke alarm. Things may provide Channels you don’t care about and there may be some automatically discovered Things you don’t care about. And the Thing IDs are usually inscrutable so linking an Item to a Channel lets you give that Channel a meaningful name and define how you want it to behave in your home automation. It is at this level that you can Group Items together (e.g. put all your lights into the same Group so you can control them all as a unit). You can also define a little about how the Item looks on your sitemap (icon and label). Items can be created and linked to Channels in PaperUI or created manually in .items files.
-
Rules: Rules is how you define the behavior of your home automation. When one event occurs you can write some code to cause other things to occur in response. Events can be changes, updates, or commands to Items, time, or OH system events (e.g. OH just started). Rules can be created manually in .rules files.
-
Persistence: Persistence is how you define what and how often to save the states of Items to a database. This can be used to generate charts, you can pull historic data and use them to make decisions in Rules, restore the states of Items when OH starts up, etc.
-
Sitemaps: Sitemaps define the home automation user’s interface. When you build a sitemap you are building the GUI for your custom home automation. The Sitemap allows you to organize, arrange, and configure how to interact with your Items. This is your day-to-day user interface and the interface you will present to other users of your house. NOTE: HABPanel would probably fall under this concept but HABPanel does not use sitemaps. Sitemaps can be manually created in .sitemap files.
-
REST API: The REST API is the interface defined for external applications to interact with OH directly. You may never need to mess with this but the UIs based on Sitemaps and PaperUI use this to interact with OH.
-
PaperUI: This is the administration UI that you, as the developer of the home automation system use to manage your home automation. Bindings, Things, Items, and coming soon Rules can be created, installed, configured, and changed through PaperUI. But PaperUI has a few major limitations.
- It cannot manage Items that use OH version 1 bindings.
- It cannot create sitemaps.
- The Experimental Rules Engine is still Experimental and not yet ready for general use.
- Only those Items that are bound to Channels will appear in the Control tab.
- Only Things can be automatically discovered. OH 1.x version bindings do not support automatic discovery.
-
Karaf Console: This is the foundation upon which all of the above runs. There is a way to interact directly with it should you need to.
These are the big concepts in OH.
One thing you will notice that most of these concepts operate on the Items. Items are kind of the hub around which everything else in OH rotates.
Now let’s discuss the first complication you are experiencing. MQTT is a 1.x version binding. So that means, per above, there are no Things, no Channels, no automatic discovery, and no management/control through PaperUI. You can install the MQTT binding through PaperUI but everything else from configuration to creation of Items will require the manual editing of config and .items files. A lot of the tutorials out there are focused primarily around OH 2.x and doing things through PaperUI. It is a real shame that the 2.x version of some really key bindings (MQTT, HTTP, etc) don’t have a 2.x version yet. But that is where we are.
OK, back to your original question. Let’s trace it from end-to-end.
We know the technology is MQTT for the Wemos so you need to install and configure the MQTT binding. You may need to install an external MQTT broker if not already done.
Since the MQTT binding is a 1.x version binding, you need to create the Items by hand. Vincent shows what that should look like in post 8 after “For the OH item:”. It defines a Switch Item named WemosRelay and it is bound to an mqtt config (stuff between the { }). As mentioned above, this needs to go into a .items file.
As documented here, Switch takes OnOffType commands so the messages sent by the Wemos need to be ON/OFF or need to be transformed from whatever it does send to ON and OFF. Vincent shows two ways to deal with this, one by changing the WeMos code to accept ON and OFF and the other to transform the ON/OFF to 1/0 before sending it to the WeMos via MQTT. See the MQTT README in the docs to understand the MQTT binding config.
At this point you should look at the logs to make sure that there are no errors.
Now that you have the Item you are most of the way to your destination.
The next step is to add the Switch to your sitemap. So this is a device you want to control as a Switch so you would use the Switch element (or Default). This will put the toggle on the UI so the user can control it. But just because the Item is a Switch doesn’t mean you can only put it on your sitemap as a Switch. For example, your Dining_Light Item is linked to a Network binding channel. Thus this Item represents whether Light is online or not, not how to control the light. So you probably don’t want a toggle on the sitemap because you shouldn’t be manually changing this Item’s state. So you can use Text item=Dining_Light and it will appear on your sitemap and show the status of the light but without the toggle.
This part is important to understand. The sitemap is there to present the Items how you want them to appear and be interacted with by the User. Any Item can appear as Text which will show that Items state as read only. Some Items can be shown several different ways. For example, a Color Item can be shown on the sitemap as a Text, Switch, a Slider, a Setpoint, or a Color depending on how you want it to be controlled.
So, given Vincent’s Item above, you would use
Switch item=WemosRelay
and it will appear on your sitemap with a toggle control. The toggle control will let you send ON and OFF commands to the WemosRelay Item which will generate the MQTT message to the device. Note, you need to be using a sitemap based UI to see this. This means one of the phone apps, BasicUI, or ClassicUI.
