Does anyone know why the UMH MQTT Broker would reject connection requests of some devices as not authorized, but accept others? They connected to a standalone hivemq-ce instance without problem. The HiveMQ log (via

kubectl

) doesn't list any connection requests at all, but it does tell me there's no authentication or authorisation.

For some Tasmota Smart Sockets of mine this took me ages to figure it out, but HiveMQ config map by default rejects retained messages and enforces UTF 8 validation. I’m on the road but will share my guide below that I tinkered with

@Ferdinand I remember there was something about those MQTT options that we changed, do you have some background infos on this?

https://github.com/united-manufacturing-hub/united-manufacturing-hub/blob/v0.28.0/deployment/united-manufacturing-hub/templates/hivemq/config-hive.yaml This is our current hivemq config. We by default have retained messages disabled. If you use MQTT 3.1.1 or 3.1 it will disconnect with "Not Authorized" (https://docs.hivemq.com/hivemq/latest/user-guide/configuration.html#config-mqtt-retained-messages).

OK, so I was able to reproduce this in Node-Red. I set a retained last will message, and the connection was refused - with both MQTT 3.1.1 and 5. The 3.1 error message now makes sense - because it doesn't have a more appropriate error code that it can send. Changing the client's retained setting to

false

allows the connection to succeed, but of course breaks the last will strategy. How can I change Hive's

config.xml

permanently on my UMH system? Changes inside the container will be gone when it restarts, right?

FYI: If I remember correctly, HiveMQ stores all of those retained messages, which can result in very high memory usage (or something similar). @Ferdinand @Luke van Enkhuizen do you know how we can change the config permanently? i know its possible, but don't remember how exactly. i assume some configmap

I don't think that setting is exposed via helm, but you can change it in the configmap directly. (united-manufacturing-hub-hivemqce-hive in the united-manufacturing-hub namespace)

Yes config maps but be sure to backup in case of updates! In the hivemq xml file.

Thanks for the tips. I patched the configmap and restarted HiveMQ (deleted the pod so Kubernetes recreated it). Now it's doing what I want. Yay!

Feel free to post them, I can then create maybe later an article for it 🙂

OK, here's what I did. I hope Discord copes with the formatting...

# Look at current HiveMQ configuration
sudo $(which kubectl) exec --stdin --tty \
    -n united-manufacturing-hub united-manufacturing-hub-hivemqce-0 --kubeconfig /etc/rancher/k3s/k3s.yaml \
    -- \
    cat /opt/hivemq-ce-2024.1/conf/config.xml

# List available ConfigMaps
sudo $(which kubectl) get configmaps \
    -n united-manufacturing-hub --kubeconfig /etc/rancher/k3s/k3s.yaml

# Get current configmap
sudo $(which kubectl) get configmap \
    -n united-manufacturing-hub --kubeconfig /etc/rancher/k3s/k3s.yaml \
    united-manufacturing-hub-hivemqce-hive \
    --output yaml > united-manufacturing-hub-hivemqce-hive.yaml
    
# Create a patch file containing the changed YAML (ie: data->config.xml, set retained messages enabled to true)
sudo $(which kubectl) patch configmap \
    -n united-manufacturing-hub --kubeconfig /etc/rancher/k3s/k3s.yaml \
    united-manufacturing-hub-hivemqce-hive \
    --patch-file united-manufacturing-hub-hivemqce-hive.patch.yaml

# The config.xml file inside the pod will have now been changed.

# Restart HiveMQ by deleting the pod (and having Kubernetes recreate it)
sudo $(which kubectl) delete pod \
    -n united-manufacturing-hub --kubeconfig /etc/rancher/k3s/k3s.yaml \
    united-manufacturing-hub-hivemqce-0