groov AR1 can deliver ordinary email while runtime event texts silently disappear. When a Groov Build test reaches the same phone, the SMTP account, network path, and gateway address are working at that moment. Focus on the difference between the test message and the runtime event path.
Stop repeating the quick fixes
| Quick fix | Why it does not resolve this symptom | What it proves |
|---|---|---|
| Reboot every AR1 | A restart does not repair a stale recipient assignment, rejected runtime payload, or event configuration problem. Rebooting all three units did not restore text delivery. | Little beyond confirming that the failure survives a restart. |
| Replace the Gmail credentials | Runtime events still reach normal email addresses, and the Groov Build test reaches the phones. Authentication is therefore not the first fault to chase. | The shared Gmail account can submit mail. |
| Retype every carrier gateway address | The addresses @vtext, @txt.att.net, and @messaging.sprintpcs.com accept a Groov Build test. Blind edits risk introducing a second fault. |
A successful test validates the tested destination, not the runtime recipient selection. |
| Change hardware | Three AR1 units stopped delivering texts on April 11, 2021 while continuing to send email. A simultaneous independent hardware failure is not the lead diagnosis. | The common Gmail account, runtime configuration, message format, and downstream gateway handling deserve attention first. |
Get production visibility through working email recipients, then isolate text delivery with one controlled event. Do not make the same unverified change on all three boxes at once.
Separate event generation from message transport
The notification chain has distinct stages: the condition becomes active, groov records or processes the event, the runtime resolves its recipients, Gmail accepts the message, and the carrier email-to-text gateway accepts or rejects the resulting payload. Each observation clears only part of that chain.
- A runtime email at a normal mailbox proves that the event fired and that groov submitted at least one notification.
- A successful Groov Build test to a phone proves that the AR1 can submit a test message to that gateway address.
- A manual Gmail message proves the gateway can accept that manually composed message. It does not test the runtime subject, body, headers, or recipient resolution.
- Failure on three mobile devices shifts the first investigation toward a shared stage, but each carrier destination still needs an individual controlled test.
The leading fault domain is the runtime-only path: an SMS recipient is no longer selected for the event, saved runtime data differs from the Build configuration, or the carrier gateway rejects the runtime message while accepting the simpler test. Determine which branch applies from logs and message comparison.
Read the runtime trail before editing
- Choose one event that can be triggered safely and whose normal email delivery is easy to identify.
- Record the trigger time, event name, AR1 identity, normal email recipient, and phone gateway recipient.
- Trigger the event once. Check the event history log for a matching entry.
- Open the groov View logs at the same timestamp. Look for recipient resolution, submission, rejection, authentication, connection, or event-processing messages. Preserve the exact text for support.
- Check the Gmail sent-mail record and any delivery-status or rejection response. Determine whether a message addressed to the phone gateway left the account.
If the event is absent from event history, troubleshoot event processing before SMTP. A recently restored project would make KB88691, “Restored groov View project is Not Logging Events,” relevant; no recent restore was reported here, so confirm history rather than applying that correction blindly.
If the event appears and normal email arrives, event generation and basic SMTP submission are operating. If Gmail shows no phone-addressed runtime message, inspect the event’s recipient configuration and saved runtime state. If Gmail shows the gateway message plus a rejection, move downstream to message content, account policy, and carrier handling.
Repair the branch that failed
- Back up or record the working project configuration before changing recipients or user roles.
- Open the affected event in Groov Build and compare its normal email and phone gateway recipients character for character. Remove spaces, incomplete domains, duplicate entries, and obsolete recipient references.
- Confirm that the phone destination belongs to the runtime event, not only to the Build test function. Save and apply the project through the normal groov workflow.
- Because the only recent configuration change was changing one user from operator to editor, check whether that user is referenced by the affected notification. If it is, temporarily restore the prior role as a controlled test. If delivery returns, rebuild the recipient or role assignment deliberately instead of leaving an unexplained rollback.
- Send the exact runtime subject and body manually from the same Gmail account to one gateway. If the exact payload fails while a short test succeeds, shorten or simplify the event message and inspect Gmail’s response. The deciding evidence is the delivery-status record, not whether a generic manual message worked.
- Repeat the test on the other gateway destinations individually. Keep the event, account, and message constant so that only the destination changes.
KB89539, “Events Not Sending Email on GROOV-AR1 or GROOV-AT1,” is not the first match when normal runtime email and the Build phone test both work. Revisit it only if Build testing or ordinary event email also begins failing.
Prove runtime delivery end to end
| Checkpoint | Pass condition | Failure direction |
|---|---|---|
| Event history | One entry matches the controlled trigger. | Event condition, event engine, or restored-project state. |
| Normal runtime email | The mailbox receives the same event occurrence. | SMTP configuration or notification processing. |
| Gmail sent record | A separate message is addressed to the phone gateway. | Runtime recipient selection or applied project state. |
| Gateway response | No rejection or delivery-status failure appears. | Account policy, message payload, or carrier gateway. |
| Mobile device | The controlled event appears as a text. | Downstream carrier delivery after Gmail acceptance. |
Run the proof once per AR1 and once per carrier destination. Record results as a matrix rather than declaring the system fixed after one phone receives one test. Finish with a real runtime event; a Build test alone is not acceptance.
Avoid the recurring diagnostic traps
- Do not treat “email works” as proof that every configured recipient was selected.
- Do not treat a short test message as equivalent to the runtime alarm payload.
- Do not clear logs or make bulk edits before capturing the first failing timestamp.
- Do not restore projects or change roles on all three AR1 units during diagnosis. Change one variable on one unit, test, and record the result.
- Do not keep rebooting after the symptom survives one controlled restart.
Keep normal email notifications active as the temporary production path. After recovery, document the event recipient list, the shared Gmail dependency, and a scheduled runtime test for every gateway destination.
FAQ
Can I trust a successful Groov Build text test?
Trust it only as proof that the AR1 submitted that test to the selected gateway address. It does not prove that a runtime event selects the same recipient or produces a gateway-acceptable payload.
Does rebooting a groov AR1 repair missing event texts?
Not when the failure comes from recipient configuration, applied project state, message rejection, or carrier handling. All three reported AR1 units were rebooted without restoring text delivery.
Can I prove whether the carrier gateway is rejecting the alarm?
Check Gmail for the phone-addressed sent message and its delivery-status response, then manually send the exact runtime subject and body. A generic Gmail test is not equivalent to the alarm payload.
Does changing a user from operator to editor affect notifications?
Check whether that user is referenced by the event’s recipient configuration. Temporarily restoring the prior role is a valid controlled test, but keep the change only if runtime delivery proves the relationship.
Can I keep troubleshooting when logs show no clear failure?
Stop after reproducing the fault once, preserving the groov View logs, event-history entry, Gmail delivery record, project state, and results from each destination. Escalate to official groov support when runtime recipient selection cannot be reconciled, the logs report an unexplained internal failure, or the problem spans all three AR1 units with the same controlled evidence.