Schöne Lösung und einfach.
Der Vollständigkeit halber hier ein Beispieltext für den Function-Node, der den Change-Node ersetzen könnte, wofür jedoch keine Notwendigkeit besteht:
Code
msg.payload = msg.payload["min_brightness"];
return msg;Beiträge von Schubbie
VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
-
-
Moin,
Experte ist übertrieben. Hier da Thema, welches man vorab lesen sollte:
Ich habe die Logik des Dimmers in NodeRed nachgebaut, Seven of Nine per Script(?).
Also ich sehe da die Notwendigkeit eines übergeordneten Systems, wenn man alles annähernd realisieren möchte.
Der SW2 ist leider von der Art der Auslöser für Actions begrenzt. Ich vermute, dass du mit separaten 4-fach-Tastern und Shelly i4 näher an dein Ziel kommst.
Problem, selbst mit übergeordnetem System, wird deine gewünschte Synchronisation zwischen den Dimmern sein. Mit dem i4 hinterlegst du fixe Werte, die dann von allen angenommen werden. Denn z.B. der Toggle-Befehl weiß nicht, welcher Dimmer an und welcher aus ist, sowie der Cycle-Befehl nicht weiß, welcher Dimmer bei nächster Aktion hoch- oder runterdimmen wird.
-
Liest sich so, als wenn es funktionieren sollte, es führen ja sicherlich keine Einzeladern in die Verteilerdose?
-
Und wo in deiner Skizze soll der Shelly sitzen. Welche Adern führen in die Schalterdose und gehen wohin?
Hast du einen Elektriker, der dir helfen kann? Ich vermute, dass du uns lediglich mit Farben dienen könntest.
-
Das heißt, dort wo der Shelly hin soll, habe ich L, N und "L" zum Schalter.
Oder "L" zur Lampe? Dann würde es vermutlich reichen.
Hast du gemessen oder nach Farben geguckt?
Kannst du es skizzieren?
-
So einen Beitrag hätte ich mir gleich am Anfang gewünscht, dann hätte ich meine Taster früher nochmals getestet, ob ich damit ebenfalls nahezu verzögerungsfrei schalten kann. Danke.
-
Dem Shelly ist es egal, ob er hinter einem Schalter oder Taster sitzt. Ich würde Taster bevorzugen. Bei einer Wechselschaltung lassen sich eher Shellies mit Tastern realisieren.
-
Um HP-IP allgemein.
Ich habe als Reverenz jedoch nur Fensterkontakte und die Displaytaster. Die Fensterkontakte benötigen länger zum Senden, die Displaytaster vermutlich bis zu einem Update X ebenfalls. Ich war davon ausgegangen, dass die Verzögerung der Taster immer noch besteht.
Wenn du bei anderen Tastern bestätigen kannst, dass diese auch nahezu Verzögerungsfrei schalten lassen, dann ist es kein Problem (mehr) und ich habe mich durch die Fensterkontakte und irreführen lassen. Ich habe die Taster direkt bei Erscheinen bekommen, vielleicht war die Firmware da noch nicht ausgereift, zumindest habe ich größere Verzögerungen am Schreibtisch in Erinnerung.
-
Mit dem Schalten des Lampendrahts zwischen BWM und Leuchte hast du natürlich recht, das sollte beachtet werden. Oder man sagt sich, dass die LED 1x am Tag mehr eingeschaltet weniger Strom als der Bewegungsmelder den halben Tag verbraucht.
-
Wir kennen die Gegebenheiten nicht. Idealerweise passt der Shelly in den Bewegungsmelder, wo L/N vorhanden ist und du Schaltest die Phasen vor dem Bewegungsmelder per Sunrise/Sunset.
Bitte bedenke, dass die Installation durch eine Elektrofachkraft erfolgen muss.
-
Du meinst das Logging, welches über das Web-UI abrufbar ist? Hast du es denn aktiviert? Als Hinweis steht, dass man es nicht grundlos aktivieren soll.
-
Ich hoffe, dass es nicht zu OffT ist, aber kannst du sagen über welchen Weg? Funktionieren Gen1 nun auch ohne CoIoT? Ich habe leider noch keine Gen2 zum Testen.
-
Dann wäre auch mein nächster Versuch ein Bypass oder zu versuchen einen (von selben LS-Schalter) zu bekommen. Hierfür darf NICHT der Grün/Gelbe verwendet werden, bevor du auf die Idee kommst, da es eventuell die einzig "freie" Ader sein wird.
-
Es sind lediglich die 3 gezeigten im Einsatz, 1er pro Entnahmestelle für Warmwasser.
Bei diesen muss man bei der Programmierung tatsächlich aufpassen. Ich habe erst immer den kompletten Text, alle 5 Zeilen, geschickt und mehr Ausgaben des Status. Da merkt man ziemlich schnell, dass der DC am Ende ist.
Man muss nur die Zeile ändern, die sich tatsächlich ändern muss und überlegt sich dementsprechend Texte, bei denen möglichst viel stehen bleiben kann und reduziert die Ausgaben auf ein Minimum.
Aber auch hier erschien es mir vorhin so, als ob der DC trotz häufigeren Probierens nicht so stark wie bei Markteinführung belastet wurde. Mag täuschen, da es schon länger her ist, ist aber mein Eindruck.
Die Aktualisierung hält sich in Grenzen, da die Taster für Warmwasser wenig gebraucht werden, da habe ich schon drauf geachtet, um den DC gering zu halten.
Ich habe allerdings viele "Thermometer" die häufiger die Temperatur übermitteln als z.B. ein Schalter etwas sendet, daher ist es wahrscheinlicher, dass es eine Verzögerung gibt.
Bei den Tätern ist es echt fix, also wurde verbessert, ohne dass ich es mitbekommen habe, die Fensterkontakte sind für mich jedoch häufiger sichtbar, vor allem in der Verzögerung und somit habe ich die Verbesserung nicht mitbekommen. Aber dennoch hatte ich es vorhin 2x, dass ich geschätzt 2 Sekunden warten musste. Jetzt gerade nochmals probiert, der Taster wurde länger nichts genutzt, lief anscheinend wieder recht fix, vielleicht gibt es die Verzögerungen tatsächlich nur noch, wenn gerade jemand anderes sendet, zumindest ist es so, dass die Taster in Vergangenheit länger geblinkt haben (ca. 2 Sekunden), was ich jedoch nicht explizit beobachtet hatte.
Ich hätte es schön gefunden, wenn sich jemand gemeldet hätte, der es für Licht im Einsatz hat, da man es dort direkt merkt. Meinen Fensterkontakt darf ich somit nicht mehr als Referenz für die Schalter nehmen.
-
unterstützt Shellies der ersten und zweiten Generation "Out-Of-The-Box"
Moin,
über welchem Weg die Gen2? Gab es ein Update oder meinst du über die inoffizielle Integration aus dem HACS? Die habe ich nicht ans laufen bekommen oder gibt es inzwischen etwas aktuelles. Wenn ja, wie wird es realisiert?
-
Ich habe noch einen Versuch gemacht und die Displaytaster 2 Meter von der Antenne positioniert. Übertragung ging fix, eventuell werden weniger Daten als bei den Fensterkontakten übertragen. Demonstrieren soll es, dass aufgrund einer Systemvariable die Anzeige geändert wird, dieses jedoch Display nach Display geschieht und nicht gleichzeitig. Gruppen lassen sich in HM, jedoch meines Wissens (noch) nicht in HM-IP anlegen. Sprich Abarbeitung erfolgt der Reihe nach, was je nach Empfangsqualität dauern kann.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. Ich hatte die Seitenangabe fälschlicherweise von schote übernommen und auf dem Handy nicht wahrgenommen, dass da ein Seitenumbruch ist, da ich die Stelle gleich gefunden hatte. Wenn das nun schon ein Aufreger ist... man könnte auch einfach das Kapitel lesen, die Seiten sind ja nun wirklich nicht umfangreich...
Mit dem Lesen schieße ich lediglich zurück, da mir dieses von dir unterstellt wurde. Aber wenn du es schreibst, dann scheint es etwas anderes zu sein...
Ob überlesen oder ignoriert interessiert mich nicht mehr..
Ich habe es gelesen. Aber anstatt zu vermuten und drauf loszupreschen hätte man z.B. um Tests bitten können, anstatt einen gleich anzugehen und das Thema mit nicht treffenden Titel zu verschieben, wobei gegen die Ausgliederung selbst nichts einzuwenden ist. Es macht aber auch die Art, in welcher Weise die Gegenreaktionen erfolgen.
Es hat nichts mit Selbstüberzeugung zu tun, sondern damit, dass von Dir keine Fakten kamen sondern lediglich Vermutungen.
Darum schreibe ich auch weiter oben, dass es den Anschein hat, als wenn die Taster weniger Daten übertragen und schneller reagieren, da ich es jetzt daraufhin nochmals getestet habe. Die waren bei meinen ersten Tests bei Installation ähnlich träge wie die Kontaktschalter. Hier scheint Homematic reagiert zu haben und hat dieses beschleunigt (zwischenzeitlich gab es mindestens 1 Update für die Displaytaster, ich hatte jedoch nur auf die Geschwindigkeit des Textwechsels geachtet und keinen Unterschied bemerkt), die Kontaktschalter blieben jedoch bei der Übertragungsdauer, daher ist mir die Änderung nicht aufgefallen, da ich nicht damit gerechnet habe, dass die Statusmeldung anscheinend nur bei den Tastern beschleunigt wurde.
Dennoch konnte ich beobachten, dass an nicht optimalen Stellen und wenn die Taster anscheinend länger kein Traffic gehabt haben, die Übertragung länger dauert, sprich beim ersten Mal Tasten nach Pause scheint die Verzögerung bei ca. 2 Sekunden zu sein. Dieses bekomme ich aber jetzt nicht mehr ausführlicher getestet, wäre dennoch bei einem Lichtschalter störend. Da die Taster täglich genutzt werden sehe ich ja, dass diese länger blinken, ob gelegentlich oder öfter muss ich künftig beobachten.
Wie geschrieben, ich lerne gerne dazu, jedoch mag ich deine überhebliche Art nicht und habe dann dementsprechend auch einen anderen Ton.
-
Die nächste Core-Version (2021.10.0) unterstützt Shelly Plus- und Pro-Geräte
Das wäre noch meine Hoffnung, dass es dann ohne CoIoT geht und es eine passende Implementierung für Shelly gibt, die Gen1 und Gen2 ohne CoIoT unterstützt. So lange werde ich bei MQTT bleiben.
Weißt du da mehr?
Ich weiß nicht, wer sich worauf stürzen wird. Nur für mich macht es derzeit keinen Sinn sich festzulegen. Ich werde es erst wieder probieren, wenn beides offiziell unterstützt wird. Wie geschrieben, ich nutze Node Red mit MQTT und habe keinen Zugzwang.
Von der Pflege, die man selbst betreiben muss, erscheint mir Homeassistant jedoch bisher am einfachsten, da alles direkt über das Web-UI upgedated werden kann. Die Pflege von Linux-VMs nervt mich, da ich von Linux nicht viel Ahnung habe und bei jedem Updateproblem googeln muss und ich erstmal per SSH drauf muss. Da ist ein Web-UI einfacher.
Grundsätzlich finde ich es also bisher gar nicht so schlecht, muss mich aber weiter mit beschäftigen. Geplant ist es Node Red (neben anderen Plugins/Add-Ons) in Homeassistant laufen zu lassen.
Ich wollte lediglich meine Bedenken kundtun. Inwieweit diese für den einzelnen relevant sind muss jeder für sich entscheiden.
-
Hast du wirklich gelesen, was ich geschrieben habe? Die Verzögerung von Node Red ist mit bloßem Auge nicht feststellbar, es dient lediglich der besseren Erkennbarkeit. Weiteres dazu nach dem nächsten Zitat.
Da ich HM nicht nutze, kann ich nicht sagen, welches schneller ist. Ich schrieb bereits, dass die Datenübertragung von HM-IP sehr langsam ist und das innerhalb der CCU unterschiedliche Hardware für HM und HM-IP zuständig ist (auch bei Raspberrymatic muss man aufpassen, dass man das Modul kauft, welches man benötigt), von daher vermute ich, dass die beiden Systeme so gar nicht vergleichbar sind, was ich bereits schrieb.
Wir müssen leider unterschiedliche Anleitungen haben:
Ich schrieb extra "unten auf der Seite". Dort findest du eine Tabelle, die das blinken beschreibt. Also erkläre ich es nochmals, da du meinen Beitrag offensichtlich nicht gelesen hast.
Der Kontakt blinkt = Daten werden übertragen
Langes leuchten = Datenübertragung erfolgreich, zeitgleich, ohne Verzögerung, schaltet das Licht an, um diesen Punkt deutlicher darzustellen (keine Verzögerung durch Node Red!!!).
Ersteres ist meiner Meinung nicht abzukürzen, bestenfalls durch optimalen Empfang vielleicht etwas, aber dann wäre die Antenne direkt neben den Kontakt und die Datenmenge bleibt, dürfte nicht merklich etwas ausmachen.
Zu Threads in BBezug zu der Verzögerung schrieb ich bereits, dass es keine Anfragen gibt, wenn es als technisch gegeben hingenommen wird, so wie ich es mache und aufgrund der blinkenden LEDs ist es nachvollziehbar. Zudem werden die meisten HM-IP Anlagen vermutlich, wie bei mir, reinweg für die Heizung sein, wo es egal ist, ob das Heizungsventil 3 Sekunden später schließt oder öffnet. Selbst bei den direkten Verknüpfungen gibt es diese Verzögerungen.
Deine Anfrage richtete sich explizit an den Duty-Cycle im Vergleich HM zu HM-IP, also eigentlich am Thema vorbei, daher bekommst du darauf keine Antworten, die zu diesem Thema hier passen.
HM-IP hat für die Heizkörperregelung meiner Meinung nach seine Daseinsberechtigung, da hier eine Verzögerung egal ist. Allerdings wurde dann schleppend versucht (wenn ich bedenke, wie lange ich nach Vorbestellung auf meine Taster gewartet habe) noch anderes mit HM-IP zu realisieren. Die Taster nehme ich um unsere Zirkulationspumpe für das Brauchwasser einzuschalten. Auch da ist eine Verzögerung von ein paar Sekunden egal. Die Textänderungen der Displays dauern sogar so lange, dass ich von ein in den anderen Raum laufen könnte, um die Änderung zu verfolgen, da eben nur ein Empfänger nach dem anderen angesprochen werden kann, aber nicht zeitgleich.
Ob da dann HM ins Spiel kommt, da es eventuell schneller mehr Daten oder zeitgleich mehrere Geräte ansprechen kann, kann ich nicht beurteilen.
Wie geschrieben, ich lasse mich gerne von anderem überzeugen, aber dann darf dieses nicht auch Vermutungen basieren.
-
Dass er auch für Homeassistant stimmt.
Ich habe es derzeit testweise laufen Die Gen1 per CoIoT mag gehen, teste ich aber nicht, da sie Gen2 der Shellies es nicht kann. Wotu ezwas anfangen, was abgeschafft wird. Mit dem Plugin aus der Community konnte ich leider nichts anfangen, da bin ich wohl zu blöd für und der Weg zur Installation war für mich, der recht überfahren ist, sehr steinig.
Noch bin ich bei Node Red und nutze die Shellies per MQTT bzw. HTTP.
Diagramme sind im Dashboard begrenzt, da soll Grafana als Ergänzung gut sein.
Homeassistant hat ein Plugin für Node Red. Super ist, dass man da kein Betriebssystem per SSH pflegen muss, negativ finde ich derzeit das Rollback von Homeassistant. Ich lasse beides als VM auf der Synology laufen. Theoretisch ist Homeassistant super, da alle Updates über die UI laufen (samt Betriebssystem) und Node Red als Plugin läuft. Mache ich nun ein Rollback, da ich in Node Red etwas versaubeutelt habe, dann wird die ganze Homeassistant Installation zurückgesetzt werden müssen, die ebenfalls Grafana enthalten kann (Datenbanken der Diagramme kann man sicherlich auslagern). Zudem ist man auf die Pflege von Node Red für Homeassistant angewiesen, was anscheinend nur einer macht. Hat der keinen Bock mehr, dann steht man eventuell ohne Updates da. Dafür hat man kein Linux zu pflegen.
Von den Möglichkeiten finde ich Node Red gut, man muss sich allerdings mit den Nodes beschäftigen, welcher wie zu kombinieren ist.
-
Zumindest meine Displaytaster brauchen auch so lange. Wenn er eine Lösung haben sollte, dann wäre es nett, wenn er diese nicht für sich behält. Es kam aber noch nichts definitives, außer dass er in Foren nichts diesbezüglich gelesen hat. Ich z.B. habe keine Frage diesbezüglich erstellt, da mir aufgrund der Funktionsweise eine Verzögerung üblich erscheint. Sehen das alle so, dann wird auch keine Frage dazu erstellt werden oder es läuft bei allen anderen tatsächlich schneller oder es wird kaum als Lichtschalter eingesetzt (ich nutze es eigentlich auch nur für die Heizung und binde die Fensterkontakte in Node Red ein. An der Haustür stört mich die Verzögerung nicht, bricht jemand ein und ich bin nicht zu Hause, dann sind 3 Sekunden auch nicht entscheidend).
Auf Seite 21 unten steht, was ich geschrieben habe und im Video zu sehen ist. Die Funkübertragung dauert (blinken) und dann wird das Außenlicht zeitgleich (vielleicht sogar noch etwas früher) mit dem längeren Leuchten als Quittierung eingeschaltet, sprich der Sender kann seinen Status nicht schneller übertragen und somit ist die Verzögerung meiner Ansicht nach vorprogrammiert.
Beim Empfang scheinen die Daten deutlich geringer zu sein und es geht axhneller, aber bei einem Lichtschalter geht es ja ums senden.
