sjenkins

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

VERSION = '1.12.5' """ 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 Mostly a clean-up version & debug. Some reliability for G3 events. Putting in beta for try-out and comment ; will move to production in a few days if no issues. You can find it in the beta / non-production store.

So I will close this out with this is not a plugin issue, it was a gateway connectivity issue. I ended up adding another gateway device so I had one in each room. Solved the issue. Seems the gateways do not recover well unfortunately.

this folder issue was brought up a while ago in the alpha. the response was that the fix comes with the next major isy update (perhaps the one @bmercier refers to above coming next week).

did you try substituting eisy.local for your local ip adress? that works more consistently for me

@bmercier first, thank you for taking the time to explain the plumbing a bit. Not only helpful but very interesting. Second, you are right I was not forcing when sending my updates, I had left the defaults. Changed that and all of a sudden I am updating just fine in the local dev mode to the eisy-ui. Not sure if there is any penalty for this beyond a bit more traffic and time; but I cannot observe any side-effects. self.setDriver('GV6', self.shadedata["batteryStatus"],report=True, force=True) (the report=True is already default) I will go with this method for now. Thanks again. I will move to the new forum, but thought I should close this out here.

Installed 0.5.8 All looks good. Couldn't tell from the version notes what I need to specifically test. My issue with the local plugin is very odd. A few fields are updating on some of the nodes, but only a few and not real-time. I get this is much lower priority, let me know if it gets to the top ten list.

Hi Emile, since @TriLife is travelling I will jump in, You are close, you data is just not where the node is looking for it. Attaching a link to the relevant node and a screenshot of the part of the program which is relevant (I wrote this device a long time ago to get the temp for a fish tank and the lake) https://github.com/sejgit/udi-mqtt-pg3x/blob/main/nodes/MQds.py If you look at the topics its getting the data, its under the sensor id topic and under that you need the Temperature variable. So basically just add another layer. I know this seems odd for this device but many of the other devices have Humidity, heartbeat, etc. Temp is fine as the device choice. Many of the devices added were not Sonoff as that was my original use case when I added them to the original plugin, @TriLife has brought the focus back to Sonoff as that is his use case. If you want to learn more about the different devices like raw and Analog, take a look in the python scripts of the devices in the plugin from the github link above. You mention you are programming in python so shouldn't be much of a stretch to figure out what they are doing. Hope this helps

@bmercier you are correct (of course)! But you gotta share how you came to that conclusion.