EVictory

Javi, As I stated in my post, I just posted to possibly help others be aware of issues while transitioning from jAC to eisy-ui. I am using the eisy-ui as much as possible now. With regards to the i3 device's new functionality (Night Mode, Hop Powerline on RF, Night Max On Level, Night LED Brightness, Night Ramp Rate, etc.), is there a place where these new features are documented? The reason I ask is I very am interested in a night mode for i3 devices. I have several rooms (master closet, utility room, mud room) where I have multiple (usually 2-3) insteon motion-sensors-IIs that turn on lights when they sense motion. I want the lights at 100% during the day but at night I want the lights at a much lower level such as 20-40% depending on the light bulbs. This way, walking into a room at night does not blind you. Currently, I have a program that changes the ON-LEVEL of the devices for night at 11PM and changes them back to 100% at sunrise. The new features sound like they may make achieving my goal much easier to program. -Emile

Over the last few days, I upgraded my EISY as I wanted to give the new eisy-ui a try. I ran Upgrade Packages to upgrade IoX from v6.0.4 to v6.1.2._10. Then I ran Upgrade Packages again to update the following: eisy-ui = from v1.4.4_2 to v1.4.5 PG3x = from v3.4.27 to v3.4.28 Background Info: I added an 'i3' suffix to the name of all my i3 devices to tell them apart from older insteon devices. After the upgrades, I was looking around the new eisy-ui and comparing it to the old java-based Admin Console (jAC). jAC Issue 1 - Programs with i3 in IF Statement Displays Unsupported Ruleset I noticed that the jAC can no longer handle 11 of my 13 Insteon i3 devices. I first noticed this in the jAC while looking at a program that triggers on an i3 paddle switch device's status. It appeared as follows. Notice the Unsupported Ruleset in the IF statement. I was unable to edit the IF condition in the jAC. My best guess is that this is because the jAC cannot correctly read these i3 devices statuses. The same program containing the i3 device showed the IF condition correctly when veing in EISY-UI. jAC Issue 2 - i3 Paddle Switch Not Displaying Status of Primary Node The next symptom I noticed is the primary node of the same i3 paddle switch does not display its status in the jAC at all. Below I recorded a video to demonstrate this. Watch as I move between standard devices and i3 primary devices. When selecting an i3 device, the jAC continues to display whatever it was displaying just before selecting the i3 device. This happened on 11 of the 13 i3 paddle switches I have. The flag (65) node seems to display correctly. jAC Cannot Display i3 Main.mp4 On 2 of the 13 Insteon i3 devices, the primary device displays correctly. Below is a video of 1 of the 2 switches that display correctly. I created a test program using the working i3 device below in the IF statement as in Issue-1 above. I did NOT see the Unsupported Ruleset message. jAC i3 Main Display Works.mp4 jAC Issue 3 - Cannot Add i3 Device to Scene as a Controller Because of the above issues, I initially thought that I had a problem with the particular i3 device being corrupted in EISY. Therefore using the jAC, I deleted the 'Front Lantern Lights i3' device from my EISY and then added it back in. However, when I attempted to add the i3 device to a scene, I found I could not switch from Responder to Controller. (When I clicked the Controller/Responder button in the scene Confirm Add dialog, nothing happened.) I could add the i3 device as a Responder but NOT as a controller. I eventually figured out how to add the i3 device to my scene by using the Add to Group right-click menu item. It would have been better if this was called Add to Scene though... Other Info: I do not currently have an issue as I managed to figure out how to add my i3 device back into the scene as a controller. I just thought that perhaps others may benefit from reading my post. Thinking that I was using an older version of the admin.jnlp, I found the little icon in the upper right corner of the eisy-ui page and used it to download the admin.jnlp file to run the jAC. It made no difference. I do not have any of the 4-button i3 switches. I cannot figure out what is different between the 2 devices that work vs. the 11 that do not. All of my i3 paddle switches show as being v.54 firmware. I discovered that the i3 devices have additional flags under the flags node. There are new flag items (Night Mode, Hop Powerline on RF, Night Max On Level, Night LED Brightness, Night Ramp Rate, etc.) I have never seen before. -Emile

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

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, 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

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

TriLife, Sorry for the delay, I have been down with a cold for the last two weeks. You provided the following: 01:42:04.420 MQT: tele/ClrTemp/SENSOR = {"Time":"2025-08-11T01:42:04","DS18B20":{"Id":"3C01B55696F0","Temperature":20.50},"TempUnit":"C"} What would be the correct YAML code to read the above sensor data? Thank you for your help. Emile Victory

TriLife, No, I have not made any further progress. Allow me to layout my situation. I do not have any of the sonoff devices your plugin was originally built to support. I am not a professional programmer. Over my carrier, I have dabbled in various programming and scripting languages at a novice level, starting with basic (50+ years ago) up to python in the last few years. SJenkins included a snip-it of python code but I am afraid it did not help me understand how the MQTT data should be formatted. I was able to modify a python script I found to read 1-wire temperature and humidity values from the OWFS (one wire file system) running on a raspberry pi and publish them to an MQTT broker (Info on OWFS). The screenshot below shows the results of my efforts. From what I have learned so far, I now believe my MQTT temperature / humidity data is not laid out as expected by your plugin. What would really help me understand what is needed is to see an MQTT Explorer screenshot of what the 'Temp' and 'TempHumid' types are expecting (with all relevant branches of the tree fully expanded). In connection with #4 above, I would like to see the corresponding YAML code that successfully reads the 'Temp' and 'TempHumid' types illustrated in #4 above. My plan is to attempt to modify my python script to publish the data in the way that matches what the plugin expects. At this time, all I am trying to do is read the temperature and humidity data and make it available to EISY for use in programs. I am not doing any writes back to the RPi. Thank you for any help you can offer. Emile Victory

SJenkins, Thanks for your help. Are you suggesting that I restructure the way I publish the 1-wire data to the MQTT broker so that it is similar to below? ▼ owfs timestamp = 2025-07-23 05:24:22 AM ▼ outside_ds18b20 temperature = 78.8125 humidity = 80.7931 ▼ garage_ds18b20 temperature = 86.4525 humidity = 60.4421 ▼ bporch_ds18b20 temperature = 77.9 In the above, I listed other sensor data such as humidity. The 1-wire board I use for most locations includes a DS18B20 (or DS18S20) temperature sensor and for humidity it uses a HIH4021-004 humidity sensor and a DS24382 1-wire device to send humidity over 1-wire. The author of NodeLink (io_guy) found the DS24382 also had a built-in temperature sensor. Later versions of his OWLink and NodeLink captured this second temperature as well. This is why my MQTT has two temperature devices listed for the some locations (Example: garage_18s20 and garage_combo). Is the following the correct way to setup the yaml to read the above? devices: - id: "Outside_ds18b20" sensor_id: "outside_ds18b20" type: "Temp" status_topic: "owfs/outside_ds18b20/temperature" cmd_topic: "owfs/outside_ds18b20/POWER" - id: "Outside_ds18b20" sensor_id: "outside_ds18b20" type: "TempHumid" status_topic: "owfs/outside_ds18b20/humidity" cmd_topic: "owfs/outside_ds18b20/POWER" TriLife mentioned that I may need to use 'sensor_topic' instead of 'status_topic'. I have not seen sensor_topic mentioned on the PG3 configuration page or the github repository. Is there a place that documents each 'type' and their corresponding requirements? I would think the different types would each have different requirements. Sincerely, Emile Victory

I had posted last week but later figured out how to get my old PG1 NodeLink node server working, so I cancelled my request for help. NodeLink provides 1-wire data and GenMon data to EISY. I am posting again because I would like to learn more about your MQTT plugin for applications other than sonoff devices. Since my earlier post, I have found out how to access files on the EISY using SFTP. I am now able to use 'devfile' to control the MQTT plugin. I would like to use the MQTT plugin to replace the old NodeLink as the latter creates a lot of traffic on EISY. I also have future RPi projects in mind where I can have an RPi post data to a MQTT broker. I need a MQTT plugin that can receive the MQTT data and make it available to EISY. I have an RPi running the OWFS (one-wire file system) for a series of 1-wire devices (humidity & temperature sensors and a counter). This RPi also runs the NodeLink (PG1 era) node server mentioned above. On this RPi, I added a python script to read the 1-wire values from the OWFS system and post them to my MQTT Broker as 'strings'. Below is a screen shot from MQTT Explorer showing my 1-wire sensors. My script only posts the string values representing the numeric data for each sensor. DEVFILE Example: For testing, I created a .yaml file containing the lines below for just one temperature sensor. devices: - id: "Outside_18B20" sensor_id: "outside-18b20" type: "Temp" status_topic: "owfs/temp/outside_18b20" cmd_topic: "owfs/temp/POWER" PG3: PG3 shows two nodes. The first is the MQTT and the second is the Outside_18B20. The EISY shows the Outside_18B20 device but it has a value of 0. Here are my questions: 1. Is my example yaml correct? If not, what do I have wrong? 2. I think the type of 'Temp' is probably incorrect as it appears to apply to a particular sonoff 18B20 temperature sensor and not my simple string in my MQTT broker. Does your MQTT plugin have a way to display my simple string data shown in MQTT Explorer above? 3. Another way to do this is for me to change my python script to publish additional data so as to mimic what the 'Temp' type is expecting. Is there an example of the MQTT data needed by the Temp type? 4. What are the requirements for the Analog and Raw types? 5. This is not a question but a comment. I continue to receive the following two notices in PG3. My MQTT broker runs on a RPi and does not use a username and password. So, those fields are blank in your MQTT plugin configuration page. Sincerely, Emile Victory

Please disregard my earlier help request on the MQTT node server. Yesterday I migrated my ISY-994i over to an EISY. I had previously used a PG1 level node server called NodeLink to communicate with my OWFS (OWLink) and my GenMon. I was under the impression that these would NOT work in EISY and PG3, which is why I was trying the MQTT node server. However to my surprise, I found that if I added the port (:8080) to the end of the ISY IP address, the old NodeLink node server started communicating with PG3 and EISY as an unmanaged plugin. Below is a screen shot of an Attic humidity and temperature sensor in EISY. I will keep your MQTT plugin (node server) in mind if I try out sonoff devices. Sincerely, Emile Victory

I am a long time user of ISY 99i and 994i but just upgraded to EISY with PG3 built-in. I have installed the MQTT node server on PG3. In my application, I just want to read values from a broker and will never be writing data back. I have a few questions. 1. Since this is on EISY PG3, I cannot access the EISY file system. Does this mean I cannot use the devfile option to store my configuration file on EISY? 2. I have an RPi running OWFS for a series of 1-wire devices (humidity & temperature sensors and a counter). I modified a MQTT python script to read the values from the OWFS system and post them to an MQTT Broker as strings. Below is a screen shot from MQTT Explorer showing my 1-wire sensors. My script only posts the string values representing the numeric data for each sensor. What Type should I use to display my string data? I have tried analog, temp, and raw but cannot get the values to appear in ISY. 3. What are the requirements for the ANALOG and RAW Types with regards to sensor_id, status_topic, and cmd_topic? 4. I have looked at https://github.com/Trilife/udi-mqtt-pg3x/blob/0.40/POLYGLOT_CONFIG.md and have read the Configuration Help in PG3. Is there some place I can additional information on how to configure each device? --- Below is an example of my devlist line. [{"id": "outside_18b20", "sensor_id": "outside_18b20", "type": "Temp", "status_topic": "tele/owfs/temp/outside_18b20", "cmd_topic": "cmnd/sensor/POWER"}] Sincerely, Emile Victory

I have figured this out. The problem was that I needed to add the Java Runtime Parameter -Xmx512m to my Java. I had done this in the past due to slow response but had not realized the setting is removed when you upgrade from one version of Java to the next. Now that this is figured out, I am upgrading to a faster micro SD card. I am going to try a SanDisk Industrial 16GB card at 50/80mb/s. The Industrial grade supposedly is tougher card. Thanks to all that offered help. This forum is awesome.

I am running malwarebytes AV and I disabled it and firewall on all attempts. This is standard practice anytime I upgrade firmware. Yes, I am using the ZIP file and not decompressing it. Yes, I always download the launcher, dashboard, and admin jnlp files along with the firmware. Yes, I tried clearing the java cache, all three boxes as always. I am on a Windows 10 Pro PC. Have used this PC many times to do upgrades in the past. I have had the replacement SD card for a few years which is why I used the FS command to format it during the rebuild. Right now, I suspect the SD card. I do have new Sandisk cards on order. They will arrive Tuesday I will try it with a brand new card. This one has me stumped.

The replacement SD card is a PNY 16GB SDHC device. I have had this card for a year or two. I have ordered two SanDisk Industrial 16GB cards but they will not arrive until Tuesday. I mention this in case this card is not fast enough.