Deleting an "Area" on Elk M1?

[mikefamig]

I figured out the issue.  I had one disabled zone that was still assigned to Area 2 that I completely forgot about it.  Once I reassigned that zone to Area 1, I was able to delete Area 2 as expected and then "send all Areas."  Now Area 2 is gone from the panel.
 
Although I feel dumb for missing this, some more informative prompts from Elk RP sure would be helpful.
 
Edit: Thanks for the help and patience DEL and Mike!

 
I personally think that ElkRP is due for an overhaul, it is a little primitive compared to modern software and now that we have Windows 10 I'm afraid that there will be some new problems with it. On the other hand it does a lot of work and I would hate to have to live without it and do everything through the keypad. It really is the true strength of the system.
 
Before spending a lot of hours troubleshooting a problem I like to start a new customer account and then receive my panel to that account. It takes a lot less time than I might otherwise spend trying to discover what is causing the problem and you can always just go back to the old customer account if the new one doesn't solve the problem.
 
I consider it a bug that RP will remove the area and leave behind a zone assigned to that area.
 
Mike.

 

[Del91574]

Not necessarily what I'd call a bug. It's a valid point as far as the system is concerned. Disabled only means it doesn't affect the system per se, yet it still exists on the system,  but could sit in standby or unused....I have plenty of larger panels with points on them that were installed as part of a contract but later ended up being disabled or deleted.
 
Only way I'd say otherwise would be if the system had a checksum to flag disabled zones, but then you'd have to factor in outputs, rules, etc. that can be disabled yet still exist in the system programming.
 
Of course, I'm dealing with massive systems with SQL based actions and items, so a few thousand points linger out there in the systems I'm dealing with.....RP is a pretty darn good software compared to Compass, DL900, Miniloader or a few others.

 

[mikefamig]

Not necessarily what I'd call a bug. It's a valid point as far as the system is concerned. Disabled only means it doesn't affect the system per se, yet it still exists on the system,  but could sit in standby or unused....I have plenty of larger panels with points on them that were installed as part of a contract but later ended up being disabled or deleted.

 
But when an area is deleted it should also delete any zones associated with that area or at least warn you that you have zones that will become orphaned. How can you have a zone that is associated with area 2 after area two has been deleted? It seems like a loose end to me.
 
Mike.

 

 

[Del91574]

In my mind and working on larger and more complex systems, we're dealing with a MS access based program and limited hardware and not a SQL based system with exceptionally robust hardware.
 
The points assigned to an area would always remain associated with that area if they are enabled, which would put a flag on them to be recognized by the system itself and then associated as part of that area. When you delete the area, it would pull the reference and flags out and completely remove the associated data.
 
By having the zone disabled via programming, it would not be flagged by the system, even though it has a baseline association to the area itself. Deletion of the area would not necessarily pull out items that are not flagged as associated by the system due to them being disabled. Area and ZT are only an attribute of the larger picture of a zone, vice versa. In almost every system on the market, you define the areas first, then define the zones and associate the zones with the area itself. Others just put the zones in limbo when orphaned, in this case the MS access is flagging the zone exists, but is associated with an area that has now become undefined. If anything, RP should not allow you to attribute items to areas or components that don't exist, but that becomes a one way street also.
 
Is it what the tinkerer would want on their system? Probably not because they're the ones that want a single "blow this out" button, but understanding the background of how the hardware, embedded software and the MS end of the equation, I don't see it as a bug based on how the flowchart and hierarchy would exist on the  M1 or any other system on the market.
 
FWIW, with full blown SQL or Linux based systems, the items usually end up getting tossed into an "unassigned" pool and still have their background references still attached, though they are not assigned to an active point, association, or panel. Very common operation for security hardware and software.

 

[mikefamig]

Given that we accept the fact that a zone is going to exist as an entity that is associated with an area that no longer exists and that htis is normal then shouldn't RP be able to resolve the zone and deleted area between the panel and the DB and not keep reporting it as a conflict? It seems that the OP could not get RP to resolve trhe conflict until the zone was deleted.
 
It would be nice if RP could have pointed out that the zone was causing the conflict. Seems like a problem to me.
 
Mike.

 

[Del91574]

I just tried to replicate what the OP said was happening in his system using my RP and M1 and every time and variable was flagged and the detail screen and brought up. RP 2.0.24
 
RP isn't going to resolve this issue, in this case; it comes down to programming hierarchy and how areas are constructed. Verbiage might be desired in the conflict tab for clarification, but zones should be removed or definitions removed in the system before blowing out the area, which really makes more sense because if you still have them attached to an area, then it points to the other portions of the area not being defined by the system's area tab. The zones still constitute an "area" though there is no definition for E/E delay, etc. which could also mean rules would still be able to reference those points and perform actions.
 
If there was a "fix" it would involve like the FACP manufacturers that provide a system simulator to map and test all I/O's and determine the linkages, if they exist or not or are referenced by another portion of the system's programming, but this would also be problematic for phantom outputs and other items that may not be mapped directly in the M1 but through a 3rd party application. All it would be able to do is determine the I/O and whether it was mapped to something else in the system, not whether or not it performs a valid system action, which would be impossible on a burg panel due to the variables that may or may not exist and be actionable elsewhere or via another attached system.
 
I understand what is being said, but the practicality is the zone in itself, though disabled, assigned to an area, created an area in the system itself, but keep in mind what the area tab in RP and the M1 addresses: E/E and keypad functionality. Can you have an area without a keypad (yes) can you have zones assigned to an area without a keypad (yes) can those zones be disabled (yes) will the area still exist if there is no keypad or basic timers (yes). Can those zones still perform actions not dependent on a KP or basic system timers (yes). Can rules still be actionable to items to an area that does not have associated timers (yes).
 
I know you aren't going to like the statement Mike, but it really comes down to programming discipline and what should be done on the system and in what order (delete or remove the zones from RP if they're unused as they can reference items that are independent of the "areas" tab).

 

[mikefamig]

I had to read it twice but I think I understand what you're saying. Zones can exist whether they are governed by or belong to an area or not. I can't think of an example where it would be practical or necessary to have a zone that is not associated with an area but it is how the hardware engineers wanted it to be.
 
Mike.

 

[Del91574]

Not necessarily, the system zones can be attributed to an area that has no definition for keypad or E/E times. The practical application would be a 3 area system with only 2 areas with keypads and control, so to speak. Think of a office building with 2 separate offices and a common lobby. You have a door on the common lobby you want to control but only if each office is armed and have it affect each area separately, so entry into the common lobby affects office 1 but not office 2 and vice versa. I'm thinking the best example of an area with no attributes would be if you put a KAM on a single door and had those points mapped to an area but didn't require any other interaction to the other areas besides disarm when either office 1 or 2 had their system disarmed. You could also do something like drop an environmental sensor or a fire door into an area that only drove an output, no need to assign any other system attributes via an area at that point.
 
It also depends on what the manufacturer's definition of area vs. partition and how the two interact with arming or other items. While clumsy, not to mention making for an "interesting" system operation, some systems define an "area" to be really a partition within a global system, with the area being the next tier up, which is then globally controllable. DMP XR500/550 comes to mind for that sort of operation.
 
In the case of the M1 and a few other panels, Area isn't necessarily a true system partition, only a logical grouping that can be interacted with by rules or other system events.