Adding Comments to Web Log
in SecuritySpy
Greetings.
I am using sSpy in consort with a Hubitat Elevation Hub. Would it be possible to modify the API so that a Label(?) could be included in HTTP GET & POST that would write the label to sSpy's web log so a rule's actions could be readily followd.
Initially I added a Get Request with a "Rule Label" in my rules. That worked OK.
Presently: I am creating user accounts named for the rule and this provides the level of granularity I am seeking. It would be easier however if I was just able to add a label to each rule.
I'm not a coder so I have no idea if this is feasible and/or reasonable.
Thanks for your efforts.
cjs
P.S. Great Product!
Comments
Great to hear you like the software! The web log is not designed to be machine-readable. What exactly are you trying to achieve here? Maybe I can suggest another way.
Hi.
My intent is to make the log more "human readable." Log Snippet of my end goal.
I have been replacing a generic user account "top" with user accounts named for the rule that makes the GET/POST request. This method is working fine but I was thinking it would be nice to be able to include a label in a GET/POST request vs. creating multiple user accounts.
Make sense?
09/02/2022 21:26:13 192.168.1.79 GET /Keena_Comes_In
09/02/2022 21:26:13 192.168.1.79 GET /ptz/command?cameraNum=1&command=12&base64
09/02/2022 21:26:13 KeenaComesIn@192.168.1.79 GET /index.html
09/02/2022 21:26:13 top@192.168.1.79 GET /ptz/command?cameraNum=1&command=12&auth=base64
09/02/2022 21:26:13 top@192.168.1.79 POST /camerasettings?auth=base64
09/02/2022 21:26:13 top@192.168.1.79 GET /index.html
09/02/2022 21:26:13 top@192.168.1.79 GET /triggermd?cameraNum=1&auth=base64
09/02/2022 21:26:13 top@192.168.1.79 GET /setSchedule?cameraNum=1&schedule=0&override=2&mode=C&auth=base64``
09/02/2022 21:35:49 top@192.168.1.79 GET /triggermd?cameraNum=1&auth=base64
09/02/2022 21:35:49 Guest@192.168.1.65 GET /ptz/command?cameraNum=1&command=12&auth=R3Vlc3Q6MUshort
09/02/2022 21:35:49 top@192.168.1.79 POST /camerasettings?auth=base64
09/02/2022 21:35:49 top@192.168.1.79 GET /index.html
09/02/2022 22:01:10 top@192.168.1.79 GET /setSchedule?cameraNum=1&schedule=0&override=0&mode=C&auth=base64
09/02/2022 22:04:36 192.168.1.79 GET /Keena_Comes_In
09/02/2022 22:04:36 192.168.1.79 GET /ptz/command?cameraNum=1&command=12&base64
09/02/2022 22:04:36 KeenaComesIn@192.168.1.79 POST /camerasettings?auth=S2VlbmFDbzebra
09/02/2022 22:04:36 KeenaComesIn@192.168.1.79 GET /index.html
09/02/2022 22:04:36 KeenaComesIn@192.168.1.79 GET /triggermd?cameraNum=1&auth=S2VlbmFDbzebra
09/03/2022 00:11:12 Guest@192.168.1.65 GET /ptz/command?cameraNum=1&command=12&auth=R3Vlc3Q6MUshort
09/03/2022 00:11:12 top@192.168.1.79 POST /camerasettings?auth=base64
09/03/2022 00:11:12 top@192.168.1.79 GET /index.html
09/03/2022 00:11:21 top@192.168.1.79 GET /ptz/command?cameraNum=1&command=12&auth=base64
09/03/2022 00:11:21 top@192.168.1.79 POST /camerasettings?auth=base64
09/03/2022 00:11:21 top@192.168.1.79 GET /triggermd?cameraNum=1&auth=base64
09/03/2022 00:11:21 top@192.168.1.79 GET /setSchedule?cameraNum=1&schedule=0&override=2&mode=C&auth=base64
09/03/2022 00:11:21 top@192.168.1.79 GET /index.html
09/03/2022 01:05:08 192.168.1.79 GET /ptz/command?cameraNum=1&command=12&base64
09/03/2022 01:05:08 KeenaComesIn@192.168.1.79 GET /triggermd?cameraNum=1&auth=S2VlbmFDbzebra
09/03/2022 01:05:08 192.168.1.79 GET /Keena_Comes_In
09/03/2022 01:05:08 KeenaComesIn@192.168.1.79 POST /camerasettings?auth=S2VlbmFDbzebra
09/03/2022 01:05:08 KeenaComesIn@192.168.1.79 GET /index.html
09/03/2022 02:35:55 top@192.168.1.79 GET /setSchedule?cameraNum=1&schedule=0&override=0&mode=C&auth=base64
09/03/2022 04:40:00 top@192.168.1.79 POST /camerasettings?auth=base64
09/03/2022 04:40:00 Guest@192.168.1.65 GET /ptz/command?cameraNum=1&command=12&auth=R3Vlc3Q6MUshort
09/03/2022 04:40:00 top@192.168.1.79 GET /triggermd?cameraNum=1&auth=base64
09/03/2022 04:40:00 top@192.168.1.79 GET /index.html09/03/2022 06:27:14 192.168.1.79 GET /Capture_Garage_Motion_Activity
09/03/2022 06:27:14 192.168.1.79 GET /ptz/command?cameraNum=1&command=12&auth=X
09/03/2022 06:27:14 top@192.168.1.79 POST /camerasettings?auth=base64
09/03/2022 06:27:14 top@192.168.1.79 GET /triggermd?cameraNum=1&auth=base64
09/03/2022 06:27:14 top@192.168.1.79 GET /index.html
09/03/2022 06:48:50 KeenaGoesOut@192.168.1.79 GET /triggermd?cameraNum=1&auth=S2Vlbmshortened
09/03/2022 06:48:50 KeenaGoesOut@192.168.1.79 POST /camerasettings?auth=S2Vlbmshortened
09/03/2022 06:48:50 KeenaGoesOut@192.168.1.79 GET /ptz/command?cameraNum=1&command=12&auth=S2Vlbmshortened
09/03/2022 06:48:50 KeenaGoesOut@192.168.1.79 GET /index.html
09/03/2022 06:50:54 Guest@192.168.0.83 GET /video?cameraNum=1&auth=R3Vlc3Q6MUshort
Sorry but I'm struggling to understand what the benefit of such a feature would be. Could you please explain why this would be useful? The purpose of the log is to check who is accessing the web server and what resources they are accessing, mainly for security purposes - it's not designed to be a log of events, or to contain information beyond the details of each connection.
1st Off: In addition to a great product; this forum is a significant reason why I use sSpy. This forum works towards improving our respective knowledge and understanding in a respectful way and that is a joy.
"The purpose of the log is to check who is accessing the web server and what resources they are accessing"
At the moment, I am the only human accessing the server. My "users" are the Hubitat rules which I have concocted to tweak sSpy settings to suit my needs. When I began meshing sSpy (camera management) with my Hubitat I used a lone sSpy web account in my Hubitat rules to authenticate. With the creation of each new Hubitat Rule I was essentially (albeit not on the sSpy web server) creating a new user manipulating sSpy resources differently. I only came upon this realization/thought a few days ago when troubleshooting an error and having to spend a lot of time moving between the logs of sSpy and Hubitat.
e.g. "Continuous Recording" was being prematurely disarmed by my Hubitat Rule - KeenaGoesOut. This access and resource use, I traced back a User named "KeenaGoesOut."
09/03/2022 06:48:50 KeenaGoesOut@192.168.1.79 POST /camerasettings?auth=S2Vlbmshortened
Previously in order to troubleshoot a rule sending a problematic command sent to sSpy server I was coordinating the time stamp between sSpy and Hubitat as all the commands were authored by same sSpy User named "top" - 09/03/2022 06:27:14 top@192.168.1.79 POST /camerasettings?auth=base64
Hopefully this explanation attempt mitigates the struggle. :-)
Regardless I stumbled upon a solution to a non-problem(?) of my own making that makes debugging easier for me. There is nothing broken per se, so all is good.
cjs
Thank you for the detained explanation, and for your kind words about the software and forum, I'm glad to hear that SecuritySpy has been so useful for you and it's also great to hear how you are using it and integrating it with Hubitat.
I'm slightly less confused now :) What you can do is to add any parameter you like to any request - this way, you can set the value of this parameter to be different for each rule, and this will allow you to trace the particular rule to a particular entry in the log.
So, for example, for the request to set camera settings, you can use the following:
/camerasettings?auth=S2Vlbmshortened&hubitat=rule23
SecuritySpy will ignore any parameters it doesn't understand.
What do you think?
Thank you Ben.
I had previously tried this (so I thought). duh! my syntax was incorrect. I was adding the parameter to the body of the POST vs. including it in the request. I tried this and it works as expected. Thank you for your help and insight with this.
Truth be told. Though this does work, I spoiled myself by creating user accounts named for the rules. The log readability is easier on the eyes when the rule name is the user name vs having the rule name appended to the end. Make sense? This is all good as I now have two options available to me to debug + I learned something. Thanks again.
cjs
This is good stuff. I was searching on here for Hubitat because I just got a C-8, and after a few days of getting it all figured out, I've got a pretty elaborate security system working - and I just discovered the "Maker API" app in Hubitat, which exposes device parameters (on/off bulb level/color etc) as http GET endpoints, so now when SecSpy detects motion and triggers an action, it calls a shell script with these simple curl -X https://etc endpoints and turns on lights & sound. It's amazing how easy it is to get this stuff working with Security Spy!