xlurkr

Thanks. Picked up some remotes and open/close sensors.

From the manual. I don't speak z-wave, so I don't understand it. -Tom

I am fooling around again with a very old Monster IWC600 z-wave scene controller on my Vera, and the behavior is similar. It has 4 buttons, and they have mutually exclusively lit LEDs. The idea is that there is always a scene selected. Maybe that's what they were going for with the Zen32. To turn something off with the Monster controller you have to make a direct association with the button. If you do, the second press will turn off the associated light. The second press of any button also reports a button 0 push for each of the 4 buttons meaning, I guess, that the scene hasn't changed. Or something. -Tom

Except for whatever capabilities/features UDI decides not to include in ISY on Polisy, and for which no simple and/or complete alternative exists. That's why we're discussing Elk now. Also, wouldn't this be the ideal solution to the "multi ISY/one interface" scenario asked for by those individuals who automate more than one property (assuming they can set up a VPN or secure port forwarding)? I'm in that boat now, on a long-term remote work assignment. An ISY NS would also support multiple Polisys at multiple locations now, and after the 994i is completely dead. UDI ought to care about that. I'd be OK with someone in the crowd creating the NS I seek. UDI certainly has demonstrated that they'll work with NS authors to get them whatever they need. -Tom

Thanks. I'm aware it could be done this way, but I was really hoping to hear that support for a 994i would either be built in to ISY on Polisy, or that someone would create a NS. Easy for me to say, but it shouldn't be very hard or risky, since the protocol is well known, and completely under UDI's control, as opposed to many other devices you might attempt to add to Polisy. And such a NS would ease the transition to Polisy for those who want to add control but not disrupt anything in place. In fact, I'd argue that UDI should write and maintain such a NS themselves. -Tom

How does ISY on Polisy interact with a 994i? That's the question. If I want to migrate everything over to Polisy, but leave Elk lighting running on a 994i, how could I interact with it? -Tom

@Michel Kohanim I understand. I sure hope "full featured node server" means lighting is supported. As as of PG3 it probably won't be free anymore, but one can only mooch for so long, I guess. I might keep a 994i going until Elk is fully baked on Polisy. Which begs the question: what's the plan for anyone who wants a Polisy to control a 994i? Nodeserver? Who is going to create it? NRs? -Tom

Thanks, but I just think it's going to be complicated. On the 994, you can export a list of your lights that the Elk can read in, and you're set, once you fill in the Elk details in the AC. Both platforms listen to (or subscribe to, or whatever) each other and the lighting states keep in sync, and you can trigger rules on the Elk based on lighting events. And this functionality doesn't require the Elk module; it's free and built in. I'm not sure that exporting a list of lights is within the scope of what a NS can do, but if it is, maybe lighting support isn't so unlikely. But then how high of a priority is it? The lighting is already fully accessible in ISY, right? So goes the logic. Supporting Elk lighting is also a way to keep X10 alive. -Tom

Also, I think you'll lose the ability to control ISY lighting through the Elk (e.g. keypads, phone, etc.). I'd like to be wrong about that, and it doesn't matter anyway if you're not doing so already. -Tom

Because I always forget about it until after I've manually entered them again. Nothing more than that. I just didn't want to vouch for a recovery process I've never actually used. -Tom

A couple of days ago my Polisy spontaneously restarted - I heard the chimes. It was probably due to a power glitch I observed at about the same time. After that, not only couldn't I access its ISY via the Finder, I couldn't add it back after deleting it. Another reboot seems to have fixed it. I also have a 994, and it was also unreachable, but after I rebooted the Polisy, I could reach them both. Weird. And like carealtor, I've always had to add the Polisy, though Finder can usually find the 994. Lesson: keep those URLs handy so you can manually add them to Finder whenever you need to, which might be often. There is a save button, but I've never used to recover the addresses. -Tom

As an outsider, let me just comment that this could serve as a textbook example of thread drift in the future. Pretty sure there's no connection between the 300 series dongle and COVID. -Tom

I don't know how I missed that Michel misspelled Insteon in fix #1. I guess the love affair is truly over. -Tom

Glad you tried! I would have been afraid to. Yet another option for moving forward. I have one of these sitting in a drawer. This plus Polisy on WiFi= one outlet (and it could be a noisy, signal-sucking one), no hardwired network port solution. Probably just what somebody needs. -Tom

I moved across country for an extended work assignment, left my ISY at home, and took my Polisy with me. I bought a USB PLM from Smarthome and the combo is my only means of automation in my rental here, controlling a couple of LampLincs and an ApplianceLinc. I'll be adding some Door/Window Sensors soon. It may be alpha, but it's stable enough to control my small environment here. When you connect via the Java Administrative console, you'd never know the difference. -Tom

Sorry, I've been away from home for a while, and will continue to be for a while. For anyone joining this thread, keep in mind that I'm still using the 300 series dongle (though I have the 500 series in a box) and am on 5.0.16C. It works well enough for my needs now, but someday I'll upgrade and see if I can enable more functionality. At this rate, it'll probably be with the upcoming 700 series dongle on the Polisy, though, and not the ISY. -Tom

Thanks for helping. My ISY is on the other side of the country. I just want to delete the nodeservers on my Polisy, not connect to an ISY. I deleted my ISY's address from the Polisy just now, and I get an error Invalid URI "http:///:null/rest/profiles/ns/1/connection remove/" when I try to delete the 1st nodeserver on the Polisy by clicking the Delete button. I assume that's the Polisy attempting to remove it from the ISY. But it doesn't actually delete the nodeserver from the Polisy, which is my problem. -Tom

I moved and took my Polisy with me, but left my ISY behind. My plan is to use it to control Insteon at my new location. It has two nodeservers on it. At the new location, they both show as "Connected." Not sure why. Anyway, I can't delete them. Are the two related? Is it finding my ISY through the portal? If that's what's going on, how can I delete the nodeservers from the ISY through the portal so I can delete them from the Polisy? -Tom

How are you having the Vera tell the ISY to turn on the load? There are several ways to do this, but a REST command should be possible to implement regardless of how you're doing it now. -Tom

You don't need to upgrade the dongle to run 5.0.16C. That's the last release that supports the original dongle. However, you may find that some of the nodes still won't work after showing up. This is device-dependent. I have a couple of ZooZ switches for which that is true, and plan to upgrade the dongle and firmware to deal with it. It will cost you nothing to try 5.0.16C first, and see if it solves your problem. -Tom

If the switches are linked by being part of an ISY-defined scene, you should be able to send a REST command to turn on the scene, rather than the one light, and it should work like you want it to. -Tom

Sorry if this is irrelevant, but are you sure you're not having a problem of too high of an RF signal to the MSs? With mine, I always need to move them to a location inside of a drawer or cabinet to write links successfully. They will trigger existing links correctly and I can almost always read their status correctly in situ, but for some reason writing updates to them doesn't work unless I attenuate the RF level to them somehow. Others have reported this, too. -Tom

I forgot to add: having an ON level of <100% is really nice built-in Insteon behavior. If the ISY is down, or you want to or need to remove it from the environment, you can still have a low lighting level set with the first press, and go to 100% with the second. I remember loving it when I was first starting out with Insteon and didn't have my ISY, 20 years ago. -Tom

Thanks for the clarification. I only have 6 button KPLs, but I can understand why an 8 button toggles the load on/off by default. There's no off button! I still don't see how variables can fix the following issue: a switch doesn't appear to generate either a control or status event if it is turned on when it is already at its ON level. Without a means to trigger the ISY to know this has happened, how can the ISY do anything to establish the desired state? If you suggest using variables along with not having an ON level of <100%, then I get it. -Tom

This may be true for the non-load-controlling keys on a KPL, but I believe that the KPL load acts like a dimmer or relay, so it will go to the ON level on first press, then 100%, then ON level, then 100%, etc. Looking at the Event Viewer, it looks like an ST event is triggered when the switch is turned on manually ONLY if the status is not the same as the ON level when it happens. If so, it goes to the ON level (whether that is higher or lower than the status; i.e, down or up) and there's an ST command. If it is at the ON level, it goes to 100%, with no ST command. So maybe the solution will involve setting the light programmatically to be 1% away from the ON level, so you will always get an ST command if it's manually manipulated. Also, turning the switch on, no matter what its current state, always generates a DON 0 event, so maybe just look for those somehow. Dimming doesn't generate a DON 0, but does always lead to an ST event, in my testing. -Tom