Light Automation via mqtt

[jab99407]

I have 20 lights in my house including street lights that I want to control through an application. I have a ESP 01 with a single channel relay module board that controls a one light. I have a total of 20 ESP 01 with realy board to control 20 lights. I have a raspberry pi that I want to use to communicate with 20 esp 01bords . I have decided to use MQTT Protocol for communication between raspberry Pi and esp 01

In my system raspberry pi will act as broker and esp 01 will act as client.

I am asking for some suggestions, what features should I keep in the application?

 

[ronsimpson]

I have played with Node Red on the Pi. It has the ability to turn on/off remote relays and also graph on/off events and power usage.
I am using SonOff relays.
My relays are triggered by time, temperature, light, motion-not work yet. For a while we had a relay connected to the wind speed from the weather lab.
I hope to follow your progress, I am not a programmer and am in over my head.

 

[jab99407]

I have played with Node Red on the Pi. It has the ability to turn on/off remote relays and also graph on/off events and power usage.

looking great,
Which protocol are you using? I assume you are using http protocol.

 

[rjenkinsgb]

I'd have a regular "Alive" beacon from any powered on unit with its ID, eg. every five seconds or so.

As it's just a single switch, return the new status immediately after any change command and also send the present status when it sends a beacon.

If you are also using local control switches, the common method with such as Z-Wave control modules is that a change of the local switch inverts the present on/off state.

That change should also be sent immediately.

(In other words, the switch + remote module act together like a conventional two-way light switch setup - operating either changes the on/off state.

The only other possibility is if you included a load sensor, so you could send current consumption as well?

I just use Z-Wave modules for lighting on my setup as they are so cheap and ready to use on AC power; eg.

In Wall Dual Relay Switch Module(EU) TZ74EU Plus,China In Wall Dual Relay Switch Module(EU) suppliers/Manufacturers | Z-wave Module|Z-wave Smart Home Product - TKB TECHNOLOGY

Frenquency:868.42MHzResistive Load:2X1500W(230V)Overload protectionOperation range:up to 130 feet line of sightUser manual please download from / From China Manufacturers/Suppliers

www.tkbhome.com

(The US version is less than $10)

TZ06 In Wall Dual relay switch module 908.42MHz ,China TZ06 In Wall Dual relay switch module 908.42MHz suppliers/Manufacturers | Module Promotion|Online Order - TKB TECHNOLOGY

Product modelFrequencyTZ06 US908.42MHzPromotional product listWe aggregate all promotional products in google excel, you can find the one you want. Pl From China Manufacturers/Suppliers

www.tkbhome.com

But I have started using MQTT and ESP01s to integrate my cleaning robots (irobot Roombas / Scooba / Dirt dog).
They are all different ages and have different interfaces, just to make it, er, interesting....

You may find the original project I based mine on to be useful - it includes all the MQTT stuff; just leave out the roomba-specific parts that you don't need.

GitHub - johnboiles/esp-roomba-mqtt: ESP8266 MQTT Roomba controller (Useful for hooking up old Roombas to Home Assistant)

ESP8266 MQTT Roomba controller (Useful for hooking up old Roombas to Home Assistant) - GitHub - johnboiles/esp-roomba-mqtt: ESP8266 MQTT Roomba controller (Useful for hooking up old Roombas to Home...

github.com

 

[jab99407]

You may find the original project I based mine on to be useful - it includes all the MQTT stuff; just leave out the roomba-specific parts that you don't need.

I only have two questions

1) If we have one broker and more than one client then how can you identify the client for which message is to be published.

Will the client id be written in the code of the broker so that the message can be published to the particular client?

2) I want to control 20 lights from broker so how many topics should I publish and how many messages should I send to each client

 

[rjenkinsgb]

Apologies, I gave you the wrong link.. This is the one I ended up using:

GitHub - thehookup/MQTT-Roomba-ESP01: Making an old roomba smarter using and ESP01

Making an old roomba smarter using and ESP01. Contribute to thehookup/MQTT-Roomba-ESP01 development by creating an account on GitHub.

github.com

The project video is here, which helps explain the MQTT side:

Go through the notes with the project and in the youtube text to add the various libraries.


In that code, it's this section that you customise for each device:

//USER CONFIGURED SECTION START//
const char* ssid = "your_wifi_name";
const char* password = "and_password";
const char* mqtt_server = "192.168.0.52";
const int mqtt_port = 1883;
const char *mqtt_user = "";
const char *mqtt_pass = "";
const char *mqtt_client_name = "Roomba880"; // Client connections can't have the same connection name
//USER CONFIGURED SECTION END//

In the original, every publish has the device name hardcoded, like
client.publish("roomba/status", "Cleaning");

With that, you would need to change every publish line to a different name...

I added a bit of code in the end of that user config section to make it more versatile:

// The name to use for this specific machine -
// Change it if you have more than one roomba / scooba / dirt dog
// etc. so each has a unique set of topic data to identify it.

// Ensure the string ends with a single forward slash/
const char *mqtt_topic = "roomba/";

Plus a couple of extra functions:

void buildTopic(char *topic) {
  // Result is in topicBuf global, no need to return anything

  strcpy(topicBuf, mqtt_topic);
  strcat(topicBuf, topic);
}

void rPublish(char* topic, char* payload) {

  buildTopic(topic);
  client.publish(topicBuf, payload);
}

All the publish lines then only need the sub-topic and payload, and call the rPublish routine rather than publish directly. rPublish builds the topic string with the global device name.

Also add the character buffers at the end of the variables list:
char topicBuf[50];
char commandBuf[50];

It also need the callback routine matching against the device name, but I got sidetracked by the comms and hardware variations between all the different robots - no two are identical & a couple need major work just to access the internal serial ports..

You can use the buildtopic function to create another character string with the "device_name/commands"
that's what the commandBuf was for, so it would be possible to match the callback topic string.

You could use a #define for the name everywhere instead..

 

[tepalia02]

I think ESP32 will be more convenient. It has more GPIO pins than ESP-01. The processor speed is higher too. Here is an example of MQTT with ESP32: https://www.theengineeringprojects.com/2021/11/esp32-mqtt.html