I have a question about subscribing a dynamic mqtt message:
fbdk[].mqtt[tcp://localhost:1883, topic, message]
Is it possible to build a dynamic message by subscribing a message into a fixed text?
If yes, how can I do that: with +, $, &,....?
For example:
Dynamic value is ZAHL, which changes all the time - for example = 4
Static values are TEXTa and TEXTb.
Now I want to merge them to get something like this
I'm not sure if I understand your question. I had a look at the code and the mqtt layer does not have a parameter called message. Do you mean you have a changing topic name?
If so does this topic name change during the execution of your application? In this case I think it will be best to write an FB which will use the IEC 61131-3 string functions to create the required ID string for the subscriber.
If it is static but changes on certain deployments then the Virtual DNS feature of 4DIAC could be interesting for you. This would allow you to write the following:
In the Virtual DNS view you can have then several configurations where you assign different values to you key ZAHL. Depending in which of your configuration is set as active the this value is then inserted before the download to the device.
I hope this helps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
please consider that the ID of a PUBLISH function block for MQTT is defined fbdk[].mqtt[tcp://IP:1883, clientID, Topic] if you want to change the data that is sent, then you have to do that at the PUBLISHER's data inputs SD_x.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the quick answers!
Sorry for my bad wording. Yes, with message I meant topic.
To explain it better I will switch to German language:
Ich hole mir die Daten eines Subscribers immer per MQTT (von einer Datenbank) ab.
In meinem Beispiel sieht die Adresse am Input so aus fbdk[].mqtt[tcp://localhost:1883, logic, WHA/TEMP4HRS].
Den Wert von WHA/TEMP4HRS beziehe ich bei jedem Trigger.
Jetzt ist es aber so, dass ich diese Adresse gerne dynamsch gestalten würde - das heißt ich möchte den Wert "4" mit jedem Trigger beliebig ändern können, sodass zum Beispiel aus WHA/TEMP4HRS dann WHA/TEMP1HRS wird UND ich dann den Wert der Adresse fbdk[].mqtt[tcp://localhost:1883, logic, WHA/TEMP1HRS] beziehe.
Ich hole per MQTT quasi je Trigger den Wert 1–4 von der Settings-Datenbank,
setze ihn zwischen WHA/TEMP und HRS
bekomme z.B. fbdk[].mqtt[tcp://localhost:1883, logic, WHA/TEMP1HRS]
und subscribe den Wert von WHA/TEMP1HRS
Best regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the german explanation I hope it is ok to answer in english.
For that my suggestion with the seperate FB would be the option you need to go for. However you then also need to do an INIT(-) INIT(+) cycle all the time wou need to change the ID parameter.
Maybe a better solution would be to use a publish_4 to subscribe to all 4 topics and select the one you need. Don't know if the current implementation of MQTT in FORTE is capable of doing it that way. Maybe Martin can shed some light here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is no way for a single Publish or Subscribe FB to subscribe to more than one topic. This would not make any sense from my perspective, as the whole idea of topics is to separate the data flows from each other.
The solution of INIT and DEINIT the publish/subscribe FBs would be possible, but again I don't think it would be a good solution, to the follwoing reasons:
Each DEINIT/INIT cycle will cause to delete and create the connection to the broker, which will cause unncessary computation overhead
Messages on the subscribed/unsubscribed topics willl get lost anyway in the period where no topic is subscribed
It will be a rather confusing program
In my opinion it would be better to permanently subsribe all needed topics and to programmatically select which one will be used, if all of them are sent all the time, as this generates a minimum amount of overhead, as messages gets received and decoded, but this overhead is usually neglectable. If not all data topics needs to be sent permanently, it would be even better to supress the sending of the data, which then cause no overhead at all, as the FBs are only activated if a message has arrived from them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear all,
I have a question about subscribing a dynamic mqtt message:
fbdk[].mqtt[tcp://localhost:1883, topic, message]
Is it possible to build a dynamic message by subscribing a message into a fixed text?
If yes, how can I do that: with +, $, &,....?
For example:
Dynamic value is ZAHL, which changes all the time - for example = 4
Static values are TEXTa and TEXTb.
Now I want to merge them to get something like this
and in 4DIAC it looks like that
Is that possible?
Thank you,
Wolfgang
Hi,
I'm not sure if I understand your question. I had a look at the code and the mqtt layer does not have a parameter called message. Do you mean you have a changing topic name?
If so does this topic name change during the execution of your application? In this case I think it will be best to write an FB which will use the IEC 61131-3 string functions to create the required ID string for the subscriber.
If it is static but changes on certain deployments then the Virtual DNS feature of 4DIAC could be interesting for you. This would allow you to write the following:
fbdk[].mqtt[tcp://localhost:1883, topic, TEXTa%ZAHL%Textb]In the Virtual DNS view you can have then several configurations where you assign different values to you key ZAHL. Depending in which of your configuration is set as active the this value is then inserted before the download to the device.
I hope this helps.
please consider that the ID of a PUBLISH function block for MQTT is defined fbdk[].mqtt[tcp://IP:1883, clientID, Topic] if you want to change the data that is sent, then you have to do that at the PUBLISHER's data inputs SD_x.
Thank you for the quick answers!
Sorry for my bad wording. Yes, with message I meant topic.
To explain it better I will switch to German language:
Ich hole mir die Daten eines Subscribers immer per MQTT (von einer Datenbank) ab.
In meinem Beispiel sieht die Adresse am Input so aus fbdk[].mqtt[tcp://localhost:1883, logic, WHA/TEMP4HRS].
Den Wert von WHA/TEMP4HRS beziehe ich bei jedem Trigger.
Jetzt ist es aber so, dass ich diese Adresse gerne dynamsch gestalten würde - das heißt ich möchte den Wert "4" mit jedem Trigger beliebig ändern können, sodass zum Beispiel aus WHA/TEMP4HRS dann WHA/TEMP1HRS wird UND ich dann den Wert der Adresse fbdk[].mqtt[tcp://localhost:1883, logic, WHA/TEMP1HRS] beziehe.
Best regards!
Thanks for the german explanation I hope it is ok to answer in english.
For that my suggestion with the seperate FB would be the option you need to go for. However you then also need to do an INIT(-) INIT(+) cycle all the time wou need to change the ID parameter.
Maybe a better solution would be to use a publish_4 to subscribe to all 4 topics and select the one you need. Don't know if the current implementation of MQTT in FORTE is capable of doing it that way. Maybe Martin can shed some light here.
Hi all,
There is no way for a single Publish or Subscribe FB to subscribe to more than one topic. This would not make any sense from my perspective, as the whole idea of topics is to separate the data flows from each other.
The solution of INIT and DEINIT the publish/subscribe FBs would be possible, but again I don't think it would be a good solution, to the follwoing reasons:
In my opinion it would be better to permanently subsribe all needed topics and to programmatically select which one will be used, if all of them are sent all the time, as this generates a minimum amount of overhead, as messages gets received and decoded, but this overhead is usually neglectable. If not all data topics needs to be sent permanently, it would be even better to supress the sending of the data, which then cause no overhead at all, as the FBs are only activated if a message has arrived from them.
Dear Martin,
thank you for the explanation!
Best regads,
Wolfgang