greazer

Thanks @Geddy I'll check out the videos too!

Nevermind, found it!

Awesome, thanks! Oh wait, while I have "you" here, can somebody provide me a pointer to where I can find instructions for installing Polisy on a raspberry pi? I'll look around myself. Maybe I've missed it somwhere.

Oh, here's my understanding in a nutshell, of Polyglot and Polisy. The Polyglot cloud provides a way to run nodeservers with your ISY without needing to purchase Polisy hardware or Raspberry Pi. The Polisy hardware or a configured Raspberry Pi can be used *instead* of the Polyglot cloud. Current hardware and the cloud are using Polyglot 2.0 nodeservers. Polyglot 3.0 is in development and will require existing nodeservers to be modified to work. The polyglot cloud is not likely going to support 3.0 nodeservers, so it would be prudent to consider setting up local hardware in some reasonable timeframe. Do I have this right?

Just up front, I am always amazed at how thorough and helpful the users are on this forum. I've never experienced one this good. Thank you soo much! Also, @geddy, thank you for the details. It really really helps. @jimbo, First good name (It's my first name too). Second, you have helped me in the other thread. For anybody who runs across this thread for ecobee problems, here's three really useful pieces of info. Restart on the polyglot cloud service means, Stop and Start of the node server. You certainly don't need a PIN anymore to setup ecobee. The biggest thing I hadn't been doing but needed to was to restart the ISY admin console after getting the ecobee nodes to appear in the console. To get the nodes to appear in the admin console you might need to copy the ecobee authorization link from the ecobee nodeserver log as I understand that sometimes the website fails to display the link.

I've been using ISY now successfully for many years. And recently I was able to get a couple of node-servers up and running on it (DarkSky, Ecobee). However, I have a few questions: I'm confused as to what an extra Polisy device would be used for? I mean I was using two node servers and an ISY without one. I do have a raspberry pi that I could consider installing it on but for some reason I'm having a hell of a time trying to find instructions on how to do so. Maybe it's right in front of me, but I'm not seeing it. As I mentioned that I had both DarkSky and Ecobee successfully running once. BUT now neither are working for me. I was just trying to do some updates after setting them up about a year ago. For whatever reason I ended up uninstalling and tryin to reinstall both. I don't care about DarkSky but I do care about Ecobee. I'm never getting the PIN that it says I should be getting. I can post or look in another forum for that I suppose. Based on my problems above, I'm having trouble understanding just how to diagnose the problem and fix it. Would my life be simpler if I just got a Polisy (either new device, or raspberry pi?) Any answers to the above questions or pointers to existing docs on this would be greatly appreciated. In the meantime, I'll keep digging through.

Ah, both very useful! The fact that the I/O Linc is powerline only would totally help explain why it's only the garage doors that I'm having trouble with. Er, I mean I may be having trouble with other devices, but since they're dual band, I just don't notice the problems as much. I actually have a range extender in the garage, plugged into one of the other outlets in the garage, but I suppose if the noise is happening between where the I/OLinc is and when the range extender "sees" the signal, that could be a problem. So I'd think plugging the range extender into the same outlet as the I/OLinc might do the trick as I have another dual band switch in the garage anyway. Great to know about the LED bulbs! Right now I do have incandescents in the openers themselves. Probably from trying to fix this before.

Sigh, just found these two topics. The first one looks quite appropriate to me, the second was a topic on this very problem I tried to solve 2 years ago. Guess my memory is just full of noise too. I don't recall whether I checked my LED bulbs as the culprit. Gonna go do that now. Regardless, if anybody has anything else interesting to say, I'd still appreciate it. and

I have two IO Linc's connected to the two garage doors in my house. I'd say about 75% of the time they work exactly how I have them setup with the ISY programming. However, the other 25% of the time sometimes a door doesn't open/close when sent the request. I also experience errors in the ISY admin console indicating there is a problem communicating with the "Garage # sensor". If I query the device, it usually resolves the communications error (no more red exclamation points next to the device). I don't really have any sort of problem like this with any other sensor, device or ISY program in my home, and I have probably close to 100 Insteon devices. It's just the damn garage doors. The garage door openers are on their own circuit in my electrical panel. I do have a fridge in my garage, but it's not a big one and again it's not on the same circuit at least. But to be safe I put a filter-linc on it, thinking that that might be causing the problem. Nope. I've experimented putting filter-linc's on the garage door openers themselves to no avail as well. I've been kinda successfully living with this problem for about 2 years, but I'm finally fed up enough to try and get some advice. Any and all would be great. Thank you!

Really great info, MrBill! Yeah, this community is just one of the best I've experienced for anything. Yeah, I didn't think of having to re-add all my devices. That would be a pain. For now I just ordered a new serial PLM. Hopefully that at least buys me a couple more years.

Good to know about the PLM! And thanks for the info about how you use HA. With regard to the PLM fail problem, one thought I had (but it's ugly), is to move away from the PLM and instead use HA integrated with a true Insteon Hub. I don't think the hub requires a PLM as it is one (I think). All the programming I've depended on in the ISY would have to move to HA though. That's the ugly part. But in theory is this a possible option? Hmmm... I suppose this is an inappropriate question for this forum, since it implies leaving ISY... The only solace is that I've really liked how well the ISY has worked for me over the years!

One other thing though, MrBill, do you find yourself doing programming using HA exclusively now? Or are there situations where you still rely on programs in the ISY? I'm new to the HA world, but I'm thinking that it's likely going to support more devices than ISY will ever be able to support (even with the Polyglot stuff) and it can to integrate all of them. This question is totally off topic, I realize, but any pointers would be appreciated.

Thanks for all the help here! After determining that I wasn't getting any events for ANY of my devices (including wired switches) I realized that this was more likely a problem on the PLM side. I found this article (INSTEON No Status Feedback From Devices - Universal Devices, Inc. Wiki (universal-devices.com) and followed the instructions. Lo and behold it found 0 links in the PLM. After restoring it all is working again. I'm not sure what happened, but perhaps it had to do with what MrBill indicated about "adjust scene" events accumulating. The fact that I had had a power outage happen while I was on vacation AND I adjusted the TLS settings for HA were just red herrings. I have updated to 5.3.3. So hopefully I won't see this again. Thanks again!

Note that it's possible that this has been happening for a longer time than just recently and I didn't notice. I don't depend so much on programs for my motion sensors and typically my door sensors only matter when I'm not home and somebody opens a door that shouldn't. Therefore, it's entirely possible I just failed to notice until now. Here's the version of the firmware I'm using. Perhaps 5.3.1 is buggy in this regard?

I'm at a loss. For some reason all of my sensors in the house are no longer showing status. It's simply blank. This screenshot was taken right after I manually pressed the Set button on one of my original Insteon MS's. No events, no status. The linked devices do turn on and off though so it's not a battery problem. I can even make my hidden door sensors beep from the admin console, so communication is possible. I'm getting the same problem for Door sensors and motion sensors I have in the house. What am I missing? Note that I just recently started playing around with Homeassistant and it's integration with the ISY. Could that be the source of the problem? I know I futzed with a TLS setting somewhere. Otherwise, Homeassistant successfully found my ISY and all the connected devices. I can control lights and such with it just fine.

@larryllix, I am definitely changing the brightness of triggered lights based on the time of day using the technique I described above. That leaves a way to change the OFF time after a light is triggered on. I don't know how that can be done other than by changing the MSII to be ON Only, then creating a program that starts a timer when the MSII is triggered on and turns the light off after it times out. You could then use a variable time limit in the program itself based on time of day. If you did that, then you could set the applicable MSII's to timeout after 30 seconds since you want motion to be sensed as quickly as possible each time. This way, you can still take advantage of having scene-link performance to turn a light on. Lag is probably not much of an issue when turning a light off. I used to do something like this, but I really didn't like the fact that when setting up a new MS, I'd HAVE to remember to change the hardware options (particularly make it On Only as well as setting the timeout) AND make sure I have a program for it to ensure the lights are turned off. By making use of the defaults for MSII, there have been cases where I just made a scene to link the light and the MS and that's pretty much it.

@tjkintz, I didn't think I was experiencing what you indicate with my MSII. I don't get an ON notification until after the MSII times out. I created a quick program to beep my office light switch when an ON is received (or just open the event viewer to see what events are occurring, I usually find beeping easier). It looks like this: The Office Desk MS is an MSII v.46 (not v.47, like my others) and sits pretty much right by my keyboard so it's constantly seeing me move as I type. The LED blinks as expected when I move, and the scene-linked lights stay on while I'm in here, but I do not hear a beep from my light switch. If I let the timeout expire and the MSII goes off, when I trip it back on I do hear a beep from my light switch. This is true regardless of whether I have On/Off or On Only set for the MSII. Here are the settings for my Office Desk MS II: Note: I actually get multiple beeps when the MSII senses movement. This can be verified in the event viewer. I don't know why this is. But in any event, I don't get continual beeps as I see the LED light up. Only after the timeout occurs.

Your welcome, @larryllix! Lord knows I know you have helped me countless times in the past! What you describe is happening makes total sense now and I certainly agree with your new ISY Axiom. However, I do wonder why you would even need to have the ISY timer fallback to turn off a light that is hard-linked to a MS or MSII? As long as there's motion in the room, the light will stay on. When you leave, the MS or MSII times out, turns off and thus turns off the light. I suppose you might have a situation where a person can turn on the light in the room for some reason without ever triggering the MS. OR perhaps you have it hooked up to Alexa or have some other programmatic way to turn on the lights without requiring anybody to walk into that room. Is this why you have this fallback? For me, I don't have this situation occur much, but even if I did, it doesn't bother me as the appropriate MS is likely to be tripped eventually. On a related note though, I do have a program that runs when all MS's in the house turn off. That program waits for a 30 minutes before turning off all the lights in the house if no further motion is sensed anywhere. (Actually if the lack of activity is discovered during the day, I lengthen the timeout to 3 hours since during the day, 30 minutes could conceivably pass if somebody's sitting on the couch watching TV, not moving much. In that case, turning off all the lights in the house is undesirable. If you're not moving for 3 hours, then you must be asleep. ) This should usually ensure that any light that doesn't need to be on is turned off after 3 hours, no matter what.

I'm definitely not seeing this behavior, and I have several MSII's with long (3-5 minute) timeouts. In fact, here's my laundry room settings. The firmware version looks the same, so I'm not sure what might be happening. I believe most of the values here except for Timeout is set to the default. As I mentioned above, it's possible that some of these settings aren't what they say they are in the ISY. You might try a simple experiment by resetting your MSII to factory and then just changing the Timeout value. I know with 100% confidence that the behavior you're desiring is exactly what I'm experiencing. I have several other MSII's setup the same way. FWIW, I just did another a test with my Kitchen MSII instead of the Laundry. It has a 5 minute timeout. I walked into the kitchen and triggered it on. I waited 5 minutes back in my office till I saw the sensor go off. Walked right back in the kitchen (takes about 5 seconds) and the sensor tripped on again thus turning on the kitchen lights.

I'm not sure I'm following. I use one in my laudry room in the way I think you're describing. I have my router, server, amp and other things in my laundry room up on a shelf and yesterday I was up there cleaning and organizing. After walking into the laundry room, the lights came on as expected. While I was dorking around up on a ladder, the MS II couldn't see me, so the lights eventually went out. All I needed to do is wave my foot in front of it to get it to turn back on. But maybe I'm misunderstanding what you're describing... ?

Thanks @larryllix. By "logic applications" you mean using notifications from them in programs? And by "off time duration" you mean a time to specify that the motion sensor will stay off and not send ON notifications? I'll edit the post to mention those things that I found to be MSII specific. I have actually really liked MSII especially compared to the original MS's. In fact, I've replaced almost all of my MS I's with MS II's and have been quite satisfied with them. At one point, I had tried to use a Z-wave motion sensor (Dome) which worked well, but they seem to be sooo picky and difficult to configure (hold down a button for half a sec to wake it up, and you're not sure if you did it right) and then you have to look up parameter numbers and datatype sizes. Such a pain.

(Per suggestion from @larryllix below, adding tags for info that is specific to MSII's. There's only a couple things actually. I did a lot of this with MS I's) Wanted to provide some information about things that I've learned over the years of using Insteon motion sensors with the ISY. These are in no particular order, but you all may find them useful. From what I've gathered ISY by Universal Devices is not Insteon. Therefore, all of the options that are available for the motion sensors are the result of reverse engineering or really bad communication between the two companies. This means just about anything goes with these options. The most basic ones will most likely definitely work, but some of the other ones are probably the result of reverse engineering and therefore wind up poorly documented, or may not even work. The motion sensor will send one on event when they are triggered. They will not send another ON event until after they go off. BUT they continue to sense motion while on and each detection will reset the timeout to turn off. Therefore, if you have a 3 minute timeout the OFF event will never be sent until motion ceases for 3 minutes. MSII-only: Pretty sure that that default 495 seconds of "Off Button Timeout" likely controls how long the motion sensor stops sending events after you press the *motion* button on the device. I haven't tested that but I do know that when I've turned off motion for a sensor, it does magically eventually turn itself back on... probably after 495 seconds. I used to use programs to better control when things happen when motion is detected. BUT that method can tend to be very laggy. In other words, if you have a program to turn on a light when you walk into a room, by using a program the amount of time it takes for the event to occur, be detected, and turn on the light is slower, often much slower, than if you just set up a controller/responder scene (whereby communication between the motion sensor and the responding light is basically a direct line of communication). So pretty much all of my "walk-into-a-room-and-turn-on-the-light" behaviors are now no longer programs. It's a bit more of a pain to setup and maintain (say when you want to change the timeout, as you have to physically put the MS into write-mode), but I just have found it worth the effort. I do have some motion sensors that I set to send ON-only events, and have a program that detects the light coming on but then turning it off. One case of this is for my garage, where I have two motion sensors. One of them is the "main" sensor and turns the garage light on and off after a default timeout, like normal. The 2nd motion sensor is there to just basically "support" the main one to ensure that the garage light stays on if I happen to be in a place where the main sensor can't see me for its timeout period. This second MS keeps the lights on and ONLY keeps the lights on. Eventually the main sensor will see me again and thus it will eventually be able to turn off the lights. MSII-only: I've played around with sensitivity and day/night thresholds, but I cannot make rhyme or reason about them. I could be wrong, but I've just chalked this up to bullet #1. To do something like preventing a light from coming on during the day or having it come on dim between certain hours of the evening, I DO use a program. But the program is only designed to set the light level of the scene in question. So in other words, if say you don't want a motion sensor that is directly connected to a light via a scene during the day, then here's what the program looks like: THEN you also have a program that sets the light levels for *scenes* given whatever criteria, like this: Note that this capability requires 5.x version of the ISY firmware but it does work with the original Insteon Motion sensors. This program, is called "Set Scenes" and is called by other programs (like the one above) depending on the criteria I'm using to set the light levels. Note that scenes can be adjusted in devices WITHOUT having to put them into write mode (waking them up, or whatever you want to call it). I've found that using programs to enable and disable other programs to be very problematic and difficult to deal with. So I try to avoid doing that. I DO use disabling of programs to make sure that they are never called for me by the ISY AND to remind me that they are helper functions only (as you can call disabled programs from other programs and the disabled program executes). In fact I have a whole set of helper functions that I organized into a folder: Hope this helps somebody out there.

Thanks @larryllix, I’ll give that a shot!

Just looking up the same thing on these forums. Yes. I'm wondering what the technique is to be able to have Alexa announce the state of a sensor. "Alexa, is my garage door open?"

Seems others are experiencing what I'm experiencing. I seem to not be able to get any notifications from locative at all (let alone making a web-request from it). I'm wondering if it's even working anymore. Since GPS mapping apps are able to basically know where you're at in close to realtime, I don't see why locative shouldn't be able to fire a notification within a couple seconds after leaving or entering a geofence. No?