SMS Message Sent to Wrong Contact

As you apparently know, the key is to do a wired sync each and every time you make any change to contacts, or any other portion of your account. If you really were fully sync-d immediately before the trip, I can't account for the behavior.

It is very important to sync after any change to contacts. When you send a message to a contact (as opposed to typing in a phone number or e-mail address), the unit does not transmit the contact's phone number. Instead, it sends a very short code which the server then matches to the proper contact. This allows for more recipients without impacting the number of characters you can send in the message. If the unit and the server disagree on the meaning of the short code, the message may go to the "wrong" contact.

This problem is different (but likely related) from that reported by the OP. The use of the Earthmate app is a new factor, as is the change in behavior once an SMS recipient has replied to the message. I don't know enough about the older model inReach/app interaction to be able to suggest a workaround other than what you are currently doing. I do have one question, though. When you send the subsequent message (the one that goes to the wrong recipient), is this a new message thread or are you replying to the reply (if that makes any sense)?

If you are replying to the reply, you might try starting a new message thread instead.

Makes no difference. Either writing a new message entering the destination manually or reply to an existing response. The message goes to the wrong person and the length of the recipients address is not deducted from the available characters (indicating that it is not being included is the message).

I've received another response from Pivotel saying they'll look onto it - though they seem to be suspecting earthmate-inreach1.5 compatability issues whereas I'm fairly convinced it's an issue between earthmate and their satellite earth station/messaging gateway. They also say that whilst the inreach1.5 is still supported garmin no longer provide any support for it. Which may hinder any resolution unless ither models are affected (eg the OP)

The business about address length not being deducted from the message length isn't quite accurate. The length of the recipient address is being deducted - it's just that it's very short. This is the whole point of predefined contacts. The way this is supposed to work (when it's working right) is as follows. Leaving out the role of the Earthmate app, if any, for the moment.

You define contacts on the web site. Each contact is assigned a short identifier. You sync the web site with the device. The contact info, including the short identifiers, are sent to the device. You send a message from the device, selecting from the predefined list of contacts. The device transmits the message. The recipient address(es) sent by the device are the short identifiers, not the full address (not the e-mail address, SMS number, or whatever). The message transits the satellite/ground station network and eventually ends up back at the Garmin server. The server looks up the short identifier in your account and "expands" the short identifier to the full address. The server then uses the full address to forward the message for delivery. In the case of e-mail targets, the message is sent directly via the public Internet. In the case of an SMS message, the message is forwarded to the appropriate regional SMS gateway (which depends on the location of the recipient's number). From the gateway, the message transits the cell network, eventually reaching the recipient's phone.

The usual source of misdirected messages to predefined contacts is failure to sync after a change in predefined contacts. That usually results in disagreement between the device and the server as to the meaning of a particular short identifier.

The presence of the Earthmate app in the loop further confuses the issue. Sounds like the initial message (the one that was properly delivered) apparently contained the full address rather than the short identifier. This strikes me as incorrect. It's as if the device+Earthmate app doesn't recognize the predefined nature of the contact. Something about having received a reply seems to have woken it up to that fact. But now it apparently has the incorrect short identifiers? Offhand, I'm inclined to agree with the Pivotel people - sounds like a problem in the Earthmate app. Whether or not it has to do with the old-model device is open to question.

Note: I don't know if Pivotel's servers enter into this at all. It's my impression that all the traffic eventually transits the Garmin servers regardless of which regional organization resells the service. But I could easily be wrong about that.

The main reason I asked about reply-to-reply vs. new message is that some additional server-side magic is involved in replies directly from a cell phone. The details aren't relevant here, particularly since both reply-to-reply and a new message behave the same way.

Edited to add: Can't speak to the Android version of Earthmate, or to a device this old. However, the iOS version of the app drags in the entire contact list from the phone. And does NOT show contacts that are unique to the inReach contact list (that is, those that don't otherwise appear on my phone). Even when paired with the device and sync-d. This leads me to believe that perhaps the initial (properly addressed) messages were sent using data from the phone's contact list, without reference to the inReach contact list. Perhaps receiving a reply via the app augmented the information (incorrectly) with data from the inReach? Because I have a newer model inReach with a user interface, I don't typically use the app - can't ever recall sending a message via the app. So I'm not sure what, if anything, it does to the displayed contact list or subsequent messages.

It is likely the v1.5 device is using an API that is no longer supported. 10 years is prehistoric for electronic devices of this type. You can't even expect Androids and iPhones to be supported that long.

The 1.5 device support is a grey area. The device is officially supported by the network and earthmate app - and they are happy to take my money monthly to connect it to their network. But, there will be no more firmware releases for this device.

twolpert - to reitterate. I have _NO_ predefined contacts on the inreach system. So all outgoing messages should (and used to) be carrying the full destination address, not some shortened index. My feeling is that the issue I'm seeing and the defferent behaviour regarding replies sent from inreach not deducting the destination address started at the same time. My impression is that as well as indexing predefined contacts a recent update to the app & server software now also indexes 'conversations' between addresses that have been used previously. And furthermore that that new indexing system is broken in some way.

@teolpert To respond to your edit:

When I reinstalled earthmate after first having this issue I denied the app's request for access to my phone's contact list- so it has not got any contacts from there. However ... there remains the possibility that an old contact list from the previous installation, or that from another device I've used the inreach with, has been cached on the server and is not being deleted/updated when I synch. Which would be possible explanation #2

Could be wrong, but I don't believe the server knows anything about the phone's contact list. The most it would know would be contacts that were actually used send messages from the inReach.

With the newer inReach devices, manually addressed messages do create an entry in the contact list on the device. However, such contacts should not cause the use of a shortened index. Emphasis on should. And it's possible that that behavior would change with the next sync. However, I have never seen such contacts appear on the server as a result of a sync. Have never seen any contacts on the server that I did not create there. This is not to say that things works as they should, or that I have observed every possible combination of events.

There IS server side logic involved in routing replies from your SMS recipients back to your inReach. But as far as I know it only affects the routing of replies in that direction. It should not (as far as I know) affect routing of a "reply to a reply" from the inReach. Briefly, the way this works is as follows. Your inReach does not have an assigned cell number. When you send an SMS from the inReach, the Garmin server, in conjunction with the partner SMS gateway in the target geographical area, chooses an originating number from which to send the SMS. The Garmin server records the chosen originating number, the recipient's number, and the ID of your inReach. If the SMS recipient replies, the reply goes to the chosen originating number. The Garmin server matches the number to which the reply is sent (the originating number) and the caller's number (the original recipient's number) against its records. If a match is found, the reply is routed to your inReach. Eventually, the entries on the server "age out" and are discarded, but this usually takes at least a month or two.

One other thing occurs to me. I did not realize that the old inReach had no contact list on the device. Since you get better results immediately after (re)installing the Earthmate app, you might try doing an OTA sync via the app rather than (re)installing. Still not ideal, but might be an easier workaround if, indeed, it helps.

Yes - Garmin told me to just do a sync to fix the problem in the one helpful response I had from them before they decided they did not provide support. But unless I'm missing something a sync requires mobile coverage - which rules out it being possible in any situation in which I am using the InReach. Thanks for the explanation of how the SMS messaging works. I've noticed that all messages I send go out as the same Australian number - but since I use the device most weeks I guess the entry never gets time to 'age out' and I've kept the same originating number.

Just to fill in the story on Garmin / Pivotel support. Garmin, as stated above will not provide me with any support and say that my provider, pivotel, are responsible for that. Pivotel have been very helpful and have engaged in an extended dialog and troubleshooting process with me which has helped clarify (as detailed above) when the issue occurs. Pivotel are of the opinion, like yourselves, that there is an incompatability / bug in the earthmate software relating only to the 1.5 inreach. But as pivotel have no control over earthmate code (or the server-side software), they are unable to help further and suggest I talk to Garmin.

But I'm wondering if that (a bug) is the case - because if so, why aren't hundreds of other people complaining about the same issue - Garmin stated in their one helpful reply that 1.5 inreach still forms a big proportion of their user base (as in 'but no-one else has complained').

The other possible explanation is that there is simply some bad/corrupted server-side data specific to my account & contacts - which is not getting flushed out by a sync. That would explain why the issue is not more widespread. And would also explain why the original poster encountered something similar on a completely different device.

Anyway - thanks for the suggestions. I'll have another go at getting Garmin to provide some support, and if that fails, I guess I'll be paying to upgrade to a newer device, as everyone keeps suggesting.