Thanks for the feedback. I will talk to the team on Monday about the docs for ser2sock and the dependencies needed if SSL is enabled.
Minicom is a little off topic but I can bring that back a little and its a good topic.
So Minicom has been one of the suggested tools to configure the AlarmDecoder but it has been a real problem as you found out and as my good friend berkinet here on the forums would say it has a VERY low
WAF 
and its just overly complex for such a simple task. This is why we suggest putty but thats no help for embedded applications.
Minicom by default wants to "initialize" modems or send long strings of
Hayes modem commands to the serial device. The AD2 is not a modem but like a modem will gladly gobble up all the data minicom sends to it. These modem init commands have been known to trigger alarms as you found out. The -o option was suggested to prevent this behavior but as you found its possible to re-trigger the behavior inside of some of minicoms configuration screens so in the end minicom needs to be removed from all docs and a suitable replacment found for testing and initial configuration of the AD2*.
Now to bring it back on topic of ser2sock. I am thinking about creating a branch of ser2sock that allows for a non daemon mode where it watches the keypad for input and then sends the input directly to the attached serial device and thus provides all that is needed to interact with the AD2* from a terminal and we can stop suggesting minicom. It would likely still require a control sequence to exit like minicom
CRTL-a q gets you out but I would echo that to the user upon startup
if one were to run ser2sock under
Screen then it would be possible to ssh back into your AD2* appliance and reconnect to your screen ('screen -r') and start talking to your panel directly. Detaching from the screen with
CRTL-a CRTL-d would leave ser2sock running as if it were a daemon.
Re
Sean M
