sjenkins

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.