Guy Lavoie

Well the version itself could always be fully capable, but could offer wizard style utilities for people who want to do simpler stuff like scheduled tasks or macros. A bit like the Alexa app from Amazon, which steps you through programming a routine. That could help someone get started. Then if they want to get in deeper, access the full programming screens. The mention of ipads in the case of Chris's friend Warren is another thing. I actually commented on this elsewhere, when it was mentioned that Apple Homekit support would be added. Apple users are more often than not non-geeks. They just want things to work without needing to go into technical stuff. This is where wizard like features might help with that.

Well, the more features and device support that gets added, the harder it is to create a dumbed down version. What do you leave out? I suppose you could have it just do macros and scheduled tasks...like a hub.

Any difference in range would probably be very minor. Zwave really depends on it's mesh network topology to get signals to devices that often aren't even in the same room.

Hopefully, they meant to say browser based...

Hah, naming devices for voice control has it's quirks. When you start to have many devices, finding good, unique names becomes a challenge.

My question is: how different will the look and feel of the new admin console be? For all it's quirks, we get used to them, so needing to relearn stuff is always a bit annoying. Will there be new console user features too? For example, it would be handy to be able to comment out program lines instead of always needing to delete them. New monitoring tools? Another thing that would be useful is a user log file that you can write to by program action. It would be handy to be able to do things like log the locking/ unlocking of doors, alarm activation, or for troubleshooting. It would be easier than needing to try to filter through hundreds of lines of the activity log. Just a few ideas.

That would be a unix version that eisy is running on. It's currently been 13.1 for most people.

I agree, and furthermore, the people developing the software shouldn't be the document writers! The usual problem is that they're too familiar with how it works, so they'll overlook stuff and can't always anticipate some of the questions that some of the users will ask themselves. I say that from experience. The Applied Digital Ocelot controller was a great little controller, but with gaping holes in it's documentation. The way the logic operates, order of precedence, etc wasn't properly explained. When they brought out the next major revision of C-Max (the equivalent of the admin console), they actually hired me, a user living in another country who had never set foot in their offices, to rewrite the manual for it. 150 pages later, it really made a difference, and they were very happy with it. It didn't happen by magic. I sent countless emails back and forth with the software developer, and we really figured out how everything worked, down to the size of the internal command output buffers, etc. and put words to it. That's the kind of thing that would need to happen with the eisy.

It often happens that you need to exit and log back into the admin console to see plugin related things, especially if you made a configuration change to the plugin.

Normally yes. https://wiki.universal-devices.com/Eisy:User_Guide Scroll down to zwave

The two connectors are for the zwave and zigbee antennas.

No, the 300 or 500 zwave board in the older ISY cannot be used with a eisy. The eisy uses either a Zooz 700 series dongle, or the Zmatter board, installed as a USB device.

Aren't Zigbee rf frequencies also different in Europe?

Both run exactly the same version of IoX, so it's not really an "upgrade" in that sense. You would gain a more recent version of the UDI product, with a longer time where it will still be supported. The Polisy could then become a backup just in case... It's your judgement call. I actually bought a used Polisy just to use it as an experimental platform, and to use for learning to write plugins. It's also a backup unit, though some things would still be a bit of a hassle, such as needing to buy any paid plugins again and transfer (if that's possible) the portal subscription.

It's actually a mPCIe card, not nvme (my mistake). There was a thread somewhere explaining that you needed to snap off the tail end of the card to fit it in the enclosure. I agree, just use it as a USB dongle on the Polisy.

Though it's actually the same card, so it could probably be taken out of the enclosure and installed inside the Polisy. But I see no advantage in doing that, other than aesthetics. The USB enclosure was sold separately, for someone moving from a Polisy to a eisy.

Yes, two antennas. One for zwave and one for zigbee

Which would make sense because you have to manually put it in linking mode, contrary to line powered devices that you can link by just entering the device id. However, how would links get written into it?

The advantage would be the added zigbee functionality, as well as the upcoming Matter support. I think you would also get a better security protocol (S2) on the zwave. The Zmatter board can be installed inside the Polisy, or added externally as a USB dongle. The eisy only the supports the dongle option.

What is a "RL"? A Keypadlinc? If the scene isn't triggered by that same keypadlinc (sounds like it isn't) then you can make the keypadlinc a responder to the scene that controls the light. I have a few keypadlinc buttons that get updated that way, so that they are always in the correct next toggle mode. If the keypadlinc is also controlling that light, then you need to create two scenes: one with the keypadlinc as a controller and the light as responder, and a second scene where the roles are reversed. In my naming scheme, I have for example "Scn table" and "Scn table rev", where that second one updates the keypadlinc button if the light was turned on other than by the keypadlinc button (could be the switch itself, a program, even another keypadlinc).

I've just been reading through the whole thread for the past hour. Sounds like there is something fundamental that changed in the execution logic, when it went from a standalone program to one that runs as a unix application. It also reminds me of my own thread about how the execution order is "unknown", which could do crazy things, especially if the order is not only unknown, but possibly different from time to time.

If it ain't broke, don't fix it.

For zwave, you'll need a network of devices if you're looking to get reliable communications over a house that has many rooms. Also, battery powered devices like door locks will not function as signal repeaters.

The zwave standard has it's own version of "scenes"... that the eisy doesn't support. These would likely be used within a zwave only system, where devices communicate directly with each other. This is similar to how the Insteon spec also allows direct device to device links, but the eisy doesn't use those either. Indeed, the idea of a controller like the eisy is that it wants to include itself in every link, so that it can track device status for making program logic decisions. So it tends to treat devices as slave devices only; as inputs and outputs. It does support some of the more useful features of zwave devices, like the errors or status conditions that can come from door locks.

The ISY language operates more like a simplified multitasking operating system than as an application. The "applications" are the individual If/then programs that you create, as well as monitor the input/output devices it can receive and send from. If you ever programmed in VB6 and created routines that send and receive data through sockets or serial ports for example, then you know that you had to sprinkle "DoEvents" commands in your code that sent data and waited for received data, to allow the operating system to do those and other tasks as you program waited for the next event. DoEvents releases control to the operating system so that it can scan for the possible events. In the ISY, it evaluates the status of each If/then program, to see if the next step is due. If so, then it initiates it...and keeps monitoring the rest of the system.