Einleitung:
Mich interessierte, welche minimalen Impulse an den Outputs möglich sind, evtl. auch um dort eine eigene PWM erzeugen zu können.
Letzteres vorweg: max. 6Hz bei 1 kanaligem Betrieb und max. 3 Hz bei 2 kanaligem Betrieb.
Damit ist einem wirklich nicht geholfen, wenn mein eine PWM benötig.
Aber man könnte (evtl. werde ich das noch ergänzen) am Analogeingang ein Poti anklemmen und dann damit die "PWM" als autarke Blinklichtsteuerung nutzen.
Messaufbau:
Der Messaufbau ist recht simpel: 24V Netzteil versorgt den Shelly Plus Uni und die beiden Pull-UPs mit je 1kOhm. Die andere Seite der Widerstände sind an je einem Output verschaltet.
Und natürlich noch ein Scope zum Messen.
messaufbau shelly plus uni outputs_IMG_2370.jpg
Ich messe zuerst jedoch nur einen Kanal, um das grundsätzliche Verhalten zu erforschen.
Versuche mit 1 Kanal:
Als erstes habe ich es mit einem meiner üblich erstellten Scripte probiert: alles schön in Teil-Funktionen gepackt, die dann von irgendwas anderem aufgerufen werden.
Da habe ich schnell gemerkt, dass wenn man da an die Grenzen will, das Plus Uni recht schnell "sensibel" wird.
Ich habe dann mal alle AddOns entfernt und alles weitere auch deaktiviert (bis auf den Websocket), den brauchte ich zum Debuggen.
Dann habe ich gemerkt, dass auch diese Aufruferei der Funktionen Zeit kosten, also habe ich das Script auf das wesentliche minimalisiert:
// FJG, Stand 11.04.24
// es duerfen hier nur die Peripherals integriert werden,
// die der Weboberflaeche installiert worden.
// Ansonsten Scriptfehler!
// Konstanten definieren
//===========================================
// Shelly-Type vorbesetzen
const shellytyp1_c = "ShellyPlusUni";
const shellyname1_c = "Plus-Uni-SSR-Speed3 1 Kanal";
//check every seconds > <
const checkInterval_c = 80;
// Namensdefinitionen, Anwendungsspezifisch
//===========================================
// Benennung SSR am ShellyPlusUni
const switch_name0_c = "LowPegel Out1";
const switch_name1_c = "LowPegel Out2";
// Benennung Digital-Eingaenge am ShellyPlusUni
const digital_name0_c = "LowPegel In1";
const digital_name1_c = "LowPegel In2";
// Analog-Eingang
const analog_name0_c = "Analog-Eingang 0";
// Variablen definieren
//===========================================
// Hardwarenahe Variablen
let togglebit0_v = "0";
//ShellyPlusUni
//=======================
function FuncTimerSet() {
ScheduleTimer_v = Timer.set(
checkInterval_c,
true,
function (ud) {
if ( togglebit0_v === "0" ) {
Shelly.call(
"Switch.Set",
{ id: 0, on: false },
function (response, error_code, error_message) {}
);
togglebit0_v = "1";
}
else {
Shelly.call(
"Switch.Set",
{ id: 0, on: true },
function (response, error_code, error_message) {}
);
togglebit0_v = "0";
};
},
null
);
}
FuncTimerSet();Das sich aus diesem Script ergebene minimal taugliche Timing ist in [checkInterval_c = 80;] als Millisekunden definiert, für einen Puls bzw. eine Pause.
Die Signale mit einer Pulsdauer von 79ms und Pausendauer von 80ms sehen recht passabel aus.
Warum das die minimalsten Zeiten sind, kann man am folgenden Screenshot erahnen:
Ab und an kommt wohl der Sheduler des Shellys bei der hohen Scriptlast aus dem Tritt und unterbricht knallhart das Script.
Eine Timing-Inkonsistenz tritt auf, im Screenshot bei etwa 1000ms hinter der Mittenachse.
Das wird umso schlimmer, wenn der Wert bei CheckInterval kleiner als 80ms wird.
Recht gut geht es, wenn auch mit geringen Einschränkungen, mit CheckInterval = 100ms.
Versuche mit dem 2-Kanalige Output
OK, dass war der einkanalige Betrieb, da dürfte doch wohl beim 2 kanaligen das Gleiche rauskommen?
Der Shelly hat ja 2 gleich wertige SSR-Outputs, da könnte man doch auf die Idee kommen, die im Gegentakt zu betreiben.
Warum? Weiss ich gerade selber nicht, aber manchmal kommen mir da so Ideen ...
Also, das Script von oben auf 2-kanaligem Betrieb umschreiben und damit dann die weiteren Timing-Versuche durchführen:
// FJG, Stand 11.04.24
// es duerfen hier nur die Peripherals integriert werden,
// die der Weboberflaeche installiert worden.
// Ansonsten Scriptfehler!
// Konstanten definieren
//===========================================
// Shelly-Type vorbesetzen
const shellytyp1_c = "ShellyPlusUni";
const shellyname1_c = "Plus-Uni-SRS-Speed3 2 Kanal";
//check every seconds > <
const checkInterval_c = 150;
// Namensdefinitionen, Anwendungsspezifisch
//===========================================
// Benennung SSR am ShellyPlusUni
const switch_name0_c = "LowPegel Out1";
const switch_name1_c = "LowPegel Out2";
// Benennung Digital-Eingaenge am ShellyPlusUni
const digital_name0_c = "LowPegel In1";
const digital_name1_c = "LowPegel In2";
// Analog-Eingang
const analog_name0_c = "Analog-Eingang 0";
// Variablen definieren
//===========================================
// Hardwarenahe Variablen
let togglebit0_v = "0";
let togglebit1_v = "0";
//ShellyPlusUni
//=======================
function FuncTimerSet() {
ScheduleTimer_v = Timer.set(
checkInterval_c,
true,
function (ud) {
if ( togglebit0_v === "0" ) {
Shelly.call(
"Switch.Set",
{ id: 0, on: false },
function (response, error_code, error_message) {}
);
Shelly.call(
"Switch.Set",
{ id: 1, on: true },
function (response, error_code, error_message) {}
);
togglebit0_v = "1";
}
else {
Shelly.call(
"Switch.Set",
{ id: 0, on: true },
function (response, error_code, error_message) {}
);
Shelly.call(
"Switch.Set",
{ id: 1, on: false },
function (response, error_code, error_message) {}
);
togglebit0_v = "0";
};
},
null
);
}
FuncTimerSet();Das Script wird später nochmal interessant.
Bei dem Ursprünglich, vom ersten Script übernommenen Wert, von 80ms stürtzte das Scripting sofort nach Aktivierung ab.
Die Fehlermeldungen in der Script-Konsole sind ja nicht wirklich hilfreich.
Also den Wert langsam erhöhen, bis sich eine stabile Funktionalität einstellt: [checkInterval_c = 150;]
Weniger geht nicht.
Ja, man kann hier auch schön die eingestellten Puls- und Pause-Zeiten erkennen und der 2. Kanal ist eine Invertierung des 1. Kanals.
Jetzt kommen wir wieder zum Script zurück.
Dort kann man in den IF-Cases sehen, dass die Shelly CALLS nacheinander erfolgen.
Dieses nacheinander ist der Grund dafür, dass die beiden Kanäle nicht wirklich exakt invertiert sind, sondern ein kleiner Versatz dazwischen ist.
Ich habe dann mal den Versatz ausgemessen: dieser liegt bei 15ms.
Das bedeutet auch, dass dieser Shelly 15ms benötigt, um den Shelly CALL abzuarbeiten.
