Guy Lavoie

I get that. The advantage with your approach is that it can all be done by creating a scene, avoiding programming. That's one thing I've learned from reading everything on the forum for over a year: not every UDI user is from a programming background, and there are often requests for a more "canned" approach, avoiding the need to program. In that regard, your latest addition is certainly filling a need. You're adding to the scene capability, just like with virtual switches. Keep it up! (now back to my selfish little world)... I'm a geek, I like having basic building blocks that I can use to make up fancy stuff that's often more fun creating than actually using once finished. It's an incurable disease! There must be a support group out there somewhere... In the case of my bathroom fan program, you'll notice that it's comparing the timer value to an integer value, not to a fixed number. The reason for that is that there are a few other programs related to this be all, end all bathroom fan routine. Why make things simple when you can make them complicated? Hehe. It's because if I turn on the fan and the timer isn't running, then it sets an initial time value of 600 seconds (10 minutes) and starts the timer: G2 toilette 1 fan debut - [ID 0010][Parent 0016] If 'T2 Toilette Fan' Status is On And 'Timers / t0_toilette' raw data 0 is 0 Then $i_toilette_temps = 600 Set 'Timers / t0_toilette' Raw value 1 -- If however a control event comes from the same switch and the timer is already running, it's because I want to add running time (let's just say that this particular trip to the bathroom was challenging..), so it adds another 240 seconds (4 minutes), and will allow time to be added up to two instances of 4 additional minutes: G2 toilette 2 fan ajout temps - [ID 0007][Parent 0016] If 'T2 Toilette Fan' is switched On And 'Timers / t0_toilette' raw data 0 > 0 And $i_toilette_temps < 1080 Then $i_toilette_temps += 240 -- When the timer value is reached: G2 toilette 3 fan fin - [ID 0008][Parent 0016] If 'Timers / t0_toilette' raw data 0 > '$i_toilette_temps Raw' Then Set 'Timers / t0_toilette' Raw value 0 $i_toilette_temps = 0 Set 'T2 Toilette Fan' Off -- And finally, if the switch is turned off manually: G2 toilette 4 fan off manuel - [ID 0006][Parent 0016] If 'T2 Toilette Fan' Status is Off Then $i_toilette_temps = 0 Set 'Timers / t0_toilette' Raw value 0 You can see why I like to treat the timer like a variable. This is how it would probably be done with a generic PLC. I also use a timer in my garage door programs, to create a lockout timer (to ignore additional commands) while a triggered open or close is underway.

Interesting that you bring up timers. In fact this was one of the first subjects I posted about when I first got started with a ISY994i just over a year ago. Where are the timers? I also come from a PLC world with ladder logic, and my first home automation controller was the Applied Digital Ocelot, which has timers that can be treated just as variables. I found out that you can create timers in IoX with a variable that increments after waiting 1 second, but this isn't as clean, and the unpredictable order of execution of IoX programs (which is also contrary to proper PLC logic) makes that a bit less reliable for short intervals. Forward about 6 months later (and much learning) I started learning about plugins and although the documentation is very sparse, I managed to create a simple plugin that I called Timers, that replicates the functionality of the Ocelot timers. Just as many of us name state variables with s_xxx and integer variables with i_xxx, I name my timers with t_xxx so that they're easily recognizable in programs, but are otherwise useable like variables. They certainly have been useful. Here is a screenshot of what they look like: Just like with the Ocelot, I made mine increment once per second of they're set to a non-zero value. They're handy for stepping through time separated steps of macros, and aren't subject to early termination like Wait statements (because of the triggering event no longer being true). If I only want a simple time interval, I can set one to a negative value. For example set it to -5, and five seconds later it will roll over to 0 and stop automatically. Here is an example of how I use one for the ubiquitous bathroom fan timer application: If 'Timers / t0_toilette' raw data 0 > '$i_toilette_temps Raw' Then Set 'Timers / t0_toilette' Raw value 0 $i_toilette_temps = 0 Set 'T2 Toilette Fan' Off Else - No Actions - (To add one, press 'Action') Now that we have an actual person who produces distributed plugins recognizing the need for timers...we're getting there! If you can make generic variable-like timers, that would be a great addition!

I just fixed the "Starting Subscription..." thing as indicated, by upgrading to 0.6.3. So far everything is working as it should.

I think the by default, they meant the Admin Console login by using portal account and password, and not the eisy-ui interface, which will be become the preferred way once it's all finished. The advantage with logging into Admin Console this way is that you're logged into everything at once: portal, PG3 and Admin. If you log into admin console using port 8443 like before, no biggie. That's still possible.

Yes, you can still do so. You can choose to work either way. If you look at the URL entries in IoX finder, you will see whether a port number is defined or not. It always used to be "https://<ip address>:8443/desc" and if you use that, it will ask you your usual admin login and password. If you have an entry without a port number, such as "https://<ip address>/desc", then that will bring you to the login screen where it asks you for your portal login and password. So if you have an entry without a port number and you'd like to login with your IoX admin name and password instead, create a new URL entry in IoX finder using the Add button.

After being a UDI user for just over a year now, I've noticed a few things with being involved with the hardware/software and the community. - There is often excitement...and trepidation when new releases of IoX come out. I've seen the birth of 5.9.1, Matter support, and now 6.0.0 and eisy-ui. It appears that it's not rare that something doesn't quite turn out as expected and the update causes some users to not be able to reconnect with their controller, and require some extra manual steps (ie: pkg install ...) to get it working. In some cases it just fails and a ticket is needed. Other times there are some unexplained effects, like the "small filesystem" that a few of us ended up with on a Polisy. - A few of us have more than one controller. Myself I have a eisy actually running things, and two Polisys. Sometimes it happens from having upgraded from one to the other, or by chancing upon a unit for cheap or free. I certainly enjoy have the two Polisys for experimenting. When a new release comes out, I'll try it on a test controller (Polisy) first. It's a great, risk-free way of trying things out and learning about new stuff, like eisy-ui. Having the ability to reflash the SSD on a Polisy adds greatly to the "risks" we can take! I like to try things that would be quite foolhardy on a running system. My reason for starting this thread is that I'd like to see what people are doing for backup. Not just file backups as we see in the menus, but actual operational backup, in case our main controller fails (failed upgrade or whatever). A lot of us have come to depend on our controllers, and having voice control with Alexa has often widened the user base to our families too. When things stop working, we quickly get called upon to "fix it!". At minimum, A serious (read: highly dependent) user should at least have a spare PLM, and a spare power supply for the controller isn't a bad idea either. Having a spare controller is a bit more expensive, and moving our operations to another one when our main one fails isn't exactly a simple process. In fact that's the real reason I'm starting this discussion: does anyone have that kind of plan? How are you doing it, to be in a state of readiness? For the purpose of this discussion, let's stick to switching between eisy and Polisy (both: between same type of controller, or from one to the other). Several sticking points come to mind: - Zwave: how do you backup zwave when you have a zooz stick? Is it included in the main IoX backup? The Zmatter dongle offers a backup/restore menu, but zooz doesn't. With Zmatter, is it as simple as moving the dongle over and restoring the zmatter backup? How about zooz? If you have a Zmatter dongle insie a Polisy, you'll need an adapter if you want to be able to quickly move to a eisy. - Insteon: usually that just requires you to move the PLM over. But if you have a Polisy with a serial PLM, you'll need a USB to serial adapter. - IP based connections: If you have plugins, network resources, and especially external devices or apps that send REST commands to your controller, It will be complicated if it ends up with a different IP address. To switch controllers, you'll probably have to play with your router's DHCP address reservations so that your replacement controller has the same IP address as the controller you're replacing. - Portal access: The difficulty here is that portal subscriptions are based on your controller UUID. And that is based on the network card's MAC address. Even if UDI moves over your subscription to your new UUID, do you have to manually recreate all the device definitions? Or can UDI actually reassign all the definitions to the new UUID at the same time? This still means that you can't quickly move over to another controller, without external support. - Plugins: This is probably the most complicated part, especially with paid plugins. I know that the plugins pathnames include the UUID of the controller. Can plugins be backed up and restored on a different controller without external intervention. I think we have enough here for getting a good discussion going...

As often happens, you sometimes need to recreate the URL manually in IoX Finder, the first time (click on the Add button, then enter "https://<ip address>:8443/desc" ) When you pointed a browser to the IP of the eisy, you got the new eisy-ui screen. This is still in development and will eventually become the replacement for the admin console. But it's not anywhere near finished yet. No program editor, etc. yet. Right now it's more of a device dash board allowing you to see and control devices directly.

That looks perfectly normal. You have absolutely nothing to worry about.

But if there are no scheduled commands of any kind when these random lights turn on, it would take more than messed up links for these events to be triggered. I'd start with leaving the PLM unplugged overnight just to see if the commans appear to come from it. You don't want to assume anything.

The two Polisys I have also have 32 GB SSDs. I doubt they ever came with something smaller.

Is there any pattern to it? Like the same light coming on at the same time? Do any of your programs have time triggered events?

It's ordering new home automation toys from Amazon! ;-)

I have the android version.of UD mobile and it syncs up fine with a Polisy running 6.0.0

One of my two Polisys did upgrade correctly, and I made an image of that one to reimage the other that didn't upgrade properly. The one that failed (the first one I tried) had one of those smaller filesystems, and it's one I had previously reimaged from a file provided by UDI. Hence the discussion about these incidents of smaller filesystems.

So this small filesystem size thing is popping up again. That's three of us now.

If you have multiple control systems, each with their own Alexa skill, then you'll need to be careful and avoid creating duplicates. They don't know about each other. Ideally it's better to have only one system actually talking with Alexa, and the other systems communicate locally with the one that does. Finding unique device names becomes a challenge as the number of them grows. It's best to avoid multiple word names where one word is used in several names (ie: bedside lamp, kitchen lamp, etc). I've kept everything to single word names, which is much more reliable.

No, if Michel tells you it needs flashing, then that's your next step. That's a more extreme solution because you're not recovering anything, so if you have no backups, this really sets you back. About the portal subscription or not and my login screen comment above: I might have a bit of an exception here. I have two Polisy units, that I use for testing and learning. Polisy 1 has a few test nodes defined on it, and a lapsed portal subscription. Polisy 2 is one that I got recently, given to me for free by a generous forum member. He said it was messed up, it wouldn't even boot up. I ended up getting an image file from UDI and buying the needed USB adapter card to enable flashing the SSD using Rufus. That worked...I think. As I posted in another thread, it was seemingly working fine, and I picked that one to try the 6.0.0 upgrade. Well the upgrade failed (it stayed at 5.9.1) and when I started checking it out, I had the same issue as @apostolakisl: a 3 GB filesystem and the upgrade was failing due to disk being full. I haven't proven it but my thinking was that maybe I made a mistake when using Rufus to flash it's SSD. Well ok, so then I tried the upgrade on Polisy 1. That worked great. So I had an idea: make an image file of the SSD of Polisy 1 using Rufus, then I used that image file to reflash Polisy 2. So now I had a clone of Polisy 1 running fine on Polisy 2. Already upgraded to 6.0.0 too. Now back to the portal subscription thing: Polisy 2 was eligible for the free 1 year portal trial subscription (the previous owner had never subscribed), which I enabled. Works fine. Portal access is up and running on it. But, it was running an image of Polisy 1, which had a lapsed portal subscription. The 6.0.0 upgrade process was done on that unit, then the image copied over to Polisy 2. So the 6.0.0 upgrade process must check if you have an active portal subscription, and configure the Admin console login to use the usual IoX login and password if you have no portal subscription, or use your portal credentials if you do. Since the upgrade had been done on a no subscription unit and then copied over, Polisy 2 is having me log in using the IoX login and password, but still has a working portal subscription. I'm sure there must be a simple configuration file somewhere that tells the admin console login program which user name and password (IoX or portal) to use, and that could be easily changed to use one or the other.

I notice that when you log into with the launcher, the login box actually tells you what login to use. On both of my test units (both Polisy) the box has the User ID and Password fields, and underneath it tells me "Use your IoX userid/password". I imagine that for those who now log in with their portal credentials, it must tell you to use those instead? Because not everyone has portal subscriptions.

I'm confident that UDI will get you running again soon, since your Polisy is booting up and is getting a network address. Yes, do tell us what it ends up being. I have two Polisys here running 6.0.0 so it definately works.

I also get the warnings about the polyglot owner not being right, the -H option, and a pkg names serial not found when doing a udx restart, but I can still log with with admin console.

It would be helpful to see what those are. Ok, dusting off some old unix tricks here... redo the pkg install as follows: sudo pkg install -f isy >/tmp/log 2>&1 This redirects standard output and error output to a log file (/tmp/log). Because screen output is being redirected to a file, you won't see the prompt for the admin password, so just type it in blindly about 3 seconds after starting the command. You also won't see the "do you want to proceed" question, so after about a minute, just type "y" and enter. When the prompt comes back, you can view the output in the /tmp/log file, and post it here.

So you tried the recovery in the announcement: sudo rm /var/udx/.udx_install_cleanup sudo rm /var/udx/.upgrade_status sudo pkg install -f isy sudo service udx restart The recovery instructions are written for a eisy, so it's normal that the interface re0 would not exist. For the polisy, that would be igb0 instead, so: sudo dhclient igb0 sudo service udx restart But first, what did you see when you did: sudo pkg install -f isy ?

That looks good, so it's not a messed up filesystem. Normally when the upgrade finishes, it prompts you to reboot. See that at all?

Log in with ssh and do the "df" command to show the disk apace, and post a picture of the screen.

Thanks. I hadn't thought about the multiple pages, which can certainly make organizing things much more intuitive.