Custom Lookup that goes into error when false statement is caught instead of true

Hello Mihai,
thank you for your inquiry!

The reason why you're getting the zero right now is because PRTG is unable to parse the string and then returns 0 for that channel. The issue here is that you have to work with numerical values in lookups, and not text*. For example here's the prtg.standardlookups.yesno.stateyesok:

<?xml version="1.0" encoding="UTF-8"?>
<ValueLookup id="prtg.standardlookups.yesno.stateyesok" desiredValue="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PaeValueLookup.xsd">
	<Lookups>
		<SingleInt state="Ok" value="1">Yes</SingleInt>
		<SingleInt state="Error" value="2">No</SingleInt>
	</Lookups>
</ValueLookup>

The value="1" must always contain an interger. Strings or float values are not supported here. This does however mean that your script must take this into account and parse whatever text result you get to a numerical value first. So basically the sensor turns the string into a number and the lookup converts the number back to a string in PRTG's interface. This is because PRTG's Database (and channels) don't support strings, only numerical values.

Real-world example

Here's an example of a Powershell script to monitor the Replication Status of a DHCP Scope on Windows Server (partial-excerpt from the script):

[...]
		}'Replication'{
			
			#Parse the results for Replication
			
			switch ($remoteResult.state){
				'NoState'                  { $state = 0 }
				'Normal'                   { $state = 1 }
				'Init'                     { $state = 2  }
				'CommunicationInterrupted' { $state = 3  }
				'PartnerDown'              { $state = 4  }
				'PotentialConflict'        { $state = 5  }
				'Startup'                  { $state = 6  }
				'ResolutionInterrupted'    { $state = 7  }
				'ConflictDone'             { $state = 8  }
				'Recover'                  { $state = 9  }
				'RecoverWait'              { $state = 10  }
				'RecoverDone'              { $state = 11  }
				default                    { $state = -1  }
			}
			
			$results += @{
				Channel = 'State'
				Value = $state
				ValueLookup = 'prtg.customlookups.dhcp.failoverreplication'
			}
[...]

And here's the corresponding lookup:

<?xml version="1.0" encoding="UTF-8"?>
<ValueLookup id="prtg.customlookups.dhcp.failoverreplication" desiredValue="1" undefinedState="Error" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PaeValueLookup.xsd">
	<Lookups>
		<SingleInt state="Error" value="-1">Unknown Status</SingleInt>
		<SingleInt state="Error" value="0">No State</SingleInt>
		<SingleInt state="Ok" value="1">Normal</SingleInt>
		<SingleInt state="Warning" value="2">Init</SingleInt>
		<SingleInt state="Error" value="3">Communication Interrupted</SingleInt>
		<SingleInt state="Error" value="4">Partner Down</SingleInt>
		<SingleInt state="Warning" value="5">Potential Conflict</SingleInt>
		<SingleInt state="Warning" value="6">Startup</SingleInt>
		<SingleInt state="Error" value="7">Resolution Interrupted</SingleInt>
		<SingleInt state="Ok" value="8">Conflict Done</SingleInt>
		<SingleInt state="Warning" value="9">Recover</SingleInt>
		<SingleInt state="Warning" value="10">Waiting for Recovery</SingleInt>
		<SingleInt state="Ok" value="11">Recovery Done</SingleInt>
	</Lookups>
</ValueLookup>

Side note: On the first line of my answer I wrote "you have to work with numerical values in lookups, and not text*" - The asterisk there is not an accident. When you work with the SNMP Custom String Lookup sensor, you can actually work with strings in lookup-files, but that's an exception and not the norm:

• KB: Lookups when value is a String

Best Regards,
Luciano Lingnau [Paessler]