Beiträge von Schubbie

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.

https://youtu.be/XiAMfBmYCOU

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.

https://www.google.com/url?q=https://…cWaXyQ5EMWvXTzV

Vielleicht lohnt es sich für den TE auf den Shelly i4 zu warten.

Schade, dass es noch keine Antwort zu der Verzögerung gab und hier, sowie auch in dem Homatic-Forum, schon beim Titel falsch begonnen wurde und mir damit unterstellt wird, dass ich gesagt hätte, dass Homematic-IP den Duty-Cycle in die Höhe treibt, wobei ich nur von einer Verzögerung sprach, die für Lichtschalter ungünstig ist, welche daraus resultiert, dass die Übertragung langsam ist (Entfernung zur CCU spielt auch eine Rolle), nicht alle Geräte gleichzeitig "sprechen" können und der Duty-Cycle gering gehalten werden soll.

Na ja, macht man so weiter...

Bei mir befindet sich ebenfalls ein 1PM im Außenbereich. Dieser sitzt in einer AP Taster-/Steckdosenkombination. Er hält es sich durch die Abwärme selbst etwas warm, daher habe ich keine Bedenken. Bedenklicher wäre es bei direkter Sonneneinstrahlung und wenn die Elkos ständig hohen Temperaturen ausgesetzt sind.

Robert_M. Du hast aber kein übergeordnetes System o.ä., welches Updates anstößt und du vergessen hast?

j.c.w. wie groß sind denn deine Verzögerungen?

Ich schrieb, dass ich 2-4 Sekunden für nicht hinnehmbar halte, jedoch nicht, dass es die Regel ist, es kommt jedoch des Öfteren vor. Ich habe halt einige Teilnehmer, die funken wollen.

Der von mir verlinkte Beitrag beschreibt, wie man dieses verkürzen kann und was man nicht tun sollte, um Kollisionen zu vermeiden - aber wurde ja sicherlich ebenfalls gelesen.

SW und L von selber Phase oder lagen dort 400V an?

Gut, also ist die Verzögerung von dir bestätigt. Würdest du mit der Verzögerung auch leben wollen, wenn es sich um einen Lichtschalter handelt? Das ist das einzige, worum es mir geht und weshalb ich grundsätzlich von dem Einsatz für Lichtschalter abrate. Wenn man es dennoch nutzen will, muss man sich dessen bewusst sein.

Ich kann es allerdings nicht für allgemeingültig hinnehmen, dass es keine spürbare Verzögerung gibt und wenn, dann eine fehlerhafte Programmierung unterstellt wird.

Anders gefragt, und um das geht es mir auch, wie wahrscheinlich ist es, dass man beim Druck auf einen HM-IP-Schalter eine Verzögerung der Meldung hat?

Ich selbst nutze HM-IP fast ausschließlich für die Heizung, daher ist es mir persönlich wurscht.

Um es nochmals deutlich zu sagen, mir geht es um die Verzögerung die mit HM-IP einhergeht, um den Duty-Cycle möglichst gering zu halten und Kollisionen zu vermeiden.

Es geht mir nicht darum, dass der Duty-Cycle bis zum Maximum ansteigt. Mein Duty-Cycle ist ebenfalls gering, je nach Nutzung höher, was sich auch durch andere Programmierung nicht ändern lässt, da die Daten benötigt werden.

Hier noch etwas zu meinen allgemeingültigen Aussagen, die anscheinend nur bei mir zutreffend sind:

https://technikkram.net/blog/2019/03/0…ors-verkuerzen/

Man kann es verkürzen, muss aber ggf. mit Problemen rechnen.

Geschuldet ist die Verzögerung auch, da bei HM-IP (HM habe ich nicht) nur 1 Gerät zur Zeit funken darf, bzw. angefunkt wird. Gebe ich auf meine Status-Displays einen Text, dann werden alle nacheinander angesprochen und nicht alle gleichzeitig als Gruppe.

Daher sind Schalter aus HM-IP für Licht aus meiner Sicht ungeeignet, da die Verzögerung zu groß ist. Hier im Forum werden ja allein schon die kleinen Verzögerungen von den Dimmern bemängelt, welches auch nicht nur meinem Empfinden entspricht.

Wenn man falsch programmiert und ständig funken lässt, dann kann man natürlich den Duty-Cycle künstlich erhöhen, was jedoch nicht das Ziel sein sollte.

Verbaut ihr Schalter und sonstiges für Beleuchtung und werdet glücklich. Ich für mich weiß, dass es nicht zufriedenstellend laufen wird, egal wie man es programmiert, so lange man die Begrenzung nicht aushebelt. Ich sehe es jeden Tag an meiner Haustür und immer wenn ich ein Fenster öffnen und dabei auf die Thermostaten gucke.

Wenn man falsch programmiert und ständig funken lässt, dann kann man natürlich den Duty-Cycle künstlich erhöhen, was jedoch nicht das Ziel sein sollte.

Verbaut ihr Schalter und sonstiges für Beleuchtung und werdet glücklich. Ich für mich weiß, dass es nicht zufriedenstellend laufen wird, egal wie man es programmiert, so lange man die Begrenzung nicht aushebelt. Ich sehe es jeden Tag an meiner Haustür und immer wenn ich ein Fenster öffnen und dabei auf die Thermostaten gucke.

Nein, 1 Taster reicht, jedoch könnte man einen Serientaster für "auf" und "ab" installieren.

Ich war davon ausgegangen, dass die Leuchtmittel ersetzt werden, was für den Dimmer zwingend erforderlich wäre.