MarkJames

lol - you're preaching to the choir. I live on Vancouver Island in BC. When my tag manager and tags showed up yesterday I had to pay the GST/PST and a $10 CanadaPost handling fee. That's a world better than the way UPS or FedEX rapes us, mind you. With the tag thing, though, you only buy the one tag manager. After that - yeah - maybe $30-50 CAD for a tag delivered. I guess time will tell. The other benefit to the tags (if you call it a benefit) is that they're battery powered so easier to put them in inconspicuous places. I built a beautiful Nixie tube clock a couple of years back and I can't find a place in the house to put it where I don't have a damned power cord running across a counter top. Drives me nuts! mark

I've built quite a few things with arduinos and pis - love those little things. I host my web page on a pi and have another one that polls my weather. Quite a few people are using them as HTPC's nowadays running plex, too. I can't help but think that in this case either of those would actually be more expensive than a premade product. Heck, a pi3 is somewhere around $40. Add a power supply and any light sensors you might want, tack on some shipping and you'll probably want an enclosure and you're easily upwards of $60. A CAO tag can be had for $25 and you don't have to code it or build it.

So how would you say they compare to a basic keypad lock. That's what I have on the doors that I generally come and go through. Do you use the zwave functionality in some way for that?

Those look very useful! I'm gonna check on those. Out of curiousity - how do you use your z-wave locks? I've pondered pulling the trigger on those a few times now but can't quite wrap my head around how I would benefit from them. mark

Do you like them? I've read mixed reviews from people on these. How do they report light? lux? percentage? something else? I've been tempted to put the zwave dongle into my 994i but I'm not sure what else I'd do with it other than perhaps door locks. mark

Yeah - I had nothing but trouble with those. I have 3 brand new ones in a drawer that I'm gonna but on eBay. I didn't like the battery life - and depending on where you mounted them they were awkward to change the batteries in. Plus I didn't find them attractive (though the new ones look better). They also only reported light/dark. I want something that can tell me HOW light or dark. I'm trying for 'so bright that lights that get turned on get shut off again' or 'bright - but maybe you want the lights on anyways so I'll leave the alone for half an hour' vs 'dark - lights get left alone' mark I'm familiar with the REST interface - I use it a lot - I'm just not sure how these tags send info to it? Do they have wifi built into them or what? mark

Those look really interesting. Small, good battery life and excellent range. So when you say via the REST interface - do they report to a website that I then scrape? Or can I get the data locally? What's involved in getting the info from them? Thanks!

Is anybody using any form of luminance/brightness detection in their HA system? I'd like to determine how bright a room is to decide if lights need to be turned on or off based on motion. Rather than deal with sunrise/sunset/time of day it would be ideal if I could just determine how bright the room is with the lights off and use that to decide if the lights should come on. The HSM200 looks like a reasonable fit for this job but it's Zwave which I don't have. I suppose for under $50 I could add it to my ISY.... There doesn't seem to be any environmental sensors for Insteon other than leak/motion/contact. I was hoping there would be something that might report luminance in lux as a dim level (0-255) or similar. Thanks! mark

Actually, I noticed something afterwards... My screen is a 32" BenQ (3840x2160). The popup box that the UI was putting up was too small for all the elements to show up so the 'normal' and the 'pump' buttons were superimposed and looked like 1 button. I stretched it out and they were both there all along. I'm not sure why these are buttons, though. Seems radio buttons would be a better choice here as this is an either/or proposition. mark

I'll go back and check my UI. I'm on 4.5.4 but my UI might be behind. Just to clarify - you see both the NORMAL and the PUMP choices? Thanks! [Edit] Confirmed - it works with the newer UI. Thanks! I hadn't considered that it would work with an older one and a newer one but not with the one I had. mark

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