[SOLVED] How to connect a BasicUI switch to a Wemos d1 mini

I’m trying to work through setting up an ON/OFF switch in the BasicUI to send commands to a Wemos d1 mini to turn a relay on and off. I used the HomeBuilder to generate the Sitemap and items code for the light switch. I’ve also used the network binding to find the board on my network.

I’m trying to figure out how and what code to send to the Wemos to turn on and off the Wemos relay.
I’m using the library PubSubClient on the Wemos which allows me to read from and write to MQTT.


Switch   Dining_Light   "Light"      <light>   (Dining, gLight)      {channel="network:pingdevice:Wemos_Switch:online"}


 Frame {
        Text label="Light" icon="light" {
            Default item=Dining_Light label="Dining"

I have set up another Wemos and a Hazzah for 2 door sensors that sends the OPEN/CLOSED message via MQTT to the BUI screen and displays the doors opening and closing every 2 seconds. Now I’m trying how to go the other way.

Any help would be appreciated.

What topic does the Wemos subscribe to?

Here is what I’m using in OH to read the door OPEN/CLOSE contact

**in items file**

Contact DoorSensor2 "Front [%s]" <door> { mqtt="<[broker:SmartHouse/Security/DoorSensor2:state:default]" }

**in sitemap file**

 //Switch item=PDoor
    Text item=DoorSensor2  label="Patio Door [%s]" labelcolor=[CLOSED="green", OPEN="red"] valuecolor=[CLOSED="green", OPEN="red"]

then in the Arduino IDE. This changes for each door

// Topic which listens for commands
char* outTopic = "SmartHouse/Security/DoorSensor3";

There is also a statement in the Arduino sketch for inTopic to receive commands. I just don’t know how to transfer the ON/OFF switch movements in OH to the Wemos. That would be for the inTopic statement.

Ok, Your have DoorSensor2 subscribing to SmartHouse/Security/DoorSensor2
and the wemos publishing to SmartHouse/Security/DoorSensor3

Ensure that you are subscribing to the right topic

What payload does the wemos published for your contacts?

Right now I have the Wemos programmed to send OPEN then CLOSE every 2 seconds so I don’t have to keep pressing a button to simulate the door movement.

They need to send OPEN and CLOSED
These are the two allowed states for a contact item.

Do you see the messages incoming in mqttfx or other mqtt monitor?

The contacts part of my OH is working fine.

What I’m trying to do is turn on a light via OH. I don’t know how to send a payload from OH to my Wemos. Once I know what data is coming from OH then I can program the Wemos to turn on a relay.

Ok, let’s that the topic will be House/WemosRelay
In your wemos you need to declare

char* inTopic = "House/WemosRelay"

For the OH item:

Switch WemosRelay "Wemos Relay [%s]" { mqtt=">[broker:House/WemosRelay:command:*:default]" }

That will send “ON” or “OFF” every time you send a command to WemosRelay

Now the catch is that in your wemos you need to get the payload and perform an action depending on the payload. I haven’t see your wemos code so I don’t know how you are doing it but I have:

const char* inTopic = "House/WemosRelay"; // MQTT Topic this switch subscribes ("listens" to
void callback(char* topic, byte* payload, unsigned int length) {
  Serial.print("Message arrived [");
  Serial.print("] ");
  for (int i = 0; i < length; i++) {

  // Switch ON the RELAY if an "N" was received as the second character and OFF if the character is "F"
  if ((char)payload[1] == 'F') {
    digitalWrite(led_pin, HIGH); // Turn LED OFF
    digitalWrite(relay_pin, LOW);   // Turn the RELAY OFF
    relayState = LOW;
  } else if ((char)payload[1] == 'N') {
    digitalWrite(led_pin, LOW); // Turn LED ON
    digitalWrite(relay_pin, HIGH);  // Turn the RELAY ON by making the voltage HIGH
    relayState = HIGH;

This is because the default payload for a switch is “ON” or “OFF”

You could also do:

Switch WemosRelay "Wemos Relay [%s]" { mqtt=">[broker:House/WemosRelay:command:ON:1],>[broker:House/WemosRelay:command:OFF:0]" }

And in the wemos:

void callback(char* topic, byte* payload, unsigned int length) {
  Serial.print("Message arrived [");
  Serial.print("] ");
  for (int i = 0; i < length; i++) {

  // Switch ON the RELAY if an "1" was received and OFF if "0" was received
  if ((char)payload[0] == '0') {
    digitalWrite(led_pin, HIGH); // Turn LED OFF
    digitalWrite(relay_pin, LOW);   // Turn the RELAY OFF
    relayState = LOW;
  } else if ((char)payload[0] == '1') {
    digitalWrite(led_pin, LOW); // Turn LED ON
    digitalWrite(relay_pin, HIGH);  // Turn the RELAY ON by making the voltage HIGH
    relayState = HIGH;
1 Like

I have been trying to wrap my head around how to set up OH from reading an looking at all the demo code. I still don’t get it how easy it is supposed to be. How you have to have stuff set up in the sitemap and then stuff set up in items to get this to work. It took me 3 days of reading and experimenting to get the door contacts to work. Then I ran across the PubSubClient library and that made it work. I haven’t written any code for the switch yet because I didn’t know what to write.

I basically took the PubSubClient library and made changes to output the OPEN/CLOSE commands to OH so what ever code is in the library is what I used. I have been using MQTTfx to monitor the code between the Wemos and OH to get things to work.

From the videos I have been watching, you just have to do some sort of scan and OH finds your device and bam it’s set up.

I greatly appreciate all your help. I’m 64 years old and want to automate my home. With an electronic background, I think this is a fun project. I just wish it wasn’t so hard for me to understand.

So in your example above, what do I need and where in OH do I need to place the statements?

You can do that with OH2 bindings.
Unfortunately MQTT is an OH1 binding and the config and items bindings have to be done manually

What statements?

Sorry, I’m just trying to understand what I need to put in the sitemap file and items file from your example above to make this work. I already have the light switch in OH, I just need to match it up with what you have to make it work.


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.

    1. It cannot manage Items that use OH version 1 bindings.
    2. It cannot create sitemaps.
    3. The Experimental Rules Engine is still Experimental and not yet ready for general use.
    4. Only those Items that are bound to Channels will appear in the Control tab.
    5. 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.

1 Like

Thank you Rick for all this information. I have been watching videos, reading the OH online manual and looking over the demo files for the past week and you are correct, I don’t thoroughly understand how all this works together. I guess I happened to scrape together the code to make the door contact work after using the PubHubClient library for the Wemos. I was using the installed HomeBuilder to hopefully generate the code needed to make this switch work in a similar way. I didn’t realize that the MQTT was version 1.X . I guess I just figured that since I had to manually configure for the contacts to work with MQTT, that I would have to do the same for the switch.

I have also been watching videos on the Sonos modules, which also have the esp8266, chip, so I was unsure why the same programming that worked for that didn’t work for my Wemos. I’m guessing it has something to do with the software loaded on the 8266 for them.

So at this point I’m trying things to get what boards I have to interface into this system. When I get back home, I will go over your info above and keep reading more.

I got some info from another person back when I was first getting started, that said to get this program that would automatically setup the 8266 board to interface easily into OH. The program ran off of the Arduino IDE but I could never get this program to work so I’m trying to hack my way into making them work manually for now.

Thanks again !!

If that program was either Tasmota or ESPEasy it would be well worth your time to give it a second try. They really make both setting these devices up initially and maintaining them in the long term much much easier.

If not, have a look at either of these. I use both and if it weren’t for the fact that I’m using the analog pins on my NodeMCU sensors I’d use Tasmota for everything.

Tasmota was the program I was thinking about. I always had trouble when unpacking the file. I may switch to 7zip to unpack it as program I’m using now gives me all kinds of errors.

You can flash the tasmota firmware directly and upload with esptool:
That’s what I do. It’s precompiled for you so you don’t need and IDE and libraries and all the dpendencies…
You don’t need to compile and deal with potential errors:

WELL… I finally got ESPEASY to load up my Wemos and Huzzah boards, connect them into openHAB and started controlling lights. For some reason, when I tried Tasmota, the code would load but nothing would happen. No network activity so I switched over to ESPEasy and everything started to work after I cleared the chips memory first. Now they work great !!

Thanks for everyone’s help !!