Guy Lavoie

Well I've made some interesting progress in backup strategy. The fact that I have two Polisys (and the hardware necessary to reflash their SSDs) for testing allowed me to try some of the riskier things that I wouldn't do on a single system that's actively in production. The first was to do a full file backup (unix, IoX, plugins... everything) to a USB stick, and then use that to "clone" the Polisy I took it from to the second Polisy. Worked great. This involves connecting by ssh and running unix commands. This type of backup is good when you're about to do a major change, like an upgrade to a new IoX version, especially if it also upgrades the version of FreeBSD. This has been the case with 6.0.0. Before doing any of this: Please... UDI provides truly great support (almost to a fault, if we think that we can try risky stuff because at worse, they can always bail us out). At minimum, you need to be confident with using unix commands, and be ready to recover using one of their supported methods if you get into trouble doing this (like buying their recovery USB stick). As the saying goes: a lack of planning on your part does not necessarily constitute an emergency on their part. UDI gives us an amazingly open product and great support. Don't abuse it! That said, here is my procedure for making a full cpio unix backup of a controller. Cpio is the name of the unix command (means copy in and out) that we use here. I know that most people use "sudo" commands for this kind of thing. I've worked with unix since 1985 and was used to doing everything in straight "root" login. Sudo didn't exist back in the day! Yes, I'm an old dinosaur. Try it with sudo commands if you feel better doing it that way. To get to a root prompt, login with ssh the usual way (admin@polisy.local) then do: sudo sh and when prompted for a password, enter the admin password. You should then get the "#" prompt. Ok, you'll need a USB stick. I bought some 32 GB sticks for this. First you need to create a filesystem on the stick, partitioned as a single large partition: - insert the usb stick and view disk devices: # geom disk list - note that da0 is the usb stick, should show brand and size. # gpart destroy -F da0 da0 destroyed # gpart create -s GPT da0 da0 created # gpart add -t ms-basic-data da0 da0p1 added # newfs -U /dev/da0p1 Now you have a mountable filesystem that you can copy files to. cd to the root directory (cd /) and create a directory that will be a mount point with a filename that you won't find anywhere else in the system, to make it easy to find in a list. # mkdir abcxyz Finally, mount the usb stick: # mount /dev/da0p1 /abcxyz Verify that its mounted, using just the mount command. You can also see the storage capacity using the df command, which will show you the number of blocks available on both the SSD and the mounted USB stick. # mount # df In unix, filesystems are mounted as subdirectories to the root filesystem. This makes file operations between physical media seamless. It's just another directory. Ok, now for the cpio backup. The trick is to create a file list of everything on the root filesystem, and then have the cpio command get the names of the files to backup from the list. The reason for this two step process is because we need to make a list from the root filesystem, which will by default include the subdirectory where the USB stick is mounted. We then want to edit the list to remove that directory from the file list because if you don't then the backup will try to backup the backup itself, recursively, like a snake eating it's own tail. So create the file list from the root directory, using a unique file name: # cd / # find . -print >/tmp/file_list Now use the vi editor to remove the mount point directory from the file list. Delete any lines that begin as "./abcxyz" in the file, and save the file. Then launch the actual backup, which will back up everything into a single large file with a name of your choosing: # cpio -ov >/abdxyz/my_pre_upgrade_backup </tmp/file_list This cpio command redirects it's standard output to the /abcxyz/my_pre_upgrade_backup file, and redirects it's standard input from the file list we created earlier. the "o" option means output, and the "v" option means verbose, which means it will display the file names it's backing up to the screen (technically, to the "error output" file descriptor). You'll see hundreds of file names scroll by. Once it's finished and you're back to the root prompt. You can verify the presence and size of the backup file: # ls -l /abcxyz You then need to unmount the USB stick, using the umount command: # umount /dev/da0p1 You're done! Now suppose that digital armageddon occurs and you need to restore your system. You at least need to get back to a unix shell prompt. This could involve reflashing the SSD, or connecting a keyboard and screen to a eisy because networking isn't working. Whatever. The first thing you need to do is recreate the mount point if it got lost as part of the disaster: # mkdir abcxyz Now insert and mount the usb stick: # mount /dev/da0p1 /abcxyz Verify that its mounted, using just the mount command. All ok? So now make sure you're in the root directory and logged in as root, because this is going to be a real smash! Cringing is permitted! (remember, I did this on a test system that I could reflash). Launch the restore: # cpio -ivumd </abcxyz/my_pre_upgrade_backup Aside from the obvious "i" for input and "v" for verbose options, "u" means unconditionally overwrite same name files, even if the existing file has a newer modification time, "m" means write back the original modification times that the files had when backed up, and "d" means create any directories needed for the files to restore. This will totally overwrite everything, unix and all, with the files from the backup. Once your back to the root prompt, reboot the controller: # reboot Your controller should be back to how it was when you backed up. Don't use this procedure to change controller types (eg: Polisy to eisy, or other way around) as some files would be different. We're talking about a backup here, not a migration. Also, if you're restoring to a different physical controller, the UUID of the old controller will not be carried over to the new one. The UUID is generated by the startup process, extracted from the controller's network card MAC address. Once again: this is for your information only, and use at your own risk, And...if something happens where you think you'll need UDI to help you, well this isn't the kind of procedure they support. Be ready to reflash your SSD from a image file they provide before getting them involved. On the bright side, I've done this a couple of times and it's worked well 🙂 PS: cpio is a great tool for copying unix directory trees, when multiple files and directories are involved. If you don't need to copy to a subdirectory to your current one, but rather to a directory above or beside yours. You don't need to do the two step directory list thing. Here is an example: suppose you're working on a plugin and you want to make a copy of all the files in it to a new directory as a backup, because you're about to make big changes to it. Let's say that your plugin's home directory is "/home/admin/workspace/plugin-dev/myplugin" and you want to copy everything in it to a new directory: "/home/admin/myplugin_save". Begin by creating the new directory you want to copy to: # mkdir /home/admin/myplugin_save Now position yourself in the directory to want to copy: # cd /home/admin/workspace/plugin-dev/myplugin Make sure you're in it, using the pwd (print working directory) command: # pwd Once that's confirmed, copy everything over to the new directory with the magic cpio command: # find . -print | cpio -pduv /home/admin/myplugin_save Verify that everything has been copied to the new directory 🙂

The new login in method is an option (makes going between admin console, PG3 and portal seamless). You can continue logging in using the previous way too, as long as the URL contains the port number (8443) as it always has. Good ole "admin" and your IoX password.

Sounds like a ghost node issue. I've seen similar effects with other plugins, where you create new nodes but haven't restarted yet.

I'd open a ticket with UDI before doing a factory reset. Can you see it in your router's connected device list?

I'd try a factory reset on the switch, then adding it back to your system.

Does detecting a single tap work? If you just create a simple program that looks for a control event (on or off) from that switch and do something like increment a variable, does that work? If that doesn't work either, it could be an Insteon signal issue, with the switch itself. Also, can you turn the switch itself on and off from the admin console?

No, they don't need to. The alternate login URL (without a port number) to the admin condole is a user convenience, giving you seamless access to the portal and PG3 without needing to re-enter a user id and password.

If that's the eisy-ui login screen (black background), then log in with your portal username (usually your email address) and password.

The current product (eisy) has all those modules built-in as standard. To use Zwave, you'll need to get either the ZMatter dongle sold by UDI, or get a Zooz 700 series Zwave stick, if you can find one.

Eisy-ui is still in development, and doesn't support editable things like scenes and programs yet.

I don't think that's possible. The plugin would have to obtain the value of a variable through PG3 dynamically. Also...what sets the variable? Usually that would be a program. Just have the program also set the offDelay time for the virtual switch.

Fair enough...you're wanting to keep it within the realm of scene commands. That's why we're brainstorming. Yes, I'm a program guy. If it weren't for the programmability, I probaby wouldn't be a UDI user! Nothing wrong with having the extra commands for programs either! 😆

Now trying out the toggle mode. I'm not quite sure what the "Off" button is meant to do. I'd tend to see it as needing only 3 buttons: Start, On, Off. Start starts the timed toggles, while the other two set the status to On or Off, just like a regular switch. A fancier version could have two Start buttons: Start On to alternate starting with the timed On, and Start Off to start with the timed Off. Just some thoughts.

No, I actually derived my explanation from trying it out, as a "black box" discovery process. That's what I figured would be a good independent verification, and part of trying to "break it" 😉 . I did see your initial description, though it's rather cryptic to someone not yet familiar with it: (On (DON) when ST Off/On, ST status set to TIMER, CMD (DON), after DUR (DOF)... I preferred to stick with a cookbook style explanation, using the familiar terms we see for IoX, which should help other people discover and use this meaningful addition to an already useful plugin! Thanks again! But the essence is that it seems to be doing what you intend it to do, and will surely be appreciated. I've been mentioning the Virtual plugin many times as a solution to some user's questions.

I'm checking out the various modes. This will be important for your documentation. Let me know if I have it figured out right so far: ondelay switch: The virtual ondelay switch has three possible statuses: Off, Timer, or On. The status of the switch will be updated to "On" after a set delay when it is first turned on by a On command (from a program or scene). During the set delay, the status will be "Timer". The delay in seconds is set by the onDelay parameter, and can be set as a fixed value, or from a variable value. The On trigger is control event based, and will retrigger the delay from zero if a new On control event is received while the timer delay is underway. So a series of On control events will delay the transition from Timer status to On, until the timer is allowed to run out without a new On control event. A forced off (FOff) control event will immediately cancel a ondelay switch that is in the timer phase to Off, or turn it Off if it's On. A Off command will turn the ondelay switch to Off if it's On. An Off command during the timer phased will be ignored. offdelay switch: has the same characteristics as ondelay, with the following differences: It has no On status. It will go from Off to Timer status if triggered with a On control event, and the timer can be retriggered just like the ondelay switch. Once the timer phase expires, it will go back to Off status. This is meant to be used to trigger the detection of it's status going to Off. I'll have to experiment more with the toggle to see exactly how it works.

Ok I figured out where the bug is. In the Controller.py file, the new options need to be added to the parameter validation routine: I now have it all working. 😀 Nothing like having new options. Thanks for keeping this great plugin up to date with new features! With the toggle option, we can now add turn signals to our eisy!

No, the trick is to add the new motion sensor first, with a temporary name. Then locate the one you want to replace in IoX, right click on it, and choose "Replace with", and select the new one you just added. IoX will do the changes needed in all the programs and device links to replace the old one with the new device, and unconfigure the old one, so you just physically replace it.

I'm trying this out, and not getting very far. I added one custom parameter to my updated Virtual plugin, but I get a "bad configuration" error when I restart it. Error log complains: Controller:_handle_json_device: JSON parse error for key '95' with value 'ondelay': Expecting value: line 1 column 1 (char 0)

It certainly is. I like discussing nuts and bolts. I'll certainly be giving your updated plugin a try soon, on my test controller.

Others have been reporting issues with Alexa plus. Someone mentioned actually calling Amazon and canceling it, and things got back to normal.

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.