I’m running into an issue with OpenRemote (latest version 1.5.0) and would appreciate any insights.
I’ve successfully configured MQTT agents to connect to both The Things Network (TTN) and ChirpStack brokers. Initial connection succeeds and I receive data. I then added some more devices and MQTT agents in different realms and I stop receiving data. I’ve confirmed that:
The MQTT agent is connected (CONNECTED in logs).
Agent Link subscriptions are correctly configured with topics like:
application/{appId}/device/{devEUI}/event/up
The mosquitto broker is receiving messages: verified with mosquitto_sub on the same topics (uplinks appear reliably).
Simulated MQTT publish commands are received by an older OpenRemote instance and third-party clients.
Despite all this, uplink messages are not being received or processed by the new OpenRemote Manager instance.
Relevant logs show the client connects and stays connected, but no attribute updates are triggered. No errors are thrown either. Just silence.
What I’ve checked so far:
Topic is exact and matches payload source.
valueFilters` are defined with correct JSONPath - even simplified to “$” to test entire message.
MQTTAgent is enabled and connected.
No known token/auth issues from Keycloak (aside from unrelated refresh warnings).
Connection is to port 1883 using plain MQTT (not MQTTS) for now, so TLS shouldn’t be a factor.
I should also mention that the Assets UI freezes intermittently i.e. “loading” and locked out of accessing Assets. Everything else is accessible but I need to restart the system.
It does look similar, although I’ve experienced the issue on an 8 vCPU machine as well. One thing to note: both our production and staging machines are subscribed to the same ChirpStack and TTN instances, which could potentially be a contributing factor.
Interestingly, the production machine continues to receive uplinks without any issues.
However, the staging machine stopped receiving uplinks again. To troubleshoot, I set the MQTTAgent’s client-id to it’s attribute-id to give it an unique value, and the uplinks have resumed. I’ll continue monitoring and will report back with any further findings.
I thought I’d share an observation that might be relevant to the MQTTAgent threading behavior.
We’ve been encountering an issue when restoring a backup of our OpenRemote v1.3.5 platform onto OpenRemote v1.5.0 on a larger machine. The original system was running on an AWS 2 vCPU instance, and we were migrating it to a 4 vCPU instance. However, on the new setup, the Manager container would consistently:
Take an unusually long time to compile rules
Eventually become unhealthy
To troubleshoot, I added the following JVM option a new 2 vCPU instance:
OR_JAVA_OPTS=“-XX:ActiveProcessorCount=16”
With this setting, rule compilation completes very quickly — even on the modest 2 vCPU instance. The Manager stays healthy, and the platform appears to function as expected, although the MQTT issue still persists.
Hi @Clint you mention here that you’ve set the client ID to a unique value but the client ID should always be unique for a given broker, were you previously connecting to the same broker with multiple MQTTAgents (MQTT clients) using the same client ID?
I think I may have gone off on a bit of a tangent earlier. In our current running system (v1.3.5), I don’t explicitly specify the client ID in the MQTT agent — and everything works fine.
In the new OR version, however, it seemed like no matter what I tried, the uplinks would eventually stop coming through. At one point, I thought that explicitly setting the client ID (using the asset’s ID as a unique ID) in the MQTT agent made a difference, but it turns out it still failed.