In my blog series for Openhab (Part 1, Part 2, part 3) I dealt with MQTT and the use of different devices and measurement data. To see the data or control devices, the operating interface of Openhab always needed. In my case, I didn't always want to use the cell phone or tablet, e.g. to switch on a socket or light. After a short brainstorming, I got the idea to use the AZ-Touch Mod as a simplified control element. The development is still running, basic control and display work without any problems.

In this article, I will explain what the AZ-Touch Mod should do and how it is configured.

Hardware for this blog

For this blog, the AZ-Touch Mod wall housing set is a must, see Table 1.

POS	Number	Component	link
1	1	AZ-Touch Mod wall housing set	https://az-delivery.de
2	1	Optional ESP32 NODEMCU Module WiFi Development Board	https://az-delivery.de
3	1	Voltage supply 12 V

Table 1: Hardware for this blog

In addition, it is mandatory My modification on the AZ touch necessary because we need access to the SD card slot of the touch display and, if necessary, the reset button on the outside could help.

The idea behind the project

After I started with Openhab, I didn't always want to access the corresponding base page in my four walls via tablet or smartphone. Especially with children and their cuddly corner, I wanted to create a simple interface, which you can easily turn on and off, for example, or can simply operate other functions. For children in particular, the corresponding device and the operation must be as simple as possible and give back simple feedback that the children also understand. Of course, the whole thing should not be so playful that as an adult, you have the feeling of using a children's toy. After a longer search on the Internet and the resulting brainstorming, the idea came up to use the AZ-Touch Mod wall housing with an ESP32. On the Internet I came across an older article by chance that had modeled everything using Openhab-API, but this project was not maintained and was no longer able to run.

Before the project, however, the second idea came to program the AZ-Touch Mod wall housing in such a way that no APIs need to be used, but is used to general MQTT. The reason for this idea is that a company should also be possible without a home automation server, which is easy to realize via MQTT. A simple MQTT broker and IoT devices, which mostly master MQTT, would be sufficient. One could also talk about a low-budget home automation solution.

A point that should not be underestimated was the configuration of the individual elements on the display. There is quickly a new device in the household that should be controlled and do I have to touch the whole source code again? I wanted to avoid that directly, which is why in addition to the assembly of the AZ-Touch Mod wall case modification It is necessary to access the SD card slot. A microSD card can be used here, using a corresponding SD card adapter, on which the complete basic and MQTT configuration is secured. If a new element is required on the display, only the MQTT configuration needs to be expanded. A disadvantage that some could see here may be that the access data for WLAN on the SD card can of course be viewed in plain language. But you have to know that an SD is installed in the AZ Wandmod.

As you can see, there is a long finding process behind the initial basic idea. At the same time, the feature list has grown steadily during the actual work, which is why the configuration file already has entries that have not yet made it into the current release of the project.

The surface of the AZ touch and the features

If I have now made you curious about the project, I want to go into the surface a bit first, see Figure 1.

Figure 1: User interface of the AZ-Touch

Let's start with the upper frame. First of all, you can show a clock to display the current time. If this is not desired, the NTP server is not set up and queried, which does not affect functionality. In order to find the device quickly, there is the possibility to give the device a name. The signal quality of the WiFi is displayed in the right corner. So you first have the essential information at the top.

The heart is the six buttons that cannot be overlooked. These serve either for the pure information indicator, in my case 28 degrees at 40% humidity and a button with which MQTT plugs are switched on or off. Elements, such as the switch button, give an optical feedback on whether the switch should be switched on or off. Here the feedback from MQTT is used, i.e. the transmitted status of the Device via MQTT.

Further button modes are planned, so far only the modes info, measurement, light and Switch are really usable, but more on that later.

How maybe. To recognize, only this six button is currently possible, but this should change with upcoming project stalls. Here it is planned that "scrolled" can be "scrolled" via the button at the bottom right.

Not to be seen in the picture, but still available, are indicated by error messages. For example, if the MQTT broker can no longer be reached or the WiFi problems, this is displayed via a corresponding dialog on the surface. At the same time, however, normal operation via the touch surface is no longer possible until the error has been remedied.

Another core feature, which was also deliberately disregarded in my jobs, is the watchdog. If the case occurs that the built -in microcontroller gets stuck, the device will be restarted automatically. This feature can be switched on or off and the timeout can also be determined in seconds, but more when explaining the configuration.

Another feature is the clock that is displayed, see Figure 2. This is shown if the time is to be displayed and the NTP service starts.

Figure 2: Current time and date

This does not always show the status side of all devices. If this is necessary, a touch of the touch display is enough to get to the button side. Here, too, the change of button surface at the clock over an adjustable time in the configuration is realized.

The configuration

As mentioned in the presentation of the display, the AZ WandMod is configured via configuration files on an SD card. At the start, an attempt is made to access the display of the display of the display. If this was successful, the following files are searched for, which must be on the SD card:

• general.xml
• MQTT.xml

As the ending. suggests, it is two separate XML files. The syntax of XML is not difficult, I like to recommend NotePadd ++ with the plugin XML tools at this point, which indicates errors in the XML syntax when saving.

general.xml

First the General.XML, which includes the basic configuration for the AZ Wandmod. At this point, access to the WiFi and the MQTT broker is described, for example. If you look at the sample file in the project, see code 1, the configuration is manageable.

 <? XML version = "1.0" encoding = "utf-8"?>
 <root>
     <Gui Surname="Aztouch Openhab" Dark fashion="0" show time="1"/>
     <Wifi Surname="Wifi" SSID="Test-Wifi" passport="Test pass"/>
     <Secure Surname="Secure" active="0" passport="12345" time-out="5"/>
     <Mqtt Surname="MQTT" broker="Test broker" port="1883" user="" passport="" client name="Wallmount"/>
     <Watchdog Surname="Watchdog" active="1" time="10"/>
 </root>

Code 1: Example file from General.xml

Table 2 explains every single parameter to clear out misunderstandings.

node	attribute	Description	default
Gui	Surname	Name that is displayed on the surface. Max 18. Signs on the display allowed.	Aztouch Openhab
	Dark fashion	Will switch between a light or dark screen in a later release	"0", bright display
	show time	Should the time be displayed? Starts an NTP client and syncs the time	1
Wifi	Surname	Name of the knot has no meaning here	"WiFi"
	SSID	Enter the SSID of the WLAN here	"Test WiFi"
	passport	Password of the WLAN	"Test pass"
Secure	Surname	Name of the node, has no meaning in the configuration	"Secure"
	active	(De-) activates the numpad on the display to enter the password. Not implemented yet!!!	„0“
	passport	The password for unlocking, only numbers allowed	„12345“
	time-out	The time that has to pass until the screen is closed again and the clock or the numpad for input. Time in minutes	5
Mqtt	Surname	Name of the node, has no meaning in the configuration	"MQTT"
	broker	Enter the DNS name or the IP address here	"Testbroker"
	port	The port of MQTT can deviate	1883
	user	If a user is used to register, enter the user here	„“
	passport	Password for the user to connect to MQTT	„“
	client name	Describes the name under which the device registration at MQTT. No spaces in the name allowed!	"Wallmount"
Watchdog	Surname	Name of the node, has no meaning in the configuration	"Watchdog"
	active	(De-) activates the watchdog	„1“
	time	The watchdog time in seconds. Attention: values ​​under 2 seconds can lead to a boot loop	„10“

Table 2: Explanation of the parameter General.xml

There are no more entries in this file and are not checked. To avoid errors or problems, the sample file should be used as a template.

MQTT.xml

Almost as important as the General.xml is the MQtt.XML. This describes current several things:

• The name of the button to be displayed
• The type of button, important for display and control,
• The position for the button on the current page
• Which side of the button should be on, currently only the first page goes
• The pub and sub-nodes to send commands to MQTT and get the status

The example from the project also helps, see Code 2.

 <? XML version = "1.0" encoding = "utf-8"?>
 <root>
     <element Surname="Switch" type="Switch" POS="1" page="1">
         <pub>cmnd/nous_monitor/power</pub>
         <sub>stat/nous_monitor/power</sub>
     </element>
     <element Surname="Info" type="Measurement" POS="2" page="1">
         <sub unit="Degree">Shellies/Shellyht-Office/Sensor/Temperature</sub>
         <sub unit="%">Shellies/Shellyht-Office/sensor/humidity</sub>
     </element>
 </root>

Code 2: Example file for mqtt.xml

Table 3 helps to understand the individual nodes and attributes.

node	attribute	Description	default
element	Surname	Name for the button	„“
	type	Type of the button, is described in more detail below	„“
	POS	Indicates the position on the respective page	„-1“
	page	Indicates which side the button should be on	„-1“
Element -> pub		Describes which MQTT node a command should be sent to
Element -> sub		Describes which node should be monitored for the status
	Unit	Special case at type "Measurement" or "Info", here a suffix is ​​attached to the content of the message	„“

Table 3: Explanation of the parameter mqtt.xml

However, there are a few rules in the definition. You can assign the position and page for the button as desired, but the program internally checks how many pages are actually needed and whether the position is already occupied. If a page is selected that does not correspond to the calculated pages, or the position on the page should already be documented, these elements are first skipped and filled with gaps in the sides. If there are too few pages, it is also expanded here so that all elements can be accommodated.

With the types "Measurement" or "Info" it is possible to store up to three sub-nodes. However, these only serve the advertisement and cannot send anything to the broker! As a result, the values ​​are then displayed in the button in three lines. This is practical, for example, if you want to display environmental values ​​here.

A big question will probably still be what types there are, there is also Table 4.

Type	Description	Picture	remark
info	Displays up to three values, corresponding sub-nodes must be attached to the element		The symbol is gray with the button stored
Measurement	Displays up to three measured values. Appropriate sub-nodes are required		The symbol is gray with the button stored
Light	Button to symbolize a light switch		When "off" red, otherwise green
Socket	Button, which is intended, for example, for a socket		When "off" red, otherwise green
Switch	Button that symbolizes an on/off switch		When "off" red, otherwise green
Shutter	Knot defines a roller shutter, each of the two SUB and PUB nodes. This displays two separate buttons presented with each other		Has not yet been implemented in the software.
	Symbol on the display to "scroll" between the pages		Cannot be selected as a type in the configuration. Is always black

Table 4: Currently existing types

Current project status December 2023

The project has been running for a good 5 months. Many ideas were created during development and many ideas were rejected. Ultimately, the following features made it into my release 1.2.2:

• Display of an analog clock with calendar week and digital displays
• Full configuration via the internal SD card slot of the display
• A dark fashion so that the screen is not so bright at night
• Several pages for button actions and advertisements
• NTP communication
• Various button types that do different things
• Display of the connecting strength
• Free configuration of all pins via platform if the project is supposed to use another display

This does not reach the end of my feature list, but it is enough for the first start. Since I currently have no electric windows, the feature "Shutter" has no great relevance for me, which will definitely change.

About the box

This project was created in parallel to my blog series via Openhab. As a result, I learned a lot about Openhab again, but also MQTT. The project also does very well without Openhab! Only a MQTT broker and a few IoT devices are necessary to do something with the display. My 3D printer or my large work PC in particular have missed Tasmota smart sockets to reduce the electricity consumption in the house. However, other concepts in your own four walls are also conceivable. Since MQTT is one of the protocols that almost every common smart home device knows,

Conclusion

The project presented here is far from finished. The source code on my Github repository is already available before the release, but has not yet been described in detail. Many features and bug fixes are still waiting for me in this project, but such projects show that it does not always need an expensive solution from well -known manufacturers, for example to bring the home automation of Openhab to an external display. There is still a lot possible with the previously used RAM of the NODEMCU. The complete project can be found under https://github.com/M3taKn1ght/AZ-Touch-Control