Troubleshooting the Mentalista module
The client cannot connect at all
Cause. Either the capture session is not running yet (the listener only exists while a
session is active), or Port has been changed away from 5555 without also updating the
workstation firewall rule this module’s network.listen capability is scoped to.
Fix. Start the capture session before connecting the client. If Port was changed, update
the firewall rule to match - see Configure.
The client connects, but no predictions ever appear
Cause. In this deployment the client is Mentalista’s own web application, running in an
automated Chrome session (driven via ChromeDriver) that must itself be logged into Mentalista’s
cloud backend and paired with the physical headset - this module has no visibility into any of
that. A browser session that opened the WebSocket but is not actually logged in, or whose headset
is not connected on the Mentalista side, will sit connected here and never send a
prediction event; nothing in this module’s own logs distinguishes that from a healthy idle
connection.
Fix. Check the Chrome/ChromeDriver session and Mentalista backend login first - this is a peer-side problem, not something this module’s settings can fix.
The client connects but a specific prediction never appears
Cause. A prediction event that has none of the four recognised prediction paths
(predictions.emotion.valence, predictions.emotion.arousal,
predictions.attention.attention_index, predictions.cognitiveLoad.cognitive_index) produces no
frame at all - silently, with no warning logged. Any event type other than ready, prediction,
commandSuccess or commandError is also silently ignored.
Fix. Confirm the client is actually sending prediction events with at least one of the four
paths populated, not only raw sensor data.
Automatic connect never succeeds
Cause. Retries only happen after an explicit commandError naming connect - a client that
never responds is not retried at all, and once ConnectRetryCount retries are exhausted
after repeated commandError responses, the module gives up permanently for that WebSocket
session.
Fix. Check the client is actually replying to the connect command it receives. If it needs
more attempts, raise ConnectRetryCount; if a slower client needs longer between attempts, raise
ConnectRetryDelayMs and MaxConnectRetryDelayMs. A client that stays silent will never be
retried regardless of these settings - reconnecting the WebSocket session is the only way to
trigger another attempt.
The listener rejects a client immediately
Cause. The listener answers a plain HTTP request that is not a WebSocket upgrade with HTTP 400 - a health-check probe or browser hitting the URL directly will see this and nothing else.
Fix. Confirm the client is actually issuing a WebSocket upgrade request, not a plain HTTP
request, on the listener’s Host:Port.