OpenRemote

Hey @blubbsik ! Thanks for your interest in OpenRemote. We’re always happy to see people interested in contributing to the platform. You mentioned you work with GPS trackers. I am the PO for the fleet management integration of OpenRemote, and as such I also do some work with GPS trackers. I’d be happy to have a conversation to see what you’ve worked with/how you can contribute there, or maybe something more generic for the entire platform. Looking forward to hearing back from you! All the best, Panos

Hey @Ankou , It’s not quite an “OpenRemote” issue, it’s just that we weren’t aware of Teltonika’s MQTT client changes I have opened a PR to allow the devices to connect: Fix anonymous MQTT authentication with empty passwords by pankalog · Pull Request #3244 · openremote/openremote · GitHub Once that is merged to the main OpenRemote repository, I will be updating fleet-management to the latest OpenRemote version to make sure the changes are implemented. You’d just be pulling the new container images to get the newest OpenRemote version. I’ll also reply here to let you know when that happens. Again, thanks for letting us know of the issue!

Thank you for your response. The issue lies on the side of Openremote correct? How long would your fix take? If it would take a longer time we are thinking about building a sanitizer to “cut out” that piece. Another question regarding the fleet management feature. We are currently running the containers: proxy latest, keykloack latest and manager 1.15. 1 Openremote core is running on 1.28,correct? Is that maybe an issue or is that intended,that the fleet management runs on 1.15.1

I guess that password is empty not null when ActiveMQORSecurityManager.authenticate() is hit. We could change if (password == null) to if (TextUtil.isNullOrEmpty(password))

Hey @Ankou , Thanks for your post! That’s exactly what’s happening most probably, we assume Teltonika devices that connect to OpenRemote do so via anonymous connections, and connections that do have a username but an incorrect password are kicked out. not sure how we missed this update, but I will take a look soon. At the same time, my mTLS PR ( MQTT Broker: authenticate connections from client certificates by pankalog · Pull Request #3203 · openremote/openremote · GitHub ) would solve this, and the new fleet telematics architecture changes coming up would make this vastly easier to manage. Thanks for trying out OpenRemote, let me know if anything else comes up!

Hi, I’m trying to use the OpenRemote Fleet Management setup with Teltonika FMC650 devices, following the tutorial for the FMC003. The FMC003 works correctly, but the FMC650 is rejected by the MQTT broker. The FMC650 is configured as follows: Firmware: 03.01.01.Rev.15 MQTT Client Type: AWS IoT Custom Device ID: empty Data Topic: xxx/FMC650Test/teltonika/%imei%/data Commands Topic: xxx/FMC650Test/teltonika/%imei%/commands Only the root CA certificate is configured, same as on the working FMC003 I captured the MQTT CONNECT packet on the OpenRemote Docker network. The FMC650 sends: Client ID: Username: x.x.de/ Password: empty For example: Client ID: 862xxxx6159 Username: x.x.de/862xxxx6159 The CONNECT flags are 0xC2 , so username and password are explicitly present. OpenRemote then immediately responds with: 20 02 00 05 which is MQTT 3.1.1 CONNACK: Connection refused - Not authorized , and the connection is closed. This happens consistently with two different FMC650 devices. The FMC003, using the same general OpenRemote setup, works correctly. My suspicion is that the FMC650’s newer AWS IoT Custom MQTT implementation automatically generates the username / , while the OpenRemote Teltonika MQTT handling expects the Teltonika connection to be anonymous. The FMC650 never reaches the publish/subscribe stage, so the configured data and command topics do not seem to be the immediate problem. Have you encountered this behavior with FMC650 devices before? Would it make sense to adjust the

Hi, I’m trying to use the OpenRemote Fleet Management setup with Teltonika FMC650 devices, following the tutorial for the FMC003. The FMC003 works correctly, but the FMC650 is rejected by the MQTT broker. The FMC650 is configured as follows: Firmware: 03.01.01.Rev.15 MQTT Client Type: AWS IoT Custom Device ID: empty Data Topic: xxx/FMC650Test/teltonika/%imei%/data Commands Topic: xxx/FMC650Test/teltonika/%imei%/commands Only the root CA certificate is configured, same as on the working FMC003 I captured the MQTT CONNECT packet on the OpenRemote Docker network. The FMC650 sends: Client ID: Username: x.x.de/ Password: empty For example: Client ID: 862xxxx6159 Username: x.x.de/862xxxx6159 The CONNECT flags are 0xC2 , so username and password are explicitly present. OpenRemote then immediately responds with: 20 02 00 05 which is MQTT 3.1.1 CONNACK: Connection refused - Not authorized , and the connection is closed. This happens consistently with two different FMC650 devices. The FMC003, using the same general OpenRemote setup, works correctly. My suspicion is that the FMC650’s newer AWS IoT Custom MQTT implementation automatically generates the username / , while the OpenRemote Teltonika MQTT handling expects the Teltonika connection to be anonymous. The FMC650 never reaches the publish/subscribe stage, so the configured data and command topics do not seem to be the immediate problem. Have you encountered this behavior with FMC650 devices before? Would it make sense to adjust the

Hi all! I’m a hobbyist developer and have a built a couple of Android apps (e.g. GPS trackers) and some plugins for web applications (e.g. data conversion or reporting tools). Now I’m searching for a new “project” for me. The OpenRemote IoT platform is really nice and I would like to develop something for it. My problem is: I have no idea what can be interesting not only for me, but also for OpenRemote users. As I said, I developed some GPS trackers and maybe If I will extend them with e.g. MQTT, then it will be interesting for OpenRemote users. But I don’t really know whether it will be “profitable”. I don’t mean money (sure, it will be nice too), I want only that my software will be used. So my question: have someone an idea for an Android app or an OpenRemote add-on or maybe other tool, which will be interesting for at least a dozen of OpenRemote users? Thank you! 2 posts - 2 participants Read full topic

Hi all! I’m a hobbyist developer and have a built a couple of Android apps (e.g. GPS trackers) and some plugins for web applications (e.g. data conversion or reporting tools). Now I’m searching for a new “project” for me. The OpenRemote IoT platform is really nice and I would like to develop something for it. My problem is: I have no idea what can be interesting not only for me, but also for OpenRemote users. As I said, I developed some GPS trackers and maybe If I will extend them with e.g. MQTT, then it will be interesting for OpenRemote users. But I don’t really know whether it will be “profitable”. I don’t mean money (sure, it will be nice too), I want only that my software will be used. So my question: have someone an idea for an Android app or an OpenRemote add-on or maybe other tool, which will be interesting for at least a dozen of OpenRemote users? Thank you!

Hi, Please volume map custom certs into the default CUSTOM_CERT_DIR or set this environment variable to a different path if required (i.e. if mounting a docker volume). Indeed the /etc/haproxy/certs dir is managed by our entrypoint script and is for auto generated certs. See proxy README for details of available variables and their meaning

I mount my SS-cert in docker compose with: - ../OR-certs/certs/edge.pem:/etc/haproxy/certs/00-custom If the docker project happens to self-restart (as it should). The proxy seems to delete the given certificate and crash loop ( similar issue ). This is fixed by running docker compose up; docker compose up -d As I am quite unexperienced with SSL and shell-scripting etc. i asked claude if i was doing something incorrectly - but it came back saying that there might be some relic code / logic that overrides the self-signed certificate: “”" This is from claude so take it with a grain of salt The actual failure is a different, dangling file: /etc/haproxy/certs/00-cert. Looking at the entrypoint logic, this file is a symlink created by the add() function whenever a real domain gets a Let’s Encrypt cert — it points to a first domain’s cert file inside CERT_DIR to take precedence over the self-signed cert. But critically: add() explicitly skips IP addresses (there’s an IP_REGEX check that bails out early for anything that looks like an IP or a bare hostname). Your DOMAINNAME/DOMAINNAMES is 192.168.1.xx — an IP — so under the current script logic, that symlink should never get (re)created. That strongly suggests this symlink is a leftover artifact — likely from an earlier point where OR_HOSTNAME was a real domain (or from before an image update), a real cert got issued and symlinked, and at some point the target file in CERT_DIR was cleaned up by the “remove obsolete certs” logic in ce