Thank for the elaborate description and analysis. You are right the raw layer is currently only working with a single in or output and this in or output has to be of type STRING. The problem for PUB and sUb 0 is that the raw layer wouldn't know what to generate as payload for the MQTT messsage. With FBDK a 0x5 will be send for pure event PUBs. So this could be better on your case.

mqtt[tcp://ip-address:port, client-id, topic]

Regarding the invalid ID I see two issues. First of all I think you mixed up ClientID and Topic name. The ClientID should be the second mqtt parameter and currently it needs to be the same for all MQTT pubs and subs within one device. We know this is a little bit inconvenient and we should improve this.

The second thing can really be that the domain names is also an issue. However this depends on the paho lib and if your device supports name resolving. For example on the Bosch Rexroth PLC name resolving was not working and therefore I had to replace the the domain names with ips.

FBDK then. Is it possible to use a single MQTT layer? Just including as ID:

mqtt[tcp://ip-address:port, client-id, topic]

The PUBLISH_0 and SUBSCRIBE_0 FBs are in different HW devices, each with its own client id (4diac-pub-test and 4diac-sub-test respectively) and they are both using the same topic (4diac-events). The idea is that one device triggers an event on the other device, as a first test for MQTT communication with 4DIAC.

I think that the problem may be inside the MQTTHandler::registerLayer() method. Is there anyhow that I can check that MQTT paho was properly linked to FORTE?

Adrian Orive wrote on Thu, 16 March 2017 08:29

FBDK then. Is it possible to use a single MQTT layer? Just including as ID:

mqtt[tcp://ip-address:port, client-id, topic]

No. The problem is that MQTT does not define a payload format and therfore you always need in 4diac a layer on top of MQTT layer.

Adrian Orive wrote on Thu, 16 March 2017 08:29

The PUBLISH_0 and SUBSCRIBE_0 FBs are in different HW devices, each with its own client id (4diac-pub-test and 4diac-sub-test respectively) and they are both using the same topic (4diac-events). The idea is that one device triggers an event on the other device, as a first test for MQTT communication with 4DIAC.

Not sure if i got your idea. This will only work if the pub and sub are mapped on two different devices. In your screenshot both where mapped onto the same device and then you need to use the same clientid for both FBs otherwise the second FB will not work.

Adrian Orive wrote on Thu, 16 March 2017 08:29

I think that the problem may be inside the MQTTHandler::registerLayer() method. Is there anyhow that I can check that MQTT paho was properly linked to FORTE?

I have a hard time to believe this as the MQTT is used by many users which din't had such problems.

I understand that. I meant for PUBLISH_0 and SUBSCRIBE_0 FBs, as they do not need any payload. I tried it and worked just fine, so I can confirm that PUBLISH_0 and SUBSCRIBE_0 MQTT FBs do not require an additional communication layer.

Those FBs are in two different HW devices, sorry if I didn't make that clear from the start. They are both with a white background as they are not defined in the app view, but inside each HW resource. I already show the part of the code that raises an INVALID ID error if either the host or the client id of every mqtt FB in a HW device are different.

Sorry, I didn't mean that there was a bug there, I was just saying that I suspect that the error was being raised from that function. I have it working properly both for empty payloads with just a single communication layer (mqtt[...]) and for strings as payloads with two communication layers (raw[].mqtt[...]).

Adrian Orive wrote on Fri, 17 March 2017 08:41

I understand that. I meant for PUBLISH_0 and SUBSCRIBE_0 FBs, as they do not need any payload. I tried it and worked just fine, so I can confirm that PUBLISH_0 and SUBSCRIBE_0 MQTT FBs do not require an additional communication layer.

I don't know that MQTT allows also empty messages. Interesting and good to know. But it is a bit of a hack and can be fragile. Maybe it would be better to expand the raw layer also to PUB/SUB 0.

That's good to here. But still I'm a bit curios why it didn't work in the first place.

1. A single layer setup (mqtt[...]) can only be used for PUBLISH_0 and SUBSCRIBE_0 FBs as MQTT does not enforce any payload.
   
2. The raw data layer can be used in a two layer setup (raw[].mqtt[...]) only for PUBLISH_1 and SUBSCRIBE_1 FBs as this layer enforces a single input/output. Only STRING inputs or outputs are allowed, not even WSTRING ones will work.
   
3. The fbdk layer can be used as two layer alternative (fbdk[].mqtt[...]) for PUBLISH_0 and SUBSCRIBE_0 FBs, including a non-meaningful payload. This increases both the message size and the processing time so I would not recommend it as it is not needed.
   
4. Using the fbdk layer for higher ammount of inputs or outputs has not been tested.
   

Alois Zoitl wrote on Fri, 17 March 2017 22:13

Adrian Orive wrote on Fri, 17 March 2017 08:41

I understand that. I meant for PUBLISH_0 and SUBSCRIBE_0 FBs, as they do not need any payload. I tried it and worked just fine, so I can confirm that PUBLISH_0 and SUBSCRIBE_0 MQTT FBs do not require an additional communication layer.

I don't know that MQTT allows also empty messages. Interesting and good to know. But it is a bit of a hack and can be fragile. Maybe it would be better to expand the raw layer also to PUB/SUB 0.

Empty payloads are allowed in MQTT's specification, so I would not consider it to be fragile. Using a single layer sounds fine to me, but if you want to have 2, fbdk[].mqtt[...] also works. From a network efficiency point of view this 2 layer messages are sending non-needed bytes that in a constrained application may be relevant.

Adrian Orive wrote on Mon, 20 March 2017 07:34

Alois Zoitl wrote on Fri, 17 March 2017 22:13

I don't know that MQTT allows also empty messages. Interesting and good to know. But it is a bit of a hack and can be fragile. Maybe it would be better to expand the raw layer also to PUB/SUB 0.

Empty payloads are allowed in MQTT's specification, so I would not consider it to be fragile. Using a single layer sounds fine to me, but if you want to have 2, fbdk[].mqtt[...] also works. From a network efficiency point of view this 2 layer messages are sending non-needed bytes that in a constrained application may be relevant.

With fragile I meant that it is fragile from 4diacs' mqtt layer implementation. Which some further investigation may be needed.

Compared to the overhead of a TCP message sending one or two additional bytes seams to be negligible. One could for example send the event count that ocured so far. This would allow to detect if messages where lost on the way.

If the MQTT layer is the top most one, the sendData() function will be called with no arguments a 0 in as the second argument if PUBLISH_0 is being used so an empty payload will be sent. I don't think it needs further checking but it could be added.

TCP already offers you losless guarranty. However the event number may be useful for other reasons. The two bytes may be negligible compared with TCP overhead (20 bytes, 10%) in most situations but for ultra-optimized applications even these two bytes may count. The communication layers allow both options to be implemented and be the user the one who selects which to use.

Adrian Orive wrote on Tue, 21 March 2017 15:53

TCP already offers you losless guarranty. However the event number may be useful for other reasons. The two bytes may be negligible compared with TCP overhead (20 bytes, 10%) in most situations but for ultra-optimized applications even these two bytes may count. The communication layers allow both options to be implemented and be the user the one who selects which to use.

This depends to whome the TCP connection is. In MQTT only to the broker. I noticed but can not confirm that if the subscriber is gone or connects later it does not get any information how many messages have been. Sometimes dont even get the latest value but only updates. But I've to say I'm not very into MQTT.