@icecube86 Schwer zu sagen. Ich betreibe meine ioBroker bereits seit mehr als 4-5 Jahren und solche Ausfälle kommen vor, ohne dass sich immer eine Ursache finden lässt. Häufig beendet ein Restart oder etwas Abwarten den Spuk ohne zusätzlichen Eingriff.

Ich habe das Problem bei mir zwischenzeitlich gelöst (auch mit Hilfe dieses Threads).

Insbesondere habe ich

• den Alexa-Skill von ioBroker de-/aktiviert inkl. erneuter Kontoverknüpfung (auf dem mobilen Gerät)
• die Log-Ausgabe der ioT-Instance auf Debug-Level gesetzt (ioBroker-Admin-Instanz-Tab)
• in der ioT-Instanz die Alexa-Geräte erneut suchen lassen und den Adapter 2x nacheinander neu gestartet.
• im ioBroker-Web unter Diagnose alles auf grün gecheckt
• dabei gleich meine iobroker.pro-Lizenz erneuert (war nicht erforderlich, ist es mir aber wert)

Nach allem habe ich dann auf meinem mobilen Device eine meiner Test-Routinen manuell gestartet (hätte das auch über "Alexa, Telegram-Test" sprechen können).
Fast gleichzeitig konnte ich im ioBroker-Admin-Log-Tab die Meldung sehen:

iot.0
2022-01-28 14:56:17.513	debug	Response: {"header":{"namespace":"Alexa.ConnectedHome.Control","name":"TurnOnConfirmation","payloadVersion":"2","messageId":"6df08bec-c9c6-4702-bee0-1fd273de9784"},"payload":{}}

iot.0
2022-01-28 14:56:17.513	debug	[ALEXA] Set "0_userdata.0.TelegramTest" to true

iot.0
2022-01-28 14:56:17.513	debug	[ALEXA] Controlling: 0_userdata.0.TelegramTest

iot.0
2022-01-28 14:56:17.513	debug	[ALEXA] ALEXA ON: TelegramTest

iot.0
2022-01-28 14:56:17.513	debug	[ALEXA] New Request: TurnOnRequest

iot.0
2022-01-28 14:56:17.513	debug	[ALEXA] Found following devices to control: {"id":"0_userdata.0.TelegramTest","role":"button","name":"Statusmeldung für Telegram","friendlyNames":"Telegramm Test, TelegramTest","byON":false,"nameModified":true,"room":null,"func":null}

Das Log zeigt keine Fehler und es hat in der Tat auch wieder funktioniert.

HTH.

Diese Probleme habe ich seit mehreren Tagen ebenfalls beobachtet: Die Alexa-Steuerung von ioBroker-Datenpunkten, die per SmartName und IoT eingebunden sind, funktioniert leider nicht mehr.

Als Ergänzung: .TS bzw. .LC werden im Bereich 0_userdata.0.xxx bei einem get-Request nicht korrekt ausgegeben. Auch dann nicht, wenn Werte per Script mit ack=true eingetragen und/oder geändert werden. Im Web-Admin werden diese Daten dagegen immer korrekt dargestellt. Der eigentliche Wert stimmt bei Get-Abfrage, inkorrekt sind die Bulk-Wert .ts und .lc.

Bei durch Adapter geschriebenen Werte werden .ts und .lc korrekt aktualisiert.

Es wäre schön, wenn dieser Code ins Repo eingepflegt werden kann, damit bei Adapter-Aktualisierungen die Änderungen nicht überschrieben werden.

Vielleicht liest ja auch Github user diginix hier mit und kann das bei Gelegenheit noch umsetzen.

Vielen Dank auf jeden Fall schon mal von mir.

In den Github issues bin ich fündig geworden:

Dazu editiert man die Device-Datei (unter Windows z.B. hier: "C:\Program Files\iobroker\SmartHome\node_modules\iobroker.mihome\lib\devices.js" mit notepad++) und ergänzt sie mit diesem Eintrag:

    remote_b286acn02: {type: 'remote.b286acn02',   fullName: 'Xiaomi Aqara Wireless Remote Switch (Double Rocker)', ClassName: WallButtons, states: {
            voltage:          states.voltage,
            percent:          states.percent,

            channel_0:        states.channel_0,
            channel_0_double: states.channel_0_double,
            channel_0_long:   states.channel_0_long,
            channel_1:        states.channel_1,
            channel_1_double: states.channel_1_double,
            channel_1_long:   states.channel_1_long,
            dual_channel:     states.dual_channel,
        }
    },

Alternativ ersetzt man einfach die komplette Datei mit der im obigen Link verfügbaren Version.

Die Erkennung funktioniert nach Neustart des mi home Adapters.

Leider lässt sich zurzeit der D1 Wireless Remote Switch (Double Rocker) noch nicht als MiHome-Objekt ansprechen. Log-Eintrag:

(1244) Could not add new sensor: Type "remote.b286acn02" is not valid, use one of Hub::sensorTypes

Gibt es dazu eventuell schon ein Plan für die Implementierung?

Vielen Dank.

[ v3.2.1 ]
Bislang habe ich die HUE Dimmer switch button per red node flows ausgewertet. Bei der Umstellung auf JS wollte ich nun auf die Änderung der ID ".buttonivent" triggern. Dabei fällt auf, dass bei wiederholtem Drücken derselben Dimmer-Taste nur ".lastupdatet", aber leider nicht ".buttonevent" aktualisiert wird. Das betrifft sowohl den Wert als auch den Zeitstempel.

Natürlich kann ich im Script auch auf ".lastupdatet" reagieren und ".buttonevent" auswerten, aber vielleicht kann man diese Verhalten konsitent gestalten.

@ostseereiter
Factory Reset/Werkseinstellung soll wohl 10/30 sec Knopfdrücken bewirken. Wäre ein Versuch wert.

Siehst Du das GW in MiHome-App?

@ostseereiter sagte in Xiaomi Gateway V3 will nicht in ioBroker:

auch ich habe momentan Probleme mit den Gateways ich sehe zwar alle im iobroker aber einen von 3 sehe ich nicht in der App bekomme diesen auch nicht mehr installiert im Netzwerk wird dieser noch erkannt nur er kann sich nicht mit dem Internet verbinden so das dann die Installation abgeschlossen werden kann. auch einige Temperatur und Fenstersensoren fangen an zu spinnen sind offline oder werden nicht mehr aktualisiert. So langsam werde ich wieder auf Homematic umsteigen sind zwar teurer aber funktionieren.

Du kannst das Problem-GW erneut verbinden, indem Du die GW-Taste 5 sec. drückst und in der Mi-Home-App das GW zuvor löschst und anschließend als neu hinzufügst (also mit + und WLAN-Parameter setzen etc.). Keine Sorge, die angelernten Sensoren/Geräte sowie die NW-Einstellungen bleiben dabei erhalten.

Das Problem mit Offline-Sensoren habe ich auch (scheint mit dem letzen FW-Update 1.4.1.170 wohl wieder besser zu sein). Leider "mault" meine iOS-App nun etwas von "poor network connection", wo eine Android-App allerdings keine Probleme sieht. Merkwürdig.

Ich habe nicht nur mit einigen meiner >100 Xiaomi-Zigbee-Sensoren Probleme, sondern auch mit den Osram-Zigbee-Plugs unter HUE, die ebenfalls nicht zuverlässig erreichbar sind. Eigentlich sollten die Zigbee-Teile doch meshen?!

Hier etwas für die Schadenfreu(n)de: Ist es beim Licht vielleicht nicht so tragisch, erzeugen ein inaktiver Fenster-Sensor bei der Kombi Dachfenster/Regen oder ein nicht reagierender Plug bei nächtlicher Gartenberegnung (dadurch Laufzeit von mehr als 5h!) schon ziemlich Ärger.

@neo4a
So, nun habe ich die 2 Problem-GW genau nach dieser Anleitung behandelt und nun laufen sie auch.

FAQ:

Benutzen Sie einen speziellen Schraubendreher (wie eine Gabel) zum Öffnen des Gateway-Gehäuses.
Benutzen Sie eine UART-Kabel/Karte wie diese.
Löten Sie 3 Drähte GND und RX / TX wie hier im Bild .
Trennen Sie das RX-Kabel vom UART-Modul, sonst bootet das Gerät nicht.
Verbinden Sie Vcc (Power) nicht von UART mit dem Gateway.
Schalten Sie das Gateway ein (220V).
Öffnen Sie die Putty verbinden Sie sich mit der seriellen Schnittstelle (COM1-30) - wählen Sie Ihre Einstellung (siehe z.B. Windows-Gerätemanager).
Warten Sie auf die vollständige Booten des Gateways, verbinden Sie das RX-Kabel mit UART.
Sie werden alle Nachrichten des Gateways sehen.
Senden Sie den Befehl psm-set network.open_pf 3 (markieren und im Windows-Putty-Fenster mit rechter Maus einfügen)
Senden Sie ihn wiederholt, denn er kann verloren gehen (in Putty einfach Pfeil-Hoch-Taste und Enter)
Überprüfen Sie Ihren Parameter mit dem Befehl psm-get network.open_pf, um sicherzustellen, dass er OK ist (muss mit 3 angegeben sein).

Schalten Sie das Gateway aus.
Schalten Sie es ein.
Überprüfen Sie Ihren Port bzw. den Objektbaum in ioBroker-Admin, wo das GW automatisch erscheint, wenn der GW-Key und die IP in den Adapter korrekt hinterlegt wurden.

(Übersetzt mit www.DeepL.com/Translator)

Meine Problemstellen (passender Schraubenzieher und USB UART waren vorhanden):

1. Löten
2. Rx und TX mussten vertauscht werden
3. Wenn putty die Verbindung hat, dann sieht man die Kommandos, die aus der MiHome-App ausgelöst werden, wie z.B. Licht an/aus
4. Mit angestecktem UART bootet das GW nicht, deshalb beim Neustart besser trennen.