BACKGROUND: I upgraded from an ISY994 to the EISY last summer. I had posted on 7/17/2025 and 7/22/2025 regarding using the MQTT plug-in to parse 1Wire sensor data from my NodeLink server running on a Raspberry Pi over to the EISY. I dropped the project when I figured out how to get the NodeLink working directly in the EISY and PG3. However, the NodeLink communications seems to cause a heavy burden on the EISY -- I get a lot of 'System Busy' pop-ups. This eventually causes the EISY to not be able to read device REC files, which caused me to have to delete several devices from EISY, factory reset them, and load them back into EISY.

REFERENCES:
NodeLink: https://forum.universal-devices.com/forum/113-nodelink/
7/17/2025 Post: https://forum.universal-devices.com/topic/45372-questions-using-mqtt-on-eisy/
7/22/2025 Post: https://forum.universal-devices.com/topic/45389-using-mqtt-plugin-for-non-sonoff/
1wire2mqtt: https://github.com/unlo/1wire2mqtt
MQTT Explorer: https://mqtt-explorer.com/

REVISITING MQTT: I have decided NodeLink is causing more problems than it is worth. I have stopped NodeLink from talking with my EISY which has stopped the 'System Busy' pop-ups. Hence I am revisiting using the MQTT plug-in. I still have NodeLink running so that it's underlying OWFS (OneWire File System) is available. I am using a modified OWFS-to-MQTT python program (1wire2mqtt) to control how the 1-wire data is presented to the EISY MQTT broker. My strategy is to use the 1wire2mqtt program to present the data to the MQTT plugin in a format the plug-in can already handle. Below is a snapshot of the last entry in my 7/22/2025 post. I had asked TriLife for a sample of what a Sonoff/Tasmota Temperature sensor publishes to mqtt. Then I asked him what the Devfile would look like to access that data.

From the information above, I was able to modify the 1wire2mqtt python program to publish my 1wire data in a compatible format. Below is the results shown with MQTT Explorer.

Next, I setup my MQTT plug-in's devfile to access the MQTT data. Below is the contents of my devfile.yaml file.

I have had some success. Two of the eight devices are working in the MQTT plug-in. Below are snapshots from the PG3 MQTT nodes screen.

PROBLEMS:
1. As you can see, two of the DS18B20 sensors are working (highlighted in yellow). One of these is a DS18B20 device and the other is the older DS18S20 device. (The DS18B20 has selectable 9 to 12-bit resolution where the DS18S20 is 9-bits only.) I modified my 1wire2mqtt python program to present both as DS18B20 devices. However, I cannot figure out why the other five DS18B20 type sensors are not working. I have examined the MQTT Explore output closely and cannot figure out what is wrong. Can you help?

2. The second problem is I am trying to access both temperature and humidity data from a DS2438 1wire device. I have manipulated the 1wire2mqtt python program to present these as AM2301 devices and am using the TempHumid type in my devfile.yaml. I have no idea if the MQTT data is in the expected format for the plug-in. If you could supply me with an example of what the MQTT data looks like for the TempHumid type like TriLife did for the Temp type, this would be a tremendous help?

I am running v0.40.2 of the plug-in.

Thanks,
Emile Victory

Edited August 11Aug 11 by EVictory

Hi @EVictory ,

Appreciate the in depth data on your questions:

1. At first glance I do not see anything wrong, but there may be more in the logs. You may try deleting the nodes that are not working, so they can be remade. If you have been iteratively working on this, the node which was made in a previous attempt may be blocking the making of a new one. Two ways to do this, either stop the node then hit the 'x' on the right side in the node listing you attached above, or go nuclear and delete the whole node instance (make sure you have your yaml file safe). When you start the plugin again it will remake the nodes. If this does not work then I need the logs to go further.

2. As you mentioned, not the first time this 'What is the format expected?' question. I am adding a section to the README.md and a link in the POLYGLOT_CONFIG.md so people can get to it but it does not pollute the config help. For your specific question:

   {
     "AM2301": {
       "Temperature": 72.5,
       "Humidity": 55.0,
       "DewPoint": 54.3
     }
   }
   
   

Hope this helps, let us know here how the project goes, your translation program is neat. When you get it working and know what you want for translation it could be added to this plugin as a feature request. Just need the raw data you are getting from the device and the desired conclusion on the node side.

Edited August 13Aug 13 by sjenkins

SJenkins,

I have had success on one of my two problems areas. The reason all but two of the Temp/DS18B20 type sensors did not work came down to capitalization used in the YAML file.

This does NOT work:
- id: "CE3F82040000"
name: "BPorch_18B20"
type: "Temp"
sensor_id: "DS18B20-3"
status_topic: "tele/28.CE3F82040000/SENSOR"
cmd_topic: "cmnd/28.CE3F82040000/"

However, this does work:
- id: "ce3f82040000"
name: "BPorch_18B20"
type: "Temp"
sensor_id: "DS18B20-3"
status_topic: "tele/28.ce3f82040000/SENSOR"
cmd_topic: "cmnd/28.ce3f82040000/"

I had the hex letters in the 1wire IDs capitalized when they needed to be lowercase. Now, all seven of my DS18B20 and DS18S20 sensors are reporting with the MQTT plug-in.

PROBLEM #2: My second problem has to do with reading temperature and humidity from my DS2438 1wire sensors. The 1Wire PC board I am using incorporates a DS2438 1wire chip and a HIH-4021-004 humidity sensor for reading humidity. It also has a DS18S20 1wire temperature sensor (which I now can read correctly). Several years after I built and installed the PC boards around my house, the author of NodeLink figured out that you can also read temperature from the DS2438. This means that each PC board has two temperature sensors (the DS18S20 and the DS2438). I would like to also read in the temperature and humidity from the DS2438 chip into EISY, mainly to get the humidity data.

My approach for the DS2438 sensor is the same as with the DS18x20 sensors. That is, I will modify the 1wire2mqtt python program to report DS2438 data in the exact same format that the MQTT plug-in expects for the TempHumid / AM2301 device. My issue is that I am not sure how to format the MQTT data for the TempHumid sensor. The screenshot below is what TriLife had sent me last year for the Temp/DS18B20 MQTT data.

The above helped me to arrange the data to be published to the MQTT broker. (If you look through my posts from last year, you will see I started out with the 1wire data being published in a completely different arrangement.) For example, it looked like the MQTT plug-in was expecting the TempUnit value of C or F for each sensor. Well, that was not readily available as output in the OWFS system as this is set globally in OWFS and is not available for each sensor. To work around this, I just added the fixed string of "TempUnit":"F" to the end of each sensor published. That is, the F for fahrenheit is hard coded. TriLife's information also gave me a clue that I needed to nest everything under SENSOR in {} brackets and list the ID and temperature within {} brackets (i.e., the nesting).

Based on the JSON sample you sent in your reply, I took a guess at the correct MQTT format. Below is an MQTT dump (using MQTT Explorer) of what I have tried today. The yellow highlighted lines are the DS2438 1wire sensors.
NOTE: I first tried a version where I had the Id info like for the DS18B20 sensors, but it did not work either.

Within my 1wire2mqtt python program, I replace the DS2438 device type with AM2301. Also, the DS2438 as used with NodeLink does not support reporting dewpoint. However, since dewpoint can be calculated if you have temperature and humidity, I added code to the 1wire2mqtt python script to calculate the dewpoint and report it for each sensor. The above MQTT format does NOT work for the TempHumid type in the MQTT plug-in.

Is there anyway to get a sample of the MQTT data output for the TempHumid/AM2301 sensor? Ideally, this will be a screenshot like above using the (free) MQTT Explorer program or output like what TriLife sent me last year. I need to see exactly what the published data looks like for the TempHumid type. I could have the nesting all wrong, could be missing required info like the TempUnit:F info needed for the Temp type, etc.

Note: I find the free MQTT Explorer program very helpful in trouble shooting MQTT issues. When you launch the program, you get a screen similar to below. You select the MQTT broker on the left, provide the IP address, port, and login credentials then click on CONNECT. You then are presented with a browser like window shown above. The data changes as new data arrives in the broker.

Thank You,
Emile Victory

VCS-Humidity & Temperature Board 2.pdf

Edited August 14Aug 14 by EVictory

@EVictory ,

Glad your solution for #1 worked. I also use MQTT Explorer and would call it invaluable.
On your #2 issue, on first blush it looks like you have an extra double quote and comma before the "Temperature" label. (In the future could you paste the raw MQTT output from an individual output in addition to the history. It has the raw JSON. The picture of the history list is useful but makes it much harder to get the actual text.)

SJenkins,
The extra double quote and comma was keeping the TempHumid type from working. Now all of my temperature and humidity boards are being received by the MQTT plug-in! Thanks for your help.

I would be more than happy to share anything about my setup. To that end, attached below is a write-up I did back in 2020. (Before retiring, one of my IT related jobs was writing technical documentation.) I converted it to PDF to upload here. Please note that some of the hyperlinks to vendor sites within the PDF no longer work because the company(s) are no longer in business.

Raspberry Pi 2 and RPI3 V2 Board - 2020, 11-02B.pdf

I first implemented this 1-wire system back around 2013. If I was starting over today, I do not know if I would choose 1-wire. At the time, there were not a whole lot of options for temperature and humidity sensors that I could tie into ISY. One goal I wanted back then (and still desire today) is to not have battery-powered devices. I did that years ago with devices and got real tired replacing batteries all the time. That being said, there are so many more options for sensors today.

I mentioned NodeLink in my earlier posts. Technically, I do not need NodeLink anymore. The minimum I would need are:

• Same Raspberry Pi hardware with RPI3v2 Hat

• OWFS (1-Wire File System) installed on RPi. (NodeLink used OWFS under the hood.)

• My modified 1wire2mqtt python program.

I still have some work to do with the modified 1wire2mqtt program to clean it up. I am afraid my python coding is at a pretty low-level. You mentioned being able to see the JSON in MQTT Explorer. Unfortunately, I am not using JSON to publish the MQTT. I am building a string in a variable called ejv_data. Then, I just publish the string variable. All of the commented-out print lines were used to troubleshoot the changes as I went. You can see why the extra double quote and comma was easy to miss. To get double quotes in the string at all, I had to use single quotes to delineate the ends of the string, which then allowed me to embed double quotes.

As you can see above (commented-out lines), the original 1wire2mqtt program used JSON but I do not understand how it works. Rather than try to figure out how to use the JSON method, I choose the brute force method because I was trying to keep the number of things I did not understand to a minimum.

Thank you for your help.
- Emile Victory

SJenkins,

Below I have attached my modified 1wire2mqtt.py python program and 1wire2mqtt.cfg files. I have changed my IP addresses to 0.0.0.0.

1wire2mqtt.cfg1wire2mqtt.py

Thank you for your help.

-Emile