Neueste Beiträge

Seiten: [1] 2 3 ... 10

Anfängerfragen / VERSCHOBEN: configcheck (HMInfo) geht seit gestern nach Update nicht mehr (gelöst )

« Letzter Beitrag von Bison am Heute um 08:38:24 »

Dieses Thema wurde verschoben nach Homematic.

https://forum.fhem.de/index.php?topic=131981.0

Sonstiges / Antw:configdb crasht FHEM

« Letzter Beitrag von betateilchen am Heute um 08:38:19 »

Moin Peter,

der reißerische Thread-Titel

Zitat von: Prof. Dr. Peter Henning am Heute um 07:15:50

configdb crasht FHEM

ärgert mich gerade maßlos.

Wenn Dein Rottweiler ein kleines Kätzchen frißt und daran erstickt, ist auch nicht das kleine Kätzchen schuld, sondern der Hund, weil er etwas getan hat, das er nicht tun sollte. Genau so ist das hier:

Zitat von: Prof. Dr. Peter Henning am Heute um 07:15:50
bis ich dann configdb filedelete 'muell.ics' eingegeben habe

Du hast etwas getan, was man nicht tun sollte. Es steht nirgends, dass man den Dateinamen in dem Befehl in Anführungszeichen setzen soll
Der Titel hat überhaupt nichts mit dem eigentlichen Problem zu tun, für das Du eine Lösung suchst. Dein Problem ist ja nicht der von Dir provozierte FHEM Absturz, sondern dass Du eine Datei nicht löschen kannst.

Kommen wir zu Deiner Frage:

Zitat von: Prof. Dr. Peter Henning am Heute um 07:15:50

und als Datei /opt/fhem/muell.ics in die configdb importiert.
...
Nachdem das dennoch nicht richtig funktionierte
...
Außer der Datei /opt/fhem/muell.ics behauptet configdb auch noch eine Datei muell.ics zu enthalten, die - folgerichtig - die Daten aus dem letzten Jahr enthält und bei der Anforderung aus dem Müllkalender als erstes gelesen wird. Kann also nicht gehen...

Wenn die Datei im Vorjahr muell.ics hieß und Du die neue Datei dieses Jahr als /opt/fhem/muell.ics importiert hast, sind das für configDB zwei unterschiedliche Dateien. Hier wird nämlich nicht mit Pfaden im Sinne eines Dateisystems gearbeitet, sondern der angegebene Name inklusive Pfad identifiziert die abgespeicherte Datei eindeutig.

Dateien OHNE Pfadangabe können zwar in die Datenbank importiert werden, solche Dateien können aber mit configdb filedelete nicht gelöscht werden. Beides ist so beabsichtigt, auf die Hintergründe und Notwendigkeiten dafür will ich jetzt nicht eingehen.

Wenn Dein Müllkalender nach einer Datei muell.ics (ohne Pfadangabe) sucht, dann importiere doch die ics Datei einfach aus dem Verzeichnis /opt/fhem mittels

Code: [Auswählen]

configdb fileimport muell.icsin die Datenbank, dann wird die vorherige Datei durch die neue ersetzt.

Alternativ kannst Du die Datei als /opt/fhem/muell.ics importieren, dann musst Du halt in Deinem Müllkalender die Datei dort auch genau so angeben.

Eine Datei ohne Pfadangabe kannst Du nur auf Datenbankebene außerhalb FHEM aus der configDB löschen.

Anfängerfragen / DOIF und (laaaanges) wait

« Letzter Beitrag von roemi am Heute um 08:36:55 »

Guten Morgen,

inzwischen habe ich mein "neues" fhem relativ gut am laufen und so einiges dazugelernt.
Aber ... es gibt immer ein aber

Ich habe nach dieser Anleitung https://heinz-otto.blogspot.com/2018/07/kalender-in-fhem-einbinden.html den Abfallkalender meiner Stadt eingebunden und lasse mir nun Rest- und Biomüll anzeigen. Top.
Ich wollte nun noch den Hinweis "Morgen" und "Heute" mit unterbringen was mir auch auf einfach Art und Weise gelungen ist.
Das DOIF schreibt im Dummy v_tonne ins Reading "tag" gleich zu Beginn um 12:00 "Morgen" und dann, nach einer zwölfstündiger Wartezeit "Heute".
Funktioniert auch einwandfrei.

In der Referenz heißt es aber wörtlich:

Zitat

Das Aufspalten einer kommagetrennten Befehlskette in eine Befehlssequenz, wie im obigen Beispiel, sollte nicht vorgenommen werden, wenn keine Verzögerungen zwischen den Befehlen benötigt werden. Denn bei einer Befehlssequenz werden Zwischenzustände cmd1_1, cmd1_2 usw. generiert, die Events erzeugen und damit unnötig FHEM-Zeit kosten.

Auch wenn mein DOIF selbst keine Komma's beinhaltet, habe ich den Eindruck das in den 12 Stunden fhem nicht reagiert wie es soll. Mehrere Device waren nicht erreichbar ... sehr komisch.
Allerdings bin ich mir auch nicht sicher ob mit diesem Hinweis das "wait" gemeint ist.

Nun meine Frage: Ist die Lösung mit dem "wait" eine blöde Idee oder sollte ich an anderer Stelle suchen?

Hier das DOIF

Code: [Auswählen]

Internals:
   DEF        ([v_tonne] ne 0)(setreading v_tonne tag Morgen) (setreading v_tonne tag Heute) DOELSE (setreading v_tonne tag 0)
   FUUID      63da8498-f33f-dc64-83ad-3bc003a004d0b33e
   MODEL      FHEM
   NAME       d_tonne
   NOTIFYDEV  global,v_tonne
   NR         214
   NTFY_ORDER 50-d_tonne
   STATE      cmd_1
   TYPE       DOIF
   VERSION    26938 2023-01-01 18:13:32
   READINGS:
     2023-02-01 16:29:59   Device          v_tonne
     2023-02-02 04:29:59   cmd             1.2
     2023-02-02 04:29:59   cmd_event       v_tonne
     2023-02-02 04:29:59   cmd_nr          1
     2023-02-02 04:29:59   cmd_seqnr       2
     2023-02-01 16:29:59   e_v_tonne_STATE HIS Restmüll, 2-wöchentliche Abfuhr
     2023-02-01 16:29:11   mode            enabled
     2023-02-02 04:29:59   state           cmd_1
   Regex:
     accu:
     collect:
     cond:
       v_tonne:
         0:
           &STATE     ^v_tonne$
   attr:
     wait:
       0:
         0
         43200
       1:
         0
   condition:
     0          ::InternalDoIf($hash,'v_tonne','STATE') ne 0
   do:
     0:
       0          setreading v_tonne tag Morgen
       1          setreading v_tonne tag Heute
     1:
       0          setreading v_tonne tag 0
   helper:
     NOTIFYDEV  global,v_tonne
     globalinit 1
     last_timer 0
     sleeptimer -1
   internals:
     all         v_tonne:STATE 
   perlblock:
   uiState:
   uiTable:
Attributes:
   room       Dummy
   wait       0,43200:0

Vielen Dank schon mal ...

Römi

Homematic / Antw:[Wired] HMW Bus Devices nicht alle erreichbar

« Letzter Beitrag von Saphora am Heute um 08:33:41 »

Zitat von: Ralf9 am Gestern um 23:33:21

Es sollte mindestens sowas im HM485d log stehen
Code: [Auswählen]
2023.02.01 22:22:30.075 5: SW: fd608f400098000000020368923a 2023.02.01 22:22:30.077 3: HM485d: Tx: (36:1) I[0](0,Y,F,B)(98) 00000002 -> 0000808C [3] 68(h) {923A}

Anbei das Logging für "getConfig". Sieht so aus, dass nichts passiert?

Code: [Auswählen]

2023.02.02 08:20:45.375 4: HM485d: Rx: FD02E84B
2023.02.02 08:20:45.376 4: HM485d: Tx: FD03E86100
2023.02.02 08:21:07.152 4: HM485d: Rx: FD02E94B
2023.02.02 08:21:07.152 4: HM485d: Tx: FD03E96100
2023.02.02 08:21:27.281 4: HM485d: Rx: FD02EA4B
2023.02.02 08:21:27.282 4: HM485d: Tx: FD03EA6100
2023.02.02 08:21:47.290 4: HM485d: Rx: FD02EB4B
2023.02.02 08:21:47.290 4: HM485d: Tx: FD03EB6100
2023.02.02 08:22:07.297 4: HM485d: Rx: FD02EC4B
2023.02.02 08:22:07.298 4: HM485d: Tx: FD03EC6100
2023.02.02 08:22:27.305 4: HM485d: Rx: FD02ED4B
2023.02.02 08:22:27.306 4: HM485d: Tx: FD03ED6100
2023.02.02 08:22:47.312 4: HM485d: Rx: FD02EE4B
2023.02.02 08:22:47.313 4: HM485d: Tx: FD03EE6100
2023.02.02 08:23:07.320 4: HM485d: Rx: FD02EF4B
2023.02.02 08:23:07.320 4: HM485d: Tx: FD03EF6100
2023.02.02 08:23:27.330 4: HM485d: Rx: FD02F04B
2023.02.02 08:23:27.331 4: HM485d: Tx: FD03F06100
2023.02.02 08:23:47.346 4: HM485d: Rx: FD02F14B
2023.02.02 08:23:47.346 4: HM485d: Tx: FD03F16100
2023.02.02 08:24:07.353 4: HM485d: Rx: FD02F24B
2023.02.02 08:24:07.353 4: HM485d: Tx: FD03F26100
2023.02.02 08:24:27.360 4: HM485d: Rx: FD02F34B
2023.02.02 08:24:27.360 4: HM485d: Tx: FD03F36100
2023.02.02 08:24:47.368 4: HM485d: Rx: FD02F44B
2023.02.02 08:24:47.369 4: HM485d: Tx: FD03F46100
2023.02.02 08:25:07.376 4: HM485d: Rx: FD02F54B
2023.02.02 08:25:07.377 4: HM485d: Tx: FD03F56100
2023.02.02 08:25:27.385 4: HM485d: Rx: FD02F64B
2023.02.02 08:25:27.386 4: HM485d: Tx: FD03F66100
2023.02.02 08:25:47.394 4: HM485d: Rx: FD02F74B
2023.02.02 08:25:47.395 4: HM485d: Tx: FD03F76100
2023.02.02 08:26:07.402 4: HM485d: Rx: FD02F84B
2023.02.02 08:26:07.403 4: HM485d: Tx: FD03F86100
2023.02.02 08:26:27.414 4: HM485d: Rx: FD02F94B
2023.02.02 08:26:27.415 4: HM485d: Tx: FD03F96100
2023.02.02 08:26:47.423 4: HM485d: Rx: FD02FA4B
2023.02.02 08:26:47.424 4: HM485d: Tx: FD03FA6100
2023.02.02 08:27:07.430 4: HM485d: Rx: FD02FB4B
2023.02.02 08:27:07.430 4: HM485d: Tx: FD03FB6100
2023.02.02 08:27:27.439 4: HM485d: Rx: FD02FC7C4B
2023.02.02 08:27:27.439 4: HM485d: Tx: FD03FC7C6100
2023.02.02 08:27:47.447 4: HM485d: Rx: FD02FC7D4B
2023.02.02 08:27:47.447 4: HM485d: Tx: FD03FC7D6100
2023.02.02 08:28:07.456 4: HM485d: Rx: FD02FE4B
2023.02.02 08:28:07.457 4: HM485d: Tx: FD03FE6100
2023.02.02 08:28:27.468 4: HM485d: Rx: FD02FF4B
2023.02.02 08:28:27.469 4: HM485d: Tx: FD03FF6100
2023.02.02 08:28:47.553 4: HM485d: Rx: FD02014B
2023.02.02 08:28:47.553 4: HM485d: Tx: FD03016100
2023.02.02 08:29:07.571 4: HM485d: Rx: FD02024B
2023.02.02 08:29:07.571 4: HM485d: Tx: FD03026100
2023.02.02 08:29:27.578 4: HM485d: Rx: FD02034B
2023.02.02 08:29:27.578 4: HM485d: Tx: FD03036100
2023.02.02 08:29:47.585 4: HM485d: Rx: FD02044B
2023.02.02 08:29:47.585 4: HM485d: Tx: FD03046100
2023.02.02 08:30:07.597 4: HM485d: Rx: FD02054B
2023.02.02 08:30:07.597 4: HM485d: Tx: FD03056100
2023.02.02 08:30:27.609 4: HM485d: Rx: FD02064B
2023.02.02 08:30:27.610 4: HM485d: Tx: FD03066100
2023.02.02 08:30:47.618 4: HM485d: Rx: FD02074B

Zitat von: Ralf9 am Gestern um 23:41:16

Du kannst auch mal testen ob bei "set raw 68" was im HM485d log steht

Und hier das logging bei "set raw 68":

Code: [Auswählen]

2023.02.02 08:30:47.619 4: HM485d: Tx: FD03076100
2023.02.02 08:30:48.185 4: HM485d: Rx: FD0D0853C80000808C1A0000000268
2023.02.02 08:30:48.186 5: SW: fd0000808c1a0000000203680534
2023.02.02 08:30:48.188 3: HM485d: Tx: (8:1) I[1](0,F,B)(1A) 00000002 -> 0000808C [3] 68(h)  {0534}
2023.02.02 08:30:48.219 3: HM485d: Rx: Response: (8) I[2](1,F,B)(3C) 0000808C -> 00000002 [4] 1C() 00 {F6FA}
2023.02.02 08:30:48.220 5: SW: fd0000808c59000000020211c2
2023.02.02 08:30:48.221 3: HM485d: Tx: ACK(2,B)(59) 00000002 -> 0000808C [2] {11C2}
2023.02.02 08:30:48.222 4: HM485d: Tx: FD0508723C1C00
2023.02.02 08:30:55.171 4: HM485d: Rx: FD0D0953C80000808C1C0000000268
2023.02.02 08:30:55.172 5: SW: fd0000808c1c000000020368e1b2
2023.02.02 08:30:55.173 3: HM485d: Tx: (9:1) I[2](0,F,B)(1C) 00000002 -> 0000808C [3] 68(h)  {E1B2}
2023.02.02 08:30:55.200 3: HM485d: Rx: Response: (9) I[3](2,F,B)(5E) 0000808C -> 00000002 [4] 1C() 00 {B6F2}
2023.02.02 08:30:55.201 5: SW: fd0000808c790000000202f504
2023.02.02 08:30:55.202 3: HM485d: Tx: ACK(3,B)(79) 00000002 -> 0000808C [2] {F504}
2023.02.02 08:30:55.203 4: HM485d: Tx: FD0509725E1C00
2023.02.02 08:31:00.220 4: HM485d: Rx: FD0D0A53C80000808C1E0000000268
2023.02.02 08:31:00.221 5: SW: fd0000808c1e0000000203684dce
2023.02.02 08:31:00.224 3: HM485d: Tx: (10:1) I[3](0,F,B)(1E) 00000002 -> 0000808C [3] 68(h)  {4DCE}
2023.02.02 08:31:00.249 3: HM485d: Rx: Response: (10) I[0](3,F,B)(78) 0000808C -> 00000002 [4] 1C() 00 {55E4}
2023.02.02 08:31:00.249 5: SW: fd0000808c190000000202c84c
2023.02.02 08:31:00.251 3: HM485d: Tx: ACK(0,B)(19) 00000002 -> 0000808C [2] {C84C}
2023.02.02 08:31:00.251 4: HM485d: Tx: FD050A72781C00

Allgemeine Frage:
Wie ließt sich das Logging?
Was macht das raw 68?
Gibt es da eine FHEM bzw. Homematic Spezifikation?

Solaranlagen / Antw:[98_Fronius.pm] Fronius API Modul

« Letzter Beitrag von Pnemenz am Heute um 08:32:29 »

Gute Frage.
Das hat mein E-Installateur gemacht. Ich denke aber er ist am Einspeisepunkt. Gibts eine Möglichkeit das herauszufinden?

Heizungssteuerung/Raumklima / Antw:Neues Modul: vitoconnect

« Letzter Beitrag von buec65 am Heute um 08:31:31 »

Hallo Marc,
habe heute ein Update von meinem fhem gemacht und bekomme folgende Meldung

Code: [Auswählen]

2023.02.02 07:51:15 0: Server shutdown
...
2023.02.02 07:51:39 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at ./FHEM/98_vitoconnect.pm line 1757.
2023.02.02 07:51:41 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/98_vitoconnect.pm line 1851.
2023.02.02 07:51:42 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/98_vitoconnect.pm line 1869.
...

werden die Meldungen in Zukunft mit dem Update beseitigt?

Anfängerfragen / Antw:Frage zu df und freiem Speicher auf SD-Karte

« Letzter Beitrag von gestein am Heute um 08:31:24 »

Das „sudo du -ch --max-depth=4 /media“ ergibt:
4,0K /media/usb7 4,0K /media/usb1 4,0K /media/usb2 4,0K /media/usb4 4,0K /media/usb3 4,0K /media/usb5 4,0K /media/usb6 4,0K /media/nas 36G /media/usb0/fhem/log 1,4M /media/usb0/fhem/sync/test 2,8M /media/usb0/fhem/sync/log 9,6G /media/usb0/fhem/sync 45G /media/usb0/fhem 45G /media/usb0 4,0K /media/Sicherung 45G /media 45G insgesamt

Die Platte habe ich nach dieser Anleitung eingebunden:
https://forum.fhem.de/index.php/topic,66177.msg574473.html#msg574473

Werde die Platte heute Abend mal abstecken.
Lg, Gerhard

FHEM Code changes / Revision 27167: controls_fhem.txt: fhemupdate checkin

« Letzter Beitrag von System am Heute um 08:00:35 »

Revision 27167: controls_fhem.txt: fhemupdate checkin

controls_fhem.txt: fhemupdate checkin

Source: Revision 27167: controls_fhem.txt: fhemupdate checkin

Homematic / Antw:Wie Register setzen mit HMCCU?

« Letzter Beitrag von Prof. Dr. Peter Henning am Heute um 07:34:14 »

OK, danke für die ausführliche Antwort. Damit verstehe ich auch den CommandRef-Eintrag, das passt soweit und funktioniert auch.

Nun bilde ich mir ein, nicht ganz ungeübt zu sein. Schlussfolgerung: Wenn ich das nicht kapiere, wird das sicher anderen auch so gehen. Mein Vorschlag daher: Erstens den CommandRef-Eintrag so überarbeiten, dass er etwas einfacher zu lesen ist. Beispielsweise aus der ersten Zeile drei machen

Zitat

set <name> config <parameter>=<value>[:<type>] for channel parameters[...]
set <name> config device <parameter>=<value>[:<type>] for device parameters[...]
set <name> config <receiver> <parameter>=<value>[:<type>] [...] for receiver parameters

Zweitens: Die ausführliche Erklärung aus dem vorigen Post ins Wiki stellen.

LG

pah

Sonstiges / configdb crasht FHEM

« Letzter Beitrag von Prof. Dr. Peter Henning am Heute um 07:15:50 »

Ich habe wie immer im Januar den neuen Müllkalender eingelesen, und als Datei /opt/fhem/muell.ics in die configdb importiert. Nachdem das dennoch nicht richtig funktionierte, habe ich mit configdb filelist nachgesehen: Außer der Datei /opt/fhem/muell.ics behauptet configdb auch noch eine Datei muell.ics zu enthalten, die - folgerichtig - die Daten aus dem letzten Jahr enthält und bei der Anforderung aus dem Müllkalender als erstes gelesen wird. Kann also nicht gehen...

Also habe ich zuerst den Befehl configdb filedelete muell.ics abgesetzt. Daraufhin teilt mir configdb brav mit, dass es die Datei /opt/fhem/muell.ics gelöscht habe - die ich ja gar nicht löschen wollte. Also noch einmal configdb filedelete muell.ics. Daraufhin teilt mir configdb mit

Zitat

File /opt/fhem/muell.ics not found in database.

Allerdings ergibt configdb fileshow muell.ics sehr wohl den Inhalt der veralteten Datei. Hier stimmt also etwas nicht - wie werde ich die obsolete Datei wieder los?

Dann habe ich verschiedene Varianten des Dateinamen muell.ics ausprobiert. Alle ohne Erfolg, bis ich dann configdb filedelete 'muell.ics' eingegeben habe. Daraufhin hat sich FHEM ins Nirvana verabschiedet. Fehlermeldung:

Zitat

2023.02.02 06:57:49 1: PERL WARNING: DBD::SQLite::db do failed: near "muell": syntax error at configDB.pm line 1340.
DBD::SQLite::db do failed: near "muell": syntax error at configDB.pm line 1340.

LG

pah

Seiten: [1] 2 3 ... 10

FHEM Forum

Neuigkeiten: