Beiträge von Thomas_S.

Zitat von Angel

Konzept zur Umgestaltung der App

Und das ist völlig unnötig, solange andere Baustellen nicht fertig sind. Aber typisch für die heutige Zeit. Schnell schnell was Neues mit neuen Bugs, kruden Einstellmöglichkeiten etc.

Ist nur wieder dafür da, den Anwender zum Mitentwickler und Betatester zu machen.

Warum dieser Kommentar? Weil ich echt ang. bin. Von den Entwicklern angebomt wurde, sie bräuchten keine Hinweise mehr zu einem Bug im Plus Uni, ich sollte besser einen Workaround nutzen und programmieren lernen (ich habe mich an die Shelly-Dokumentation gehalten). Ticket wurde ohne Lösung und ohne Mitteilung nach mehreren Monaten einfach geschlossen. Ein anderes ist jetzt 11 Monate immerhin noch offen... Meine Meinung: es gibt für ältere, aber immer noch aktuelle Geräte definitiv keinen Supoert mehr. Lohnt sich halt nicht.

Zitat von Volkerm81

Der funktioniert!!! Endlich !

Dieser Beitrag von Volkerm81 hat mich inspiriert, in China noch ein wenig nach Varianten zu stöbern.

Der AM2320(B) ist nach meiner Meinung einer der besten MEMs von Asair. Aber dieser Sensor wird scheinbar nicht mehr hergestellt, zumindest gibt es bei Asair direkt keine Listung mehr. (Rest-) Bestände sind aber noch reichlich verfügbar, sowohl auf Aliexpress wie Alibaba. Und da habe das gefunden.

Der wird sehr wahrscheinlich nicht von Asair selbst zusammengebaut, der eigentliche Sensor ist aber ein original Asair AM2320. Interessant ist hier die Möglichkeit, intern ggf. notwendige Ergänzungs-Bauteile für besondere Betriebsbedingungen (Stütz-C, Rs & eine Lötbrücke für die Betriebsart) ordentlich ohne Frickelei hinzuzufügen. Es reicht aber natürlich auch für die normale Anwendung mit den Shellys nur schwarz und weiß zusammenzuklemmen (für Betriebart Singlebus) ohne zu löten.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Hier der Link zum Angebot. Man achte auf den Preis...

Ich empfehle bei Interesse übrigens immer, mit dem Verkäufer in China im Chat-Kontakt die tatsächliche Ausführung zu klären, sonst gibt es möglicherweise eine andere Ausführung mit schlechter Qualität. Und die eigene Lieferadresse sollte stimmen (China Versender verdrehen da öfters was).

Zitat von apreick

Selbst wenn du einen finden solltest, wird er intern in Shelly „kastriert“

Wie recht du da doch hast

Wollte einmal Rückmeldung dazu geben. Grundsätzlch läuft seit Mai 25 alles sehr stabil und verlässlich.

Aber alle DHT, egal welche Ausführung, werden in der Temp nur bis 80,0 °C unterstützt. Darüber wird n/a ausgegeben. Die Feuchtewerte werden auch bei sehr hohen Temperaturen noch geliefert (und sind soweit wie zu erwarten immer genau). Also wird die reine Auswertung nur der Temperatur intern begrenzt, bereits bevor Bit 14 auf H geht und mehr als 81,9 ° erreicht werden.

Ist wirklich eine sehr mutwillige Kastration, weil völlig sinnbefreit. Das kritische Timing kann kaum als Grund herhalten, da die Feuchtewerte einwandfrei ausgewertet werden. Es geht also prinzipiell.

Lösung waren zwei Plus UNI mit einem DS18B20 /einem AM2303, nur die Feuchtewerte werden vom ersten Plus UNI per rpc

http.get,{url:"http://IP/rpc/humidity.getstatus?id=100"},callback

vom zweiten abgefragt. Macht Temp. bis 125°C und Feuchte über den gesamten Temp.-Bereich.

Ein Ticket dazu bei Shelly hat wohl keinerlei Priorität (jetzt 10 Monate offen), die habe zu viele andere Baustellen. Denke ohnehin, das der Plus UNI langsam raus ist aus der Wartung.

Danke für den Link, das ist sehr hilfreich!

Zitat von DIYROLLY

Da ist die Firmware für zuständig

Nö. Viel zu ungenaue Beschreibung. Ist zwar nicht wirklich wichtig, aber wenn die FW genannt wird, sollte doch etwas klarer definiert werden, wozu die überhaupt gebraucht wird.

Für keines der aktiven / passiven Teile im AddOn ist irgendeine FW notwendig. Die Auswertung der durchgereichten DHT-Daten wird nur im Grundgerät durchgeführt. Dazu ist dann die FW natürlich notwendig.

Ob / wie die Signale vom AddOn verändert / verfälscht werden, und was davon ggf. durch die FW abgefangen werden kann, ist zuerst eine Frage der Qualität des AddOn - und, wie immer, der Versorgungsspannung, der Sensorspannung des DHT, der Qualität des DHT, der Leitungen, der... BlaBla - das gilt prinzipiell für jedes Problem der Elektronik.

Ohne Schritt für Schritt Analyse kommt man da nicht weiter.

Aber mir ist es jetzt völlig egal. Weil nicht logisch und gezielt Schritt für Schritt eine Analyse auch nur annähernd gemacht wird. Hauptsache, eine unbelegte Annahme wird wiederholt.

Wenn konkret nach Daten gefragt wird, die einen Einstieg in eine Analyse ermöglichen und die sehr einfach erlangt werden können, sind diese auf einmal nicht lieferbar... Warum? Ich mache da nicht mehr mit.

Zitat von scheuerer

In den zwei Stunden ist leider kein Spike zu sehen

Dann ist damit nichts anzufangen. #177 mag eine gute Nachricht für dich sein, aber in #178 stehen Fakten.

So kann man keine Analyse gestalten, und auch nicht helfen. Gar nicht.

Nochmal: das AddOn macht nichts, wozu die FW benötigt wird. Ein zwar aktiver, aber völlig dummer "Adapter", nicht mehr.

Es kann nur defekt sein oder funktionieren (wie alles andere auch).

Zitat von scheuerer

ist das modifizierte Firmware für den Homekit

Nur ein Teil. Natürlich ist ein Risiko dabei, aber wenn nichts mehr gehen sollte besser als nichts...

Ist zwar etwas unübersichtlich, aber die Dateien die ich hier habe (einige selbst gesicherte original 1.3.3 und 1.7.x) sind checksumidentisch.

In einigen Unterverzeichnissen (z.B. 1.7.1) stehen modifizierte und originale (xxxx-orig.zip).

Bekka420 Genau diesen Sensor habe ich im Betrieb, seit Mai 2025 keine Probleme. Natürlich kann einer auch defekt sein, aber normal ist das nicht.

Was ich von vorneherein berücksichtigt habe: immer eine abgeschirmte Leitung verwenden (außer sehr kurz). Und bei langen Leitungen ggf. einen zusätzlichen C (keramisch 1µ oder 0µ47 Folie) direkt am Sensor zwischen Vcc und GND und kein weiterer Widerstand. Der Widerstand wird eigentlich nur benötigt, wenn die Leitungskapazität erheblich ist. Bei guten Leitungen, z.B. Audioleitungen, ist das eher nicht der Fall (ca. 110 pF/m). Die Leitungen schlage ich selber an neue Steckverbinder passend zum Sensor an (Typ ist HY 2.0). Der Aufwand hat sich wohl doch gelohnt...

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.      Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

scheuerer Mir scheint da ein ganz anderes Problem als die FW vorzuliegen. Erst mal eine Analyse...

Warum wird denn so lange 0°C ausgegeben? Das sind doch keine "Spikes" sondern lang andauernde Totalaussetzer. Erklärung: Der Shelly ruft regelmäßig (ca. alle 2 - 3 Sekunden, je nach Auslastung) die Daten vom DHT ab. Das muss er, da der DHT keine Daten bei "Änderung" von sich aus meldet sondern immer nur auf "Anruf" die augenblichlich zutreffenden Daten zurückgibt. Das der das dann für mehrere Minuten völlig falsch macht ist sehr sehr unwahrscheinlich.

So etwas kenne ich nur, wenn gar keine Daten ankommen und der Shelly n/a anzeigt, was intern als leerer Wert zu null (und das dann als value 0) gerechnet wird. Was zeigt denn das Log zum gleichen "Null"-Zeitraum bzw. was zeigt die Shelly WebUI? Das solltest du mal ansehen und vergleichen.

Zuerst ein Hinweis: ich weiss es nicht, was die Ursache ist...

... aber die Reaktion auf jeden Event (hier die Temparaturänderung 0,1°C) ist möglicherweise das Problem. Die Daten müssen ja gesendet (oder abgefragt) werden, und das lastet den Shelly bereits gut aus. Da solche geringen Änderungen recht häufig auftreten, kann das zu Störungen im Datenverkehr des DHT führen. Nur meine 99ct... , kann auch unzutreffend sein.

Warum das von der FW abhängt ... es kamen immer mehr an Funktionen dazu, und da werden möglicherweise jetzt die Grenzen der ESP32-Kapazität erreicht, oder die internen Prioritäten bei der Abarbeitung wurden geändert, oder oder...

Es gibt einige FW in einem externen Datengrab beim Projekt shelly-homekit, aber nicht jede.

scheuerer Ich nutze einen AM2305B, der originär als Singlebus konfiguriert ist (siehe Datenblatt oben). Der hat also nur drei Anschlüsse.

Intern scheint beim "B" nur eine Brücke zwischen Pin 3+4 zu sein, aber da ich die AM2305 / AM2305C, die I²C können, nicht habe, kann ich nicht vergleichen, ob das Innenleben ansonsten identisch ist.

Das mit den Spikes ist mir so noch gar nicht aufgefallen. Möglicherweise auch eine Frage der Datenanforderung. Ich frage die Daten alle 10s per Script über GetStatus immer komplett ab. Die Daten werden dann nur intern per Script ausgewertet. Im Skript gibt es nur einen Filter für Nullwerte, die selten auftreten, wenn der Shelly ausgelastet ist. Eine externe Anbindung und Auswertung nutze ich nicht.

Noch was zum AddOn... Soweit ich das beurteilen kann, ist das nicht mehr als eine - ich nenne es mal so salopp - "Platinenerweiterung" des Grundgeräts. Da ist nichts drauf, was irgendwie programmiert werden könnte. Galvanische Trennung, Bereitstellung von analogen und digitalen Kanälen. Mehr nicht. Die Ansteuerung, A/D-Wandlung und Auswertung der Signale muss das Grundgerät zusätzlich leisten - was so angebunden noch etwas schwerer ist als z.B. beim PlusUni, der das direkt macht. Ich glaube, es ist besser, hier nicht zuviel zu erwarten

Und noch was Konkretes für die Fernosteinkäufer: hier habe ich einen guten Einkauf gemacht: originale AM2320, die alle sehr gut funktionieren. Der Händler hat auch noch andere originale Typen. Bei den AM2305B wird es deutlich teurer und schwieriger, die zu finden...

Zitat von scheuerer

Neuere, oder Nachbauten, sind zwar verfügbar, spinnen aber an den AddOn's mit FW > 1.4.0 rum.

Hmmm, das kann ich zu den "Neueren" eigentlich nicht so eindeutig bestätigen.

Der AM2305B an einem Shelly1G3 + Addon + FW 1.7.4 läuft ohne Probleme. Hin und wieder kommt im Log zwar "err DHT reading", aber scheinbar nur, wenn der S1 anderweitig ausgelastet ist (z.B. Script im Hintergrund). Die Timings zur Auswertung der ser. Daten sind eben zeitkritisch, und der ESP32 genügsam. Jeder Interrupt (Call, Timer, etc.) stört.

Ich sehe auch nicht, dass das wirklich ein Problem darstellt. Aus meiner Sicht sind die DHT ohnehin NICHT die richtigen Sensoren, wenn man wirklich genaue und verlässliche Messwerte benötigt.

Für meine einfachen Anwendungen verwende ich immer ausschließlich die originalen von Aosong / Asair, in Betrieb bzw. getestet habe ich AM2301, AM2301A, AM2302, AM2303, AM2305B, AM2320 an mehreren Plus Uni mit FW 1.4.x bis 1.7.x. Läuft alles.

Und natürlich auch DS18B20 in Zweier- und Vierer-Gruppe. Hinweis: auch da gibt es Fakes bei Aliexpress.

Zu Nachbauten stimmt die Aussage mehr oder weniger. Da gibt es alles, von "geht gar nicht" oder "ungenau" bis "funktioniert, ja". Aber wer kann ohne genaue Typenbezeichnug damit was anfangen? Und wie soll Shelly das fixen? Man kann ja schlecht die Timings so lange variieren, bis irgendwelche Daten kommen. Geht nicht. Die sind alle raus. Aosong / Asair, nur "origin", fertig.

Zwei Sensoren, der hier noch gar nicht erwähnt wurden: Aosong AM2303 und Asair AM2305(B)

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Leider wird der AM2303 von Aosong nicht mehr vertrieben, es gibt nur noch Restbestände oder (lizensierte?) Nachbauten, bei denen die Feuchtekalibrierung nicht so gut ist. Die Besonderheit: er enthält einen großflächigen Feuchtesensor und einen DS18x20 als Temperatursensor, er geht damit bis zu 125°C.

Angel dazu gibt es ein generelles Problem mit den Shelly (getestet mit Plus UNI): die FW begrenzt die Temperaturmessung bei 80,0°C, es wird dann nur noch "n/a" ausgegeben. Die Feuchtewerte werden weiterhin korrekt geliefert, auch bei 95°C, was bedeutet, dass die Datenauswertung einwandfrei funktioniert, es liegt nicht am Timing. Hier sollte die FW auch eine höhere TemperaturANZEIGE ermöglichen - die künstliche Begrenzung ist etwas seltsam... (Ticket #169739).

Das eigentliche Problem mit den Inkompatibilitäten der verschiedenen Singlebus-Sensoren (DHTxx / AMxxxx) ist bedingt in einer schier völlig aus dem Ruder gelaufenen Fertigung - selbst beim Originalhersteller Aosong / Asair.

Seit Begin wurden die Sensoren ständig völlig neu konstruiert, mittlerweile kommen statt diskreten Bauteilen mit A/D-Wandler nur noch solche mit MEMS-Modulen in den Umlauf. Anhängend mal ein paar Datenblätter (es sind PDFs) zur Info, aber Achtung: da sind auch alte Stände dabei.

Hinzu kommen diverse billige Nachbauten ("no brand"), die häufig einfach nicht vollständig / gar nicht funktionieren. Der Marktplatz Aliexpress ist besonders anfällig, aber auch da finden sich Händler, die bei der Beschreibung das Wort "original" benutzen. Das hilft bei der Auswahl (meine Erfahrung), sind aber nur schwer zu finden. Wenn man nicht darauf achtet: ich hatte sogar schon eine Lieferung mit original und "no brand" gemischt

Grundsätzlich noch eine Anmerkung: die Messung der rel. Luftfeuchte ist eine Aufgabe, die nur schlecht zu lösen ist. Wenn man es genau haben möchte, MÜSSEN die Sensoren regelmäßig kalibriert werden. Mit den einfachen Dingern hier kaum zu lösen, daher sind +- 10%-Punkte völlig normal, im Lebensalter noch mehr...

[Nanu... ??? warum kann man hier eigenlich keine PDF direkt hochladen ???]

Auch wenn das hier gerade gar nicht weiterhilft:

Habe mehrere Uni Plus in Betrieb, einige bereits über 1 Jahr. Keinerlei Probleme - bisher.

Nun hat einer seine WLAN-Verbindung völlig verloren, die AP-Verbindung ist nur noch sehr schwach vorhanden.

DHT-Daten werden nur noch als n/a angezeigt.

Von einem Tag auf den anderen nach nur etwa 6 Wochen, keine besonderen Betriebsbedingungen, nur stabile 12V als Versorgung.

Reklamiert, umgehend neuen bekommen, und: auch defekt, definitiv.

WLAN ist normal sehr gut verbunden, springt aber ständig von einem Hotspot zum anderen (Standardroaming auf -80 dB).

Wählt lieber -65 dB als -25 dB.

Greift man auf das WebUI zu, bootet er häufig einfach neu...

Und beim Einschalten der Versorgung wird der Switch0 kurz eingeschaltet, obwohl "off at power on".

DOA. Und klar, jetzt geht die Diskussion mit dem Händler los: Spannung, Netzteil, Schaltung, unfähig?

Es ist einfache Technik. Mag jeder seine Welt damit automatisieren, ich bleibe da lieber sehr konservativ und zurückhaltend.

[ERGÄNZUNG]

Eben habe ich eine Erstattung für den Shelly bekommen. OK, ist aber trotzdem doof.

So ganz verstehe ich deinen Hinweis nicht, denn so steht es auch in deinem verlinkten Beispiel:

Zitat

type_or_key

string

Component type or key("component:id"). Component type must be in lowercase.

Aber egal, auch mit getrennter ID keine Funktion im "besonderen" UNI.

Wenn ich die keys auslese, kommt auch "voltmeter:100" als key zurück. Noch werden die so zusammengebastelt (was es nicht einfacher macht).

Insofern ist auch die Lösung mit diesen keys so zustandegekommen, es ist nur ein "call" notwendig:

// Messdatenarray, globale Variable
let actual_data = {
    tC: "n/a", // Temperatur in °C
    rH: "n/a", // rel. Luftfeuchtigkeit in %rH
    V: "n/a" // Spannung in V
};

// aktuelle Istdaten auslesen (asynchrone Funktion)
function GetActualData() {

    Shelly.call("Shelly.GetStatus", null, function(response, error_code) {

        if (error_code === 0) {

            if (response["temperature:100"] != "undefined") {
                actual_data.tC = response["temperature:100"].tC;
            } else {
                actual_data.tC = "n/a";
            };

            if (response["humidity:100"] != "undefined") {
                actual_data.rH = response["humidity:100"].rh;
            } else {
                actual_data.rH = "n/a";
            };
               
            if (response["voltmeter:100"] != "undefined") {
                actual_data.V = response["voltmeter:100"].voltage;
            } else {
                actual_data.V = "n/a";
            };

         // Fehler
        } else {

            print("Fehler: " + error_code);

        };

    });

    // debug
    print(actual_data.tC + "°C   ", actual_data.rH + "%rH   ", actual_data.V + "V");

    // Rückgabe funktioniert HIER NICHT bei asynchronen Funktionen
    //return actual_data;

};

Möglich ist alles Mögliche (sorry für den Sarkasmus).

Fast alle, auch der betroffene, haben einen identischen AM2301A (DHT22, es ist ein originaler AOSONG), der auch Minus (-) messen kann.

Ansonsten nur ein Reed-Kontakt, der über den Shelly (mit Script) eine Lichtleiste eine gewisse Zeit nachleuchten lässt. Eher eine einfache Aufgabe... Auch dieses Script habe ich einfach mal rausgeschmissen - reboot - keine Änderung.

Auf einem Test-PLUS-UNI habe ich 9 Scripte gehabt, teilweise laufend, kein Problem. Auch der ECO-Mode spielt keine Rolle. Zeit haben auch alle übers Inet...

Zitat von tvbshelly

Dann bitte einmal alle Unis neu starten und den Aufruf Script.GetStatus wiederholen. Danke.

Keine Änderung, höchstens kleine in MEM used.

Hatte ich auch schon mehrmals gemacht. Ebenfalls die FW auf dem problematischen noch mal geflasht (habe das passende FW-zip-File).

Was noch ginge wäre ein Reset auf Werk, aber das ist mir gerade zu umständlich...

Zitat von tvbshelly

Kannst du mal bitte folgenden RPC auf den jeweiligen Uni ausführen:

Der mit dem Fehler:

{"id":2,"running":false,"mem_free":23814,"errors":["syntax_error"],"error_msg":"Uncaught SyntaxError: RETURN statement, but not in a function.\n\n at return actual_data;\n ^\nin function \"GetActualData\" called from actual_data = GetActualData()\n ^\nin function \"Timer1event\" called from Timer1event();\n ^\nin function called from system\n\n"}

Der mit dem Fehler (ohne RETURN):

{"id":3,"running":false,"mem_free":23856,"errors":["internal_error"],"error_msg":"Uncaught InternalError: Too many scopes removed\n at actual_data = GetActualData()\n ^\nin function \"Timer1event\" called from Timer1event();\n ^\nin function called from system\n\n"}

Der wo es läuft:

{"id":1,"running":true,"mem_used":2688,"mem_peak":3304,"mem_free":22498}

Und hier noch das Script. Die Problem-Funktion ist extra mit "// ############################" markiert.

// Messen & speichern von Temperatur & Feuchte inkl. Datum
// speichern von minTemp (mit Feuchte & Datum), maxTemp (mit Feuchte & Datum) für jeden Wochentag im KVS
// speichern von absoluten minTemp (mit Feuchte & Datum) bzw. maxTemp (mit Feuchte & Datum) im KVS
// 2025-05-29 - 2025-06-01 v1 ## testing ##

// Definitionen / Konstante
// Temperaturspeicher
let maxTemp = "n/a";
let minTemp = "n/a";
let maxTempHum = "n/a";
let minTempHum = "n/a";
let maxTempDate = "n/a";
let minTempDate = "n/a";
// Datum
let D = null;
let saveHour = null;
let day = "n/a";
let month = "n/a";
let year = "n/a";
let hour = "n/a";
let min = "n/a";
let sec = "n/a";
let dayName = "n/a";
let dayArray = Array("So", "Mo", "Di", "Mi", "Do", "Fr", "Sa");
// Messintervall Timer 1 (>= drei Sekunden)
let delay1 = 4;
// Messdatenarray
let actual_data = {
    tC: "n/a", // Temperatur in °C
    rH: "n/a", // rel. Luftfeuchtigkeit in %rH
    V: "n/a" // Spannung in V
};
// KVS
let err = 0;
let saved = 0;
let KVSkeyMaxTemp = "all-time max Temp";
let KVSkeyMinTemp = "all-time min Temp";
let KVSkeyMaxTempValue  = null; 
let KVSkeyMinTempValue  = null; 
let KVSdayArray = Array("-", "Mo", "Di", "Mi", "Do", "Fr", "Sa", "So");


// Startsequenz, wird unten (EOF Script) einmalig zum Scriptstart aufgerufen
function init() {

    // Variable zum stündlichen debug-log aktualisieren
    saveHour = Date().getHours() + 1;

    // Timer1 (Intervall, um Temperatur & Feuchte zu messen)
    startTimer1(delay1);

    // im KVS gespeicherten Wert "KVSkeyMaxTempValue" holen
    KVSgetValueMaxTemp();

    // im KVS gespeicherten Wert "KVSkeyMinTempValue" holen
    KVSgetValueMinTemp();

};


// Timer1 starten
function startTimer1(delay) {
    // Timer1 handle
    Timer.set(delay * 1000,
        true,
        function () {
            Timer1event();
        },
        null
    );
};

// Timer1 event
function Timer1event() {

    // Temperatur & Feuchte messen
    actual_data = GetActualData()
    
    // debug
    print(actual_data)
    
    // Temperatur auswerten
    CompareTemperature(actual_data)

};


// ############################ 
// aktuelle Istdaten auslesen
function GetActualData() {

    // wenn Temperatursensor verfügbar
    if (Shelly.getComponentStatus("temperature:100") != null) {
        actual_data.tC = Shelly.getComponentStatus("temperature:100").tC;
    }
    // wenn Feuchtesensor verfügbar
    if (Shelly.getComponentStatus("humidity:100") != null) {
        actual_data.rH = Shelly.getComponentStatus("humidity:100").rh;
    }
    // wenn Voltmeter verfügbar
    if (Shelly.getComponentStatus("voltmeter:100") != null) {
        actual_data.V = Shelly.getComponentStatus("voltmeter:100").voltage;
    }

    // debug
    // print(actual_data.tC + "°C   ", actual_data.rH + " %rH   ", actual_data.V + " V");

    // Rückgabe
    return actual_data;

};


// aktuelles Datum & Zeit holen und formatieren
function getDateTime() {

    var D = Date();

    day = "" + D.getDate();
    month = "" + (D.getMonth() + 1);
    year = "" + D.getFullYear();

    hour =  "" + D.getHours();
    min = "" + D.getMinutes();
    sec = "" + D.getSeconds();

    dayName = dayArray[D.getDay()];

    if (day.length < 2) {
        day = '0' + day;
    }
    if (month.length < 2) {
        month = '0' + month;
    }

    if (hour.length < 2) {
        hour = '0' + hour;
    }
    if (min.length < 2) {
        min = '0' + min;
    }
    if (sec.length < 2) {
        sec = '0' + sec;
    }

    return dayName + " " + [day, month, year].join(".") + " " + [hour, min, sec].join(":");

}


// erstellen von neuen KVS-Einträgen und setzen von KVS-Werten
function KVSsetValue(key, value) {

    Shelly.call("KVS.Set", {
            "key": key, "value": value
        }, function(response, error_code) {

        if (error_code === 0) {
            err = 0;
        } else {
            err = error_code ;
        };

    });

};


// asynchrone Funktion, benötigt lange zum füllen der globalen Variablen
function KVSgetValueMaxTemp() {

    Shelly.call("KVS.Get", {
        "key": KVSkeyMaxTemp
    }, function(response, error_code) {

        if (error_code === 0) {
            KVSkeyMaxTempValue = response.value.substring(0, response.value.indexOf("°C"));
        } else {
            KVSkeyMaxTempValue = "n/a";
        };

    });

};


// asynchrone Funktion, benötigt lange zum füllen der globalen Variablen
function KVSgetValueMinTemp() {

    Shelly.call("KVS.Get", {
        "key": KVSkeyMinTemp
    }, function(response, error_code) {

        if (error_code === 0) {
            KVSkeyMinTempValue = response.value.substring(0, response.value.indexOf("°C"));
        } else {
            KVSkeyMinTempValue = "n/a";
        };

    });

};


// aktuelle Istdaten mit Solldaten vergleichen und auswerten
function CompareTemperature(actual_data) {

    // temporäres speichern der Temperatur Max- & Min-Werte mit Datum und Feuchte
    // speichern des Maximalwerts
    if (actual_data.tC > maxTemp || maxTemp === "n/a") {
        maxTempDate = getDateTime();
        maxTemp = actual_data.tC;
        maxTempHum = actual_data.rH;
    }
    
    // speichern des Minimalwerts
    if (actual_data.tC < minTemp || minTemp === "n/a") {
        minTempDate = getDateTime();
        minTemp = actual_data.tC;
        minTempHum = actual_data.rH;
    }

    // debug
    print("log - min: " + minTemp + "°C " + minTempHum + "%rF " + minTempDate + " - max: " + maxTemp + "°C " + maxTempHum + "%rF " + maxTempDate);

    // stündlich einmalig einen kompletten Wert im debug-log schreiben
    // D wird weiter verwendet...
    D = Date();
    if (D.getHours() === saveHour) {

        print("log - min: " + minTemp + "°C " + minTempHum + "%rF " + minTempDate + " - max: " + maxTemp + "°C " + maxTempHum + "%rF " + maxTempDate);

        saveHour++;
        if (saveHour === 24) {saveHour = 0};

    };

    // täglich um 23:59 Uhr: speichern der Tages-Max- & -Min-Werte sowie ggf. eines neuen absoluten Max- oder -Min-Werts
    if (D.getHours() === 23 && D.getMinutes() === 59 && saved === 0) {

        // Tages-Max- & -Min-Werte f��r KVS zusammenstellen
        var newKVSmaxTempValue = maxTemp + "°C " + maxTempHum + "%rF " + maxTempDate;
        var newKVSminTempValue = minTemp + "°C " + minTempHum + "%rF " + minTempDate;

        // absolute Max- & Min-Werte prüfen und ggf. neue Werte im KVS speichern
        if (maxTemp > KVSkeyMaxTempValue || KVSkeyMaxTempValue === "n/a") {
            KVSsetValue(KVSkeyMaxTemp, newKVSmaxTempValue);
        }
        if (minTemp < KVSkeyMinTempValue || KVSkeyMinTempValue === "n/a") {
            KVSsetValue(KVSkeyMinTemp, newKVSminTempValue);
        }

        // aktuellen Wochentag für KVS-Key ermitteln - Format: "1 Mo", "2 Di", ...
        // Tageskürzel
        var KVSdayName = maxTempDate.substring(0, 2);
        // Tagesnummer (Arrayindex)
        var newKVSdayKey = KVSdayArray.indexOf(KVSdayName) + " " + KVSdayName;
        // Tages-Max- & -Min-Werte für KVS zusammenstellen
        var newKVSdayValue = "min: " + newKVSminTempValue + " - max: " + newKVSmaxTempValue;

        // Tageswert in KVS speichern
        KVSsetValue(newKVSdayKey, newKVSdayValue);

        // debug
        print(newKVSminTempValue);
        print(newKVSmaxTempValue);
        print(newKVSdayKey);
        print(newKVSdayValue);

        // zurücksetzen der temporären Tageswerte
        saved = 1;
        maxTemp = "n/a";
        minTemp = "n/a";
        maxTempDate = "n/a";
        minTempDate = "n/a";
        maxTempHum = "n/a";
        minTempHum = "n/a";

    } else if (D.getHours() != 23 && saved === 1) {

        saved = 0;

    };

};


// Startsequenz aufrufen
init();

Die Angelegenheit ist noch geheimnisvoller.

Mein Beispiel von oben läuft auf mehreren PLUS UNI problemlos. Alle PLUS UNI haben den gleichen FW-Stand 1.6.2

Heute habe ich das Beispiel von einem Plus Uni auf einen weiteren kopiert - läuft NICHT!

Fehlermeldung: "RETURN statement, but not in a function." (ist ja Quatsch).

Wenn ich "return" weg lasse kommt die Fehlermeldung: "Uncaught InternalError: Too many scopes removed". Na so was!

Wenn ich das ganze auf EIN EINZIGES Shelly.getComponentStatus() reduziere, läuft es wieder (kann so aber nicht genutzt werden).

Jetzt erkläre mir mal jemand, warum das auf allen bis auf einen PLUS UNI läuft...

Offenbar muss ich das auf Async umstellen, damit das auf diesem einen PLUS UNI auch läuft...

Die originale Dokumentation von Shelly.getComponentStatus() kommt auch ohne "Call" aus.

Der Suppoort irrt hier also.

Allerdings hat Input:2 beim PlusUni so seine Eigenheiten. Auch wenn er deaktiviert wurde, weil nicht benötigt, erzeugt er sog. Events, die im Devicelog gelistet werden und den Eventhndler auslösen. Das macht ihn für einige Aufgaben unbrauchbar...