MarkJames

It used to be that if you highlighted an EZ-Flora and hit options you would get a choice between Zone8 being PUMP or Zone8 being NORMAL. The NORMAL choice no longer appears in my UI (4.5.4) Am I missing something?

Actually two more questions.... what would this error mean? Sat 2017/02/11 08:51:35 PM System -170001 [uDSockets] RSub:24 error:6 and what would this error mean? Sun 2017/02/12 11:06:15 AM System -170001 UDQ:Queue Full: IPOLLWAKEUP : Task[9] SOCK SOCK-PROC pty=27

Thanks Michel. At the risk of asking questions outside the scope of ISY support I have a couple of things that maybe you know the answer to? Does it matter if the client doesn't gracefully unsubscribe? In other words are these error messages just 'interesting' or should I do something about them? At the moment what I'm doing is the user can manually close the socket or the socket will close automatically when the window or tab closes. My procedure for handling that is to call socket.removeEventListener() and then socket.close(). I assumed that regardless of what happens - the socket would close gracefully. Apparently I don't understand this very well (and that's not very surprising). If this isn't something you're comfortable answering perhaps you can point me in the right direction? Thanks!

Yeah - that's what's in the wiki. But what does it mean and what am I doing to cause it?

Does anyone know what the meaning of the -5012 error is and how it relates to the related number in the Message field? Also what causes the -170001 error? My .js website uses websockets. It works perfectly but I generate a lot of errors in the ISY error log. I'm not experienced with sockets and am getting quite a number of -5012 errors that have something to do with UPnP and quite a number of -170001 errors. Any help - particularly from those with js programming experience - would be much appreciated. I just need a push in the right direction to sort these out. mark

For you, Mike? I even made it purty. There are a few devices missing. Couple of EZFloras are waiting new PLM's and I've had some device failures where I've started replacing them with old-fashioned on-off switches (I know - scary, huh?) https://1drv.ms/i/s!Aq5Z1mepjZh3gbdcNEBKdlx1qYgTHw

Hey Mike! When you say 'don't have the all-on code' in them do you mean that the firmware does not contain code to SEND an ALL-ON command or does not contain code to RECEIVE an ALL-ON command? I've got a LOT of devices - nearly 150 now. Some of them are less than 6 months old so they would (I hope) have the most recent firmware. These new ones STILL turned on in the most recent ALL-ON event so if there is a code change it would have to be in what these send - not what they respond to. mark

Interesting.... Well - I realized that I do have one wireless device - a motion sensor that I use for dusk/dawn detection. I removed it and have set up my Homeseer app to inform ISY when sunrise and sunset is. I guess I'll see if it was the one little wireless guy that was doing this. The log doesn't show it sending anything prior to the ALL-ON events but I got nothing else to try. Thanks for the input! mark

I don't think it contradicts it but rather supplements it. It seems to me that the only device in the network that has access to every other device is the PLM. That's the only one that should have matching links for each device itself as well as the only one that each device should have a link for. Now I'm working under the assumption that the ALL-ON command (whatever its nature) still obeys the controller-responder link relationship. If that's not true then all bets are off. I guess it could be determined by plugging in a device, not linking it to the PLM, and seeing if it turns on in response too. What I would suspect is that the motion sensor you had the problem with is causing the PLM to send the ALL-ON. Of course this is all SWAG (scientific wild-assed guessing) so there you go. In the meantime I think it's safe to say that the PLM prior to 9E WAS the cause of the ALL-ON event. When I replaced my earlier version with the 9E my ALL-ON's stopped for at least a few months without changing a single other thing. If there's another cause for this besides the PLM I'd like to know what the technical nature of it could be as I've exhausted all the 'guesses' out there (motion sensors, looping, etc.) mark

What controller are you referring to? Do you mean the PLM? If so it's purely not practical for me to do so. There are a lot of lights and scenes that only work from the ISY - I could be waiting a week or more for an ALL-ON event that may or may not come. And are you saying that *any* of my legacy devices could be sending the ALL-ON message? mark

Hi Teken! The thing is that I've done all that already. My newest PLM is a v2.2 with firmware 9E. I have a spare of that as well. That replacement was in response to my last go with this. So.. if there is a claim that it can't broadcast ALL-ON then I call BS. It's done it and it's doing it. When an ALL-ON happens the lights don't go on in a progression the way they would programmatically. They just go BANG and everything is on. I don't even HAVE a program that would turn them all on nor do I have a scene that contains all my lights. I got rid of all my battery powered devices in my last battle with this so that's not it. I rewrote my program code last go round so I have a variable called 'OKtoGo'. It's used globally such that when a program wants to turn off multiple lights it has to wait for 'OKtoGo' to be be true. It works like this for example Program turn off all upstairs If OKtoGo = true OKtoGo=false run program bathroomoff then path wait 1 second run program bedroom1off then path wait 1 second etc OKtoGo=true Else wait 2 seconds run program turn off all upstairs As you can see there is no way for there to be a tight loop - there are built in pauses between scene offs and between program executions. AND... in todays ALL-ON there was 3 minutes of inactivity between the last ISY event and the ALL-ON. We have had power outages here recently because of the snow so it may be related - or perhaps the PLM got damaged by the unstable power. That's possible but I have no way to confirm that. It's a hugely frustrating problem. mark

So I had an issue with all on's every few days some months ago. I replaced my PLM and that seemed to solve it though to be safe I moved my fireplace and garage door on to Elk output relays from Insteon contact closures. All was well but since last week I've had two all ons. It's quite disturbing as every single light in my home is Insteon so having 140 odd switches pop on at 5am for no apparent reason is, in no uncertain words, a piss off. One that I've lived through more times than I should have to for the amount I have invested in this. This morning at 6:30am I had another all on event. My log shows my last ISY activity at 6:27 so it's not something to do with ISY traffic and I have no Insteon motion detectors so it's not that either. I'm sick and tired of replacing PLM's and the hassle that goes with that - not to mention the expense - so I've decided to try something and wanted to run it past the community for an opinion. I've got a couple of IOLincs (2450) that I'm not using. My plan is to link one to the PLM via the ISY but leave its link table otherwise blank - that way I know that it's not being activated by another device or by the ISY itself. My understanding of the ALL-ON is that the PLM sends an on signal that triggers everything in its link table. So - an ALL-ON *should* trigger a 2450 - at least it did when I used the 2450 as a GDO - that's why I moved to Elk - my garage door would open when an ALL-ON happened and then my alarm would go off. I'm going to connect the NO contact pair on the 2450 to my Elk as a non-burglar alarm zone. The ISY can then monitor the status of that zone. When an ALL-ON event occurs it should cause the relay on the 2450 to close. When the relay closes the Elk will know it so the ISY will know it. I keep a table of variables of the desired state of all devices in my house so the ISY could then run a program to simply turn every device back to the state it should be in. This seems like a workaround to the problem. I know it's not a solution but I don't think there IS a solution to this. This is a huge failing imho of Insteon. It's enough that it would be a deal killer for me if I were to be just starting off. Does anyone see a problem with this idea? Mark

Apparently not... hence my original post.

Thanks Teken, I've done the switch over - I just had to manually add the switch to all the scenes needed and then delete the old one. It was controller/responder to quite a number of scenes so it took me the better part of an hour to do it. Fortunately it works now and all is well. I sure hope it doesn't revert to 8 position after the inevitable power failure we're sure to have here before winter is over That was a problem with the very first iterations of the KPL's that came with both 6 and 8 button keypads I was just posting this in case it's something overlooked in the 'replace device' featureset of ISY - which is one of the things I like most about ISY. Perhaps there are innate differences between the 2 that prevent ISY from being able to do a replace this way. I would very much appreciate a link to your repair guide. I have a number of KPL's that I've accumulated lately that 'buzz' and no longer work. One that flickers the lights on the load on and off non-stop (this since a recent power failure). At the better part of a $100 a hit it'd be nice to bring them back to life. The only ISY devices that I've repaired so far are the outdoor switch modules. Those came with crappy relays that failed after not very long and were a simple swap. Mark

I'm not sure if this is a bug or if this is just the way things are but I noticed an odd behavior today. I'm replacing a KPL 6 that's failed (if anyone knows someone who repairs these I'd be interested to know). I accidentally ordered a KPL-8 instead by mistake No matter, I thought - I just swapped the faceplates and did the switch over described in the documentation to change it from 8 button to 6 button operation. All good. However - when I add the device to my ISY it DETECTS it with 6 positions (main plus A through D) but it SHOWS UP in the ISY description as an 8 button KPL. The significance of this is that when I try to do a device replace from the 6 that failed to the 8 converted to 6 I can't do it as 8 converted to 6 doesn't show in the list of devices available to swap with. mark

Here's the error log - The problem seems to start around 8:48 on July 25th so I've removed the events prior to about 8am so you don't have to wade through it. I don't see anything whacky - do you? I set up a system so that I don't flood the ISY with too many requests. Prior to turning a lot of devices on or off I set a flag called 'oktogo'. When oktogo is true no other programs are making changes. The program sets oktogo to false then starts turning lights on or off with a 1 second delay between each request. Once it's done it sets oktogo back to true and exits - thus allowing other programs to do their thing. When oktogo is false the program waits 2 seconds then re-executes itself to try again. It looks like this Daytime Energy Saver Actions - [ID 00DB][Parent 0018] If $OkToGo is $TRUE Then $OkToGo = $FALSE Set Scene 'Back yard / Back Yard Lights - All' Off Wait 1 second Set Scene 'Games Room / Games Room - All Lights' Off Wait 1 second Set Scene 'Garage/Shop / Garage - All Lights Off' Off Wait 1 second Set Scene 'Kids Floor / Kids Floor - All' Off Wait 1 second Set Scene 'Living Room / Living Room - All Lights' Fast Off Wait 1 second Set Scene 'Garden / Garden Lights - Back yard' Fast Off Wait 1 second Set Scene 'Garden / Guest Lights' Fast Off Wait 1 second Run Program 'Laundry Lights off' (If) Wait 2 seconds Run Program 'Kitchen Lights off' (If) Wait 2 seconds Run Program 'Ensuite Lights off' (If) Wait 2 seconds Run Program 'Eblanket naz off' (If) Wait 1 second Run Program 'Eblanket mark off' (If) Wait 1 second Run Program 'Main floor lights off' (If) Wait 2 seconds Run Program 'Sun room Lights off' (If) Wait 1 hour Run Program 'Blanket Mark Off' (If) Wait 1 second $OkToGo = $TRUE Run Program 'Daytime Energy Saver' (If) Else Wait 2 seconds Run Program 'Daytime Energy Saver Actions' (If) mark https://dl.dropboxusercontent.com/u/18230046/errors.xlsx

Thanks Michel, It's odd that whatever generated that series of errors didn't repeat neither before nor since. Everything is hunky dunky now without having changed anything. I'll clear my error log and start monitoring it. The sockets opening and closing I'm going to chalk up to a lot of beta testing going on at present. I'll often rapidly open a half dozen tabs that each open a socket then close them again. Thanks for going through that. I'll clear my log and start paying attention to it.l mark

Sorry Michel. Here's mine - I saved it just after the problem. There are lots of trivial errors related to messing with the REST interface at first - I just included the whole log even though the problem is in the last 100 or so entries. The 'system busy' non responsive issue started just about July 25th. It seems to be reflected in a series of 'Queue full' errrors. Here's the log https://dl.dropboxusercontent.com/u/18230046/ISY%20Error%20Log.v4.4.6__Fri%202016.07.29%2009.29.10%20AM.txt

Any experience with the Ubiquiti line of these devices? MFI? They seem to have a lot of sensors available - and the intent of the device seems more for tracking than just remote reboot - but the pricepoint is lower and the Ubiquiti products that I have installed have been of excellent quality - perhaps not 'commercial' but definitely 'prosumer' mark

I do a similar thing - a state variable that starts as false and after setting things up the way I want I switch it to true. I've also repurposed a motion detector recently to act as an 'is it light out' detector instead. I just put one facing out the window. When it's light enough to trip the motion detector 'dark' sensor I set a dark=false flag. Conversely at night when the detector decides it's dark enough to need lights I wait half an hour (they trip a bit early I find) and then set the dark=true flag. I never found the sunrise/sunset thing to work very well at my latitude. mark

Oh ok... They weren't doing that when I set up mine. I had to send fake credentials to my 'account manager' who then set me up with an account. I bought mine from Smarthome and they had all the software available there to download. Soon after they pulled it off the Smarthome site and I had to approach Elk directly to get in. That's when the fun started. I guess they had so many unhappy end users that they changed their policy. Good thing, too. Now if only Universal Remote would do the same - I LOVE their products but it's brutal getting the software for them. mark

I'm glad to hear they're supporting end users again. I bought my system about 15 years ago and all the software, updates, etc. either came with it or could be downloaded. Shortly after they put all the software and updates behind a professional log-in page. mark

Thanks for that, Kevin. I hadn't noticed the 'Init to' variable assignment before. I can already think of quite a number of uses for it. That will make rebooting less problematic for sure. My experience has been the same as yours - I very, very seldom have to reboot my ISY. It's the Windows XP SP3 of devices - it just doesn't crash. mark

Sadly not on Amazon.ca (well - there IS one but they want $70 to ship it). The only drawback to adding the ISY is that your variables will all reset to their initial values. I depend on a lot of variables so that wouldn't work for me. If I reboot I'd possibly have to go back and change a few things to after the boot. mark

I'll look more closely at the heartbeat event. I see it come in via the websocket but I haven't parsed it to see its significance. I was looking to see if an IP was associated with it so that I could tell which PC the socket was connected to. There are some 14 pcs, laptops, ipads and android tablets around the house - I was hoping to see which machine(s) were connected. mark