Starting with release 2024.11 of Home Assistant, there is a change in the way the recommended topics and payloads are structured, based on a single device payload with all entities defined, as opposed to a separate payload for each entity with matching device details. The method used in this video is still supported and still works (for now), but you can find a short update video with the changes here: ruclips.net/video/n9QXRcFqbLY/видео.html
Great video; i feel your angle on MQTT, HA, etc. is unique in a fairly crowded field of options and I always learning more about things like MQTT interactions like this video highlights
Thanks! I often learn a lot about a topic in the process of creating the video and I try to share that from a perspective of someone that might just be starting out, with little-to-no experience. Sometimes I succeed at it better than at other times! I really appreciate you taking time to leave a comment. Feedback really does drive the direction of future videos.
Great explanation. I knew you would do a much better job of explaining it than I ever could!! I am glad you shared the mqtt message size limit problem. That took me a while to figure out. Thanks for sharing. I would love to see some more mqtt stuff. Getting into the weeds of things so to speak. Your videos are a huge help to the rest of us. Joe
Thanks! As I mentioned in another comment, I think I often learn as much (if not more) when making a video than those who watch it. And same here... it took me forever to discover the pubsub library issue. I kept thinking I had something wrong in the JSON formatting. As soon as the buffer size issue was fixed, everything just started working! So I did want to try to help others avoid the same issue we experienced. Thanks for the comment and the kind words! I do appreciate it and viewer feedback does have a big impact on future videos. Have a great New Year!
I JUST found your channel and watched your bed sensor and IR transmitter video not even 30 minutes ago, it was super interesting. This video looks great as well, and I’ll be setting up HA for the first time later today so thank you 😊
Just curious: How well has the FSR strip under your bed held up over the past several months? I’ve heard FSR as a slightly better alternative to more conventional pressure mat alarm systems, but they also degrade over time. About how long is the lifetime of the FSR in your experience? Thank you in advance!
First... welcome to the channel. Glad you found me! As far as the FSR, it has only been in use for a little more than 6 months at this point, but is still working fine. I do notice a little "drift" over time, but I believe that is due to my Sleep Number bed losing a little pressure, as it tends to do. When I notice the drift, I check the Sleep Number value and reset it, and that change in pressure generally 'resets' the FSR value. I don't think this would occur with a 'conventional' mattress. So, after 6+ months, I still get pretty consistent readings of around 3V when unoccupied and less than around 1.5V when occupied. I do get some variations in the occupied voltage depending on how I'm positioned in the bed, but the reading is still significantly different enough from unoccupied to use for automations. I haven't noticed any degradation yet... that my change in another year or so, but I'll just have to wait and see.
That sounds great, thank you so much for your thorough anecdote in regards to the FSR. It seems like as long as I do a decent enough job calculating the proper resistor value (to have the largest difference in voltage), then it should be a more than viable long-term solution. Many thanks@@ResinChemTech
You are very welcome! I do like how easy it is to remove and re-add devices and entities... even multiple times if necessary until you get things the way you want. Thanks for watching... and taking time to leave a comment!
Thanks! I do always try to include a written guide for any videos that show wiring diagrams or have code blocks so that people don't have to try to 'freeze frame' the video if they want to see them. Thanks for watching and taking a moment to post a comment!
This is another great video, your methodology and descriptions are just what the doctor ordered for me! Excellent coverage of what used to be a pure mystery to me. Still not there yet but I will make it someday and this will be booked marked and waiting when I arrive! Hope that you had a great Christmas and will have a safe and prosperous New Year!👋
Thanks Rodney! This isn't a video that will have an immediate impact on the average Home Assistant user... at least until they begin developing their own custom firmware for their DIY projects. But for those that do... and want to share their projects... it sure is a great way to make Home Assistant integration a lot easier. And here's wishing you a wonderful New Year full of new DIY and home automation projects!
I had tried in once in the past for just a couple of basic entities. It worked fine, but I hadn't really dug into some of the details and options, like creating a device until I decided to make this video. Like a lot of my videos, I probably learned more than anyone who watches the video! Now I need to go back and update all my project repos to implement discovery because as I mentioned, many people that implement my projects struggle the most with getting all the manual YAML correct for the MQTT entities. If nothing else, it should make supporting my projects a bit easier on my end. Thanks for watching and taking a minute to leave a comment!
@@ResinChemTech Same here - once I've learned how to create device with multiple entities, I was like "I should go back and...", but so far I've only edited one old project. Too lazy ;)
Thanks! I think if you are looking to integrate a device into Home Assistant, this is much easier than trying to decode and interpret some of the API stuff... if you can add MQTT to your device. My only wish is that it would prompt the user like when other devices are 'discovered' by Home Assistant. But since the devices are added immediately, it just means you have to manage that on your device's end. Thanks for watching and taking a moment to post a comment. I appreciate it!
Thanks for your videos! For argument sake. Is it possible to manually create a device where different mqtt entities are combined or this is only possible via discovery?
You are very welcome! I'm not 100% sure what you mean by 'combining' different MQTT entities, but discovery is simply a convenient way to get your MQTT device into Home Assistant. It certainly isn't required and I created a lot of my own DIY devices and used MQTT and YAML on the Home Assistant side to integrate those devices/entities. But the gist is that you can do whatever you like or need on the device's code side to publish whatever values you like... and combining them if desired. Then you just manually define the Home Assistant entities via YAML. Discovery simply handles this last step of creating the Home Assistant entities without manual YAML. Otherwise, the process is the same. Let me know if I am misunderstanding your question.
@@ResinChemTech thanks for your answer. I've got mqtt entities created via yaml on the configuration file already. Now i was trying to understand how could i create a device, and i got stuck because i couldn't find any guide or tutorial. I understand with discovery you can create entities and devices, i want to know how can I do it manually (this is what i meant by "combining". You have a bunch of entities under the same device). Makes sense? Do u have any tips on how to search for this information? Many thanks!
Ah, I understand you now. I haven't tested this, but I believe you can just include the device: info under each entity just like you would with the JSON. Do note that each entity must have a unique_id and that all the device info (identifiers, etc.) must exactly match for all the entities. See this example: community.home-assistant.io/t/mqtt-entities-via-configuration-yaml-how-to-combine-into-a-device/583295 It reported works as reported here, but as I mentioned, I haven't tried it since my devices are created via discovery. Let me know if the above method works for you.
Great Video. Unfortunately I need to geht more Details in how to switch Off or On auto discovery as you have shown. I'm running HA OS latest Version. How can I Set discovery Default to Off in yaml? And what ist the entity or variable to Access in Automation? I would Like to have a toogle Button in the user gui. Any hint how to find that ist highly welcome.
In the video, I mention toggling discovery off/on, but this is handled on the Arduino or external device's side. In my example, I issued a URL command to the IP address of the remote device to turn discovery off/on. It has nothing to do with Home Assistant or any Home Assistant settings. You can globally disable discovery in Home Assistant via the MQTT integration configuration, but note that this is all-or-none and turning it off may impact the discovery of other devices. I don't believe there is a service call via YAML or GUI automation that can toggle MQTT discovery on the Home Assistant side. So my point in the video is that the external device code/creator that is going to use MQTT Discovery to create their device in Home Assistant should provide an option or feature so that discovery can be enabled/disabled on the device without requiring the end user to change any discovery settings in Home Assistant that could impact other integrations.
Nice explanation and integration possibility. Any thoughts regarding an Auto Discovery option implemented in ESP Easy (mega)? I am running ESP8266 Wemos D1 mini devices integrated in Domoticz. Would like to explore more in HomeAssistant, however MQTT Auto Discovery is not that easy. Any suggestions for this?
Well, I'm not very familiar with ESPEasy, but a quick glance at the documentation show that it does have commands/functions for subscribing and publishing to MQTT. So from that perspective, you'd just need to use the same logic (although the syntax will be different) for creating and publishing the discovery topics and payloads. However, what I don't know if is the JSON payload can be created and formatted properly for publishing via ESPEasy. The logic and process is identical regardless of language. You just need to create the special payload and publish it to the Home Assistant discovery topic. But you must be able to create the JSON serialized payload in whatever language you are using. ESPHome supports both MQTT publishing and JSON payload options (although discovery generally isn't needed with the API integration), but I just don't know enough about ESPEasy to know if creating a JSON payload is possible.
A question about HOME ASSISTANT MQTT and statistics: It seems my MQTT devices integrated with mqtt: yaml (for now) do not have statistics associated with them. Where as my ATC_MI thermometers integrated with ble_tracker do. Can you explain why this is? Thank you for your excellent channel!
If you are defining your own MQTT entities, then you must include a state_class if you want long term statistics to be tracked. According to the HA developer documentation ( developers.home-assistant.io/docs/core/entity/sensor/#available-state-classes ): "Home Assistant has support for storing sensors as long-term statistics if the entity has the right properties. To opt-in for statistics, the sensor must have state_class set to one of the valid state classes: SensorStateClass.MEASUREMENT, SensorStateClass.TOTAL or SensorStateClass.TOTAL_INCREASING. "
Within OpenMQTTGateway, Home Assistant discovery is already enabled by default. How this works and its use is described on the OpenMQTTGateway site: docs.openmqttgateway.com/integrate/home_assistant.html#auto-discovery
Unfortunately I messed this up too, my MQTT integration still says, "no devices or entities". I know the IP address for the device but Home Assistant doesn't offer a way to enter it.
And you have added the MQTT code to the device you want to integrated into Home Assistant that publishes the discovery topics, right? If so, and they aren't appearing, then you need to check the broker to see if your topics and payloads are correct, using a utility like MQTT Explorer. As far as the IP address, that isn't something that you enter on the Home Assistant side. You have to have the code on the device to publish the IP address to the state (e.g. /stat ) topic that was defined when the device was discovered. When the device publishes the IP address on the same state topic that Home Assistant is listening to, the IP address will be automatically updated in Home Assistant.
Great video well-done , I have a custom sensor with temperature and humidity and it has also current measurements is there a possibility to define a current sensor sending a float ? Would that still be a sensor type in homeassistant
Thanks. If I understand what you are asking, the current sensor would not be any different than temperature or humidity in terms of how you'd structure it. The payload really doesn't have a data structure (which is why you can pass things like a JSON array as well as single values. So passing current as a float (e.g. 26.4) isn't really any different than passing a temperature as a float (e.g. 71.3). On the Home Assistant side, and according to the official docs, a sensor can contain a datetime, integer, decimal, float or string. So, yes, you should be able to create a current sensor in Home Assistant in the same manner that you do for temperature and humidity. If for some reason your device isn't able to create or format a value in the way you want for Home Assistant (or you need to do things like apply additional processing), you can take the MQTT sensor in Home Assistant and use that to create a templated sensor that applies this extra processing or formatting. I hope that answers what you were asking!
A great tutorial! THANKS! I have a MKR 1010Wifi I'd like to use for this(which uses the ESP32 chip). Do you think this would work for this unit as well?
You are welcome! I think as long as you can write the code to publish (and optionally subscribe) to the proper MQTT topics, it would work. The use of HA Discovery is pretty device and language agnostic. As long as the device or code language used can support MQTT, then it should be entirely possible to publish the discovery message for Home Assistant to automatically discover and integrate the device.
i'm new to all this home assistant and ESP32 stuff :) i'm loving the vids. currently trying to make my two 8x32 boards as a scoreboard on esp32 and wled... and it's hard :( how can i stop the text from scrolling? i just want static text :(
Unfortunately, that's a function of WLED... which isn't my firmware so I really don't have any control over its features. I don't know if there is a built-in way of having static, non-scrolling text. My clock / scoreboards / text displays are my own custom Arduino firmware so I am in complete control of that and have static score/text displays on my matrix. You probably need to post your question and/or request to the WLED Discord account or to their Github repo. Sorry I can't be more help here... but since WLED isn't my firmware, I'm not really able to address its features or make any changes to them. But WLED is constantly being updated, so a feature that isn't there today might be there tomorrow.
Hiya. Thanks for replying!! :) i was just throwing it out there as a current project i'm messing with, BUT... i am still very much following your home automation stuff, and will likely end up using your methods. Thx for all your vids by the way :) @@ResinChemTech
I agree. ESPHome is great if you just want to integrate a couple of sensors, a light or some sort of entity like that. But good luck with trying to do more advanced logic like loops with delays, etc. For building a bit more complex devices, I think that using Arduino C++ (or Python, etc.) and then using MQTT to integrate into Home Assistant is the better option... at least for me. Thanks for watching... and taking a few moments to leave a comment!
@@ResinChemTech Completely agree. Have some devices with a display for user-interface and status messages. Wouldn't know where to start with those in ESP-Home. ESP-Home seems to me, just an extra abstraction layer over Arduino code, with all the HA specific stuff hidden from view. No no.. thank *you* for all the time and effort you put into these videos.
You simply use whatever function in your code that is needed to take a temperature reading and store that value in a char array. You then use this char array as the payload and publish a message to the topic you defined for the state_topic in the discovery statement: curTemp = getTemperature(); sprintf(outTemp, "%3.1f", curTemp); client.publish(state_topic, outTemp, true); Of course the function to get the temperature will be dependent upon the library used and "state_topic" would be whatever topic you have established for the device's temperature state, such as "stat/mydevice/temperature". If you visit my repository ( github.com/Resinchem ), you can find many examples where I'm using MQTT. Most will have sections near the end of the source code with 'updateMQTTxxx' functions that will show publishing actual values from the device.
Thanks, for this video. You’ve cleared up a couple of things for me. I’m new to HA and I’m working on my first MQTT-HA integration. My MQTT device is a lamp that I retrofitted with an ESP-32 and some WS2812 led strips. I used to control this lamp with Blynk but now that they’ve changed to a subscription service I’m taking the opportunity to convert it to MQTT control via HA. I’ve got MQTT working and communicating between HA and my lamp. I can turn the lamp on and off via HA and I can see the status changes on HA. What I’d like to add next is the ability to send RGB colors and effect settings to my lamp from HA. So far I haven’t figured out how to add these controls to HA and then send the configuration to my lamp. Any assistance or pointers would be appreciated.
I'm assuming you developed your own code that is running on the lamp ESP32? I've done something similar with my LED clocks (also using an ESP and WS2812b LEDs). In my case, I have three input number sliders in Home Assistant to set the red, green and blue values. I use these to pass a 3-value comma delimited payload for the RGB values (such as "255,0,128"). Then in the MQTT message processing on the device, I simply used the comma to split the payload into separate red, green and blue variable values that I could use to set the color of the LEDs. Alternatively, you could publish three separate message for R, G and B. If you want to see an example, my matrix clock code is available in this repo: github.com/Resinchem/LED-Matrix-Clock_WS2812b If you look at the matrix-clock-main.ino file in the /arduino folder and locate the section of code labeled ***MQTT Message Processing***, you will see examples of how I'm taking the 3-value MQTT payload and splitting it out to separate R,G,B variables that are then used to set the RGB values of the LEDs. I hope that gets you pointed in the right direction.
@@ResinChemTech Yes, for the most part it’s all hand-coded using the FastLED library. Thank you for your extensive reply. I’m slowly starting to understand the way HA does things. I think I have a grasp on how to proceed. Thanks for your help.
The code for publishing MQTT discovery commands goes onto the device you want to integrate to Home Assistant. This could be an ESP device, a Raspberry Pi or really any device that runs a language that supports MQTT. In this video, I'm using Arduino/C++ code on an ESP8266 that publishes the MQTT discovery commands. Those MQTT statements are published to an MQTT broker and Home Assistant "'reads" those payloads and creates the devices and entities in Home Assistant. If you are new to MQTT, you might want to start out by watching this video that describes MQTT and how it works in a little more detail, along with how it is used in Home Assistant: ruclips.net/video/Q0S0xOW35k8/видео.html
I'll for suer add this code to some of my projects. I had to look up your website to find out more about how you tell the device to turn discovery on and off, but perhaps you can include a quick link to how to handle the post call.
Well, using an HTTP post isn't necessarily the only (or best) way to handle turning discovery off/on. But it was a quick and simple way for me to show the results in this video. I'll try to add something the Github gist file example when I get time, but the short of it is that you include the ESP libraries to make your device act as a web server (e.g. ESP8266WebServer library). You can then setup callbacks for various URLs (such as 'discovery_on' and discovery_off'). In those callbacks, I'm simply setting the value of the global 'auto_discovery' variable and then calling the ha_discovery function. The ha_discovery function then either publishes the JSON payload or an empty payload for each entity based on the variable setting. I hope that at least provides some direction. I'll try to follow up to this comment if/when I add something to the gist file as an example.
OK... it didn't take me long, but I did update the gist file ( gist.github.com/Resinchem/ecd86dfb52bd699c79acfa80cd348d7b ) with the code I used to enable/disable discovery using an HTTP post. Note that like the rest of the sample code, it is incomplete... it doesn't include things like declaring the MQTT client, Wifi Client, HTTP server, etc. But it does include the basic logic on how I toggled discovery in this video.
This video has helped me out so much! For some reason, you're one of the very few sources who shows both the arduino side and the homeassistant/mqtt side. I don't know why, but other guides that I've found only show one part of the setup.. Thanks for giving us a complete package! On that note, I am running into a weird issue (yes, I'm going to be that guy. I'm sorry, I just can't seem to find what's going wrong, and google can't seem to help me, so I'm desperate). While adding a device with entities works, only entities that are of type sensor are picked up by homeassistant. Switches, lights, fans, humidifiers, none of them work. If I understand correctly, the only thing that really matters when it comes to determining the type of an entity is the part in the discovery message. Any input is greatly appreciated!
Glad you found the video helpful! I try to approach all my videos from the aspect of explaining both the "how" as well as the "why", so that someone has enough info to duplicate my project or understand it well enough to adapt it to their own needs. That tends to make my videos longer than most, but I also felt that this approach was lacking when I was first learning. As far as your issue, have you increased the default buffer size for the Arduino pubsubclient library? This was my initial problem (and as you saw in the video, only my sensor was picked up too, likely because a sensor requires the smallest payload). By default, the buffer is only 256 bytes. Any MQTT messages longer than that are simply dropped (silently, with no error) meaning they don't show up in Home Assistant. Try increasing the buffer. If you are using the latest pubsubclient version (2.8.0 in my case), in the setup right after you defined the MQTT server: client.setServer(MQTTSERVER, MQTTPORT); Add the following line: client.setBufferSize(512); You might even need to make that 1024 if you have exceptionally long messages and if your device has the memory to support it. That fixed all my problems with my devices and entities not appearing. Note that if you have an older version and/or want to permanently increase the buffer size, you can edit the pubsubclient.h file and increase the MQTT_MAX_PACKET_SIZE from 256 to 512 (or 1024). Let me know if increasing the buffer size resolves your issue. If not, then it is likely something wrong with how you are forming the serialized JSON payload.
@@ResinChemTech Thank you for the quick reply! I did try increasing the buffer size to 512, as well as 1024, but no dice. It's especially strange since it does get picked up when I say it's a sensor.. So this works: String discoveryTopic = "homeassistant/sensor/" + deviceUniqueId + "_sensor_1/config"; But this doesn't: String discoveryTopic = "homeassistant/switch/" + deviceUniqueId + "_sensor_1/config"; Googling this problem is frustratingly hard lol, thank you for taking the time to try and help me out 🤗 Edit: I just checked with MQTT Explorer, and that does pick up the message regardless of what type of entity I use.. So the Arduino side is probably fine. Time to look at whatever HomeAssistant/MQTT is doing! I'm quite new to those things, but luckily I just found this cool RUclips channel that seems to have a video or two on the topic 👀 Edit 2: When I go to MQTT in HomeAssistant and listen to topics, the messages also show up regardless of the entity type! So the MQTT addon in HA does receive the discovery messages, but for some reason only decides to integrate entities of type sensor.. very curious
You are using different object IDs, correct? In your above example, you have changed the type from sensor to switch but the object ID (deviceUniqueId + 'sensor_1') is the same for both examples. Each discover topic and entity ID must have a unique object Id in the discovery message and if a unique ID is supplied in the entity payload (recommended), it has to be unique from all others as well. It may have just been an example above, but remember that the object ID that appears between /switch/ (or /sensor/) and /config must be unique for each discovery topic, regardless of entity type. Otherwise, other discovery topics after the first one just updates the config of the first one.
@@ResinChemTech That's a good point! I updated the code to use different object ID's for the different entities, however, it does not seem to resolve the issue
@ResinChemTech Figured it out! I didn't realize the command_topic was a required value for Switches. Documentation is a wonderful thing. If only I had read it carefully.. 😬 Thanks for helping me out! Excited to see your future videos!
If it is a momentary button (non-latching), then you could create that as either a binary sensor or button entity. You can look up both types in the Home Assistant documentation, see the various properties and services, and decide which type of entity would be best for your particular situation.
Thankyou for a great tutorial. Could you plz share the full code please. I am new to iot world and really struggling to automatically add DHT sensors to homeassistant.
If you check the video description, you find links to both a written guide to this topic and a Github gist with a copy of all the pertinent code that I showed in this video. That being said, if you are just wanted to add something like DHT sensors to Home Assistant, using something like ESPHome would be a much better (and easier) solution that writing your own code with MQTT discovery: esphome.io/components/sensor/dht.html
@ResinChemTech I am already using ESPHOME. I wanted to learn how to setup and enable autodiscovery of MQTT without using esphome. I took help from your code, I can see the MQTT topics being published correctly but the devices and sensors are not showing in Homeassistant MQTT integration. Is it possible to share my code with you so that you can have a look and guide me what am I doing wrong? Thank you
Sorry... my misunderstanding. If you are seeing the payloads published in your broker, but the device/entities are not showing in Home Assistant, I recommend trying the following: Copy the payload you see in your broker (should be JSON formatted) and paste it into some sort of text editor. Be sure the format looks correct... opening/closing brackets match up, etc... and is what you expect it to be. Next, assure that all required fields are present for whatever type of entity you are trying to create... sensor, switch, light, etc. Since you mentioned DHT sensors, I'm guessing you are trying to create two sensors. You need, at a minimum, a state_topic defined. You can always check the HA documentation for the type of MQTT entity you are creating to see what is required or optional: www.home-assistant.io/integrations/sensor.mqtt/ If your device is publishing under the proper discovery topic (/homeassistant/entity_type/uniqueID/config) but isn't showing up in Home Assistant, then it is most likely something wrong or missing in the payload...or you have disabled discovery in your MQTT integration. Looking at the actual published payload in a text editor can really help. And don't forget if you are using the Arduino pubsubclient library, it defaults to only 256 bytes so it could be truncating your payload if you didn't increase the buffer size. You should see this in the payload in the broker as well if it has been truncated. I initially had the same problem when I first started out (and occasionally still do) and it is almost always due to a malformed payload or a required field missing from the payload.
Very well done, but you really glossed over how to send control messages to the DIY device. Yes, I've looked at both MQTT videos and I'm still struggling with getting something like a button to turn something on. The interaction of scripts, templates, and automation are harrowing and a real stumbling block for adopting Home Assistant fully. I like your explanations and appreciate that you can't take forever making a video, but with the terse documentation that has very few examples in the HA documentation something more is needed to tie all this together in a newbie's mind. Maybe publish more on your blog about this from a simple dimmer device all the way through the control (including the card used) on a dashboard with one item on it.
While you mentioned that you watched both MQTT videos, did you also watch the third one that approaches integrating MQTT devices from the Home Assistant side (this is a Home Assistant 101 video instead of MQTT 101): ruclips.net/video/WYyPMHqMV-w/видео.html This gives examples of how to send commands from Home Assistant for both switches and lights (including brightness control). This video and related blog are about the best I can offer. I understand your frustration. But when dealing with DIY projects... and even Home Assistant... a certain amount of technical skill and often a little bit of individual research is simply part of the process. I sure didn't learn everything about how to use MQTT or implement my own DIY projects in Home Assistant from any single video or article. It took a lot of watching, reading and often looking at example of other's code, and then simply trying and experimenting on my own to learn how everything fit together and functioned. It took even longer to learn and get comfortable with YAML and the Home Assistant configuration files. While it has come a long way, Home Assistant is simply not a plug-and-play solution and it will likely always require some level of tinkering and learning to get the most out of the system. I'm happy to answer any specific questions or to try to help you with a particular issue. But no matter what sort of step-by-step guide I might make, it won't be a perfect fit for everyone... or there will be some specific need that I didn't cover for someone. I try to provide the best info that I can to introduce the concepts... with the understanding that more research may need to be done for a particular individual's project or knowledge level.
I took your advice and started over with the videos and played sections of them several times to get more familiar with the parts related to my problem with getting data going both ways. Then I coded up a complete configuration for a device and code to keep the various status items current. Of course, it didn't work, and after much close inspection, I managed to get the various topics and such all spelled correctly as well as coming up with a way to assign a unique device id that I could actually remember for more than 10 seconds as I scrolled down the page to put the next one in. It all works now, but some things came up besides keeping close track and inspecting everything a dozen times to make sure you have that mqtt topic exactly correct in every single place it shows up. The biggest is that when experimenting with the unique device id for both entities and devices, you can inadvertently create ghost devices that you can't edit or delete. They hang around confusing things because the names are so similar to what you are actively dealing with and they just appear and disappear as you work. This is mentioned without resolution on the discussion board. The other thing that I noted was that publishing is incredibly easy (discounting the paragraph above). I did not have to use the publish at all; just setting the state in the mqtt integration 'select' was handed automatically. This is nice because of the drop down list that can be used by a human. I haven't tested the others yet, that is coming soon. I also didn't have to use any templates yet as I step through the device; that is handled for me as well. All in all though, the three videos taken as a unit, gave me enough information to test and correct mistakes through the process of a reasonably complex device. Good job and good suggestion, THANK YOU!
I'm glad you got it working! Like most things, It will get easier the more you use it. Sometimes, for me, it helps to look over others' code and see how they did things. Along those lines, just today I released an update to the ESP Parking Assistant Github repo that implements MQTT Discovery (and the generation of an unique ID based on the MAC address of the ESP). I also have a couple of other repositories/projects that make heavy use of MQTT with Home Assistant (although not auto-discovery). These repos have examples of the Home Assistant side plus the device (Arduino) side where data and commands are being sent back and forth. Probably the two biggest examples are the Arylic-Amp-MQTT and LED-Matrix-Clock_WS2812b repos. Again, this may or may not be helpful to you. I just throw it out there since, for me, looking at code created by others is one of the ways I like to learn more about how something works or alternate ways of accomplishing a task. You can find all the mentioned repos here: github.com/Resinchem?tab=repositories
Thank you for the pointer and I will, again, follow your advice and go prowling for ideas. My take on the unique id is a bit different. I think about the next time I add a DIY idea and how I will remember the dog gone id for the last one, etc. I want to be able to see it and know what it is as well. There are ways to do it, but then I have to remember what that was as well. I do something like "theSnickersBarBought-June16" So I have something that can be read while troubleshooting with MQTT. I may regret it, but it's working while I learn. It's especially useful for keeping track of the master device with a bunch of entities.
Sharp eye! That is probably a typo on my part, but it would actually still work as written. The top payload is the unique id for the entity. While the Arduino publish statement just needs an unique 'object id' for the discovery statement. Yes... I usually use the same ID for both (so this _was_ a typo on my part with the extra 't'), but it isn't a requirement. The publish statement can be any unique string, so even though I didn't intentionally include the extra 't', it would actually still create the device/entity as expected. Think of it like this: The top unique ID is the ID for the entity, while the publish statement includes a unique ID for creating or updating the entity via MQTT discovery. Since, as shown later in the video, I programmatically create a unique ID based on the device MAC address. It is easier to create a single base unique ID and adapt it for both the entity ID and the publish object ID. But it certainly isn't a requirement to have these two identifiers be the same value.
Starting with release 2024.11 of Home Assistant, there is a change in the way the recommended topics and payloads are structured, based on a single device payload with all entities defined, as opposed to a separate payload for each entity with matching device details. The method used in this video is still supported and still works (for now), but you can find a short update video with the changes here: ruclips.net/video/n9QXRcFqbLY/видео.html
Great video; i feel your angle on MQTT, HA, etc. is unique in a fairly crowded field of options and I always learning more about things like MQTT interactions like this video highlights
Thanks! I often learn a lot about a topic in the process of creating the video and I try to share that from a perspective of someone that might just be starting out, with little-to-no experience. Sometimes I succeed at it better than at other times!
I really appreciate you taking time to leave a comment. Feedback really does drive the direction of future videos.
Great explanation. I knew you would do a much better job of explaining it than I ever could!! I am glad you shared the mqtt message size limit problem. That took me a while to figure out. Thanks for sharing. I would love to see some more mqtt stuff. Getting into the weeds of things so to speak. Your videos are a huge help to the rest of us.
Joe
Thanks! As I mentioned in another comment, I think I often learn as much (if not more) when making a video than those who watch it. And same here... it took me forever to discover the pubsub library issue. I kept thinking I had something wrong in the JSON formatting. As soon as the buffer size issue was fixed, everything just started working! So I did want to try to help others avoid the same issue we experienced.
Thanks for the comment and the kind words! I do appreciate it and viewer feedback does have a big impact on future videos. Have a great New Year!
I JUST found your channel and watched your bed sensor and IR transmitter video not even 30 minutes ago, it was super interesting. This video looks great as well, and I’ll be setting up HA for the first time later today so thank you 😊
Just curious: How well has the FSR strip under your bed held up over the past several months? I’ve heard FSR as a slightly better alternative to more conventional pressure mat alarm systems, but they also degrade over time. About how long is the lifetime of the FSR in your experience? Thank you in advance!
First... welcome to the channel. Glad you found me! As far as the FSR, it has only been in use for a little more than 6 months at this point, but is still working fine. I do notice a little "drift" over time, but I believe that is due to my Sleep Number bed losing a little pressure, as it tends to do. When I notice the drift, I check the Sleep Number value and reset it, and that change in pressure generally 'resets' the FSR value. I don't think this would occur with a 'conventional' mattress.
So, after 6+ months, I still get pretty consistent readings of around 3V when unoccupied and less than around 1.5V when occupied. I do get some variations in the occupied voltage depending on how I'm positioned in the bed, but the reading is still significantly different enough from unoccupied to use for automations. I haven't noticed any degradation yet... that my change in another year or so, but I'll just have to wait and see.
That sounds great, thank you so much for your thorough anecdote in regards to the FSR. It seems like as long as I do a decent enough job calculating the proper resistor value (to have the largest difference in voltage), then it should be a more than viable long-term solution. Many thanks@@ResinChemTech
Thank you very much for the clarification in removing discoverd entities.
You are very welcome! I do like how easy it is to remove and re-add devices and entities... even multiple times if necessary until you get things the way you want.
Thanks for watching... and taking time to leave a comment!
Really great videos. I enjoy learning from you about HA. I just read your written guide and all I needed was there. Thank you
Thanks! I do always try to include a written guide for any videos that show wiring diagrams or have code blocks so that people don't have to try to 'freeze frame' the video if they want to see them.
Thanks for watching and taking a moment to post a comment!
Fantastic, I can see this coming in handy! Thanks for another great guide!
Thanks! I appreciate the comment.
This is another great video, your methodology and descriptions are just what the doctor ordered for me! Excellent coverage of what used to be a pure mystery to me. Still not there yet but I will make it someday and this will be booked marked and waiting when I arrive! Hope that you had a great Christmas and will have a safe and prosperous New Year!👋
Thanks Rodney! This isn't a video that will have an immediate impact on the average Home Assistant user... at least until they begin developing their own custom firmware for their DIY projects. But for those that do... and want to share their projects... it sure is a great way to make Home Assistant integration a lot easier.
And here's wishing you a wonderful New Year full of new DIY and home automation projects!
I've used this a month ago on my own device, works great :)
I had tried in once in the past for just a couple of basic entities. It worked fine, but I hadn't really dug into some of the details and options, like creating a device until I decided to make this video. Like a lot of my videos, I probably learned more than anyone who watches the video!
Now I need to go back and update all my project repos to implement discovery because as I mentioned, many people that implement my projects struggle the most with getting all the manual YAML correct for the MQTT entities. If nothing else, it should make supporting my projects a bit easier on my end.
Thanks for watching and taking a minute to leave a comment!
@@ResinChemTech Same here - once I've learned how to create device with multiple entities, I was like "I should go back and...", but so far I've only edited one old project. Too lazy ;)
That was a great video. I didn't know it was so easy. Thank you.
Thanks! I think if you are looking to integrate a device into Home Assistant, this is much easier than trying to decode and interpret some of the API stuff... if you can add MQTT to your device. My only wish is that it would prompt the user like when other devices are 'discovered' by Home Assistant. But since the devices are added immediately, it just means you have to manage that on your device's end.
Thanks for watching and taking a moment to post a comment. I appreciate it!
Thanks for your videos! For argument sake. Is it possible to manually create a device where different mqtt entities are combined or this is only possible via discovery?
You are very welcome! I'm not 100% sure what you mean by 'combining' different MQTT entities, but discovery is simply a convenient way to get your MQTT device into Home Assistant. It certainly isn't required and I created a lot of my own DIY devices and used MQTT and YAML on the Home Assistant side to integrate those devices/entities.
But the gist is that you can do whatever you like or need on the device's code side to publish whatever values you like... and combining them if desired. Then you just manually define the Home Assistant entities via YAML. Discovery simply handles this last step of creating the Home Assistant entities without manual YAML. Otherwise, the process is the same.
Let me know if I am misunderstanding your question.
@@ResinChemTech thanks for your answer. I've got mqtt entities created via yaml on the configuration file already. Now i was trying to understand how could i create a device, and i got stuck because i couldn't find any guide or tutorial.
I understand with discovery you can create entities and devices, i want to know how can I do it manually (this is what i meant by "combining". You have a bunch of entities under the same device).
Makes sense?
Do u have any tips on how to search for this information? Many thanks!
Ah, I understand you now. I haven't tested this, but I believe you can just include the device: info under each entity just like you would with the JSON. Do note that each entity must have a unique_id and that all the device info (identifiers, etc.) must exactly match for all the entities. See this example: community.home-assistant.io/t/mqtt-entities-via-configuration-yaml-how-to-combine-into-a-device/583295
It reported works as reported here, but as I mentioned, I haven't tried it since my devices are created via discovery. Let me know if the above method works for you.
Great Video. Unfortunately I need to geht more Details in how to switch Off or On auto discovery as you have shown. I'm running HA OS latest Version. How can I Set discovery Default to Off in yaml? And what ist the entity or variable to Access in Automation? I would Like to have a toogle Button in the user gui. Any hint how to find that ist highly welcome.
In the video, I mention toggling discovery off/on, but this is handled on the Arduino or external device's side. In my example, I issued a URL command to the IP address of the remote device to turn discovery off/on. It has nothing to do with Home Assistant or any Home Assistant settings. You can globally disable discovery in Home Assistant via the MQTT integration configuration, but note that this is all-or-none and turning it off may impact the discovery of other devices. I don't believe there is a service call via YAML or GUI automation that can toggle MQTT discovery on the Home Assistant side.
So my point in the video is that the external device code/creator that is going to use MQTT Discovery to create their device in Home Assistant should provide an option or feature so that discovery can be enabled/disabled on the device without requiring the end user to change any discovery settings in Home Assistant that could impact other integrations.
Excellent video.
Thanks! And thanks for taking time to leave a comment. It is appreciated.
Nice explanation and integration possibility.
Any thoughts regarding an Auto Discovery option implemented in ESP Easy (mega)?
I am running ESP8266 Wemos D1 mini devices integrated in Domoticz.
Would like to explore more in HomeAssistant, however MQTT Auto Discovery is not that easy.
Any suggestions for this?
Well, I'm not very familiar with ESPEasy, but a quick glance at the documentation show that it does have commands/functions for subscribing and publishing to MQTT. So from that perspective, you'd just need to use the same logic (although the syntax will be different) for creating and publishing the discovery topics and payloads. However, what I don't know if is the JSON payload can be created and formatted properly for publishing via ESPEasy.
The logic and process is identical regardless of language. You just need to create the special payload and publish it to the Home Assistant discovery topic. But you must be able to create the JSON serialized payload in whatever language you are using. ESPHome supports both MQTT publishing and JSON payload options (although discovery generally isn't needed with the API integration), but I just don't know enough about ESPEasy to know if creating a JSON payload is possible.
A question about HOME ASSISTANT MQTT and statistics: It seems my MQTT devices integrated with mqtt: yaml (for now) do not have statistics associated with them. Where as my ATC_MI thermometers integrated with ble_tracker do. Can you explain why this is? Thank you for your excellent channel!
If you are defining your own MQTT entities, then you must include a state_class if you want long term statistics to be tracked. According to the HA developer documentation ( developers.home-assistant.io/docs/core/entity/sensor/#available-state-classes ):
"Home Assistant has support for storing sensors as long-term statistics if the entity has the right properties. To opt-in for statistics, the sensor must have state_class set to one of the valid state classes: SensorStateClass.MEASUREMENT, SensorStateClass.TOTAL or SensorStateClass.TOTAL_INCREASING. "
@ thank you so much. You are the best.!
Thanks for this Video. If i use OpenMQTT Gateway, how i could provide this?
Within OpenMQTTGateway, Home Assistant discovery is already enabled by default. How this works and its use is described on the OpenMQTTGateway site: docs.openmqttgateway.com/integrate/home_assistant.html#auto-discovery
Unfortunately I messed this up too, my MQTT integration still says, "no devices or entities". I know the IP address for the device but Home Assistant doesn't offer a way to enter it.
And you have added the MQTT code to the device you want to integrated into Home Assistant that publishes the discovery topics, right? If so, and they aren't appearing, then you need to check the broker to see if your topics and payloads are correct, using a utility like MQTT Explorer.
As far as the IP address, that isn't something that you enter on the Home Assistant side. You have to have the code on the device to publish the IP address to the state (e.g. /stat ) topic that was defined when the device was discovered. When the device publishes the IP address on the same state topic that Home Assistant is listening to, the IP address will be automatically updated in Home Assistant.
Great video well-done , I have a custom sensor with temperature and humidity and it has also current measurements is there a possibility to define a current sensor sending a float ? Would that still be a sensor type in homeassistant
Thanks. If I understand what you are asking, the current sensor would not be any different than temperature or humidity in terms of how you'd structure it. The payload really doesn't have a data structure (which is why you can pass things like a JSON array as well as single values. So passing current as a float (e.g. 26.4) isn't really any different than passing a temperature as a float (e.g. 71.3). On the Home Assistant side, and according to the official docs, a sensor can contain a datetime, integer, decimal, float or string.
So, yes, you should be able to create a current sensor in Home Assistant in the same manner that you do for temperature and humidity. If for some reason your device isn't able to create or format a value in the way you want for Home Assistant (or you need to do things like apply additional processing), you can take the MQTT sensor in Home Assistant and use that to create a templated sensor that applies this extra processing or formatting.
I hope that answers what you were asking!
A great tutorial! THANKS!
I have a MKR 1010Wifi I'd like to use for this(which uses the ESP32 chip). Do you think this would work for this unit as well?
You are welcome! I think as long as you can write the code to publish (and optionally subscribe) to the proper MQTT topics, it would work. The use of HA Discovery is pretty device and language agnostic. As long as the device or code language used can support MQTT, then it should be entirely possible to publish the discovery message for Home Assistant to automatically discover and integrate the device.
i'm new to all this home assistant and ESP32 stuff :) i'm loving the vids. currently trying to make my two 8x32 boards as a scoreboard on esp32 and wled... and it's hard :( how can i stop the text from scrolling? i just want static text :(
Unfortunately, that's a function of WLED... which isn't my firmware so I really don't have any control over its features. I don't know if there is a built-in way of having static, non-scrolling text. My clock / scoreboards / text displays are my own custom Arduino firmware so I am in complete control of that and have static score/text displays on my matrix. You probably need to post your question and/or request to the WLED Discord account or to their Github repo.
Sorry I can't be more help here... but since WLED isn't my firmware, I'm not really able to address its features or make any changes to them. But WLED is constantly being updated, so a feature that isn't there today might be there tomorrow.
Hiya. Thanks for replying!! :) i was just throwing it out there as a current project i'm messing with, BUT... i am still very much following your home automation stuff, and will likely end up using your methods. Thx for all your vids by the way :) @@ResinChemTech
Seems to be exactly what I was looking for.
I prefer my own devices, rather than use ESP-Home. ESP-Home debugging is so cumbersome.
I agree. ESPHome is great if you just want to integrate a couple of sensors, a light or some sort of entity like that. But good luck with trying to do more advanced logic like loops with delays, etc. For building a bit more complex devices, I think that using Arduino C++ (or Python, etc.) and then using MQTT to integrate into Home Assistant is the better option... at least for me.
Thanks for watching... and taking a few moments to leave a comment!
@@ResinChemTech Completely agree.
Have some devices with a display for user-interface and status messages.
Wouldn't know where to start with those in ESP-Home.
ESP-Home seems to me, just an extra abstraction layer over Arduino code, with all the HA specific stuff hidden from view.
No no.. thank *you* for all the time and effort you put into these videos.
Great but, how do we send the actual temperature value of the temperature device?
You simply use whatever function in your code that is needed to take a temperature reading and store that value in a char array. You then use this char array as the payload and publish a message to the topic you defined for the state_topic in the discovery statement:
curTemp = getTemperature();
sprintf(outTemp, "%3.1f", curTemp);
client.publish(state_topic, outTemp, true);
Of course the function to get the temperature will be dependent upon the library used and "state_topic" would be whatever topic you have established for the device's temperature state, such as "stat/mydevice/temperature". If you visit my repository ( github.com/Resinchem ), you can find many examples where I'm using MQTT. Most will have sections near the end of the source code with 'updateMQTTxxx' functions that will show publishing actual values from the device.
Thanks, for this video. You’ve cleared up a couple of things for me. I’m new to HA and I’m working on my first MQTT-HA integration. My MQTT device is a lamp that I retrofitted with an ESP-32 and some WS2812 led strips. I used to control this lamp with Blynk but now that they’ve changed to a subscription service I’m taking the opportunity to convert it to MQTT control via HA. I’ve got MQTT working and communicating between HA and my lamp. I can turn the lamp on and off via HA and I can see the status changes on HA. What I’d like to add next is the ability to send RGB colors and effect settings to my lamp from HA. So far I haven’t figured out how to add these controls to HA and then send the configuration to my lamp. Any assistance or pointers would be appreciated.
I'm assuming you developed your own code that is running on the lamp ESP32? I've done something similar with my LED clocks (also using an ESP and WS2812b LEDs).
In my case, I have three input number sliders in Home Assistant to set the red, green and blue values. I use these to pass a 3-value comma delimited payload for the RGB values (such as "255,0,128"). Then in the MQTT message processing on the device, I simply used the comma to split the payload into separate red, green and blue variable values that I could use to set the color of the LEDs. Alternatively, you could publish three separate message for R, G and B.
If you want to see an example, my matrix clock code is available in this repo: github.com/Resinchem/LED-Matrix-Clock_WS2812b If you look at the matrix-clock-main.ino file in the /arduino folder and locate the section of code labeled ***MQTT Message Processing***, you will see examples of how I'm taking the 3-value MQTT payload and splitting it out to separate R,G,B variables that are then used to set the RGB values of the LEDs.
I hope that gets you pointed in the right direction.
@@ResinChemTech Yes, for the most part it’s all hand-coded using the FastLED library. Thank you for your extensive reply. I’m slowly starting to understand the way HA does things. I think I have a grasp on how to proceed. Thanks for your help.
Where are you publishing that code? I'm brand new to this, so i don't understand at all.
The code for publishing MQTT discovery commands goes onto the device you want to integrate to Home Assistant. This could be an ESP device, a Raspberry Pi or really any device that runs a language that supports MQTT. In this video, I'm using Arduino/C++ code on an ESP8266 that publishes the MQTT discovery commands. Those MQTT statements are published to an MQTT broker and Home Assistant "'reads" those payloads and creates the devices and entities in Home Assistant.
If you are new to MQTT, you might want to start out by watching this video that describes MQTT and how it works in a little more detail, along with how it is used in Home Assistant: ruclips.net/video/Q0S0xOW35k8/видео.html
Guess my standing desk is becoming a device in Home Assistant! Thanks.
I'll for suer add this code to some of my projects. I had to look up your website to find out more about how you tell the device to turn discovery on and off, but perhaps you can include a quick link to how to handle the post call.
Well, using an HTTP post isn't necessarily the only (or best) way to handle turning discovery off/on. But it was a quick and simple way for me to show the results in this video.
I'll try to add something the Github gist file example when I get time, but the short of it is that you include the ESP libraries to make your device act as a web server (e.g. ESP8266WebServer library). You can then setup callbacks for various URLs (such as 'discovery_on' and discovery_off'). In those callbacks, I'm simply setting the value of the global 'auto_discovery' variable and then calling the ha_discovery function. The ha_discovery function then either publishes the JSON payload or an empty payload for each entity based on the variable setting.
I hope that at least provides some direction. I'll try to follow up to this comment if/when I add something to the gist file as an example.
OK... it didn't take me long, but I did update the gist file ( gist.github.com/Resinchem/ecd86dfb52bd699c79acfa80cd348d7b ) with the code I used to enable/disable discovery using an HTTP post. Note that like the rest of the sample code, it is incomplete... it doesn't include things like declaring the MQTT client, Wifi Client, HTTP server, etc. But it does include the basic logic on how I toggled discovery in this video.
This video has helped me out so much! For some reason, you're one of the very few sources who shows both the arduino side and the homeassistant/mqtt side. I don't know why, but other guides that I've found only show one part of the setup.. Thanks for giving us a complete package!
On that note, I am running into a weird issue (yes, I'm going to be that guy. I'm sorry, I just can't seem to find what's going wrong, and google can't seem to help me, so I'm desperate).
While adding a device with entities works, only entities that are of type sensor are picked up by homeassistant. Switches, lights, fans, humidifiers, none of them work. If I understand correctly, the only thing that really matters when it comes to determining the type of an entity is the part in the discovery message.
Any input is greatly appreciated!
Glad you found the video helpful! I try to approach all my videos from the aspect of explaining both the "how" as well as the "why", so that someone has enough info to duplicate my project or understand it well enough to adapt it to their own needs. That tends to make my videos longer than most, but I also felt that this approach was lacking when I was first learning.
As far as your issue, have you increased the default buffer size for the Arduino pubsubclient library? This was my initial problem (and as you saw in the video, only my sensor was picked up too, likely because a sensor requires the smallest payload). By default, the buffer is only 256 bytes. Any MQTT messages longer than that are simply dropped (silently, with no error) meaning they don't show up in Home Assistant.
Try increasing the buffer. If you are using the latest pubsubclient version (2.8.0 in my case), in the setup right after you defined the MQTT server:
client.setServer(MQTTSERVER, MQTTPORT);
Add the following line:
client.setBufferSize(512);
You might even need to make that 1024 if you have exceptionally long messages and if your device has the memory to support it. That fixed all my problems with my devices and entities not appearing. Note that if you have an older version and/or want to permanently increase the buffer size, you can edit the pubsubclient.h file and increase the MQTT_MAX_PACKET_SIZE from 256 to 512 (or 1024).
Let me know if increasing the buffer size resolves your issue. If not, then it is likely something wrong with how you are forming the serialized JSON payload.
@@ResinChemTech Thank you for the quick reply! I did try increasing the buffer size to 512, as well as 1024, but no dice. It's especially strange since it does get picked up when I say it's a sensor..
So this works:
String discoveryTopic = "homeassistant/sensor/" + deviceUniqueId + "_sensor_1/config";
But this doesn't:
String discoveryTopic = "homeassistant/switch/" + deviceUniqueId + "_sensor_1/config";
Googling this problem is frustratingly hard lol, thank you for taking the time to try and help me out 🤗
Edit: I just checked with MQTT Explorer, and that does pick up the message regardless of what type of entity I use.. So the Arduino side is probably fine. Time to look at whatever HomeAssistant/MQTT is doing! I'm quite new to those things, but luckily I just found this cool RUclips channel that seems to have a video or two on the topic 👀
Edit 2: When I go to MQTT in HomeAssistant and listen to topics, the messages also show up regardless of the entity type! So the MQTT addon in HA does receive the discovery messages, but for some reason only decides to integrate entities of type sensor.. very curious
You are using different object IDs, correct? In your above example, you have changed the type from sensor to switch but the object ID (deviceUniqueId + 'sensor_1') is the same for both examples. Each discover topic and entity ID must have a unique object Id in the discovery message and if a unique ID is supplied in the entity payload (recommended), it has to be unique from all others as well. It may have just been an example above, but remember that the object ID that appears between /switch/ (or /sensor/) and /config must be unique for each discovery topic, regardless of entity type. Otherwise, other discovery topics after the first one just updates the config of the first one.
@@ResinChemTech That's a good point! I updated the code to use different object ID's for the different entities, however, it does not seem to resolve the issue
@ResinChemTech Figured it out! I didn't realize the command_topic was a required value for Switches. Documentation is a wonderful thing. If only I had read it carefully.. 😬
Thanks for helping me out! Excited to see your future videos!
How do I do this with a single click button? Not with a switch right?
If it is a momentary button (non-latching), then you could create that as either a binary sensor or button entity. You can look up both types in the Home Assistant documentation, see the various properties and services, and decide which type of entity would be best for your particular situation.
Thankyou for a great tutorial. Could you plz share the full code please. I am new to iot world and really struggling to automatically add DHT sensors to homeassistant.
If you check the video description, you find links to both a written guide to this topic and a Github gist with a copy of all the pertinent code that I showed in this video.
That being said, if you are just wanted to add something like DHT sensors to Home Assistant, using something like ESPHome would be a much better (and easier) solution that writing your own code with MQTT discovery: esphome.io/components/sensor/dht.html
@ResinChemTech I am already using ESPHOME. I wanted to learn how to setup and enable autodiscovery of MQTT without using esphome. I took help from your code, I can see the MQTT topics being published correctly but the devices and sensors are not showing in Homeassistant MQTT integration. Is it possible to share my code with you so that you can have a look and guide me what am I doing wrong? Thank you
Sorry... my misunderstanding. If you are seeing the payloads published in your broker, but the device/entities are not showing in Home Assistant, I recommend trying the following:
Copy the payload you see in your broker (should be JSON formatted) and paste it into some sort of text editor. Be sure the format looks correct... opening/closing brackets match up, etc... and is what you expect it to be.
Next, assure that all required fields are present for whatever type of entity you are trying to create... sensor, switch, light, etc. Since you mentioned DHT sensors, I'm guessing you are trying to create two sensors. You need, at a minimum, a state_topic defined. You can always check the HA documentation for the type of MQTT entity you are creating to see what is required or optional: www.home-assistant.io/integrations/sensor.mqtt/
If your device is publishing under the proper discovery topic (/homeassistant/entity_type/uniqueID/config) but isn't showing up in Home Assistant, then it is most likely something wrong or missing in the payload...or you have disabled discovery in your MQTT integration. Looking at the actual published payload in a text editor can really help. And don't forget if you are using the Arduino pubsubclient library, it defaults to only 256 bytes so it could be truncating your payload if you didn't increase the buffer size. You should see this in the payload in the broker as well if it has been truncated.
I initially had the same problem when I first started out (and occasionally still do) and it is almost always due to a malformed payload or a required field missing from the payload.
Very well done, but you really glossed over how to send control messages to the DIY device. Yes, I've looked at both MQTT videos and I'm still struggling with getting something like a button to turn something on. The interaction of scripts, templates, and automation are harrowing and a real stumbling block for adopting Home Assistant fully.
I like your explanations and appreciate that you can't take forever making a video, but with the terse documentation that has very few examples in the HA documentation something more is needed to tie all this together in a newbie's mind. Maybe publish more on your blog about this from a simple dimmer device all the way through the control (including the card used) on a dashboard with one item on it.
While you mentioned that you watched both MQTT videos, did you also watch the third one that approaches integrating MQTT devices from the Home Assistant side (this is a Home Assistant 101 video instead of MQTT 101): ruclips.net/video/WYyPMHqMV-w/видео.html This gives examples of how to send commands from Home Assistant for both switches and lights (including brightness control). This video and related blog are about the best I can offer.
I understand your frustration. But when dealing with DIY projects... and even Home Assistant... a certain amount of technical skill and often a little bit of individual research is simply part of the process. I sure didn't learn everything about how to use MQTT or implement my own DIY projects in Home Assistant from any single video or article. It took a lot of watching, reading and often looking at example of other's code, and then simply trying and experimenting on my own to learn how everything fit together and functioned. It took even longer to learn and get comfortable with YAML and the Home Assistant configuration files. While it has come a long way, Home Assistant is simply not a plug-and-play solution and it will likely always require some level of tinkering and learning to get the most out of the system.
I'm happy to answer any specific questions or to try to help you with a particular issue. But no matter what sort of step-by-step guide I might make, it won't be a perfect fit for everyone... or there will be some specific need that I didn't cover for someone. I try to provide the best info that I can to introduce the concepts... with the understanding that more research may need to be done for a particular individual's project or knowledge level.
I took your advice and started over with the videos and played sections of them several times to get more familiar with the parts related to my problem with getting data going both ways. Then I coded up a complete configuration for a device and code to keep the various status items current. Of course, it didn't work, and after much close inspection, I managed to get the various topics and such all spelled correctly as well as coming up with a way to assign a unique device id that I could actually remember for more than 10 seconds as I scrolled down the page to put the next one in.
It all works now, but some things came up besides keeping close track and inspecting everything a dozen times to make sure you have that mqtt topic exactly correct in every single place it shows up. The biggest is that when experimenting with the unique device id for both entities and devices, you can inadvertently create ghost devices that you can't edit or delete. They hang around confusing things because the names are so similar to what you are actively dealing with and they just appear and disappear as you work. This is mentioned without resolution on the discussion board.
The other thing that I noted was that publishing is incredibly easy (discounting the paragraph above). I did not have to use the publish at all; just setting the state in the mqtt integration 'select' was handed automatically. This is nice because of the drop down list that can be used by a human. I haven't tested the others yet, that is coming soon. I also didn't have to use any templates yet as I step through the device; that is handled for me as well.
All in all though, the three videos taken as a unit, gave me enough information to test and correct mistakes through the process of a reasonably complex device.
Good job and good suggestion, THANK YOU!
I'm glad you got it working! Like most things, It will get easier the more you use it. Sometimes, for me, it helps to look over others' code and see how they did things. Along those lines, just today I released an update to the ESP Parking Assistant Github repo that implements MQTT Discovery (and the generation of an unique ID based on the MAC address of the ESP).
I also have a couple of other repositories/projects that make heavy use of MQTT with Home Assistant (although not auto-discovery). These repos have examples of the Home Assistant side plus the device (Arduino) side where data and commands are being sent back and forth. Probably the two biggest examples are the Arylic-Amp-MQTT and LED-Matrix-Clock_WS2812b repos.
Again, this may or may not be helpful to you. I just throw it out there since, for me, looking at code created by others is one of the ways I like to learn more about how something works or alternate ways of accomplishing a task. You can find all the mentioned repos here: github.com/Resinchem?tab=repositories
Thank you for the pointer and I will, again, follow your advice and go prowling for ideas. My take on the unique id is a bit different. I think about the next time I add a DIY idea and how I will remember the dog gone id for the last one, etc. I want to be able to see it and know what it is as well. There are ways to do it, but then I have to remember what that was as well. I do something like "theSnickersBarBought-June16" So I have something that can be read while troubleshooting with MQTT. I may regret it, but it's working while I learn. It's especially useful for keeping track of the master device with a bunch of entities.
👍
Is that an error at 8:09? The payload says "mqttem01a" (2x "t"), while the topic in the arduino code says "mqtttem01a" (3x "t").
Sharp eye! That is probably a typo on my part, but it would actually still work as written. The top payload is the unique id for the entity. While the Arduino publish statement just needs an unique 'object id' for the discovery statement. Yes... I usually use the same ID for both (so this _was_ a typo on my part with the extra 't'), but it isn't a requirement. The publish statement can be any unique string, so even though I didn't intentionally include the extra 't', it would actually still create the device/entity as expected.
Think of it like this: The top unique ID is the ID for the entity, while the publish statement includes a unique ID for creating or updating the entity via MQTT discovery. Since, as shown later in the video, I programmatically create a unique ID based on the device MAC address. It is easier to create a single base unique ID and adapt it for both the entity ID and the publish object ID. But it certainly isn't a requirement to have these two identifiers be the same value.
@@ResinChemTech Got it! Thanks for the explanation!