mirror of
https://github.com/ushahidi/SMSSync.git
synced 2026-04-25 07:45:53 +03:00
[GH-ISSUE #160] Debug & Alerts #122
Labels
No labels
Bug report
Code improvement
Concern
Feature request
Feature request
Good first issue to work on
In progress
Needs info
Question
Ready
Translation
User Experience
User Experience
Website
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/SMSSync#122
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @eyedol on GitHub (Apr 25, 2014).
Original GitHub issue: https://github.com/ushahidi/SMSSync/issues/160
As improvement to the logging feature, we need a way to interact with SMSSync via SMS by sending simple keywords to SMSSync. Based on the received keyword, SMSSync will send a response back to the sender. This will enable remote debugging to figure out what might be wrong with the phone/server. Here are sample keywords with responses.
Admin sends
smsto phone runningSMSSyncStatus
Is cell reception okgets a responsecell reception okotherwise no response from SMSSync which means there is something wrong. We can use the PhoneStateListener API for this.Is server okgets a responseserver responded with <200>otherwise sends a reponsecannot reach server. Once SMSSync receives thesmsit will make a request to the server.battery levelgets a responsebattery level is <10%>otherwise no response from SMSSync which means phone is dead.get statusgets all of the above responses as a singlesmsAlerts
Status
To mitigate the issue of having to type a long sentence to query for status response from the phone or the potential of a normal message triggering a status query, it should use an @ prefix and a code instead. See comment by @browndav.
The table below list the query codes, the query, the query's positive and negative responses.
@10Is cell reception okcell reception ok@20Is server okserver responded with <HTTP Status Code> status codeeg.server responded with 200 status codeCannot reach server@30battery levelbattery level is <percentage of battery level>. eg.battery level is 10%@40get statusThe query codes sent as SMS shouldn't be sent to the configured
Sync URLAlerts
Scenario 1
If battery level of the device running SMSSync drops below 10%, SMSSync will make an HTTP GET request to the server with the following query params.
?task=alert&message=battery level is at <percentage of battery level>At the same time, SMSSync will send SMS with the message
battery level is at <percentage of battery level>to a phone number that has been configured at the Settings screen to receive alerts. For now it should be only one phone number and cannot be the phone number of the device.Scenario 2
If SMSSync failed to send SMS due to error reported by [sendMultipartTextMessage](http://developer.android.com/reference/android/telephony/SmsManager.html#sendMultipartTextMessage%28java.lang.String, java.lang.String, java.util.ArrayList<java.lang.String>, java.util.ArrayList<android.app.PendingIntent>, java.util.ArrayList<android.app.PendingIntent>%29) make an HTTP GET request to the server with the following query params.
?task=alert&message=<error message>See http://developer.android.com/reference/android/telephony/SmsManager.html for the error messages.Scenario 3
If data connection is lost for extended time (either WiFi, or GSM)
Send SMS with the message
No data connection on the deviceto the configured phone number.@mandric commented on GitHub (Apr 27, 2014):
+1
@ghost commented on GitHub (Apr 27, 2014):
I would just be careful to pick a very distinct header for the monitoring requests that's unlikely to be used by normal messages. Something like "Is cell reception ok" could easily be triggered inadvertently by a normal plain-text message (and might need to consider localization), whereas something abbreviated like
PWRwith a prefix like@@@or!!!is unlikely to get in the way.@eyedol commented on GitHub (May 8, 2014):
@browndav absolutely right. Maybe a short code to trigger these things. Something similar to
HTTPstatus code. Of course with what the codes map to documented.How does that sound?
@mandric commented on GitHub (May 13, 2014):
For the time being, does anyone happen to know of any separate apps that take a URL and do some kind of monitoring, similar to this issue? Even just basic monitoring that does a GET on a URL and if not 200 status code then send an sms alert (throttled to some value), would be great.
@eyedol commented on GitHub (May 13, 2014):
@mandric not that I have come across. My search gives me this https://play.google.com/store/apps/details?id=com.sgr.servermonitor but it's very basic and doesn't seem to send any alert messages.
@KamilKalfas commented on GitHub (Jun 9, 2014):
So those keywords are in body of sms ? Should we search for it in whole text or message must contain only 'the keyword' ? And I agree with prefix idea.
@mandric commented on GitHub (Jun 9, 2014):
Ran across this project, which does basic http monitoring and notification via SMS on failure. https://code.google.com/p/httpmon/
Also had the thought, maybe this issue could be a standalone app?
@KamilKalfas commented on GitHub (Jun 10, 2014):
@mandric it's doable but i don't think there is a need to do that. Anyway in case of new app we would need some spec, repo and etc. @eyedol what are your thoughts ?
@ghost commented on GitHub (Jun 10, 2014):
I don't think external monitoring apps are necessarily in scope for SMSsync; @mandric, you might make an issue over on Medic's side and we could take a look at it.
@eyedol commented on GitHub (Jun 10, 2014):
With
SMSSyncwe can always make a request to an externalHTTPserver to check it's status. What we do need is something that theHTTPserver can use to reach out to the device runningSMSSync. What I can think of is some sort of an internalHTTPserver running on the phone( a public IP is needed to ping it I guess ) that the server can issue a request to figure out it's status.@mandric commented on GitHub (Jun 10, 2014):
@browndav this issue could easily turn into a basic monitoring app, so it's already in scope. The positives I see going standalone are:
I'm trying to see a feature in this issue that is directly coupled with SMSSync and failing to see any. Let me know what you think the downsides are.
@eyedol I agree that two-way communication is good but do you think it's necessary for this first rev?
@KamilKalfas commented on GitHub (Jun 11, 2014):
OK, so we should decide something cause i would like continue work on this.
@mandric commented on GitHub (Jun 11, 2014):
@KamilKalfas I think the consensus right now is not standalone, so you can continue working on it. Didn't mean to slow things down.
@KamilKalfas commented on GitHub (Jun 17, 2014):
OK guys, few things. Someone should define those sms. What prefix should they contain and I believe that is more user friendly to use only one word. Next thing is post alert to the server, should I use standard URL or would you like to add some params ? What information should be in those post alerts ? And the last one, @eyedol 'stored phone number' could you explain me where is thin number stored ?
@KamilKalfas commented on GitHub (Jun 17, 2014):
Oh also would be nice to know an endpoint/s for Status response so it would be clear and ready to implement. @mandric can you prepare similar spec to #11 only with request examples, if you have time. Because i see some lacks of information to finish this issue.
@mandric commented on GitHub (Jun 17, 2014):
Thanks for the update @KamilKalfas , I will make some time to put together some API request examples tomorrow. Also @eyedol if you have something specific in mind please let me know.
@mandric commented on GitHub (Jul 24, 2014):
@eyedol just thinking about this one a bit. Is there a reason we are doing the SMS based queries vs something server side? It's great when the connection with the server goes down to send an SMS, but querying the handset statistics via SMS is not as useful as getting data into the server? I could see another polling request option in SMSSync that just sends these data statistics to the server every [frequency].
Do we prefer that as the first part of this feature?
@eyedol commented on GitHub (Jul 28, 2014):
@mandric so at any point in time you can query for the status of the phone and get response via SMS and not have to login to the server to figure out what's going on. Some alert responses are however sent to the server as well. Also to avoid hogging the phone with too much work.
@mandric commented on GitHub (Aug 13, 2014):
Is there a reason we're doing GET requests when sending alert messages to the server? I'm thinking these should be POST requests because the server should process them and create or modify a record on the server?
@eyedol commented on GitHub (Aug 14, 2014):
I agree with
POSTrequest. Amended the spec.@mpandi commented on GitHub (Jul 26, 2016):
After an SMS has been synced..I am not bale to delete from the phone...0 messages deleted