bitte löschen

Vielen Dank für die Info.

Ich prüfe das auch. Die Steuerung erfolgt bei mir über node-red via mqtt; der ioBroker nimmt nur geänderte Werte an. Problem hierbei ist, dass die Werte ja sowohl übermittelt, als auch abgefragt werden sollen. Wenn sich das zeitlich überschneidet (was leider manchmal vorkommt), wird ein Wert nicht übermittelt, weil er genau in der Sekunde, in dem auch ein abgefragter Wert eingetragen wurde -oder vermutlich eine Zehntelsekunde zu früh, sodass der abgefragte Wert direkt überschrieben hat- auch übertragen wurde. Damit könnte ich aber sogar noch leben und ggf. jeden Wert 2x in einem 5-sekündigen Intervall übermitteln; wird dann einmal der falsche Wert wegen Überschneidung gesetzt, wird er zumindest direkt mit dem richtigen überschrieben.

Das Hauptproblem ist aber weiterhin der Error Status, der sich nicht beheben lässt. Ich nehme an, Du hast dieses Problem nicht? Hatte schon überlegt, einfach einen zweiten MaxCube anzuschaffen und im Obergeschoss aufzustellen. damit er näher an den Geräten dort oben ist... aber ich habe die Hardware nun seit fast drei Jahren und der Fehler tritt erst seit gut einem halben Jahr auf. Deshalb kann ich mir nur schwer vorstellen, dass es wirklich an der Funkleistung des Cubes liegt.

Hat niemand eine Idee? Ich steige notfalls auch gerne auf ein anderes System um, sofern ich mich endlich mal darauf verlassen kann, dass meine Heizungssteuerung wirklich immer funktioniert.

Aktuell ist es so, dass diese Verbindungsabbrüche (siehe oben, Error true) immer häufiger auftreten, und ich dann eben manuell immer nachbessern muss. Laut Github des Entwicklers kann man diesen Fehler über den Adapter nicht beheben, sodass wirklich jedes Mal mit der offiziellen spaghetticode Software des Herstellers gearbeitet werden muss...

Hallo zusammen,

ich nutze ioBroker, um (unter Anderem) meine Heizkörperthermostate von eq!Max zu kontrollieren. Der entsprechende Adapter funktioniert super, aber es gibt zwei Nachteile, die meinen gesamten Workflow extrem stören:

1. der MaxCube hat ein Limit, wie viele Befehle er pro Zeit X (ich glaube, es sind 60 Minuten) absenden darf.
   Beim Testen neuer Routinen passiert es schnell, dass dieses Limit erreicht ist, und dann kann man nicht weiter arbeiten, weil einfach nichts mehr vom Cube and die einzelnen Thermostate übermittelt wird.
2. in letzter Zeit (~6 Monate) kommt es immer wieder vor, dass einzelne Heizkörperthermostate plötzlich einen Fehler melden.
   Klar sichtbar unter maxcube.0 -> devices -> thermostat_34234 -> error = true. Dieser Fehler lässt sich (anscheinend; wurde auf der GitHub Page unter Issues schon diskutiert) nur so lösen, dass man den Adapter pausiert, sich mit dem offiziellen Max! Client vom PC oder Mac verbindet, das entsprechende Thermostat einmal plus oder minus X°C schaltet, und kurz wartet. Danach ist der Fehler weg und man kann den Adapter im ioBroker wieder starten. Das ist natürlich sehr schlecht, wenn es mal passiert, während man nicht zu Hause ist, weil man dann nicht ohne Weiteres* remote etwas reparieren kann.

*klar, wenn man einen Windows- oder Mac Laptop hat, kann man sich über das Heim-VPN mit dem MaxCube zu Hause verbinden das ist grundsätzlich unschön, zudem ist mein "Reiselaptop" ein Linux Gerät, auf dem die Max! Software nicht läuft. Es gibt keinen offiziellen Linux Support, und das OSX Programm, das glücklicherweise unter Linux zum Laufen gebracht werden kann, frisst für den Reiselaptop zu viele Ressourcen, weshalb ich es in diesem Fall überhaupt nicht benutzen kann. Es lädt ewig und crasht dann irgendwann.

Aaaanyway, mein eigentliches Anliegen ist ja auch folgendes: Wie kann ich den MaxCube gegen einen MaxCul austauschen? Gibt es da ioBroker-spezifische Tutorials, die ich trotz diverser Suchen nicht gefunden habe? Ich weiß nicht, wie man einen MaxCul überhaupt einrichtet. Die meisten Tutorials beziehen sich auf FHEM, was ich nicht verwende, und auch definitiv nicht einsetzen möchte.

Aus Bequemlichkeit bzw. mangelndem Know-How würde ich auf den teureren USB Stick von busware zurück greifen, statt selbst etwas zu basteln. Aber selbst der kommt ohne Firmware, und die Anleitungen, die sich auf das Flashen der Firmware beziehen, kommen auch alle aus dem FHEM Umfeld.

Ich muss quasi:

• MaxCul USB Stick bestellen
• diesen flashen (womit? culfw, a-fculfw? Eine extra auf ioBroker zugeschnittenen Fork hiervon?)
• Bzw. erst einmal die Firmware kompilieren (wie? Nach FHEM Tutorial, oder muss ioBroker spezifisch etwas beachtet werden??)
• in den ioBroker einbinden (geringstes Problem)

Ich habe gestern noch gelesen, dass man den MaxCube selbst auch direkt mit einer alternativen Firmware flashen kann. Soweit, so gut, aber wenn da etwas schief geht, bzw. die Einrichtung länger dauert, als erwartet, stehe ich erst einmal ohne funktionierende Heizungssteuerung da.

Könnt Ihr mir etwas empfehlen, wie ich endlich zuverlässig meine Thermostate über den ioBroker steuern kann? Das Problem "Zuverlässigkeit" liegt hier nicht bei ioBroker, sondern bei der Hardware. Ich habe parallel mal versucht, von eq!Max weg auf DECT Thermostate umzusteigen. Diese rufen nur alle 15 Minuten den Soll-Status von der Fritz!Box ab, sodass die Reaktionszeit bei einem geöffneten Fenster (Xiaomi Sensoren) hier viel zu lange ist. Das war keine Alterantive, und alle anderen Lösungen, die ich mir bislang angeschaut habe, scheitern auch entweder an der Reaktionszeit, dem Protokoll (Bluetooth?! Das kann ich im gesamten Haus vergessen. Lösungen, die grundsätzlich über einen Server des Anbieters kommunizieren, ich glaube, die Nachfolgelösung von eq!Max arbeitet so, gehen ebenfalls gar nicht!), oder sonst woran.

Daher würde ich gerne einen MaxCul zur Steuerung einsetzen, außer, jemand empfiehlt mir hier noch eine ganz andere Lösung (bsp. Heizkörperthermostate, die sich ausschließlich über den ioBroker steuern lassen, ohne auf fremde Server zurückgreifen zu müssen, und dabei auch zuverlässig arbeiten - dann steige ich vielleicht sogar direkt darauf um ).

Vielen Dank im Voraus für Eure Tipps

Vielen Dank!

Dann muss ich lieber einmal in den sauren Apfel beißen und sämtlichen Routinen ändern, sodass sowohl die Glühlampen, als auch Türen und Fenster mit dem neuen Adapter laufen.

Hallo zusammen,

ist es möglich, dass ich zwei Versionen desselben Adapters gleichzeitig auf meinem ioBroker laufen lasse?

Ich nutze aktuell mit einem CC2531 den zigbee Adapter in Version 0.6.0. Dieser funktioniert super mit meinem Xiaomi Sensoren, aber kann die eingesetzten Philips Hue Glühlampen nicht steuern (sie werden gefunden, verbunden, und angezeigt; Steuern ist jedoch nicht möglich).

Wenn ich den Adapter auf Version 0.7.7 update, kann ich die Glühlampen steuern; allerdings verändert dieser Adapter die Struktur einiger Objekte, sodass ich sämtliche Routinen umschreiben müsste. Version 0.6.0 übermittelt den Status "geschlossen", das heißt, wenn ein Sensor geöffnet ist, wird "false" übermittelt. Bei Version 0.7.7 wurde dies leider umgestellt und es wird "offen", also "true" übermittelt. Ich muss demnach sämtliche Routinen umändern, um die neuere Version zu nutzen.

Daher würde ich gerne einfach einen zweiten Adapter installieren, der auf Version 0.7.7 läuft, diesem einen weiteren Zigbee USB Stick zuweisen, und die Glühlampen hierüber steuern.

Ist das möglich?

Vielen Dank für Eure Hilfe

Hallo miteinander,

ich bin erst vor Kurzem auf den ioBroker gestoßen, vorher habe ich ausschließlich mit node-red gearbeitet. Um nun beide Systeme miteinander zu verbinden, nutze ich MQTT als Protokoll, um Datenpunkte hin- und herzuschieben (ich weiß, das ginge auch ohne MQTT mit dem Adapter, ich nutze MQTT aber beispielsweise auch am Smartphone, weshalb ich auf darauf einfach nicht verzichten möchte).

Mit dem Alexa Adapter habe ich nun öfter das Problem, dass Geräte angeblich nicht reagieren, obwohl sie im ioBroker im Cloud Adapter als Geräte angelegt und richtig konfiguriert sind. Das passiert meistens dann, wenn ich ein Gerät per MQTT geschaltet habe, und der alte Status noch bei Alexa "hinterlegt" ist.

Beispiel: mein PC wird mit "Alexa, Rechner an" eingeschaltet. Ich schalte ihn dann "irgendwie" (Zeitregel, MQTT, …). Möchte ich ihn wieder einschalten, sage ich noch einmal "Alexa, Rechner an" und bekomme "Rechner reagiert nicht". Sage ich dann "Alexa, Rechner aus" kommt der Bestätigungston und ich kann mit "Alexa, Rechner an" das Gerät wieder einschalten.

Alle per Alexa zu steuernden Geräte sind im ioBroker als eigene Objekte angelegt. Per MQTT Client werden die werde an meinen MQTT Server übermitelt, von dort gehen sie u.A. in node-red, und da ist ein Großteil der Logik, wann welche Geräte wie geschaltet werden. Der MQTT Client published diese Werte nur, abonniert sie aber nicht. Aaaaalso dachte ich, dass Alexa wahrscheinlich nicht damit klar kommt, wenn ein Gerät auf "true" steht und erneut auf "true" gestellt werden soll - der Umzug mit einfach auf false setzen ("Alexa, Rechner aus") und dann wieder auf true ("...") klappt ja.

Also habe ich bei den Objekten auch abonnieren aktiviert; wenn ich jetzt per MQTT ein Gerät ausschalte, wird der Status im ioBroker auch unter Objekte korrekt angezeigt (also war via Alexa false, wurde via MQTT auf true gesetzt). Trotzdem habe ich manchmal -aber NICHT immer- das Problem, dass Geräte angeblich nicht reagieren.

Habt Ihr eine Idee, woran das liegen könnte? Dass die Alexa und Cloud Adapter erfolgreich verbunden sind, kann ich ja problemlos testen, indem ich einfach ein anderes Gerät im selben Zimmer kurz ein- oder ausschalte; das funktioniert immer. Es muss also irgendwie trotzdem am Gerätestatus liegen.

Mir ist aufgefallen, dass ioBroker den Status als String verschickt, oder zumindest bekomme ich in node-red als Ausgabe "false" (mit Anführungszeichen und in rot, wie Strings dort dargestellt werden), und nicht false (ohne Anführungszeichen und in blau, wie boolean dargestellt wird). Vielleicht liegt es daran, allerdings sieht der Objektstatus im ioBroker immer korrekt aus (würde ich dort boolean senden, aber es würde ein string erwartet, käme ja irgend ein Fehler..?).

Vielen Dank im Voraus für Eure Lösungsansätze