Hello Petr,

thanks for your question, please see my answer below:

There are no changes to the databus’s mqtt broker between the versions mentioned in the question. Also, the databus is configured no to override the keep alive value sent by the clients.

In MQTT, the keep alive time set by the client enables the brokers to sustain the client session even when there are no actual message exchange with he use of the Ping Request and Response.

It is the client that sends the Ping Request and the broker the Responds.

The broker will clean up the session if the client does not send either a control packet or a ping Request within the “Keep Alive” time.

Since the Ping messages can inundate the broker logs the current logs are limited to the client session event logging. This is the source of “Client XYZ has exceeded timeout, disconnecting”.

The same could also be read from the Databus Configurator’s Application Logs view.

This scenario could be caused if the client’s event loop was blocked or was terminated within the keep alive time sent by the client.

Here is a popular webpage which explains the MQTT Ping Request Response : http://www.steves-internet-guide.com/mqtt-keep-alive-by-example/

Please feel free to share some code snippets to check your implementation and what could cause your behaviour.

Hello Norman,

well, it is not possible to set a keep alive value to "0".

The specification for MQTT protocol says "A Keep Alive value of 0 has the effect of turning off the Keep Alive mechanism. If Keep Alive is 0 the Client is not obliged to send MQTT Control Packets on any particular schedule.", but this is the citation from IED databus documentation - Databus V2.1.0, Operating Manual, 04/2023, A5E50594959-BF

Note
MQTT clients connecting to Databus must mandatorily set "keep alive" greater than "0", else
MQTT client will not be connected to Databus.

I am able to set a keep alive value to maximum one (65535) though. If I do so all messages arrive from broker, but the time period between S7 Simatic connector timestamp "ts" and the time the mqtt client receives messages is still increasing.

Note, that I did’t mention previously that the same code that I run locally in a docker container on my PC using External databus connection works well as we expected on both IED.

In the MQTT specification there is also statement: "If a Client does not receive a PINGRESP packet within a reasonable amount of time after it has sent a PINGREQ, it SHOULD close the Network Connection to the Server." So if there is an unacceptable delay on IED Databus that could be the reason the client disconnect itself(?).

Best regards,

Petr

Hello Norman,

>> Does other clients (e.g. Flow Creator MQTT Node) are working fine with your Databus?

Yes and no. I tried it on Monday…

I verified that the mqtt node in the NodeRed app on the same IED receives all messages from the Databus and gets it instantaneously (note that from some unknown reasons no one can log into FlowCreator and test a connection to the databus - we have tried to re-install FlowCreator multiple times).

On the other hand, the DataService connectors/adapters page show some warning an I am not able to select an appropriate connector for given asset's variable at all.

>>...indicate lack of ping response from the client

You have meant ping request from the client, haven’t you?

>> Would it be possible to share your code or a network trace for further debugging?

We will consider it...

Thanks,

Petr

Hello Norman,

>> Regarding the Data-Service connectors, did your specify the needed topics….. ie/#

Yeap. Using hashtag is exactly how we are used to setting the needed topics

Best regards,

Petr