@paul53 Naja ehrlich gesagt weiß ich das nicht genau.. Aktuell übertrage ich den Wert quasi genau wie er ist und das klappt nicht. Loxone zeigt ihn nicht an. Wobei gut das ihr fragt.. sehe gerade ich übertrage noch einen anderen Wert auch aus dem Wolf Adapter nach Loxone und der ist im gleichen Format und funktioniert einwandfrei.. dann muss ich da nochmal in Loxone schauen. Danke trotzdem für die vielen Antworten! Ist echt mega das hier so viele hilfsbereite Experten sind!!

@paul53 danke.

Mir ist gerde im current log noch was aufgefallen: 2023-04-16 01:50:00.003 - debug: shuttercontrol.0 (10132) calculate astrodata ... 2023-04-16 01:50:00.003 - debug: shuttercontrol.0 (10132) Sun Azimut: 5.6° 2023-04-16 01:50:00.003 - debug: shuttercontrol.0 (10132) Sun Elevation: -29.1° 2023-04-16 01:55:00.002 - debug: shuttercontrol.0 (10132) calculate astrodata ... 2023-04-16 01:55:00.003 - debug: shuttercontrol.0 (10132) Sun Azimut: 7° 2023-04-16 01:55:00.003 - debug: shuttercontrol.0 (10132) Sun Elevation: -29° 2023-04-16 02:00:00.005 - debug: shuttercontrol.0 (10132) calculate astrodata ... 2023-04-16 02:00:00.006 - debug: shuttercontrol.0 (10132) Sun Azimut: 8.4° 2023-04-16 02:00:00.006 - debug: shuttercontrol.0 (10132) Sun Elevation: -28.9° 2023-04-16 00:00:00.031 - info: host.iobroker instance system.adapter.daswetter.0 started with pid 13008 2023-04-16 02:00:00.882 - info: daswetter.0 (13008) starting. Version 3.1.7 in /opt/iobroker/node_modules/iobroker.daswetter, node: v14.21.2, js-controller: 4.0.24 2023-04-16 00:00:04.049 - info: host.iobroker instance system.adapter.ical.0 started with pid 13023 2023-04-16 02:00:05.102 - info: ical.0 (13023) starting. Version 1.13.2 in /opt/iobroker/node_modules/iobroker.ical, node: v14.21.2, js-controller: 4.0.24 2023-04-16 02:00:06.405 - info: ical.0 (13023) processing URL: Müll https://calendar.google.com/calendar/ical/s.w.bernhard%40gmail.com/private-21faa25aa0eb243313582d9996cb7327/basic.ics 2023-04-16 02:00:09.810 - info: daswetter.0 (13008) still wrong data structure from server received! repaired... 2023-04-16 02:00:11.833 - info: ical.0 (13023) Terminated (NO_ERROR): Without reason 2023-04-16 02:00:11.933 - info: daswetter.0 (13008) Terminated (ADAPTER_REQUESTED_TERMINATION): All data handled, adapter stopped until next scheduled moment 2023-04-16 00:00:12.345 - info: host.iobroker instance system.adapter.ical.0 terminated with code 0 (NO_ERROR) 2023-04-16 02:00:12.450 - info: daswetter.0 (13008) cleaned everything up... 2023-04-16 00:00:12.456 - info: host.iobroker instance system.adapter.daswetter.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) Ab 2 Uhr, springt die Zeit hin und her zwischen der richtigen und dann wieder 2 Stunden zurück. Da wundert mich natürlich nicht, dass auch das Skript so merkwürdige Dinge bezogen auf den Zeittrigger macht. Hat da einer eine Idee, oder sollte ich diesbezüglich noch mal explizit danach und in einem anderen Unterordner fragen? VG Sascha

@liv-in-sky In MySQL muß man Variablen nicht definieren. Daher kann man die Output Variable @Preis einfach angeben und die wird durch die Definition in der Prozedur definiert. Das SELECT @Preis gibt sie einfach nur aus- das war der lahme Versuch an den Inhalt der Variablen zu kommen. Wenn man die Prozedur aus SQL heraus aufrufen würde, würde man einfach mit dem Preis weiter rechnen oder sonst was machen. LG Martin

@mrhary sagte: Beispielblockly erstellen? [image: 1681487181442-blockly_temp.jpg] Inhalt der JS-Funktion parentID(idDp): return idDp.substring(0, idDp.lastIndexOf('.'));

@miwi sagte: Jedoch wird der Entfeuchter um 18 Uhr nicht ausgeschaltet. Du hast die Trigger-Zeiten so begrenzt, dass der letzte Trigger um 17:50 Uhr erfolgt. Dann genügt es nicht, nur die Variable um 18:00 Uhr zurück zu setzen, sondern es muss auch der Entfeuchter ausgeschaltet werden.

@solarmaxe sagte in Werte vergleichen und Debug Modus funktioniert nicht: @bananajoe sagte in Werte vergleichen und Debug Modus funktioniert nicht: tail -n 50000 -F /opt/iobrok Hallo auch dir danke für die Antwort :) Aber mit tail -n sehe das gleiche wie im iobrocker Gui log. Das stimmt. Aber leichteres Copy&Paste, mehr Filter. Und eine Admin-Sitzung weniger im Webbrowser

@paul53 das läuft an der Realität vorbei, dann brauchts auch Fensterkontakt usw. Nein, das ist nicht was ich machen werde und wäre overkill, es geht nur um die einfache Überhitzung vom Heizkörper, Ein/Ausschaltzeiten werden das bewerkstelligen.

@homoran so simple...danke dir

@haselchen said in Adapter nachts ausschalten: AhoyDTU Nein. Aber danke für die Info. Mir gings darum dass ich bei "meinem" Adapter (envertech-pv) auf den Sonnenaufgang/-untergang reagieren könnte und z.B. das poll Intervall nachts reduzioeren kann, da da ja eher selten Solarstrom produziert wird. Aber wenn ich mal dafüpr Zeit hab. forsch ich da nochmals nach und frag ggF im dvp channel. Danke euch.

Warum geht er aber erst gar nicht in den Funktionsblock bei meinem Script?

@paul53 Danke. Stimmt jetzt gehts auch. Keine Ahnung warum ich eben ein falsches Ergebnis hatte. Ich stand wohl auf dem Schlauch :-(

@steely2 sagte in Anfängerfrage zu zulässigen Werten: Der On/Offmode hat aber dann doch nen Wahr/Falsch Wert gebraucht Das ist halt abhängig vom Datentyp des jeweiligen DP.

@rtwl said in Rechenfehler bei "Zeitstempel": die ganz letzte variable ist Ende statt Gesamt Du hast recht - Copy&Paste. Ich wusste was rauskommen würde, darum habe ich nicht mehr richtig geschaut (war so klein geschrieben ) Jetzt nochmal: [image: 1680677183113-ea016bd1-234a-4ee0-9628-2ce33a798a21-grafik.png] 08:46:29.776 info javascript.0 (1661) script.js.common.Testen.Zeitrechnungen2: Das interne Format des Start-Timestamps: 1680548400000 - wird für unsere Zeitzone zu dieser Darstellung formatiert: 03.04.2023 - 21:00:00 08:46:29.777 info javascript.0 (1661) script.js.common.Testen.Zeitrechnungen2: Das interne Format des Start-Timestamps: 1680634800000 - wird für unsere Zeitzone zu dieser Darstellung formatiert: 04.04.2023 - 21:00:00 08:46:29.777 info javascript.0 (1661) script.js.common.Testen.Zeitrechnungen2: Die Differenz aus beiden Daten (Ende-Start) ist die Differenz in Millisekunden: 86400000 oder in Stunden: 24 08:46:29.777 info javascript.0 (1661) script.js.common.Testen.Zeitrechnungen2: Der Versuch die Differenz als Datum darzustellen scheitert offensichtlich jenseits von UTC: 02.01.1970 - 01:00:00 Da sieht man jetzt auch die 1 "zusätzliche" Stunde, dadurch dass sich MEZ um 1 Stunde von UTC unterscheidet.

@dirk-4 sagte in Zwei Schalter sperren: ich habs mittlerweile hinbekommen. bitte die Lösung hier auch posten damit Mitlesende wissen wie Du es gelösts hast !

@jrlohni Mehrfaches Starten von Timern verhindert man, indem man die Timer-Variable als Sperre verwendet. Beispiel: [image: 1680620065536-blockly_temp.jpg]

@griessbx Versuch mal den Vorschlag von @paul53 umzusetzen. Damit sollte das auch dynamisch machbar sein - ohne Neustart des Script.

@codierknecht Das mit dem Zeitplan ist ok , ich habe eine feste Einschaltzeit Gruß Roland

@mickym ist ja auch okay. Macht ja was es soll. Damit komme ich erstmal klar. Und vielleicht nehm ich das ja auch zum Anlass mich mit NodeRed mal mehr zu beschäftigen. Es sieht ja interessant aus.

@myzerat [image: 1680527699674-blockly_temp.jpg]