Confirm that the iPhone or iPad and the target can communicate across the current Wi-Fi, Ethernet, VLAN, or routed network.
DeviceJockey Support
Troubleshooting
Find the layer where communication stops, then check only the settings that belong to that layer.
Start here
Follow the signal from the item to the target and back.
A DeviceJockey control usually crosses several independent layers. Checking them in order avoids changing values that were already correct.
1
Scene and mode
Confirm that the expected scene is active and test the item in Live Mode.
2
Interface
Check that the item uses the intended interface and that the interface is enabled and connected.
3
Transport
Verify network, MIDI endpoint, Bluetooth connection, broker, or controller availability.
4
Message
Compare address, topic, channel, universe, value type, range, and authentication with the target.
Test one direction at a time.
First confirm that a command reaches the target. Then test the separate event or feedback path back to the panel.
Connection status
The interface does not connect.
Check the active scene.
Only interfaces belonging to the active scene are available to its items.
Check the interface state.
Make sure the interface is not disabled and that global interface connections are switched on.
Confirm the target is ready.
Start the application, broker, server, MIDI endpoint, or hardware before reconnecting DeviceJockey.
Verify the address.
IP addresses can change. Compare the configured host and port with the current values on the target.
Check authentication.
Re-enter the password, username, certificate, or token required by the target.
Review the protocol version.
Both sides must use compatible protocol and security settings.
A saved configuration can become outdated.
Router changes, DHCP addresses, replaced certificates, new passwords, and software updates can invalidate settings that worked before.
Network diagnosis
The device or application is not reachable.
Check the system privacy settings when iOS has denied DeviceJockey access to devices on the local network.
Allow the target application and its configured TCP or UDP port through the computer firewall.
Guest Wi-Fi and access point isolation can prevent two devices on the same wireless network from reaching each other.
A VPN can change routing or hide the local network. Test once without it when a local target disappears.
Confirm that the address belongs to the intended device and that another application is not occupying the required listening port.
Do not assume that Wi-Fi alone guarantees reachability.
Two devices can show the same network name while firewall rules, VLANs, or guest isolation still block communication.
Outgoing direction
The item moves, but the target does not react.
Check the item action.
Confirm that the command is attached to the action you are actually using, such as Tap, Touch, Slider, or Rotary.
Check the command trigger.
If the command uses a numbered trigger, the item action or event must execute that same trigger.
Check the selected interface.
The command must point to the intended interface in the active scene.
Compare the destination.
Verify path, topic, channel, universe, host, port, request type, and parameter names as applicable.
Compare the value type.
A receiver expecting an integer, float, Boolean, string, MIDI value, or JSON structure may ignore another type.
Resolve dynamic values.
Check the current contents of every Swap used in the command, address, topic, or Script.
Incoming direction
The target changes, but the panel does not update.
Confirm that feedback exists.
A successful command does not automatically update an item. The target must send a response, event, topic update, MIDI message, OSC message, or another supported value.
Check the event interface.
The event must listen through the interface that receives the feedback.
Compare the identifier.
Check topic, path, message type, MIDI channel, JSON attribute, DMX channel, or Local path.
Check the event action.
Make sure the event is attached to the item property you expect it to control.
Check matching values.
Compare minimum, maximum, on, off, label attribute, value type, and text capitalization.
Check whether the event is disabled.
An existing event can remain visible in Edit Mode while being disabled for operation.
Feedback should represent the confirmed state.
Let the event update the item from the target’s response. This also reflects changes made outside DeviceJockey.
Unexpected item behavior
The event arrives, but the item reacts incorrectly.
Swap the configured minimum and maximum values when a slider moves opposite to the incoming value.
Compare normalized values such as 0 to 1 with protocol ranges such as MIDI 0 to 127 or controller axes from -2048 to 2048.
Check whether the source sends text, integer, float, or Boolean data and select the corresponding event type.
Two events can update the same item property. Temporarily disable one to isolate the source of the change.
A matching event can also trigger commands. Review its selected triggers when an unexpected action follows the update.
Review Shared Values when an edit affected several items, commands, or events at once.
State and startup
The panel shows the wrong state after loading.
Separate requested and confirmed state.
Do not rely only on the last command sent. Request or receive the current state from the target.
Check the Event status behavior.
Some events can evaluate their current configuration when the panel performs a status check.
Use the appropriate System Event.
Panel Ready, Panel Loaded, Live Mode Started, All Interfaces Connected, or Swaps Updated can initiate the required refresh workflow.
Review retained MQTT messages.
An old retained value can immediately initialize an item with a state that is no longer valid.
Check active Swaps.
A changed Swap can alter interface addresses, message paths, values, Scripts, and item status calculations.
Logging
Observe the interface where the problem occurs.
Add a Logging item to a diagnostic panel and select the relevant interface. Test one item action at a time and compare the log entry with the value expected by the target.
1
Select the interface
Choose the interface used by the command or event under investigation.
2
Clear unrelated entries
Start with a readable log before reproducing the issue.
3
Perform one action
Tap one button, move one control, or generate one incoming message.
4
Compare the result
Check direction, address, value, type, status, and error messages.
Script logging belongs to the Local Interface.
Select the Local Interface in the Logging item to see messages written with console.log().
Interface-specific checks
Continue with the guide for the affected transport.
Rescan endpoints, distinguish MIDI in from MIDI out, and verify channel and message type.
MIDI troubleshooting →Check the system pairing and remove a stuck connection before reconnecting.
Bluetooth MIDI troubleshooting →Compare outgoing destination and incoming listening ports, paths, and argument types.
OSC troubleshooting →Check node reachability, universe, DMX channel, resolution, and refresh rate.
Art-Net troubleshooting →Verify WebSocket server, host, port, password, firewall, and protocol version.
OBS troubleshooting →Check Client ID, authentication, TLS, topic spelling, payload structure, QoS, and Retain.
MQTT troubleshooting →Confirm system pairing, detection in Developer Extras, Local Interface path, and event type.
Game Controller troubleshooting →Check XML Control, gateway host and port, client connection, camera identifier, function, and range.
Grass Valley troubleshooting →Verify the MIDI Device Profile, automatic installation, port 8000, connection approval, and predefined OSC path.
Logic Pro troubleshooting →Check mixer address, network reachability, and the OSC command or feedback path.
Mixer guide →Before requesting support
Collect a small reproducible example.
Name the affected scene and interface.
Include the interface type and whether DeviceJockey reports it as connected.
Describe one failing action.
State which item action, command, or event is involved and what you expected to happen.
Record the relevant settings.
Include addresses, ports, paths, topics, channels, universes, and value types. Remove passwords and private keys.
Include the matching log entries.
Capture only the entries around one reproduction of the problem.
Note what already works.
For example, state whether connection succeeds, commands work, or only feedback is missing.
Do not share credentials.
Remove passwords, authentication tokens, private certificates, and other secrets from screenshots and logs.