Problem: You can't access the web application or it's not loading properly.
When to use this guide: When you're having trouble connecting to or loading the Essentials Web Config App.
Try these quick checks first:
- Can you ping the processor?
ping [processor-ip] - Is the URL correct? Should be
https://[processor-ip]/cws/debug/ - Does the processor respond on any port? Try
https://[processor-ip](may show different content)
Check network connectivity:
ping [processor-ip]- ✅ Success: You get replies → Network connectivity is working
- ❌ Failure: Request timeout or unreachable → Network issue
If ping fails:
- Verify you're on the same network/VLAN as the processor
- Check your IP configuration and subnet mask
- Confirm the processor IP address is correct
- Test with a different device on the same network
Test HTTPS connectivity:
telnet [processor-ip] 443Or try the base URL in your browser: https://[processor-ip]
Expected results:
- ✅ Connection successful: Port 443 is open and accepting connections
- ❌ Connection refused: Web service may not be running
- ❌ Timeout: Firewall blocking or service not responding
Try a different browser:
- Chrome, Firefox, Safari, or Edge
- Use incognito/private mode to avoid cache issues
Clear browser data:
- Clear cookies and cache for the processor's IP
- Disable browser extensions temporarily
- Check if popup blockers are interfering
Common certificate warnings:
- "Your connection is not private"
- "NET::ERR_CERT_AUTHORITY_INVALID"
- "This site can't provide a secure connection"
How to proceed safely:
- Click "Advanced" or "Show details"
- Click "Proceed to [IP] (unsafe)" or "Accept the risk"
- This is safe on your internal network
Note: These warnings are normal for internal devices with self-signed certificates.
Correct URL format:
https://[processor-ip]/debug/
Common mistakes:
- ❌
http://instead ofhttps:// - ❌ Missing
/debug/path - ❌ Wrong IP address
- ❌ Extra characters or typos
Examples of correct URLs:
https://192.168.1.100/debug/https://10.0.0.50/debug/https://processor.local/debug/(if DNS is configured)
Physical indicators:
- Power LED should be solid (not blinking)
- Network LED should show activity
- Any error displays on the processor
If processor seems unresponsive:
- Try power cycling (unplug for 30 seconds, reconnect)
- Check for overheating or physical damage
- Verify all network cables are secure
Try connecting from:
- Different computer on same network
- Different network location (if processor accessible)
- Mobile device on same WiFi network
This helps identify:
- Whether the issue is device-specific
- Network routing problems
- Firewall or access control issues
Cause: Network connectivity issue Solution: Check network configuration, IP address, and physical connections
Cause: Self-signed certificate (normal for internal devices) Solution: Click "Advanced" → "Proceed to [IP] (unsafe)"
Cause: Wrong URL path
Solution: Ensure URL ends with /debug/ (include the trailing slash)
Cause: Web service error on processor Solution: Try power cycling the processor, check processor logs
Cause: Firewall blocking connection or service not running Solution: Check firewall rules, verify processor is running properly
Cause: JavaScript errors or API connectivity issues Solution: Check browser console for errors, try different browser
- Open Developer Tools (F12 in most browsers)
- Go to Console tab
- Look for error messages (usually in red)
- Check Network tab for failed requests
Common console errors:
- CORS errors: May indicate proxy configuration issues
- Network errors: API endpoints not responding
- JavaScript errors: Browser compatibility issues
If you have access to the development setup:
Check required environment variables:
# Should be set to processor IP
echo $PROGRAM_HOST
# Should be set to application slot (usually app01)
echo $PROGRAM_IDTry accessing API endpoints directly:
https://[processor-ip]/cws/app01/api/versions
Should return JSON data if the API is working.
- Ensure your device and processor are on the same network segment
- Check VLAN configuration if using managed switches
- Verify subnet masks allow communication
- Corporate firewalls may block HTTPS to internal devices
- Some networks block self-signed certificates
- Guest networks may restrict device-to-device communication
- If using hostnames instead of IP addresses
- Check DNS configuration and host entries
- Try IP address directly to bypass DNS issues
- Test connectivity periodically
- Monitor processor uptime and performance
- Keep browser bookmarks updated with correct URLs
- Document working IP addresses and URLs
- Note any special network configuration requirements
- Keep contact information for network administrators
Contact your network administrator if:
- Multiple users report the same connectivity issues
- Network infrastructure changes preceded the problems
- Firewall or security policy changes are suspected
Contact PepperDash support if:
- Processor hardware appears to be failing
- Software updates may have caused issues
- Configuration changes are needed
- Correct URL format:
https://[ip]/debug/ - Network connectivity (ping works)
- HTTPS port 443 accessible
- Browser certificate warnings handled
- Processor powered on and responding
- No firewall blocking access
https://[processor-ip]/debug/- Main applicationhttps://[processor-ip]/- Base web servicehttps://[processor-ip]/cws/app01/api/versions- API test
- Allow self-signed certificates for internal networks
- Disable popup blockers for the processor IP
- Clear cache/cookies if problems persist
Remember: Most connection issues are network-related rather than application problems. Work systematically from basic connectivity up to application-specific issues.