[Solved] OH: OwnTracks; OH web map does not show last recorded item

OH 2.4.0 apt-get install on rPi3 stretch.

It is this time of year when tackle OH problems…

My OH works with OwnTracks via mosquitto; works perfectly well.

However, when I arrive at whatever destination, and a short while later, the map does not show the location pin on the map; in fact it does not show a map at all… while the map and pin are there while updates are sent.

Has this got to do with sitemap updates?
What I noticed in REST is the item holding the coordinates is empty, after a few seconds.
Considering that a location message is only sent every so often, why is this item set to undefined and thus clearing the map?

2019-09-02 21:06:52.817 [vent.ItemStateChangedEvent] - GeoLoc_MaxG_Coord changed from -25.82441125122754,151.8969802675012 to undefined,undefined

Expected result:
Keep the last position, until it moves again… (would be nice)

I cannot figure out where to look or troubleshoot this problem.
Any hints appreciated.

Presumably something is clearing out the location Item at some point. But what and when is that occurring? Look in events.log and see if there is some sort of pattern. Does the Item get cleared a certain number of minutes or seconds after the last change in state? Do you have Expire based timers in place on these Items? It is telling that the Item is changing to UNDEF as that value is usually used by bindings to report that an Item is in an unknown state. Are you using the Mqttitude/OwnTracks binding? Do you see any errors or warnings in the logs from this binding?

Now, for the part you will not want to hear. Using OwnTracks with MQTT is deprecated. There is a new(ish, it’s been around for about a year) GPSTracker binding which uses REST API calls instead of MQTT. If the problem is in fact the binding, then the solution may require moving to this new binding.

1 Like

Presumably something is clearing out the location Item at some point.

  • Yes :slight_smile:

But what and when is that occurring?

  • Good question :slight_smile:

Look in events.log and see if there is some sort of pattern.

  • will have a closer look, but could not see anythign else other than the messages being picked up

Does the Item get cleared a certain number of minutes or seconds after the last change in state?

  • It disappears literally when I switch off tracking on the phone, by killing the app. Yet, no message of that effect arrives at the broker (mosquitto). When I look up REST, the GeoLoc_MaxG_Raw item is UNDEF

  • Do you have Expire based timers in place on these Items?

Yes, I am using expire, but not on this item, or any other that goes as parameter into this map.

  • It is telling that the Item is changing to UNDEF as that value is usually used by bindings to report that an Item is in an unknown state.

  • U Are you using the Mqttitude/OwnTracks binding?

No. I am using the OT-recorder software (Linux) and app (iPhone), sending mqtt messages, recieved by mosquitto. OH picks up this message with"

String   GeoLoc_MaxG_Raw		    "Max Raw [%s]"										            	(gGeoMax)	{mqtt="<[mymosquitto:owntracks/owntracks/maxg-iphone:state:default]"}

String   GeoLoc_MaxG_Coord		  "Max Coord [%s]"						      <coordinates>	(gGeoMax)	{mqtt="<[mymosquitto:owntracks/owntracks/maxg-iphone:state:JS(mqttitude-coordinates.js)]"}

Do you see any errors or warnings in the logs from this binding?

  • No; not using the binding

Now, for the part you will not want to hear.

  • It is what it is… happy to go with the flow. :slight_smile:

Using OwnTracks with MQTT is deprecated. There is a new(ish, it’s been around for about a year) GPSTracker binding which uses REST API calls instead of MQTT. If the problem is in fact the binding, then the solution may require moving to this new binding.

  • I would have to read up on this.
    Are you referring to the GPS(whatever)binding for OH, or OwnTracks (as in OT-recorder) no longer supporting MQTT? I shall find out.

As always: I appreciate your help!

Huh… was also revisiting my persistence business, as in not using groups, but explicitly adding items to the rrd4j group.
Adding the item to persist brought the map back up with the last recorded value! :slight_smile: