Guy Lavoie

Bingo, exactly what I needed to know! Added to my (ever growing) notes!

@Michel Kohanim Thanks. That brings up another question: if an update did in fact really mess things up and it's bad enough that eisy-ui can't be accessed, how could we manually switch to the inactive boot environment from the command line (by hooking up a screen and keyboard)?

Ok, but is the general idea that after you confirm that the new one has working fine for a while, you can delete the inactive one? Will a new update further down the line then made the current one an inactive one, offering a recovery path again? It's a great feature, making updates less do or die.

@xlurkr Try the manual update, as suggested by @Michel Kohanim himself (a couple of posts up). Worked for me. Join the geriatric Polisy club 😄

Well hey, I just tried exactly that, and it upgraded fine! Thanks for the honest reply. Yes, it's a bit slower but as a testing device, that's small price to pay for the versatility I get from having these test units. I'm quite active on the forum and many of my posts begin with "I tried this on one of my test Polisys..." It both helps the community, and pushes me to try and learn new things. I have three Polisys that I obtained as used units for a very low cost or free. For sure, a test eisy would be nice, but it's prohibitively expensive here in Canada. I even got my own eisy as a used unit, and used eisys come up rather rarely. A slower but otherwise functional Polisy makes for a good compromise and a handy test device. Thanks for the workaround. 😊

That does not appear to be supported yet.

Oops its: uname -a

The raw method is to ssh into it and do: umame -a Otherwise it should appear in the sysconfig.txt file that is accessible as shown in the release announcement

That program editor is going to take some getting used to...

you ssh into it and watch the log file as it grows: tail -f /var/udx/logs/debug.log This is handy for observing the progress of upgrades as they happen.

Looks like the Polisy won't getting this update. I just thought I'd try it on one of my test units and the upgrade log file says: Upgrade failed: field upgrading of non-eisy devices no longer available ...

Basically, don't do this from any type of remote access. Do the upgrade from Admin Console, on a computer that's in the same physical location and on the local network, such that you can restart the eisy by power cycling if necessary. This avoids any issues that could be dependant on remote access authentication, etc.

Paranoia is an asset in software development 😄

That release announcement sure caught my attention! Let's discuss it, and indicate how our own upgrades went. I haven't taken the plunge yet myself. Looks like this is the version where eisy-ui becomes fully functional. The release notes raise several questions that come to mind: It starts with "We're happy to announce the availability of OS14.4, IoX 6.1.1, UDX 5.0, and eisy-ui 1.2.0 for eisy (only)". Does this mean that the whole upgrade is for the eisy only, or just eisy-ui? Farther down it does mention that you need to be local to your eisy/Polisy, so I'm wondering if the Polisy is supporting this upgrade. There is a link showing the supported Zwave and Zigbee dongles. The ZMatter dongle isn't listed, but I'm hoping that's just an omission. Similarly, is the Zooz 700 series dongle still supported?

I just added a feature suggestion: https://forum.universal-devices.com/topic/46913-suggested-ud-mobile-feature-numeric-keypad/

As another poster was looking for, a handy feature would be a generic numeric keypad. Digits 0 to 9, Clear and Enter. This could then be associated to a selected variable, and with configurable low and high limit values. The variable could then be used in programs as a pin, temperature setting, etc. Anything you like.

Yes, that clunkly way is the workaround that comes to mind.

For that, I'd either create an icon that runs a program, or create a switch with the Virtual plugin, which then runs a program that then sends the desired commands to the alarm system.

That's a good idea, but a backup like the one we do in Admin Console would also be great to automate, something like do one automatically when logging into Admin Console if the previous one is more than so many days or weeks old.

So these are strictly internal changes, right?

90% of the answer is from the buyer. If it's a techie, they might be delighted. If they shun technology, it could be a support nightmare.

Join the ranks, we're recruiting!

Well if you know me well, I get everything used! Ebay, marketplace...UDI coffee shop 😆 etc. I originally got my URTSII literally for free, and the Tahoma Beecon for a low price. @sjenkins , did you update your docs to indicate that your plugin workes with both the Tahoma switch and the Beecon?

Yup, just installed the update. It's been working reliably, installed on one of my test Polisys. I have two shades that I lower partially during the day, every day, with this. My main (eisy) controller is still using the original Somfy plugin, which works with the URTSII device, for now. One handy feature of the Somfy plugin has is that you can define a travel time parameter (in PG3 configuration and/or as a program command) for each shade, which is the time it takes (in seconds) for a shade for a fully open or close. Then you can send commands to open or close by a certain percentage, which will activate it for the percentage of the time of a full travel. This could be a nice feature to add to the Tahoma plugin. If Time is Sunset - 45 minutes And $s_shade_close_early is not 1 Then Set 'Somfy Controller / Shade_02_Shade_bedroom' Set Travel Time 20 seconds Set 'Somfy Controller / Shade_02_Shade_bedroom' Open 15% $s_Shade_bedroom = -1 Else - No Actions - (To add one, press 'Action')

Well, there's still the ole workaround of wiring a dry contact unit like a IOlinc across the button contacts of a physical remote.