sjenkins

I do agree an ESPhome version may be the right way to go. Got so frustrated with the MQTT version that I abandoned it. I have been running for now the last month with ESPHome on my Ratgdo. I put up a HomeAutomation server on a Pi4 laying around (I don't use HA for anything else) and then using the UDI plugin on HA backfed the Ratgdo flags to variables then Virtual devices on my EISY. The above chain gang of handoffs which took about 2hrs with writing the automation on the HA and some programs on the EISY has been rock solid for a month, in both directions. Go figure. My plan is to make a Virtual device to match the garage door opener I/O. For bonus points, If I can find the time, would like to take the HA out of the chain with a plugin. Just really need to find some docs with the protocol and write it. Or wait for someone else to do it.

Hi @GTench, this is the first try at a multi room scene for G2. As is usual, I seem to remember the command to activate may be different. can you activate the scene from the PowerView app?

*** LATEST BETA is 0.40.2 DONE README.md clean-up DONE POLYGLOT_CONFIG.md clean-up 0.40.1 DONE: S31 debug: displays in program now 0.40.0 DONE: Changed versioning so git branches and hot fixes can work. so 0.40.0 means it will be on branch 0.40 with the last .0 reserved for hotfixes. These will then be pushed by PG3 to users DONE raw fix docs & allow int in addition to str DONE find topic by topic if no device_id find DONE discover button updates nodes and MQTT subscriptions DONE config.md fixes DONE status for switch device available in programs DONE internal: improve logging for debug DONE: Parameters are not initially populated, plugin uses the following defaults: mqtt_server = LocalHost mqtt_port = 1884 mutt-user = admin (same as None) mqtt_password = admin (same as None) DONE: Switch make Status available in IF for programs Please add your bugs, suggestions, and improvement thoughts in the forum thread I will update this list as ideas come in and are prioritized. NEXT: Query is not consistent across the devices REMOVE: iFan debug: ****calling this working (no changes made) as my tests work, also working for original raiser of issue. Let me know if not the case for anyone. HELP: Google Assistant is not reporting device status consistently: HELP: Multiple-Analog clean-up (particular issues?) HELP: Tasmota potential automation opportunities in discovery LATER: simplify devlist/devfile by using 'defaults' for status_topic and cmd_topic.

@maxnorth appreciate knowing if it was new. Shouldn’t be as nothing was changed in that area of the program, but. we certainly can add the above to the list. Shouldn’t be a big deal. my next stop is to start the thread on bugs and suggestions.

@maxnorth I can confirm that only control works and not status on switches. I tended to only use control in my programs ; can you confirm, is this new or an old issue? thanks

@maxnorth we are compiling a list of errors / improvements for this plugin, like above. For today can we verify that everyone is up and going? I will start a "suggestions" topic thread for items like the s31 fix, typos like above, & perhaps @TriLife & I will share our list. Together we can prioritise !!!

So there is a new version up 0.0.39 Want to explain the issue & why it sometimes worked for some things. Seems it was a timing error which raised its head as we went to the new plugin template The new template is much more asynchronous than the previous which was much more script Its why you have to restart the plugin every time you change a parameter (for a future fix) Basically the plugin does the mqtt.subscribe on connect to the mqtt server. unfortunately discover is handled from the parameter side of things So a "wait for me" flag was required here. So sorry everyone, but this one was a hard one to debug as I never saw the issue & my test file of 160 nodes does not have devices updating to it. Please let us know here if it worked for you!

I agree. The issue is finding the file; spent an hour last night until I defaulted to this. Does not seem to be where the mosquitto docs say it should be and Michel is out of town until tomorrow. The others are saying he knows the most about this.

@EWhite appreciate the feedback ; couple questions: 1. just to be clear, did you delete back to root on the topics? 2. you mentioned everything else is working. Above here you said everything was not sending status. Is that a change with this or were the other devices working. thanks

@GTench Yes I am finding this out with another plugin as well. Not sure if this happens with every name change or something special here. Bit of a PITA for the users. Thanks for the feedback, I will bring it up on the developers forum. Glad all is working well. You must not have any multi-room scenes, as one of my G3 users found where the discovery went into exception (not a crash but effectively tanked updates of scenes) when it tried to discover one. Maybe if you have a min you could make one and fire-test it for me on G2 as the discovery functions are completely separate. No rush, but I'd be interested that it works.

For those not on the other stream there is a solution to try & looking for feedback on.

per @TJF1960 I would delete all under tele, tasmota, and stat. Do NOT delete $SYS I agree this is NOT the way I would prefer to be sending regular users to. At this point it is outside our plugin and better than sending people into SSH ing into the EISY and deleting files. The program status/control problem he brings up sounds like a profile file issue which is more in my bailiwick to fix. I can get to it tonight after work.

As this is happening to some and not others, as well happening to some switches and not others I am coming to conclusion that this is to do with the gen.mosquitto server and its persistence. This survives reboot & deletion of an individual plugin. As well as restart of the mosquitto server. I guess that is why they call it persistence. My theory as we all had to delete and install rather than upgrade with the name/author change on this plugin due to the different serial number associated with it, I am thinking that mqtt topics have been corrupted as some things have changed. For those who have an MQTT Explorer on their Mac or the equivalent on Windows, you can get to it your server. This is at the ip of your EISY and the port number 1884 You will find your topics there. Delete back to the ROOT one or all of your switches. You may need to restart the plugin. Your only loss here will be the current status of your devices. ** for those who don't know what I am talking about, wait a few hours until we get some answers from a few users If we prove this out with a number of users, we will find a more elegant way to do this for all users. I may need some help from @bmercier as I don't think we can expect all users doing this. Basically the mosquitto.db needs to be deleted while the service is stopped on the gen.mosquitto.ud server.

@apostolakisl such a good idea that I have been trying to do it for the last 2 months The latest PG3 update of last week allowed developers to change names and some other things. But I am a bit confused because I changed it last week, so it should be updated in the store on your PG3, it is in my other users.

Hey guys, can I get some data from you. As you heard both @TriLife & I are getting status' , also I think I am hearing that some of you are getting mixed results with some working and some not. Is the only device affected the switches? could @EWhite , @maxnorth attach debug level logs? Please point out which are working and which not please. Has anyone done a reboot of their EISY? Because of the variance of experience I am wondering on that too. We should be able to figure this out before too long. Sorry for the inconvenience.

I think this may be with the latest PG3 update & name changes. With the updates that @TriLife and I made I think the number which goes along with the plugin may have finally changed from the old xKing version of MQTT. I had to do the same, delete and reinstall, but didn't think anything of it.

Thanks to @glarsen for pointing out that multi-room scenes broke discovery. This update should fix that for both G2 & G3. Also changed a timer on node throttling as I was getting the dreaded "red box" in the bottom right for the first time. VERSION = '0.1.10' """ 0.1.10 DEBUG multi-room scenes sending Discover into exception FIX Throttling timer from 0.1s to 0.2s past versions: 0.1.9 DONE Fix G3 Events stop working after some period of time 0.1.8 DEBUG branch 0.1.7 DONE rename nodes if changed in PowerView app 0.1.6 DONE parameters based on shade capabilities 0.1.5 DONE format for program setShadePosition DONE set Shade Position change using False to define which parameters to change DONE more debug on G2 so it acts as expected 0.1.4 DONE add node_queue & as result need pause updates while in discovery DONE FIRST TRY G2 tilt feature 0.1.3 DONE node discover rewrite to allow add/remove DONE add event 'homedoc-updated' currently no actions DONE limit room label size to 15 as room - shade/scene < 30 for ISY DONE clean up LOGGING.debug messages DONE G2 bug fixes 0.1.2 DONE change icons to nicer ones DONE docs with screenshots & description for udi spotlight DONE add troubleshooting document DONE add some support for G2 gateways (no gateway push, only polling) 0.1.1 DONE tap into gateway events, which allows longPoll update to move from 30s to 60s DONE active scene indications from events DONE shade motion indicator from events DONE shade position update from start, stop, online events DONE remove parameters based on shade capability (primary, secondary, tilt) DONE update readme & config instructions to highlight G3 scope 0.1.0 DONE handle multiple gateways automatically, picking primary & switching if required DONE updated configuration instructions as well as link to the forums 0.0.9 DONE fix uom for positions(100) & ids(107) DONE more notices clean-up DONE shade naming to include room as scenes DONE remove status based on shade capability (primary, secondary, tilt) 0.0.8: DONE handling of notices individually DONE polling 5s short-poll 30s long-poll DONE status for programs (positions etc) 0.0.7: DONE faster status updates when command is given DONE bug fix DONE re-order of parameters displayed 0.0.6: DONE move shade by specific amounts DONE bug fix scenes not activating 0.0.5: DONE change shortpoll to 30s DONE update shades on shortpoll DONE clear start notice at shortpoll DONE clean up error proofing in get DONE fix updating variables with shortpoll DONE limit device ping to 5s 0.0.4: DONE discover when new gatewayip is entered DONE poll status regularly using shortpoll DONE update required after nodes added to get status DONE notice when gateway get error """

Thanks @raymondjiii, for your thorough problem solving. As a macOS user who spun the Russian roulette yesterday and updated ; without issue ; I have been reading with interest. I love my Mac and I love my IoX, java meh.

Fixed issue where G3 would stop updating as SSE events would not update after a number of hours. VERSION = '0.1.9' """ 0.1.9 DONE Fix G3 Events stop working after some period of time past versions: 0.1.8 DEBUG branch 0.1.7 DONE rename nodes if changed in PowerView app 0.1.6 DONE parameters based on shade capabilities 0.1.5 DONE format for program setShadePosition DONE set Shade Position change using False to define which parameters to change DONE more debug on G2 so it acts as expected 0.1.4 DONE add node_queue & as result need pause updates while in discovery DONE FIRST TRY G2 tilt feature 0.1.3 DONE node discover rewrite to allow add/remove DONE add event 'homedoc-updated' currently no actions DONE limit room label size to 15 as room - shade/scene < 30 for ISY DONE clean up LOGGING.debug messages DONE G2 bug fixes 0.1.2 DONE change icons to nicer ones DONE docs with screenshots & description for udi spotlight DONE add troubleshooting document DONE add some support for G2 gateways (no gateway push, only polling) 0.1.1 DONE tap into gateway events, which allows longPoll update to move from 30s to 60s DONE active scene indications from events DONE shade motion indicator from events DONE shade position update from start, stop, online events DONE remove parameters based on shade capability (primary, secondary, tilt) DONE update readme & config instructions to highlight G3 scope 0.1.0 DONE handle multiple gateways automatically, picking primary & switching if required DONE updated configuration instructions as well as link to the forums 0.0.9 DONE fix uom for positions(100) & ids(107) DONE more notices clean-up DONE shade naming to include room as scenes DONE remove status based on shade capability (primary, secondary, tilt) 0.0.8: DONE handling of notices individually DONE polling 5s short-poll 30s long-poll DONE status for programs (positions etc) 0.0.7: DONE faster status updates when command is given DONE bug fix DONE re-order of parameters displayed 0.0.6: DONE move shade by specific amounts DONE bug fix scenes not activating 0.0.5: DONE change shortpoll to 30s DONE update shades on shortpoll DONE clear start notice at shortpoll DONE clean up error proofing in get DONE fix updating variables with shortpoll DONE limit device ping to 5s 0.0.4: DONE discover when new gatewayip is entered DONE poll status regularly using shortpoll DONE update required after nodes added to get status DONE notice when gateway get error """

Yes, and. The issue with that is his use of ESPhome , it’s a platform in its own right. So he is really programming his application as a set of JSON scripts which ESPhome then handles as a platform. So not much to easily compare. That is why I was thinking if I could understand the HA comms. For now my very ugly method of adding a pi with HA is working more reliably than you might think. My current frustration is that the author seems to want the MQTT version to go away. It was why we purchased hardware. There currently seems to be one sided dialogue with little from the author. Happy if I’m wrong here but I am subscribed to the issues & that is my read.

Minor debug and name change to HunterDouglas per naming standard. Means it will show up on the store list in proper alphabetical order, instead of near the bottom with the old hunterdouglas name.

Installed and the new features are working, thanks Benoit!

Upgrade & reboot worked as expected. Attempted a name change on my plugin & no joy. Stayed the old name in the store and back-fed the old name to the developer list, but my changelog did update. @bmercier I will also put in a ticket.

I’ve gotten so frustrated with the mqtt version I abandoned it & put home assistant on a pi. I have no use for HA otherwise. I am now backfeeding to the ISY the variables I want. Pain in the a** but it is working. certainly not the recommended solution. My next step was to figure out how the HA protocol works. Sounds like a time sink. I would really rather they just fix the mqtt version. Seems like he knows how as this esphome version is bulletproof.

@GTench Not currently as it makes that choice at the start. Would require some rewrite, and a tester (hint hint). No reason it can’t be done, I just don’t know how the gateways operate together or are talked to separately. Might make more sense just to run two instances of the plugin. There isn’t any other cross talk between blinds. You could make your own scenes in the ISY. I’d be interested how their app handles it.