sjenkins

In pg3x when you update beta it will replace with an updated beta, but you are supposed to be able to put the same production on beta or beta on production from the store. Not sure what is wrong here as I have been doing that for a month with these. The other way to do it is delete the beta and install the production on that slot. You will want to copy the configuration to a scratch pad and then update the new one. Your programs will not be deleted, they will stay populated with the new programs nodes. If you have used any of the node in a scene though, they can get trashed. I have done this a lot lately because of the eisy-ui plugin changes. btw: this issue is exactly why in the new eisy-ui they went from 3-stores (local,beta,production) to one, where you do a beta by adding multiple sales options.

Just go to the production store and install into the slot the beta is in.

So I pushed the update to GitHub and the easy-ui plugin store, which should replicate to the PG3x store, but it may take a day. I am resisting the temptation to update in both stores (was told not to). So if you reinstall from the pg3x production store you will get the new version; the store just may not say it, but the plugin will.

So from the readme: Plugin for EISY/Polisy (eisy-ui or PG3 environment) that integrates UniFi Protect cameras and USL/UP Sense sensors via Ubiquiti's Public Integration API (API-key auth). It reports motion, person, vehicle, animal, package, line crossing, audio, doorbell, and sensor events (contact, leak, glass break, temperature, humidity, and more) as ISY nodes. Detection changes emit ISY control commands (e.g. MOTION, PERSON, OPEN) for program triggers, not only status driver updates. Read-only — subscribes to Protect; does not send commands back to UniFi. Let me know what you think!

Time to move this one up to production; the RTS move by percent feature seems to be working well on my system and some others. Let me know if you see anything. Make sure you do a full open / close and time how long it takes then put that in the span for each shade. Right now the default is 8s but my Phantom outdoor blinds are a full 27s. After that you can move by percent in the up or down direction. Remember the Pending / Completed is much slower as that is a handshake with the Tahoma, not measuring when the stop signal is given. Significant profile changes which can take some dancing to get eisy-ui to recognise, the admin just restart. To bmerciers advice, I will take another look at dynamic profiles, but it is a whole new paradigm. ## 0.0.27 - RTS Move By Percent: new MOVEPCT command (percent 1–99, direction Up/Open or Down/Close) sends open or close, waits (percent × total span) / 100 seconds, then sends stop; SETSPAN sets per-shade Total Span Move Time (GV1, default 8 s, persisted); Last Command Executed adds Move By Percent; RTS-only — io/Zigbee shades keep SETPOS

Some warnings if you migrate or install new using the Eisy-ui Plugins. if you use a devfile upload it to the data folder (you don't need to use a zip file anymore). I found that if you put it somewhere else, like in your admin folder, strange things happen. Like some of my devices did not show up, not all of them, just a few. I first thought it was a permissions thing, but just some of them?!? Check your programs using the old Admin, you may find some unloaded (yellow), where you need to update one line of your program and save again. Check all your scenes where you used Virtual devices. I have had to re-add mine due to how I transitioned. Do this from Admin(not eisy-ui), there is a new groups thing which is more complicated than regular scenes. Once done, it sticks but be warned, an inspection of all your devices may be necessary Come back here with any learnings. This move to eisy-ui is a very good thing, but there are a few unintended consequences. tagging @bmercier , don't need anything, just feedback if all this makes sense. Its only Virtual which has had these issues.

@oberkc Good news & appreciate the update. Why don’t you mark the above as the solution for future others What about you @Guy Lavoie ? Did you try the reinstall all plugins? I remember a few years ago having to do that & it solved my issues at the time.

responded in virtual

Not sure what to say guys ( @Guy Lavoie & @oberkc ), just did an install to a new slot on both virtual and Tahoma, all is good. (mine are up to date so can't do the update) You could do a stop, delete and install to the slot you are on , you programs should be fine & configs usually repopulate when you do that (sometimes you have to redo the configs). The odd time you have to resave your programs. The other thing is do a reboot and then try the update, that can work do.

Sorry, @Guy Lavoie , What you are showing is what I was attempting to describe on my phone. I have multiple lines as I usually have local,beta, and production in three slots with different versions. Not sure what to say, the store and the GitHub look good & I am able to run 0.0.27 on beta. I will push the beta to store again. Anyone else having the issue?

production is at v0.0.26 non-production(beta) is at v0.0.27 @Guy Lavoie there should be a button beside that slot 8 indicator to reinstall there. I just checked the repos & all look good.

@Techman , It can be done: You just need to make sure the object you are doing this with {default, command, etc} is chosen as a shade (not a scene).

Purely a unique identifier given by the Tahoma app. Can be used to make sure you have the right device if a node name is changed independently of the unit. Its carryover from my HunterDouglas plugin where it was the only true way to know you were talking to the right shade. Clean look?!? Are you truly an Eisy user? ;)

Follow up: (too late to edit for some reason) If we added the beta type sales option to the old production store then we could make changes in only one of the two places. Adding two sales options to a plugin, if they do sync

ug.

@bmercier , Thought this would be useful to the wider audience. For the transition period how is the production store and the new plugin(beta) store sync'd (or not). I see the new one is populated with what was in the production store. As I have added to the new one I see it doesn't push back to the old production store. Does anything from now on in the old store get sync'd to the new store? Does this mean for the next while that we have old and new, we developers need to update both stores? Not a problem for any of the above I am just trying to figure out the rules of the sandbox between them.

I have had at least once where it blasted right by the percent I had tried to move to. Wondering if the stop signal didn't get through. Let me know if anyone else sees this the odd time, I could send it twice. I must say I am enjoying this feature (use it to bring down the second shade and block morning sun)

This one is a feature request by @Guy Lavoie to be able to move by percent for RTS shades. Make sure you do a full open / close and time how long it takes then put that in the span for each shade. Right now the default is 8s but my Phantom outdoor blinds are a full 27s. I also know on my Hunter Blinds I have one blind which is a laggard to the others all the time. After that you can move by percent in the up or down direction. Remember the Pending / Completed is much slower as that is a handshake with the Tahoma, not measuring when the stop signal is given. Anyway, have fun and give some feedback! ## 0.0.27 - RTS Move By Percent: new MOVEPCT command (percent 1–99, direction Up/Open or Down/Close) sends open or close, waits (percent × total span) / 100 seconds, then sends stop; SETSPAN sets per-shade Total Span Move Time (GV1, default 8 s, persisted); Last Command Executed adds Move By Percent; RTS-only — io/Zigbee shades keep SETPOS PS - This plugin modifies the profile, so if you are using Eisy-ui it can be harder to get it to read the profile update (the button to load profile doesn't seem to be making it happen; on the old Admin you just restart it. I am still figuring out the best way besides deleting the browser cache and restarting the service. Any ideas @bmercier or @Javi ?

I’ve moved to it exclusively and so far it’s doing it all for me. Small bits to be solved like moving a node to a folder or scene can’t always be done by drag-n-drop. Too far, and it won’t scroll. But I write and publish a few plugins, so am in and out of everything daily. Looking forward to the new plugin method inside easy-ui. I like what I see. Thanks UD!

Added a status for RTS shades which gives last command executed. Was a feature request of @Techman ; as well he found a bug in discovery, much appreciated for both! Next will be working on another feature request by @Guy Lavoie also for the RTS blinds to give allow setting of partial moves by percentage. Boy this would all be much easier if we bought blinds with full control, eh? ## 0.0.26 - Skip OGP protocol gateway during discovery: TaHoma reports ogp:Bridge (Open Generic Protocol gateway) as a device; it is infrastructure, not a shade. Previously it appeared as an extra node with no useful commands. Run Discover after updating to remove an existing OGP node automatically. ## 0.0.25 - Shade Last Command Executed (GV8): new status alongside Last Command (GV7); reports Open, Close, Stop, or My Position when sent; starts as None on node startup; GV7 still tracks Pending / Completed / Failed from the gateway

@Guy Lavoie , ok, can do a default time as well (just timed my outdoor Phantom blinds and they take almost 26s to raise). Looks like the old plugin used configuration variables. In the new EISY api the retention across boots and installs is not an issue. the problem with doing it in a config is you don't know the node number until the first boot anyway and this node number can change with a rediscover. I think I would implement with a settable value which is stored as a persistent value. Sound Kosher?

@Guy Lavoie , (and anyone else who has 2c to give), The way I see it this is just an RTS shade function (shouldn't be needed in the new positional based ones). The user enters a time to fully raise/lower, Total Span Move Time We add a command with parameters Move by % This command is Activate with parameters of Move %(1-99), Direction (up,down) The program sends a up/down command, then Stop after x seconds. x being: Move % x Total Span Move Time Thinking now of status. As the shade can be moved manually I don't think keeping a % position has any value. I think the Sade Last Command would be something like Move% Does the above meet your vision?

@Guy Lavoie , I did , then I forgot, good reminder. I'll put it in my todo list, yours is a bit more complicated. Last bit has been busy with life, when I had plugin time I did a bunch of spring cleaning and got some of the older plugins common on the backend. Was slowing me down when everytime I switched work to a plugin the workflow was so different.

Just put up to beta v0.0.25 with a feature request from @Techman Added a field called Last Command Executed which upon startup is populated with None then moves to {Open, Close, Stop, or My Position} based on the command given. Note that if the RTS shade is moved manually with the remote or even from the Tahoma app, there is no feedback here, this is purely as a memory for your programs ; careful as you use it. Feedback welcome as we tweak this plugin. ## 0.0.25 - Shade Last Command Executed (GV8): new status alongside Last Command (GV7); reports Open, Close, Stop, or My Position when sent; starts as None on node startup; GV7 still tracks Pending / Completed / Failed from the gateway

Fixed where there is a delay at normal startup for the waiting on user connection message to clear. As well have fixed the upload to the data folder for your devfile. This and other communications and moving to the modern UD standards on things. Tests out on my system, give it a try: ## 0.50.11 - Fix config overwrite on update: stop re-injecting example devlist/devfile and MQTT defaults on every parameter load; clear customParams in server.json so plugin updates do not reset saved Polyglot configuration - Clear waiting notice when discovery or MQTT connection fails ## 0.50.10 - Fix stop() crash on early shutdown: remove legacy mqttc teardown path that raised AttributeError when discovery failed before the MQTT bridge was created (common during eisy-ui config) ## 0.50.9 - Clear MQTT waiting notice promptly after broker connects: drain Paho callbacks at startup and at DISCOVER so "Waiting on user MQTT connection" does not linger for a full poll cycle when the broker is already up - Fix devfile path resolution: bare filename (e.g. virtualconfig.yaml) resolves to data/<name>; empty devfile no longer silently loads mqtt-devices.yaml — use an explicit devfile or devlist - Fix startup log (was incorrectly labeled "Virtual Devices") - PG3 store manifest server.json) with executable udi-mqtt-pg3x.py — use Update from the store - Rename entry script from mqtt-poly.py to udi-mqtt-pg3x.py - Standard bootstrap (error handling; version in VERSION / profile/version.txt / server.json) - Developer toolchain: uv, pytest profile sync test, Makefile, CONTRIBUTING (runtime install unchanged: install.sh + requirements.txt)