TrojanHorse

@Michel Kohanim, I checked the logs. I don't believe I have any infinite loops. There is definitely a pattern here though, with these errors beginning about 30 seconds after restarting the ISY and then stopping after about 10 minutes. So maybe this isn't really a problem if that's the only time they occur and they stop within 10 minutes? Please bear with the rest of this post as I noticed something that seems interesting to me. Note that probably all of the "start" entries in the log occur after Mobilinc iOS app locks me out and then I use eKeypad iOS app to directly control an Elk relay to reboot the ISY. (On a related note, I'm excited for the UD Mobile app for iOS to become available and I've signed up to be notified about beta testing) I believe I'm seeing more of these errors as I've been forced to restart the ISY more often than usual as Mobilinc continues to randomly lock me out of the app and the admin console, requiring a restart (as many have detailed here https://forum.universal-devices.com/topic/25634-already-subscribed-bug-in-5014/) I noticed something interesting to me as I went through the logs. Prior to restart, I will see several "UDQ: Queue(s) Full, message ignored" entries. I will also sometimes see entries like "[UDSockets] RSub:26 error:6". However, these "RSub" errors occur elsewhere in the logs. But whenever there is a group of the "message ignored" entries, I see a "start" entry shortly thereafter (sometimes within a minute). This seems to reflect what happens when Mobilinc locks me out and then I immediately restart with eKeypad. So I'm wondering, are these "message ignored" errors any type of clue to the Mobilinc lockup issue? I will try to keep closer track of the details around these issues going forward to help make more sense of these log entries. I also noticed that the raw entries in the error log after reboot are not in exact chronological order, with the "/CONF/ELKXPRT.XML" and "[Network] Established" entries listed after these "Queue Full: ELK" errors even though the timestamp is earlier. In case it's helpful for anyone, I will post portions of the error log that I've color-coded to help me visualize these patterns.

Hello, I'm seeing several entries in the error log. Does anyone know what they mean? Seeing many that say --- System -170001 UDQ:Queue Full: ELK : Task[14] Modules MOD-CB-Elk Secu pty=24 And at least one --- System -170001 UDQ:Queue Full: MP : Task[6] ProtocolReader PR-PROCESS pty=14

Post the full program Sent from my iPhone using Tapatalk

What app? Sent from my iPhone using Tapatalk

Re #8 I tried that too and had same problem. I’d suggest clearing the Java cache and deleting applets and then go to UDI’s website to download the “my ISY” file. Sent from my iPhone using Tapatalk

Will that hopefully also include the Elk zone status at restart issue noted previously, please : - ) Thanks. Sent from my iPhone using Tapatalk

There’s an issue with MobiLinc, at this point I’m certain. See here and please post there. I think it’s helpful to have these issues in a single thread for Wes to see: https://forum.universal-devices.com/topic/25634-already-subscribed-bug-in-5014/ Edit: you can also look into ekeypad. I haven’t had the same problem with that app and actually it seemed to have a way of connecting and smoothing everything over when MobiLinc effed up my connection. Sent from my iPhone using Tapatalk

Here’s an option. https://www.elkproducts.com/product-catalog/elk-9200-heavy-duty-relay-contactor Sent from my iPhone using Tapatalk

I did notice that smart selection in MobiLinc. I had the problem I described and now use programs to get around it. But perhaps new Fanlincs don’t suffer this problem? If you have the same problem don’t fret. Your explanation is still helpful and it’s not much work to use programs. Sent from my iPhone using Tapatalk

Does this get around the problem where a “Fast On” of the OFF scene will turn the fan on at full speed? What happens when you send a “Fast On” from the admin console and also when you double tap your off button on the keypad? Sent from my iPhone using Tapatalk

I got excited when I skimmed this and saw reference to alarms but then realized that’s a z-wave fix (actually from 5.1). Still hoping that bug in programs with Elk sensor triggers loading at startup gets addressed. Sent from my iPhone using Tapatalk

For remote control I’ll use an app when needed. I don’t have voice control here. Would like it but don’t like the hot mic in my house... Not sure if this is where you are heading but I’ve always thought it would be cool to be able to respond to a text message sent from my ISY to my phone to have the ISY do something. I think someone had a way to do this but it was a little too technical and/or convoluted for me at the time. For example, if I get a text at 10pm saying my security system is not armed, I could reply with a number of minutes to delay any further action. If I don’t respond in say 5 minutes maybe the system would do a default action - eg arm the system if ready, make a verbal announcement at the house, etc. I also get texts when my garage is left open. Would be nice to be able to respond to that to delay further notifications for some period that I could define in the text reply. But if I had to send a new text to a different recipient rather than simply reply I’d probably just find another way to control the system. Sent from my iPhone using Tapatalk

Does this fix the issue where status of Elk Sensors aren’t properly loaded for program status - If conditions - at startup of ISY? Sent from my iPhone using Tapatalk

One thing I’ve noticed here is that an outage can occur with my ISP and eventually my modem will fix itself usually, but it can be faster if I power cycle the modem. There’s a handy ping node server here that I believe [mention]markv58 [/mention] wrote that allows me to check my internet connection. I use it in a program with a relay to power cycle the modem if the internet can’t be reached for say 5 minutes. If it still doesn’t work it will wait another 5 minutes and repeat a few times then waits an hour to check again and repeat if needed. Sent from my iPhone using Tapatalk

What router? Sent from my iPhone using Tapatalk

Fair point. What I did with “prior value” variables in v5 would have required hundreds of programs to do properly (and as many hours probably to make sure), and maybe a hundred to hack it. So I guess it’s worth it on balance then to accomplish what we now can do. That said, as a non-programmer professional who dives deep sometimes, the files that I see in the backups appear simple. Would be cool if someone could develop a “plugin” ?!? that would provide the code to allow someone to edit their all-Insteon scene as they did previously. I’d pay for another module!! Sent from my iPhone using Tapatalk

Respectfully I don’t think that’s the “whole purpose” for everyone. I agree it’s huge and that may be the biggest leap “under the hood”. But the first thing I did with v5 was store current Insteon dimmer values as variables so I could restore the prior settings after an event - say an exterior door opening (e.g. brighten the lights then go back to what they were, not just turn them off or whatever). Next was thermostat heat set points for the garage where I change them more frequently (that said a literal sledgehammer is probably what the Insteon thermostat needs). Like others I miss this functionality. Thanks for pointing out the “add controllers last” bit as it certainly helps. Fortunately for me all of my scenes were set up in v4... Edit I’m mostly Insteon. No z-wave and haven’t played with any “mixed scenes” yet as I haven’t had the need yet. Sent from my iPhone using Tapatalk

Another thought could be to make the time conditions relative to sunset. At least here in the Northern Latitudes there’s significant swing in sunset time. I’d start there while thinking of when you really need these to come on. Then go down the movie —> disable route if needed. Sent from my iPhone using Tapatalk

Haven’t spent many brain cells here, but are these sensors on the Elk or something else (eg insteon or z wave)? The way the program is written I suspect they’re not on the Elk. There’s an easy way to do this if they’re on the Elk. Regardless I tend to agree with just making this linked to an armed condition rather than your 3 conditions. But if you want the 3 conditions the best way to get this going may be to start with 3 programs - 1 for each of your Elk conditions. The programs don’t have to do anything - in fact the quickest fix would be to monitor them in Admin Console to see which programs is true / false when. That said Maybe put a 1 minute wait in each one so you know if the condition remains true. Without knowing what’s in the Then portion of your program (is that a problem too?). I’d start with the If to make sure they’re all triggering as you expect. Figure them out individually before putting 3 together? Sent from my iPhone using Tapatalk

I assume you’re right. Still a typo though in program 2? Sent from my iPhone using Tapatalk

Also notice that “His Bath” is a trigger in your original program and in one that you enable, correct? Please report back as you said on the enable and also try putting these enable statements at the end and report back. Sent from my iPhone using Tapatalk

I forget - anyone know? When a program is enabled will it automatically run If? If so, you will be running Else most likely and firing in network resource commands. Edit: Regardless, maybe try putting the enable program commands at the end if that works for your goals and as you mentioned you considered. Sent from my iPhone using Tapatalk

Great suggestions here. Curious, what are the other programs that you enable here? Can you post them? Sent from my iPhone using Tapatalk

Typo? That would create an infinite loop during time x with the door open I think, at least if using status. Program 2 should say “closed” not opened. Sent from my iPhone using Tapatalk

My understanding of recent GDO photo sensors in the US is that they had some type of signal on them, not just a voltage. Does anyone know if that is or isn’t true? I believe I read it somewhere and know that when idiots try to avoid using them they often stick them eye to eye right above the opener. They can’t just wire them closed or whatever. Sent from my iPhone using Tapatalk