[Ovmsdev] Car lost GPRS connection notification
tom at idleloop.com
Wed May 16 01:04:15 HKT 2012
That's a good point about sending SMS from the server. I'll just be sure
push is turned on when I'm monitoring remote charging.
on 5/14/12 10:48 PM, Mark Webb-Johnson wrote:
> Supporting SMS would mean having to do this from the car, which is much more
> tricky (particular if you want to control time of day for notifications).
> Doing this in the car would mean we could SMS but not PUSH notify. Doing it on
> the server would mean we could PUSH notify but not SMS.
> I didn't really want to do this in the car because what if the car lost
> network connectivity? We can't issue the SMS.
> In theory, we can do SMS from the server, but that means paid plans and the
> server needing to know contact telephone numbers - which is messy.
> Regards, Mark.
> On 15 May, 2012, at 1:36 PM, Tom Saxton wrote:
>> I think it's a great idea and would like to have it. I generally leave push
>> turned off to reduce battery usage, so I'd prefer a text message.
>> I'm thinking of being on the road, charging in some rural area with spotty
>> coverage, and expecting that if the charge gets interrupted (unplugged, pops
>> the breaker, whatever), then I'll get a text message. If the cars loses the
>> connection, I'd like to be notified of that promptly so I know I need to
>> check on the car.
>> I would want to selectively enable, as I don't want a text message in the
>> middle of the night if the car loses the connection while in our garage.
>> on 5/14/12 10:14 PM, Mark Webb-Johnson wrote:
>>> Rafael has suggested that we add a car-lost-gprs-connection notification to
>>> the OVMS system. The idea being that when your car loses GPRS connection
>>> (cellular coverage, fault, whatever), you get a notification to your app to
>>> let you know. And, presumably, another notification should it come back.
>>> It is common for a car to lose cellular connection for a minute or so, then
>>> It is also reasonably common to lose connectivity when the GSM signal is
>>> It does seem a nice idea, and not too hard to do.
>>> The way it would work would be to have a threshold in the server. A
>>> notification time, presumably in seconds.
>>> If a car disconnected (or 20 minute timeout was force disconnected), we
>>> put a record in a pending table, timestamped NOW()+thresholdseconds.
>>> If the car connected, and the pending table has a record for that car, we
>>> would just remove the record.
>>> If the car connected, and there was no pending table record for that car, we
>>> would send a push notification for all apps on that car to tell them that
>>> car is connected.
>>> Periodically, we check the pending table and if any records have timed out,
>>> (a) send a push notification for all the apps on that car to tell them that
>>> the car has disconnected, and (b) remove the record.
>>> The result of this is that if the car disconnects for a short time, then
>>> reconnects, no notification is raised. But, if the car disconnects for a
>>> time, you get a notification both when we find it has disconnected and when
>>> see it reconnect. This can all be done from the server, irrespective of
>>> version of firmware in the car/apps.
>>> The questions are: (a) what do people think, (b) what should a reasonable
>>> timeout be, and (c) could this be _on_ for everyone.
>>> Would anyone here _not_ want this?
>>> I would suggest a reasonable timeout, to alert after, would be an hour or
>>> It is easier to code this if it is universally on for everyone - we can just
>>> have a single timeout in the server. If we want individual control, we'd
>>> to have a setting per-vehicle and provide the users a mechanism to change
>>> setting. That would be much more work.
>>> Regards, Mark.
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
More information about the OvmsDev