Hallo zusammen,
ich habe in Symcon den MQTT Server installiert und konfiguriert, als Client hab ich den jomjol AI-on-the-edge am Wasserzähler.
Grundsätzlich funktioniert auch alles Daten kommen, variablen werden angelegt, Werte passen.
Das Problem ist aber dass die IDs der Variablen sich ständig ändern (Logik dahinter sehe ich nicht). Damit wird das archivieren genau so unmöglich wie das verwenden in skripten.
Kann mir jemand sagen wo der fehler ist?
Viele Dank vorab!
Kann es sein, dass sich der Typ der Variablen ändert? Das könnte erklären warum eine Variable gelöscht und neu angelegt wird.
Soweit ich sehen sind sie immer vom gleichen Typ. Zumindest die für mich relevanten bleiben gleich.
Merkwürdig.
Von selbst können sich die ID doch nicht ändern. Ich glaub du verwechselst da was.
Sie ändern sich nur wenn DU den Variablentyp änderst ansonsten nicht. Oder wenn du die ganze Instanz weglöscht oder das Topic änderst. evtl. hast du auch nur den Namen das Zählers geändert.
Dann erkennt IPS dies als neues Gerät und legt natürlich auch neue Variablen an.
schöne Grüße
Bernhard
Ich verwechseln da nichts, die IDs ändern sich. Aber ich ändere defenitiv nichts. Ich stelle nur von Zeit zu Zeit fest das die IDs die ich geloggt hab oder für Skripte genutzt wurden weg sind, obwohl an der gleichen stelle die gleiche variable nur mit einer anderen ID ist.
Ich verstehe nur nicht wann und warum IPS sie neu anlegt.
Auch am Zähler wurde nichts verändert
Dann hat sich eventuell der Variablentyp nur kurzfristig mal geändert.
Du könntest das Debug der Mqtt Instanz mal aktivieren.
Der Variablentyp änder sich aber nicht „von selbst“.
Das mußt du doch als User aktiv einstellen.
bb
bleibt die Instanz denn die gleiche? also von der ID her?
So, hab mal ein Bild gemacht, wie man sieht ändern sich nicht alle Instanzen gleich oft.
Zuletzt hat sich die json mal wieder geändert und damit meinen Frust und den Post ausgelöst.
Ich kann allerdings nicht verstehen warum es passiert und was genau es auslöst.
Die Änderung war punkt 11:30:00, das sieht nach einem automatismus aus, an dem Tag zu der Urzeit hab ich definitiv nichts am Client verändert.
Ich hab mal das debug laufen lassen und so ziemlich alles geändert was geht am Client (inkl. ein Firmwareupdate) ergebnis = NIX, alles ist gleich geblieben 
evtl. kommen ja die Daten in der Json irgendwie verstümmelt an. IPS denkt dann das es eine neue Variable ist und der Ärger geht los. Das wäre eine Erklärung.
Sehe in meinem MQTT Konfogurator oft irgendwelche Müll-Einträge.
Warum nimmst du die Daten überhaupt aus der json ?
Ich habe die json Instanz gar nicht angelegt und arbeite nur mit „value“.
Variblentyp und Profil muß man händisch setzten. Aber dann „steht das“.
schöne grüße
Bernhard
Leg dir doch testweise mal eine MQTT Instanz an, welche den JSON-String enthält und log die ins Archiv. Das kostet zwar viel Speicherplatz aber um das Problem zu finden wäre es dies Wert. Und wenn das Problem da ist, kannst du dir alle Werte nach und nach durchschauen und siehst bestimmt was da falsches gesendet wird.
paresy
Danke für eure Tipps.
Da mich meine aktuelle IPS Hardware (Raspi) eh nervt (mir fehlt einfach die Zeit und Muse mich um die Updates zu kümmern damit 6.2 läuft), hab ich mir jetzt erst mal für ~350€ + extras so einen „grünen“ Raspi bestellt.
Hab gehört da läuft IPS noch viel schneller und besser 
(hat nur leider so wenig Schnittstellen)
Ist sogar schon verschickt und wenn der dann am WE eingebaut ist migriere ich erst mal alles dahin.
Den MQTT werde ich dann nochmal komplett neu einrichten, vielleicht löst das schon das Problem.
Ich werde auf jedenfall weiter berichten.
Viele Grüße
Rolf
Hallo,
ich vermute, dass bei den Zahlenwerten die Nachkommastellen dein Problem sind.
wenn man z.B. mal
{"Wert1":58.1}
und dann
{"Wert1":58}
als JSON String an den MQTT Server schickt, dann kann der Typ der Symcon-variable von float auf int wechseln und das nächste mal mit Nachkommastellen wieder auf float.
daher bei float-Werten immer die Nachkommastellen mitschicken, auch wenn diese 0 sind!
{"Wert1":58.0}
Man muss beim Absender der Werte wirklich höllisch aufpassen, so dass diese immer richtig formatiert sind. 1 falscher Wert und das Archiv ist weg.
Wichtig ist auch ob man die Hochkommas mitschickt (–> string wert) oder nicht → Zahlenwert!
ebenso das Dezimaltrennzeichen . (Punkt) und nicht , (Komma)
lg
Wolfgang
ich hab mir jetzt BBQKees EMS-ESP Gateway zugelegt, das kommuniziert auch via MQTT und dort hab ich genau das Problem wieder.
Ich kann es aber nicht beeinflussen was geschickt wird (hab auch schon auf github mal nachgefragt beim EMS projekt).
@paresy
Gibt es im Symcon keine einfache Möglichkeit das zu verhindern? Ich kann doch nicht ständig alles neu anlegen, archiv aufräumen usw. nur weil symcon meint hier den Typ ändern zu müssen. 
In dem Fall wurde die Variable auch initial als INT angelegt obwohl es ein Float wäre, jetzt kann ich natürlich nicht so leicht sehen wo bei 148 Variablen der Fehler noch vorliegt 
Servus
Wenn es deine IPS Lizenz hinsichlich möglicher Variablen erlaubt, dann könntest du doch einfach einen Clone des Baumes machen wo alle MQTT Variablen liegen. Diese sind dann deine „Arbeistvariablen“ werden archiviert , weiterverarbeitet usw. Per Script kopierst dann den bei jeder Änderung der MQTT Variablen deren neuen Wert in die Arbeistsvariablen um. Das Script behandelt allfällige änderungen des Variablentypes.
Das einmalige Anlegen der Kopie sollte sich mit einem rekursiven Script recht einfach erledigen lassen.
Nicht schön, aber immerhin ein Workaround.
bb
Das fangen wir ab. Wenn wenn es einmal ein Float ist, bleibt es ein Float, auch wenn Integer Werte kommen.
@rolf1: Das Problem muss woanders sein. D.h. dein Gerät muss z.B. einen Boolean oder String Wert senden (und keinen Zahlenwert). Dann löschen wir die Variable. Meiner Meinung nach verhält sich das Gerät dann aber falsch. Du kannst dir den Wert selber in eine String Variable per MQTT holen und die Auswertung in einem PHP Skript machen. Dort hast du dann die volle Kontrolle und kannst das komische Verhalten von deinem Gerät geradebiegen 
paresy
Hi,
also inzwischen bin ich schlauer, das Hauptproblem ist Integer zu Float. Das scheint aber wohl bei ESP, Arduino, JSON ein verbreitetes Problem zu sein Github Issue zum Thema.
Das kann ich auch bestätigen, einige Werte kamen beim ersten mal ohne .0 und wurden daher von IPS als Integer angelegt, später kam dann ein Zahl mit Kommawert und IPS hat die alte Variable gelöscht und mit neuer ID als Float angelegt (damit geht dann das suchen im Archiv und in dem skripten los). Bei einigen warte ich noch drauf das der Floatwert kommt, wenn man es nicht kommen sieht ist hier der Ärger vorprogrammiert.
Der umgekehrte Fall Float zu Integer wird wie von dir beschrieben abgefangen.
Die anderen Fälle waren String zu Integer, das hab ich durch einen Konfigfehler selbst ausgelöst, trotzdem ist es suboptimal wenn variablen einfach verschwinden, sowohl fürs wiederfinden im Archiv als auch zur Fehlersuche allgemein. Könnteman das nicht irgendwie über eine Option in der Instanz abschaltbar machen? soll er halt ne neue anlegen aber Finger weg von der alten 
Grüße
Ich ruf mal das Thema „zWave Geitervariablen“ ins Gedächtnis. Da haben wir ja ein ähnliches Thema und Vorschlag zum Workaround. Allerdings mit anderem technischem Hintergrund.
gruß
bb
