Skip to main content
“A resident’s device can’t connect” is the top EasyPSK support call. Most issues trace back to: the SSID being misconfigured on the Meraki side, a recent Pre-Shared Key rotation the resident missed, the Meraki API key being revoked, or a device quirk unrelated to EasyPSK itself. Walk through these in order.

​
1. Is the SSID still configured correctly on Meraki?

Symptoms. Every device in every apartment stops connecting, or new apartments can’t be onboarded because the SSID dropdown in Basic Configuration is empty. Check.
  • On the Meraki dashboard, confirm the SSID is still configured for Identity PSK without RADIUS. Some other Meraki IPSK modes (like IPSK with RADIUS) break the integration.
  • Confirm the SSID is still enabled on the network or template.
  • Confirm the wireless network the SSID broadcasts from still has MR-series access points in service.
  • Confirm the network uses an external DHCP service, not the Meraki AP-assigned DHCP (NAT mode). EasyPSK does not work with NAT mode — devices authenticate but can’t route out.

​
2. Is the Pre-Shared Key the one the device is using?

Symptoms. One resident can’t connect, but their roommates can (or vice versa). Check.
  • Has the Group Administrator rotated the PSK recently? If so, the resident’s device is still trying the old key. Ask them to open the Self-Service portal, reveal the current PSK, and re-enter it on their device — or scan the QR code from the How to connect card.
  • Did an admin rotate the PSK from Group Settings? Same fix.
  • Copy-paste errors are common. Ask the resident to retype the PSK manually if auto-fill keeps failing.

​
3. Is the resident inside the right Wireless Personal Network?

Symptoms. The resident has signed into the Self-Service portal and reveals a PSK, but it’s not the one that joins the Wi-Fi. Check.
  • Is the resident a member of more than one WPN (shared Group Administrator role across buildings, for example)? The portal shows a picker at the top. Make sure they’re on the right apartment’s detail page.
  • Does the WPN the resident is looking at actually correspond to the apartment the device is physically in? EasyPSK isn’t geofenced; any PSK from the Context will authenticate a device to the SSID anywhere the SSID is broadcast.

​
4. Is the Meraki API key still valid?

Symptoms. New Wireless Personal Networks can’t be created. PSK rotation fails with an error. The Context’s Configuration tab shows the Meraki API User Info card in an error state. Check.
  • Has the Meraki admin account that minted the key been disabled or removed from the Meraki organization?
  • Has the key itself been revoked in the Meraki dashboard’s organization settings?
  • Is the key still scoped to Full organization access? A Tag-restricted or Network-restricted key works if every object the integration touches is inside the allowed scope — but if you’ve recently added a new Meraki network to the Context that isn’t in the tag scope, the integration will fail for that network.
  • Rotate the key: generate a fresh one in the Meraki dashboard, paste it into Basic Configuration → Meraki API Key, verify Meraki API User Info updates, revoke the old key.

​
5. Group Policy mismatch

Symptoms. The device authenticates, gets an IP, but has no internet — or has the wrong bandwidth, wrong VLAN, wrong firewall treatment. Check.
  • Is the Context’s Group Policy Strategy One policy per group? Confirm the per-WPN policy on the Meraki side wasn’t edited manually to something broken. EasyPSK owns these policies; any out-of-band edit can be reconciled away or get stuck.
  • Is the Context’s strategy Shared Policy? Every WPN uses the same Meraki Group Policy. If that shared policy breaks, every apartment breaks together.
  • Switching from one strategy to the other mid-deployment is disruptive (see Meraki connection → Switching Group Policy Strategy).

​
6. Device-side Wi-Fi quirks

Not EasyPSK-specific, but common:
  • 2.4 GHz only device on a 5 GHz SSID. Some older IoT devices don’t see 5 GHz. If the Meraki SSID broadcasts only on 5 GHz, the device won’t even see it.
  • Cached “forgotten” profile. If the device was previously on a different SSID with the same name (a neighbour’s Wi-Fi, say), the OS might try the cached PSK first. Ask the resident to forget every student-wifi-like network in their phone’s settings and reconnect.
  • MAC randomization. Doesn’t usually affect EasyPSK itself — the PSK is the identity — but can make troubleshooting harder because the MAC in the admin-side Connected Devices list may differ from yesterday’s.

​
7. Self-Service Users can’t sign into the portal

Symptoms. The Group Administrator clicks the invite link but can’t authenticate, or says the portal is empty. Check.
  • If the Organization uses SAML with the target set to self-service: is the resident present in the IdP claim set? Are group claims mapped to Self-Service User roles correctly? See Organization SAML authentication.
  • Did the invite email expire? Use the row’s Resend Invitation action on the WPN’s Self-Service Users tab.
  • Is the resident’s email typed correctly? Revoke and re-invite if not.

​
Reading the Audit Log

The Context’s Administration → Audit Log is the source of truth for “what changed and when”. Every create, update, and delete against the Meraki integration, the Wireless Personal Networks, and the Self-Service Users shows up there with the admin (or Group Administrator) who did it. Secrets — the Meraki API key, every Pre-Shared Key — are never readable in the log, by design.

Meraki connection

Reconfigure the integration after an API-key or SSID change.

Managing WPNs

Rotate a PSK, rename a unit, remove a unit.

Webhooks

Stream configuration-audit events to your SIEM.