MarkJames

Thanks for the quick response. I have all my Elk violations in a folder for easy tracking. When, say, a PIR in a hall gets tripped it looks like this In this case it always turns them on - with some other doors/PIRs it checks first against time of day etc to see if they're needed. PIRs, can be funny things so I've been careful to make sure that the PIR actually does trip - I can see the light flick on it so I know it's sensed the motion. In general, you're right - it does happen fairly quickly. Fairly often, though, the lag is such that I stand there in the dark waiting for it to happen. I wasn't sure if the long and short poll numbers would be useful here as I'm new to PG and don't understand the finer details yet. On another note should I be checking for zone status for this sort of thing or should I be looking for a control ON message instead? Oh - lastly - any chance of being able to grab the lines of the Elk log as a substitution variable to be able to send via an email notification? You've made the Elk integration far more robust than the native version. I integrated all the same functionality that you did but I did it through the rest interface and acted on it through Tasker via autoremote on my phone. Yours makes it much easier Thanks!

I just migrated to eisy from my isy and purchased the Elk nodeserver. I use motion sensors connected to my Elk to turn on lights. This was fairly immediate with the ISY but with the eisy and the nodeserver I have a lag. Sometimes it's very minimal but other times it can be long enough to make it useless for turning on lights to navigate at night. Is there something I can tweak to fix this?

Interesting that you don't experience the lag as I do. It may be that my system is seeing a lot of collisions and failed communications at the moment as I complete my migration. Many devices didn't come across properly and so I've had to restore them one by one. Once all the links and relationships are restored properly perhaps it will get more zippy. The Elk is what it is. The native option is sadly gone - I would have preferred that it remain and the Elk poly was a choice I could make rather than having it forced upon me. The native support did everything I need other than access to the log which I wrote support for myself. I launch a lot of programs based on doors/windows opening and closing, motion detected, and I arm/disarm my system from within the ISY. I've been with ISY since the 99ir - easily 20 years or more - so much of my programming revolves around occupancy and motion within the home. Time will tell if it's as stable

So I got my eISY and am migrating from my ISY994. It's been a little tricky - partly because of the DHCP requirement of the ISY, partly because I had to change my PLM and I have some 109 Insteon devices to update. Admin console seems to load faster so that's nice. I'm a bit disappointed about the lack of native support for Elk. The plugin that replaces it is more robust - I'm not sure if it will be more stable - and frankly I think that the plugin should have been included for legacy users who were already extensively making use of Elk support. With the loss of native Elk I now have to rewrite dozens of programs to use the plugin. Anyways, be that as it may I'm a bit confused by what seems to be a bit of a lag between writing programs to the eISY and having them 'go online'. The ISY994 would accept 'save changes' to programs and within moments they were functional. With the eISY I find that I write changes and they don't go into effect for a 'while' (vague term, I know). It caught me the first few times because I thought the programs just weren't working but it turns out they worked - just 'not yet'. Is this a thing? Is there a delay that I should be expecting going forward? Thanks

You both got it. The problem was in the 'from' field of the customized email. Thank you both. mark

I have a routine that emails me if my sprinkler is shut down during the spring/summer. The email had a typo in it which I corrected. But the routine that sends the email still sends the typo. I'm not sure if this is just a buffer that needs to be refreshed or if the actual old content of the email is part of the program. Here is the code This is the content of the email as of now. It's been this way for a couple of weeks But this is the email that I get The typo was in the customized email when I wrote it and when I added it to the program but it was corrected a few weeks ago. Version info is

Same... I guess I'll burgle a KPL from somewhere that's not used too often to replace the one that does my kitchen. Sigh. Gonna have to decide on a new technology for any future repair/replacement.

Well that's not the best news ever. Thanks, I guess. Do you know if there are any services out there repairing Insteon devices for people with existing installations?

Ahh - damn Any idea what exists that is similar to a Keypadlinc (8 buttons)? I guess I'll get out there and start exploring options.

Well - that would be kind of mean. Leaving new owners with a problem that I know about. I wouldn't feel right doing that.

They are the same - yes. But that's not going to help long term if they cease production

As many have pointed out Insteon products seem to be done. I understand that the line is being picked up by Nokia but not all devices will still be available. I have a fairly large installation. Probably 80-100 Insteon devices. Many of my lights depend on Insteon control. This change in availability of Insteon products couldn't come at a worse time for me. I'm getting ready to sell my home and I have a couple of devices that are not working and I can't find replacements for - an 8 button and a 6 button Keypadlinc to be exact. I'm wandering around looking for KPL's that I can burgle from one location that I don't use as much to ones that I use a lot. I guess I'm going to have to move to a different technology to make things work again. I'm okay with moving to Polisy from my current 994 if that's what it takes. Can anyone point me in the right direction to start replacing some of my failed Insteon with something that I can integrate with or without PolIsy? Thanks

All changed over successfully. When adding it ISY identified it as an 8 button even though I had changed it but it correctly recognized 6 buttons. So all is well. Thanks everyone, for the help. mark

That should have been my next question - what would ISY recognize it as. I guess you're saying that it sends a different ID depending on how it's configured. It would be a lot more convenient to have it just be recognized as a 6 so that I can directly replace it in ISY. Thanks again. [edit above] in my previous post I wrote that 3 ISY devices had failed. I meant to say '3 Insteon devices had failed'

Thank you - will give it a try. The new ones don't come with a manual the way the old ones did and I wasn't clear on whether the old steps would still work. Will give it a go. For some reason I had 3 ISY devices fail in the last month - things had been going along pretty good for a year or two with no failures so this caught me off guard.

Admittedly I'm being lazy here but often there is nuance in these devices so I'm asking. When I first started using KPL's you could convert them between 6 and 8 button. They've stopped coming with both plates now and are sold separately. I have an older 6 button that has failed. I have a new in box 8 button that I'd like to replace it with. I wouldn't care about the extra buttons except for that I had engraved custom buttons made for the 6 that won't fit the 8. Does anyone know if it's still possible to convert an 8 to a 6 programmatically? Or has that been discontinued? Thanks

That seems possible too. It's the response I always get, though, and I have some 27 network resources that I test out all the time. One would think that I'd get variations of HT, HTT, and all sorts of truncated responses if that was what was happening. But it's always just HT. It doesn't bother me - it works fine. I have a 1500ms timeout - which I thought was excessive. Do you think upping it even higher might get the rest of the response?

Not sure.... I only send network resources to tasker via autoremote and I've only ever received the HT response. I have nothing to compare it to

You got it. My network resources temporarily stopped working so I went in to the configuration screen and tested the one that I was suspicious of. A normal response looks like this but for a few hours I was getting that other message instead of the HT message. I was getting it with every resource, not just the one I was looking into. I rebooted the ISY and my laptop as well but it persisted. A few hours later it went back to normal. I think the website that the resources were being sent to had some issues.

Funny - when I get that message I don't get success. The message doesn't get sent - or at least it doesn't get received at the other end. When I get nothing but an 'HT' then I get success. This error message went away after a short time. I had searched it out but only found references to Cross Origin Resource sharing and that's above my paygrade. I speculated that it was a problem with the receiving web page.

I started getting this when I send network resources HTTP/1.1 200 OK Access-Control-Al

So if I send myself an elk variable using an email customization it works fine. Something like ${elk.zone.1.name} - I can send that to myself with no problem But if I send the same thing via network resource it fails with a 400 error. I can send ${var.1.1} but if I send ${elk.zone.1.name} I get a Net Module Rule 400 error. Any idea why? To send variables I have to leave URL encoding off. If I turn it on then it sends the text ${var.1.1} instead of the value of ${var.1.1}

Ticket submitted. Thanks

My issue with google home has been going on for weeks.

Thanks - I'll go check it out.