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

Custom notifications broken -- partial fix offered #99

Open
star-glider opened this issue Mar 12, 2024 · 1 comment
Open

Custom notifications broken -- partial fix offered #99

star-glider opened this issue Mar 12, 2024 · 1 comment

Comments

@star-glider
Copy link

The custom notification option is broken; the notify_data dictionary is always empty. There's quite a bit of code that works over this dictionary (lines 1182 through 1204 in types.py), but none of it runs because custom_values is blank. I haven't dug in deeply enough to really understand what's going on here; it's way more code than exists in the other notification methods, and I'm not sure why.

I ran into this trying to set up Slack notifications (JSON POST) and threw in a quick patch to get it working. Basically, I just skip over all of the inactive code, create a dictionary directly in a manner similar to the other notification methods, and then reference that in the _do_post method call. Since the project isn't being maintained, I don't think it's worth the time to submit a pull request (and do the associated work to figure out why there's all that additional code), but I figured I'd drop my patch in here just in case it helps anyone.

Two notes: 1) the modification to line 1144 was just me troubleshooting; it's not relevant to the fix but is kind of a nice-to-have; 2) the new "message_string" variable includes a version of the "Subject" option from the email notification, but I just harcoded in the message instead of modifying the web forms to offer it as a front-end-selectable option, mainly because I'm lazy. Presumably, if you're applying this patch, you can just type in whatever you want there or just set it equal to the 'text' variable to eliminate it entirely.

I know the project is essentially abandoned, but it's a great addition to these old (and very reliable) ADEMCO systems. As long as you're running it behind a firewall with no ports exposed, there's really not much risk in running an old image with so little attack surface, and while old it works just perfectly (kind of like my 20-year-old alarm system)!

I hope this helps someone.

pi@alarm-controller:/opt/alarmdecoder-webapp/ad2web/notifications $ diff -u types.backup types.py
--- types.backup        2024-03-11 22:58:01.365754219 -0700
+++ types.py    2024-03-12 00:49:32.200027460 -0700
@@ -1141,7 +1141,7 @@
             return True
         else:
             app.logger.info('Event Custom Notification Failed')
-            raise Exception('Custom Notification Failed (' + str(http_response.status) + ") " + http_response.reason)
+            raise Exception('Custom Notification Failed (' + str(http_response.status) + ") " + http_response.reason + " Headers:" + str(self.headers) + " Body:" + str(data))

     # Warning: Threaded so it may be sent later and state may change.
     # Never access any AD2* state vars in a threaded function.
@@ -1175,6 +1175,8 @@
     @raise_with_stack
     def send(self, type, text, raw):
         self.msg_to_send = text
+        message_string = 'Primary Residence Alarm Event: %s' % text
+        json_data = {"text": message_string}

         result = False
         if check_time_restriction(self.starttime, self.endtime):
@@ -1211,7 +1213,7 @@
                    result =  self._do_post(self._dict_to_xml('notification', notify_data))

                 if self.post_type == JSON:
-                    result = self._do_post(self._dict_to_json(notify_data) )
+                    result = self._do_post(self._dict_to_json(json_data))

             if self.method == CUSTOM_METHOD_GET_TYPE:
                 if self.post_type == URLENCODE:
@edrikk
Copy link

edrikk commented Feb 23, 2025

@ajschmidt8
Given that you have commit access, I wanted to flag a few PRs/changes that I've been running cleanly for a couple of years. These changes will also enable updating/correcting the requirements.txt file.
I'll using this same "approve" comment across these items.

edrikk added a commit to edrikk/alarmdecoder-webapp that referenced this issue Feb 25, 2025
As provided by star-glider in issue:

nutechsoftware#99

The custom notification option is broken; the notify_data dictionary is always empty. There's quite a bit of code that works over this dictionary (lines 1182 through 1204 in types.py), but none of it runs because custom_values is blank. I haven't dug in deeply enough to really understand what's going on here; it's way more code than exists in the other notification methods, and I'm not sure why.

I ran into this trying to set up Slack notifications (JSON POST) and threw in a quick patch to get it working. Basically, I just skip over all of the inactive code, create a dictionary directly in a manner similar to the other notification methods, and then reference that in the _do_post method call. Since the project isn't being maintained, I don't think it's worth the time to submit a pull request (and do the associated work to figure out why there's all that additional code), but I figured I'd drop my patch in here just in case it helps anyone.

Two notes: 1) the modification to line 1144 was just me troubleshooting; it's not relevant to the fix but is kind of a nice-to-have; 2) the new "message_string" variable includes a version of the "Subject" option from the email notification, but I just harcoded in the message instead of modifying the web forms to offer it as a front-end-selectable option, mainly because I'm lazy. Presumably, if you're applying this patch, you can just type in whatever you want there or just set it equal to the 'text' variable to eliminate it entirely.

I know the project is essentially abandoned, but it's a great addition to these old (and very reliable) ADEMCO systems. As long as you're running it behind a firewall with no ports exposed, there's really not much risk in running an old image with so little attack surface, and while old it works just perfectly (kind of like my 20-year-old alarm system)!
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

2 participants