Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Light Automation via mqtt

Status
Not open for further replies.

jab99407

Member
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?
 
Last edited:
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.
1660361120970.png
 
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.
(The US version is less than $10)

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.

 
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
 
Apologies, I gave you the wrong link.. This is the one I ended up using:

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:

C:
//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:

C:
// 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:

C:
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..
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top