Connecting a selfprogrammed ESP32 to display a temperature

I have installed OpenHABian on a rasperry Pi and I can connect to it using the IP-Adress:8080

I’m a total noob about openHAB.

As a first step I want to display a temperature measured by an ESP32 microcontroller programmed with Arduino-IDE. An ESP32 can connect to my local WLAN with WiFi.

What kind of “connection” or is it called “binding”?
would you use for this?

cheers from e-tinkerer

What sort of interface does your ESP32 support? If you are going to code this device instead of using an off-the-shelf firmware like Tasmota or ESPEasy, you will have to decide and code the interface yourself. MQTT is popular as is HTTP but it’s really up to you to decide.

From what you’ve described, you are not done yet. It’s not enough to just connect to WiFi. You have to provide the API that other devices can use to communicate with it.

Aha.
there are a lot of libraries for different protocols available it can be UDP, HTTP, ESP-NOW, MQTT
UDP seems to be quite simple to program just a few lines of code in C++

The ESP32-Part is very easy

#include <WiFi.h>
#include <WiFiUdp.h>

WiFiUDP Udp;

IPAddress    remoteIP     (192, 168, 178, 160); // receiver-IP
unsigned int remotePort = 4210;                 // receiver port to listen on must match the portnumber the receiver is listening to

    Udp.beginPacket(remoteIP, remotePort);
    Udp.write((const uint8_t*)UDP_Msg_SS.c_str(), UDP_Msg_SS.length() );
    Udp.endPacket();

this means with UDP I can send to any IP using any port
Does OpenHAB have an easy to configure possability to receive UDP-messages?
cheers from e-tinkerer

Does it have support for UDP? There is probably a third party add-on that provides UDB support. Is it going to be easy? Probably not. If you want easy, pick something at a much higher level than a custom UDP protocol. The problem is while it’s nice and easy for you to publish a message, it’s going to be very painful to parse the message on the OH side.

Remember an OH binding is configured.

MQTT too is pretty simple and is only one or two more lines of code if you use Paho.

But MQTT, HTTP, etc. are all low level interfaces. It’s going to take a lot of work on the OH side (relatively speaking). For example, I trust you’ve already gone through the Getting Started Tutorial and seen the example for configuring MQTT.

Aha. So does this mean there is no easy way to show a UDP-message like a “serial” message in the serial monitor of the Arduino-IDE?
The serial monitor of the arduino-IDE is like almost any serial terminal-software. Show received characters in a screenarea similar to this postwriting function.

well if this “work” is coding in a programming-language like C++, Delphi, Python or Lua this is no problem. This is what I do a lot.

Is there something similar than setting some rules like
if message starts with “TMP” (realised as pick character 1 to 3 of received message and compare it with “TMP” )
if it does match
copy 4 to 8 character and put it into the field named …?

As you can see I try to solve it with a programming-approach.
Does it have a feature like that?

cheers from e-tinkerer

Well, there is a Serial binding. You’ll still need to do a bit of potentially painful configuration to parse out the serial messages.

But that’s not what OH does and it’s not what it’s for. OH is a platform that allows one to bridge 300+ different APIs and technologies from simple web services to the full Zwave/KNX stack. It does this through bindings. Bindings are configured and from there devices are represented as Things. Things have Channels, one for each sensor and actuator. Channels are Linked to Items. Items are used in rules, in the UI, persistence, etc.

All these layers of abstraction are required to be able to present devices from this diverse set of technologies in a unified manner.

And that means to configure OH to receive a UDP packet you’ll need to:

  • find and install a binding that talks UDP
  • create a Thing for that binding
  • configure a Channel for that binding
  • create the expressions to parse the UDP message and extract that one piece of information that Channel represents; repeat for the parts of the messages and other messages
  • link the appropriate type of Item to the Channel

From here you can probably follow the events.log to see the Items changing as it receives messages.

There is no screen to just print out what was received.

No, it’s work learning how OH works and figuring out how to configure complex stuff like parsing serialized data out of a string of bits without access to code.

Maybe. Remember, I’m unaware of an actual UDP binding in OH in the first place. If you want to wire it up with a serial interface look at the binding docs for that to see what it can do.

There is also the potential to code the parsing in OH rules.

Honestly, I have to ask what brings you to openHAB in the first place then. Or perhaps you haven’t been through the Concepts page in the docs or the Getting Started Tutorial to see how OH actually works.

As I said, OH is designed to bridge between different technologies. If you are happiest living at such a low level of programming to the point that MQTT is too high level for you, I can’t imagine how you’ll ever be happy with OH. OH primarily works at much higher levels and by necessity has layers of abstraction the data has to filter through so that regardless of the technology it’s presented and used in a normalized manner.

Indeed behaviors are coded in programming languages (when x happens do y). But connections to devices are configured, not coded.

1 Like

Aha. OK. So as the next step I will look into this Getting sStarted Tutorial to get a glimpse how it works. And maybe with MQTT it is easier to realise.

I don’t know how to code html and I thought openHAB would offer a simple way to use it as a remote-control and a display so that I can use any smartphone to look up measured data and switch on/off things.
cheers from e-tinkerer

You might find Integration of I2C sensors (raspberrypi4/BMP085 or BMP180; openhabian snapshot, Lua 5.1, lua-periphery, Exec Binding/REST API/MQTT) insightful. It explains which steps are required to integrate a sensor into openHAB using different methods: Exec Binding (doesn’t make much sense in your case), REST API, MQTT.

Hi Ap15e,

thank you very much for pointing me to how to program the internals OpenHAB.
Seems to be a lot of work. Too much work for my intentions.
I have understood: OpenHAB is easy to use for existing communication-standards and openHAB is able to work as a super-translator/interpreter for a lot of “languages”
(where “languages” means communication-protocols like zigbee, z-wave, KNX etc. etc.)

Well for the self-programmed devices that I’m using I will look into MQTT and see if this aproach has a limited effort.

cheers

1 Like