Fehler durch Limit von 5 RPC vermeiden/reduzieren

2025-04-29

Angenommen du verwendest mindestens ein Skript auf einem deiner Shelly und es kommt mehr oder weniger regelmäßig zum anhalten eines Skripts. Dies sei begleitet mit einer Fehlermeldung, welche besagt, dass zu viele RPC Aufrufe vorlagen.

In der Shelly API Dokumentation unter "Shelly Script Language Features" sind dazu die Ressource Limits zu finden, u.a. "No more than 5 RPC calls used in a script." Was bedeutet dies?

Die Beschreibung wäre treffender mit "No more than 5 RPC calls used in all running scripts."

Diese Einschränkung besagt, dass zeitgleich nicht mehr als 5 RPC ausgeführt werden dürfen, unabhängig von der Anzahl an laufenden Skripten. In einem Skript können und dürfen sehr wohl mehr als 5 RPC (= Shelly.call() Aufrufe) enthalten sein. Sie dürfen dann nur nicht alle zeitgleich ausgeführt werden. 

Wie lässt sich eine zu hohe Anzahl an zeitgleich ausgeführten RPC vermeiden?

Dies kann mit geeignet zusammengestellten Zeitplänen (= Schedule Jobs) realisiert werden, allerdings nicht mit den vorgesehenen Standard Werkzeugen. Siehe hierzu auch Mächtige Schedule Jobs auf dieser Website!

Die hierfür geeignete Vorgehensweise soll am Beispiel einer Uhrsteuerung für Nebenuhren dargelegt werden. Diese Uhrsteuerung habe ich per Skript und Schedule Jobs für einen Shelly Plus 2 PM + externes Polwenderelais implementiert.
(Inzwischen stelle ich auf pure Halbleitertechnik per Shelly Plus Uni + Brückentreiber DRV8801 von Texas Instruments um. Zum Einsatz kommt das Modul Polulu DRV8801, welches bereits die erforderliche Beschaltung mit Pull-Up bzw. Pull-Down Widerständen besitzt und ohne SMD Löten leicht kontaktierbar ist.)

Der Shelly Plus Uni besitzt zusätzliche Eingänge, über welche

• zwei binäre Signale,
• ein analoges Signal,
• mehrere Temperatursensoren DS18B20

gelesen werden können. So lasse ich auf dem Uni auch die Umgebungstemperatur erfassen. Zusätzlich habe ich vor, die Bodenfeuchtigkeit analog zu messen. Der "Uhr Shelly" wird also zur "Eier legenden Wollmilchsau" ausgebaut, wozu ich zwei Skripte verwenden werde.

Eine Standardmethode zum Skript basierten erfassen von Signalen bzw. deren Änderungen ist die Verwendung eines Eventhandlers, also einer Ereignis behandelnden Skriptfunktion. Siehe hierzu auch meine kleine Skripteinführung.

Der Eventhandler muss dem Shelly System mitgeteilt werden. Dann wird diese Funktion über das Auftreten von Ereignissen informiert. Die Funktion kann daraufhin unterschiedliche Prozesse/Aufträge starten, auch RPC.

Warum kann solche Ereignisbehandlung zum RPC Problem werden?

Wann solche Ereignisse auftreten, liegt nicht fest. Dieses Auftreten ist nicht determiniert. Es kann somit zu Häufungen kommen, und damit zum Überschreiten des RPC Limit. Abhilfe ist mit geeignetem Zeitmanagement möglich. Hierfür sind Schedule Jobs geeignet. Allerdings ist die Zeitsteuerung für zeitkritische Signale ungeeignet, bspw. Notfallsignale oder vom Anwender per Tastendruck ausgelöste Signale, auf die er eine sofortige Reaktion erwartet. Viele andere Dinge, wie Messungen, Abfrage eines Eingangszustandes ... können einem Zeitmanagement unterworfen werden. Eine RPC Häufung wird durch zeitliches Auffächern verschiedener Aufgaben verhindert oder zumindest verringert.

Das Zeitmanagement

Die bereits erwähnte Shelly Uhr arbeitet mit einer festen Periode von 1 Minute. In einer Minute wird

• das Signal zum minütlichen weiterstellen der Nebenuhrzeiger ausgegeben - immer zur Sekunde 59,
• die tatsächliche Uhrzeit abgefragt - immer zur Sekunde 29,
• bis zu 30 Impulse zum weiterstellen der Nebenuhr ausgegeben, wenn diese nachgestellt werden muss. Dies erfolgt alle geradzahligen Sekunden.

Hier sollte erkennbar sein, dass die obigen Aktionen nicht gleichzeitig erfolgen. Insbesondere zum Nachstellen der Uhr alle geradzahligen Sekunden liegt um mindestens 1s versetzt zu den anderen Sekundenwerten 29 und 59. Das ist Absicht.

Mit einer einfachen Planung kann bspw. die Temperaturmessung in dieses Zeitmanagement eingebaut werden. Es sei vorausgesetzt, dass die Abfrageperiode von 1 Minute als Grundlage verwendet wird. Das ist zwar nicht notwendig, kann aber leicht genutzt werden. Die zielführenden Kriterien für die Temperatur Abfragezeitpunkte sind

1. Der Sekundenwert soll ungerade sein, damit er nicht zeitgleich mit dem evtl. Nachstellen der Uhr auftritt.
2. Er soll mittig zwischen den anderen beiden Sekundenwerten 29 und 59 liegen, um möglichst große Zeitabstände zu jenen zu haben. Dies ist nicht zwingend. Es wäre auch ein 5s oder 10s Abstand möglich.

Dies ergibt zwei mögliche Sekundenwerte: (29+59)/2 = 44 -> 45 (weil ungerade) oder (59-29)/2 = 15.

Nun kann ein Schedule Job hinzugefügt werden, der minütlich bspw. zum Sekundenwert 15 eine Skriptfunktion aufruft, in welcher der Temperaturwert abgefragt und irgendwie verarbeitet wird. Zwischen diesen Sekundenwerten liegt vermutlich soviel zeitlicher Abstand, dass sich die RPC nicht anhäufen werden. Für einen Härtetest kann die Uhr in einen längeren Nachtstellvorgang gezwungen und die Temperatur jeweils in Sekunde 15 abgefragt werden. Soll der minimale zeitliche Abstand (hier 1s) größer sein, lässt sich dies mit einem langsameren Uhr Nachstellen erreichen, bspw. alle 4s ein Impuls statt alle 2s.

Dieses Szenario sollte auf andere zeitbasierte Anwendungen leicht übertragbar sein.

Wie können solche Schedule Jobs angelegt werden?

Hierfür habe ich auf einer Website u.a. zwei Seiten zur Verfügung gestellt, welche dieses Anliegen unterstützen.

1. Anlegen, ändern, entfernen von Schedule Jobs zum aufrufen von Skriptfunktionen
2. Unterstützung beim anlegen, ändern und entfernen von Schedule Jobs mit frei editierbaren Methoden und Parametern

Zum festlegen der Zeitwerte kann auch das Web-UI des Shelly genutzt werden. Unter "Schedules" kann ein solcher Zeitplan im "Advanced" Modus angelegt oder nachträglich editiert werden. Hier kann allerdings kein Skript Funktionsaufruf eingetragen werden. Stattdessen wählt man irgendeine Aktion, welche anschließend mit einer der beiden Webseiten (s.o.) abgeändert wird. Auch bereits angelegte Schedule Jobs können per Web-UI in den Zeitwerten geändert werden.

Hinweis: Im Web UI steht an den Stellen solcher Methoden, die das UI nicht "kennt", der Text "Call may not work as expected". Sie funktionieren trotzdem. Das Web-UI, App und Cloud arbeiten aus verständlichen Gründen für Standardanwendungen mit eingeschränkten Möglichkeiten. Der Scheduler ist erheblich vielseitiger, weil er Teil des RPC Konzeptes ist.

Erweiterung um weitere Aufgaben für den Shelly

Wenn bspw. der Uhr Shelly zusätzlich die Erdfeuchtigkeit erfassen soll, dann lässt sich dafür ein weiterer Schedule Job nutzen, welcher bspw. minütlich zur Sekunde 45 den Analogwert holt und irgendwie verarbeitet.