Danke dir für deine Arbeit, Sokkemeinheld!
Die Veröffentlichungen im ersten Post ersparen mir viel Sucherei.
Was mir noch aufgefallen ist:
Beim Publishen des Wert 0001 macht der Broker daraus ein Integer mit dem Wert 1. Sollte aber ein String in dem Fall sein mit dem Wert 0001
Beim Publishen des Wert 23.65 erkennt er anscheinend den Datentyp nicht und legt nur ein Script an.
Danke fürs Testen! 
Korrekt. Das ist ein Bug und er wird in Version 0.13 behoben sein.
Das konnte ich so nicht nachstellen. Sicher, dass das Retain-Flag gesetzt war?
zu 1: Danke
zu 2: Stimmt, die hatte ich mit Retain = False gesendet. Mit Retain = True gehts. Danke für den Hinweis
PS: Langsam komme ich in Versuchung meinen Raspberry Broker abzuschalten
[ul]
[li]Strengere Prüfung der Datentyp-Kompatiblität: Messages, die nach Darstellung durch den vorhandenen Datentyp anders „aussähen“ führen zu Datentyp-Eskalation, auch wenn der mathematische Wert gleich wäre[/li][li]Datentyp-Eskalation führt zu einer nachvollziehbareren Umbenennung. Umbenannte Variablen tragen den Suffix @bool, @int oder @float. Variablen dieser Benennung werden fortan weiterhin bei empfangenen Publish-Paketen mit Retain-Flag auf einen (datentyp-konvertierten) Wert gesetzt, aber nicht mehr publiziert, weil dies zu unnötigen Mehrfach-Aussendungen führen würde.[/li][li]Das entfernen einer Message mit Retain-Flag führt jetzt bei allen Datentypen einheitlich nicht mehr dazu, dass der Variablenwert geändert wird. Die Variable wird lediglich als versteckt markiert. [/li][li]Dokumentation erweitert in den Punkten „Datentyp-Eskalation“ sowie „Variablenprofile“[/li][/ul]
Bei allen Punkten außer TEMP0 und TEMP1 ist das so aber korrektes Verhalten, da deren Messages ja nur als Strings unverfälscht darstellbar sind.
Bei TEMP0 und TEMP1 sieht es so aus, als ob das Floats sein müssten - es sei denn, da sind z.B. noch whitespaces angehängt die man in dem Screenshot nicht sehen kann.
Ich habe gerade bei mir nochmal versucht, auf ein Topic das noch nicht existiert(!) 24.75 zu publishen und das wird bei mir als Float erkannt. Heißt, ich kann es so bei mir nicht nachstellen.
Falls möglich überprüfe bitte mal ob da evtl. ein Leerzeichen o.ä. mit in der Message steht und was passiert wenn du die Variable löschst und auf das nächste Paket wartest, das sie neu erstellt. Wenn die Variable einmal als String existiert, dann bleibt sie auch einer, eine „Deeskalation“ gibt es nicht
Kann ich so nicht bestätigen. Getestet auf einer weiteren IPSymcon Installation
Das einzige was noch erkannt wird, sind Integer Variablen. Alles andere sind Strings.
Weiterhin zeigt er nicht mehr alle Topics unter Symcon an. Im Meldungsfenster (DEBUG=TRUE) erkennt er zwar den Topic mit Payload. In der Struktur wird er aber nicht mehr angezeigt.
Topic 1 -> funktioniert, wird angezeigt
0010/Produktion/EQ/10002000/Data/00001/LICHTSCHRANKE1
VALUE
TRUE bzw. FALSE
Topic 2 -> funktioniert nicht, wird nicht angezeigt,
0010/Produktion/EQ/10002000/Data/00001/LICHTSCHRANKE2
VALUE
TRUE bzw. FALSE
Beide Meldungen funktionieren aber mit dem MQTTBroker unter Raspberry sowie Bevywise unter Windows
Gibt es bei aktivierten Debugausgaben denn irgendwelche Fehlermeldungen?
Welche IPS-Version hast du laufen?
Habe eine neue Version hochgeladen, deren einziger Unterschied darin besteht dass sie ein paar mehr Debugausgaben macht, wenn $debug = true ist.
Magst du es bitte mal damit testen?
Danke dafür. Sehe ich es also richtig, dass nach dem Headerinfo für LICHTSCHRANKE2 keine Ausgabe „Topic Variable info“ kommt wie zuvor bei LICHTSCHRANKE1?
Merkwürdig. 
So, ich habe mit der 0.15 nochmal eine Version gebaut die mehr Debugausgaben macht, um dem Problem auf die Schliche zu kommen. Es ist etwas mysteriös, aber ich kann es mir aktuell nur so erklären, dass irgendwie der JSON-String mit der Session corrupted wird. Ich bin dir sehr dankbar, wenn du mir weiter hilfst indem du es nochmal testest und mir die Debugausgaben zeigst, denn ich kann bislang alle diese Probleme bei mir nicht nachstellen.
Anbei die Debug Ausgabe mit 0.15
Anscheinend ist keine Session dafür mehr aktiv. Aus der Software heraus (in diesem Fall ein Codesys Programm) werden insgesamt 3 Sessions aufgebaut. 2 davon sehe ich in IP-Symcon. Alle Verbindungen werden über eigene Client ID´s erstellt.
Okay, ich bin wohl auf der richtigen Fährte aber ich muss noch mal weiter gucken. Melde mich. Danke für deine Mithilfe! 
ich glaube ich weiss wann es passiert.
Die Verbindungen werden in 2 Task in der SPS erzeugt (1 Task erzeugt eine Verbindung ein weiterer Task erzeugt zwei Verbindungen). Da diese beim Programmstart (fast) gleichzeitig erzeugt werden, kann deine Software die nicht mehr im Stream unterscheiden und erstellt nur 2 Sessions.
Gehe ich hin und erzeuge diese manuell nacheinander in einem Abstand von ca. 1 Sekunde werden alle Sessions korrekt erstellt.
Hmm… ich hatte mal eine Semaphore drin, aber das herausgenommen. Muss ich wohl mal testweise wieder einbauen und dann weiter schauen. Auf jeden Fall sehr interessant das ganze.
Nee, ich glaube nach einigem Nachdenken doch, dass ich mit der Semaphore auf dem Holzweg bin da RegisterVariable an sich thread safe sein sollte. Nun bin ich am überlegen, ob meine Angewohnheit, Sessions als Variablen zu speichern ein Problem darstellt. Vielleicht kennt sich jemand ja genauer damit aus.
Mir ist bekannt, dass man keine Daten in Variablen puffern soll. Allerdings tue ich das auch nicht, sondern ich speichere da „nur“ die Parameter einer Session, als JSON-String. Die Daten selbst werden ganz korrekt im Puffer der RegVar abgelegt.
Es bedeutet allerdings trotzdem, dass pro komplett empfangenem und interpretiertem MQTT-Datenpaket ich die Session-Variable einmal beschreibe, allein der Timeout-Behandlung wegen. Wenn das ein Problem darstellt, dann habe ich dieses Problem noch nicht verstanden und würde es aber gerne.
Letztlich scheint es durch irgendeinen Zusammenhang (Timing, „race condition“) so zu sein, dass zu einem Zeitpunkt, da eine Session-Variable da und auffindbar sein sollte, dies nicht der Fall ist. Mir bleibt wohl nicht viel anderes übrig, als da noch mehr Debugausgaben einzubauen, und dich einfach zu bitten es noch ein paar mal zu versuchen. :-/
mqttbroker.php.v0.16.zip (22.1 KB)
So, hier nochmal eine Version die sehr verbose ist. Ich hoffe, damit komme ich dem Problem dann auf die Schliche.
Falls irgendjemand das beschriebene Problem noch bei sich nachstellen kann und Zeit hätte, die Debugausgaben zu posten, würde mir das sehr helfen. Aktuell steht dieses Problem auf jeden Fall einem Versionssprung auf die 1.* im Wege :-/