[Solved] Internal Server Error - during new webapp setup

[l2g]

Hey guys,

I'm packaging everything into installable RPMs for both CentOS (Red Hat) 6.x an 7.x as well as intending to blog about it all @ http://nuxref.com but I've hit a wall.

I'm so close to getting this thing to light up like a Christmas tree; i can feel it!

I've satisfied all of the the dependencies, nginx, ser2sock, alarmdecode and alarmdecode-web app are all in place.
I initialized the database without a problem (had a bit of issues with SELinux but I'll work on a module after i get this going; it's disabled for now).

i can telnet to ser2sock and see my alarm status perfect, and i can use your example scripts you provide on the alarmdecode website to communicate with the device that way too.

Soo... my problem:

the alarmdecoder-webapp is installed and i get a nice welcome page and a blue 'Start!' button to begin the initial configuration, but when i press it i get an 'Internal Server Error'.

It isn't logging anything into my instance/log/info.log file (From gunicorn) and it isn't logging anything into nginx's error.log. However, it is logging the entry in the (nginx) access.log as an error 500. So i presume my gunicorn instance is mad at me?

The url that bombs is the first one after pressing 'Start!' (in my case): https://localhost:9443/setup/type

Code: Select all

telnet 127.0.0.1 5000
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
GET /setup/type HTTP/1.1

HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
Connection: close
Content-Length: 21
Date: Fri, 29 Apr 2016 03:43:43 GMT

Internal Server Error
Connection closed by foreign host.


What can i do to turn on more debugging? Or does this error ring a bell? I tried searching the forum without any success.

Chris

[kevin]

Kill off the gunicorn process and try to run it manually from the command line, something like

Code: Select all

sudo /usr/bin/python /usr/bin/gunicorn --pid /var/run/gunicorn/alarmdecoder.pid --name alarmdecoder --user pi --group dialout --log-file /var/log/gunicorn/alarmdecoder.log --worker-class=socketio.sgunicorn.GeventSocketIOWorker --timeout=120 --env=POLICY_SERVER=0 --workers=1 --log-level=debug --log-file=/tmp/alarmdecoder.log wsgi:application


Then check the /tmp/alarmdecoder.log and hopefully you have something more to go on. This has recently come up, and I think it had something to do with the python "gevent" module and unicode locale settings.

[l2g]

Thanks for your help,

I didn't realize alarmdecoder-webapp gunicorn instance spawned a new thread and was hard-coded to use port 5000 (in some discovery module?); what's that if you don't mind me asking? Port 5000 was coincidentally was the port i decided I'd use in my gunicorn configuration file i set up (so i was conflicting here with it's spawn). Anyway, changing it to a different port (I chose 5001) fixed it.

I also got the unicode issue you were talking about too and patched that as well. If that's any use to you: This StackOverflow question led me to this Python bug that was declared a feature (go figure) and closed.

I fixed it by patching python-flask-wtf to just ensure the self.SECRET_KEY is never of type unicode (and now everything works great).

Here is the patch in case it's of any use to anyone else:

Code: Select all

diff -Naur Flask-WTF-0.12/flask_wtf/form.py Flask-WTF-0.12.patched/flask_wtf/form.py
--- Flask-WTF-0.12/flask_wtf/form.py   2015-06-22 22:41:51.000000000 -0400
+++ Flask-WTF-0.12.patched/flask_wtf/form.py   2016-04-29 20:37:56.192507711 -0400
@@ -88,6 +88,9 @@
                 secret_key = getattr(self, "SECRET_KEY", None)
 
             self.SECRET_KEY = secret_key
+            # http://bugs.python.org/issue5285 - Handle HVAC
+            if isinstance(self.SECRET_KEY, unicode):
+                self.SECRET_KEY = self.SECRET_KEY.encode('utf-8')
         else:
             csrf_context = {}
             self.SECRET_KEY = ''


[kevin]

The WSGI app itself is configured as port 5000 and sets itself as such on startup as you've noticed, the discovery you are seeing is the ssdp discovery so things like the SmartThings platform can detect the device on the network and use it. (basically UPnP but not the whole protocol)

[l2g]

Thanks for the info Kevin,

Before i let this thread die, I've got one new problem. The keypad on the webapp doesn't seem to be acknowledging the keys i press. I have all of the debug information on you provided me earlier and there is no errors or anything. Things really seem like they're working great.

I'm using ser2sock (unencrypted) as the gateway for the webapp. It's displaying what's on the alarm panel perfectly and updating when the statuses change. Maybe i should change it to just switch to using the raw device instead? Hence what is involved in getting 'write' access (read is working perfectly)?

Just wanted to ping you for more advice!

Edit: doesn't work using the /dev/device either. The setup says that it can send/receive and (well i get 4 check boxes during the setup). Perhaps I shouldn't expect the display to change? Right now i intentionally have a door ajar, and the alarm says "Press * to see faults". So when i press '*' I guess I was hoping the display would change (as it would on the other keypad)? Should it?

Chris

[timlegge]

Likely your device (webapp keypad) is not addressed properly on the alarm panel:

See viewtopic.php?f=3&t=288

If it is working correctly you should be able to use telnet to arm and disarm the alarm

Tim

[l2g]

Thanks guys,

Marking the thread solved!

That was all it was! I enabled the wrong keypad address . It's all working great now.

Chris