jkmcfadden

@sjenkins So my second droplet arrived and has been successfully added to MQTT. Thank you for all you help! Once you have moved it into your production MQTT release, I'll re-add everything. But for now, everything looks good with beta. For anyone looking to add this device, here is what I did. 1) In the Droplet phone app -> Smart Home Integrations -> MQTT, configure: Host Name : the local IP address of my EISY Port Number: of my MQTT interface (I used 1884) User name and password of your EISY All other fields blank 2) I added my .yaml file name in the MQTT configuration entry 3) I added the below entries in my .yaml file (I have two droplets). The status and cmd topic entries are the unique value displayed in the phone app, type: must be "droplet", id: and name: are what I chose. devices: - id: "DropletAE50" name: "Droplet-AE50" type: "droplet" status_topic: "droplet-AE50" cmd_topic: "droplet-AE50" - id: "Droplet53B4" name: "Droplet-53B4" type: "droplet" status_topic: "droplet-53B4" cmd_topic: "droplet-53B4" Once I restart my MQTT to pick up the entries, this is what I see in the console: I created a test program to notify on flow and that worked as well. Kelly

@sjenkins Ends up I was just not patience enough. I am getting the offline status - it appears 3-4 minutes after I disconnect the device. I can live with that. So, what I am still wanting to test is adding the second Droplet. I ordered it late last week so hopefully I get it sometime this week so I can test that. I'll keep you posted. Thanks!

@sjenkins observation and question I have been playing around with the online/offline status. What I notice is that if I unplug the Droplet, the status messages just stop and the status in the console remains as the last status received which was online. The Droplet App on my phone does recognize that the device is offline. Then, when I plug it back in a few minutes later an "offline" message does appear followed immediately by the online status. It looks like the device sends a stored offline message. Sort of useful, but not really since it is very transient. Below I unplugged at 8:20 and plugged back in at 8:23 - and that is when the "offline" message appears followed immediately by the online message. I assume the App has some additional handling of the device to recognize that it has gone offline. And the limitations of MQTT are different. And I understand that. But I do think it would be useful to know when the device is not responding. So, I am wondering if it is possible to add another parameter to the device data to include the date/time of the most recent message. With that I could at least create a notification program if the last date/time exceeds a certain time limit. Is that doable? Or is there a way for the interface to recognize if a device is not "sending"?

@sjenkins My testing is going well. This is the yaml I am currently using. devices: - id: "Droplet" name: "Droplet-AE50" type: "droplet" status_topic: "droplet-AE50" cmd_topic: "droplet-AE50" Couple of questions: 1) I have a second droplet on order. How would the entry of the second one look? Sould all the values be different except the "type". For instance: devices: - id: "Droplet2" name: "Droplet-XX00" type: "droplet" status_topic: "droplet-XX00" cmd_topic: "droplet-XX00" I sort of remember I tried using the following in my original configuration and it did not work with anything except "Droplet" as the "id:" - sorry I don't have the exact log messages anymore, I just know I had to change the "id:" to "Droplet" to get it to work. I sort of remember a message about "DropletH" not found (or something like that). devices: - id: "DropletH" name: "Droplet-AE50" type: "droplet" status_topic: "droplet-AE50" cmd_topic: "droplet-AE50" 2) To then add the new "Droplet", once I update the yaml, do I just restart MQTT in the PolyGlot dashboard to get it to appear in the Console? Or is there a cleaner way? Again - thanks for your patience with me while I learn this new interface. Kelly

@sjenkins Just created and ran a test program to alert me when the flow exceeds a certain level. Works like a charm! It is exactly what I wanted to do with this device. Basically to get notified on flow when there should not be - AKA a "leak". Thanks for your patience with me, your hard work and quick turn-around. Kelly

@sjenkins WooHoo!

@sjenkins Some progress Here is my yaml entry: devices: - id: "Droplet" name: "Droplet-AE50" type: "droplet" status_topic: "droplet-AE50" cmd_topic: "droplet-AE50" But still not getting the fully configured entry in the admin console. I can see the health and state calls and replies. Log attached. Unfortunately, I have to go to my day job - so replies might be sporadic. To be honest, this is way more fun but I gotta pay the bills 😉 debug2.txt

@sjenkins I was hoping it was something stupid like that - the one I had said "beta" so I assumed it was correct. I am re-installing now. Thanks!

Hi @sjenkins and @TriLife I have installed the beta MQTT and updated to the settings listed above. FYI - I did delete the production version of MQTT since I have no other MQTT devices and I wanted to make sure I was using the correct version. Here is my yaml file: devices: - id: "DropletH" type: "droplet" status_topic: "droplet-AE50" cmd_topic: "droplet-AE50" But I am getting this message in the log file. 2025-11-13 06:03:08.663 Thread-3 (parameterHandler) udi_interface ERROR Controller:discover_nodes: Device type droplet is not yet supported I have attached the full log file that was created after my most recent "restart". Did I maybe miss a step? Would you like me to continue to use this thread - or use the "generic" one you created for the beta release? debug.log

@sjenkins Thanks for the quick turn-around. I am working on an on-call issue for my job tonight but will try to give this a try tomorrow. I'll keep you posted. Thanks!

@sjenkins That looks good to me (but then again, I don't have to write it 😁 ). Thanks!

@sjenkins that is wonderful news - thanks! I'll try to answer your questions. 1) The device type could just be "Droplet" - the -AE50 part is what my specific device on my Droplet App has been automatically named. Each device is given a unique (I assume) value. I only have the one device (so far) so I assume it would be unique in my account. 2) Here is the link to the Droplet MQTT interface docs - I think it gives you the return types and possible responses. 🌐 Smart Home API - Technical Specifications | Droplet Resource Center 3) My wishlist would be a single device entry for a Droplet that has the individual state values as sub-categories. Right now, my configuration has 4 separate device and each sends a state request for each "device". A single device that handles all of the state values would be cleaner. Again, just a wish. I leave the implementation details up to you. I am happy to help test with anything you come up with. Or if you need anything else, just let me know. Thanks again, Kelly

So I have made some progress. Using the following yaml file, I can now get all 4 "devices" to show up in the admin window. But all they do is to execute the same "state" command. devices: - id: "DropletFlow" name: "DropletFlow" type: "sensor" sensor_id: "Droplet-AE50" status_topic: "droplet-AE50/state" value_template: "{{ value_json.flow }}" cmd_topic: "droplet-AE50/cmd" - id: "DropletVolume" name: "DropletVolume" type: "sensor" sensor_id: "Droplet-AE50" status_topic: "droplet-AE50/state" value_template: "{{ value_json.volume }}" cmd_topic: "droplet-AE50/cmd" - id: "DropletSignal" name: "DropletSignal" type: "sensor" sensor_id: "Droplet-AE50" status_topic: "droplet-AE50/state" value_template: "{{ value_json.signal }}" cmd_topic: "droplet-AE50/cmd" - id: "DropletServer" name: "DropletServer" type: "sensor" sensor_id: "Droplet-AE50" status_topic: "droplet-AE50/state" value_template: "{{ value_json.server }}" cmd_topic: "droplet-AE50/cmd" Note - I have the "value_template" option in the yaml after some discussion with the Droplet support bot. It does not seem to hurt so I have left it for now. And the "Status" value in the admin console is just a phantom leftover of whatever I clicked on last. What my issue is (I think) is that the Droplet has just a single "state" command that returns all the values. Droplet does not have individual state requests for each value. status_topic: "droplet-AE50/state" Payload = {"server":"Connected","signal":"Strong Signal","volume":-23.06,"flow":0.00}, Topic = droplet-AE50/state So my question seems to be, how do I get the parsed value out of the state request to associate with the entity? The value_template appears to be how it is handled in the Home Assistant variation of this interface. Is there a different type I should be using?

Here is where I have gotten so far: My .yaml I used "sensor" as the type. I am not sure that is correct but nothing else looked any better. devices: - id: "DropletFlow" name: "DropletFlow" type: "sensor" status_topic: "droplet-AE50/state" value_template: "{{ value_json.flow }}" cmd_topic: "droplet-AE50/cmd" - id: "DropletVolume" name: "DropletVolume" type: "sensor" status_topic: "droplet-AE50/state" value_template: "{{ value_json.volume }}" cmd_topic: "droplet-AE50/cmd" - id: "DropletSignal" name: "DropletSignal" type: "sensor" status_topic: "droplet-AE50/state" value_template: "{{ value_json.signal }}" cmd_topic: "droplet-AE50/cmd" My MQTT config settings: I am getting good data back in the Polyglot MQTT log. All three expected values are present - signal, volume and flow. But this is all I see in the Admin window. Volume is not present and the values associated with the entities that do show up are not present. The Polyglot MQTT window says I have the 3 nodes so I should see flow, volume, and signal. Node DetailsNode Name 1 Address NodeDef Primary Node Hint Enabled Is Primary Delete DropletFlow dropletflow mqsens mqctrl 0x00000000 true false Name Driver UOM Value Variable CLIHUM 22 0 ${sys.node.n002_dropletflow.CLIHUM} CLITEMP 17 0 ${sys.node.n002_dropletflow.CLITEMP} GPV 17 0 ${sys.node.n002_dropletflow.GPV} GV0 78 0 ${sys.node.n002_dropletflow.GV0} GV1 100 0 ${sys.node.n002_dropletflow.GV1} GV2 100 0 ${sys.node.n002_dropletflow.GV2} GV3 100 0 ${sys.node.n002_dropletflow.GV3} GV4 100 0 ${sys.node.n002_dropletflow.GV4} LUMIN 36 0 ${sys.node.n002_dropletflow.LUMIN} ST 2 0 ${sys.node.n002_dropletflow.ST} Node Name 2 Address NodeDef Primary Node Hint Enabled Is Primary Delete DropletSignal dropletsignal mqsens mqctrl 0x00000000 true false Node Name 3 Address NodeDef Primary Node Hint Enabled Is Primary Delete DropletVolume dropletvolume mqsens mqctrl 0x00000000 true false Node Name 4 Address NodeDef Primary Node Hint Enabled Is Primary Delete MQTT mqctrl mqctrl mqctrl 0x00000000 true true I feel like I am very close. I am guessing (hoping) it's a yaml config issue, but I am not sure where. And talking with the DropLet AI support made things worse. They focus primarily on HomeAssitant integration. But the fact that HA works tells me that we should be able to get this working in EISY. If you have any suggestions, I am all ears :) Thanks!

Thanks! - I will give this a try - likely tomorrow.

Hi All, I am trying to configure the Droplet water flow device which supports the MQTT interface. I am struggling with the .YAML entry (I think). I have MGTT added in the Polyglot window and can see it in the EISY admin control window. Has anyone successfully configured this device? If so, could you provide the details - the Droplet app settings, the MQTT configuration settings and the /YAML file you used. I have been able to at least see the details of the device in the Polyglot log, but getting it to show up in the EISY interface is where I seem to be getting stuck. I have been back and forth with the Droplet support AI bot all afternoon, and it has been helpful, but I am still not getting exactly what I need. I think because it just does not understand the EISY. I have been an ISY/EISY user for many years, but this is my first foray into MQTT. There is another post about the Droplet device in this forum who was working on this same device a few months ago. I have asked my question in that post as well, but I am hoping that someone else might also have solved this issue. Thanks!

Hi @tmorse305 I ran across this post because I also am trying to integrate my Droplet into eISY. I have it sort of showing up as a device under MQTT, but only as a switch. I know it is my specific config parameters. Can you show me what you are using? I know I am missing something. Specifically: Your integration settings in the Droplet app? Your Node configuration settings in the Polyglot configuration screen? Your entry in the .yaml file? And anything else you found useful. Thanks!

Very common item to buy. I have several for my testing. Amazon.com: EP 2 Pack 3 ft 14/3C SJTW Appliance and Power Tool Cord, 14 Gauge 3 Prong Heavy Duty Replacement Power Supply Cord Cable, 110V 115V 120V AC Pigtail, 15A, 1875w : Tools & Home Improvement

I mix the two often, though over the years I have relegated the older switches to out of the way places like closets and the garage. Primarily since the ones I have are toggle and everything else is generally decora. Just make sure a dual band is somewhere in the vicinity and you should be OK. In the same box (like Guy mentioned) is ideal but probably anywhere nearby will help. I have one older switch, that consistently does not get the signal, that I plan to replace in an upcoming remodel. In the meantime, I have a dual band keypad in a tabletop encloser (that I use for testing and other things) and I plug it in near the "offending" switch. Problem solved. For Z-wave, I like the Zooz line. Lots of options for switches and keypads. I have a few dozen installed of different types. Only issue with Z-wave is that they will respond to, but not control, a scene. So programs are required. Good Luck!

While Insteon is my first choice, they just don't offer the variety that Z-wave does. I love the Zooz Z-wave motion detector switches - I use them in closets, pantry and my attic. A Z-wave fan controller for a fan that is 18 foot up and just not an easy install with the Insteon fanlinc. The Z-wave water detectors are much better as well. I use the UD Z-wave dongle. Z-wave does not always play well with scenes (it can respond, just not control) so that is the only real drawback.

I have been hesitant to upgrade given all the posts mentioning issues. So, this gives me hope. However, some recent posts mentioned issues with their Z-wave devices after their upgrade. And as I have a significant number of Z-wave devices, I continue to hold off. Do you have any Z-wave in your configuration?

I wonder if it is now automatically included in the normal backup with the newer version. It is annoying to have to remember to do it because it apparently becomes embedded in the normal backup anyway. UD Support should be able to answer.

You are saying that you don't have this? I am on 5.8.4. If not you might need to open a ticket unless someone else has an idea.

You might investigate using a program as the Alexa interface instead of the device directly. The program can set the actual on level. I use a ZooZ Z-wave dimmer switch in this manner and programmatically set the on dimming value when turned on. I like Z-wave devices, but you (like many of us) have discovered that there are some limitations where Eisy is concerned. Programs seem to be the best/only solution.

I currently use a program or programs to activate a scene. But occasionally, in my more complex scenes that also have multiple zwave devices as responders, I end up in what I can only describe as a feedback loop where the scene turns off and on repeatedly. That is why I am trying to find a less complex solution.