# e!Cockpit MQTT FbSubscribeMQTT



## Jproject (20 September 2021)

Hallo,

ich habe eine Steuerung PFC100 mit e!Cockpit projektiert. Daten sollen über den Mosquitto Broker per MQTT ausgetauscht werden.

Ich habe jetzt mal Testweise ein Topic mit Daten angelegt, die Daten werden per Openhab gesendet und sollen von der Steuerung ausgelesen werden.
Jetzt habe ich folgendes Problem, wenn ich einen FB Subscribe anlege funktioniert das Senden der Date nicht immer. Ich muss die Steuerung komplett neu starten dann geht es manchmal. Wenn ich einen 2. Instanzbaustein vom FbSubscribeMQTT hinzufüge und ihn lade geht nichts mehr. Die Daten werden ordentlich von Openhab versendet, ich habe das per MQTT.FX überprüft aber die Wago PFC100 empfängt sie nicht.

Hat jemand eine Idee wie man das lösen kann?




Normal sollte der Wert in der Variable: sMessage_Licht1_Dimmer erscheinen aber sie tut es nicht.


----------



## Oberchefe (20 September 2021)

8212 mit Mosquitto
					

Hallo, ich habe besagten Controller mit dem MQTT-Broker Mosquitto laufen. Was muss ich nun im WBM eintragen damit ich mit codesys darauf zugreifen kann? Wie spreche ich die beiden Cloudschnittstellen an?. Die Doku gibt bis auf den Hinweis mit Mosquitto nichts her. Google weiss auch nicht viel...




					www.sps-forum.de


----------



## Jproject (20 September 2021)

Hallo Oberchefe,

das hat leider nicht funktioniert aber danke. Die Verbindungen habe ich alle auf Connected=1
Wenn ich den FbSubscribeMQTT im Programm PLC_PRG mehrfach aufrufe dann geht es. Sobald ich den  Baustein mehrfach in einen FB aufrufe bekomme ich keine Daten.


----------



## Blockmove (20 September 2021)

Hast du die aktuelle Firmware auf dem Controller und die aktuellen FBs?
Wago hat da öfters geändert.


----------



## Jproject (22 September 2021)

Ich habe die Firmware und die Bibliothek auf den neusten Standgebracht, leider ohne Erfolg.
Ich kann den FbSubscribeMQTT in einem anderen FB nur einmal aufrufen, wenn ich ihn ein 2.mal aufrufe und Instanziiere bekomme ich keine Werte.


----------



## WAGO Soluteer (22 September 2021)

Hallo Jproject,
hast du den FbSubscribeMQTT_2 verwendet (der alte Baustein (FbSubscribeMQTT) ist für FW<17)? 
Da gibt es eine FB_INIT Methode, mit der du den Baustein auf eine Connection hängen musst. Das machst du bei der Deklaration der Instanz: "mySubscriber: FbSubscribeMQTT_2(WagoAppCloud.eConnectionId.Connection1);" 

Die Connection ist nötig, da im WBM 2 verschiedene Verbindungen parametriert werden können, die unterschiedliche Protokolle verwenden.
Desweiteren würde ich prüfen, ob folgendes eingestellt ist: 

Cloud Platform: MQTT Any Cloud
Hostname: 127.0.0.1
Port number: 1883
Data protocol: Native MQTT
Außerdem könntest du den Status im WBM abfragen: Configuration>Cloud Connectivity>Status
Meistens sieht man da schon, wo es hakt.

Viel Erfolg!


----------



## Jproject (22 September 2021)

Ich habe jetzt den FbSubscribeMQTT_2 verwendet aber jetzt kommt immer folgende Fehlermeldung:



Was kann ich da jetzt tun?


----------



## WAGO Soluteer (22 September 2021)

Du kannst den Baustein nicht debuggen, da er übersetzt in der WagoAppCloud gespeichert ist. Also mit F10 die Bausteininstanz überspringen und nicht mit F8.


----------



## Jproject (22 September 2021)

Ich finde damit keinen Fehler beim Debugen


----------



## Jproject (22 September 2021)

Ich vermute, dass es ein Problem in der Deklaration vom FbSubscribeMQTT_2 gibt.


----------



## WAGO Soluteer (22 September 2021)

Wie ist der Verbindungsstatus des Connectors im WBM?


----------



## Jproject (22 September 2021)

Verbunden.


----------



## Jproject (22 September 2021)

So Bald ich einen 2. FbSubscribeMQTT_2 einfüge kommt es zu der Fehlermeldung.
Hier mal die Deklaration:


----------



## WAGO Soluteer (22 September 2021)

Ok, das sieht gut aus. 
Es gibt noch Parameter zum Verstellen des Payload und der Anzahl der Subscriptions:


Eventuell musst du die Anzahl da hochsetzen, wenn ein Fehler kommt. Welche Beschreibung hat der Fehler?


----------



## Jproject (22 September 2021)

Nach den Werten habe ich geschaut, diese sind soweit ok.
Wenn ich das Programm starte passiert erstmal nichts, wenn ich einen neuen Wert sende kommt sofort diese beiden Fehlermeldungen:




Die Steuerung geht in  Stop und lässt sich nur durch einen Neustart retten.


----------



## WAGO Soluteer (22 September 2021)

Probiere mal bitte ohne die MemCopySecure Bausteine, ob die Steuerung immer noch in den Ausnahmezustand geht. Wie es scheint, stürzt er erst ab, nachdem was empfangen wurde.


----------



## Jproject (22 September 2021)

Ja genau, ich habe MemCopySecure auskommentiert danach ging es ohne Probleme. Was kann ich jetzt tun um den Wert auszulesen?


----------



## WAGO Soluteer (22 September 2021)

Ich würde die SysMem.SysMemCpy Fuktion verwenden und diese nicht zyklisch aufrufen wie in deinem Code, sondern nur, wenn der Baustein Daten empfangen hat. Da geht nämlich das "xDataReceived" Flag auf TRUE.  Also so, oder ähnlich:

`IF mySubscriber.xDataReceived THEN
   SysMem.SysMemCpy(ADR(myDestination),ADR(mySource),MIN(mySubscriber.dwRxNBytes,SIZEOF(myDestination)));
END_IF`
Du kannst das Ganze noch verbessern, indem du das empfangene Topic auswertest und dann der Variable via CASE zuordnest. Das brauchst du, wenn du Wildcards benutzt.


----------



## Jproject (22 September 2021)

Hey Wago Soluteer,

danke für die Hilfe. Wenn ich die Funktion SysMem.SysMemCpy aufrufe, bekomme ich die Fehlermeldung, dass er die Funktion nicht kennt. Muss ich die Funktion über eine Bibliothek einfügen?


----------



## WAGO Soluteer (23 September 2021)

Ja selbstverständlich. Die Bibliothek muss noch eingebunden werden. 
Bibliotheksverwalter>Bibliothek hinzufügen


----------



## Jproject (23 September 2021)

Danke, jetzt habe ich die Funktion "SysMemCpy" gefunden.



Ich muss die Funktion über WagoSysPlainMem.SysMem.SysMemCpy aufrufen.


----------



## Jproject (23 September 2021)

WAGO Soluteer schrieb:


> Du kannst das Ganze noch verbessern, indem du das empfangene Topic auswertest und dann der Variable via CASE zuordnest. Das brauchst du, wenn du Wildcards benutzt.


Wie kann ich die Topics dann auswerten?


----------



## Jproject (23 September 2021)

Zusätzlich habe ich jetzt noch ein Problem, wenn ich Werte sende kommen sie in MQTT.fx richtig an. Aber zum Teil werden sie in der Wago falsch dargestellt.
	

		
			
		

		
	



Muss ich da noch ein Einstellung vornehmen?


----------



## WAGO Soluteer (23 September 2021)

Das scheint ein Kopierproblem mit unterschiedlichen Stringlängen zu sein. Lösche doch mal die Schreibvariable "sMessageDimmValue" vor dem MemCpy Aufruf. Also `sMessageDimmValue:='';`


----------



## Jproject (24 September 2021)

Ich weiß ehrlich gesagt nicht, wie du das meinst?
Die Variable: sMessageLicht1DimValue, wird erst mit MemCpy aufgerufen.


----------



## Thruser (24 September 2021)

Hallo,

mit der SysMemCopy Funktion kopierst Du nur die Anzahl der empfangenen Zeichen in Deinen String. s. MIN(...) Abschnitt im Funktionsaufruf.

Wenn Dein neuer String also weniger Zeichen als Dein alter hat, dann werden nur die ersten Zeichen überschrieben, der Rest bleibt bestehen.

Z.B. erste Nachricht 10.3, zweite Nachricht 0 -> 00.3 bekommst Du dann als Ergebnis

Kann man auch an Deinen Daten sehen, Dein String ist zwei Zeichen lang '03', Du bekommst aber nru ein Zeichen übermittelt: dwRxNBytes = 1

Gruß


----------



## WAGO Soluteer (24 September 2021)

Genau das ist das Problem. Bitte den String vor dem Aufruf der SysMem.SysMemCpy() Funktion löschen! So wie ich es geschrieben habe.

`IF ...xReceived THEN
   sMessageLicht1DimValue:='';
   SysMem.SysMemCpy(...);
END_IF`
Zur Info: Ein STRING wird BYTE-technisch immer durch eine "0x0" abgeschlossen. Ist der neue Wert kürzer (weniger Zahlen/Zeichen) wird der alte Wert nur teilweise überschrieben und du bekommst diese komischen Zahlen. Im Übrigen würde ich keine STRING Variable als Wert nehmen, sondern REAL. Du müsstest eine temporäre Variable deklarieren und den DimWert in REAL umdeklarieren. Dein Code würde sich dann wie folgt ändern:

`IF ...xReceived THEN
   tmpString:='';
   SysMem.SysMemCpy(ADR(tmpString),...);
   rMessageLicht1DimValue:=TO_REAL(tmpString);
END_IF`
Ist etwas eleganter und mit REAL arbeitet es sich leichter


----------



## Jproject (24 September 2021)

Ok danke, das mit dem löschen habe ich jetzt verstanden.
Aber er zeigt mir immer noch die falschen Werte an, der String wird trotzdem nicht geleert.


----------



## WAGO Soluteer (24 September 2021)

Was passiert, wenn du den String mit dem Wert '0' statt '' löschst?


----------



## Oberchefe (24 September 2021)

Das setzen mit sMessageLicht1DimValue:=''; bringt gar nichts, weil damit nur das erste Byte auf 0 gesetzt wird. Es muss das erste Byte nach dem String auf 0 gesetzt werden, also abhängig von der empfangenen Länge.


----------



## WAGO Soluteer (24 September 2021)

Versuche es mal ohne SysMemCpy Funktion und kopiere die Bytes um.

Bitte folgende Variablen zusätzlich deklarieren:

`ptSource: POINTER TO BYTE; // Quellpointer
ptDestination: POINTER TO BYTE; // Zielpointer
i: DWORD; // Laufvariable`
Dann ersetzt du denen Code mit dem SysMemCpy durch folgendes:

`IF Subscribe_LichtDimValue1.xDataReceived THEN
   ptSource:=ADR(aDatenMQTT_LichtDim1);
   ptDestination:=ADR(sMessageLicht1DimValue);
   FOR i:=1 TO MIN(subscriber.dwRxNBytes,SIZEOF(aDatenMQTT_LichtDim1)) DO
       ptDestination^:=ptSource^;
       ptSource:=ptSource+1;
       ptDestination:=ptDestination+1;
   END_FOR
   ptDestination^:=0;
   rMessageLicht1DimValue:=TO_REAL(sMessageLicht1DimValue);
END_IF`

Das sollte nun funktionieren.


----------



## Jproject (24 September 2021)

Vielen vielen Dank. es hat beides funktioniert:


> ```
> IF Subscribe_LichtDimValue1.xDataReceived THEN
> ptSource:=ADR(aDatenMQTT_LichtDim1);
> ptDestination:=ADR(sMessageLicht1DimValue);
> ...





> ```
> IF Subscribe_LichtDimValue1.xDataReceived THEN
> 
> sMessageLicht1DimValue:='0';
> ...


----------



## Oberchefe (24 September 2021)

> Vielen vielen Dank. es hat beides funktioniert:


Das hier:
 sMessageLicht1DimValue:='0';

funktioniert aber nur für den Fall, dass der empfangene String genau 1 Byte lang ist, und das auch nicht wegen dem Text "0", welcher einem Bytewert von 48 entspricht, sondern geschuldet der Tatsache, dass dann das zweite Byte den Wert 0 erhält weil der String eine Länge 1 von hat.


----------



## Jproject (29 September 2021)

Also, der Code:

```
IF Subscribe_LichtDimValue1.xDataReceived THEN
   ptSource:=ADR(aDatenMQTT_LichtDim1);
   ptDestination:=ADR(sMessageLicht1DimValue);
   FOR i:=1 TO MIN(subscriber.dwRxNBytes,SIZEOF(aDatenMQTT_LichtDim1)) DO
       ptDestination^:=ptSource^;
       ptSource:=ptSource+1;
       ptDestination:=ptDestination+1;
   END_FOR
   ptDestination^:=0;
   rMessageLicht1DimValue:=TO_REAL(sMessageLicht1DimValue);
END_IF
```

funktioniert am besten. Danke nochmal für die Solide Lösung.


----------



## Jproject (29 September 2021)

WAGO Soluteer schrieb:


> Du kannst das Ganze noch verbessern, indem du das empfangene Topic auswertest und dann der Variable via CASE zuordnest. Das brauchst du, wenn du Wildcards benutzt.


@WAGO Soluteer  Kannst du mir das mal am Beispiel zeigen, wie ich die empfangenen Topics mit Case auswerte?


----------



## WAGO Soluteer (29 September 2021)

Zur Zeit meldest du dich mit je einem Baustein an ein Topic an, also zum Beispiel an deinen Dimmwert 1. Da brauchst du das nicht auszuwerten, da es 1:1 auf deine für Dimmwert 1 verwendete Variable kopiert wird. 
Wenn du aber einen Subscribe-Baustein für das ganze Wohnzimmer nimmst und dich auf "Wago/Wohnzimmer/#" subscribst, bekommst du vom Dimmer 1, 2, .. und allen anderen Geräten vom Wohnzimmer Nachrichten. Dann müsstest du das empfangene Topic stringtechnisch verarbeiten, also quasi den Sender "rausschneiden". In diesem Fall also "Licht1_Dimmer". Anschließend kannst du dann den empfangenen Wert via IF-Anweisung deiner Zielvariablen zuordnen. Dadurch würdest du die FB-Instanzen und Speicher sparen.


----------



## Jproject (29 September 2021)

Alles klar, das habe ich jetzt verstanden.

Wenn ich aber das Topic mit Case abfragen will, bekomme ich eine Fehlermeldung: Unerwartetes Token "+/Licht1/command" gefunden.



```
Subscribe_TopicZimmer(
    xSubscribe:= TRUE,
    sTopic :=in_sTopicSubscribe,
    eQoS:=eQualityOfService.QoS0,
    aPayloadData:= aDaten,
sReceivedTopic=> sTopciSubscribeRevceived);
    
CASE sTopciSubscribeRevceived OF
    '+/Licht1/command' : rdimValue1:= TO_REAL (sMessage);
END_CASE;
```

habe ich die Abfrage falsch strukuriert?


----------



## WAGO Soluteer (29 September 2021)

Das kann e!C nicht. Du müsstest mit IF THEN vergleichen


----------



## Jproject (8 Oktober 2021)

Hey @WAGO Soluteer, gibt es auch eine Möglichkeit, ähnlich wie beim Subscribe, mehre Topics über einen FbPublish zu veröffentlichen?


----------



## WAGO Soluteer (8 Oktober 2021)

Das sollte freilich funktionieren. Du musst nur das Topic vor dem Senden mit "xTrigger" neu zusammenbauen.
Schlussendlich wäre eine Art Auftragsliste denkbar, die über einen FbPublishMQTT_2 abgearbeitet wird.


----------



## Jproject (8 Oktober 2021)

Ich überlege schon wie ich die Auftragsliste Steuere, also über eine If Anweisung oder über eine FOR-Schleife.


----------



## WAGO Soluteer (8 Oktober 2021)

Ich würde eine Struktur bauen und die in ein Array schmeißen mit einem Zeiger auf das letzte Element. So kann man die Elemente nacheinander abarbeiten (der FB braucht zum Senden mehrere Zyklen!)

`STRUCT typMsg
   sTopic: STRING;
   sMessage: STRING;
END_STRUCT
STRUCT typBuffer
   iPosition: INT;
   aMsg: ARRAY[1..MAX_MSG] OF typMsg;
END_STRUCT
myBuffer: typBuffer;`
Dann deklarierst du den Puffer als Variable und schreibst deine Nachrichten an die Stelle "iPosition+1" wenn iPosition<MAX_MSG.
Dann muss nur der FbPublisher die Nachrichten wegsenden, wenn xTrigger=FALSE und iPosition>0 ist. Je nachdem wie die Nachrichten rausgehen sollen, musst du das korrekte Element übergeben. myBuffer.aMsg[1] wär ein FIFO und myBuffer.aMsg[iPosition] ein FILO. Beim FIFO müssen alle nachfolgenden Elemente hochkopiert und der Positionszeiger um 1 verringert werden. Beim FILO wird einfach nur iPosition um 1 verringert ohne umzukopieren.


----------



## Jproject (11 Oktober 2021)

Das anlegen der STRUCT typMsg und typBuffer klingt erstmal plausibel.
Jetzt habe ich nicht ganz verstanden, wie du die Daten einschreiben willst.
Ich hatte jetzt folgende Ansatz aber ich bin mir nicht sicher ob ich richtig liege:


```
PROGRAM Test
VAR
        //Publish Test
    oFbPublish: WagoAppCloud.FbPublishMQTT_2 (eConnection:= 1);
    xMyTrigger        : BOOL := FALSE;
    dwBusyCounter    : DWORD := 0;
    dwErrorCounter    : DWORD := 0;
    dwBytesCount     : DWORD;
    xTaster1: BOOL;
    xTest: BOOL;
    sTopictoPublish: STRING(255):= '';
    aBufferData: POINTER TO BYTE;
    sMessage: STRING;
    BufferData: typBuffer;
    ptSource: POINTER TO BYTE; // Quellpointer
    ptDestination: POINTER TO BYTE; // Zielpointer
END_VAR

// Trigger MQTT publish
oFbPublish(sTopic := ,
            eQualityOfService := 1,
            dwSize := dwBytesCount,
            aData := ,
            xTrigger := xMyTrigger);

FOR BufferData.iPosition :=1 TO 100 DO
       
        IF BufferData.iPosition >100 THEN
            BufferData.iPosition:= 1;
           
        ELSIF BufferData.iPosition <100 AND oFbPublish.xTrigger = FALSE THEN

                ptSource:=ADR(sMessage);
                ptDestination:=ADR(aDaten);  

                oFbPublish.xTrigger := TRUE;
        END_IF
       
       
END_FOR
```

Ich weiß halt nur nicht, wie ich mein Topic und meine Message in das Array aMsg schreiben soll und vor allen wie ich die Daten dann abrufe und in den FbPuplish übergebe?


----------



## WAGO Soluteer (11 Oktober 2021)

Ich habe es befürchtet 
Zuerst einmal kannst du den Puffer nicht mit einer FOR-Schleife aufrufen, das ist Unsinn.
Dann musst du dein Sendedaten ja irgendwie in den Puffer reinschreiben. Dazu ist dann "iPosition", welches den "Füllstand" des Puffers anzeigt. Also z.B. Rückmeldung Licht "90%" -> Nachricht in Puffer schreiben. (würde ich über einen separaten FB lösen, der die Nachricht in den Puffer einträgt) Dann füllt sich der Puffer mit Nachrichten und du musst die mit dem FbPublish wegschicken. Das tust du, wenn:
1. xTrigger FALSE ist
2. iPosition>0
Wenn diese Voraussetzungen erfüllt sind, lädst du die gewünschte Nachricht (wir sprachen von "sTopic" und "sMessage" des zu sendenden Elementes, z.B. [1]) auf den FbPublish und setzt den Trigger auf TRUE.
Ist das Senden abgeschlossen (Trigger wird selbstständig zurückgesetzt) solltest du das gesendete Element löschen; in meinem Beispiel dann via FOR-Schleife alle folgenden Elemente hochkopieren und iPosition um 1 verringern. 
Dann beginnt das gleiche Spiel von vorn. Ist eigentlich nicht schwer...


----------



## Blockmove (11 Oktober 2021)

Jetzt misch ich mich auch mal ein:
Bedingung für Publish ist ja im Prinzip ein auslösendes Event.
Je nach Verarbeitung auf dem anderem System (Visualisierung, Leitsystem) kann auf der SPS eine Queue sinnvoll sein.
Sowas macht man normalerweise mit einem FIFO.


----------



## WAGO Soluteer (11 Oktober 2021)

Blockmove schrieb:


> Jetzt misch ich mich auch mal ein:
> Bedingung für Publish ist ja im Prinzip ein auslösendes Event.
> Je nach Verarbeitung auf dem anderem System (Visualisierung, Leitsystem) kann auf der SPS eine Queue sinnvoll sein.
> Sowas macht man normalerweise mit einem FIFO.


Das steht ja schon in den vergangenen Posts und bringt den Kollegen hier nicht weiter.


----------



## Jproject (11 Oktober 2021)

Ich habe jetzt Folgendes getan einen Aktionsbaustein angelegt, um die Werte erst mal in das Array zu bringen:


```
BufferData.aMsg[1].sMessage := TO_STRING (GVL.rWohnzimmer_Licht_Haenge_Value);
    BufferData.aMsg[1].sTopic := '1.Etage/Wohnzimmer/Licht1/state';
   
    BufferData.aMsg[2].sMessage := TO_STRING (GVL.rWohnzimmer_Licht_Spots_Value);
    BufferData.aMsg[2].sTopic := '1.Etage/Wohnzimmer/Licht2/state';
   
    BufferData.aMsg[3].sMessage :=TO_STRING( GVL.rKizi1_Licht_Value);
    BufferData.aMsg[3].sTopic := '1.Etage/Kinderzimmer1/Licht1/state';
   
    BufferData.aMsg[4].sMessage :=TO_STRING( GVL.rKizi2_Licht_Value);
    BufferData.aMsg[4].sTopic := '1.Etage/Kinderzimmer2/Licht1/state';
   
    BufferData.aMsg[5].sMessage :=TO_STRING( GVL.rFlur_Licht_Value);
    BufferData.aMsg[5].sTopic := '1.Etage/Flur/Licht1/state';
   
    BufferData.aMsg[6].sMessage :=TO_STRING( GVL.rKueche_Licht_Value);
    BufferData.aMsg[6].sTopic := '1.Etage/Küche/Licht1/state';
   
    BufferData.aMsg[7].sMessage :=TO_STRING( GVL.rklFlur_Licht_Value);
    BufferData.aMsg[7].sTopic := '1.Etage/kleinerFlur/Licht1/state';
   
    BufferData.aMsg[8].sMessage :=TO_STRING( GVL.rBad_Licht_Value);
    BufferData.aMsg[8].sTopic := '1.Etage/Bad/Licht1/state';
```

Ich hoffe das ist erstmal soweit i.O.


----------



## Jproject (11 Oktober 2021)

Meinst du mit FIFO = First in First out und FILO = First in Last out?


----------



## WAGO Soluteer (11 Oktober 2021)

Jproject schrieb:


> Meinst du mit FIFO = First in First out und FILO = First in Last out?


Jep.


----------



## WAGO Soluteer (11 Oktober 2021)

Wenn ich deinen Code sehe, möchtest du die Werte immer senden. Ich war davon ausgegangenen, dass du die Nachrichten/Werte dynamisch senden willst... Soll die Steuerung ständig senden oder nur bei "Bedarf" (Wertänderung, 1x pro Minute o.Ä.)? Das ändert nämlich deinen Code.


----------



## Jproject (11 Oktober 2021)

Also ich würde die Werte gerne alle 500 ms - 1s die Werte verschicken. 
Natürlich kann man auch nur nach Wertänderungen senden, das würde die Netzwerklast etwas herunter setzten.


----------



## Blockmove (11 Oktober 2021)

Jproject schrieb:


> Also ich würde die Werte gerne alle 500 ms - 1s die Werte verschicken.
> Natürlich kann man auch nur nach Wertänderungen senden, das würde die Netzwerklast etwas herunter setzten.



Netzlast bei einer Smarthomelösung?


----------



## WAGO Soluteer (11 Oktober 2021)

Jproject schrieb:


> Also ich würde die Werte gerne alle 500 ms - 1s die Werte verschicken.
> Natürlich kann man auch nur nach Wertänderungen senden, das würde die Netzwerklast etwas herunter setzten.


Willst du das wegen des Clients (Handy, Tablet, ...) so häufig senden, damit das schnell bei Verbindung die aktuellen Werte bekommt?


----------



## Jproject (11 Oktober 2021)

Ich habe eine Übergeordnete Steuerung(openHAB) und will die Werte so schnell wie möglich aktuell haben.


----------



## WAGO Soluteer (11 Oktober 2021)

Dann würde ich dir pro Nachrichtenquelle einen FbPublisher empfehlen. Ich dachte, es geht um "BYTE-Sparen" und nicht um die größte Performance... 
Noch eine andere Idee: Wenn ich die Beschreibung von openHAB richtig lese, kannst du auch Modbus TCP verwenden. Das wäre für deine Anforderung des schnellen Datentransfers eher geeignet.


----------



## Jproject (11 Oktober 2021)

Modbus als Übertragungsprotokoll hatte ich auch schon im Einsatz. Problem bei obenHAB ist aber die Verarbeitung der Empfangen Modbus-Daten. Diese müssen immer umgewandelt werden beim Empfangen und senden.  Zusätzlich muss man in dann noch viel mehr Variablen anlegen. 

Meine Vorstellung ist, die aktuellen werde in das Array der Struktur abzulegen und diese dann nach und nach über einen FbPublish zu versenden.


----------



## WAGO Soluteer (11 Oktober 2021)

Das kannst du machen; musst aber bedenken, dass bei der Benutzung von einem Baustein die Latenzzeiten größer werden, d.h. je mehr du Nachrichten über einen FB schickst, desto länger dauert es, bis die erste Quelle wieder gesendet wird. Das kannst du nur umgehen, indem du mehr Instanzen des FB definierst. Ich würde jeder Quelle einen FB spendieren. 
Außerdem kannst du noch die Nachrichtengröße unter den Globalen Parametern im Librarymanager anpassen. Ich glaube das Payload ist da standardmäßig (zu) hoch eingestellt.


----------



## Jproject (13 Oktober 2021)

Ich habe jetzt erst mal den einfachen und langen Weg gewählt  und für jedes Topic/Message einen FB angelegt.

Vielen Dank nochmal für die tolle Hilfe und gute Erklärung @WAGO Soluteer


----------

