Test button about smssync

[olliebennett]

In order to test the setup, I simply send myself a SMS message, and then monitor what request the server receives.

I agree that a test button would be useful, but would also add complexity and it could be unintuitive for the user as to what the button really does.

[eyedol]

When a test button is hit, it should send a ping to the configured URL. Upon successful ping, the test should expect a JSON format as below

{
    payload: {
        success: "true"
    }
}

Or

{
    payload: {
        success: "false"
    }
}

We can safely assume the SYNC URL is properly configured.

Return a Success or Failure depending on the status of the test.

[mitra42]

I think Github failed to post my comment - apologies if there is a delay and this gets duplicated.

I think that we want more from the test than this. This is commonly going to be used to check the phone, and also for diagnostics to split the problem between Mobile <> Smsync and SMSsync <> Server
The human intelligence could be either end - someone in the field trying to figure out what is working, or a support person at the server giving instructions to a non-smssync literate person in the field.

Ideally it should
a) let the holder of the phone know its configured correctly
b) let them know the server is working properly.
c) If forwarded to a support person, provide useful information to help diagnose problems.

I suggest that the message should be a correctly formatted SMS request - i.e. json to the server, and that the settings AND the phone number of the phone - should be packed into it (maybe also the location) . In case (c) this could be passed onto the support person who can check the settings, and confirm that for example in Peru the smssync gateway sits at phone number 123456

The response should also look like a SMS message - it could be human readable (allowing instructions on changing settings) or any server diagnostic message (for case b). Maybe it should be packaged so its destination phoen number is the one in the request packet).

I don't think I'm complicating it too much ?

[eyedol]

@mitra42 what you've said above is more like what we want to do with the Log viewer feature. See #97

This issue is going to fix scenario a)

[mitra42]

I don't think these are the same thing at all - #97 doesn't seem to solve any of a,b or c - maybe c, but only then if the log contains enough info for hte support person to diagnose the problem.