Hauptmenü

Probleme mit rename

Begonnen von Invers, 14 Dezember 2022, 17:53:32

Vorheriges Thema - Nächstes Thema

Invers

Mist. Ich hab mal wieder was, vermutlich wieder NUR ICH. LOL

Ich habe ein DOIF mit copy DI_Rollo_Wintermodus Rollo_Wintermodus_Reserve kopiert.
Aber das sieht nun komisch aus.

In der Übersicht, wo alle Devices des Raumes angezeigt werden, ist der Name Rollo_Wintermodus nun doppelt. S. Bild 1.
In der Deteailansicht des Gerätes sieht es auch komisch aus. S. Bild 2.

Cache leeren, anderer Browser hat auch nciht geholfen.
Kennt / hat noch jemand das Problem und ?

Ich habe mal ein Dummy kopiert, da passiert das nicht. Bei anderen DOIF aber immer.

Besten Dank für die Hilfe im Voraus.


Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

CoolTux

Mal das alias Attribute kontrolliert
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

Es hilft ansonsten auch immer ein list der Devices hier mit zu geben.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Invers

Die Idee mit dem Alias war/ist goldrichtig.
ABER!
Ich habe niemals für irgendein DOIF einen Alias vergeben. Es macht ja auch gar keinen Sinn, denselben Alias zu wählen, wie der Name des DOIF lautet.
Jetzt haben alle DOIF einen Alias. Weiss der Teufel, woher.

Ein List hatte ich nicht gepostet, weil ich nicht dachte, dass es in diesem Fall hilfreich sei. Sonst mache ich das ja immer.

Kannst du mir den Befehl sagen, mit dem ich bei allen DOIF den Alias löschen kann? Oder muss ich das einzeln machen?

Danke für die schnelle und erfolgreiche Hilfe. Ich dachte schon, das bleibt wieder für immer in meiner Installation kleben.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Invers

DAnke, erledigt. Schon alles gelöscht.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

CoolTux

Ansonsten

deleteattr TYPE=DOIF alias
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

LuckyDay

ZitatIch habe niemals für irgendein DOIF einen Alias vergeben. Es macht ja auch gar keinen Sinn, denselben Alias zu wählen

hast du z.B. IOBroker mit Fhem verbunden?

Invers

Mist. Das hatte ich testweise vor einigen Tagen mal ausprobiert. Hab dann aber keinen wirklichen Nutzen für mich erkannt. Geräte werden zwar leichter eingebunden, aber war alles nicht so mein Ding, abgesehen von der Optik.
Mir war nicht klar, dass irgendein Kram einfach eingebunden wird. Aber wie gesagt, meine Dummys haben dieses Problem offenbar nicht.
Danke für den Tipp.

@CoolTux
Danke, genau so habe ich das gemacht, als das Brett vvor dem Kopf hzeitweilig verschwunden war.
Die Operation lief ewig. Ich wollte schon den Pi neu starten. Hast du da Erfahrung? Ist das normal? Sollte ich langsam einen Pi 4 einplanen? Keine Ahnung.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

CoolTux

Zitat von: Invers am 15 Dezember 2022, 08:03:46
Mist. Das hatte ich testweise vor einigen Tagen mal ausprobiert. Hab dann aber keinen wirklichen Nutzen für mich erkannt. Geräte werden zwar leichter eingebunden, aber war alles nicht so mein Ding, abgesehen von der Optik.
Mir war nicht klar, dass irgendein Kram einfach eingebunden wird. Aber wie gesagt, meine Dummys haben dieses Problem offenbar nicht.
Danke für den Tipp.

@CoolTux
Danke, genau so habe ich das gemacht, als das Brett vvor dem Kopf hzeitweilig verschwunden war.
Die Operation lief ewig. Ich wollte schon den Pi neu starten. Hast du da Erfahrung? Ist das normal? Sollte ich langsam einen Pi 4 einplanen? Keine Ahnung.

Kommt halt drauf an wie viele DOIF Du hast. Kann dann schon mal dauern.
Pi4 sollte nur bei großen Installationen nötig sein. Wie ist denn die allgemeine Auslastung?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Invers

Die allgemeine Auslastung ist niedrig. Nur, wenn ich die Configdb auf die SSD speichere, dauert das länger. Sonst schläft alles. Meist so zwischen 10 und 20 Prozent CPU. Nur selten mal ganz kurz 80 %, so für 1 Sekunde. Speicher auch nur 15-20%.
Ich denke, dann warte ich, bis der Pi3+ sich verabschiedet.
Danke dir.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

CoolTux

Beim speichern sollte Du mittels top Dir mal das IOwait anschauen. Eventuell ist das schon das Problem das er lange auf die SSD warten muss. Warum auch immer.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Invers

Das finde ich leider nirgends. Nur SQL kann ich sehen. Ich habe natürlich geguckt, während das Speichern lief.
top - 12:33:39 up 19:33,  1 user,  load average: 0,50, 0,66, 0,54
Tasks: 130 total,   2 running, 128 sleeping,   0 stopped,   0 zombie
%CPU(s):  2,9 us,  2,1 sy,  0,0 ni, 94,9 id,  0,0 wa,  0,0 hi,  0,1 si,  0,0 st
MiB Spch:    923,1 total,    323,3 free,    263,2 used,    336,7 buff/cache
MiB Swap:    100,0 total,     19,6 free,     80,4 used.    602,5 avail Spch

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
  517 fhem      20   0  180504 124616   8820 R  11,3  13,2 147:42.38 perl
27438 root      20   0       0      0      0 I   8,6   0,0   4:18.54 kworker/2:0-events
29267 fhem      20   0  180504 118652   2788 S   1,0  12,6   0:00.03 perl
29266 pi        20   0   11676   3072   2524 R   0,7   0,3   0:00.08 top
   80 root       0 -20       0      0      0 I   0,3   0,0   4:25.07 kworker/0:1H-events_highpri
  719 fhem      20   0  171252  46988  29892 S   0,3   5,0   1:01.48 node /usr/local
    1 root      20   0   33800   6920   5536 S   0,0   0,7   0:20.44 systemd
    2 root      20   0       0      0      0 S   0,0   0,0   0:00.13 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 netns
    7 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kworker/0:0H-events_highpri
    9 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 mm_percpu_wq
   10 root      20   0       0      0      0 S   0,0   0,0   0:00.00 rcu_tasks_rude_
   11 root      20   0       0      0      0 S   0,0   0,0   0:00.00 rcu_tasks_trace
   12 root      20   0       0      0      0 S   0,0   0,0   0:07.01 ksoftirqd/0
   13 root      20   0       0      0      0 I   0,0   0,0   0:13.92 rcu_sched
   14 root      rt   0       0      0      0 S   0,0   0,0   0:00.18 migration/0
   15 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/0
   16 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/1
   17 root      rt   0       0      0      0 S   0,0   0,0   0:00.17 migration/1
   18 root      20   0       0      0      0 S   0,0   0,0   0:01.60 ksoftirqd/1
   20 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kworker/1:0H-events_highpri

Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Beta-User

Ein paar Anmerkungen:

- wenn du statt "copy" den Weg über raw-Definition nimmst, werden die Internals nicht mit kopiert und das (wie jedes Modul) dann neu initialisiert. Vermeidet manche anderen komischen Effekte, die sonst auftreten können.
- Falls du MQTT2_SERVER im Einsatz hast, könnten uU. "retain"-Einträge mit für eine größere Datenmenge beim Speichern (und Laden) (nicht nur aus) der configDB verantwortlich sein. Ggf. mal löschen und bei den Gegenstellen, wo das möglich ist, insbesondere den "homeassistant"-autodiscovery-Mode abschalten.
- evtl. sind auch einige viele Alt-Versionen in der Datenbank und das Ding daher insgesamt sehr groß. Ggf. mal die Zahl der möglichen Versionen prüfen und/oder aufräumen.
- Falls du auch DbLog im Einsatz hast, ist vielleicht die neue Version einen Blick wert, die grade im Test ist. Die hat einen kleineren Speicherabdruck, was ggf. dazu führen kann, dass dein Pi gar nicht mehr swappen muss (das scheint er mal gemacht zu haben).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Zitat von: Invers am 15 Dezember 2022, 12:35:01
Das finde ich leider nirgends. Nur SQL kann ich sehen. Ich habe natürlich geguckt, während das Speichern lief.
top - 12:33:39 up 19:33,  1 user,  load average: 0,50, 0,66, 0,54
Tasks: 130 total,   2 running, 128 sleeping,   0 stopped,   0 zombie
%CPU(s):  2,9 us,  2,1 sy,  0,0 ni, 94,9 id,  0,0 wa,  0,0 hi,  0,1 si,  0,0 st
MiB Spch:    923,1 total,    323,3 free,    263,2 used,    336,7 buff/cache
MiB Swap:    100,0 total,     19,6 free,     80,4 used.    602,5 avail Spch

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
  517 fhem      20   0  180504 124616   8820 R  11,3  13,2 147:42.38 perl
27438 root      20   0       0      0      0 I   8,6   0,0   4:18.54 kworker/2:0-events
29267 fhem      20   0  180504 118652   2788 S   1,0  12,6   0:00.03 perl
29266 pi        20   0   11676   3072   2524 R   0,7   0,3   0:00.08 top
   80 root       0 -20       0      0      0 I   0,3   0,0   4:25.07 kworker/0:1H-events_highpri
  719 fhem      20   0  171252  46988  29892 S   0,3   5,0   1:01.48 node /usr/local
    1 root      20   0   33800   6920   5536 S   0,0   0,7   0:20.44 systemd
    2 root      20   0       0      0      0 S   0,0   0,0   0:00.13 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 netns
    7 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kworker/0:0H-events_highpri
    9 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 mm_percpu_wq
   10 root      20   0       0      0      0 S   0,0   0,0   0:00.00 rcu_tasks_rude_
   11 root      20   0       0      0      0 S   0,0   0,0   0:00.00 rcu_tasks_trace
   12 root      20   0       0      0      0 S   0,0   0,0   0:07.01 ksoftirqd/0
   13 root      20   0       0      0      0 I   0,0   0,0   0:13.92 rcu_sched
   14 root      rt   0       0      0      0 S   0,0   0,0   0:00.18 migration/0
   15 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/0
   16 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/1
   17 root      rt   0       0      0      0 S   0,0   0,0   0:00.17 migration/1
   18 root      20   0       0      0      0 S   0,0   0,0   0:01.60 ksoftirqd/1
   20 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kworker/1:0H-events_highpri



0,0 wa,

hier hätte ich einen höheren Wert erwartet. Scheint aber soweit ok zu sein.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Invers

@CoolTux
Ich antworte dir mal zuerst, ist kürzer. Bin erfreut und beruhigt,danke.

@Beta-User
Zitat- wenn du statt "copy" den Weg über raw-Definition nimmst, werden die Internals nicht mit kopiert und das (wie jedes Modul) dann neu initialisiert. Vermeidet manche anderen komischen Effekte, die sonst auftreten können.
Dessen war ich mir gar nicht bewusst. Ich werde das in Zukunft so machen, ist ja auch kein Mehraufwand.
Zitat- Falls du MQTT2_SERVER im Einsatz hast, könnten uU. "retain"-Einträge mit für eine größere Datenmenge beim Speichern (und Laden) (nicht nur aus) der configDB verantwortlich sein. Ggf. mal löschen und bei den Gegenstellen, wo das möglich ist, insbesondere den "homeassistant"-autodiscovery-Mode abschalten.
MQTT2_Server Hab ich.
"retain"-Einträge löschen, verstehe ich nicht.
Homeassistent habe ich eigentlich nicht mehr in Benutzung. Lag auf einen anderen Pi und ich hab nur mal so aus Spass nebenbei probiert. Seitdem nioe mehr eingeschaltet.
Bei meinem MQTT Stick war/ist der ganze Homekram rausgenommen.
Zitat- evtl. sind auch einige viele Alt-Versionen in der Datenbank und das Ding daher insgesamt sehr groß. Ggf. mal die Zahl der möglichen Versionen prüfen und/oder aufräumen.
Ich bin halt ein Angsthase und hab deshalb mal 25 aufgehoben.
Zitat- Falls du auch DbLog im Einsatz hast, ist vielleicht die neue Version einen Blick wert, die grade im Test ist. Die hat einen kleineren Speicherabdruck, was ggf. dazu führen kann, dass dein Pi gar nicht mehr swappen muss (das scheint er mal gemacht zu haben).
DbLog  habe ich nie genutzt.

Danke für die Ausführliche Antwort.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Beta-User

Zitat von: Invers am 15 Dezember 2022, 14:37:18
"retain"-Einträge löschen, verstehe ich nicht.
Das kann man am MQTT2_SERVER machen, gibt seit einiger Zeit einen Setter dazu.

Zitat
Homeassistent habe ich eigentlich nicht mehr in Benutzung.
Sorry, war vielleicht mißverständlich: Es geht gar nicht darum, ob man das im Einsatz hat, sondern um die Frage, ob die MQTT-Clients, die man so rumfliegen hat, auch die "autodiscovery"-Infos versenden, oder eben nicht. Z.B. viele ESP-basierte Projekte machen das ungefragt! Das sind meistens riesige Datenstrukturen, die da mit "retain"-flag beim MQTT-Server abgeladen werden. Für FHEM sind die nutzlos...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Invers

OK, alles verstanden und umgesetzt. MQTT2Server wusste ich nicht, aber wann guckt man sich den schon an, wenn er läuft. Meistens bekommen solche Sachen nur Aufmerksamkeit, wenn sie nicht laufen.

Nochmals besten Dank. Mal sehen, wie sich alles entwickelt.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

FHEM-User22

Hallo,

Zitat von: Invers am 15 Dezember 2022, 14:37:18
    - wenn du statt "copy" den Weg über raw-Definition nimmst, werden die Internals nicht mit kopiert und das (wie jedes Modul) dann neu initialisiert. Vermeidet manche anderen komischen Effekte, die sonst auftreten können.
@Beta-UserDessen war ich mir gar nicht bewusst. Ich werde das in Zukunft so machen, ist ja auch kein Mehraufwand.

aber wenn man es mit der RAW-Definition macht, muss man da nicht den Device-Namen in alles Zeilen ändern? Das wäre suboptimal. Oder verstehe ich da was falsch?

Beste Grüße
FHEM auf Raspberry Pi und Proxmox und... und.... und....

Beta-User

Zitat von: FHEM-User22 am 16 Dezember 2022, 09:25:27
aber wenn man es mit der RAW-Definition macht, muss man da nicht den Device-Namen in alles Zeilen ändern? Das wäre suboptimal. Oder verstehe ich da was falsch?
Doch, klar. Die Frage ist halt immer, was das "kleinere Übel" ist: Komische Effekte bis zum Neustart oder copy nach Editor, search&replace, copy zurück, execute.
Ich bin eher für letzeres zu haben, zumal in der Regel ja weitere Änderungen sinnvoll sind (room, z.B.) und gleich mit "abgefrühstückt" werden können.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files