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.
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.
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.
Magst du es bitte kurz beschreiben, wie es anzuwenden ist. Ich mache es per MQTT oder HTTP. Eine andere Lösung für Node Red würde mich interessieren.
Nein, er will es nicht wahrhaben, dass es eine Verzögerung bedingt durch HM-IP gibt, da er es mit HM nicht nachstellen kann und mich dazu bewegen, dass ich den Usern nicht schreibe, dass ich von HM-IP als Lichtschalter aufgrund meiner Erfahrungen abrate. Ich habe nie um Hilfe gebeten. Es geht einfach nur um meine Aussage, dass es zu Verzögerungen durch HM-IP kommt, die ihm nicht passt.
Aber vielleicht könntest du einen Link zu der Anleitung posten und schreiben, wo in der Anleitung es zu lesen ist.
Ich nehme an von einen externen Sensor?
Ist die gewünschte Temperatur in dem String enthalten, wenn du
[Shelly-IP]/Status
im Browser eintippst? Dann könntest du z.B. minütlich per HTTP abfragen und dann z.B. per Function-Node parsen.
Gib Mal die Ausgabe und markiere benötigtes.
Ich habe damit kein Problem. Die Diskussion wurde aus einem Thema verschoben, in dem es darum ging, einen Schalter zu finden. Dort hat 66er HM und HM-IP ins Spiel gebracht, wobei HM aufgrund benötigen N-Leiters nicht möglich ist und ich dann aufgrund meiner Erfahrung (also diese hier) von HM-IP als Schalter abgeraten habe. Um mehr geht es hier nicht. Es geht schlicht darum, dass ich davon abgeraten habe aber 66er der Meinung ist, dass die Verzögerung nicht üblich ist.
Korrekt, du siehst es falsch. Ich habe extra im letzten Absatz (ich dachte) eindeutig geschrieben, dass die Verzögerung nicht durch Node-Red kommt und beschrieb es extra mit dem Inject-Node. Das zeigt mir, dass du wieder nicht vollständig liest, bzw. nicht folgen willst, und direkt dein Urteil bildest, ohne den Sinn verstanden zu haben. Du siehst einfach nur, das da was sein könnte, wobei ich noch extra beschrieben habe, dass der Kontakt während der Übertragung blinkt. Man sieht auch, dass sofort geschaltet wird, wenn der Kontakt signalisiert, dass die Übertragung erfolgreich war.
Ich habe das gewählt, da ich schlecht meinen PC neben den Fensterkontakt bekomme, um ein Video zu machen... Ich kann es aber mit einem zweiten Smartphone probieren, welches das UI der Raspberrymatic anzeigt, aber dann wird vermutlich gesagt, dass der Browser Zeit für die Aktualisierung benötigt.
Eben, da (fast) niemand nach einem Tastendruck auf das Licht warten will, ist es für mich keine Lösung.
Mag sein, dass es leicht als Allgemeingültig aufgefasst wird, da ich nur von den Systemen sprechen kann, die ich selbst kenne und das sind die in unserem Haus. Daher resultiert, dass ich schlecht über anderes schreiben kann, was keinen Sinn hätte, wenn ich es nicht kenne.
Ist es denn nun allgemeingültig, dass es keine Verzögerung gibt? Denn so lesen sich hier andere Beiträge.
Der Versuch es durch Dritte beurteilen zu lassen war nichts, da du dort lediglich deine fehlerhafte Interpretation hinterfragt hast.
Mir geht es, so wie ich immer schreibe, um die Verzögerung, welche durchaus mit dem Duty-Cycle und der Übertragungsgeschwindigkeit zusammen hängt.
Meiner Kenntnis nach werden Befehle der Reihe nach abgearbeitet (ich stelle es mir dabei wie bei CB-Funk vor, es kann nur einer sprechen).
Die Übertragungsgeschwindigkeit ist sehr langsam, was eindrucksvoll durch die Updates der HM-IP Geräte demonstriert wird. Ein paar Kilobyte benötigen mehrere Stunden.
Zu guter Letzt der Duty-Cycle. Ist dieser erschöpft, dann muss gewartet werden und es sind sicherlich Vorkehrungen getroffen, um diesen gering zu halten.
Du schreibst in der Frage jedoch (und auch hier im Titel), dass ich sage, dass der Duty-Cycle bei HM-IP eher als bei HM ausgelastet wird, was ich jedoch nie behauptet habe und aufgrund fehlender Hardware auch gar nicht beurteilen kann (Meine Zentrale hat gar kein Modul, um sich mit HM untehalten zu können, spirch es handelt sich um unterschiedliche Systeme, bei denen ich nicht weiß, in wie weit die überhaupt vergleichbar sind). Die Frage beruht lediglich auf einer Fehlinterpretation von Dir.
An meiner Haustür (HM-IP Fensterkontakt zu Raspberrymatic über Node-Red zum Shelly 2.5, der das Licht schaltet) sind es in der Regel 2-4 Sekunden, die ich auch nicht durch Einstellungen reduzieren kann (die Einstellung gibt es nicht für alle Teilnehmer, bei mir für kaum einen). Die Verzögerung kommt durch den Fensterkontakt, da der Zeit zur Übertragung benötigt. Andersrum kann ich allerdings auch meine HM-IP-Aktoren an der Heizung, welche an Netzspannung hängen, über die Oberfläche der Raspberrymatic verzögerungsfrei schalten, sofern der Duty-Cycle es zulässt, aber das ist halt die andere Richtung und vielleicht macht es einen Unterschied, dass die nicht batteriebetrieben sind.
Da ich 2-4 Sekunden bei einem Lichtschalter für nicht hinnehmbar halte, ist es aus meiner Sicht korrekt ausgedrückt.
Ich habe nie bestritten, dass der Duty-Cycle eine Verzögerung verursachen kann und diese ist auch so, nur habe ich nie geschrieben, dass HM-IP diesen in die Höhe treibt. Das hast du, wie auch immer, aus irgendetwas interpretiert, was ich nicht nachvollziehen kann.
Hättest du gefragt, ob HM-IP Schalter gegenüber HM Schaltern (häufig) eine höhere Verzögerung haben und wie groß diese Verzögerungen sind, dann hätte ich nichts dagegen einzuwenden gehabt, jedoch unterstellst du mir in dem anderen Foren Aussagen (die ich zudem auch noch ständig getätigt haben soll, so wie es sich liest), die ich so nie getroffen habe und da kräuseln sich mir dann die Nackenhaare.
Vielleicht muss man nicht alles geschriebene als allgemeingültig ansehen und hat man andere Erfahrungen gemacht, dann teilt man diese mit. Soweit ich es rauslesen konnte, vergleichst du es jedoch mit HM, was ich nicht beurteilen kann, da ich ausschließlich HM-IP nutze, und du scheinst keine HM-IP Taster zu haben, ansonsten hättest du es sicherlich bereits geschrieben und mich des Gegenteils überzeugt.
Ich mache mal ein kurzes Video meiner Haustür. So lange der Fensterkontakt blinkt, überträgt er seinen neuen Status, sprich früher kann gar nicht geschaltet werden. Setze ich einen Inject in Node-Red, dann wird sofort geschaltet, sprich an der Programmierung liegt es nicht. Auch an falschen Programmen in Homematic wird es nicht liegen, da ich dort fast ausschließlich direkte Verknüpfungen habe sowie 2-3 recht einfache Programme, die die meiste Zeit nichts tun.
Wenn mir jemand darlegen kann, dass das Verhalten meiner Anlage nicht normal ist (HM-IP Fensterkontakte und meine Displaytaster benötigen je nach Umständen (Signalqualität. Funkauslastung...) ca. 1-4 Sekunden, bis der Befehl an der Raspberrymatic bzw. CCU ankommt), dann würde ich mich auch die Suche machen, um dieses zu beheben.
Stattdessen wird hier ein anderer Anwendungsfall, vermutlich in andere Richtung, beschrieben und dann auch mit Homematic anstelle von Homematic-IP. Wenn beides gleich sein soll, dann frage ich mich, warum innerhalb der CCU und auch für Raspberrymatic für beides unterschiedliche Hardware benötigt wird.
So kann ich weiterhin nur von meiner Erfahrung mit Homematic-IP schreiben, da mir noch niemand darlegen konnte, dass das Verhalten meiner Anlage nicht normal ist und daher empfehle ich dann nicht den Einsatz von Homematic-IP Tastern für Licht, bei Homematic (ohne IP) kann es anders sein, kann ich jedoch nicht beurteilen.
Auch sage ich nicht, dass meine Regelung nun super ist. Ich berichte darüber, was die kann. Andere Systeme werden das auch können und Thebentheserva (oder so ähnlich) kann glaube ich die Wettervorhersage mit einbeziehen, was für eine Fußbodenheizung nicht schlecht sein soll, aber da muss man Kosten, Nutzen und Aufwand abwägen. Eher rate ich davon ab, dass man nur mit Shelly aufgrund der aktuellen Temperatur seine Fußbodenheizung regeln möchte und hier die Trägheit außer acht lässt. Kommt das falsch rüber, dann gebe mir da an passender Stelle bitte bescheid. Es kann jeder nur von dem berichten, was er kennt.
Die Diskussion über SELV war tatsächlich haarsträubend und hat vielleicht mit dazu beigetragen, dass die Isolationsabstände im Shelly 1 Plus entsprechend vergrößert wurden.
Ich für mich kann nur sagen, dass ich den Titel dieses Themas nie so gewählt hätte, da es mir schlichtweg um die Verzögerung geht und ich das DC für Homematic (ohne IP) gar nicht beurteilen kann, da ich mich mit dem System nie beschäftigt habe.
Edit: habe ich nicht wegen Dir meinen Heizungsverteiler umgebaut? Ist ja nicht so, dass ich keine Tipps annehme, die beiläufig entstehen.
Ich wäre da auch bei einem RC-Glied. Von Eltako gibt es ein 3-fach-Glied. Es ist zwar verhältnismäßig teuer, sieht dafür gut in der Verteilung aus.
Vielleicht lohnt es sich für den TE auf den Shelly i4 zu warten.
