MMAltair

Thanks to Andy P for putting this guide together, it was quite helpful. One additional thing I figured out is that on my cell phone the mac id is randomized by default (I have a Samsung phone). This feature can be disabled in the phone settings, with some loss of privacy, and needs to be disabled for the Unifi Presence plugin to work. I don't know if this is an issue with iPhones. Another thing I did is create a Unifi Controller admin login (I have the Dream Machine Pro so the controller is integrated) specifically for the Presence plugin and gave it "view only" rights and "Local Network only" connection capability. No point in giving it more access than is required for the job. Mike

@tazman I started down that path at one point but for some reason changed direction. I'll try putting the buttons in Scenes, all by themselves, and then see if I can control them with the programs. Thanks!

The way I have it implemented now the programs provide the mutual exclusivity when each one executes. This works for everything except for the button LEDs. When I tried including the buttons in the Insteon scenes the lights (the actual lights that are part of the scene) get set correctly but the button LED of the previous scene remains lit when the new scene is activated. For example, let's say there are 2 scenes, each one controlled by a keypad button, one scene is "TV" and the other scene is "Conversation". If the "Conversation" button is pressed the lights in the room get set to level that supports people conversing, playing games, etc. Then the user changes their mind and decides to watch the TV. This requires the lights to be dimmer than conversing so they push the "TV" button. This causes the TVe scene to to be activated, which sets all of the lights in the room to a dimmer or off level, but there are now 2 buttons illuminated on the keypad even though the "conversation" scene is no longer active. When the activity is over the current scene button is pressed again to revert the lights back to there normal behavior. (the actual implementation is far more complicated than this since the "normal" behavior of the lights in this room is controlled by occupancy, time of day, security system armed vs. disarmed, etc). This is another reason for the programs, if a lighting scene is active this overrides the automation of the lights. To get around the mutual exclusivity of the buttons issue I have to press the button for the currently active scene, which turns it off, then press the button for the new scene to turn it on. This is workable but not very family friendly. Hopefully this makes more sense now.

@bhihifi Thanks for the reply. I do use EISY (ISY) for all of my control programming and only use HA as a graphical interface to EISY. With Insteon "scenes" are the way to go for quick responding lighting scene changes and in this case I do have Insteon scenes setup for the different lighting scenes. I need to figure out this mutually exclusive button issue.

I need advice on a 6 button keypad usage scenario. The 2 main buttons are used for triggering a program and are set to mutually exclusive mode, this works fine. Of the other 4 buttons I use 3 to individually trigger programs that control mutually exclusive lighting scenes and this is where I need advice. I know that I could set up individual scenes for the lights, including the buttons but this doesn't work for me since I also control these scenes with Home Assistant which requires that I use programs. The programs also enforce the mutually exclusive requirement for HA and they control variables that affect other program functions. In the Insteon switch setup (I use EISY) there is a dialog where you can make buttons mutually exclusive but this doesn't seem to work. My goal is to only use the 3 buttons as program triggers, with the button LED reflecting which of the 3 different scenes is active. I would also like the button LED to reflect the current lighting scene if initiated by Home Assistant. Is this possible or am I going down the wrong path?

I read through this thread with great interest since I have new Bali Z-Wave shades and was planning to connect them to EISY/Zmatter. I purchased the Bali ZWave controller and have the shades connected to it currently but would like the additional flexibility/control that EISY provides. Here are my observations on how things work with the Bali ZWave controller - - Using the Bali Zwave controller with their App there is no way to group shades together for simultaneous control. The App allows you to control each shade individually where they each move independently. Moving the shades to an end point is not a problem since they will all end up at the end point eventually. You can also have the shades go to an intermediate point although this is not a precise point since it is controlled by a slider for each shade. - I connected the controller to Alexa which works fine but is similar to controlling the shades with the App. To get the Shades to all move as a group I have to add each shade as a separate Action in the associated Alexa Routine. When the Alexa voice command is issued each shade (in my case 4) start moving at different points in time and eventually go to the same end point. It looks a bit weird while moving. Alexa routines do allow you to specify a % open which works quite well. The Bali App does not allow a % (just an approximate slider position for each shade). - I also purchased the premium remote with the shades and it has different behavior than the Gateway/App. The instructions are very explicit that when you add the remote it has to be added after all of the shades have been added (paired) to the Controller/Hub. The process for adding the remote is to first pair it with the ZWave controller/Hub and then pair it separately with each shade. Once each shade has been paired with the remote you can then create "Channels" in the remote to "associate" shades into groups. The remote then issues commands to individual channels where all shades move and stop synchronously. In my case I have 10 shades and 3 channels, 2 channels of 4 and 1 channel of 2 shades. Based on RPerrault's description of ZWave Association, I suspect the remote is being added to each shade as a secondary controller which supports the ZWave association function. I also suspect the ZWave ControlIer/Hub does not support the Association function since no grouping of shades is possible in the Bali App. I should add that you can purchase the shades without the ZWave controller and only use a remote to control them. In this case it is likely that the remote is the primary ZWave controller and still includes the Association function. At this point I haven't decided if I will transition the Shades to EISY based on the experience RPerrault described in this thread. I'm well aware that I can write programs to create the virtual groups Scenes) of shades but with the underlying problem of issuing commands over a spaced out interval of time. If I decide to give it a try I'll report back on the status.

I'm back trying to get EISY/ELK integration closer to how it worked on the ISY994. Is there a way to start keypad beeps on specific ELK keypads with the ELK node server? I find it useful to turn on Keypad beeps along with a periodic voice announcement to get people's attention to urgent conditions such as a water leak detected or a door left open. If this isn't possible I can always resort to the Output method of communicating this situation between EISY and ELK. Thanks

Thanks for all the advice. I finished the transition to the ELK node server on EISY and it was mostly uneventful although a substantial amount of work (lots of programs to modify. It seems the one big difference between the ELK node server and the integrated ELK support on ISY994 is the support of the keypad function keys and their associated lights. I use the function keys quite heavily to provide a quick and easy way to change behavior in the system (the ELK plus EISY system). For example I have a program function that monitors the garage doors and if they are open too long a warning is announced through the ELK system. This behavior can be modified by pressing a function key to disable the warning for an extended period. I can solve this problem by adding a tracking output for each function key to relay this information to the ELK node server for use by the EISY programs. Not a huge issue, just extra work. Thanks again!

It must have been busy and ignored the button presses. I'll try again after bit. Thanks!

Power cycling EISY worked. Thanks! I tried rebooting it but that didn't resolve the problem. Also, I tried the 6 button press to power down EISY gracefully but that didn't work. Is the button press functionality suppose to work? Mike

Not sure if this is the correct place to post this but here goes. I migrated my ISY994 to EISY today and overall things went as expected but I ran into a problem with PG3. PG3 seems to launch properly but when I try to login with admin, admin I get an "HTTPS 408 error, Request Timeout". I have not changed the EISY password from the default yet so PG3x should still have the default password. Any ideas on what to try next?

Thanks for the pointers. I will use the Notepad trick to make a copy of my Programs ahead of migration. My thought on using PG3 on RPI was to do the conversion of the programs to the PG3 Elk node server on the ISY994 and then make a backup to use for the migration to EISY. This way all of the ELK node server modifications would be migrated to EISY automatically. Not sure if this would work.

I just purchased an EISY with Z-Matter to start the transition from ISY994 for one of my two residences. Both places have ISY994 systems, ELK M1 systems for security, Insteon for lighting, and Z-Wave for smart locks. I'm looking for a little guidance on migrating the ISY994/ELK systems to EISY. I have extensive integration between my ELK systems and the ISY systems going back many years (back to ISY99) and typically using ISY programs to interact with ELK through ELK Output semaphores (both directions) and by monitoring ELK zones, Arm States, etc. Since EISY lacks the ELK integration I know I have to migrate everything to the ELK PG3x node server but don't know the best way to go about this. Questions - - During migration of the ISY994 backup to EISY do the ELK related programs migrate with place holders for the unsupported ELK integration from ISY994? If not I need to figure out how to maintain a reference to the programming that will be lost during migration. I saw on another thread that it is possible to have ISY994 running at the same time as EISY on the same network which could provide a reference to guide the manual program updates on EISY. Is my understanding correct? - Would it make more sense to get a PG3 node server running with the ISY994 system and do the program updates to ELK PG3 before the migration to EISY? Are there any downsides to this approach? (I have a PG2 node server running on an RPi but have not updated it to PG3) Thanks in advance! Mike

I just saw this thread and thought I would respond with my experience. I've had two 6-button Switch Link switches exhibit this behavior in the past year, both after having worked fine for years. In both cases I replaced the capacitors in the power supply section with new caps ordered from Digi-Key and that fixed the problem. If you're handy with a soldering iron that may be the solution.