Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle unknown TPI response codes gracefully. (tornado) #45

Open
rct opened this issue Jul 1, 2016 · 2 comments
Open

Handle unknown TPI response codes gracefully. (tornado) #45

rct opened this issue Jul 1, 2016 · 2 comments

Comments

@rct
Copy link
Collaborator

rct commented Jul 1, 2016

AlarmServer should handle unknown TPI codes gracefully.

Currently with the feature/tornado branch, an unknown code generates a KeyError and then AlarmServer is broken but still running.

See #46 for an explanation of the 616 code which was added to TPI 1.07.

Jul 01 09:48:04 - ERROR: Future exception was never retrieved: Traceback (most recent call last):
  File "alarmserver/python/tornado-4.3-py2.6-linux-i686.egg/tornado/gen.py", line 282, in wrapper
    yielded = next(result)
  File "alarmserver/juggie/AlarmServer/core/envisalink.py", line 105, in handle_line
    event = getMessageType(int(code))
  File "alarmserver/juggie/AlarmServer/core/envisalink.py", line 17, in getMessageType
    return evl_ResponseTypes[code]
KeyError: 616
rct added a commit to rct/AlarmServer that referenced this issue Jul 7, 2016
* handle (and log) unknown TPI response codes. Fixes juggie#45
* handle TPI timestamps if enabled. Fixes juggie#43
* validate TPI input and verify checksum
@rct rct closed this as completed Jul 8, 2016
@rct
Copy link
Collaborator Author

rct commented Jul 8, 2016

With #49 (tornado) it will now log the unknown message and keep processing normally. Will add definition for the new zone bypass code, 616 shortly.

@rct
Copy link
Collaborator Author

rct commented Aug 22, 2017

Reopening - This isn't working as intended.

I maybe misunderstanding things, but I'm guessing there is a structural problem with envisalink.py:handle_line(). All of the error handling in handle_line does a return which I think breaks things because that means the code never gets to the yield which causes the next read to occur.

Actually maybe this should be a separate/new issue.

@rct rct reopened this Aug 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant