Custom build ESP8266+Relays Auto Discovery by Openhab2


-I have been trying to discover my custom designed pcbs having ESP8266 and Relays to control lights. I have clubbed it with openhab2 and able to control room lights through Alexa and with Openhab mobile app.
I have programmed ESP8266 chips by providing SSID and PWD for a specific network.

-But I want to code them to design as smart things like sonoff does and similarly openhab2 can detect these smart thing/devices as and when they come to a wifi network. Any one has done it before? Kindly discuss it so that I can clarify more.

Easiest thing is to run your ESP8266 under MQTT. I use the PubSubClient under Arduino for this.
Install the Mosqito broker and you can comunicate via the topics you create in OH and on the ESO8266.


That would need a custom binding IMO. To just detect new devices in your network, you could use network binding. But it only adds network things, so you wouldn’t be able to control such things, as they have only generic channels like present/absent.
Since each ESP device can have various channels depending on device’s design (relay, multiple relays, temperature, power usage, etc), it is not possible to develop a generic MQTT or HTTP binding that would detect various ESP devices. Also each device can communicate using different MQTT topic or HTTP URI.
That means you need a new binding for your custom designed devices.

If I’m the one to create the Binding, I would use UDP/multicast. This way we can create a custom contract (for autodiscovery) between OH and other future devices (ESP or not)

But why is auto-discovery really needed?
Just create your items using the MQTT binding with the topics you have created in your ESP8266 and you are done.

Because not everyone uses MQTT. Hence, we have 300 Bindings available.

For what? If for autodiscovery, sounds like standard approach. But I assume this is only the beginning of such new binding development.

I think @Revestroke wants to have the autodiscovery for his devices which would add dedicated things with appropriate channels for each of them.

Because it is more convenient than editing text files? No need to access OH machine directly. No need to know the right syntax for each file.

I don’t think anything exists currently but a binding of some sort would likely be a good option.

Seems lots of users are handling client devices via MQTT connections which is fine although it does appear we are all rebuilding the same or similar solution each time.

Just saw @rlkoshak post here: Mozilla Web of Things

Haven’t looked at it beyond a 10 minute glance but it could be the foundation of something more standard and structured for all to easily reuse. But as said it’s early days and you’d have to do the ground work for most of it yourself but if you had the interested in doing something along those lines anyway then why not do it inline with a standard that will hopefully get adopted overtime. It also has likely done a lot of the architectural thinking for you as well.

-I have coded Esp8266 chips by providing ssid and password for my WiFi network, thereby declaring mqtt server IP that is of Raspberry Pi as Openhab installed.
-The respective Esp8266 right now are hardcoded with the same network and they are communicating with openhab nicely.
-Issue: I want to use this smart home system in another place where network differs. Now here comes the need for Smart Things… Not everytime I can code the Esp8266 chips by changing ssid and pwd. So need to discover by coding in such h a way that they can be used as smart things and then detected by openhab server automatically either by any binding or by adding in things file.
-Samsung smart things and sonoffs are like that… One can just power them up and can set to different networks, as the server auto detects them. I am interested to do the same with Esp8266 and Openhab.

So you need something else I think. You need AP mode for your ESPs and some protocol to send your network settings using HTTP. This is how sonoffs work and I guess other WIFI devices as well.
You can look at tasmota sorce code how this is achieved. Basically by long pressing a button the device switches WIFI to AP mode with own private network and starts an HTTP server. Then you connect to that network and send to the server your network settings (SSID, password). After that the device changes the WIFI to client mode and connects to your network. That’s it. If you have properly configured OH server everything should work fine after that.

Wouldn’t something like a homie binding - which would support autodiscovery of esp devices.

If your main problem is that you don’t want to code the ESP if you need to change the WiFi setting, maybe that could help:

Its made for ESP32 but maybe it will work with ESP8266 as well.
This comes with a web interface where you can set WiFi and MQTT Broker settings.

When you change the location, just reset it 5 times and the ESP will automatically create an Access point where you can change the network settings again.

Exactly, and if you’re not too concerned about using MQTT, but more about configuring without having to upload new code if you move it, I would definitely check Homie library :slight_smile:

It allows you to just have to focus on the logic of the sensors programming. All the configuration is done by a JSON file pushed externally.
Basically at first start your ESP8266 boots in configuration mode, creating an Access Point. Connecting to this access point gets you to a web interface where you have to put your wifi credentials, mqtt broker location, and every custom settings you enabled. Then it reboots in normal mode. The code is very independant of your local configuration
And it also supports OTA so you can update firmware remotely…

This is a very modular solution, but no autodiscovery though :pensive: Imo you would need to implement a custom binding if you really want it.

I have just done a similar thing and yes it needs to be a binding with the eclipse tutorial covering what you need to do to create a discovery service in your binding.

The way I did it was use mqtt and use retained messages, then when the discovery service connects to the broker it gets a full list of all your devices as topic:payload format you then need to write code to take that info and anncoince to openhab u have found a new device.

The learning curve is high at the start but once learnt it is very easy.

All of my ESP8266-based devices use mDNS/SSDP to announce themselves on the network. That makes them show up in Windows in the Network Devices (which means you can double-click on them to get to their web pages), and also makes it super trivial to write an OpenHAB binding to find them.

Its definitely the best route to go to for simple management. If I deploy new devices, they just show up, if they change IPs, they just pick up the new IP, etc…

There’s tons of examples of using SSDP on the ESP8266. And the ESH/OpenHab2 docs have samples for bindings to use SSDP.

That’s exactly what I said above. Braodcasting using UDP is easy but still, you’d have to manually do it in openHab. If we can come up with a protocol, we can have this done automatically by openHab. The thing is we need to create a contract between the devices and OH so that devices will broadcast it’s device type and OH would know what to do, which methods to retrieve states, and how to update states. Doing it this way, it would be easy to autodiscovery stuff much like how the zwave binding work.

Your basically describing UPnP.

A generic UPnP plugin would do that if your hardware exposed it. It’s how most media controllers work, Sonos, all the Vera home automation devices, etc…

is there some progress in here ? i’m using the espurna firmware on my esp8266 devices. i would love the idea that i switch them on the gets visible in inbox and expose there channels…

could someone point me in the right direction ? at the moment i use the rest api, by using mqtt, i havent until now, would the be visible in inbox and all that stuff of automatic item linking ?

I’ve got a binding that isn’t really in any shape to commit to OH yet that I use for most of my ESP8266-based systems in my house (around 20 of them).

They basically use mDNS for autodiscovery, and a standard JSON payload (easier than full UPnP) that tells the caller what the available services (and therefore, channels) are.

Its on my list to get back to at some point, as I make an upgrade pass through the firmware on all these devices. I’m hoping to get a combination of an Arduino library and OH2 binding that handles bidirectional services and autodiscovery. (The reason the stuff I have is not sufficiently generic to commit to OH is that they use a combination of HTTP, raw TCP, and UDP interfaces, and its too convoluted and use-case specific at the moment.)

That said, you can do a lot of it right out of the box – if you set up an mDNS discovery endpoint on the ESP8266, you can set a specific hostname to get advertised, and you can use those hostnames in the TCP/UDP binding (with the caveat that the TCP binding is a festering pile right now, and has memory leaks).

Basically, if you expose your device’s hame as “mydevice-{chipId}” or something, where chipId is the ESP’s internal ID, you’ll have a fixed hostname you can use in a TCP channel, so you can do something like:

String MonoPrice "MonoPrice Amp [%s]" (MonoPriceGroup) { tcp=">[monoprice-13997243.local:1001:]" }

That’s taken from a set of items I use for controlling a whole-house audio amp. The ESP’s hostname is “monoprice-13997243.local”, and OpenHab can connect to it just fine. Its not really auto-discovery, but at least the address is stable even if I don’t use static IPs. Basically the device shows up as {hostname}.local