Datenpunkt in der Objekt-Ansicht ändern
-
Nur mal als Nachfrage:
du manipulierst einen Adapterdatenpunkt innerhalb des Namespaces eines Adapters? -
@homoran Das machen MQTT-Clients/Geräte ALLTÄGLICH, das ist ihr Lebenszweck...
Der MQTT-Explorer simuliert bei meinem Test, den Fehler zu reproduzieren einen Client, ein Gerät.
Geräte, die das erste Mal an einem Adapter auftauchen, subscriben NATÜRLICH Datenpunkte, auf denen sie z. B. Sollwerte oder ähnliches erwarten.
Es ist die Frage, was ein MQTT-Gerät machen soll, wenn es nach dem subscriben feststellt, dass der subscribte Wert leer ist: Selber korrigieren, oder muss man das per Blockly/Javascript von iobroker aus korrigieren?
Soweit ich das getestet habe, legen andere MQTT-Broker subscribte Datenpunkte, die es nicht gibt gar nicht an. Getestet habe ich das mit Mosquitto...
Da erscheint ein nicht subscribter Datenpunkt nicht im Tree des Mqtt-Explorer nach Aufbau der Verbindung.Das Verhalten des mqtt-Adapters ist da wohl etwas anders, finde das aber durchaus bequem..
-
@martinp Du hast meine Frage nicht beantwortet!
-
@martinp sagte in Datenpunkt in der Objekt-Ansicht ändern:
Hier:
schreibst du (was aus meiner Sicht korrekt ist):
"Es scheint so zu sein, dass das Subscribe auf den Datenpunkt im Mqtt Broker nicht dazu führt, dass der Datenpunkt automatisch angelegt wird..."
Nun behauptest du (was ich bezweifele)
Ein MQTT-Device hat durch Subscriben eines Topics das Anlegen eines Datenpunktes durch den Adapter verursacht. ./<Devicename>/Soll/Temperatur
Was stimmt denn nun?
EDIT: oder, um genauer zu sein, wie ist der Adapter in diesem Punkt konfiguriert?
-
@marc-berg Ist ja leicht reproduziert ...
Die JETZIGE Version des MQTT-Adapters legt den Datenpunkt jedenfalls nach meinen Tests halbgar an ... im Mosquitto führt bei einem Gegentest das Subscriben nicht zu einer entsprechenden Erweiterung des Trees um den Subscribten Punkt
-
Ich habe den Datenpunkt nur indirekt ANGELEGT, (über den Weg MQTT-Explorer-> mqtt-Adapter als Broker -> iobroker Datenpunkt)
Die KORREKTUR des TYPS habe ich als Admin von Hand vorgenommen
-
@martinp sagte in Datenpunkt in der Objekt-Ansicht ändern:
Die KORREKTUR des TYPS habe ich als Admin von Hand vorgenommen
und damit hast du in einem Adapternamespace ein Objekt manipuliert.
Das ist für die Ursachenforschung entscheidend!
@martinp sagte in Datenpunkt in der Objekt-Ansicht ändern:
Das machen MQTT-Clients/Geräte ALLTÄGLICH, das ist ihr Lebenszweck...
das stimmt so auch nicht wirklich!
Das mach der Adapter in seinem Namespace.
Und nur der darf das da.Und ich bin jetzt auch wieder weg
-
@homoran Auf der anderen Seite wurde mir aber auch gesagt, dass das MQTT-Device auf "subscribed" Nodes nicht publishen darf, weil das eine Endlosschleife auslösen könne ...
Wahrscheinlich ist es sinnhafter, den Typ so zu lassen, wie er ist... Da wäre dann alles, was im Mqtt-Adapterbaum an Elementen liegt ein String, weil es so erzeugt wird.
Ist natürlich nicht besonders schön, einen Datenpunkt, der z. B. eine Temperatur enthält bei String als Datentyp zu belassen ...Erklärt vielleicht auch, warum viele MQTT-Devices mit JSON hantieren, statt mit einfachen Datentypen ...
-
Habe jetzt eine vereinfachte und legitimere Form des Tests gemacht .. crasht auch
- Userdata Datenpunkt anlegen
- Name z. B. 0_userdata.0.LeererDP
- Typ String,
- Wert leer lassen
- (versucht man nun direkt (im "Expertenmodus") den Typ auf Zahl zu ändern klappt das.)
- Javascript Schnipsel programmiert, um den Fehler zu forcieren ...
setState("0_userdata.0.LeererDP", null, true);-
Script kurz ausgeführt ...
-
Versucht man nun in der Objekt Ansicht den Datentyp auf Zahl zu ändern, kracht das auch..
-
Hier noch der Link zum Issue
