Guy Lavoie

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.

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