Guy Lavoie

Interesting. Could this in any way have affected UD Mobile in local mode? Earlier this morning UD Mobile wouldn't connect, and give me a "no proxies available" message. To get to connect I had to go into settings and re-enter my admin password, or so I thought. Coincidence or related? My question is: does UD Mobile need to be able to see anything external even if used in local mode?

It's not really about the feeling of abandonment, but about trading away known reliability for something new that has yet to make us feel as confident.

How do you think I feel about my 25 year old Ocelot controller, that's never missed a beat? It's like an old friend. It's still running a few things, like my solar pool heating. One of my projects is to make a PG3 plugin for it, so I can keep using the relay modules and other features. Right now I do that with X10 commands, not the best way. I've already tested serial communications with it from the eisy in Python. So it's just a question of getting it done.

WAF...there's a term I haven't seen in a while! In that regard, I think that voice control has been a game changer. Given how they like to have "people" do things on command! But seriously, my legally blind wife has finally found a benefit that really suited for her, by not needing to walk to switches, remember which one does what, etc. Also loves Alexa as a kitchen reminder, talking clock, temperature and weather source, etc. Home automation has also evolved beyond the geek only image it had 20 years ago, and is becoming mainstream, just like computers did with the internet. even my 88 year old mom has Alexa and a few smart plugs to turn on lamps. If you only need that level of control, then there is no need for the full blown controller. We need to recognize that.

I might add that an alternative to making this mod would be to use only external magnetic contacts (wired on series) connected to the screw terminals, and mount the open close sensor module itself nearby, but with no magnet near it. This would leave the internal reed switch open, allowing just the external wired ones to work.

That's the very first thing to check. If you have a spare device that was never added to a z-wave network, try adding that one first. If it works, that would pretty well indicate that this is the problem. To know if your eisy is seeing the adapter, in admin console, go to z-wave -> advanced -> z-wave information. Check that it says "Connected".

I already had a few of these on doors and just got some more as part of a lot I bought, so I thought I'd add some to windows now. I have several windows that open as two separate panes, so I thought it would be convenient to use the external sensor option on the modules to monitor both panes with one 2843-222. I want to get an "open" condition if either pane is open. These modules have two screw terminals to add an external set of contacts but upon reading the documentation, the screw terminals are in parallel with the internal normally open magnetic reed switch. This means that both window panes would need to be open to have an "open" condition. Hardly useful, especially with most magnetic reed switches being open when no magnet is present. So I looked around on the web for a modification to have the switches in series (surely, I can't be the only one wanting this!). I didn't find anything, and the Insteon support forum has been down for a while. So here is my own little mod to get this functionality. It involves cutting a trace, cutting one lead of the reed switch, and soldering in a wire. Dismantle the circuit board from the case (remove two screws) and turn it over to see the underside. Position it vertically, with the negative battery terminal at the bottom. Be careful not to break anything when sliding the negative battery terminal off the plastic mount. Step 1: Cutting a trace. Ignore the yellow wire for now. On the underside you will see one trace going from JP1 to the screw terminal on your right. Cut it near the screw terminal using an xacto knife or something similar. It's a good idea to verify that continuity from JP1 to the screw terminal is indeed cut, using a multimeter. Step 2: Cutting reed switch lead. Flip the board over to see the component side (with the screw terminals still at the bottom). Cut the top lead near where it enters the hole in circuit board, then bend it a bit, towards the center of the board. Because the reed switch is now held to the board by just one lead at the bottom, I put a small dab of hot glue to help in keeping it in place. Step 3: Adding a wire. Add a small wire (I use wire wrap wire) from the screw terminal that was isolated in step 1 (that's the yellow wire), through a hole, and solder it to the free end of the reed switch that you bent towards the middle in step 2. Don't go through the screw hole! There is a convenient smaller hole near JP1. That's it! Now, both the internal reed switch and an external switch (or several, in series) are in series and have to be closed to get a "closed" condition. If you ever need to use this modified module without an external sensor, now you'll need to put a small jumper wire between the screw terminals to bypass the missing external reed switch. Put it back together and enjoy.

Ah yes, the "use a bigger hammer" approach. Works as a short term solution, but will leave you unsatisfied over the long term, and cynical about the technology. As Paul said, the real solution is to try and work out the communications issues by testing, making small fixes or changes and observe if it improves, by not using the programming workarounds that you have added. Are your devices dual band? Are the ones that aren't reliable in an isolated location, where signal strength might be a problem. If you put other types of Insteon devices in the same area, so they also fail to respond? Sometimes, just adding something like a lamplinc to act as a signal booster/coupler helps. All things to consider. The Insteon support forum also has good suggestions, though it appears to be down, has been for at least a week.

Yes, and the learning curve is quite steep. There is little or no tutorial information, it's mostly just reference material. The way to learn for most (including myself) is to install a simple plugin, and reverse engineer it to try and understand what does what. So far I've done two simple plug ins, mostly as an exercise to eventually make a more complex one. I'm also learning python at the same time. It's rewarding, but consider it mostly as a hobby, if you're counting the time you're putting into it.

The currently installed firmware version will remain. I've factory reset a ISY994i with a 300 series Zwave card and it didn't cause any issues.

So the second scene did the trick. In my naming convention (to avoid going crazy) I'll usually give the scene a name (eg: "scn kitchen") for the scene where the keypadlinc controls the light, and "scn kitchen rev" for the reverse scene that updates the keypadlinc if the light is operated directly from the switch.

The networking module comes by default with the eisy. Not sure about the Polisy.

Did you create a second scene with the on/off switch as the controller and the keypadlinc button as a responder?

Well since 14.1 seems to be part of the promised January upgrade, I'll just wait until it's announced (and let a few early adopters dip their toes first). Maybe UDI will streamline the process too. I'm in no rush.

If I log into my eisy with ssh and do the unix command "uname -a", I get: FreeBSD 13.2 release p11

Well turning on/off keypadlinc button backlights isn't something distinct or particular, it's just a regular Insteon device as far as commands go. You're controlling a light. I'm grateful that Insteon designed-in the capability and programmability that the keypadlinc has. The toggle mode would really be annoying to use if there was no way to keep a button's next on or off command in sync with the actual status of the device it's controlling. Now not only is the next button press always correct, but you also get a visual indication with the backlight. I love it. Yes, I've done scenes similar to "all off". My previously mentioned kitchen lights are a good example. I can (by programmed Insteon commands or Alexa) I can control individual lights, I have a kitchen scene that control all 3 together, a "back of the house" scene that controls those 3 lights plus two others, and a "ground floor" scene that controls those and every other light on the floor, which gets turned off when I arm my alarm system. The beauty with Insteon scenes is that the response speed stays the same, whether you control 2 lights or 20. The multiple link system can appear to be daunting at first, but it is very well thought out.

Yes, that should solve your need. You can keep it simple because there is only one way to turn on the fan. When you have more than one trigger, such as a 3 way setup, then you need to create a second scene that gets triggered by that alternate switch so that it can also "turn off" the keypadlinc C button. I actually call those scenes "reverse" scenes. The alternative is to use a program, as you have done. A program will work fine if it's a single device like the fan that is being controlled because you can watch it's status with If statements. If there are multiple devices though (I have 3 switches in the kitchen that often get turned on and off as a scene, but can also be controlled individually) well there is no "If scene Status..." command in IoX to trigger on. That's where the virtual switch comes in. I have the virtual switch turned on and off as part of the scene, but it can't get turned on manually... So now my program can watch the status of that virtual switch to keep the keypadlinc button correctly lit or not. Keypadlinc buttons are great in toggle mode, but need a bit more programming to keep in sync.

The way I do that kind of thing is to have the button turn on a scene, and include a virtual switch in the scene (use the "Virtual" plugin to create the switch). Then have a program that looks for the status of the virtual switch getting turned on, waits 1800 seconds (30 minutes) then turns off the button and virtual switch.

That goes for most plugins where you configure it by making parameter changes or doing some type of discovery. You need to exit the admin console and log back in to see the results.

Yes, that's the idea: to redo the variable reference. I still have your mention in the back of my mind that this worked fine on the ISY but not on the eisy. This problem potentially popped up between the two. I'm looking forward to hearing how it goes this evening.

Well that should be easy to troubleshoot, if it's repeatable. One thing: In both the program(s) that sets the variable, and the program that looks for it being set to 1: edit the program, select the variable again from the list (as if you were selecting another variable), click on update to save the line, and save the program. I've seen odd stuff happen with variable references looking right but not working. It could be an admin console thing.

Well yes, because most of the people who take the time to visit the forum regularly and reply to questions are enthusiasts by definition. I'm actually pleasantly surprised by the balanced responses I see from many of them, saying outright that if all you want is to control lights from your phone and schedule a few routines, the eisy might be too much for you. Maybe we just don't want people getting in over their heads and then whining that it's too complicated! There is a learning curve. But it brings many rewards...if that is what you want.

Somewhere in the middle of that range of users are the hobbyists. Those, like me, who automate things just for the pleasure and challenge of doing it. Those who have more fun getting it working than using it once it's done. It's hard for us to give an unbiased opinion because we tend to give much more time and effort than "worthwhile" to getting some things working. The person who just wants it to work will find that they don't want to put anywhere near that kind of commitment. And that's ok. It's not all or nothing. I think it's just honest that we recognize ourselves and such and don't push too hard on someone who isn't like us.

Why? Too much to maintain? Does having local control have value for you? With an Insteon hub, you'd only have Insteon capability, which might be ok if that's all you need.

- A product that stops getting updates is a dying product. As Paul just mentioned, the eisy is getting a well anticipated update just next month. That's a good sign. - Not being vendor specific allows the eisy to evolve with whatever promising new standard comes out. No single platform seems to have emerged yet as a defacto standard. As your own post says, they all have their merits. Maybe that's not such a bad thing. Some seem to be good for low power, low bandwidth applications, others for versatility (eg: scenes in Insteon) I just switched from X10 to Insteon, and I'm quite happy with the performance. I also bought everything used, keeping costs down significantly. - Currently, voice control is a big thing, and acts as a unifier in some ways (how many products can you count that say "works with Alexa"?). - Matter, is it the next big thing? Well, UDI will be supporting it, so they're staying ahead of the curve. Only time will tell. The use of wifi in products will only be growing, and the Thread component of Matter is basically adapting wifi for use with home automation devices. I think that the attraction of the UDI controller for us is the programmability and expandability (with plugins). It's not a simple consumer product, just like Visual Studio isn't for the casual computer user. If you're getting a controller like the eisy, it's because you already know what you want to to with it. I find it to be a very good single-box solution for people who want full programmability, without getting into hand editing drivers, config files, etc.