New 1-wire topic using aliases (MQTT) #590
Conversation
|
I deeply apologize for committing the main.yml file. I have restored its previous value, but please remove any requests related to main.yml. |
Currently, 1-wire is read synchronously, which means the program is paused for up to 750ms. During this pause, a yield is called, ensuring that WiFi works correctly. However, other issues may arise, such as UART read buffer overflow.
I have modified the code so that everything operates asynchronously.
The previous solution to this problem contained a bug:
if ((DALLASASYNC) && ((unsigned long)(millis() - dallasTimer) > ((1000 * dallasTimerWait) - 1000)) ) {
DS18B20.requestTemperatures(); // get temperatures for next run 1 second before getting the temperatures (async)
}
The author assumed the code would execute only once, while in reality, it was executed multiple times per second before the reading.
Asynchronous 1-wire reading
|
Idea is great but the implementation of the idea isn't what I would have done. Creating another main tree under the heatpump topic doesn't look right. But I can't think of something better right now. But maybe I need to finally add auto-detect for homeassistant and follow that schematic for mqtt and let go of the old style. For now keep this PR but don't commit yet. |
|
That's exactly how I wrote it. It works both the old way and the new way. It's backward compatible. |
|
@IgorYbema - have you analyzed the modified program code? The first level is the name contained in the variable "mqtt_topic_base". It must be derived from there to enable handling multiple heat pumps. The second level is "1wire_alias", which I created based on "1wire". The subsequent levels are defined by the user's alias.
|
|
Yes I did check and ofcourse very thankful for your addition. But for now I just dislike adding the same value to mqtt. |
|
Duplication is a common solution when maintaining compatibility is necessary. In many cases, we have basic functions and their "_ex" counterparts, which are simply extensions. Fortunately, the extension I implemented expands the program code only minimally, so there should be no issues maintaining the code in the future. Currently, the value is presented in the tree by the sensor's identifier. There is no straightforward way to read this value using an alias. If you're concerned about the duplicate temperature publication, it could be made configurable in the general settings. However, in my opinion, that would unnecessarily complicate things—it would require explaining what such an option is for, and even then, someone configuring HeishaMon for the first time likely wouldn't understand it. Another approach could involve adding an additional parameter when configuring an alias, such as "Publish as an MQTT topic." Alternatively, encoded aliases like MQTT_[alias] could be created, where the MQTT_ prefix would be stripped, and the resulting alias would define an MQTT topic. However, I think this would be over-engineering the solution. In my opinion, the current approach is effective. It sends data about the sensor immediately upon physical connection, requiring no additional configuration. The alias solution is intended for users who want "something more" and understand the problem. |
Adding a new MQTT topic: "1wire_alias". This topic allows publishing temperatures from "1-wire" sensors in the following format:
mqtt_topic_base/1wire_alias/[alias]
where [alias] is the alias assigned to the 1-wire sensor in HeishaMon.
This solution eliminates the issue of replacing a faulty sensor. After replacing the sensor, simply assign the same alias to the new one.