@TheDamned sagte in Ständiges Disconnect des Admins: Oder weißt du zufällig, was ich machen muss, damit der Pi diese Antenne akzeptiert und damit besser funken kann? nein - Nimm Kabel

@bob-der-1 Ja, das meinte ich. Von nvm bitte die Finger lassen.

@UncleSam Jawoll... das wars dann wohl... die multihost Einstellungen haben dazu geführt, dass nichts zu sehen war, denn der netstat schaut jetzt so aus: pi@All-In-One_RasPi:~ $ netstat -an | grep LISTEN tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN tcp 0 0 10.30.10.101:2001 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 10.30.10.101:2010 0.0.0.0:* LISTEN tcp6 0 0 :::8081 :::* LISTEN tcp6 0 0 :::8082 :::* LISTEN tcp6 0 0 :::22 :::* LISTEN Und schon klappst auch wieder mit dem System... Danke auf jeden Fall mal fürs mit draufschauen und Tip geben...

@Homoran Dank Dir, ich habe neu aufgesetzt und konfiguriere neu. Gruß Gil

@danny_v1 sagte in Deconz hue Lampe Simulieren: Aber wenn man sich mal die Datenpunkte der RGB Lampe anschaut wie schnell diese geändert werden (Lampe kommt eigentlich mit Regeln gar nicht hinterher) und es mit dem Effekt den man erzielt vergleicht. Ist mir die Rechenleistung die der pi mit iobroker aufbringen muss zu hoch Ich denke die Rechenleistung des Pi sind da nicht das Problem. Schwieriger ist da schon die Steuerung der Lampe über deconz / zigbee. Auf diesem Weg ist eine Steuerung schneller als alle 200 ms kritisch. Mit dem Zigbee Adapter ist eine schnellere Steuerung realisierbar (alle 100 ms). Wichtig ist auch - dadurch das Du 2 Lampen ansteuerst (von denen nur eine wirklich genutzt wird) belastest Du das System unnötigerweise. A.

Hallo, noch ein Versuch um Hilfe! Es geht um den "Xiaomi Mi Robot Vacuum Mop Pro Saugroboter mit Wischfunktion" in Verbindung mit dem "mihome-vacuum" Adapter. Hier die Einstellungen: [image: 1609918038745-mihome_main.png] [image: 1609918054957-mihome_setting.png] Instanz auf debug und folgender Log-Auszug: mihome-vacuum.0 2021-01-06 08:14:56.212 debug (6023) sendMsg[1] >>> {"id":5,"method":"get_status"} mihome-vacuum.0 2021-01-06 08:14:56.209 debug (6023) sendTo "getStatus" to system.adapter.mihome-vacuum.0 from system.adapter.mihome-vacuum.0 mihome-vacuum.0 2021-01-06 08:14:56.208 info (6023) connecting, this can take up to 10 minutes ... mihome-vacuum.0 2021-01-06 08:14:56.207 debug (6023) Receive <<< Helo <<< 2131002000000000165d849b5ff5636fffffffffffffffffffffffffffffffff mihome-vacuum.0 2021-01-06 08:14:51.160 debug (6023) sendTo "getStatus" to system.adapter.mihome-vacuum.0 from system.adapter.mihome-vacuum.0 mihome-vacuum.0 2021-01-06 08:14:51.159 debug (6023) no answer for id:4 received, giving up mihome-vacuum.0 2021-01-06 08:14:46.158 debug (6023) sendMsg[3] >>> {"id":4,"method":"get_status"} mihome-vacuum.0 2021-01-06 08:14:41.156 debug (6023) sendMsg[2] >>> {"id":4,"method":"get_status"} mihome-vacuum.0 2021-01-06 08:14:36.156 debug (6023) sendMsg[1] >>> {"id":4,"method":"get_status"} mihome-vacuum.0 2021-01-06 08:14:36.152 debug (6023) sendTo "getStatus" to system.adapter.mihome-vacuum.0 from system.adapter.mihome-vacuum.0 mihome-vacuum.0 2021-01-06 08:14:36.151 info (6023) connecting, this can take up to 10 minutes ... mihome-vacuum.0 2021-01-06 08:14:36.150 debug (6023) Receive <<< Helo <<< 2131002000000000165d849b5ff5635bffffffffffffffffffffffffffffffff mihome-vacuum.0 2021-01-06 08:14:31.214 debug (6023) sendTo "getStatus" to system.adapter.mihome-vacuum.0 from system.adapter.mihome-vacuum.0 mihome-vacuum.0 2021-01-06 08:14:31.213 debug (6023) no answer for id:3 received, giving up mihome-vacuum.0 2021-01-06 08:14:26.212 debug (6023) sendMsg[3] >>> {"id":3,"method":"get_status"} mihome-vacuum.0 2021-01-06 08:14:21.211 debug (6023) sendMsg[2] >>> {"id":3,"method":"get_status"} mihome-vacuum.0 2021-01-06 08:14:16.209 debug (6023) sendMsg[1] >>> {"id":3,"method":"get_status"} mihome-vacuum.0 2021-01-06 08:14:16.202 debug (6023) sendTo "getStatus" to system.adapter.mihome-vacuum.0 from system.adapter.mihome-vacuum.0 mihome-vacuum.0 2021-01-06 08:14:16.201 info (6023) connecting, this can take up to 10 minutes ... mihome-vacuum.0 2021-01-06 08:14:16.200 debug (6023) Receive <<< Helo <<< 2131002000000000165d849b5ff56347ffffffffffffffffffffffffffffffff mihome-vacuum.0 2021-01-06 08:14:11.151 debug (6023) sendTo "getStatus" to system.adapter.mihome-vacuum.0 from system.adapter.mihome-vacuum.0 mihome-vacuum.0 2021-01-06 08:14:11.150 debug (6023) no answer for id:2 received, giving up mqtt.0 2021-01-06 08:14:08.142 info (23843) Client [shelly1-F4CFA27687F9] subscribes on topic "shellies/shelly1-F4CFA27687F9/relay/0/command" mqtt.0 2021-01-06 08:14:08.140 info (23843) Client [shelly1-F4CFA27687F9] subscribes on topic "shellies/shelly1-F4CFA27687F9/command" mihome-vacuum.0 2021-01-06 08:14:06.149 debug (6023) sendMsg[3] >>> {"id":2,"method":"get_status"} mqtt.0 2021-01-06 08:14:05.331 info (23843) Starting MQTT authenticated server on 0.0.0.0:1882 mqtt.0 2021-01-06 08:14:03.850 info (23843) starting. Version 2.1.14 in /opt/iobroker/node_modules/iobroker.mqtt, node: v12.20.0, js-controller: 3.1.6 host.PI-Slave 2021-01-06 08:14:02.185 info instance system.adapter.mqtt.0 started with pid 23843 host.PI-Slave 2021-01-06 08:14:01.157 info Restart adapter system.adapter.mqtt.0 because enabled host.PI-Slave 2021-01-06 08:14:01.152 info instance system.adapter.mqtt.0 scheduled normal terminated and will be restarted on schedule. mihome-vacuum.0 2021-01-06 08:14:01.147 debug (6023) sendMsg[2] >>> {"id":2,"method":"get_status"} mqtt.0 2021-01-06 08:14:00.519 info (23780) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason mqtt.0 2021-01-06 08:14:00.516 info (23780) terminating mqtt.0 2021-01-06 08:14:00.009 info (23780) Scheduled restart. mihome-vacuum.0 2021-01-06 08:13:56.145 debug (6023) sendMsg[1] >>> {"id":2,"method":"get_status"} mihome-vacuum.0 2021-01-06 08:13:56.140 debug (6023) sendTo "getStatus" to system.adapter.mihome-vacuum.0 from system.adapter.mihome-vacuum.0 mihome-vacuum.0 2021-01-06 08:13:56.139 info (6023) connecting, this can take up to 10 minutes ... mihome-vacuum.0 2021-01-06 08:13:56.138 debug (6023) Receive <<< Helo <<< 2131002000000000165d849b5ff56333ffffffffffffffffffffffffffffffff mihome-vacuum.0 2021-01-06 08:13:51.209 debug (6023) sendTo "getStatus" to system.adapter.mihome-vacuum.0 from system.adapter.mihome-vacuum.0 mihome-vacuum.0 2021-01-06 08:13:51.208 debug (6023) no answer for id:1 received, giving up mihome-vacuum.0 2021-01-06 08:13:46.207 debug (6023) sendMsg[3] >>> {"id":1,"method":"get_status"} mihome-vacuum.0 2021-01-06 08:13:41.204 debug (6023) sendMsg[2] >>> {"id":1,"method":"get_status"} mihome-vacuum.0 2021-01-06 08:13:36.621 info (6023) set nächster Timer: Nicht verfügbar mihome-vacuum.0 2021-01-06 08:13:36.203 debug (6023) sendMsg[1] >>> {"id":1,"method":"get_status"} mihome-vacuum.0 2021-01-06 08:13:36.188 debug (6023) sendTo "getStatus" to system.adapter.mihome-vacuum.0 from system.adapter.mihome-vacuum.0 mihome-vacuum.0 2021-01-06 08:13:36.187 info (6023) connecting, this can take up to 10 minutes ... mihome-vacuum.0 2021-01-06 08:13:36.185 debug (6023) Receive <<< Helo <<< 2131002000000000165d849b5ff5631fffffffffffffffffffffffffffffffff mihome-vacuum.0 2021-01-06 08:13:36.153 debug (6023) No suitable Lua script, fallback to keys!: function(doc) { if (doc.type === 'state') emit(doc._id, doc) } mihome-vacuum.0 2021-01-06 08:13:36.114 debug (6023) server started on 0.0.0.0:53421 mihome-vacuum.0 2021-01-06 08:13:36.096 info (6023) Cloud control disabled mihome-vacuum.0 2021-01-06 08:13:36.094 info (6023) Expert mode enabled, states created mihome-vacuum.0 2021-01-06 08:13:36.027 info (6023) starting. Version 2.2.4 in /opt/iobroker/node_modules/iobroker.mihome-vacuum, node: v12.20.0, js-controller: 3.1.6 host.PI-Master 2021-01-06 08:13:33.338 info instance system.adapter.mihome-vacuum.0 started with pid 6023 host.PI-Master 2021-01-06 08:13:30.860 info instance system.adapter.mihome-vacuum.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) mihome-vacuum.0 2021-01-06 08:13:30.305 info (29044) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason mihome-vacuum.0 2021-01-06 08:13:30.304 info (29044) terminating mihome-vacuum.0 2021-01-06 08:13:30.301 info (29044) Got terminate signal TERMINATE_YOURSELF host.PI-Master 2021-01-06 08:13:30.296 info stopInstance system.adapter.mihome-vacuum.0 send kill signal host.PI-Master 2021-01-06 08:13:30.290 info stopInstance system.adapter.mihome-vacuum.0 (force=false, process=true) mihome-vacuum.0 2021-01-06 08:13:24.518 info (29044) connecting, this can take up to 10 minutes ... mihome-vacuum.0 2021-01-06 08:13:04.507 info (29044) connecting, this can take up to 10 minutes ... mihome-vacuum.0 2021-01-06 08:12:44.607 info (29044) connecting, this can take up to 10 minutes ... Was mache ich falsch??? Danke im voraus. Wastl

[Gelöst]

@rupi619 Meist zeigt sich, dass die Problematik höchstens ähnlich ist. Statt als Monate alte Threads wieder aufzuwärmen mach lieber einen neuen eigenen auf, der dann auch die eigenen Daten enthält und nicht nur vermeintlich gleiche.

@smile X ist für die graphische Oberfläche notwendig, das willst du nicht auf einem Serversystem haben. Installier am besten gleich ein System ohne Desktop. In dem neuen System dann erst gar kein node oder npm aus den debian-Repos installieren sondern gleich die Version von nodesource. Macht wie gesagt der Installer. Wenn da wider Erwarten von Haus aus node/npm schon installiert sein sollte, hau es raus: sudo apt remove node* sudo apt remove npm

@SunkHD Nee, keine Datei, das komplette Verzeichnis iobroker-data rekursiv.

Auch wenn es schon lange her ist, vielleicht stolpert ja mal einer der Proxmox Admin's über das gleich Problem ;-) Das Verhalten ist erklärbar falls Proxmox PVE nicht auf einem reinen Debian SERVER läuft sondern ein Desktop Environment wie beispielsweise Gnome installiert wurde. Dann ziehen die Stromsparmechanismen, die ja bei einem DESKTOP-Betriebssystem durchaus Sinn machen.

@Thomas-Braun gut dann muss da was neues her, mit mehr RAM! Danke dir!!!

@MatthiaB sagte in fritzdect.o legt neue Objeke an: @stefande und das mit dem Alias hat nicht funktioniert. Ich haben noch eine 2. die nur zum Test. Da hängt ein Lüfter dran. Gleicher Alias bei SourceAnalytix - hat aber einen neues Objekt dort bekommen... Gut mag bei Sql anders sein. Alias hat mir auch nicht geholfen. Ich hab den Datenpunkt direkt in der SQL Datenbank umbenannt, und konnte somit die alten Werte "retten". Ob man die Datenpunkte auch in der InfluxDB auch umbenennen kann kann ich dir leider nicht sagen.

Sorry falscher Thread...

@fuso Hast du ein Backup von vorher? Dann könntest du versuchen, das zurück zu spielen. Ansonsten gibt es noch den Weg über die Expertenansicht im Objekt-Baum. Aber da kannst du dir ganz viel zerstören. Also unbedingt vorher ein Backup machen. Du kannst die Expertenansicht einschalten (oben in der Toolbar) und dann system.adapter.rpi2.0 sowie system.adapter.rpi2.1 komplett löschen. Danach den Fixer laufen lassen und ioBroker neu starten.

@Rushmed BESTEN DANK! Die Seite kannte ich nicht.

@AFi sagte in [erledigt] Variablen Definieren / Warnmeldungen: Für mich liest der Funktionsblock "Wert von" den Inhalt des Datenpunktes aus, ungeachtet ob Zahl, Bool, String oder Array nicht nur für dich ;-)

@weimaraner sagte in [gelöst] backup eingespielt und nichts passiert - Was nun?: dafür doch viel dazugelernt. dann hat es sich ja gelohnt!