jkmcfadden

Most routers allow you to "reserve" an IP within the DHCP range for a specific MAC. That way it cannot get reused. It seems like more and more devices don't allow the setting of a fixed IP (newer Foscam cameras for instance). But by adding it to the reserved list (once it has grabbed an IP), you can be guaranteed it won't get usurped by another device. IP reservation is usually somewhere deep in your advanced settings.

@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!