Nach Deiner Beschreibung machen die Shellys genau das, was Du parametriert hast.
Woher soll der erste Shelly denn wissen, dass die Lampe via Smartphone eingeschaltet ist um dann eine URL mit Ausschaltbefehl zu senden?
Mach da mal statt "...turn=on bzw. turn=off..." turn= toggle...
Mir gefällt der "Json-Käfer"... 
Hallo Kluke,
nur kurz zwischendurch:
Guck dir mal die ganze Message an, die der Shelly-Node liefert (im debug-node nicht nur msg.payload, sondern msg. anzeigen lassen) dann findest du sehr viele Werte (ähnlich als wenn du im Browser ip-adresse-shelly/status eingeben würdest) - dort läßt sich dann der gewünschte Wert filtern.
Wenn ich wieder zuhause bin, kann ich dir das ggf. auch erläutern.
Ich weiß jetzt, warum die DW2 alle mit so hohen Temperaturen starteten... ?
Sind wir hier ein Rätselforum? 
Sach doch was du herausgefunden hast...
Ob du den DW zur Montage in der Hosentasche hattest oder mit bloßen Händen angepackt hast....?!?
Wenn der NodeRed und der ioBroker beide auf dem gleichen Rechner einen Coap-Listener aufmachen dann dürfte es u.U. Probleme geben weil der Port bereits in Benutzung ist..
Hm... wie könnte man das denn trennen?
Ich hatte die ganze Installation so verstanden, dass der ioBroker quasi die Grundlage, die Plattform, die Basis darstellt und die Adapter/Instanzen die Schnittstellen/Datenzulieferer sind...
NodeRed läuft, wie z.B. Telegram, text2command, javaskript (Blockly) etc. als im ioBroker installierter Adapter...
Wie und wieso sollten ioBroker-Adapter auf einem anderen Gerät installiert werden (können)?
Zudem habe ich - bevor die Probleme auftauchten - die Datenpunkte der Shellys in NodeRed nicht mittels der Shelly-Nodes geholt, sondern die Nodes "ioBoker in" und "ioBroker out" verwendet - also die Datenpunkte des Shelly-Adapters...
Erst neuerdings "spreche" ich die Shellys über die Nodes direkt an....
poste mal relevante Versionen deines Systems. Also auch den Raspbian Unterbau, Kernel, was du so findest und meinst das es relevant sein kann. Selbst hab ich ähnliches HW Setup. Fritzbox, Raspi4B an Netgear xyz Switch, Shelly Adapter und hier bemerke ich keine Ausfälle.
Also RaspberryPI4b mit 8GB per LAN direkt an Fritzbox 7490 (Firmware 7.21).
Ich hänge mal ein paar Bilder an:
Soweit das - ich hoffe, du kannst dir einen Reim darauf machen....
Switches hängen, was Shelly angeht nicht dazwischen...
Wie gesagt, Shelly-App/Cloud und NodeRed funktionieren 24/7 tadellos - nur die Shelly-Daten im io-Broker fallen immer wieder aus...
Viele Grüße,
Wolfgang
und NodeRed läuft über Coap (auf dem gleichen Rechner)?
Ja - wie gesagt, als Instanz/Adapter im io-Broker auf dem Raspberry...
Eventuell ist es doch der Unmanaged Switch, der Pakete verschluckt, weil die Shelly Cloud jederzeit funktioniert und die Pakete per WLAN nicht über den Switch gehen …
UPDATE: Ich habe jetzt einen neuen Managed Switch bestellt (NETGEAR GS716T) … ich hoffe, der beseitigt die Probleme.
Hallo ,
da bin ich ja mal gespannt, was du zu berichten hast...
Bei mir hat auch der nächtliche Neustart nicht dazu geführt, dass es für 24h funktioniert... Habs wieder deaktiviert..
Bei mir kommt es manchmal nach wenigen Minuten wieder zum Ausfall.. oder auch erst nach Stunden...
Ich schließe mittlerweile bei mir ein Netzwerkproblem aus, da zum Einen die App/Cloud immer zuverlässig läuft und zum Anderen NodeRed völlig störungsfrei "liefert".
Ich habe spasseshalber mal meine Skrips und Meldungen, die normalerweise die io-Broker-Datenpunkte der Shellys nutzen in NodeRed "nachgebaut"... Das funktioniert 24/7... Das bedeutet für mich, dass die Daten im Raspberry ankommen, aber dann irgendwie auf dem Weg über den Shelly-Adapter "stecken bleiben"... NodeRed läuft auch nur als Instanz im io-Broker und alle Shellywerte kommen sauber "rein"...
Ich habe den Shelly-Adapter mal in Ruhe gelassen - auch wenn nichts mehr ging - manchmal kommen nach Minuten wieder die Werte, manchmal dauert es mehr als ein Tag (währenddessen NodeRed brav mit den Shelly kommuniziert)...
Dies einfach mal als Info über den Stand der Dinge....
Viele Grüße,
Wolfgang
Ähem - auf die Gefahr hin, dass ich mich hier lächerlich mache:
Sollte der "Motion" nicht primär "Bewegung einer Wärmequelle" (Lebewesen/Warmblüter) detektieren und nicht ein sich bewegendes Garagentor?
M.E. macht der Motion alles richtig, wenn lediglich das Tor aufgeht und sich ggf. die Lichtverhältnisse ändern....
Guten Morgen,
ich habe seit einigen Tagen das ähnliche Problem.
Allerdings steigen bei mir sämtliche Shellys im ioBroker aus.
In der App/Cloud wird alles richtig angezeigt (Status, Energie etc.etc.) und ist im EventLog der App auch lückenlos sichtbar.
Witzigerweise wird der Uptime-Wert der Shellys aktualisiert und der Status "online" im ioBroker wird als "true" angezeigt. Alle anderen Werte (z.B. Temperatur, rssi-Wert etc.) sind "eingefroren".
Auch bei mir bringt der Neustart des Adapters sofortige Abhilfe des Zustands - bis zum nächsten Mal...
Bei mir hängt der RaspberryPi4b direkt am LAN der Fritzbox 7490 und die Shellys sind via Repeatern/Powerline-Adaptern etc im WLAN-Netz. Wie gesagt, in der App/Cloud auf dem Smartphone oder auch im PC-Browser sind alle Shellys lückenlos online und werden aktuell angezeigt/können gesteuert werden....
Alle Updates sind gelaufen Shellys/ioBroker/Adapter/Fritzbox/Repeater/Powerline...
Alle anderen Geräte werden problemlos angezeigt etc. z.B. über ModBus, tr-064 usw.
Mir fehlt ein bisschen die Idee, was ich noch testen könnte... da es ja immer direkt sämtliche Shellys betrifft (egal über welchen Weg die im Netz sind)...
Vielleicht habt ihr eine Idee?
Der TE casa_ab scheint ja kein Problem mehr zu haben - ich habe auch mal einen Neustart in der Nacht eingerichtet, aber irgendwie will mir der Sinn/Hintergrund nicht einleuchten...
Viele Grüße,
Wolfgang
Hallo Julian,
obwohl ich deiner Beschreibung nur rudimentär folgen kann sind meine Tipps:
1. Endlagenschalter Markise auf zulässigen Fahrweg einstellen.
2. Korrekte Kalibrierung des 2.5er auf den zulässigen Fahrweg.
Hallo shadow79,
nun, wenn du dir vor Augen führst, warum es die Mindestlast bzw. den Bypass gibt (geben muss), der Schaltkontakt nicht potentialfrei ist (sein kann) und dir dann anschaust, wie die Anschlußdiagramme die Verdrahtung darstellen, dann siehst du, dass es nicht um die Versorgung des Shelly1L mit einer Phase geht, sondern dass der Shelly-Betriebsstrom "irgendwo fließen kann".
Daher nützt es überhaupt nichts, wenn du dir woanders eine Phase herholst. Abgesehen davon, dass das (wenn es tatsächlich ein anderer Außenleiter ist) auch mächtig schief gehen kann....
Moin,
das ist doch nur eine Ausschaltverzögerung (TOF). Ich kenne zwar BLOCKLY nicht (sieht so aus wie Lego Mindstorm ab 10 Jahren...).
Solange am Timer die Eingangsbedingung erfüllt ist (Leistung > 1.500W) läuft der Timer. Ist die Bedingung nicht mehr erfüllt, fängt die Nachlaufzeit an herunter zu laufen. Ein erneutes Erfüllen der Bedingung setzt den Timer wieder auf den Vorgabewert (60min), ob nun die Zeit schon abgelaufen ist oder nicht. Solange der Timer läuft ist sein Ausgang 1.
Was mir auffällt (aber das muss ja nicht so sein): Wie soll ein Block mehrfach durchlaufen werden, wenn sein Aufruf auf der Änderung eines Status beruht? Wenn im aktuellen Zyklus die Änderung festgestellt wurde, dann trifft doch dies im nächsten Zyklus nicht mehr zu, da der Status nun gleich dem vorherigen ist.
So nur mal als Gendanken von mir gegeben...
Hallo ASI-Master,
kommst Du auch aus der SPS-Welt?
Mir ist das mit dem Ablauf/Aufruf auch so gegangen, dass ich von zyklischen Abläufen ausgegangen bin.
So, wie man mir das erklärt hat wird das Skript genau einmal abgearbeitet, wenn die Triggerbedingung erfüllt ist - und dann wird wieder gewartet, bis der Trigger erneut auslöst (hier Power einen anderen Wert annimmt, als der Wert bei der letzten Auslösung). Dann werden die wenn/dann/sonst, falls/mache/sonst, if/then/else Blöcke durchlaufen - ggf. Timer etc gestartet.
Und dieser Timer (und wahrscheinlich auch andere Dinge) laufen wohl quasi "außerhalb" des Skrips ab.
Soweit ich das auch verstanden habe werden die Timer/Cron-Jobs etc im System registriert und müssen definiert gestoppt werden, wenn sie nicht weiterlaufen sollen. Da reicht es wohl nicht, dass der Trigger nicht auslöst. Und so kann es wohl auch zu den (undurchsichtigen) Zuständigen kommen, dass mehrere Timer o.ä. im System aktiv sind, nur weil man im Skript die Parameter geändert hat. Ich bin da streckenweise schon verzweifelt, bevor ich das wusste. Mittlerweile starte ich einen Skript immer manuell neu, wenn ich was geändert habe und wenn Timer laufen, dann sogar den ganze Adapter...
Ich starte das Script, wenn die Maschine läuft. Nach der eingestellten Zeit geht alles aus, wunderbar. Einschalten kann ich sie allerdings nicht mehr. Der Startvorgang wird immer nach 3 - 5 Sekunden unterbrochen, alles wieder aus. Wo hier der Fehler liegt weiß ich nicht.
Wie meinst du das denn, du startest den Skript, wenn die Maschine läuft?
Den Skript startet man einmal, dann registriert der Trigger den zu überwachenden Wert und man läßt das ganze in Ruhe...
Wie startet denn "die Maschine"?
Hast Du mal die Stromwerte über einen Zeitraum X verfolgt?
Vielleicht benötigst Du noch eine Verzögerung, bis das Gerät "hochgelaufen" ist?!?
Viel zu aufwändig.
So geht das einwandfrei:
Dann würde ich als erste Amtshandlung die funktionierende Firmwareversion aufspielen.
Dann ggf. ein Ticket eröffnen und Problem/Beobachtung genau beschreiben.
Trotz aller Unkenrufe funkt mein DW2 mit seinem ersten Satz Batterien den Status und die Temperaturänderungen draußen vom Einfahrttor her... gut - sind erst zwei Monate, aber hier im Forum hat man mir aufgrund der niedrigen Temperaturen einen schnellen Batterietod prophezeit...
Je nach "Auslastung" bzw Konfigurationsänderungen/Firmwareupdate ist die Batterieanzeige schon mal bis 86% abgesunken... erholt sich aber immer wieder... trotz Minusgrade....
Ich hab die Batterien (nur nach Preis entschieden) in meinen DW2er
weil ich mir das Thread Thema genauer anschauen möchte
Gibts da schon echte Produktivinstallationen? Ich dachte das gibts erst auf dem Papier...
Nun, ich kenne Homekit nicht.
Daher kann ich da keine Aussage machen, welches System sich da eignet.
Ich persönlich bin mit ioBroker und NodeRed unterwegs - ggf. auch demnächst mit MQTT...
Und da ist die Einbindung vorhandener Hausinstallation, die ich steuern will sehr gut mit Kleinsteuerungen wie Siemens Logo, Eaton EasyE4 o.ä möglich. Ein Grundgerät EasyE4 (welche mit 12VDC, 24DC, 230VAC Betriebsspannung gewählt werden können) bieten je nach Ausführung 8 Eingänge (wovon ggf. 4 analog genutzt werden können) und 4 Ausgänge , die je nach Ausführung potentialfrei sind. Kosten je nach Angebot (Bundle) rund 120€. Leistungsbedarf <3W.
Und die Ethernetschnittstelle würde ich als zuverlässiger einstufen, als eine Batterie ganze WLAN-Geräte an einem Fleck und so eine Kleinsteuerung hat gerade mal 4 TE - viel weniger wirst du für die Shellys nicht benötigen, wenn du deren Temperatur niedrig halten willst.
Aber wenn Du eh keine Aktoren willst...
In meinem Fall würde ich dann nach einem Teil mit zig Eingängen suchen, welches mir die Signale an die Zentrale liefert.
Aber bei Dir - da werden ja Signale von verschiedenen Stromkreisen (ggf. sogar von unterschiedlichen RCD-Kreisen) ausgewertet ist Deine Shelly-Idee vielleicht doch gar nicht die Schlechteste. Garantiert zumindest die strikte Trennung der Kreise auf Signal-/Leistungsebene.
Also wenn ich alle infrage kommenden "Strippen" in Verteilerkästen hätte, würde ich nicht mit jeder Menge einzelnen WLAN-Geräten/Aktoren arbeiten, sondern mir ein System installieren, welches als ein Gerät im Netz auftaucht...
