Ja, geht wieder. Ich tippe auf den Server.

@Samson71 ich habe eine Lösung gefunden!!! habe meine 30 der 34 Neuen Geräte aus IOT gelöscht und die 4 Geräte in ALEXA suchen lassen! War erfolgreich. dann habe ich immer 3 Geräte in IOT gebracht und dann ALEXA suchen lassen und auch erfolgreich! bis ich alle neuen Geräte in ALEXA hatte. FAZIT: ALEXA mag nicht wenn sie überfordert wird. ich habe auch nicht ausprobiert ob er mit mehr Geräten geht. Danke für die TIPS

Mittlerweile ist es mir gelungen das Problem zu lösen. Hier mein Vorgehen mit den jeweiligen Ergebnissen .. Neustart des Raspberry Pi 5 -> Fehler unverändert vorhanden. Gerät (Shelly 2.5) kurzzeitig vom Strom getrennt -> Fehler unverändert Alle oben beschrieben Zuordnungen gelöscht und neu konfiguriert -> Fehler unverändert Gerät gelöscht -> Gerät wird im HomeKit nicht mehr angezeigt. Gerät neu eingerichtet -> Gerät funktioniert.

Ich sehe das wie @ticaki , meine Shellys und Tasmotageräte sind nach einem Stromausfall im letzten Status. Und sobald die wieder Strom haben und WLAN, melden dieses den auch wieder an ioBroker. In ioBroker habe ich durchaus Dinge die ich dann zusammenschalte. Da läuft dann neben dem Trigger der auf akute Änderungen reagiert auch ein regelmäßig Task der ggf. abgleicht wenn 2 Dinge voneinander abweichen die nicht abweichen sollen. Bei 2 Shelly gibt der eine dann vor was der andere haben soll. Das Problem sehe ich bei mir eher Theoretisch. Im Gegenteil, mit meinem ioBroker und dem MQTT darauf bringe ich das eher mal durcheinander als die Geräte es ohne könnten. Neulich machte ein Bewegungsmelder und eine Lampe Probleme, nach einem Neustart von ioBroker machte die Lampe Disco. Weil ich im Skript nicht auf einen definierten Startzustand geachtet habe - da spielten 2 Shellys zusammen und die hatten dann eine Kombination die laut meinem Skript gar nicht vorkommen dürfte und es lief Amok.

Meine Strategie für diesen Fall, das System regelmässig neu aufsetzen inkl. aller Adapter. Das leere System in das Isolierte Netzwerk schieben und dann das Backup vom alten System einspielen. So kann man das System Aktuell halten ohne Internet zu brauchen.

@Thomas-Braun sagte in sudo apt full-upgrade mit Medung: Da würde ich dann die Version des Paketbetreuers installieren Habe ich heute auch auf drei Maschinen getan, es funzt.

Puh, nach Update auf DSM 7.3.1 musste ich den cp210x.ko wieder installieren: wget 'https://github.com/robertklep/dsm7-usb-serial-drivers/raw/main/modules/denverton/dsm-7.2/cp210x.ko' Kopieren nach /lib/modules Aktivieren: insmod /lib/modules/cp210x.ko Prüfen: ls -la /dev/ttyU* => ist da! Treiber funktioniert! Rechte: chmod 666 /dev/ttyUSB0 Mein Script unter /usr/local/etc/rc.d/usb-serivl-drivers.sh sieht so aus: #!/bin/sh case $1 in start) insmod /lib/modules/usbserial.ko > /dev/null 2>&1 insmod /lib/modules/ftdi_sio.ko > /dev/null 2>&1 insmod /lib/modules/cdc-acm.ko > /dev/null 2>&1 insmod /lib/modules/cp210x.ko > /dev/null 2>&1 insmod /lib/modules/ch341.ko > /dev/null 2>&1 insmod /lib/modules/pl2303.ko > /dev/null 2>&1 insmod /lib/modules/ti_usb_3410_5052.ko > /dev/null 2>&1 ;; stop) exit 0 ;; *) exit 1 ;; esac

Bei dem Adapter ist aber auch etwas schief gelaufen. Auf Github gibts ne NIEDRIGERE Version als auf npm !?!? ❗ [E2003] Version of package.json (0.4.2) lower than latest version on NPM (0.4.3) Außerdem sollte jedem Benutzer klar sein, dass der Adapter derzeit - waruma uch immer - vom Maintainer NICHT ALS STABIL eingestuft ist und nur als BETA Version zum Testen freigegeben wurde.

Ich habe die gleichen Einstellungen des ELFIN EW11A wie @reini 23.9.25. Für die Kontrolle der ELFIN-Venus Verbindung habe ich das Hercules Setup Utility verwendet bekomme aber keine "recieved data" , also keine Verbindung zum Venus. Um die RS485 Schnittstelle des Venus E 3.0 zu testen habe ich einen CH340 über USB angeschlossen und bekomme auf ein Read Holding (03) des Registers 30100 auch eine Antwort vom Venus über die RS485 Schnittstelle. Ich benutze den RJ45 Stecker des Venus und nehme als Pin belegung 1 RX, 2 TX, 5 Vcc, 8 GND verbunden mit ELFIN 5 RX, 6 TX, 7 Vcc und 8 GND. Stimmt dies so ?

@arteck Frage mich dann nur, warum Adapter A das Gerät automatisch erkennt und Gerät B nicht.

@Int17 Kann ich dir leider nicht mehr sagen, nutze das script nicht mehr so...

keine Anmerkung ;)

...der Adapter "Alarm" hat "nebenbei" auch eine Anwesenheitssimulation integriert, weiss allerdings nicht, ob der auch losgelöst vom Alarmanlagen-Teil funktioniert: https://github.com/misanorot/ioBroker.alarm/blob/master/docs/de/alarm.md#tab-anwesenheit

Danke, werde es mal probieren

Hi, da die Kommunikation ja zu funktionieren scheint, ist es wohl wahrscheinlich das auf der "Allgemeines"-Seite Deiner Modbus-Instanz alles richtig ist, aber zur Sicherheit: TCP, Port 502, Geräte ID 1, mehrere Geräte zugelassen und Typ = Master?

@Asgothian