Bis jetzt läuft es wieder mit der neuen Version wie es soll.

so, habe ich. nochmals dankeschön.

Jetzt, hatte zwar eine Regel drinne aber der Datenpunkt hat doch etwas länger gebraucht bis er erschienen ist. Vielen Dank für die Hilfe!

Was passiert denn wenn du den Adapter startest?

Hi, nur Admin und Discovery ist normal. Entweder Discovery dann automatisch nach HW im Netzwerk suchen lassen, wenn passende HW gefunden wird installiert sich der Adapter dazu. Oder die benötigten Adapter manuell installieren. Gruß

Die Aufteilung auf 2 Instanzen hat leider keine Besserung gebracht. Es reconnecten nun auch Sonoffs, welche ich unverändert mit alter Firmware belassen habe und die bisher stabil waren.

Hallo an die Experten. Wie kann ich denn das manuell von github installieren? Gibt es ein Download dafür?

Da ist derzeit wohl wieder ein Bug bei Terminserien drin. Habe ich auf Github schon gemeldet. Kannst Dein Problem dort auch eintragen, vielleicht gehts dann schneller ;)

Ich habe das gleiche Problem. Habe Radar 1.1.3 installiert und Adapter wird ständig neu gestartet. [image: 9039_bildschirmfoto-2018-11-05-um-11.27.30.jpg] Das der Beitrag hier als "gelöst" angezeigt wird, habe ich hier einen Neuen eröffnet. viewtopic.php?f=20&t=18234

Wenn im DP unter "unit" eine Einheit eingetragen ist, dann kann da alles ach bei einer Zahl stehen und hat mit Text nichts zu tun ;)

Konnte bei mir das gleiche beobachten. Der Admin-Adapter war's, den hab ich von Version 3.4.7 auf 3.5.10 geupdated, dann hat's funktioniert. Der Thread sollte auf [gelöst] gesetzt werden find ich.

Jetzt brauche ich doch mal wieder fachmännischen Rat. Ich taste mich gerade Schritt für Schritt an die Geschichte ran. Proxmox läuft und eine VM (für iobroker) mit Debian 9 läuft auch bereits. Jetzt scheitere ich aber gerade an der OnBoard Bluetooth Funktionalität :roll: Ich bekomme es einfach nicht zum laufen, bzw. durchgereicht. Ich habe bereits das Forum durchsucht, und die dort gefundenen Schritte ausprobiert: viewtopic.php?f=8&t=16420&p=173483 Leider Kein Erfolg. Ob es an der 8. Generation liegt, dass die Dateien: ` > - iwlwifi-8265-21.ucode iwlwifi-8265-27.ucode iwlwifi-8265-31.ucode iwlwifi-8265-34.ucode iwlwifi-8265-36.ucode iwlwifi-8265-22.ucode ` im Ordner /lib/firmware keinen Erfolg bringen? Ich muss auch zugeben, das ich nicht immer so recht weiss, wer jetzt diese Infos braucht. Das Linux unter Proxmox oder die Debian VM? Ich bin auch nicht so ein Freund davon, sinnlos irgendwelche Linux-Befehle einzuhacken die man so im Netz findet, wenn man nicht genau weis was diese tun. Kann mir vielleicht jemand helfen? Ich weiß echt nicht mehr weiter

Hallo, das ist meines Wissens mit Yahka nicht möglich. Die einzige Idee: Mittels Script (z.B. Blockly) ein eigenes Objekt erstellen. Dieses Objekt liefert nur "true/false" für Homebridge und kümmert sich im Hintergrund um die Umsetzung: Teil 1: Bei Änderung des Modbus-Lampenstatus ändert das Script den Wert des eigenen JS-Objekt. Teil 2: Bei Änderung des Werts des JS-Objekts wird, sofern sich dieser vom Modbus-Lampenstatus unterscheidet, der Pulse ausgelöst. Gruss Ralf

Vielen Dank. Dank der Hinweise von Stabilostick und AlCalzone läßt sich der Adapter wieder installieren.

Volltreffer !!! mit Version 1.9.3 aus Github gehts ! Keine Meldungen mehr und wird alles sauber geschrieben !!! DANKE

Die Daten kommen von einem ESP8266 und von Mqtt.fx Gruß, Haggi

Ok, hat sich jetzt erledigt. Ich bin vom mqtt Adapter auf den mqtt-client gewechselt und schon lief das ganze Zeug wieder.

na schau… geht doch :lol:

Hallo, bei mir sieht die Meldung so aus: ( 3.7 ) Received TUNNEL_REQUEST, but srcAdrOwn : � == [object Object]srcAdrmessage Leider habe ich keine Ahnung, was das bedeuten soll… Bei mir funktioniert die KNX-Steuerung vom ioBroker nicht. Mein ioBroker hört nur zu ;) VG. Roman