I tried GPT and Gemini with no succes.
A friend mailed me a reaction from Claude and it is the working solution.
This is a fun one — let me check the current Companion expression syntax for version 4.x so I give you accurate function names, since the expression engine has specific rules about what works.I found the key issue already. Let me pull the exact function list so I can give you the precise syntax.Good news — I found the exact cause, and it’s a quick fix.
The bug: .includes() doesn’t exist in Companion expressions
Companion’s expression language looks like JavaScript, but it isn’t — and that trips up almost everyone (this is also why “not all Java commands work”). While Expressions may resemble JavaScript, they are NOT, so do not expect something that works in JS to work in Expressions.
The dot-method form $(…).includes ’ … ’ is invalid for two reasons: there’s no .method() call syntax, and you left off the parentheses entirely. When Companion can’t parse that, the leftover just resolves to the raw response string — which is a non-empty string, and a non-empty string is always truthy. So your condition evaluates to true on every TCP response, regardless of content. That’s exactly why whichever trigger is enabled always fires: CH1_ON → always “ON”, and with it disabled, CH1_OFF → always “OFF”.
includes does exist, but as a standalone function with two arguments, not a method: includes(val, find) checks if a string contains a specific value — e.g. includes(“Companion is great!”, “great”) gives true.
The fix
Rewrite your two trigger conditions as:
CH1_ON condition:
includes($(tcp-udp:tcp_response), ‘60001/0/0/0/0/0 0 0 1 “ON”’)
CH1_OFF condition:
includes($(tcp-udp:tcp_response), ‘60001/0/0/0/0/0 0 0 0 “OFF”’)
The single quotes around the search string are correct here — they let you keep the literal “ON” double-quotes inside. Your two search strings differ at 0 0 1 “ON” vs 0 0 0 “OFF”, so once the syntax is valid they’ll correctly tell the states apart.
Cleaner option: one trigger instead of two
Since both triggers react to the same variable, you can collapse them into a single trigger that fires on a change of $(tcp-udp:tcp_response), and set the value with an expression (use the expression mode toggle on the “Set custom variable” action’s value field):
includes($(tcp-udp:tcp_response), ‘60001/0/0/0/0/0 0 0 1 “ON”’) ? ‘ON’ : ‘OFF’
Optionally gate the whole trigger with a condition so it only reacts to CH1 messages and ignores other channels:
includes($(tcp-udp:tcp_response), ‘mem_512/60001/’)
That avoids the “two triggers fighting over the same variable” situation entirely.
On the function/variable lists
Two different things, and you want the first one:
- Expression functions (what you called “Java commands”) — this is the reference you couldn’t find. It’s built into your install: in the Companion web UI open the Getting Started guide → Secondary Admin Controls → Expressions → Functions. It’s version-matched to your 4.3.3 and lists everything: includes, indexOf, lastIndexOf, split, join, concat, substr, length, replace, parseVariables, getVariable, etc. The same content is online under the Bitfocus user guide expressions/functions page.
- Connection variables (the values your TCP/UDP module produces, like tcp_response) — those live under the Variables tab in the web UI, grouped by connection.
A great community cheat-sheet that explains the gotchas (like the truthy-string trap you just hit) is thedist’s Companion guide on GitHub — worth a bookmark.