sjenkins

@Panda88, Would be great if you could "refresh" the beta and kick out the time period until you are more ready to either merge or not-merge the two. I was so excited about local that I DID move my programs over to the beta. No worries I will move to whatever solution you come up with, but would be nice to hang out with the current set-up until then. Thanks again for the efforts, this plugin is now part of the plumbing of my home automation ; literally & figuratively.

As I mentioned to @Diesel not sure why this has not been added before now other than because we all got used to using them as responders. I tested out the switches as control in programs & scenes. Try out the generic, dimmers, garage. I will leave this in beta for a bit to make sure there are not any unintended consequences. I know many of you have this plugin integral to your home automation, please throw me some feedback. 3.1.14 \ DONE commands for switches, generic, dimmer, garage 3.1.13 \ DONE prevent direct poll from re-running \ DONE add notice if comms check fails \ DONE clean-up & debug 3.1.12 \ DONE rewrite sse events collection

@Diesel , sorry for the slow return, been a busy summer. Although the programming doesn't quite work as you have above, this is a feature which should have been added long ago. Not really sure why, I guess we all got used to using it the way we did, as a responder in a scene. Anyway, I have put it up in beta on the non-production store in v3.1.14 I will give people a while to play with it to make sure there are not any unintended consequences.

hi @tmorse305, looks like good work here. Give me some time ; I've got a couple projects backed up & unfortunately I still work. I would look to make a new node in the mqtt plugin framework will start simple & add info & bells & whistles in layers will need you in the test loop, sending me logs as we go. likely will have some clarifying questions too; a snapshot pic of your mqtt explorer screen with some of the above fields populated will colour between some lines I'll update here as I have something ; before then feel free to ping if I go dark too long for a pulse check.

thanks @Guy Lavoie , @DonM there are three different ways to config virtual devices: 1. standard: the way guy shows above, which is the most simple. put a number for the key and type of device, like switch in value 2. json: a json string which describes the devices 3. yaml: a file which describes the devices hit the button for configuration and scroll down, it should describe all of them. (screen shot below) once you do that you should NOT need to do anything in the admin console to add the devices, they will be added automatically

Got around to checking @TJF1960 , can confirm that it does just fine work assuming your router keeps your local network up and going. To explain when I pulled the cable from the modem all was fine ; when I pulled the ethernet from the back to modem (to my router) my router took down the majority of my local network. One to add to my TODO list as I take one off.

I keep meaning to but haven't found the window when I won't get yelled at by the family. I'm off this week so its on the TODO list. I will try to validate @Panda88 's test. I will say that I have been running completely on the Beta plugin with no issues for that last number of weeks. Moved all my programs over will all good.

will need to know for each of those what the number is and the unit. for online status, what are the possibilities: eg, (0,1,99) or (ONLINE, OFFLINE, UNKNOWN) or (online, disconnected, none) need to know these exactly.

@tmorse305 we would need to add a device which creates a node for your flow device. Is flow the only data sent? also, no control? what are the units? knowing the above its not a huge deal to make another node. let me know.

Should only effect VirtualGarage

@evilpete your other option is to add a device to the mqtt plugin & do a pull request. Take a look at the github, the code is pretty simple. Less work than a whole plugin. https://github.com/Trilife/udi-mqtt-pg3x

A quick Python example from my Copilot friend: Here's a Python function that takes a JSON array and sends each item to a separate MQTT topic using the paho-mqtt library: import json import paho.mqtt.client as mqtt def send_json_array_to_mqtt_topics(json_array, topic_prefix, mqtt_host='localhost', mqtt_port=1883): """ Sends each item in a JSON array to a separate MQTT topic. Parameters: - json_array (list): A list of JSON-serializable items. - topic_prefix (str): Prefix for MQTT topics (e.g., 'sensor/data'). - mqtt_host (str): MQTT broker host. - mqtt_port (int): MQTT broker port. """ client = mqtt.Client() client.connect(mqtt_host, mqtt_port, 60) for i, item in enumerate(json_array): topic = f"{topic_prefix}/{i}" payload = json.dumps(item) client.publish(topic, payload) print(f"Published to {topic}: {payload}") client.disconnect() Example usage: data = [{"temp": 22.5}, {"temp": 23.0}, {"temp": 21.8}] send_json_array_to_mqtt_topics(data, "sensors/temperature") This will publish each dictionary in the array to a topic like: - sensors/temperature/0 - sensors/temperature/1 - sensors/temperature/2

@tmorse305 , have you tried changing your topic in your set-up from: droplet-BA7C/state to: droplet-BA7C/state/flow

@evilpete , your issue is these devices do not read a JSON string from MQTT but rather individual variables. so your MQTT should look more like this..... (sorry this isn't a raw example but the form factory holds). You will need to write your JSON string using each variable. Does not matter if your device is Tasmota or not ; in fact when I started using, then modifying this plugin I didn't know what Tasmota was & still have never used one. What matters is the form it hits the MQTT ; that's the beauty of MQTT ! Not sure if you are sending with Python or with C, C# but works similar in both, the topic in the below case is /sej/awning/status/hb while the message is ON. You are sending the whole JSON as one message in a topic. hope that helps

Sorry for churn but I found a long standing bug which was crashing the plugin if the connection to the gateway was locked-up and then reset. VERSION = '1.12.7' """ 1.12.7 DEBUG crash when connection reset by peer ; fix data DONE remove separate open / close behaviour for G2/G3 1.12.6 DONE reverse open / close behaviour for G3 shades 1.12.5 DONE re-write SSE for G3 DONE fix motion if motion-stop missed DONE battery low event added for G3 DONE force updates to server (helps with new eisy-ui) DONE doc clean-up DONE string clean-up DONE improve logging DONE bumped requests and urllib3 versions

Thanks so much @Guy Lavoie ! I agree, that’s why I wanted to take it over so it had a long life. We have a great little ecosystem with UD. I still think there are some rare reboots that I am always somewhere not local to chase them down. If anyone has an event like that please send me logs and description. Also, I may be the only one using virtualGarage. I wrote it at the same time as the Ratgdo plugin was written for me. If there are other users, I’m interested to know. There is no detailed reports beyond download numbers.

rewrite of the sse events routines for cleanliness and robustness. I will move to production if no noise in next few days

@bmercier , Just wanted to let you know that there is still a difference in behaviour between the local AC and the remote AC / Eisy-UI. Using my hunterDouglas plugin as an example as I know the plumbing: reportDrivers() does not update the detail fields in the remote AC / Eisy-UI works fine in the local AC ISY programs get the data just fine, so this is a display issue. Examples below: local AC: remote AC: remote Eisy-UI: Note: The field that did update are ones which have changed since the Eisy-UI was running. The remote AC are blank as I had to restart it to switch from local to remote. When I press query it runs the reportDrivers() function. This updates the local(if needed), but not the other two remote versions. Again the programs run fine.

Both 1.12.5 & 1.12.6 moved to production, thanks to @glarsen for the last minute change is the reversal of Open / Close for G3. I did not touch G2 and need some G2 users to validate the Open / Close function for them as I do not have any. The rest of the changes made in 1.12.5 were mostly not user facing. Libraries and documentation changes. G3 changes: I did add an event for battery low but that would have been triggered by the polling info too. The motion stop event seems to not always come across the sse, so I added a timeout clearing at the next polling event. The biggest effort was a rewrite of the sse event engine ; threads necessitate this being non-standard but the way I had written it was absolutely awful to look at. Significant simplification & clean-up. I am hoping some of the mystery crashes will go away with this. I have changed my polling to every 120s to lessen the traffic. Did not change the default though ; you may want to play with it. YMMV. Let me know what you see! VERSION = '1.12.6' """ 1.12.6 DONE reverse open / close behaviour for G3 shades 1.12.5 DONE re-write SSE for G3 DONE fix motion if motion-stop missed DONE battery low event added for G3 DONE force updates to server (helps with new eisy-ui) DONE doc clean-up DONE string clean-up DONE improve logging DONE bumped requests and urllib3 versions

@glarsen so you are right! I can say that I have open and close reversed for G3 ; open should be 100, close 0 position. TODO: can someone who has G2 can check if Open / Close works as expected? When I developed it, the G2-API has open as 0 and close as 100 ; the opposite of G3. I only have G3 blinds. Not sure how I messed this up or how you are the first to notice as these lines were committed in Jan-2024 ! @glarsen you win the observant user award ! The rest of us should hang our heads

Thanks for the heads up. Haven’t changed anything recently & I mostly use Activate. Maybe I missed something in my test procedure. You are the first person to notice if so. I’ll check it out and get back to you.

I forget to mention my devices working on the local-hub: leak sensors power failure temp indoor temp/humidity with display outdoor temp garage control & sensor water valve control

Got it. My only request then is to have retention of the expand/contract from session to session, otherwise this is a royal PITA. Oh and my ONLY other request is to allow us to move and expand/contract with our cursors like the AC. This using the mouse to move one down is killing my Emacs-fu

Thought I'd start a topic under eisy-ui for beta minor observations, @bmercier please take in the spirit of constructive feedback, as well know that each of these items will have a different priority to you versus me. Maybe others who are helping test can add their observations here. - noticing if I leave the eisy-ui web page up overnight it stops updating ; even if I do a refresh of the page it does not update with no real indication of "heartbeat"; takes a logout/login. Was wondering what the timeout period was? Is there a way to do a heartbeat? - have been noticing differences between the status on the column view versus the detail view. A refresh does not always fix it. Again have needed to logout/login. - the folder retention of expand/contract has been mentioned but also you cannot search for a folder name and then select it to have it open its contents - really, really, would like to be able to use my cursor controls to move up and down the list ; contract/expand folders. As a keyboard user the use of the mouse to move one up or down is maddening (personal rant) - during search as I start typing I am still getting an 'unexpected application crash' regularly. refresh of page often resets but sometimes requires a logout/login cycle.

Been running the Beta local exclusively for a week & have my programs set that way. Seems to be running quite well, with no glitches. Let me know if there is anything specific to stress test.