We’re running ThingWorx 9.7 with a custom Thing template that processes MQTT messages from legacy PLCs. The issue started after we added schema validation to our rules engine service. Messages arrive at the MQTT connector but fail during the mapping phase with NullPointerException errors.
The error trace shows:
Error: NullPointerException in CustomMappingService
at com.factory.CustomMappingService.validatePayload(line 67)
at ThingworxRulesEngine.processInbound(line 234)
Our MQTT payloads follow a nested JSON structure with timestamp, sensor arrays, and metadata fields. The schema validation works fine in our test environment with simulated data, but production PLC messages seem to have subtle format differences. We’re losing critical sensor data every few minutes when these mapping failures occur.
Has anyone dealt with MQTT schema validation issues in custom services? Specifically wondering about handling legacy PLC data formats that don’t perfectly match modern JSON schemas.
Check your custom service error handling too. NullPointerException at the validation stage usually means you’re not doing defensive null checks before accessing nested JSON properties. Legacy PLCs often skip sending entire sensor array sections when no data changed, which breaks code that assumes those arrays always exist.
I’ve seen similar NullPointer issues with MQTT inbound mapping. First thing to check - are your PLC messages sending null values for optional fields instead of omitting them entirely? ThingWorx schema validation can be strict about that distinction. Try logging the raw MQTT payload before it hits your custom service to see exactly what’s coming through.
We had this exact problem last year with Siemens PLCs. The issue was timestamp format inconsistency - some messages used epoch milliseconds while others sent ISO strings. Our solution was to add a pre-processing step in the MQTT subscription service that normalizes all incoming data before schema validation. Created a lightweight transformer that handles common PLC format variations. Also recommend checking if your legacy PLCs are sending empty strings versus null for missing sensor readings - that difference trips up many validation engines.