sjenkins

so this is back office but what it does for eisy-ui is make updates to the node list happen immediately, instead of getting stuck when you add/remove nodes or install a new version of the plugin in the same slot. It works pretty slick and is the modern way to handle profiles as we move away from the admin to eisy-ui. My only worry is you can see below you have to be decently up to date on your controller, which is not the case for everyone out there. Interested in feedback here. You can install this either from the old non-production store or it shows up as a beta trial (1-year trial) if you install from the new eisy-ui plugins(beta). 3.2.2 \ DONE dynamic JSON profiles (Phase 1): updateJsonProfile instead of static profile/ zip for eisy-ui sync; requires IoX 6.0.6+, PG3x 3.4.5+, udi_interface 3.4.5+; install.sh renames profile/ to profile.static/ on EISY; profile/ XML remains source for data/base_profile.json; bump profile_version in server.json when JSON base changes

I've been running this for a few days and seems ok. This is back office except it should mean that eisy-ui picks up on profile changes immediately. My plan is to run this across all my plugins, its the current modern way to do profiles. The OGP bit is a bug fix where some users were seeing extra nodes named OGP. Let me know how it goes. ## 0.0.28 - Dynamic JSON profiles: push profile via updateJsonProfile() instead of static profile/ zip — improves eisy-ui sync; requires IoX 6.0.6+, PG3x 3.4.5+, udi_interface 3.4.5+; install.sh renames profile/ to profile.static/ on the EISY so PG3 does not race static upload; profile/ XML remains in the repo as source for data/base_profile.json; bump profile_version in server.json when the JSON base changes - Per-device nodedef on Discover: new shade nodes pick shadertsid, shadenotiltid, shadeonlyprimid, or shadeid from TaHoma capabilities — existing nodes are unchanged until the user runs Discover and a new node is created (removed nodes rediscovered, or manual delete + Discover) - OGP skip hardened: skip all ogp:// devices and ProtocolGateway uiClass (not only ogp:Bridge controllableName) — fixes duplicate OGP nodes when the gateway returns partial records or multiple OGP entries; run Discover to remove stale OGP nodes

You may want to open a ticket with UD

Minor cleanup and a notice upon connection success. ## 1.5.5 - Temporary Polyglot success notice after connect and discovery (clears after 30 s), matching Ta$

sorry for the delay, painting day today. @Techman , I saw your DM as well , what was the other server you tried? and, of course, have you tried a reboot? I just tested and am able to install from both stores, and am able to install on top of beta -> production -> beta looks like a local issue to you.

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