Quote.. doch das geht - zumindest bei den HKT der 1. Generation. Nach einem langen Druck ( 3 Sekunden) auf die TASTE laufen verschiedene Parameter im Display durch:
- Öffnungsgrad in %...
Richtig, hatte ich schon vergessen, da ich inzwischen auf hm umgestiegen bin. Dort geht es übrigens auch nicht direkt am HKT oder in der CCU (hab da zumindest noch keine Möglichkeit gefunden), aber über iobroker ist alles zugänglich. Über diesen Zufang kann man den Öffnungsgrad sogar direkt beeinflussen.
Und trotzdem: auch wenn der Absolutwert der Temperatur in Raummitte sicher nicht genau mit dem angezeigten Wert des HKT übereinstimmt, die Korrelation ist da und Schwankungen von 3°C nicht damit erklärbar. Es handelt sich auch nicht um Zweipunktregler sondern mindestens um P-, ich nehme sogar an, um PI oder PID-Regler. Leider kann man den aktuellen Öffnungsgrad nicht auslesen (wie bei HMIP), aber man hört ja zumindest, dass der Motor häufig arbeitet, um kleine Verstellungen durchzuführen. Meine Erfahrung war, dass die (angezeigte) Temperatur so um ca. +/- 0,5°C um den Sollwert schwankt, mehr nicht.
Zu dem Thema hatte ich an anderer Stelle bereits mal etwas geschrieben:
QuoteIch hatte in der Vergangenheit auch ein paar mal Rauchalarm. Gemeinsames Kennzeichen: Immer exakt 3 Sirenentöne (also wie beim Test durch Drücken der Taste) bei allen 8 Rauchmeldern (2. Gen.). Auslöser meist der gleiche Rauchmelder. Habe ich desöfteren ausgesaugt, einmal sogar das Siebblech geöffnet, von Insekten oder anderen Fremdkörpern keine (sichtbare) Spur. Letzlich wieder einmal so ein Ereignis, diesmal aber ein anderer Auslöser. Was dabei auffiel: Der Alarm erfolgte exakt zeitgleich mit dem Anlernen eines hmip-Schaltaktors (ich habe inzwischen fast komplett auf hmip umgestellt, außer eben die Rauchmelder) in ca. 2 m Entfernung vom auslösenden Rauchmelder !! Ich nehme daher an, dass "Fehlalarme" meist gar nichts mit Fremdkörpern in der Rauchkammer zu tun haben, sondern beispielsweise durch Funkstörungen ausgelöst werden können.
An fehlerhaften Szenarien kann es bei mir definitiv nicht gelegen haben, da (wegen Umstellung auf homematic) gar keine mehr aktiv waren.
und das funktioniert da perfekt.
Nö, bis jetzt alles ok. Allerdings kann man jede Menge Fehler selbst einbauen und die Aufklärung ist nicht immer einfach. So ein hilfsbereites Forum wie dieses hier (und das "alte" rwe-smarthome-forum schließe ich da ausdrücklich mit ein) gibt es dort leider nicht. Man muss dort schon sehr präzise fragen und bekommt nicht für alle Fragen eine befriedendige Lösung, auch weil einige der äußerst vielfältigen Möglichkeiten von eq3 schlicht nicht dokumentiert sind und alle nur rätseln und vermuten.
Ich denke, bei Livisi sind sicher auch eine Reihe von Problemen, die scheinbar von der Hardware oder den Bedingungen vor Ort (angebliche "Verbindungsfehler") verursacht werden, auf die Software zurückzuführen. Z.B. "Verbindungsfehler" bei Wandschaltern und Rollladenaktoren: Nach meiner Erkenntnis treten die immer dann auf, wenn die Zentrale durch andere Prozesse stark belastet ist, d.h., nicht die physikalische Erreichbarkeit ist gestört sondern die Zentralen-SW kommt quasi nicht dazu, rechtzeitig die Verbindung zu prüfen/zu bestätigen. Z.B. beim Abspeichern/Senden mehrerer Szenenänderungen im Backend (sehr gut auch bei den Rauchmeldern zu beobachten.) Und anstatt es später noch einmal zu probieren, wird der Status "Gerät nicht erreichbar" "eingemeißelt".
Jeder kann natürlich seine Prioritäten anders setzen. Für mich war entscheidend, dass ich nicht erst zum Tag X gezwungen bin,
- mich nach einem neuen System umzusehen
- das neue System kennen- und verstehenzulernen
- die Vorteile des neuen Systems nutzen zu lernen (bzw. Nachteile zu umgehen)
- evtl. Lieferengpässe zum Tag X zu vermeiden.
Sinn einer smarthome-Installation ist für mich die Automatisierung von Prozessen durch Verknüpfung mit unterschiedlichen Einflussgrößen, wie z.B. Rollladensteuerung in Abhängigkeit von Außentemperatur, Sonnenstand, Tageszeit, Türöffnung ... Für das einfache Schalten von Lampen oder das Öffnen und Schließen von Rollladen per Knopfdruck ist es sinnlos.
Daher habe ich schon vor ca. 2 Jahren (als wieder mal die Rollladenschalter Probleme machten) angefangen, parallel eine Homematic-Installation (PIVCCU3+ioBroker auf Raspberry Pi 4) aufzubauen, aber immer so, dass beide Systeme über ioBroker kommunikativ verbunden sind. Inzwischen habe ich die letzten Livisi-Geräte ersetzt und die Zentrale abgeschaltet. Die Einarbeitung in die CCU-Programmierung (Geräte sind ausschließlich hmip) ist doch nicht so einfach - auch im Vergleich zu Livisi, sofern man die systemspezifischen Vorteile (z.B. virtuelle Kanäle, Direktverknüpfungen zwischen Geräten etc.) nutzen möchte. Andererseits bietet das aber eine Reihe von Möglichkeiten, auf die ich bei Livisi immer gehofft hatte. Und entscheidender Vorteil: Kein Cloud-Anbindung mehr ! Gerade heute früh war das Internet wieder mal für ca. 1h ausgefallen und alles war ohne Abstriche erreichbar und bedienbar.
Das geht dann aber mit iobroker o.ä. deutlich einfacher.
Ich hatte in der Vergangenheit auch ein paar mal Rauchalarm. Gemeinsames Kennzeichen: Immer exakt 3 Sirenentöne (also wie beim Test durch Drücken der Taste) bei allen 8 Rauchmeldern (2. Gen.). Auslöser meist der gleiche Rauchmelder. Habe ich desöfteren ausgesaugt, einmal sogar das Siebblech geöffnet, von Insekten oder anderen Fremdkörpern keine (sichtbare) Spur. Letzlich wieder einmal so ein Ereignis, diesmal aber ein anderer Auslöser. Was dabei auffiel: Der Alarm erfolgte exakt zeitgleich mit dem Anlernen eines hmip-Schaltaktors (ich habe inzwischen fast komplett auf hmip umgestellt, außer eben die Rauchmelder) in ca. 2 m Entfernung vom auslösenden Rauchmelder !! Ich nehme daher an, dass "Fehlalarme" meist gar nichts mit Fremdkörpern in der Rauchkammer zu tun haben, sondern beispielsweise durch Funkstörungen ausgelöst werden können.
Ich bin gerade beim Wechsel zu hmip (mit CCU3). Ich hatte schon bei innogy ein Szenario, dass unter bestimmten Bedingungen (Helligkeit, alle Rollladen noch zu, Uhrzeit) beim Öffnen eines Fensters zum Lüften die Rollladen hoch fahren ließ. Das hat immer ohne Verzögerung funktioniert. Mit hmip ging das anfangs ebenso schnell. Nun habe ich auch die Heizkörperthermostate getauscht und da werden bei hmip beim Anlernen automatisch Direktverknüpfungen zu den im Raum vorhandenen Fenstersensoren erstellt. Und nun gibt es beim Öffnen der Rollladen auch so eine merkliche Verzögerung. Ursache ist offenbar, dass zuerst die Direktverknüpfungen bedient werden und dann die Zentralenprogramme. Ist bei Dir evtl. auch die Temperaturabsenkung aktiviert ? Ich bin mir allerdings nicht sicher, ob diese bei livisi auch mittels Direktverknüpfung realisiert ist.
Homematic IP unterstützt die Steuerung von maximal 80 Geräten, fällt also raus,
Das gilt nur für die cloudbasierte Lösung mit Access Point. Vernünftig ist aber ohnhin nur der Betrieb an einer CCU3, wenn man nicht wieder in die permanente Abhängigkeit von einer Cloud geraten will. Ich hab schon mal angefangen und z.B. die Rollladenaktoren auf hmip umgerüstet und über iobroker mit dem innogy-Gesamtsystem verbunden - klappt hervorragend.
Bei iobroker kommt es ebenfalls vor, dass die Verbindung zum innogy-Adapter abreißt. Neustart des Adapters hilft dann. Ich hab das schon vor geraumer Zeit automatisiert: In regelmäßigem Abstand (bei mir 10 s) wird der Parameter "innogy-smarthome.1.info.connection" überprüft, falls "false" wird der innogy-Adapter über ein exec-Kommando neu gestartet. Seitdem ist Ruhe.
genau. Aber wie gesagt, die Zustände werden nicht nur von Alexa geschaltet. Auch wenn z.B. die Außentemperatur einen bestimmten Wert übersteigt, wird von Heizung Normalbetrieb auf Heizung Aus geschaltet oder wenn Urlaub auf Ja geschaltet wird, wird Heizung abgesenkte Temp. aktiviert usw.
nutzt du nur diese Szenarien oder in Kombination mit anderen Zeitprofilen?
Basis sind die vorgefertigten OOTB-Zeitprofile der SHZ.
Die sind auf der SHC erstellt.
In ioBroker hatte ich es auch schon mal mit blockly realisiert, geht genauso.
Habe ich auch so ähnlich. Allerdings habe ich für die Heizkörpereinstellung in Livisi 3 Zustände angelegt: "Heizung Normalbetrieb"; "Heizung abgesenkte Temperatur" und "Heizung AUS" und diese stellen dann (über Szenarien) die einzelnen Heizkörper mit einem Ruck. Das hat den Vorteil, dass man die gleichen Einstellungen auch ohne Alexa (z.B. über Fernbedienung oder vis) machen kann und dafür nicht alles mehrmals komplett programmieren muss. Oder ich kann z.B. "Heizung an" als getrennte Routine für Alexa programmieren und nehme dafür wieder die selben Zustände her.
Und als Abschluss wünscht Alexa uns natürlich auch eine gute Nacht.
Du fragst aber schon in der history nach dem Namen (alexa2.0.History.name) und nicht in den devices ?
Noch eine Frage, hast du eine Idee warum er bei mir die Ansage immer nur auf dem ECHO Dot im Büro wiedergibt...
und die Sprachausgabe über "speak" gibst Du wirklich in jedem Fall auf die aktive Alexa aus, also in Deinem Fall 5 speak-Ausgaben?
Ja genau die lila Felder 0/1 was machen die? ist das auch nur für offen/zu oder zählt er damit irgendwas?
Das dient dazu, den Text festzulegen: Anzahl offene Fenster > 1 - "sind noch offen", Anzahl offene Fenster = 1 - "ist noch offen" . Die genaue Anzahl > 1 ist dabei unwichtig.
bei mir steht da immer nur "IsOpen"
wie kann man das einstellen im ioBroker
Indem man im innogy Adapter an der entsprechenden Stelle den Bezeichner ändert. Allerdings scheint das immer nur bis zum nächstrn Neustart des innogy-Adapters Bestand zu haben, habe es noch nicht dauerhaft hinbekommen.
Hab mir's gerade noch mal angesehen: Wahrscheinlich kommt es daher, dass die Bezüge zu den Datenpunkten beim Import in Dein System ja nicht da sein können. Deshalb nimmt ioBroker dann die Texte aus dem Exportfile. Wenn ich das bei mir wieder importiere, steht auch nur "is open" oder so Zeug, d.h. die Texte werden durch die Bezeichner aus den Datenpunkten ersetzt.
meinst Du z.B. "Türsensor Terrassentür" - das sind hmip-Tür-/Fenstersensoren, die über ioBroker in das System eingebunden sind.
Falls Du die roten Ausdrücke (z.B."Anzahl offene Fenster") meinst, das sind lokale Variable, die direkt in Blockly deklariert werden.
