NEWS

@altmann Super. Freut mich wenn ich helfen konnte...

@oliverio @Homoran danke danke danke
Hab's jetzt folgender Maßen gelöst. Muss morgen Mal gucken ob die Umrechnung in Tage passt aber die 2 Minuten funktionieren sehr gut soweit.

{lastchange:0_userdata.0.Papa.Platz1.lc;wert:0_userdata.0.Papa.Platz1;((new Date()-lastchange)/1000/60) > 2 ? "#d6061f" : wert == "" ? "#FFFFF" : "#00000"}

@markusn78 wir kennen halt räume abe rnicht so wie du die brauchst..da musst du selber Hand anlegen und manuell splitten

@paul53
Danke für den Hinweis,
ich habe mir jetzt einen passenden Flow bei Node-Red angelegt. Habe den aber nicht selber erfunden sondern nur auf meine Bedürfnisse angepasst.

[ { "id": "7b93b0c.402c65", "type": "tab", "label": "Flow 2", "disabled": false, "info": "" }, { "id": "df41c583.24ff58", "type": "function", "z": "7b93b0c.402c65", "name": "word to binary", "func": "// initialize bit array to 0s\nvar bits0thru31 = [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];\n\nfor (i = 0; i < 32; i++){\n bits0thru31[i] = (msg.payload >> i) & 0x1;\n}\n\nvar bit0 = {payload: bits0thru31[0]};\nvar bit1 = {payload: bits0thru31[1]};\nvar bit2 = {payload: bits0thru31[2]};\nvar bit3 = {payload: bits0thru31[3]};\nvar bit4 = {payload: bits0thru31[4]};\nvar bit5 = {payload: bits0thru31[5]};\nvar bit6 = {payload: bits0thru31[6]};\nvar bit7 = {payload: bits0thru31[7]};\nvar bit8 = {payload: bits0thru31[8]};\nvar bit9 = {payload: bits0thru31[9]};\nvar bit10 = {payload: bits0thru31[10]};\nvar bit11 = {payload: bits0thru31[11]};\nvar bit12 = {payload: bits0thru31[12]};\nvar bit13 = {payload: bits0thru31[13]};\nvar bit14 = {payload: bits0thru31[14]};\nvar bit15 = {payload: bits0thru31[15]};\n\nreturn[ bit0, bit1, bit2, bit3, bit4, bit5, bit6, bit7, bit8, bit9, bit10, bit11, bit12, bit13, bit14, bit15 ];\n", "outputs": 16, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 640, "y": 400, "wires": [ [ "aa201119.796068" ], [ "8756f456.0d6bf" ], [ "6d516811.372178" ], [ "948f3ad4.183b88" ], [ "8f435811.a4be68" ], [ "cdb17f80.fac8e8" ], [ "75ff10d8.fba63" ], [ "e5d55421.de459" ], [ "86b811c3.0ac84" ], [ "e45a7d02.79caa" ], [ "b2aefbfc.aa2338" ], [ "2617a6bb.218c8a" ], [ "97ee1c07.1628" ], [ "79b46191.21538" ], [ "7e37e721.5da318" ], [ "3b04cc79.d38d54" ] ] }, { "id": "aa201119.796068", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "payload", "x": 850, "y": 260, "wires": [] }, { "id": "8756f456.0d6bf", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "false", "x": 850, "y": 300, "wires": [] }, { "id": "6d516811.372178", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "false", "x": 850, "y": 340, "wires": [] }, { "id": "948f3ad4.183b88", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "payload", "x": 850, "y": 380, "wires": [] }, { "id": "8f435811.a4be68", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "payload", "x": 850, "y": 420, "wires": [] }, { "id": "cdb17f80.fac8e8", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "payload", "x": 850, "y": 460, "wires": [] }, { "id": "75ff10d8.fba63", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "payload", "x": 850, "y": 500, "wires": [] }, { "id": "e5d55421.de459", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "payload", "targetType": "msg", "statusVal": "", "statusType": "auto", "x": 850, "y": 540, "wires": [] }, { "id": "e3ba4514.dd9e88", "type": "ioBroker in", "z": "7b93b0c.402c65", "name": "", "topic": "modbus.0.holdingRegisters.1.12326_MW38_OG_Stat_Kind2", "payloadType": "value", "onlyack": "", "func": "all", "gap": "", "fireOnStart": "true", "x": 280, "y": 400, "wires": [ [ "df41c583.24ff58" ] ] }, { "id": "86b811c3.0ac84", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "payload", "targetType": "msg", "statusVal": "", "statusType": "auto", "x": 850, "y": 580, "wires": [] }, { "id": "e45a7d02.79caa", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "payload", "x": 850, "y": 620, "wires": [] }, { "id": "b2aefbfc.aa2338", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "payload", "x": 850, "y": 660, "wires": [] }, { "id": "2617a6bb.218c8a", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "payload", "x": 850, "y": 700, "wires": [] }, { "id": "97ee1c07.1628", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "payload", "x": 850, "y": 740, "wires": [] }, { "id": "79b46191.21538", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "payload", "x": 850, "y": 780, "wires": [] }, { "id": "7e37e721.5da318", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "payload", "x": 850, "y": 820, "wires": [] }, { "id": "3b04cc79.d38d54", "type": "debug", "z": "7b93b0c.402c65", "name": "", "active": true, "console": "false", "complete": "payload", "x": 850, "y": 860, "wires": [] } ]

Screenshot 2022-01-11 090115.png

Im Modbus-Adapter habe ich dann Unsigned 16bit (Little Endian) verwendet. In der Wago SPS schreibe ich auf ein %MW.

Falls mal jemand diese Informationen brauchen sollte.

@paul53 Danke! habe damit erst verstanden das ich es in einen anderen Ordner legen muss. Vorher hatte ich versucht das beide scrips über den Editor auf der Webplatform an zu legen. Also mit JavaScript funktioniert es jetzt. Eigendlich wollte ich aber in TypeScript programmieren und da habe ich dann noch ein bisschen länger dran gehangen. Habe es schließlich aber auch geschafft.

Für alle mit ähnlichem Problem:
Ich mich an dem vorletzten post in diesem Thread hier orientiert: Modulare Skripe
Anstatt dann in dem neuen node module in JavaScript zu programmieren habe ich dort TypeScript über npm als dev-dependency installiert. Jetzt kann ich dort mit TypeScript programmieren, und das Ergebnis per Import in ioBroker scripteditor benutzen. Nachteil ist das ich das externe TypeScript extra nochmal compilieren und dann Adapter neu starten muss. Allerdings kann ich so auf meinem Desktop in WebStorm entwickeln und dann am ende nur die compilierten .js Dateien synchronisieren. Bin also ganz zufrieden mit der Lösung.

Danke nochmal @paul53 und @Ahnungsbefreit für eure Hilfe!

gelöscht

@richibln sagte in Homematic Systemvariable ändern mit Iobroker:

ich weiß nicht woran das liegt das ich den EM1000 den ich im cuxd erstellt habe nicht verändern kann.

ich auch nicht, solange du mir nicht die Rohdaten des Datenpunkts zeigst

@richibln sagte in Homematic Systemvariable ändern mit Iobroker:

ich hab schon versucht alle punkte zu Steuern aber ohne Erfolg die werte werden nicht übernommen.

Glaskugelmodus:
Wahrscheinlich sind das Werte, die vom Gerät geliefert werden und nicht beschreibbar sind.
Wieso sollten sie auch überschrieben werden können. Das Gerät würde sie nach der nächsten Aktualisieruung ja wieder mit seinen Werten überschreiben.

@richibln sagte in Homematic Systemvariable ändern mit Iobroker:

muss ich halt ein Script schreiben welches mir den Verbrauch Woche , Monat und Gesamt errechnet.

nicht unbedingt.
Dafür gibt es den sourceAnalytics Adapter

@sborg sagte in In entfernten Datenpunkt schreiben:

@michihorn Na damit kann man arbeiten 🙂

Das ist die Antwort der Web-Site:

No connection to home Requested instance (web, admin, ...) is not started, has SSL or authentication enabled

...und dann schau dir nochmals obigen Link an was da etwas weiter unten zu erkennen ist: "No connection..." 😉

Vielen Dank...hab das "@" in der Cloud Pro Bezeichnung vergessen **@**pro_giethoorn20@gmail.com
Mein Testscript sieht jetzt so aus und tut was es soll:

var request = require('request'); const idWind = "hm-rpc.2.00185BE98B3FCA.1.WIND_SPEED" on({ id: idWind, change: "ne" }, function () { var url="https://iobroker.pro/service/simpleApi/@pro_giethoorn20@gmail.com_xxxxxx-6x11-xxxx-bxxc-d9eaa1exxxxx/set/javascript.0.Castrop.Test?value="+getState(idWind).val; request({url : url}, function (error, response, body) { log("Änderung übertragen"); }); });

@paul53
oh man so einfach 🙂

Vielen Dank

@slipkorn_dh88

Schön das du es hin bekommen hast 👍

@fastfoot danke, das funktioniert super

@init5 said in Datetime für VIS auswerten:

@paul53 Sorry für die späte Antwort. Ich habe immer ein Problem mit diesen Skripten. Ich weiß nicht wie ioBroker damit umgeht, aber für meine Verständnis laufen dann die Skripte über die gesamte Dauer.

Normale Skripte laufen nur 1 Mal...nämlich beim Starten des Brokers. z.B. zum Initialisieren von irgendwelchen Werten o.ä.
Wenn Du jedoch einen "Trigger" einbaust, dann meldet sich Dein Skript am System bei einem Eventhandler an und sagt diesem: "Starte meine angegebene Callback-Funktion und übergieb dieser bestimmte Daten , wenn ein bestimmtes Ereignis eingetreten ist. (z.B. eine Wertänderung bei einem Knoten oder Ablauf eines Timers). Das eigentliche Skript läuft also nicht weiter sondern wartet im Hintergrund darauf, dass es vom Eventhandler erneut aufgerufen wird (nicht das komplette Skript sondern nur die jeweis übergebene Callback-Funktion).

Nur als kleines Beispiel:

on({id: "mqtt.0.esp32.temperature", change: "ne"}, async function (obj) { var value = obj.state.val; // hier können weitere Anweisungen innerhalb der Callback-Funktion stehen } );

bedeutet
on {(Ereignis}, rufe meine asynchrone Funktion "function(obj)" auf und übergieb ihr als Parameter das Objekt, in dem das Ereignis stattfand.})
Auf dieses Objekt kann man dann innerhalb der Funktion problemlos zugreifen
var value = obj.state.value;

Jetzt zu Deinem eigentlichen Problem mit der Überprüfung des Temperatursensors:
Wie oben gerade gesagt, reagieren die Trigger nur bei "Veränderungen" (welcher Art auch immer) und rufen entsprechende Routinen (callback-Funktionen) auf. Aber genau das hast Du ja eben nicht! Es verändert sich ja nichts...
Du bräuchtest also quasi so eine Art "timeout" Funktion, die aufgerufen wird, wenn sich ein Meßwert z.B. über 8 Std nicht verändert (bzw aktualisiert) hat.

Ich selber beschäftige mich jetzt erst ein paar Wochen mit dem Broker und weiß nicht, ob das Developer Team sowas evtl bereits umgesetzt (programmiert) hat

Daher würde ich für so eine Überwachung auf einen Timer zurückgreifen, der alle paar Minuten überprüft, ob meine Meßdaten aktualisiert wurden oder ob z.B. ein Meßfühler ausgefallen ist.

Je nach Wichtigkeit könnte dann sogar eine Alarmmeldung rausgeschickt werden (z.B. e-mail oder Telegram o.a.)
Damit das aber auch im VIS angezeigt wird, würde ich mir einen User-definierten Alarm-Knoten einrichten, der nur true oder false enthält.

Bsp:

Neues Objekt hinzufügen: 0_userdata.0.Temperaturalarm
parent: 0_userdata.0
Typ: Datenpunkt
Zustandstyp: boolean
Name: Temperaturalarm

Wenn man diesen neuen Knoten anlegt, bekommt er vom System sofort den default-Wert: false...

In diesem Knoten wird dann vom Timer regelmäßig abgelegt, ob der Messfühler noch aktiv ist (Alarm=false) ...wenn nicht, wird der Wert "true" gesetzt, was einem Alarm gleichkommt.

Der Timer:
interval = setInterval(async function () {}, 60000); //alle 60000 ms = 1 Min starten

Jetzt nur noch die Funktion "füllen":
Das Script sieht dann später so aus:

var interval; // Describe this function... async function getTimeDiffMin() { var aktDateTime= new Date(); return (aktDateTime.getTime() - getState("mqtt.0.esp32.temperature").ts)/1000/60; } interval = setInterval(async function () { if (await getTimeDiffMin() >= 1) { setState("0_userdata.0.Temperaturalarm"/*Temperaturalarm*/, true, true); } else { setState("0_userdata.0.Temperaturalarm"/*Temperaturalarm*/, false, true); } }, 60000);

oder das Blockly:

Unbenannt-2.jpg

Somit kann man im Blocly einstellen, in welchem Intervall geprüft wird und wie groß die 'Zeitspanne maximal sein darf... (jeweils in Minuten)

@joergh sagte in Wie Scripts mit hoher CPU-Last finden?:

Schneller geht 50% abschalten,

@oxident
Is ja eh auf 2 Instanzen aufgeteilt, also eine einfach mal abschalten, wäre am schnellsten

@mrpit
Per skript? Nein, geht nicht, das läuft alles in einem gemeinsamen Prozess ab.

@bostil sagte in Zahl in Datenpunkt springt zwischen + und -:

Weitere Pausen einarbeiten bewirkt auch nichts, oder?

Weitere Pausen

machen das Skript langsamer lassen zu das du um die Problematik herum unsauber arbeitest anstatt gleich sauber zu arbeiten sorgen dafür das das Problem "nur manchmal" auftritt machen das Skript schwer zu debuggen.

Neben dem normalen "Async" Problem hast du:

die Berechnung von Nebenkosten_Gesamtsumme_FC und Nebenkosten_Gesamtsumme_YTD jeweils um 1 Sekunde verzögert die Berechnung von Nebenkosten_Gesamtsumme_YTD_proMonat, welche auf die oben berechnete Nebenkosten YTD zugreift nicht verzögert die Berechnung von Nebenkosten_Gesamtsumme_FC_proMonat nach dem gleichen Muster nicht verzögert.

Dadurch finden die Berechnungen der Summen pro Monat statt bevor die Aufsummierung der Kosten stattfindet.

Aber das ist nur die Spitze des Eisberges:

Du definierst Konstanten im Skript (echte konstanten) und aktualisierst diese jede Minute, obwohl diese sich nicht ändern können Du berechnest aus diesen Konstanten weitere Konstanten (fix) und speicherst diese auch jede Minute in weiteren Datenpunkten Du führst Berechnungen durch die sich nur monatlich bzw. täglich ändern, und das jede Minute.

Letztendlich solltest du das Skript in 3 Teile teilen.

Einmal den der nur bei Start ausgeführt wird. Darin sind alle Konstanten abgelegt. Du kannst sie dann im Skript anpassen, und wenn du das Skript neu startest wird ab dann mit den neuen Konstanten gerechnet. Dabei sollten die Werte zunächst in Variablen gespeichert und dann in die Datenpunkte geschrieben werden. Im Skript selber rechnest Du dann weiter mit den Variablen.

Einmal den der nur einmal pro Tag laufen muss, in dem du deine Monatlichen und Täglichen Werte berechnest. Auch hier gilt: Berechnung von Zwischenwerten in Variablen machen so das du nie auf Datenpunkte zugreifen musst die du vorher aktualisiert hast.

Als letztes den Teil der schneller läuft. Da reicht es die Werte zu berechnen die sich auf die States beziehen die den Stromverbrauch bzw. die Stromlieferung dieses Jahr und/oder diesen Monat referenzierten.
Ob dieser wirklich einmal pro Minute laufen soll musst Du dann bewerten.

@bostil sagte in Zahl in Datenpunkt springt zwischen + und -:

Nun muss ich mich nur noch mit Variablen befassen.

Mit variablen solltest Du dich sowieso befassen. Betrachte sie einfach als 'Datenpunkte die nur einen Wert behalten wenn das Skript läuft'

A.

@mading
Was machst Du falsch:

Die Zeitbedingung passt nicht. Der Baustein Zeit zwischen A und B erwartet das A < B. Diese Regel verletzt du in deinem Falls. Besser wäre hier gewesen: nicht Zeit zwischen 0:00 und 3:00 Uhr die zusätzliche Abfrage im Sonst-Falls ist unnötig, ein "Sonst" hätte gereicht (wenn das Falls denn ok gewesen wäre. Die Falls Bedingung wird nur beim Start des Skriptes überprüft, sprich welchen Zweig der Bedingung du ausführst hängt nur davon ab wann das Skript gestartet wird. Die Variable BatterieLevel ist unnötig. Du kannst an Stelle dieser Variablen den Baustein aus dem Trigger-Bereich nutzen, der mit "Object ID" vorbelegt ist, sofern du diesen auf "Wert" umstellst. Die Sondermeldung bei Batterie < 5 % ist ungünstig in einem sonst Falls verbaut. Das führt dazu das wenn die Batterie unter 5% und die Ladesteckdose noch aus ist keine Warnmeldung das die Batterie so niedrig ist ausgegeben wird Ich würde auf eine gesonderte Meldung verzichten und statt dessen den Text in der Meldung über Bausteine aus dem Textbereich so zusammen setzen:
erstelle Text aus Vis Tablett Batterie auf BatterieLevel %. Schalte Strom ein.
Dabei hat der Erstelle Text aus Baustein 3 Knoten an denen die 3 folgenden Bausteine angedockt sind.

Generell gilt:
Trigger (auch Cron Trigger) machen hinter Falls Abfragen nur in Sonderfällen Sinn. Meistens ist es besser, den Trigger allgemein zu definieren und mit einer Falls Abfrage innerhalb des Triggers Zusatzbedingungen (wie die Uhrzeit) abzuprüfen.

Was du brauchst:

Im Trigger eine Abfrage auf die Uhrzeit, die verhindert das die Steckdose zwischen 0 und 3 Uhr abgeschaltet wird.

Einen cron Trigger, der die Steckdose um 0:00 Uhr auf jeden Fall einschaltet.

A.
p.s. Ich hasse Autokorrektur, insbesondere wenn sie verschlimmbessert.

@gluecksmann

Anbei mal ein Vorschlag als Pseudocode. Damit solltest Du Dir das ganze zusammen bauen können.

Kern ist die Kombination von "Timeout" zum abschalten nach 3 Minuten und "Intervall" um die Lampen jede Sekunde umzuschalten zum Blinken.

Trigger auf "IsOpen", Wert ist kleiner als vorher stopTimeout ausführen Timeout in 3 Minuten Szene Blau ausschalten, alle Lampen ausschalten stopIntervall Lampen Einschalten Lampen auf Blau schalten Warnmeldung per Speak ausgeben ausführen Intervall alle 1 sek Lampen mit "Umschalten" Baustein von an auf aus oder umgekehrt schalten

Wenn Du das so aufbaust sollte es nur aktiv werden wenn das "is Open" Objekt von wahr auf falsch wechselt.

A.

Hallo @ichbinsmart, ich bin gerade zufällig über den Beitrag gestolpert. Hast du mittlerweile eine Lösung gefunden?

Ich selbst nutze das Skript hier und damit klappt es ohne Probleme.
Ich habe es zwar etwas an meine Bedürfnisse angepasst aber mit der Version sollte es trotzdem funktionieren 🙂

@paul53 ah ja, der Befehl zum stoppen hat mir gefehlt. Sonst hatte ich es ähnlich aufgebaut. Super, vielen Dank.

@drake

Mit dem Wizard Zeitplan gibt es so einige Probleme. Nimm besser Cron.
Ggf. solltest du auch den Zahlenblock "0" nehmen, wenn dein Datenpunkt numerisch ist.