VIS nach einigen Monaten recht träge
-
Der Report läuft seit knapp einer viertel Stunde.
Okay- verstanden, dann werde ich wohl doch auf eine Proxmox VM migrieren müssen um mehr RAM zur Verfügung zu haben.
Sobald iob diag durch ist poste ich hier
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
dann werde ich wohl doch auf eine Proxmox VM migrieren müssen um mehr RAM zur Verfügung zu haben.
Dann pfleg das System dort besser als das jetzige.
-
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
dann werde ich wohl doch auf eine Proxmox VM migrieren müssen um mehr RAM zur Verfügung zu haben.
Dann pfleg das System dort besser als das jetzige.
@thomas-braun said in VIS nach einigen Monaten recht träge:
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
dann werde ich wohl doch auf eine Proxmox VM migrieren müssen um mehr RAM zur Verfügung zu haben.
Dann pfleg das System dort besser als das jetzige.
Bin für tipps dankbar.
-
@thomas-braun said in VIS nach einigen Monaten recht träge:
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
dann werde ich wohl doch auf eine Proxmox VM migrieren müssen um mehr RAM zur Verfügung zu haben.
Dann pfleg das System dort besser als das jetzige.
Bin für tipps dankbar.
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
Bin für tipps dankbar.
Was meinst du?
Ich spreche z. B. vonPending Updates: 95
nodejs v14.20.1 -
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
Bin für tipps dankbar.
Was meinst du?
Ich spreche z. B. vonPending Updates: 95
nodejs v14.20.1@thomas-braun Ich habe darauf geachtet, dass regelmäßig die Instanzen oder Host upgedatet werden. Um das Linux System habe ich mich mangels Kenntnissen wenig gekümmert.
sind
apt-get update
apt-get upgradedie richtigen Befehle um die Baustelle mit Pending Updates zu fixen?
-
@thomas-braun Ich habe darauf geachtet, dass regelmäßig die Instanzen oder Host upgedatet werden. Um das Linux System habe ich mich mangels Kenntnissen wenig gekümmert.
sind
apt-get update
apt-get upgradedie richtigen Befehle um die Baustelle mit Pending Updates zu fixen?
sudo apt update sudo apt full-upgradeFür nodejs schau in meiner Signatur, da muss die nodesource.list angepasst werden.
Um eine potentere Lösung kommst du aber nicht herum. -
@thomas-braun said in VIS nach einigen Monaten recht träge:
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
dann werde ich wohl doch auf eine Proxmox VM migrieren müssen um mehr RAM zur Verfügung zu haben.
Dann pfleg das System dort besser als das jetzige.
Bin für tipps dankbar.
@christobal0815 und die ein oder andere verzichtbare Instanz vorübergehend stilllegen, um Ram zu sparen
z.b. discovery -
@christobal0815 und die ein oder andere verzichtbare Instanz vorübergehend stilllegen, um Ram zu sparen
z.b. discoveryNach einem Hardware Update und Umzug auf besagte Hardware läuft das System wieder.
Leider hat sich die Performance nicht wesentlich verbessert. Ich bin der Meinung, dass das System damals wesentlich flotter war. Schade ... :(`` ======================= SUMMARY ======================= v.2023-04-16 Operatingsystem: Ubuntu 22.04.2 LTS Kernel: 5.15.0-76-generic Installation: kvm Timezone: Etc/UTC (UTC, +0000) User-ID: 1000 X-Server: false Boot Target: graphical.target Pending OS-Updates: 0 Pending iob updates: 0 Nodejs-Installation: /usr/bin/nodejs v18.16.1 /usr/bin/node v18.16.1 /usr/bin/npm 9.5.1 /usr/bin/npx 9.5.1 Recommended versions are nodejs 18.x.y and npm 9.x.y Your nodejs installation is correct MEMORY: total used free shared buff/cache available Mem: 5.8G 990M 3.9G 1.0M 934M 4.5G Swap: 0B 0B 0B Total: 5.8G 990M 3.9G Active iob-Instances: 14 Active repo(s): stable ioBroker Core: js-controller 4.0.24 admin 6.3.5 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.0 : admin : ioBroker - enabled, port: 8081, bind: 0.0.0.0, run as: admin + system.adapter.web.0 : web : ioBroker - enabled, port: 8082, bind: 0.0.0.0, run as: admin Objects: 7488 States: 6064 Size of iob-Database: 8.2M /opt/iobroker/iobroker-data/objects.jsonl 2.1M /opt/iobroker/iobroker-data/states.jsonl =================== END OF SUMMARY ====================chris@ioBroker:~$ ======================= SUMMARY =======================
v.2023-04-16Operatingsystem: Ubuntu 22.04.2 LTS
Kernel: 5.15.0-76-generic
Installation: kvm
Timezone: Etc/UTC (UTC, +0000)
User-ID: 1000
X-Server: false
Boot Target: graphical.targetPending OS-Updates: 0
Pending iob updates: 0Nodejs-Installation: /usr/bin/nodejs v18.16.1
/usr/bin/node v18.16.1
/usr/bin/npm 9.5.1
/usr/bin/npx 9.5.1Recommended versions are nodejs 18.x.y and npm 9.x.y
Your nodejs installation is correctMEMORY:
total used free shared buff/cache available
Mem: 5.8G 990M 3.9G 1.0M 934M 4.5G
Swap: 0B 0B 0B
Total: 5.8G 990M 3.9GActive iob-Instances: 14
Active repo(s): stableioBroker Core: js-controller 4.0.24
admin 6.3.5ioBroker Status: iobroker is running on this host.
Objects type: jsonl
States type: jsonlStatus admin and web instance:
- system.adapter.admin.0 : admin : ioBroker - enabled, port: 8081, bind: 0.0.0.0, run as: admin
- system.adapter.web.0 : web : ioBroker - enabled, port: 8082, bind: 0.0.0.0, run as: admin
Objects: 7488
States: 6064Size of iob-Database:
8.2M /opt/iobroker/iobroker-data/objects.jsonl
2.1M /opt/iobroker/iobroker-data/states.jsonl=================== END OF SUMMARY ====================
-
Nach einem Hardware Update und Umzug auf besagte Hardware läuft das System wieder.
Leider hat sich die Performance nicht wesentlich verbessert. Ich bin der Meinung, dass das System damals wesentlich flotter war. Schade ... :(`` ======================= SUMMARY ======================= v.2023-04-16 Operatingsystem: Ubuntu 22.04.2 LTS Kernel: 5.15.0-76-generic Installation: kvm Timezone: Etc/UTC (UTC, +0000) User-ID: 1000 X-Server: false Boot Target: graphical.target Pending OS-Updates: 0 Pending iob updates: 0 Nodejs-Installation: /usr/bin/nodejs v18.16.1 /usr/bin/node v18.16.1 /usr/bin/npm 9.5.1 /usr/bin/npx 9.5.1 Recommended versions are nodejs 18.x.y and npm 9.x.y Your nodejs installation is correct MEMORY: total used free shared buff/cache available Mem: 5.8G 990M 3.9G 1.0M 934M 4.5G Swap: 0B 0B 0B Total: 5.8G 990M 3.9G Active iob-Instances: 14 Active repo(s): stable ioBroker Core: js-controller 4.0.24 admin 6.3.5 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.0 : admin : ioBroker - enabled, port: 8081, bind: 0.0.0.0, run as: admin + system.adapter.web.0 : web : ioBroker - enabled, port: 8082, bind: 0.0.0.0, run as: admin Objects: 7488 States: 6064 Size of iob-Database: 8.2M /opt/iobroker/iobroker-data/objects.jsonl 2.1M /opt/iobroker/iobroker-data/states.jsonl =================== END OF SUMMARY ====================chris@ioBroker:~$ ======================= SUMMARY =======================
v.2023-04-16Operatingsystem: Ubuntu 22.04.2 LTS
Kernel: 5.15.0-76-generic
Installation: kvm
Timezone: Etc/UTC (UTC, +0000)
User-ID: 1000
X-Server: false
Boot Target: graphical.targetPending OS-Updates: 0
Pending iob updates: 0Nodejs-Installation: /usr/bin/nodejs v18.16.1
/usr/bin/node v18.16.1
/usr/bin/npm 9.5.1
/usr/bin/npx 9.5.1Recommended versions are nodejs 18.x.y and npm 9.x.y
Your nodejs installation is correctMEMORY:
total used free shared buff/cache available
Mem: 5.8G 990M 3.9G 1.0M 934M 4.5G
Swap: 0B 0B 0B
Total: 5.8G 990M 3.9GActive iob-Instances: 14
Active repo(s): stableioBroker Core: js-controller 4.0.24
admin 6.3.5ioBroker Status: iobroker is running on this host.
Objects type: jsonl
States type: jsonlStatus admin and web instance:
- system.adapter.admin.0 : admin : ioBroker - enabled, port: 8081, bind: 0.0.0.0, run as: admin
- system.adapter.web.0 : web : ioBroker - enabled, port: 8082, bind: 0.0.0.0, run as: admin
Objects: 7488
States: 6064Size of iob-Database:
8.2M /opt/iobroker/iobroker-data/objects.jsonl
2.1M /opt/iobroker/iobroker-data/states.jsonl=================== END OF SUMMARY ====================
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
Leider hat sich die Performance nicht wesentlich verbessert. Ich bin der Meinung, dass das System damals wesentlich flotter war. Schade
Definiere es etwas genauer, was war flotter?
-
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
Leider hat sich die Performance nicht wesentlich verbessert. Ich bin der Meinung, dass das System damals wesentlich flotter war. Schade
Definiere es etwas genauer, was war flotter?
@crunchip
Ich mache es einmal am Beispiel eines Bildes deutlich.
Früher konnte ich auf ein Rollo-Symbol drücken und die Jalousie fuhr nach ca. 2 oder 3 Sekunde nach ob bzw. nach unten.
Jetzt dauert es Handgestoppte 9 Sekunden bis nach Druck auf das Symbol etwas passiert. Das hat sich leider mit der neuen VM nicht verbessert.Prüfe ich im KNX-Monitor wann die Befehle auf den KNX-BUS kommen sehe ich, dass das Ansprechen der entsprechenden GA die besagten 9 Sekunden dauert. Sobald es auf dem KNX-BUS ist fährt die Jalousie direkt. Ich habe das früher nie im Detail analysiert. Jetzt ist es aber wirklich störend, weil man nach dem Absetzen der Befehle ewig warten muss.
Noch ein Phänomen: Fahre ich die selbe Jalousie über "Objekte" in ioBroker und nicht über VIS dauert das Hochfahren nach Klick auf set value 3 Sekunden, Verändere ich das Objekt wieder dauert es bis er darauf reagiert 7 Sekunden. Für mich macht das alles keinen Sinn.
Würde es helfen, wenn ich history-DB und das loggen gewisser datenpunkte deaktivieren würde und eine Slave-VM aufziehe, die solche Aktivitäten durchführt? Hauptsache meine Frau ist zufrieden ;)
-
@crunchip
Ich mache es einmal am Beispiel eines Bildes deutlich.
Früher konnte ich auf ein Rollo-Symbol drücken und die Jalousie fuhr nach ca. 2 oder 3 Sekunde nach ob bzw. nach unten.
Jetzt dauert es Handgestoppte 9 Sekunden bis nach Druck auf das Symbol etwas passiert. Das hat sich leider mit der neuen VM nicht verbessert.Prüfe ich im KNX-Monitor wann die Befehle auf den KNX-BUS kommen sehe ich, dass das Ansprechen der entsprechenden GA die besagten 9 Sekunden dauert. Sobald es auf dem KNX-BUS ist fährt die Jalousie direkt. Ich habe das früher nie im Detail analysiert. Jetzt ist es aber wirklich störend, weil man nach dem Absetzen der Befehle ewig warten muss.
Noch ein Phänomen: Fahre ich die selbe Jalousie über "Objekte" in ioBroker und nicht über VIS dauert das Hochfahren nach Klick auf set value 3 Sekunden, Verändere ich das Objekt wieder dauert es bis er darauf reagiert 7 Sekunden. Für mich macht das alles keinen Sinn.
Würde es helfen, wenn ich history-DB und das loggen gewisser datenpunkte deaktivieren würde und eine Slave-VM aufziehe, die solche Aktivitäten durchführt? Hauptsache meine Frau ist zufrieden ;)
Bin leider kein Experte auf dem Gebiet.
Sind evtl. irgendwelche Services auffällig?
top - 07:12:24 up 7:28, 1 user, load average: 0,06, 0,06, 0,02 Tasks: 118 total, 1 running, 117 sleeping, 0 stopped, 0 zombie %Cpu(s): 1,5 us, 0,3 sy, 0,0 ni, 98,0 id, 0,0 wa, 0,0 hi, 0,2 si, 0,0 st MiB Mem : 5779,9 total, 3387,7 free, 1237,9 used, 1154,4 buff/cache MiB Swap: 0,0 total, 0,0 free, 0,0 used. 4275,1 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3979 iobroker 20 0 1149560 282348 43976 S 2,3 4,8 11:19.24 iobroker.js-con 4159 iobroker 20 0 688388 80856 38736 S 1,0 1,4 0:18.80 io.doorbird.1 4039 iobroker 20 0 832440 167532 43612 S 0,7 2,8 1:29.53 io.javascript.0 14 root 20 0 0 0 0 I 0,3 0,0 0:05.97 rcu_sched 416 root 20 0 0 0 0 I 0,3 0,0 0:04.59 kworker/0:4-mm_percpu_wq 4099 iobroker 20 0 955992 90664 38720 S 0,3 1,5 1:47.48 io.tr-064.0 4204 iobroker 20 0 683228 76548 39056 S 0,3 1,3 0:16.55 io.trashschedul 1 root 20 0 102148 12940 8136 S 0,0 0,2 0:04.96 systemd 2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd 3 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_par_gp 5 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 slub_flushwq 6 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 netns 8 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kworker/0:0H-events_highpri 10 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 mm_percpu_wq 11 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_tasks_rude_ 12 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_tasks_trace 13 root 20 0 0 0 0 S 0,0 0,0 0:00.68 ksoftirqd/0 15 root rt 0 0 0 0 S 0,0 0,0 0:00.32 migration/0 16 root -51 0 0 0 0 S 0,0 0,0 0:00.00 idle_inject/0 18 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/0 19 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/1 20 root -51 0 0 0 0 S 0,0 0,0 0:00.00 idle_inject/1 21 root rt 0 0 0 0 S 0,0 0,0 0:00.61 migration/1 22 root 20 0 0 0 0 S 0,0 0,0 0:00.35 ksoftirqd/1 24 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kworker/1:0H-events_highpri 25 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kdevtmpfs 26 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 inet_frag_wq 27 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kauditd 28 root 20 0 0 0 0 S 0,0 0,0 0:00.02 khungtaskd 29 root 20 0 0 0 0 S 0,0 0,0 0:00.00 oom_reaper 30 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 writeback 31 root 20 0 0 0 0 S 0,0 0,0 0:01.94 kcompactd0 32 root 25 5 0 0 0 S 0,0 0,0 0:00.00 ksmd 33 root 39 19 0 0 0 S 0,0 0,0 0:00.00 khugepaged 80 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kintegrityd 81 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kblockd 82 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 blkcg_punt_bio 83 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 tpm_dev_wq 84 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 ata_sff 85 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 md 86 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 edac-poller 87 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 devfreq_wq 88 root -51 0 0 0 0 S 0,0 0,0 0:00.00 watchdogd 90 root 0 -20 0 0 0 I 0,0 0,0 0:00.25 kworker/0:1H-kblockd 91 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kswapd0 92 root 20 0 0 0 0 S 0,0 0,0 0:00.00 ecryptfs-kthrea 94 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kthrotld 95 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 acpi_thermal_pm 97 root 20 0 0 0 0 S 0,0 0,0 0:00.00 scsi_eh_0 98 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 scsi_tmf_0 99 root 20 0 0 0 0 S 0,0 0,0 0:00.00 scsi_eh_1 100 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 scsi_tmf_1 102 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 vfio-irqfd-clea 103 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 mld 104 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 ipv6_addrconf -
@crunchip
Ich mache es einmal am Beispiel eines Bildes deutlich.
Früher konnte ich auf ein Rollo-Symbol drücken und die Jalousie fuhr nach ca. 2 oder 3 Sekunde nach ob bzw. nach unten.
Jetzt dauert es Handgestoppte 9 Sekunden bis nach Druck auf das Symbol etwas passiert. Das hat sich leider mit der neuen VM nicht verbessert.Prüfe ich im KNX-Monitor wann die Befehle auf den KNX-BUS kommen sehe ich, dass das Ansprechen der entsprechenden GA die besagten 9 Sekunden dauert. Sobald es auf dem KNX-BUS ist fährt die Jalousie direkt. Ich habe das früher nie im Detail analysiert. Jetzt ist es aber wirklich störend, weil man nach dem Absetzen der Befehle ewig warten muss.
Noch ein Phänomen: Fahre ich die selbe Jalousie über "Objekte" in ioBroker und nicht über VIS dauert das Hochfahren nach Klick auf set value 3 Sekunden, Verändere ich das Objekt wieder dauert es bis er darauf reagiert 7 Sekunden. Für mich macht das alles keinen Sinn.
Würde es helfen, wenn ich history-DB und das loggen gewisser datenpunkte deaktivieren würde und eine Slave-VM aufziehe, die solche Aktivitäten durchführt? Hauptsache meine Frau ist zufrieden ;)
@christobal0815 mal ehrlich?
wie kommst du da auf vis als Verursacher?
für mich dieht das nach einem KNX Problem aus.
zumindest der größte Anteil der "Verzögerung"ob KNX selbst oder der Adapter kann ich nicht beurteilen.
-
@crunchip
Ich mache es einmal am Beispiel eines Bildes deutlich.
Früher konnte ich auf ein Rollo-Symbol drücken und die Jalousie fuhr nach ca. 2 oder 3 Sekunde nach ob bzw. nach unten.
Jetzt dauert es Handgestoppte 9 Sekunden bis nach Druck auf das Symbol etwas passiert. Das hat sich leider mit der neuen VM nicht verbessert.Prüfe ich im KNX-Monitor wann die Befehle auf den KNX-BUS kommen sehe ich, dass das Ansprechen der entsprechenden GA die besagten 9 Sekunden dauert. Sobald es auf dem KNX-BUS ist fährt die Jalousie direkt. Ich habe das früher nie im Detail analysiert. Jetzt ist es aber wirklich störend, weil man nach dem Absetzen der Befehle ewig warten muss.
Noch ein Phänomen: Fahre ich die selbe Jalousie über "Objekte" in ioBroker und nicht über VIS dauert das Hochfahren nach Klick auf set value 3 Sekunden, Verändere ich das Objekt wieder dauert es bis er darauf reagiert 7 Sekunden. Für mich macht das alles keinen Sinn.
Würde es helfen, wenn ich history-DB und das loggen gewisser datenpunkte deaktivieren würde und eine Slave-VM aufziehe, die solche Aktivitäten durchführt? Hauptsache meine Frau ist zufrieden ;)
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
Fahre ich die selbe Jalousie über "Objekte" in ioBroker und nicht über VIS dauert das Hochfahren nach Klick auf set value 3
Also liegt dein Problem doch eher am Frontend und nicht direkt an iobroker
Welche web Einstellung nutzt du?Edit
Falsch gelesen, auch das zurückstellen dauert dann so lange, dann liegt der Fehler womöglich wo anders
-
@christobal0815 mal ehrlich?
wie kommst du da auf vis als Verursacher?
für mich dieht das nach einem KNX Problem aus.
zumindest der größte Anteil der "Verzögerung"ob KNX selbst oder der Adapter kann ich nicht beurteilen.
@homoran said in VIS nach einigen Monaten recht träge:
@christobal0815 mal ehrlich?
wie kommst du da auf vis als Verursacher?
für mich dieht das nach einem KNX Problem aus.
zumindest der größte Anteil der "Verzögerung"ob KNX selbst oder der Adapter kann ich nicht beurteilen.
KNX selbst würde ich ausschließen, da die Verarbeitung sehr schnell funktioniert sobald ich die Adressen auf dem Gruppenmonitor sende. Okay, dann würde ich mich einmal auf den KNX-Adapter in iobroker konzentrieren. Danke!
-
@crunchip
Ich mache es einmal am Beispiel eines Bildes deutlich.
Früher konnte ich auf ein Rollo-Symbol drücken und die Jalousie fuhr nach ca. 2 oder 3 Sekunde nach ob bzw. nach unten.
Jetzt dauert es Handgestoppte 9 Sekunden bis nach Druck auf das Symbol etwas passiert. Das hat sich leider mit der neuen VM nicht verbessert.Prüfe ich im KNX-Monitor wann die Befehle auf den KNX-BUS kommen sehe ich, dass das Ansprechen der entsprechenden GA die besagten 9 Sekunden dauert. Sobald es auf dem KNX-BUS ist fährt die Jalousie direkt. Ich habe das früher nie im Detail analysiert. Jetzt ist es aber wirklich störend, weil man nach dem Absetzen der Befehle ewig warten muss.
Noch ein Phänomen: Fahre ich die selbe Jalousie über "Objekte" in ioBroker und nicht über VIS dauert das Hochfahren nach Klick auf set value 3 Sekunden, Verändere ich das Objekt wieder dauert es bis er darauf reagiert 7 Sekunden. Für mich macht das alles keinen Sinn.
Würde es helfen, wenn ich history-DB und das loggen gewisser datenpunkte deaktivieren würde und eine Slave-VM aufziehe, die solche Aktivitäten durchführt? Hauptsache meine Frau ist zufrieden ;)
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
Verändere ich das Objekt wieder dauert es bis er darauf reagiert 7 Sekunden.
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
fuhr nach ca. 2 oder 3 Sekunde nach ob bzw. nach unten.
Jetzt dauert es Handgestoppte 9 Sekunden -
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
Fahre ich die selbe Jalousie über "Objekte" in ioBroker und nicht über VIS dauert das Hochfahren nach Klick auf set value 3
Also liegt dein Problem doch eher am Frontend und nicht direkt an iobroker
Welche web Einstellung nutzt du?Edit
Falsch gelesen, auch das zurückstellen dauert dann so lange, dann liegt der Fehler womöglich wo anders
@crunchip said in VIS nach einigen Monaten recht träge:
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
Fahre ich die selbe Jalousie über "Objekte" in ioBroker und nicht über VIS dauert das Hochfahren nach Klick auf set value 3
Also liegt dein Problem doch eher am Frontend und nicht direkt an iobroker
Welche web Einstellung nutzt du?Ich hatte oben 2 Screenshot von der Web-Instanz gepostet. Falls ich noch weitere Sachen posten soll, dann gerne bescheid geben
-
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
Verändere ich das Objekt wieder dauert es bis er darauf reagiert 7 Sekunden.
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
fuhr nach ca. 2 oder 3 Sekunde nach ob bzw. nach unten.
Jetzt dauert es Handgestoppte 9 Sekunden@homoran said in VIS nach einigen Monaten recht träge:
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
Verändere ich das Objekt wieder dauert es bis er darauf reagiert 7 Sekunden.
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
fuhr nach ca. 2 oder 3 Sekunde nach ob bzw. nach unten.
Jetzt dauert es Handgestoppte 9 SekundenEs ist für mich nicht reproduzierbar. Gerade eben brauchte der Rollo nach klick in VIS zum hochfahren 8 Sekunden, beim Klick runter fahren hat er in 3 Sekunden reagiert. Ich kann es nicht wirklich nachvollziehen was da schlief läuft
-
@crunchip said in VIS nach einigen Monaten recht träge:
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
Fahre ich die selbe Jalousie über "Objekte" in ioBroker und nicht über VIS dauert das Hochfahren nach Klick auf set value 3
Also liegt dein Problem doch eher am Frontend und nicht direkt an iobroker
Welche web Einstellung nutzt du?Ich hatte oben 2 Screenshot von der Web-Instanz gepostet. Falls ich noch weitere Sachen posten soll, dann gerne bescheid geben
@christobal0815 dann probier es mal anstatt integriert im web Adapter, mit ws
Ws muss als Adapter installiert sein.
Bei manchen hat es geholfen und vis lief dann wieder etwas flotter
-
@christobal0815 dann probier es mal anstatt integriert im web Adapter, mit ws
Ws muss als Adapter installiert sein.
Bei manchen hat es geholfen und vis lief dann wieder etwas flotter
@crunchip said in VIS nach einigen Monaten recht träge:
manchen hat es geholfen und vis lief dann wieder etwas flott
@crunchip said in VIS nach einigen Monaten recht träge:
@christobal0815 dann probier es mal anstatt integriert im web Adapter, mit ws
Ws muss als Adapter installiert sein.
Bei manchen hat es geholfen und vis lief dann wieder etwas flotter
Danke - d.h. ich stelle im WEB-Adapter von integrated auf none.
WS = WebSocket?Edit: Selbst entdeckt. Nach der Installation von WS taucht die Auswahl auch in web auf... Ich teste und werde berichten.
-
@crunchip said in VIS nach einigen Monaten recht träge:
manchen hat es geholfen und vis lief dann wieder etwas flott
@crunchip said in VIS nach einigen Monaten recht träge:
@christobal0815 dann probier es mal anstatt integriert im web Adapter, mit ws
Ws muss als Adapter installiert sein.
Bei manchen hat es geholfen und vis lief dann wieder etwas flotter
Danke - d.h. ich stelle im WEB-Adapter von integrated auf none.
WS = WebSocket?Edit: Selbst entdeckt. Nach der Installation von WS taucht die Auswahl auch in web auf... Ich teste und werde berichten.
Und ich würde dem System wieder Swap geben.
Und die Zeitzone würde ich auch setzen. -
@homoran said in VIS nach einigen Monaten recht träge:
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
Verändere ich das Objekt wieder dauert es bis er darauf reagiert 7 Sekunden.
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
fuhr nach ca. 2 oder 3 Sekunde nach ob bzw. nach unten.
Jetzt dauert es Handgestoppte 9 SekundenEs ist für mich nicht reproduzierbar. Gerade eben brauchte der Rollo nach klick in VIS zum hochfahren 8 Sekunden, beim Klick runter fahren hat er in 3 Sekunden reagiert. Ich kann es nicht wirklich nachvollziehen was da schlief läuft
@christobal0815 sagte in VIS nach einigen Monaten recht träge:
Gerade eben brauchte der Rollo nach klick in VIS zum hochfahren 8 Sekunden, beim Klick runter fahren hat er in 3 Sekunden reagiert
aber die nahezu gleichen Zeiten hattest du auch in den Objekten.
das habe ich eben zitiert.Da ist für mich die vis außen vor!
Support us
315
Online32.7k
Benutzer82.5k
Themen1.3m
Beiträge