NEWS
Fragen / Antworten rund um die neue Alias Funktion
-
@zwer2k said in Fragen / Antworten rund um die neue Alias Funktion:
ist es möglich für alias read/write eine zuvor angelegte Funktion zu verwenden?
Nein, ist nicht möglich.
@iobaer said in Fragen / Antworten rund um die neue Alias Funktion:
Auch wenn es nicht nur direkt mit dem Alias zu tun hat: wie kann ich einen eigenen Datenpunkt anlegen, der nur zur späteren Verwendung da ist und nicht auf rot, sondern grün (Ack) stehen bleiben soll?
Beim setzten des Status ack=true setzen. In Admin kannst du dafür auf den Stift drücken, der beim Mausover ober das Statusfeld kommt, da kommt ein Fenster wo du "bestätigt" oder so anhaken kannst, bei setState in Javascript musst du noch ein "true" hinten dran hängen. In Blockly geht das bestimmt auch irgendwie.
-
@iobaer also ja diese Frage hat mir alias nicht dazu tun. Vllt in nem eigene thread auf machen?
Kurz: rot oder grün (also ack false bzw true) hängt davon ab wie du den Wert reinschreibst.
-
@apollon77 sagte in Fragen / Antworten rund um die neue Alias Funktion:
@zwer2k was hat denn der JavaScript Adapter damit zu tun? Alias ist ein Core Feature. Den js Adapter muss man nicht installiert haben ...
JS-Adapter haben vermutlich auch 99,9% der Nutzer installiert. Und die Nutzer die den Adapter nicht installiert haben, haben auch keine Funktion definiert die sie für Alias verwenden könnten.
War aber nur eine Frage ob es überhaupt geht. -
Ich habe gerade ein Problem.
Beim speichern von einem Alias bekomme ich den Fehler:
Fehler beim Parsen des JSON-Quelltexts
error_outlineSyntaxError: Unexpected end of JSON input{ "from": "system.adapter.admin.0", "user": "system.user.admin", "ts": 1625824504674, "common": { "name": "l1hak", "role": "", "type": "number", "desc": "Manuell erzeugt", "unit": "%", "min": 0, "max": 100, "def": 0, "read": true, "write": true, "id": "javascript.0.ShellyVerbrauch.SHEM-3#8CAAB561D496#1.Emeter0.heute" }, "native": {}, "acl": { "object": 1638, "owner": "system.user.admin", "ownerGroup": "system.group.administrator", "state": 1638 }, "_id": "alias.0.l1hak", "type": "state" }
-
@cino Wo ist da ein Alias drin?
-
@cino sagte in: Beim speichern von einem Alias bekomme ich den Fehler:
Das ist kein Alias. Verwende besser den Alias-Manager anstelle den Alias im Tab "Objekte" zu erstellen. Dann passieren weniger Fehler (alias, role, unit, max, write).
Beispiel für einen "Verbrauchs-Alias":{ "type": "state", "common": { "name": "Zählerstand", "role": "value", "type": "number", "read": true, "write": false, "alias": { "id": "s7.0.xyz.Zähler", "read": "val/1000" }, "unit": "kWh" }, "_id": "alias.0.Logo.Zaehler.Stand", "native": {}, "from": "system.adapter.admin.0", "user": "system.user.admin", "ts": 1624382656991, "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }
-
@apollon77 unter alias.0
-
-
Danke, mit dem Alias Manager hat es geklappt. Ich wusste nicht das es ihn gab.
-
@cino sagte: "id": "javascript.0.ShellyVerbrauch.SHEM-3#8CAAB561D496#1.Emeter0.heute"
Für eigene Datenpunkte verwendet man keinen Alias. Denen verpasst man eine sinnvolle ID ohne "SHEM-3#8CAAB561D496#1".
-
@paul53 das kommt von einem skript der die Vebräuche der Shellys summiert.
-
Es spricht grundsätzlich nichts dagegen Aliase für javascript / eigene Datenpunkte zu machen. Bei Javascript finde ich das sogar ok, weil sich die ID auch ändern kann, wenn man die javascript Instanz mal wechselt oder so (weshalb ich persönlich mittlerweile nur noch ungern mit createState arbeite in Skripten, wenn der State für "außen" irgendwie wichtig sein könnte oder dann auch einen Alias drauf setze und den verwende).
-
@garfonso sagte: Es spricht grundsätzlich nichts dagegen Aliase für javascript / eigene Datenpunkte zu machen
Doch: Unnötiger Ressourcenverbrauch.
@garfonso sagte in Fragen / Antworten rund um die neue Alias Funktion:
weil sich die ID auch ändern kann, wenn man die javascript Instanz mal wechselt
Wegen dieser Problematik wurde das Verzeichnis "0_userdata.0" geschaffen, in dem man auch Datenpunkte mittels createState() erstellen kann.
-
soweit ich mich erinnere, brauchst du die datenpunkte für die vis (binding)- ich kann mir nicht vorstellen, dass ein paar aliase unter javascript ein resourcen-problem erzeugt. als notfall lösung würd ich das machen - als standard lösung für viele dp unter javascript würde ich das auch nicht machen - da stimme ich paul zu
eine andere lösung wäre natürlich, das script anzugleichen - z.b. beim anlegen der datenpunkte . kannst du nicht mal beim ersteller des scriptes nachfragen, ob er das ändern möchte
ansonsten müßtest du ein eigenes script machen, welche die dp spiegeln - aber anstatt ein script finde ich das alias besser
-
@paul53 said in Fragen / Antworten rund um die neue Alias Funktion:
Doch: Unnötiger Ressourcenverbrauch.
Ok, die zusätzlichen "Ressourcen" sind exakt der Speicherplatz für ein Objekt mehr in der Objektdatenbank. Nichtmal der State wird gespiegelt. Das nehme ich in Kauf.
-
@garfonso sagte: die zusätzlichen "Ressourcen" sind exakt der Speicherplatz für ein Objekt mehr in der Objektdatenbank.
Da der Alias den Zustand des Original-Datenpunktes spiegelt, gehören auch noch zwei Trigger dazu.
-
Hallo Zusammen,
ich hoffe ich habe hier den "richtigen" Ort für meine Frage gefunden.
Ich habe ein paar Geräte mit ~500 ALIAS angelegt. Egal ob die ursprünglichen DPs von userdata oder Adapter kommen, mit dem Vorteil dort Geräte mit Ihrer Definition an einer Stelle definiert zu haben (Abstraktion). Dort greife ich mit meinen Skripten, als auch Visualisierung (JARVIS) zentral zu.
Nun zu meiner Frage... wenn ich mit JARVIS Geräte anlege, welche wiederum auf diese ALIAS zugreifen habe ich festgestellt, dass der Zugriff auf ALIAS merkbar langsamer ist (Daten werden sicherbar langsamer geladen, tlw. ~3 Sekunden langsamer), als wenn ich den originalen DP eintrage (userdata oder Adapter).
Ist das ein grundsätzliches Problem von ALIAS oder eher von JARVIS. Ich habe mir ALIAS als Pointer vorgestellt ohne wesentliche Performance-Einbuße. Oder irre ich hier und man sollte es "irgendwie" anders machen.Vielen Dank im Voraus!!!!
-
@rkccorian sagen wir es mal so … wir haben bis vor kurzem die alias Performance nie gemessen. Das hatten wir aus anderen Gründen letztens gemacht und ja aliases sind ca 1/3 langsamer als der direkte Zugriff. Wir müssen jetzt schauen warum und vllt können wir mit dem Controller 4.0 hier was optimieren.
Daher: ja bei so vielen aliases kann das durchaus aktuell Effekte haben. Wir sind aber „aware“ und dran.
Ingo
-
@apollon77 Vielen Dank für Deine Antwort! Dann lasse ich mal alles wie es ist und hoffe auf eine Optimierung.
Ich merke beim direkten Schreiben und Lesen weniger Einbuße, aber wenn ich meine VIS neu lade und der Browser damit alle meine DPs lädt. Dort ist es deutlich sichtbar. -
@rkccorian Legst Du mir bitte ein Github issue im js-controler repo an deswegen ? Dann haben wir es getrackt