stre1026 Posted February 3, 2020 Posted February 3, 2020 I'm having an issue with a program. I'm sure it's something simple with the logic but I've tried many different variations and I still can't get it to work right. What I'd like the program to do is if someone enters user code 1 or 2 into my door keypad, the program will disarm the alarm system as well as turn on the lights, etc. What happens occasionally is the alarm system will not arm when I arm it. It will arm, then immediately disarm a few seconds later.. I've traced the issue down to this program and I'm not sure why it's happening. My thought is that the user number last used to unlock the door stays in memory and so this program will always be true. Any ideas? If ( Elk Area 'House' 'Armed State' is Armed Away Or Elk Area 'House' 'Armed State' is Armed Stay ) And ( 'Locks / ZW Side Door Lock' User Number is 1 Or 'Locks / ZW Side Door Lock' User Number is 2 ) Then Set Elk Area 'House' Disarm Set 'Kitchen / Kitchen Recessed' On Set 'Thermostats-Home' On Else - No Actions - (To add one, press 'Action')
larryllix Posted February 3, 2020 Posted February 3, 2020 (edited) Look what you have done to cause this.If Elk Area 'House' 'Armed State' is Armed Then Set Elk Area 'House' Disarm Why care if the system was armed before? Just disarm it, if a 2 is registered. No circular negative feedback. This may not be a good idea as it will compromise the security level of your system. This will allow any length of combination to be detected from a KPL Edited February 3, 2020 by larryllix
stre1026 Posted February 3, 2020 Author Posted February 3, 2020 Hi Larry, Thanks for your feedback. The reason I care if the system is armed or not in the program is because I don't want to be turning the lights on and changing the thermostats if I have already been home and I am just coming back inside. The doors stay locked all the time. I am also trusting that a user 2 is in my lock in order to disarm the system. I know there is a small security risk here.
larryllix Posted February 3, 2020 Posted February 3, 2020 16 minutes ago, stre1026 said: Hi Larry, Thanks for your feedback. The reason I care if the system is armed or not in the program is because I don't want to be turning the lights on and changing the thermostats if I have already been home and I am just coming back inside. The doors stay locked all the time. I am also trusting that a user 2 is in my lock in order to disarm the system. I know there is a small security risk here. A bit confused here. You could break your functions into smaller programs. It makes it more modular and easy to understand. Sensing the same element you are controlling (jn the same program or system) is a bad idea in a trigger based language. You don't need the tests but it will set the Stat to Home each time the lock entry is used by these people. To avoid this variables or other flag methods to keep track of would be necessary and the feedback loop may be recreated again. If Keypad person is 1 or Keypad person is 2 Then Disarm system, Turn on light etc.. Else ---- If system Disarmed Then Set Thermostat Home On Else ---
lilyoyo1 Posted February 3, 2020 Posted February 3, 2020 (edited) I would seperate the alarm from the program. The fact that it's always armed means you'll always disarm if you punch in your code. However, since light control/thermostat, is not always applicable, they should be it's own separate program. Edited February 3, 2020 by lilyoyo1
stre1026 Posted February 3, 2020 Author Posted February 3, 2020 Sorry for the confusion. The system is not always armed if I'm home. The system is only armed when I'm away. I'll try separating the programs as you've mentioned to see if that solves the issue.
TrojanHorse Posted February 4, 2020 Posted February 4, 2020 I'm having an issue with a program. I'm sure it's something simple with the logic but I've tried many different variations and I still can't get it to work right. What I'd like the program to do is if someone enters user code 1 or 2 into my door keypad, the program will disarm the alarm system as well as turn on the lights, etc. What happens occasionally is the alarm system will not arm when I arm it. It will arm, then immediately disarm a few seconds later.. I've traced the issue down to this program and I'm not sure why it's happening. My thought is that the user number last used to unlock the door stays in memory and so this program will always be true. Any ideas?If ( Elk Area 'House' 'Armed State' is Armed Away Or Elk Area 'House' 'Armed State' is Armed Stay ) And ( 'Locks / ZW Side Door Lock' User Number is 1 Or 'Locks / ZW Side Door Lock' User Number is 2 )Then Set Elk Area 'House' Disarm Set 'Kitchen / Kitchen Recessed' On Set 'Thermostats-Home' OnElse - No Actions - (To add one, press 'Action') A guess here - not sure about these locks. Maybe tryProgram 1:If Locks / ZW Side Door Lock' User Number is 1Or 'Locks / ZW Side Door Lock' User Number is 2Then new.state.variable =1Wait 5 seconds new.state.variable =0ElseWait 5 seconds new.state.variable =0Program 2 (your old program replacing the 2nd part with the above variable)If: (Elk Area 'House' 'Armed State' is Armed Away Or Elk Area 'House' 'Armed State' is Armed Stay)AND new.state.variable =1Then Set Elk Area 'House' Disarm Set 'Kitchen / Kitchen Recessed' On Set 'Thermostats-Home' OnElse - No ActionsIf nothing else by tracking a new state variable you’ll know if the code is sticking in memory as you alluded to which can help with further troubleshooting. Sent from my iPhone using Tapatalk
lilyoyo1 Posted February 4, 2020 Posted February 4, 2020 12 hours ago, stre1026 said: Sorry for the confusion. The system is not always armed if I'm home. The system is only armed when I'm away. I'll try separating the programs as you've mentioned to see if that solves the issue. Even if it's already disarmed, another disarm command won't hurt anything so the status is irrelevant. You could use variables to check the status of the lights that turn on when someone walks in. If they are off, then they would turn on.
DennisC Posted February 4, 2020 Posted February 4, 2020 You could try setting a variable when you arm the system, say to 1 and return it to 0 when you disarm. Then use the variable to trigger the program. I do this to control various lights, heat, and several other functions.
oberkc Posted February 4, 2020 Posted February 4, 2020 8 hours ago, lilyoyo1 said: Even if it's already disarmed, another disarm command won't hurt anything so the status is irrelevant. I think he mentioned this, but this runs the risk of changing the light and thermostat settings of an already-occupied house...something he is trying to avoid, as would I.
lilyoyo1 Posted February 4, 2020 Posted February 4, 2020 1 hour ago, oberkc said: I think he mentioned this, but this runs the risk of changing the light and thermostat settings of an already-occupied house...something he is trying to avoid, as would I. Earlier I had told him he's better off separating the alarm from the other programs to have more control over the system. This was based off that advice 1
stre1026 Posted February 4, 2020 Author Posted February 4, 2020 I've been playing with this for a better portion of the day. I actually configured a spare lock on my ISY so I can play with this on a bench. What I'm finding is that the user number is not always recognized by the ISY. This is most likely the cause of my issue. I'm assuming this may be a version 5.x bug because I was able to consistently read the user number on the 4.x release.
lilyoyo1 Posted February 4, 2020 Posted February 4, 2020 1 hour ago, stre1026 said: I've been playing with this for a better portion of the day. I actually configured a spare lock on my ISY so I can play with this on a bench. What I'm finding is that the user number is not always recognized by the ISY. This is most likely the cause of my issue. I'm assuming this may be a version 5.x bug because I was able to consistently read the user number on the 4.x release. Is it in the same location as your other lock? Different locations may yield different results due to your zwave network. Also, make sure you aren't locking/unlocking too quickly as this can affect results as well
stre1026 Posted February 5, 2020 Author Posted February 5, 2020 It's not but, I have plenty of repeaters and the lock will unlock/lock every time so I'm pretty sure signal is fine. The one installed in the door is acting the same exact way so I don't think it's related to the Z-wave network.
larryllix Posted February 5, 2020 Posted February 5, 2020 (edited) 23 minutes ago, stre1026 said: It's not but, I have plenty of repeaters and the lock will unlock/lock every time so I'm pretty sure signal is fine. The one installed in the door is acting the same exact way so I don't think it's related to the Z-wave network. Lock/unlock is going the opposite direction of signal path to status coming back. The lock may have a much weaker signal due to battery life concerns. I wouldn't assume that. Edited February 5, 2020 by larryllix
stre1026 Posted February 5, 2020 Author Posted February 5, 2020 The batteries are brand new and are at 100%. I will put the lock near the ISY itself and do a network heal to see if that helps.
larryllix Posted February 5, 2020 Posted February 5, 2020 3 minutes ago, stre1026 said: The batteries are brand new and are at 100%. I will put the lock near the ISY itself and do a network heal to see if that helps. Not based on battery strength but on conservation technique. It may natively transmit a much lower power signal.
stre1026 Posted February 5, 2020 Author Posted February 5, 2020 Are there different revisions of Z-wave repeaters? I'm just thinking, the ones I have are pretty old. I'm wondering if I should swap them out with newer ones if this is a signal issue?
lilyoyo1 Posted February 5, 2020 Posted February 5, 2020 31 minutes ago, stre1026 said: The batteries are brand new and are at 100%. I will put the lock near the ISY itself and do a network heal to see if that helps. Putting it near the isy and healing your network is the wrong move. It needs to be located at it's final location so that the path of set properly. If it's by the isy when you heal then move it, the isy will assume it's nearby and try to talk to it.
lilyoyo1 Posted February 5, 2020 Posted February 5, 2020 (edited) 1 hour ago, stre1026 said: It's not but, I have plenty of repeaters and the lock will unlock/lock every time so I'm pretty sure signal is fine. The one installed in the door is acting the same exact way so I don't think it's related to the Z-wave network. Having repeaters is good. Having the right type is Paramount. Your repeaters must be capable of beaming. If they aren't then that can change things Edited February 5, 2020 by lilyoyo1
stre1026 Posted February 5, 2020 Author Posted February 5, 2020 I'm aware of the ramifications of moving a device and healing the network. I was still talking about the test lock that I have. All of these devices and repeaters have been installed in my house for over 7 years at this point and all has been working perfectly fine until I upgraded to 5.x. This is why I was thinking this may be software related and not hardware. The only thing I have done hardware related is replaced the z-wave dongle in my ISY which required a rebuild of the network. This could of course caused issues in itself.
lilyoyo1 Posted February 5, 2020 Posted February 5, 2020 35 minutes ago, stre1026 said: I'm aware of the ramifications of moving a device and healing the network. I was still talking about the test lock that I have. All of these devices and repeaters have been installed in my house for over 7 years at this point and all has been working perfectly fine until I upgraded to 5.x. This is why I was thinking this may be software related and not hardware. The only thing I have done hardware related is replaced the z-wave dongle in my ISY which required a rebuild of the network. This could of course caused issues in itself. I'm referring to your test device as well. The reason I stated what I said is that you were testing in a location that is different than your original lock. If you did not do a network heal with the lock in that location, the ISY may have trouble talking to it. Also, If your repeaters in that particular area does not support beaming you would encounter problems as well. The reason I bring these things up is that you earlier stated that you would move the lock closer to the ISY and then do your heal which is incorrect. Since your devices are over 7 years old, there is a good chance that the repeaters in that particular area may not be capable of beaming as many early generation zwave devices did not have that.
stre1026 Posted February 5, 2020 Author Posted February 5, 2020 The test device will stay near the ISY for testing which is why I did the network heal after I moved it. I think I will try and purchase a few new repeaters to see if that helps. They did support beaming at the time but maybe one of them went bad. Who knows. They are cheap enough to replace to see if that solves my issue.
mwester Posted February 5, 2020 Posted February 5, 2020 (edited) 1 hour ago, stre1026 said: ...This is why I was thinking this may be software related and not hardware. The only thing I have done hardware related is replaced the z-wave dongle in my ISY... Was the change to upgrade the z-wave dongle to the 500 series? If so, please be aware that many on this forum have observed that the new dongle's range (no matter how you compare it) is very different than the 300 series dongle. I originally had a 300 series with external antenna centrally located in my basement -- and according to the diagnostics, it could reach every z-wave device in the house directly. The upgraded 500 series dongle in the same location required that I have a z-wave repeater within about 10 feet of the ISY. The topology of the mesh changed every time I ran a "heal", but at most the three closest devices could be directly reached, all others repeated through one of those three devices. Alas, only one of those three was a z-wave plus device, and the ISY has NO control over the topology, so the resulting mesh often ended up with unnecessary hops, and often unreliable hops. I finally ended up shifting a bunch of devices to my Home Assistant install, so that the ISY can ONLY see the z-wave plus device, so my mesh is now stable. The 500 series dongle is a major disappointment to me (in fact, I'd go back to the 300 series if I could easily do so). Edited February 5, 2020 by mwester 1
stre1026 Posted February 6, 2020 Author Posted February 6, 2020 2 hours ago, mwester said: Was the change to upgrade the z-wave dongle to the 500 series? If so, please be aware that many on this forum have observed that the new dongle's range (no matter how you compare it) is very different than the 300 series dongle. I originally had a 300 series with external antenna centrally located in my basement -- and according to the diagnostics, it could reach every z-wave device in the house directly. The upgraded 500 series dongle in the same location required that I have a z-wave repeater within about 10 feet of the ISY. The topology of the mesh changed every time I ran a "heal", but at most the three closest devices could be directly reached, all others repeated through one of those three devices. Alas, only one of those three was a z-wave plus device, and the ISY has NO control over the topology, so the resulting mesh often ended up with unnecessary hops, and often unreliable hops. I finally ended up shifting a bunch of devices to my Home Assistant install, so that the ISY can ONLY see the z-wave plus device, so my mesh is now stable. The 500 series dongle is a major disappointment to me (in fact, I'd go back to the 300 series if I could easily do so). Indeed. This is interesting. I didn't know that about the 500 series. The Z-wave module I replaced was actually one of the beta modules and it had an external antenna. The new one does not. I will try and buy a few new repeaters and see if that helps!
Recommended Posts