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!

Edited November 11Nov 11 by jkmcfadden

Hi JK,

Not familiar with Droplet.

Could you post what MQTT message the device publishes when polled (using MQTT explorer or similar platform). Likely it publishes its own message on regular intervals.

Also please post the .yaml you are using to configure now.

Cheers.

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 Details

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

Edited November 12Nov 12 by jkmcfadden

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?

@jkmcfadden ,

You’ve done what you can here.

The mqtt plugin is not really set up as a general purpose mqtt interface, it has specific devices which are pointed to topics that device understands. It’s been rattling around in my brain that some kind of general purpose with fields like you are attempting would be fun to make.

So currently what we need to do is make another device specifically for this. On first glance I think you have given us all needed to do this. The question a while back from the other Droplet user didn’t have the data you have provided here to go to the next step. I’m doing this on my phone and am pretty full with meetings today but could likely whip something up in the next few days. The json parameter will be simpler as the plugin parses JSON already just fine. So you would call this the Droplet-AE50 , correct?

Also, I will need what the ranges or possible values of the fields are, like what is “not connected” “unconnected” or “low battery” “med battery”. I can collect and store unknown ones for now, but will need them eventually. The reason being is I need to parse them and turn them into an index which ISY uses another index to display. We don’t send the whole text to ISY with plugins.

@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

Edited Wednesday at 12:58 PM5 days by jkmcfadden

@jkmcfadden ,

Understand the desire for "one node to rule them all", and that is the easiest to implement. Thanks for the link to the API, that will help a lot.

So right now I would have these drivers & commands:
"""
UOMs:
2 = boolean
25 = index
35 = liter (L)
130 = Liters per hour (L/h)
Note: Flow rate from Droplet is in L/min, so we multiply by 60 to convert to L/h

Driver controls:
ST: Server Connectivity Status (index: 0=Connected, 1=Connecting, 2=Disconnected)
GV0: Signal Quality (index: 0=Initializing, 1=No Signal, 2=Weak Signal, 3=Strong Signal)
GV1: Health Status (boolean: 0=Offline, 1=Online) - MQTT connection via LWT
WVOL: Water Volume (liters) - point-to-point volume since last update
WATERF: Water Flow Rate (L/h)
"""

drivers = [
{"driver": "ST", "value": 2, "uom": 25, "name": "Server Status"},
{"driver": "GV0", "value": 1, "uom": 25, "name": "Signal Quality"},
{"driver": "GV1", "value": 0, "uom": 2, "name": "Health Status"},
{"driver": "WVOL", "value": 0, "uom": 35, "name": "Volume"},
{"driver": "WATERF", "value": 0, "uom": 130, "name": "Flow Rate"},
]

"""
Commands that this node can handle.
Should match the 'accepts' section of the nodedef file.
Below are receiving commands.
DON / DOF will be sending commands
"""

commands = {
"QUERY": query,
}

Edited Wednesday at 08:23 PM5 days by sjenkins
fixing as I go

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

@jkmcfadden ,

So above I updated the drivers & commands in the above post, found a "health" state which is different than the "server status". Health is connection to the MQTT, which server is connection to the Droplet cloud. By doing both of these it changes how you would set up the device in the yaml file a little bit (makes it simpler):

MQTT Configuration Example:
---------------------------

In your devices configuration, add a Droplet device with the base topic:

- id: "droplet_kitchen"
type: "droplet"
status_topic: "droplet-ABCD"
cmd_topic: "droplet-ABCD"

Where ABCD is your Droplet's 4-character identifier.

The NodeServer will automatically subscribe to:
- droplet-ABCD/state - JSON with server, signal, flow, volume data
- droplet-ABCD/health - Plain text "online" or "offline" status

NOTE:

I will push this to the non-production store later this evening after I get a chance to test it. It is called mqtt-poly, all lower case. You will have to put it in a different slot than the production version if you are using it for anything else; as this beta does not play well with the production version.

@TriLife and I are working on transferring ownership of this plugin.

@xKing wrote it originally, I took it on when I was using the devices a lot, then TriLife took the lead as his whole house used it. He is moving to different technology & so he asked me to take the lead again, which I am happy to do.

During all this I want to make sure we stay stable for those users who depend on it. That is very important. I have done a rewrite of the plugin, including adding this device. I have tested it but need the user group to test before it goes into production. You are testing this as a new device so I just want you to know it may not make it into production for a few weeks.

Edited Wednesday at 10:56 PM5 days by sjenkins

1 hour ago, sjenkins said:

@jkmcfadden ,

So above I updated the drivers & commands in the above post, found a "health" state which is different than the "server status". Health is connection to the MQTT, which server is connection to the Droplet cloud. By doing both of these it changes how you would set up the device in the yaml file a little bit (makes it simpler):

MQTT Configuration Example:
---------------------------

In your devices configuration, add a Droplet device with the base topic:

- id: droplet_kitchen
type: droplet
status_topic: droplet-ABCD

Where ABCD is your Droplet's 4-character identifier.

The NodeServer will automatically subscribe to:
- droplet-ABCD/state - JSON with server, signal, flow, volume data
- droplet-ABCD/health - Plain text "online" or "offline" status

NOTE:

I will push this to the non-production store later this evening after I get a chance to test it. It is called mqtt-poly, all lower case. You will have to put it in a different slot than the production version if you are using it for anything else; as this beta does not play well with the production version.

@TriLife and I are working on transferring ownership of this plugin.

@xKing wrote it originally, I took it on when I was using the devices a lot, then TriLife took the lead as his whole house used it. He is moving to different technology & so he asked me to take the lead again, which I am happy to do.

During all this I want to make sure we stay stable for those users who depend on it. That is very important. I have done a rewrite of the plugin, including adding this device. I have tested it but need the user group to test before it goes into production. You are testing this as a new device so I just want you to know it may not make it into production for a few weeks.

Thanks for taking the lead on this @sjenkins

ok @jkmcfadden ,

you can download from the non-production store mqtt-poly version 0.50.0 , its right near the bottom due to being all lower case.

Your yaml file will need to have something like this:

- id: "droplet_kitchen"
type: "droplet"
status_topic: "droplet-ABCD"
cmd_topic: "droplet-ABCD" # don't forget me, even though we don't use it !

I tested it out, without a device but pushing data through the MQTT & it populated on the ISY just fine.

Let me know what you see!

ps. @tmorse305 - I just searched back in this forum, if you are still interested you may want to give this a try.

Edited Thursday at 12:02 AM5 days by sjenkins

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

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

Edited Thursday at 11:32 AM4 days by jkmcfadden

Hi @jkmcfadden ,

You installed the regular mqtt plugin. Go to the non-production store and scroll right to the bottom and install mqtt-poly

It will be version 0.50.0

Edited Thursday at 11:42 AM4 days by sjenkins

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

Edited Thursday at 11:48 AM4 days by jkmcfadden

@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

@jkmcfadden ,

Do an ISY reboot for me.

Since eisy-ui came along this is sometimes required on many plugins

Actually if you log onto the local AC it will likely all be there.

The logs look healthy.

@sjenkins WooHoo!

@jkmcfadden ,

Ok!! Enjoy and test the crap out of it.

Make a few programs but remember when we goto production those programs will require touching up. Has to do with having different id number to the regular plugin.

Can’t think of any improvement path but let me know as you use it.

@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

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

@jkmcfadden ,

the id can be almost anything, droplet1, stephen, droplet2, it gets turned into the address of the node with a function to make sure its unique and short enough. The type must be "droplet". The name must be < 30 chars and also can be anything, kitchen, livingroom etc.

Let me know if you see behaviour different than this.

@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"?

@jkmcfadden ,

If you could download something like "MQTTexplorer" or equivalent for your operating system and see health status separate from the plugin, if it updates the offline status immediately when you unplug, or just when you plug back in. I am wondering if the update to the ISY is lagging. If it is logging directly to the mqtt immediately I can look into why the delay. If it is logging at the same time. when you plug in, I could pursue a parameter for last update. MQTT is a middle man which signals when a message comes in & you read it. No ability to get anything beyond that about the device (the health status parameter was supposed to tell if the device was talking to the mqtt). We can do a most recent message timestamp though.

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