Domoticz

Hi all,

Before I open a suggestion or ticket I just wanted to check - am I correct in thinking there is no way to determine the Client ID Domoticz will use when connecting to an MQTT broker? There's no configuration field on the broker config page and looking in my Mosquitto log I see the following upon restart of a Domoticz instance:

1744620644: New client connected from <redacted>:60112 as Domoticz9054ea4f-bef2-43bd-9b1a-3511c47c16574 (p2, c1, k120, u'<redacted>').
1744620644: New client connected from <redacted>:60114 as Domoticz9bdd7cd7-21c4-4b51-a291-f88640a380fe9 (p2, c1, k120, u'<redacted>').
1744620644: New client connected from <redacted>:60110 as Domoticz9ad1fb77-ae18-416a-9546-191bf8c566bc8 (p2, c1, k120, u'<redacted>').

That looks like the client ID is 'Domoticz' plus a GUID. I'd like to use a fixed Client ID per Domoticz instance so that I can properly configure ACLs in Mosquitto. There's three connections above because I have one publish and two subscribe connections on this instance but there's no reason I can see from the Mosquitto side why they shouldn't use a common Client ID.

I already have my Domoticz instances set to use topic /tele/Domoticz_<MAC last 6> and Mosquitto recognises ACL configuration of the format /topic/%c/ where %c is the client ID so the last piece of the jigsaw is deterministic client ID.

I might be out of date as I'm on 2024.7 for armv6 (Huge thank you to SjoerdNLD) but I couldn't see anything related in github issues.

Note that the wiki still says you have to set which appears from the above log to be untrue.

Cheers
Sumdum

Allow_anonymous has only to be set when you do not use an account to connect to mosquitto. Most users don not use an account for this and so need to set allow_anonymous. You seem to do use an account..

I have no idea about setting a client ID for a broker. I suppose the developers thought making a unique ID per mqtt gateway instance would be sufficient for most or even all use cases.

Hi,

It may be worth reading: https://www.hivemq.com/blog/mqtt-securi ... echanisms/

From StackOverflow:

Every MQTT Connection needs a unique client ID. With this unique client ID the broker can recognize when a client reconnects and can close an old potentially half-open TCP connection for the client. Also, the MQTT broker can hold a persistent session for MQTT clients if they desire to do so (cleanSession=false on CONNECT). If you disconnect and reconnect with the same client ID, you will receive all messages for your subscriptions you may have missed and the broker knows your old subscriptions for that client ID.

To use a Username and Password, instead of an open connection, see:
http://www.steves-internet-guide.com/mq ... d-example/

Regards

Thanks both,

It looks like my understanding is correct. I restarted the same Domoticz instance as above again and different GUIDs are used. Therefore Mosquitto is not able to do the tidying up FireWizard posted.

I'll pop a request in over on github.

Cheers
Sumdum

I couldn't find clear explanation in the MQTT specification whether Client ID must be unique to the hardware (Domoticz instance) or to the subscription. Making two connections with the same Client ID from the same PC using mosquitto_sub the sessions are unreliable. Therefore I believe that in MQTT terminology a client is the subscription. i.e. unique to each MQTT object listed on the hardware page (assuming they all go to the same broker). I've put in an enhancement request based upon that understanding.

Here's what Steve has to say on ACLs by the way:
http://www.steves-internet-guide.com/to ... iguration/

I do understand that perhaps you want an ACL per instance, but that should be possible with the current Domoticz+GUID client ID.
I do not understand the issue that Domoticz user Bob should not see topic "garage". Domoticz User Bob can only see the Domoticz devices you assign to him. User Bob cannot see any MQTT topics/messages, only Domoticz devices. So why set an ACL on the MQTT broker for user Bob?

Sorry but no, it isn't possible with the current model. MQTT ACLs are by default deny, if you activate a default ACL file every user and every client is denied access to anything. You have to grant users and/or clients access to topics you want them to be able to read and write therefore you need to know the users and client IDs that will be connecting. Each time Domoticz connects it uses a new GUID so Client access ACLs are currently impossible. I could do it with a unique user for each session but that's not how it is intended to be done.

Garage is not a topic, it's a Client ID.

Just trying to understand: I dont know how your Domoticz environment is setup but the Domoticz server should always have access to MQTT Broker. It should not be depend on the user behind it. Just struggling to read through your Github issue to understand your problem.

I can understand that you want to limit the MQTT topics that Domoticz can see. And that you can arrange with MQTT Broker accounts. Domoticz MQTT Hardware Gateway (instance?) Kitchen (with some random UID) with MQTT user kitchen can only see kitchen topics. Domoticz instance Garage (with some random UID) with MQTT user garage can only see garage topics. And the rest of the topics on the MQTT Broker like bedroom, mancave etc are hidden from Domoticz MQTT hardware gateways.

You also did not mention in the github issue that the current Client ID is changing after a new startup of the Domoticz MQTT gateway. If that is fixed it would perhaps help? Does it really change after a new startup of the Domoticz MQTT Hardware Gateway, is the GUID not directly related to the Hardware Gateway?

I am just saying this as implementation of your request can take weeks or years or even never. Unless you code it yourself of course.

And for a reference for other readers, this is the github issue: https://github.com/domoticz/domoticz/issues/6308

waltervl wrote: ↑Tuesday 15 April 2025 16:26 You also did not mention in the github issue that the current Client ID is changing after a new startup of the Domoticz MQTT gateway. If that is fixed it would perhaps help? Does it really change after a new startup of the Domoticz MQTT Hardware Gateway, is the GUID not directly related to the Hardware Gateway?

Thanks, I've updated the github issue with this and it looks like you understand what I'm trying to achieve. Remember though it's about write protection as well as read. I want to limit all my IoT endpoints to the topics they can write as everything goes [endpoint] -> MQTT -> NodeRed -> Influx¹

If the GUID was fixed it would solve the issue but it's not the neatest way, I'd have to dig into the Mosquitto logs to get my GUIDs and then it would be trial and error to find which one belongs to which gateway. As I mentioned above one of my Domoticz installs runs three gateways, one to publish and two to receive data. The Mosquitto logs only give the IP.

I wish I could make the changes myself but the code, hell even just the file structure, is too complex for me to understand. I'll have to hope one of the active coders pick it up. And then I'll have to wait for it to go out in a mainline issue and for SjoerdNLD to produce an Arm6 build. I've tried compiling on Arm6 myself and couldn't get past the Boost prerequisites. The whole compile chain as published worked like a charm on Arm7 when I tried but on Arm6 I was defeated.

Cheers
Sumdum

¹I know Domoticz can write directly to Influx but it didn't give me the control I want over the data format. I'm pulling data from many other types of endpoint and I want the data in Influx to be consistent, using NodeRed standardise everything achieves that.