Beiträge von eiche

Ich nutze für Aufzeichnungen und Grafiken einen Raspberry Pi 4 mit Mosquitto, Node-RED, InfluxDB und Grafana.

Dazu braucht es nicht zwingend eine Cloud, aber zweckmäßigerweise MQTT.

Szene bedeutet afaik Steuerung per Cloud. Na ja, dann arbeitet der Shelly nicht wie gewünscht, wenn die Cloudverbindung weg ist. Mein Ding wäre das nicht. Aber wie du willst.

Mit einem Shelly Plus 1 ließe sich so etwas per Script implementieren, was auch alleinstehend funktioniert.

Ich habe soeben mal meine erste Szene mit einem Plus 1 getestet, 1 Min ein, 1 Min aus - ohne Script. Das geht.

Ich werde das gleich mal mit 15 Min und 45 Min testen, incl. Protokollierung per Script.

Mal sehen ...

Die Mühe, dies mit einem Shelly 1 zu testen, werde ich mir jetzt nicht machen.

Ist der Shelly in ein WLAN als Client eingebunden oder ist er alleinstehend, bietet sich also als Accesspoint an?

Im ersten Fall muss der Gast einen WLAN-Zugriff haben, im zweiten Fall muss er sein Gerät mit dem WLAN des Shelly verbinden.

Das sind die Voraussetzungen, dass überhaupt das Gewünschte funktionieren kann.

Die Bedenken wurden bereits geäußert.

Es könnte hilfreich sein, wenn du nicht nur die Antwort/Fehlermeldung postest sondern insbesondere auch die von dir abgeschickte Nachricht bzw. den URL.

Das hat bereits @Muetze festgestellt.

Falls du noch Shellies in der Schublade liegen hast, sind die bereits aufgeführten Hinweise reizvoll.

Bevor du versuchst, weitere Shellies dazuzuschalten, bedenke andere Ideen! Sie basieren nicht auf Verdrahtung und purer Konfiguration sondern auf Software.

Du könntest betreffende Shelly 1 durch Shelly Plus 1 ersetzen, also solche der zweiten Generation. Diese lassen sich in ihren Funktionen sehr flexibel durch Scripte erweitern. Damit ist es bspw. möglich, die lokale Uhrzeit abzufragen und abhängig von dieser Zeit

1. den Shelly automatisiert spezifisch zu konfigurieren oder
2. die Betätigung des Schalters/Tasters wirksam oder unwirksam werden zu lassen

Ich kann gelegentlich gerne hierfür ein Script erstellen.

Besonders flexibel wird das Ganze mit MQTT. Dann kann man die "Nachtzeit" nach Bedarf per Smartphone einstellen und die Nachtszene mal eben deaktivieren bzw. aktivieren.

Man kann die Cloud verwenden, man braucht sie aber nicht zwingend. Beim Einsatz eines solchen Scripts braucht man nicht zwingend MQTT, es geht auch alleinstehend.

Für deinen Einsatzzweck würde ich dir einen Shelly Plus 1 mehr empfehlen als einen Schelly 2(.5). Die zweite Generation ist zukunftssicherer, weil auf Dauer vielseitiger einsetzbar.

Eine andere Möglichkeit mit Shelly 1, wieder mit MQTT, besteht darin, das Einschalten zu erfassen und beim Einschalten per MQTT sofort wieder auszuschalten.

Für MQTT braucht man aber so etwas wie einen Raspberry Pi. Dieser kann 24/7 arbeiten und Dienste zur Verfügung stellen. Damit geht sehr viel. Evtl. können auch die fertigen IoT Anwendungen wie ioBroker, openHAB ... so etwas. Solche können auch auf einem Raspberry Pi arbeiten.

Schließlich kann man auch Tasmota auf den Shelly 1 flashen und dessen Funktion per Rules erweitern.

Ein ersetzter Shelly 1 kann bspw. per Addon als Messstation für Temperatur und Luftfeuchtigkeit weiter verwendet werden.

Frage Fizzy : Womit steuerst du deine Shelly 1 außer mit angeschlossenen Schaltern?

Am AP sollte es nicht liegen, weil ...

Zitat von Placebo2210

--> Ich habe sogar extra einen Shelly 1 daneben geklemmt, der genau das gleiche schalten simuliert, der geht nie offline

Ich habe mit 12V Hutschienen-Netzteilen (wohl zumeist für LED Beleuchtung eingesetzt) als Shelly Versorgung und zum schalten von 12V Magnetventilen erhebliche Störprobleme gehabt. Schließlich funzten die Teile dauerhaft, als ich einen Abstand von ca. 30 cm zwischen Trafo und Shelly einhielt.

Vielleicht liegt hier ein ähnliches Problem vor. Nicht alle meine Trafos stören den zugeordneten Shelly 1 in gleichem Maße. Ob dies am Trafo oder eher am Shelly liegt, habe ich nicht weiter untersucht.

Das mag ja sein. Ich wäre aber dann nicht überrascht, wenn der Shelly 3 em zwischenzeitlich keine WLAN-Verbindung hat. Und eine kleine zusätzliche Abschirmung per metallenem Gegenstand kann in solcher Umgebung bereits die Verbindung entscheidend stören. So gesehen erscheint mir weder die Entwicklung des 3em ohne LAN sowie dessen Nutzung hinter Metall - hust - nicht sehr professionell.

Äh ... koppkratz

Auf einer Abbildung sah ich die Umgebung des betreffenden Shelly 3em. Das sieht nach Schaltschrank aus Blech aus.

Darin würde ich keine halbwegs brauchbare WLAN -Verbindung erwarten.

Professioneller sind dafür die Hutschienen-Shellies mit LAN-Buchse geeignet.

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.

Ich lasse die Daten meiner TRV aufzeichnen (InfluxDB) und kann nachschauen (Grafana), wann und wie weit der TRV das Ventil geöffnet hat - ohne Cloud. Das geht per Cloud auch unter 'Ventilposition'.

Hast du mal nachgeschaut, ob der betreffende TRV ungewöhnlich aktiv ist/war? Der Antrieb dürfte relativ besonders viel Energie verbrauchen.

Wenn der TRV eher wenig arbeiten musste, würde ich vorsichtig auf ein Akku-Problem tippen. Wenn er viel arbeiten musste, versuche dies irgendwie abzustellen, evtl. ein Kalibrieren laufen lassen!

Zusätzlich ist es möglich, die MQTT Nachrichten aufzuzeichnen. Ich nutze hierfür Node-RED. Ob Home Assistant das auch kann, weiß ich nicht. Jedenfalls könnte eine Protokollierung des MQTT Nachrichtenverkehrs evtl. einen weiteren Hinweis sichtbar machen.

Alternativ zu Node-RED kann auch ein Linux Shellscript unter Verwendung von mosquitto_sub die spezifischen MQTT Nachrichten erfassen und in eine Datei schreiben.

Ich habe bisher aus der shelly Familie nur shelly 1 mit tasmotizer geflasht und dabei vorher die Original Firmware gesichert, aber noch nie zurückgeflasht. Auf meinen zwei H&T läuft Original Firmware. Ich habe noch nicht versucht, diese zu flashen. Aber ich würde bei Bedarf versuchen, dazu erneut tasmotizer einzusetzen. Von einem funktionstüchtigen H&T die Firmware sichern und diese auf einen 'toten' H&T flashen.

Hierzu würde ich sicherheitshalber eine externe USB-Versorgung verwenden. Die Batterieversorgung wäre mir für diesen Vorgang etwas zu riskant.

Von mehr Erfahrung kann ich bei H&T leider nicht berichten.

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 ...

Hallo.

Mir gefällt die Stabilität der aktuellen Firmware zur zweiten Generation nicht. Ich kann deine Frage derzeit leider nicht beantworten. Ich habe aber einen Hinweis zum besseren Code.

Statt vieler if Abfragen kannst du eine Datenstruktur erstellen, die zudem besser pflegbar ist.

let Cmd = [
    'http://'+ipa+'/light/0?dim=down',
    'http://'+ipa+'/light/0?dim=up'
    //, ... weitere Einträge
];

let Dim = [false, false];

// in deinem EventHandler:
//...
if(event.info.event==='long_push') {
    Dim[event.info.id >> 1] = true; // >> 1 bewirkt eine Ganzzahldivision durch 2
    controlDimmer(Cmd[event.info.id]);
}

Nur mal so. Vielleicht sagt es dir zu. Auf diese Weise erhält man zu Beginn eines Scripts eine Konfigurationssequenz, die übersichtlich pflegbar ist. Und der Ablaufcode wird kürzer und damit übersichtlicher.