Access of Supla MQTT from other docker instances (Homeassistant)

[[email protected]]

List network hosts on docker so we can see the ips in docker, maybe that is not the same network

[PeterP]

NETWORK ID NAME DRIVER SCOPE
fb08aef1ce38 bridge bridge local
bfb23d8121b1 host host local
8e28af26bb40 mosquitto_webproxy bridge local
8a2e361c03d3 nginx_webproxy_default bridge local
1e034867647c none null local
99a7fe20e3ce supla_default bridge local
680897e7ae9c webproxy bridge local


HA is configured as "host" - this is the default setting for HA in container.

And in addition I set both supla and mosquitto containers joining the network webproxy and bridge additionally after I observed no connections in order to allow them to see each other

image.png

... and I also checked now with 'docker network inspect webproxy' that both (Supla and mosquitto) are in the same network and should see each other.

I toggle 'enable / disable' each time to check if I see something in the mosquitto log : absolutely noting, seems still Supla does not ask for register for the MQTT broker. By the way: the waiting between toggling the MQTT on/off is annoying, is it possible to shorten the waiting time while testing?

Thank you for digging into the issue!

[[email protected]]

I would try with one network only

[PeterP]

I change to only one additionally (I mean the default supla network I think I should keep - it's necessary for the supla DB (mariaDB) and to talk from Server to Cloud or vice versa)....

But meanwhile I think the latest SUPLA image is not working as it should.

I will test now with 2 last options: either the machine ip or internal ip of shared network as broker ip
I'll give feedback - just the waiting of some 10 minutes for toggling the MQTT is taking too much time for testing.

Now tested both options : still no attempt / entry in mosquitto.

I wonder if the registration dialog for MQTT broker was accidently switched off in this image release.

So at this point all potential ideas for faults are gone on my side. I really tried hard and proved even the network of docker and checked with all IPs for mosquitto, also with the container name itself.... nothing helped to see even a slight http request to the broker.... so I have to give up for this release. Very dissapointing but anyway a heartful thanks to anyone who tried to help

Peter

[klew]

Have you checked logs on SUPLA server side? I don't know how and where, but there should be something.
If SUPLA can't connect broker, and there are no logs on broker side, then you should check logs on SUPLA side.

[PeterP]

Hi, this it what might bring s little light - if I can find which log and where to look for. It‘s not that I only ask here - I already parsed logs not only container logs but also others.

But I really do not know if Supla logs that if it‘s doing nothing to try the broker connect.

Is it possible to know in which log this could be to find?

E.g. if I try to send anything, wrongly formatted and with a wrong protocol to mosquitto this will make a log error entry on mosquitto side - checked with http request to the opened mgtt port.

So it‘s for sure that Supla sends nothing to mosquitto via TCP.

On the other hand: I checked that both Supla and mosquitto have an ip-address in the same subnet the. join in Docker both.

I also pinged from host those IP adresses.

I configured the Supla MQTT as recommended and described in the yaml and aleays restsrted the containers.

I run a device in Supla and I started the MQTT connect on the Supla web interface as described.

I configured through sll potential IP snd names for each separate test:

Nachine IP, internal docker IP, host names etc.

Nothing of those tests gave any reaction with a log on the mosquitto - from that I assume the function itself is not working in the downloaded Supla image….

Do you understand the conclusion?

[PeterP]

Dear Supla Enthusiasts,

I checked the supla.cfg file in the running supla server container which is located at
/etc/supla-server/supla-cfg

It contains the following section:

[MQTT-BROKER]
enabled=0
host=
port=8883
ssl=0
username=
password=
client_id=


So with this I assume my yaml config for broker was not set correctly inside supla server.

With that I think it‘s a bug in release 5/26 perhaps?

I think the config in .env and therefore in docker-compose.yaml should be reflected here to open a broker connection?

I also edited the docker-compose.yml and deleted all lines pointing to .env.default (which was there too)

And let create the containers new.

-=> unfortunately the supla cfg file is always created without the correct settings of mqtt.

I think that‘s weird.


Best Regards
Peter

[Robert Błaszczak]

Peter, what devices have you added to Supla Cloud? Do you have a physical Supla controller?
You mentioned earlier that you’d added weather and energy prices. I don’t use MQTT, but I’m not sure whether these virtual devices publish topics (I’d ask anyone using MQTT to confirm this).

[PeterP]

I have created a physical device via supla-device-linux integration which works well in Supla showing temperature. The virtual devices do not run anyway.

But the first thing which needs to be done by supla server is to register at mosquitto. I think this will never happen (as observed) if the supla-server sees the mentioned empty/disabled config for MQTT.

The data from .env config are not taken and written to the supla.cfg within the container.

So I can do nothing on the behavior of supla server unless it‘s bug fixed I think…

.. and to complete the analysis:

with

timeout 3 bash -c ‘</dev/tcp/mosquitto/1883‘ && „port open“ || „port closed“

I could test from within the supla-server container that it really can contact mosquitto.


Now it‘s clear as the supla.cfg is only read in during container start: the problem is that the image does not carry the .env configuration to supla server.

So this need to be updated by supla developers.

I really cannot change and compile the whole c++ stack for myself.

So waiting for bugfixes!!!

[PeterP]

With manual editing the supla.cfg file in /etc/supla-server/ and adding the correct MQTT values
and using docker kill —-signal=SIGHUP to restart the app without recreation of the container the connect works and also the HA discovery.

So the task is now on developer side. This workaround is not stable —- any tecreation/restart of containers revoke the connection.