The level of details depends on the purpose of the diagram, aimed audience and its abstraction level.
Is it a conceptual level modelling, early analysis stage? Than just a conceptual entities, classes and objects with corresponding sequences or states will do the job. Only few or no methods, attributes without types, tec.
Is it a clarification diagram to talk with business people? An activity would probably be the best choice.
Is it a low-level implementation diagram, for developers to use it as a specification? Then you should use classes with concrete stereotypes, attributes and methods, with sequences/stats/communications.
For your example, I would first create a class (i.e. ClientLocator) to encapsulate this logic. You can also stereotype it to indicate the prog. language (<>, <<.NET>>, etc). This class then needs a method updateLocation() (stereotyped with <>) to implement this logic. I would also add a state machine to this class to model this 30-secs trigger and eventually other states. An additional sequence diagram to further specify that happens can surely come in handy.
Finally an advice. As UML is very abstarct and semantically open, simply try to be pragmatic. Keep your model purpose and aimed audience in mind and do whatever will maximaze the expresivness and communicate your message.