Jump to content

Programming Help


stre1026

Recommended Posts

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')
 

 

Link to comment

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


 

Link to comment

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.

Link to comment
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 ---

Link to comment
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 try

Program 1:


If
Locks / ZW Side Door Lock' User Number is 1
Or 'Locks / ZW Side Door Lock' User Number is 2

Then

new.state.variable =1
Wait 5 seconds
new.state.variable =0

Else
Wait 5 seconds
new.state.variable =0

Program 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 =1

Then
Set Elk Area 'House' Disarm
Set 'Kitchen / Kitchen Recessed' On
Set 'Thermostats-Home' On

Else
- No Actions


If 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
Link to comment
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. 

Link to comment
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.

Link to comment
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

Link to comment

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.

Link to comment
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

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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

Link to comment

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.

Link to comment
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. 

Link to comment

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.

Link to comment
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).

Link to comment
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!

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...