alarmdecoder.com

Hello,

I was running Alarmdecoder and the webapp fine for many months. Recently, I noticed there were some updates so I updated (I don't normally use the webapp interface, so I don't see the update notifications regularly).

At first, my email notifications had weird lists of timestamps. I figured something got messed up during the upgrade with the way the settings are stored. I created new notifications, which cleared up the huge list of timestamps on each message, but now there is no timestamp at all. I know there's a checkbox to suppress timestamps now, and it is unchecked. I even tried checking it, saving, and unchecking it and saving again, but it makes no difference.

Does anyone have any suggestions on how to resolve this? Is there a file I should look on the the Raspberry Pi to verify the setting? Any help would be much appreciated!

Thanks!

Something around here

https://github.com/nutechsoftware/alarm ... es.py#L331

Thanks, Kevin.

I "fixed" it by forcing this to false in the code. But I haven't debugged why the setting isn't getting retrieved properly. I did check the database using a SQLite DB browser and the suppress_timestamp option is set to int 0.

However, once I fixed it, I discovered something I saw before--the subject of messages has a growing list of timestamps from all of the alerts that have occurred. I believe it's because of this line:
self.subject = self.subject + " ( " + message_timestamp + ")"
(https://github.com/nutechsoftware/alarm ... es.py#L342)

I think this is actually appending timestamps to the stored subject of the message for that notification. Well, perhaps the in-memory version of the subject, as I think restarting it resets the "list."

I modified this by just using a local variable "subject":
subject = self.subject + " ( " + message_timestamp + ")"
and updating where the email is compiled appropriately. That seems to have worked.

I still haven't figured out why the timestamp option isn't being read properly, though.

Thanks!

If you enable suppression, what does the value change to in the database?

Might have to add extra checks - if self.suppress... is False or self.suppress... is 0 or self.suppress... is None:

Hi, Kevin,

Changing the suppress_timestamp option in the UI to checked does, in fact, change the value in the DB to int 1.

Thanks.

Kevin,

Ok, you're right. It looks like suppress_timestamp should be compared to 0 ("==0") instead of False. That makes it work. I don't know enough about Python or how the options are stored and retrieved to really know why the author of the change thought this would work with False (other than the "default=False" in the option retrieval that they mimicked from the "suppress" option says 'False'). It seems it should have been obvious that this didn't work through a simple test of the feature, unless I'm missing something. Does this work as it is checked-in for others?

Thanks.

I wrote it and forgot that settings table is not normal, it's my bad but an easy fix - while it did work in testing, I never tested it with a fresh database to see if it would work for others before it got pushed. One of those things that got pushed out the door right before I left the company.

Hi, Kevin,

Oh, you left the company but are still active in this forum? That's very kind of you.

Will this get resolved now that it's been reported here, or do I need to open an issue in Git? (I've never done any of that.)

I've fixed it for myself in my deployment, but I'm not sure what a modified file like that is going to do for future updates. I'm guessing they'll just get blown away with the new files.

Thanks!

Hey,

So you can either file an issue and revert your file (git checkout -- file) when an update gets pushed so the updater will work

OR

You can go through the pull request process on github through your own repository with the fixed code

your choice