Guy Lavoie

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.

If you ever find such a device, it would need to be controlling a load that can allow some current to leak through when it's off, to provide power to the module itself. That was the main characteristic of incandescent light bulbs. If you only have one or two such loads, then you might consider (don't shoot me...) an X10 switch for that, and you would need to have either an incandescent bulb as a load, or one along with the newer low power LED type lighting. Not likely to happen.

If the switch has 3 screws terminals (not counting the ground screw), then it's a 3 way switch (possibly just being used as a 2 way. But you would need to explain each cable, with each conductor going where. For example: 1- cable A with white and black conductors, white connected to white of cable B, black going to "common" on swtich 2- cable B with white, read and black conductors. white connected to white of cable A, black to black of cable C, red to switch terminal 3- cable C with white and black conductors. going to... That kind of detail.

Switches and modules don't store programs. They only have links to other devices, including a PLM that can be used by a device like the eisy to do things. A hub could also store scheduled events.

You need to indicate which wires go to which terminal. Are you counting the ground screw as one of the three screw terminals? Let me guess what you're saying here (and correct me if I'm wrong). 1- There are three wires actually going to the switch: a red and two blacks, and the two black wires are connected together. 2- No white wires go to the switch (this sounds different from your first post), the two white wires are simply connected together and taped up. If (and only if) that's right, could you try measuring the voltage between the white wires (you'd have to remove a bit of tape) and the black wires? Do you get 110 volts, no matter if the switch (and light) is on or off? If that's right, then measure the voltage between the white wire and the red wire. Do you get 110 volts if the light is on and 0 volts if it's off? That's a lot of ifs..

Well if you view it in the admin console, what does it show for "mode"?