bhihifi

I have some buttons that control scenes not turn off even when the scene is turned off from a voice command or from another controller scene member. I fail to fix it because I don’t remember how to duplicate the problem. You want a mutually exclusive set where each button is a responder to the inverse state of the active button. So after each button is a scene by itself, turn the other scene(s) off when another scene is on. You could use a single subprogram that you run as part of each scene’s main program to clean up the other buttons using a single state variable or argument specifying the desired active scene. You could use a series of if-then statements to mimic a case statement conditional on the active scene.

If I understand you correctly, the HA system is the signaling and status interface but the real control lies in your EISY setup. I'm not well-versed in mutual exclusivity but you can implement this in EISY program logic with conditions and state variables. May not be as fast as having mutual exclusivity within the switch itself, assuming that this was also an option. As an exercise, I would actually draw out my desired states and actions in a flowchart first to see what I want to have happen, then figure out the implementation that created the least dependency on hardware features.

Following. I'm here to learn but sharing some thoughts which may help. I wonder if you may be setting yourself up for future issues with multiple control points. Although you may have good reasons for doing this, as a former real-time software developer, I would anticipate situations that might be difficult to troubleshoot between systems, especially with timing and status updates. Others who run multiple control systems for years may disagree. In that case, I'm here to learn. You may have a lot of time and effort invested in the Home Assistant setup and the porting of all of that to a different platform will seem redundant and time-consuming. If I were implementing this, I would keep all of the scene and device control elements on one platform, and use the other platform just for signaling (requesting action by setting variables or flags) and displaying status. Then you isolate all the decision making to one place and only have to troubleshoot the signaling.

@CJVann There may also be an upgrade or discount code to buy the Polisy if you already own a 994i. You may have to search on this forum to find it.

Many of the advantages of Polisy are listed above; I'll only add a few that I found useful. I purchased the Polisy Pro, because I wanted the flexibility to install without Ethernet nearby and the ability to use both serial and USB (wireless and plug-in) PLMs. I ended up installing near my router, so not using the WiFi. It also has a multiport Ethernet switch built in so if you needed to expand your wired network it works well. My main router does not have extra ports, and I would have needed a switch for a wireless access point which I was able to connect to the Polisy Pro.

If controlling Z-wave devices, devices only "include" with one controller. You would have to start from scratch anyway with Z-wave migration to the Polisy from the ISY994i by excluding all the devices from the ISY994i then including them with the Polisy running IOP. You cannot control the same Z-wave device simultaneously with both controllers. Make a backup or two of your ISY 994i before you do anything. This can get you back to where you were before the Polisy if you ever need to. You can pre-load Polisy with the Insteon link tables from the ISY994i using a migration process (described in detail elsewhere on this forum). However, you are either going to control an Insteon device from one hub or the other, not both. If you have 2 PLMs then you could move a few devices at a time off the ISY (meaning delete them from the ISY's link tables) to the Polisy, test, then move some more. If you have only 1 PLM then you're going to be restoring the PLM each time you swap controllers. Back up each controller each time you make a change that works so you have a known starting point for the next change.

@apostolakisl I understand your predicament. Being new to this, I take the belt and suspenders approach. My extra caution is due to prior experience in writing real-time embedded system software. Anything that relies on timing will screw things up. If the status condition is supposed to indicate the recent past then your view of this difference with IoP as a bug makes sense. Curious to learn what UDI will say.

@apostolakisl Sorry your reply crossed my edit. You might eliminate timing issues with a state variable.

@apostolakisl Try re-sequencing the “if” clauses so the switched off is the first condition: does behavior change? I predict that it will not. I believe the clauses are evaluated sequentially but the status changes before your switch is detected so the first condition goes true even when switching off from on. Polisy executes faster than a standalone ISY so you may have a timing issue for your first two conditions. What you want is to know if the switch was off when switched off, but the status may update too quickly to use it directly. Perhaps a state variable could help here. It would change when switched off or on, but only after a slight delay.

@DaveStLou Alas, it won't be the last belt & suspenders solution in your HA setup. I got the MyQ before I got the Polisy so I was happy to have the MyQ app just to avoid the "I drove away and can't remember if I closed the door" issue that inevitably resulted in returning home to check and annoying other passengers ;-). I've been thinking about the same issue and the only other option would be to Force Query in large time increments (every 10 minutes?) and hope that it persists long enough when you need it.

@lilyoyo1 A state variable set in another program if status is on and then polled in the timer program? Do you reset the state variable after the interval?

I bought an Insteon 2448A7 USB dongle on eBay. Since the Insteon shutdown it is possible they took the listing down, but you might want to contact the seller chabaut_58 to see if they still have them. The dongle works well with the Polisy.

The 2413s can be repaired by replacing some capacitors. Deploy the U and fix the S. If you don’t want it, I will gladly take it off your hands.

@DaveStLou If you had a motion sensor monitoring the driveway, it could trigger the Force Query, then if the GDO was activated (such as when the driver uses an RF remote), you could know sooner that the door was opening without polling the MyQ service. But will the motion sensor trigger fast enough to make this work well? I'm going to experiment with an Insteon sensor to see. I seek a way to turn outside lights on when the garage door is opened at night. Coming from inside, the program is not really needed since the outside light switch is next to the GDO control. I only need to have them switch on if opening from outside after dark, so the motion sensor might do the trick. Of course, you could have the motion sensor turn on the lights regardless of the GDO, as a safety measure, in which case the GDO status does not matter. I also implemented a turn off timer program to switch off the outside lights after 10 minutes so they don't stay on all night if someone comes home and forgets to turn them off.

@DaveStLou Have you thought about what happens if the door is opened using the GDO wall keypad or the in-car remote? These openings don't come from an app or program so I wonder if you can have the same actions triggered when the door is opened another way and still do a Force Query first.

I bought one to use with IoP. I made an offer of $34; the seller accepted. It will perform better if a dual band device is nearby. Wired PLM works better if you have a lot of electrical noise in your house wiring.

I spent entirely too much time going down this rabbit hole, trying to make my Z-wave devices show associations. I have several devices from various manufacturers (Jasco, Linear, Inovelli) that all claim to support associations based on the controller and none of them expose associations as a feature. I don't plan to use Z-wave association scenes because of the need to manage dependencies at the device level. For me, scenes with Polisy/IOP are more maintainable and the dependencies more explicit. Other than the possibility of faster response, I don't fully understand why a Z-wave association might be preferable to an ISY scene built in the admin console or a program that accomplishes the same effect.

I have the Linear/Nortek WD1000Z-1 dimmer whose documentation states that it supports Association (see highlighted section on page 2 of the attached PDF). Below, I have a screen shot of this device added to a scene with another Z-wave on/off device, showing the command button and pull-down menu. There is no Association selection. Based on @Michel Kohanim's post above, I would expect to see Association in the pull-down. Linear (Nortek) WD1000Z-1.pdf

@asbril The following updated everything to versions listed by @vbphil: sudo pkg update sudo pkg upgrade sudo service udx restart sudo service isy restart I'm becoming a sudo intellectual.

@asbril I ended up doing another set of ssh commands because some of my versions don't match what @vbphil posted. We'll see. My question for you was because you had 5.0.4 in your post.

@asbril Are you sure it's not 5.4.0?

This worked for me. I restarted from the ISY Finder which found the Polisy, and all my devices showed up. Polisy v13.0.

@Geddy Thanks for this and for all you do.

@Michel Kohanim Is the single button press the best way to upgrade? Sent from my iPhone using Tapatalk

I have an assortment of Z-wave devices already installed and don’t know if they support network inclusion or not. Because they are all currently included in the Ring Z-wave network, should I delete them all from Ring before adding them to my new ISY Z-wave network (in order of increasing proximity)? Sent from my iPhone using Tapatalk