sjenkins

Hey there, just saw this thread, I am the curator of the Virtual plugin. The virtual devices do send control or switched signals as well as status & work in the AC or UD Mobile. Thus they will fire scenes or programs. Saying that some of the advice higher up does apply & is the way to do it without Virtual. Think of this plugin as a "macro", doesn't do much impossible without it, just shortcuts things. For this use case I might use a virtualSwitch and have the Fastoff program set it, while a program with the other switches turn it off. In the AC or UD you could change the virtuslSwitch directly. Now your other programs could use the "flag". You could mix and match with scenes and virtualSwitches as well, but as mentioned fastOFF is easy to pick-up in a program and more subtle in a scene. FastOFF immediately turns off the scene which just off uses the ramp ; I have used this feature to make a delayOFF happen, but in the end I created a virtualDevice to do this. hope this helps.

@Guy Lavoie , You have mentioned this before & didn't understand so I think my answer was incorrect. I am able to trigger scenes with a virtual switch both from UD Mobile and the the Admin Console. I am also able to trigger a program using a virtual switch from the AC and have programs turn a light ON or OFF using control. I just verified both again to make sure there were no changes. For example: test dimmer ON - [ID 0068][Parent 01B1] If 'Virtual Device Controller20 / Test Dimmer' is switched On Then Set 'Living / Living Fireplace Lt' On Seeking to understand here ; can you explain more what you are trying to & what isn't working?

Two fixes, one which only effects ratgdo garage node hopefully preventing hanging ; two fixing Toggle and onDelay so they send only DON and DOF. Feel free to test and let me know if everything is acting as expected. VERSION = "3.1.26" """ 3.1.26 DONE add timeout to ratgdo requests and sse client to prevent hanging DONE chg DFOF to DOF for Toggle & onDelay 3.1.25 DONE add onOnly device DONE update generic project files DONE Controller comments, refactor checkParams DONE change hints for temperature devices DONE testing added 3.1.24 DONE configuration based optional overide initial default 3.1.23 DONE add onDelay, offDelay, toggle switch, update documentation DONE magic number scrub 3.1.22 DONE generic/dimmer static/dynamic behaviour

@tmorse305 , Looks like the team has you covered. Anywhere under your home directory. I made a dir for all my local test plugins which I keep these, but anywhere there is good. Thanks @jkmcfadden & @maxnorth !!

@jkmcfadden , Good news! Small item from your notes above: The EISY MQTT server at 1884 will work without an id or password, admin / admin is fine or anything else. Unless you actively change it yourself on the EISY from ssh. The server at 1883 is the one used by the EISY for conversations with the POLY ; it is behind security for obvious reasons. I have not received any feedback from the crowd on the beta in the last week or so. Will give it a bit & push to production.

@jkmcfadden, Likely the droplet server has a timeout of that length which triggers it to send the health signal. Let me know how the adding of the next Droplet goes!

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

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

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

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

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

For the brave ones out there I have spent a bit of time to do a NON-breaking re-write. Mostly for the sake of making it easier to maintain, add devices, add testing files, and improve self documentation of the program. The devices have been made more standardised in their writing ; no changes to their behaviour . There are three new features, one I stole from another plugin, number of nodes in the controller node, just a sanity check. The second, is the ability to have a default status and or control prefix. Not sure who was asking for it, but I found the request in the logs. I updated the config instructions to include some explanation: - status_prefix: "tele/Wemos32" # any status_topic starting with ~ is replaced - cmd_prefix: "cmnd/Wemos32/power" # any cmd_topic starting with ~ is replaced devices: - id: "WemosA1" name: "Wemos A1" type: "analog" sensor_id: "A1" status_topic: "~/SENSOR" cmd_topic: "~/" Finally, the third is a new device, "droplet" which was requested to handle the Droplet water monitoring device, see the config for instructions. Again, all this is meant to be non-breaking but we won't know until more people than me test it. Download and put this non-production version in a DIFFERENT slot than your production, you can point it to the same YAML config file you use or a new test one. Please do some testing and put some feedback here, it won't go into production until we get a few thumbs up as there have been too many changes to risk peoples automation. Thanks! =========== 0.50.0 DONE refactor Controller/Nodes for Pythonic & commenting DONE add user defined default status_prefix & cmd_prefix DONE add numofnodes DONE add MQDroplet device

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.

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

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