Remaining Webapp Bug?

[peterd]

First let me say that the webapp is terrific. I just got back from a trip overseas, and while I was gone was able to solve several problems (including high winds rattling a door and a stuck keypad button rattling a worker) by logging in to disarm, alarm, bypass, etc!

Last fall, I reported a bug which was (it seemed) slated to be resolved: viewtopic.php?f=3&t=117#p589

This week, I finally got around to updating to the most recent webapp version.Upon testing, I found the same bug seemed to exist.

So, my question is whether the fix involved database changes? (The updater failed (silently, but debugging in Chrome showed error 500), so I saved off the old directory and git-cloned again. I simply re-used my existing DB (didn't run the init script), so if that's where the filters were changed then it's my problem.) If not, then the bug still exists.

Please advise.
Peter

[kevin]

This particular issue has not been fixed yet. There are other changes that have been made that do include things with the database, however.

[peterd]

Thanks, Kevin.

What is the best way to update the database?

Peter

[kevin]

The update process should have taken care of that for you - the information log should show on startup if the database version you are running is good or not. If it says Database is Good, you should be fine. If not, you can attempt to run the manual scripts in the alembic directory - all else fails, you will have to start from scratch on your setup. Unfortunately the pre-release version's updater wasn't nearly as robust as it is now.

[peterd]

Well, there was no update process. The updater failed (silently, but debugging in Chrome showed error 500), so I saved off the old directory and git-cloned a fresh install. I simply re-used my existing DB (copied the instance directory, didn't run the init script).

Now, the updater believes my version is up to date, so at the moment there will be no update process. That's why I was asking what steps I should take to replicate what the updater would do to the database.

However, thanks for pointing me to the log. I see now that the DB updater did run on the first boot after I installed the new version. Looks like it worked fine:
"INFO: DBUpdater: success [in /opt/alarmdecoder-webapp/ad2web/updater/models.py:539]"

However, on every boot I'm getting the following entry:
"WARNING: Could not bind event "on_alarm_restored": alarmdecoder library is probably out of date. [in /opt/alarmdecoder-webapp/ad2web/decoder.py:240]"

Any suggestions?

[kevin]

In the source code it's in updater/models.py - DBUpdater class method update

Through python I believe in that directory you can create a dummy python file and instantiate a DBUpdater class

from .models import DBUpdater

db = DBUpdater()
db.update()

Theoretically that will go through the revisions and update them to the latest.

From the shell is a little tough, but I think you can just take the revisions in reverse order and use the upgrade method in each python file in the "alembic/versions" directory

[kevin]

Oh, ok, your database is good

You need to upgrade the alarmdecoder base library, which is a different project than the webapp, but both on the image in /opt by default

[peterd]

Thanks. Got it. (Or is it "Git it?")

[kevin]

Hey,

This is fixed in our local repository - I have not yet pushed to github, will probably do tomorrow after more testing, but until then, since you are comfortable with git etc, you can make the change yourself in the code - and just revert/recheck out when I push

in alarmdecoder/messages.py on or around line 176:

Code: Select all

self.cursor_location = int(self.bitfield[21:23], 16)


needs to be

Code: Select all

self.cursor_location = int(self.panel_data[21:23], 16)


After that change, just restart everything (reboot is easiest) and you should be good to go.

I will post again when I push so you can revert your change and get back on our branch.


Around the time you were doing this, you may have noticed an exception in the gunicorn log with regard to the cursor location - well, this is it. Now, the cursor location isn't taken into account on the display at the moment in the webapp, but it should not impede message flow any longer. Cursor support in webapp display coming soon.

[kevin]

All right, this change is pushed up to the dev branch of the alarmdecoder library