Beiträge von VirginiaExpress

Hallo zusammen,

ich habe diverse Xiaomi Sensoren im Einsatz, die den aktuellen Status meiner Fenster und Türen übermitteln. Diese laufen mit einer älteren Version des Zigbee Adapters. Um einige per Zigbee steuerbare Glühbirnen zu steuern, müsste ich zusätzlich die aktuelle Version des Zigbee Adapters installieren. Warum erläutere ich jetzt:

Der ältere Zigbee Adapter übermittelt unter Objekte u.A. "isopen", was bei einem geschlossenen Fenster auf "false" steht. Dafür kann der ältere Adapter aber die Glühbirnen nicht steuern (weder an/aus, noch die Helligkeit erhöhen/verringern). Der neue Zigbee Adapter hingegen übermittelt statt "isopen" den gegenteiligen Wert (ob es "isclosed" oder etwas anderes ist, kann ich nicht sagen, da ich die aktuelle Version schon vor einiger Zeit wieder gelöscht habe), und zeigt deshalb bei einem geschlossenen Fenster "true" an, wo der alte Adapter noch "false" gezeigt hat.

Das Dilemma für mich ist, dass ich die Statuswerte per mqtt an node-red übermittle und dort weiter verarbeite. Das bedeutet, wenn ich den Adapter nun update, muss a) für jeden Status das mqtt Topic neu setzen (weil "isopen" ja nicht mehr existiert und der existierende Pfad bei einem Update nicht übernommen würde) b) jede Routine in node-red ändern, weil ja alle Routinen aktuell für ein geschlossenes Fenster "false" erwarten, aber nach dem Update "true" übermittelt bekämen.

Ich setze aktuell einen CC2530 Stick (oder [definition='64','0']CC2531[/definition]? Jedenfalls den, der hier im Forum auch schon öfter empfohlen wurde; bin gerade nicht im Heimnetzwerk und kann es nicht nachschauen) für Zigbee ein. Zusätzlich habe ich mir jetzt noch den ConBee Stick bestellt. Meine große Hoffnung ist, nun mit dem CC Stick den alten Adapter weiterhin zu betreiben, und den neuen Stick einer aktuellen Version des Adapters zuzuweisen, um über diesen nur die Glühbirnen zu steuern (oder ggf. Stück für Stück einzeln die Fenstersensoren dort auch einzubinden; das wäre auf jeden Fall einfacher, als noch einmal zu updaten und dann auf einen Schlag den gesamten Zigbee Workflow ändern zu müssen).

Ist das möglich? Oder habt Ihr andere Ideen, wie ich das bewerkstelligen kann? Bestimmte Dinge (mqtt Topic für jeden Sensor erstellen beispielsweise) kann ich nicht automatisieren, da ich ein ganz bestimmtes Muster ( Beispiel: /home/etage/zimmer/sensorart/status) einsetze. Dieses muss ich für jeden Sensor per Hand einstellen, und dann natürlich in node-red auch diejenigen Flows, die nicht mit Variabeln arbeiten, sondern das exakte Topic erwarten, ebenfalls manuell angleichen).

Es wäre natürlich langfristig die bessere Lösung, den neuen Adapter einzusetzen, aber um sicherzustellen, dass nicht auf einmal die Heizungen verrückt spielen (weil sie auf den open/closed Status der Fenster und Türen angewiesen sind), möchte ich nicht auf einen Sprung umsteigen. Das kann ich lieber Schritt für Schritt machen, wenn ich zwei Versionen des Adapters gekoppelt mit zwei verschiedenen Sticks habe.

Vielen Dank für Eure Ideen

Vielen Dank! Von den Spezifikationen sieht die FI9901EP für mich recht passend aus.

Ist die Kamera wirklich "offen", also könnte man sich beispielsweise per SSH verbinden und eigene Scripts einbauen etc? Ich habe mal danach gegoogelt, bin aber nur auf einige Hacks und Exploits gestoßen, die schon etwas älter sind und -falls man bei Foscam auf der Hut ist- nicht mehr funktionieren dürften

Hallo zusammen,

ich habe bereits einige no name Kameras zur Überwachung meines Grundstücks im Einsatz. Leider müssen diese alle über ein Windows System konfiguriert werden, denn ohne Internet Explorer mit ActiveX kommt man nicht auf die Weboberfläche mit der Konfiguration.

Einmal eingerichtet laufen die Cams okay, aber ein offenes System wäre mir lieber.

Könnt Ihr Hardware empfehlen?

Ich habe schon eine Xiaomi Dafang gekauft und gerade eingerichtet. Die läuft mit dem Dafang Hack stabil, rtsp läuft, Nachtsicht ist okay mqtt und Telegram muss ich noch einrichten... Sie ist aber nicht wasserdicht, weshalb sie für den Ausseneinsatz nichts ist.

Ethernet statt WiFi wäre schön, PoE noch schöner. Ansonsten möglichst Weitwinkel, Nachtsicht klar. 24/7 Betrieb (Aufnahme permanent auf Synology NAS) muss möglich sein. Zudem ein klar verfügbarer rtsp oder http Stream, damit man auf keine Hersteller App angewiesen ist.

Ob man die Cam selbst mit Firmware flashen muss, oder die vom Hersteller aus offen ist, ist in diesem Fall nicht relevant.

Danke für Eure Ideen =)

Hat jemand von Euch mqtt zum Laufen bekommen? Mqtt Control gibt bei mir den Fehler (oder Anzeige unter Services halt) "NOK", mqtt Status zeigt den grünen Haken, unter dem angegebenen Topic (bei mir home/cam/dafangcam-01/#) wird aber nichts übertragen.

UnReal danke! Wahrscheinlich reicht es vollkommen, die auf manuell stehen zu haben. Ich habe den Fehler eben noch mal versucht nachzuvollziehen. Um 00:00 stellen sich die Thermostate an manchen Tagen (aber nicht an allen!) um. Gemäß Drittanbieter-Android App war es aber so eingestellt, dass jeden Tag um 00:00 geschaltet werden soll.

Entweder ist das jetzt ein völlig anderes Problem, dann kann ich es nicht nachvollziehen... meine Temperaturänderungen werden alle zu bestimmten Uhrzeiten automatisiert angestoßen, da kann der Fehler nicht liegen.

Ich werde die Tage mal an einem Flow arbeiten, der die jeweiligen Temperaturen vor Mitternacht in eine extra Variabel schreibt und um 00:05 diese Temperatur erneut für jeden Heizkörper setzt. Nicht ganz so elegant, aber dann dürfte es ja keine Probleme mehr geben.

Danke auch für Dein Script. Ich nutze für die Logik ausschließlich node-red (ioBroker sendet die Infos vom maxCube per mqtt raus und empfängt sie ebenso wieder), weil mir diese Scripte immer zu umständlich sind. Wird 'ne Gewöhnungssache sein, bei node-red bin ich mit sowas einfach flexibler. Bei Blockly geht bei mir (macOS, Firefox) nicht mal cmd+Z für rückgängig machen, was meinen Workflow extrem stört. Das habe ich bei node-red nicht. Aber so wie ich Dein Script deute, macht es ungefähr dasselbe wie meins.

Bei Deinem finde ich äußerst genial, dass Du eine von-bis Zeit eintragen kannst. Das kann ich in meinem Flow mal ändern, da es für genau sowas ein Addon (für die node-red User: BigTimer) gibt. Aktuell stelle ich bsp. um 22:00 auf X Grad und es bleibt X Grad bis beispielsweise um 08:00 der nächste Trigger die Gradzahl ändert. Du setzt die Werte extra höher an, damit es schneller geht, richtig? Also wenn Wert <= 21.2 Grad wird direkt auf 24 geschaltet, statt nur auf 21.2. Hast Du dafür in jedem Zimmer ein Wandthermostat? Ich nutze noch den Temperaturfühler der Thermostate selbst, also wenn ich 19 Grad haben will, schalte ich das Thermostat direkt auf 19. Aber da das ja nur am Thermostat (wo es logischerweise am Wärmsten ist) gemessen wird, habe ich am Schreibtisch/Bett/Couch natürlich weniger Wärme, was jetzt nachträglich noch mit den Xiaomi Temperaturfühlern geregelt werden wird

Hast Du Weihnachten ungewollt alleine verbringen müssen, oder was soll diese patzige Art?

Klar, exakte Modellbezeichnung ist immer besser, aber so oder so wirst Du mir ganz sicher nicht meine Wortwahl vorschreiben K_L_S

Es handelt sich um den [definition='47','0']Beelink[/definition] N50 Mini PC. Meine "Weisheiten" habe ich daher, dass vor Kurzem in meinem Arbeitszimmer eine Sicherung raus geflogen ist, und nachdem wieder Strom im Zimmer war, alle (relevanten) Geräte außer dem [definition='47','0']Beelink[/definition] wieder liefen.

Zum [definition='47','0']Beelink[/definition] muss ich leider noch mal einwerfen, dass der sich nach einem Stromausfall nicht automatisch wieder hochfährt. Im Gegensatz zu einem (leider ja schwächeren) [definition='18','0']Raspberry[/definition] Pi, der bootet, sobald das Gerät wieder Strom hat. So ist das zumindest bei mir.

Kommt zwar selten vor, dass mal der Strom weg ist... aber da die gesamte Haussteuerung über den [definition='47','0']Beelink[/definition] bei mir läuft, wäre es echt mega unpraktisch, wenn ich mal länger nicht zu Hause bin und genau dann kurz der Strom ausfällt. Denn dann wird der [definition='47','0']Beelink[/definition] nichts machen, bis ich wieder zu Hause bin und ihn per Hand anschalte. Das hätte ich vor dem Kauf schon gerne gewusst. Vielleicht wäre es per Wake-On-Lan möglich, aber dafür braucht man dann ja auch ein weiteres Gerät, was immer nachschaut, ob der [definition='47','0']Beelink[/definition] läuft, und ihn startet, wenn das nicht der Fall ist

Danke für Eure Infos

Ich werde das DECT Teil auch zurück schicken. Das 15 Minuten Delay geht gar nicht, und zum Testen (ob beispielsweise eine Logik richtig programmiert wurde) ist das dermaßen nervig... da muss man ja bei jedem Test zum Gerät laufen, Taste drücken, zurück an den Rechner, neuen Befehl testen, wieder zum Gerät usw.

Meine Max Geräte stehen alle auf Manu, und größtenteils funktionieren sie ja auch... aber eben nicht immer, was mich etwas stutzig macht. Das Thermostat in der Küche (Thermostat von Max, Fenstersensor von Xiaomi) schaltet sich nicht aus, wenn ich das Fenster öffne; der exakt gleiche Code (außer Name der Variabeln) wird auch bei mir im Arbeitszimmer eingesetzt, und dort funktioniert das Schalten des Thermostats problemlos.

Zwar habe ich im Arbeitszimmer noch den Max Fenstersensor im Einsatz, aber ich sehe ja durch die Ausgabe (debug-Tab in node-red), dass der Code im Arbeitszimmer trotzdem funktioniert (= er würde das Thermostat auf 5 Grad schalten, wenn dies nicht sowieso schon automatisch passieren würde, weil der Fenstersensor direkt mit dem Thermostat kommuniziert). In der Küche passiert einfach mal gar nichts, also keine Ausgabe im Debug Tab, kein regulieren des Thermostats. Inzwischen fällt das Thermostat sogar immer auf die von Hand eingestellte Temperatur zurück (direkt am Gerät eingestellt), egal, welchen Befehl ich per MQTT oder [definition='20','0']Alexa[/definition] sende. Und das, nochmal betont, bei identischem Code, der in allen anderen Räumen funktioniert. (das Arbeitszimmer nehme ich immer als Referenz, weil ich dort halt sitze und direkt auf die Heizung schauen kann)

Welche Thermostate von Max nutzt Ihr? Es gibt ja "Heizkörperthermostat" (~28 EUR), "Heizkörperthermostat Basic" (~18 EUR) und "Heizkörperthermostat +" (~28 EUR). Ich nutze momentan die normalen Heizkörperthermostate (ohne Plus, kein Basic). Das Basic Teil soll angeblich deutlich leister sein, als das normale. Das Plus hat wohl den Vorteil, auch die Ist-Temperatur auf dem Display anzuzeigen... da ich die Geräte soweit möglich sowieso ausschließlich per Smartphone (MQTT) und [definition='20','0']Alexa[/definition] Sprachbefehl steuern möchte, fällt das Plus für mich direkt raus. Nun wollte ich testhalber mal ein Basic kaufen, um zu sehen, ob das wirklich leiser ist... da jetzt durch die Feiertage aber der Versand auch langsamer ist, wäre es schön, vor einer eventuellen Bestellung zu wissen, ob das sich lohnen würde Beleuchtet dürften sie alle sein. Und HauptstadtRocker genau, die fehlende Beleuchtung beim DECT nervt tatsächlich. Wusste ich vorher, hätte aber nie gedacht, dass das wirklich stören würde! Tut es leider.

UnReal hast Du einen Tipp, wie ich sämtliche Zeitpläne löschen kann? Unter der Max Oberfläche kann ich maximal eine Temperatur von 00:00 bis 23:55 einstellen. Diese wird dann automatisch überschrieben, sobald ich etwas regle. Im Schlafzimmer schicke ich um 01:15 noch mal einen Befehl raus, der die Temperatur von vor 23:55 wiederherstellt (denn um nicht versehentlich die ganze Nacht in allen Zimmern umsonst zu heitzen, ist die Temperatur von 23:55 13 Grad).

Mit der MAX! Remote App kann man vorhandene Zeitpläne ändern und auch Zeiten löschen (was mit der Max Webgui echt grausam ist). Aber auch hier bleibt mir dann nur 00:00 bis 23:55 als Zeitplan; leider muss als Start -sofern ich das bei meinen 100 Versuchen nicht doch nur übersehen habe- immer 00:00 Uhr drin sein; also wenn ich einstelle 00:00 bis 06:00 10 Grad und 06:00 bis 23:55 11 Grad, dann 00:00 bis 06:00 lösche, bleibt der Timer nicht -wie ich erwartet hätte- auf 06:00 bis 23:55, sondern stellt sich automatisch auf 00:00 bis 23:55 um. Das heißt, das Problem, dass definitiv nachts einmal geschaltet werden muss, werde ich nicht los.

Die stehen auf manuell und lassen sich per Tastendruck nicht auf AUTO stellen. Ist manuell okay, oder sollte auto eingestellt sein?

Ah super, danke für die Info mit den 15 Minuten. Dann wird das daran liegen. Ich habe mit Max nur noch Probleme.

Ein bestimmtes Zimmer wird beispielsweise auf 19 Grad geschaltet. Steuerung automatisch über node-red via mqtt an ioBroker (oder manuell via mqtt vom Smartphone). Plötzlich wird auch ein weiterer Raum auf 19 Grad gestellt, obwohl ich das weder manuell, noch automatisiert so angestoßen habe.

Dann hat der Maxcube ja auch noch das Zeitprogramm, was man nicht komplett deaktivieren kann, nur minimalisieren; per Umweg über eine Drittanbieter Smartphoneapp werden alle Heizkörper zumindest nur noch um 00:00 Uhr einmal auf Wert X gesetzt (ab Werkreset sind ja drei verschiedene Heizprofile definiert). Klar, ich kann manuell wieder um 00:05 Uhr den vorherigen Wert schalten, aber das ist auch das kleinere Problem.

Läuft bei Euch der Maxcube (und die zugehörigen Thermostate) rund? Aktuell nutze ich auch noch die Fensterkontakte von eqMax, aber möchte auf die Xiaomi Sensoren wechseln... Leider darf man über den Cube ja nur x mal pro Stunde senden. Wenn ich nun dieses Limit erreicht habe und ein Fenster öffne, schaltet die Heizung dann vermutlich gar nicht mehr ab..?

Hallo zusammen,

Ich nutze die Eurotronic ComectDECT Heizkörperthermostate mit dem fritzdect Adapter.

Der Adapter erkennt die Geräte nach Einrichtung an der fritzbox und ich kann die Temperatur regeln; stelle ich im ioBroker unter Objekte oder via MQTT die Temperatur um, ändert sich der Wert auch entsprechend im Webinterface der fb.

Aaaber: die Heizkörperthermostate selbst schalten sich scheinbar immer erst dann um, wenn ich von Hand eine ihrer Tasten drücke (also am Thermostat selbst) .

Das kann ja nicht so gehören, denn so könnte ich ja sonst auch manuell die Temperatur regeln und komplett auf "smarte" Thermostate verzichten.

Dass die auf den Thermostat angezeigte Temperatur erst bei Tastendruck aktualisiert wird, ist ja erstmal nicht schlimm. Aber dass ich kurz nach dem Tastendruck höre, wie der Thermostat auch tatsächlich regelt, deutet für mich darauf hin, dass eben nicht nur die Anzeige, sondern eben auch der tatsächliche Wert im Gerät aktualisiert wird und vorher keine Aktualisierung der Temperatur (=Thermostat schaltet) erfolgt.

Kennt jemand hier das Problem und hat eine Lösung? Wenn ich es unzuverlässig möchte, hätte ich auch beim MaxCube und den zugehörigen Thermostaten bleiben können (bin gerade im Wechsel, also max und eurotronic laufen parallel, bis Ende Januar wollte ich auf Eurotronic gewechselt haben).

Okay, dass die Adapterversionen vollständig mit gesichert werden, war mir nicht klar. Das ist super.

Dann reicht ja ein Backup der aktuellen (funktionierenden) Konfiguration, und danach kann ich rumprobieren.

Mit ging es auch darum, ob eine Änderung der Version dafür sorgen könnte, dass ein verbundenes Gerät nach dem Einspielen des Backups ggf. nicht mehr funktioniert. Wenn das nicht der Fall ist, kann ich ja testen und im schlimmsten Fall auf das Backup zurückgreifen.

Wisst Ihr, ob folgendes funktionieren würde:

1. vollständige Sicherung mit backitup

2. Update des Adapters auf 0.8.0 (oder Downgrade auf 0.6.0)

Wenn dann etwas nicht funktioniert

3. Downgrade/Upgrade auf 0.7.7

4. Einspielen der vollständigen Sicherung mit backitup

Mir geht es darum, dass ich gerne probieren würde, ob sich die Lampen doch wieder steuern lassen; noch einmal kann bzw. möchte ich aber nicht alle Geräte neu anlernen müssen (war letztes Mal leider der Fall), insbesondere, weil ich den Router nicht neu flashen will und weil mittlerweile 15 Geräte verbunden sind, von denen knapp die Hälfte ohne den Router aufgrund der Reichweite dann gar nicht mehr funktionieren würden.

Ich weiß nicht, ob die Kopplung von Stick und Client nach einem Einspielen des Backups "einfach so" wieder funktioniert, oder ob aus irgend welchen Gründen da eine neue Kopplung notwendig wäre.

(fast) alles andere könnte ich in einer virtuellen Maschine einfach ausprobieren... ich habe aber nur den einen [definition='64','0']CC2531[/definition] Stick, sodass ein Test auf einem anderen System mangels weiterem Stick nicht möglich ist.

Und noch ein kleines Offtopic: auf der zigbee2mqtt Wikiseite steht, um x Geräte zu verbinden, braucht man zwingend einen Router, da der Stick nur y Geräte handeln kann... kann das jemand bestätigen?

Bzw. die eigentliche Frage ist: welche Hardware zusätzlich zu meinem vorhandenen [definition='64','0']CC2531[/definition] Stick und CC2530 Router brauche ich, um >35 Clients (momentan hauptsächlich Xiaomi [definition='62','0']Aqara[/definition] Temperatursensoren und Fenster Magnetkontakte) zu benutzen?

Aktuell sind ja "nur" 15 Geräte verbunden. Seit heute Vormittag übrigens, vorher waren es nur 4 Grundsätzlich scheinen sie alle zu funktionieren (Verbindung erfolgreich hergestellt, Werte beim Testen aktualisiert), aber komischerweise sendet jetzt gerade der Sensor, der dem [definition='64','0']CC2531[/definition] Stick am nähesten ist, keine Updates mehr - obwohl ich ihn vor ein paar Stunden erfolgreich verbunden und getestet habe. Der ist im Badezimmerfenster neben meinem Büro, wo der Empfang eigentlich bestens sein sollte -.- Vorhin hat er noch alle Werte geupdatet, jetzt sehe ich bei dem nur noch isOpen und ContactEvent (keine Angaben zu Verbindungsstärke, Batteriestärke, etc. wie bei all den anderen baugelichen Sensoren)... Mysteriös...

Hallo zusammen,

ich nutzen den Alexa2 Adapter, um verschiedene Geräte zu steuern. Da der Adapter ja leider nur übers Internet funktioniert¹, wollte ich mir bei einem Internetausfall o.Ä. die Möglichkeit offen halten, meine Geräte per mqtt zu steuern. Zudem habe ich vor dem ioBroker -von Smart Steckdosen abgesehen- sowieso alles per mqtt gesteuert.

Folgendes habe ich gemacht:

1. alexa2 Adapter installiert und konfiguriert
2. mqtt Client installiert und konfiguriert
3. Cloud Adapter installiert, konfiguriert, verbunden
4. Gruppe mit eigenen Geräten unter Objekte angelegt
5. dort Geräte entsprechend angelegt (Heizungen als Heizung mit Wert Zahl, Steckdosen als Licht (Steckdose gibt es als Gerät wohl nicht?) -weil an/aus- mit Wert Switch, etc.

Als Beispiel nehmen wir mal mein Macbook. Mit "[definition='20','0']Alexa[/definition], Rechner an" wird eine Smartsteckdose eingeschaltet, die u.A. mein Macbook, die Monitore, Lautsprecher, etc. mit Strom versorgt. Ausschalten funktioniert nach demselben Prinzip.

Nun schalte ich aber manchmal meinen Rechner per Smartphone App (MQTT Dashboard) aus. [definition='20','0']Alexa[/definition]/Alexa2 "denkt" laut Objekt im ioBroker natürlich, der Rechner sei noch an; also der Rechner ist jetzt aus und [definition='20','0']Alexa[/definition] "denkt", er sei noch an. Manchmal funktioniert nun trotzdem der Befehl "[definition='20','0']Alexa[/definition], Rechner an", manchmal allerdings auch nicht Dann bekomme ich die Meldung "Das Gerät Rechner reagiert nicht". Ich kann nun zig mal "Rechner an" wiederholen, und es kommt immer wieder dieser Fehler. Wenn ich nun aber einmal sage "[definition='20','0']Alexa[/definition], schalte Rechner aus" (obwohl er ja bereits aus ist) und dann sofort wieder "[definition='20','0']Alexa[/definition], schalte Rechner an", dann funktioniert wieder alles.

Würde dieser Fehler nun zuverlässig jedes Mal auftreten, würde ich sagen, Alexa2 kann halt nicht damit umgehen, dass der Status eines Geräts bereits auf false ist, bzw. ein auf false gesetztes Gerät nicht noch einmal false schalten. Denn setze ich per Sprachbefehl einmal true, dann false, funktioniert es ja. Da es manchmal aber trotzdem funktioniert, bin ich ziemlich ratlos.

Diese unter Objekte angelegten Geräte senden per MQTT Client ihren Status; die Einstellungen sind folgendermaßen gesetzt

Vorher hatte ich auch Abonnieren aktiviert, ebenfalls qos 1, und den Haken bei Bestätigt entfernt (wenn der Haken bei Bestätigt gesetzt war, hat das Abonnieren nie die tatsächlichen Werte übernommen). Hier war es so, dass, wenn ich den Rechner nun per MQTT ausgeschaltet hatte, der Status auch im ioBroker übernommen wurde. Der beschriebene Fehler trat trotzdem auf, weshalb ich Abonnieren komplett deaktiviert hatte. Seitdem funktionierte es auch besser (aka der Fehler trat viel seltener auf), in letzter Zeit passiert es aber wieder öfter. Auch bei Heizungen ("Stelle Arbeitszimmer auf 16 Grad"), wo der Fehler bislang sehr selten bis gar nicht auftrat, habe ich in den letzten Tagen immer wieder Probleme.

Habt Ihr eine Idee, woran das liegen könnte? Ich habe ioBroker Version 1.4.2, Alexa2 1.1.3, Cloud 2.6.2, MQTT Client 1.0.1 (sehe gerade, dass es beim MQTT Client mittlerweile 1.1.1 gibt). Da ich vor Kurzem mit dem Zigbee Adapter nach einem Update echt grausame Probleme hatte -ich durfte daraufhin alle Zigbee Geräte neu verbinden, inkl. den Router neu flashen, da er sich nicht mehr verbinden lies- bin ich momentan etwas scheu, was iobroker update / upgrade angeht.

Da das Problem auch bei Abonnieren der Statuswerte auftritt (= Gerät per [definition='20','0']Alexa[/definition] an, Objekt im ioBroker = true; Gerät per MQTT aus, Objekt im ioBroker dank mqttclient = false), gehe ich davon aus, dass der Wert hier gar nicht das Problem verursacht. Meine Internetverbindung ist nicht die schnellste, aber ich kann keine andauernden Verbindungsabbrüche erkennen, die dafür sorgen könnten, dass Geräte zeitweilig nicht steuerbar sind.

Das einzige Problem, das mir immer wieder auffällt ist, dass der Alexa2 Adapter regelmäßig neu verbunden werden muss. Ich nutze ioBroker erst seit ein paar Monaten, und seitdem kam das 3 oder 4 mal vor. Ich merke, dass gar kein Gerät sich steuern lässt, logge mich dann im ioBroker ein und sehe im Log, dass Amazon neu verbunden werden muss. Das Verbinden mit Username/Passwort funktioniert nicht, daher nehme ich den Proxy, logge mich über den Browser ein, und [definition='20','0']Alexa[/definition] ist erst einmal wieder verbunden - leider ohne Gewissheit, für wie lange noch. Aber da der Adapter jetzt gerade definitiv noch verbunden ist, und ich Geräte grundsätzlich ja auch schalten kann, kann auch das nicht der Fehler sein.

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

(1) bei node-red gibt es einen lokalen [definition='20','0']Alexa[/definition] Adapter. Dieser kann aber nur ein/aus, und nicht beispielsweise "Stelle Heizung Arbeitszimmer auf x Grad", weshalb ich für [definition='20','0']Alexa[/definition] auf ioBroker gewechselt habe; einen Großteil der Logik-Arbeit verrichtet bei mir weiterhin node-red, der nur über ioBroker entsprechend die Daten per MQTT übermittelt bekommt. Diese Möglichkeit habe ich für den ioBroker leider nirgends gefunden, sonst würde ich gerne umsteigen und Alexa2 auch nur lokal laufen lassen.

Ich scheue mich noch davor, up- oder downzugraden, einfach, weil bis auf die Hue Lampen alles läuft. Bis ich alles andere vollständig eingerichtet habe (bin erst kürzlich von ausschließlich node-red zu node-red in Verbindung mit ioBroker umgestiegen), lasse ich das Problem erst einmal still im Hintergrund

Der Stick wird sowieso weiterhin funktionieren, das war oder ist gar nicht das Problem... sondern nach dem letzten Wechsel ließ sich der Router (CC2530) nicht mehr finden und verbinden. Den musste ich neu flashen, um ihn wieder mit dem [definition='64','0']CC2531[/definition] Stick (und somit ioBroker) verbinden zu können.

Aber auch meine Version (0.7.7) scheint recht tricky zu laufen... Koppeln verschiedener Geräte: diverse Fehlermeldungen (ist schon länger her, daher kein aktuelles Beispiel aus dem Log), Puls geht erstmal hoch Dann unter Objekte geschaut: alles okay. Wieder im Adapter geschaut: Gerät erkannt, Gerät funktioniert. Waren jedes Mal [definition='62','0']Aqara[/definition] Sensoren. Diese geben auch regelmäßig glaubwürdige Werte ab (Temperatursensoren; bei den Fensterkontakten kann man den Status ja leicht überprüfen), insofern war der Error ja eigentlich Quatsch. Aber so weit sind wir ja auch nicht mehr von Version 1.0 entfernt, bei der dann bestimmt alles läuft

Musstest Du, nachdem Du den Adapter neu installiert hast, alles neu einrichten?

Die [definition='62','0']Aqara[/definition] Sensoren gehen ja (noch; habe ja aktuell erst zwei) schnell, aber den CC2530 musste ich gestern Abend neu flashen, um ihn wieder mit dem Zigbee Adapter verbinden zu können.

Kannst Du die Beiträge bitte mal verlinken?

Ja genau so ist das bei mir auch!

Im ioBroker werden die Änderungen von jeder Quelle übernommen. Aber anscheinend nicht an die Lampe weitergegeben.

Komisch ist, dass es vorher halt geklappt hatte. Egal, ob ich im ioBroker die Werte per Hand ändere, per [definition='20','0']Alexa[/definition] (Lampe im Cloud Adapter angelegt), oder per MQTT: die Werte unter OBJEKTE ändern sich, die Lampen schalten nicht.

Da ich ioBroker exakt nach der Debian Installation installiert habe, gehe ich mal davon aus, dass das kein sudo/root Fehler ist...? Zudem könnte ich dann vermutlich ja gar nichts tun, auch nicht Geräte suchen und verbinden... Das geht aber alles, nur steuern eben plötzlich nicht mehr.

Beim Sensor im Bad oben kann ich mir vorstellen, dass es an der Reichweite und/oder Batterie liegt. Gerade deshalb würde ich ja gerne die eine Philips als Router einsetzen, da sich der CC2530 Router aktuell nicht verbinden lässt.

Hallo zusammen,

ich habe auf meinem ioBroker den Zigbee Adapter 0.7.7 installiert und meinen [definition='64','0']CC2531[/definition] Stick verbunden. Alles lief super, bis gestern Abend. Aber dazu gleich mehr, erst einmal meine verbundenen Geräte.

- 2x [definition='61','0']Philips Hue[/definition] White Bulb (funktioniert auch als Router)

- 2x [definition='62','0']Aqara[/definition] Temperatursensoren

- 1x CC2530 als Router geflasht

Seit dem Setup habe ich den ioBroker leider schon 2x neu einrichten müssen (einmal beim Umzug auf den [definition='47','0']Beelink[/definition], dann gestern nachdem Zigbee überhaupt nicht mehr funktioniert hat).

Resultat: die [definition='61','0']Philips Hue[/definition] Bulbs lassen sich verbinden, aber nicht mehr steuern. Ich hatte vorher immer die Punkte Brightness, State, Connection Strength (o.Ä.; kann das ja leider nicht mehr sehen) und noch mindestens einen weiteren Punkt. Jetzt habe ich nur noch Brightness und State. Über Brightness ließ sich -logischerweise- die Helligkeit steuern, theoretisch ging auch an/aus (Brightness 0 war aus, alles andere an). Über State (true/false) konnte man generell ein und aus schalten.

Das funktioniert nun nicht mehr. Ich kann die Werte zwar ändern, es werden aber keine Änderungen an die Bulbs übertragen.

Der CC2530 ließ sich bei der ersten Einrichtung (als ioBroker noch auf einem [definition='18','0']Raspberry[/definition] Pi lief) verbinden, seitdem nicht mehr. Ich nehme an, der muss irgendwie resettet werden, damit er eine neue Verbindung annimmt. Das ist aber halb so wild, da ich ja die Hues als Router einsetzen kann.

Eine Hue Bulb habe ich in meinem Flur oben verbunden, damit sie das Signal des Temperatur Sensors im oberen Badezimmer weiterleiten kann; die Verbindung aus dem Badezimmer klappt zwar auch "direkt" (also ohne den Umweg über die Bulb), aber es werden keine Werte übertragen. Der [definition='47','0']Beelink[/definition] mit [definition='64','0']CC2531[/definition] Stick steht im Erdgeschoss in meinem Arbeitszimmer.

Die beiden [definition='62','0']Aqara[/definition] Sensoren liefern ebenfalls unterschiedliche Werte: der im Bad unten (direkt neben dem Arbeitszimmer) zeigt neben Temperature, Humidity, Pressure, Volt (?) auch noch Connection Strength (o.Ä.) und Battery Percent an. Bei dem im oberen Bad fehlen Connection Strength und Battery Percent. Da er sich doch aber hinzufügen lässt (Zigbee Adapter => Suche), muss ja ein Signal da sein. Die Werte des Bad Oben Sensors werden ebenfalls nur sehr sporadisch aktualisiert, weshalb ich den Weg mit der Hue Bulb als Router einschlagen wollte.

Könnt Ihr mir weiterhelfen? Nachdem gestern nichts mehr ging, habe ich /opt/iobroker vollständig gelöscht und nach Anleitung neu erstellt und installiert. ioBroker läuft, der [definition='64','0']CC2531[/definition] lässt sich verbinden. Alles gut. Geräte finden geht auch wieder. Aber die Bulbs lassen sich trotzdem nicht mehr steuern.

Ich scheue mich auch davor, groß weiter herumzuexperimentieren; gestern hatte ich sämtliche Zigbee Geräte mehrfach gelöscht und neu verbunden (um zu sehen, ob die Bulbs dann wieder funktionieren). Ergebnis war, dass die Geräte zwar im Zigbee Adapter und unter Objekte gelöscht waren, aber sobald ich sie neu verbunden hatte wieder die vorher angelegten Werte verfügbar waren (beispielsweise in welchem Raum sich die Sensoren befanden, obwohl sie ja gelöscht und neu angelegt wurden). Daher gehe ich davon aus, dass diese Werte irgendwo zwischengespeichert werden, und je mehr ich da nun herumprobiere, desto mehr "Datenmüll" sammelt sich vermutlich an und erschwert alles noch.

Vielen Dank schon einmal für Eure Hilfe

+1

Habe das selbe Problem. Wenige Steckdosen, und die meisten Lichtschalter ohne Nullleiter.

Habe nun zwar schon extra eine Mauernutfräse angeschafft, um die nötigsten Steckdosen nachrüsten zu können... Aber trotz Industriesaugeranschluss wird das eine staubige Angelegenheit, die ich nach Möglichkeit in einigen Zimmern gerne vermeiden würde.