Evo status #18
Evo status #18
Conversation
Evo status requests and detail parsing. No handling yet. Evo label requests use constrains from the config file.
|
cfg.BUSES and so on, refer to the additional BUSES, MODULES, etc... which can be connected and can issue events. They are probably not used in the code yet. The purpose was to ignore some components (like we can ignore zones and partitions). The paradox.py file should keep common stuff and all the rest should be in the appropriate panel. It may be possible that the panels are very specific and much of the code will be there... This will bring some problems when keeping functionality synchronized. I will take a look during the next days. |
|
I think that it could make sense to further split the different EVO panels into separate files, inheriting from a EVOPanel Class. For the sake of modularity and to keep the code well structure I have nothing against further divisions. I think we should exploit commonalities as much as possible, and the strings and enums used in the messages should follow a similar style. Later we may want to translate them. |
paradox/hardware/evo/panel.py
Outdated
| @@ -58,18 +61,22 @@ def update_labels(self): | |||
| pulse=False) | |||
|
|
|||
| # Zones | |||
| eeprom_zone_ranges = [range(MEM_ZONE_48_START, MEM_ZONE_48_END, 0x10)] | |||
| eeprom_zone_addresses = list(range(MEM_ZONE_48_START, MEM_ZONE_48_END, 0x10)) | |||
| if self.product_id in ['DIGIPLEX_EVO_96', 'DIGIPLEX_EVO_192']: | |||
There was a problem hiding this comment.
Should we have conditional logic or create a subclass for each panel?
| else: | ||
| raise e | ||
|
|
||
| def update_labels(self): |
There was a problem hiding this comment.
If we have common things in the different panels, a better approach would be to have a structure with the addresses, and put the common elements in the parent class. At least zones and partition labels will be common.
There was a problem hiding this comment.
EVO192 zones are divided in two non continuous address ranges. Will need to add support for an array of ranges.
Partition names are in some structure where each next partition label is after 107 bytes from beginning of previous. But label length is always 16 bytes. Probably size is bad name in mem_map then. It is not size, but shift or offset ?
Same thing for PGMs.
|
I started merging both approaches and will update this PR in the next days. |
Without pauses "update labels" partially fails as it receives events instead of replies.
|
Would be good to limit amount of zones, users fetched from memory. |
|
On EVO192 it takes 20 seconds to read all labels of zones, partitions, PGMs, users, doors and modules via IP module. I do not read all users now. Only 256 of 999. No idea where users above 256 users are in memory. So it will take more time in future. |
|
In a MG5050 it is similar (the time). Can you use the USERS conf parameter to restrict the users loaded? Many places will have less than 10. |
Draft state parsing for EVO.
EVO status cache caches memory blocks. Probably cache needs to move to panel class. Subparsers instead of adapters for Zones and Partitions.
lib, lib64 removed from ignore list.
|
Everything is working with MG/SP. |
New pull request from a branch in your repo.
I continue to move stuff out of paradox.py.
I have decided to split evo status parsing to separate branch as it touches sp/mg stuff as well. Maybe we need some changes before merging.
@jpbarraca Please take a look.
By the way. What is cfg.BUSES? EVO probably does not have it.
As it does not have REPEATERS and KEYPADS.
I probably need to add MODULES to the config.