Problem im Script Ablauf, irritierende Fehlermeldung

Hallo.

Ich setze viele Shellies ein, teilweise mit Original Firmware, mit und ohne Cloud, teilweise mit Tasmota. Ich habe Erfahrung mit Tasmota32 und Berry auf einem ESP32 Board (kein Shelly). Davon bin ich begeistert.

Meine neuen Shelly der zweiten Generation statte ich gerne mit Scripts (Shelly Script, mJS subset) aus. Derzeit kämpfe ich mit einem Shelly Pro 2 und dem Scripting.

Ich habe drei Scripts erstellt, die virtuelle Geräte (VD=virtual device) implementieren. Diese VD kommunizieren per MQTT miteinander. Da der Pro 2 zwei Schaltausgänge besitzt, habe ich in jedem der drei Scripts eine entsprechende Struktur aus Objekten erstellt. Ein Objekt dient als Prototyp für eine Liste (Array) aus Objekten dieses Prototyps. Das Eventhandling habe ich weitgehend im Griff.

In der Doku zum Scripting vermisse ich Hinweise zum Garbage Collector, welcher vermutlich arbeitet, was aber auf der Scripting Ebene nicht feststellbar ist. mJS beschreibt eine Funktion gc().

Nun zu meinem Problem:

Die Scripte arbeiten sehr gut zusammen.

Hin und wieder erscheint eine Fehlermeldung "Subscription callback error: implicit type conversion is prohibited".

Diese Fehlermeldung ist irreführend. Sie verweist auf folgenden Codeabschnitt:

let Circuits = 2; // Tatsächlich lasse ich diese Anzahl per hässlichem aber funktionstüchtigem Workaround ermitteln.
let C0 = '0'.charCodeAt(0);

function getId(topic) {
  let i = topic.charCodeAt(topic.length-1) - C0;
  //let i = JSON.parse(topic.slice(topic.length-1));
  let max = Circuits - 1 ;
  return i<0 ? 0 : (i>max ? max : i);
}

Die Fehlermeldung verweist auf die erste Zeile in der Funktion getId(), Zeile 5. Zeile 6 ist ein Workaround-Versuch. Das importierte MQTT Topic beinhaltet am Ende die Id, hier '0' oder '1'. Es ist fehlerfrei. Eine implizite Typkonvertierung findet nicht statt bzw. ist nicht von mir codiert, entgegen des Inhalts der Fehlermeldung. Die Fehlermeldung erscheint bei ca. jeder dritten Abarbeitung eines eintreffenden Ereignisses, nicht reproduzierbar und in der Dichte nicht verlässlich.

Diese Funktion setze ich in allen drei Scripten (VD) ein. Die Fehlermeldung kann auch auf die entsprechende Stelle in einem anderen Script hinweisen. Sonstige Laufzeitfehler ereignen sich nicht mehr. Ich bin gerne bereit, ein oder alle drei Scripte zur Verfügung zu stellen. Es ist aber sehr unwahrscheinlich, dass dort ein Codefehler zu finden ist. Ich habe lange daran gearbeitet und sehr viele Tests durchgeführt. Auch habe ich aus Verzweiflung temporär alle MQTT retains abgestellt, ohne Erfolg.

Ich vermute das Problem irgendwo im Inneren der Firmware - mongoose OS oder JS Interpreter oder Speichernutzung (Stack vielleicht).

Bedauerlicherweise kann ich meine neuen Shelly Pro 2 so nicht wie gewünscht einsetzen.

Die Doku zu Shelly Script ist einigermaßen zu gebrauchen, wenn man bereit ist, sich durchzuexperimentieren. Ich nutze u.a. einen Raspberry Pi 4 mit Mosquitto und Node-RED.

Meine VD Scripte habe ich in deren Anwendung beschrieben auf deutsch und auf english. Mein english ist eingeschränkt, ich komme aber zurecht.

Ausnahmsweise weiß ich mir bei diesem merkwürdigen Verhalten nach etlichen Tagen des Experimentierens und Protokollierens nicht mehr zu helfen.

Hinweis zu den beiden Links. Die Links können statt direkt zu den Artikeln nur zu meiner Website führen. Dort sind beide Artikel dann unter 'Projekte' zu finden - Generation 2 ...

Inzwischen habe ich festgestellt (Vermutung), dass im Falle einer Fehlermeldung die Abfrage der length Eigenschaft des importierten Strings (topic) zum Fehler führt. Dies ereignet sich, wie bereits beschrieben, manchmal. Diese Fehlermeldung erscheint bei Verwendung von

• topic.charCodeAt(topic.length-1)
• topic.slice(topic.length-1)

Dann bricht die Abarbeitung (run) des Scripts ab. Eine simple Protokollierung per print() zeigt, dass das Zeichen bzw. die Zeichenkette am Ende von topic im Fehlerfall nicht zur Verfügung steht. Deshalb liegt die Vermutung nahe, dass mit der Abfrage von length der beschriebene Fehler auftritt.

Ich werde wohl als Workaround das Topic ändern und die Id in eine JSON Payload einbetten müssen, um die Scripts hoffentlich verlässlich zum laufen zu kriegen.

Ich arbeite noch daran und werde meine Erkenntnisse hier aktualisieren, indem ich diese Mitteilung bearbeite.

Hurra. Ich habe eine (fast) unglaubliche Lösung gefunden, die zudem sehr simpel ist.

Meine Funktion getId() sieht nun so aus:

let Circuits = 2;
let C0 = '0'.charCodeAt(0);

function getId(topic) {
  let p = topic.length - 1;
  let i = topic.charCodeAt(p) - C0;
  let max = Circuits - 1 ;
  return i<0 ? 0 : (i>max ? max : i);
}

Ich habe also schlicht topic.length-1 vor den Aufruf von charCodeAt() gesetzt. Das darf selbstverständlich nicht notwendig sein und ist eindeutig auf einen Fehler in der Firmware zurückzuführen.

Aber es funzt. Nun werde ich einen automatisierten Testlauf mit Protokollierung starten. Danach werde ich sehen, ob sich der beschriebene Fehler ereignete.

Zwischenbericht:

Nach inzwischen 30 automatisiert abgelaufenen Prozessen ereignete sich kein Fehler.

Diese Prozesse werden alle 10 Minuten per MQTT Nachrichten gestartet.

Dabei wird jede der beiden Schaltuhren (Script 'timer') auf eine Startzeit in 2 bzw. 3 Minuten gesetzt sowie die Einschaltdauern auf 6 und 4 Minuten eingestellt.

Die im Script 'switch' implementierte Protokollierung sendet per MQTT im JSON Format die Id (0 oder 1), die erfasste Einschaltzeit, die gemessene Einschaltdauer, und ob zwischenzeitlich ein MQTT-Ausfall vorlag.

Diese JSON Nachricht wird in einer Datei anhängend gespeichert.

Vor der simplen Lösung gab es nie zwei solcher Prozesse hintereinander ohne Fehler. Ich bin sehr zuversichtlich, dass nun die Scripte funktionssicher laufen.

Nun kann ich wohl das Problem als behoben werten. Nur der Fehler in der Firmware bleibt, es ist nicht der einzige. Die Firmware ist auch noch jung.