Hauptmenü

Frage zu ignoreRegexp

Begonnen von Helmi55, 12 Dezember 2020, 14:50:09

Vorheriges Thema - Nächstes Thema

Helmi55

Hallo
mein Shelly 2.5 schreibt sehr viel ins Log
Dies will ich mit "ignoreRegexp" eingrenzen. Leider funktioniert es nur teilweise. Ist dieses attr begrenzt?
Der erste Til wird nicht mehr aufgezeichnet, aber ab dem 7ten Eintrag wird wieder fleißig geschrieben?
Hier ein List

Internals:
   DEF        ./log/MV_Brunnen-%Y.log MV_Brunnen
   FD         17
   FUUID      5c4b2e6d-f33f-b033-41ef-f3461981b36aa98d
   NAME       FileLog_MV_Brunnen
   NOTIFYDEV  MV_Brunnen
   NR         138
   NTFY_ORDER 50-FileLog_MV_Brunnen
   REGEXP     MV_Brunnen
   STATE      active
   TYPE       FileLog
   currentlogfile ./log/MV_Brunnen-2020.log
   logfile    ./log/MV_Brunnen-%Y.log
   READINGS:
     2020-12-12 14:48:31   linesInTheFile  7573183
Attributes:
   ignoreRegexp .*new_fw.* | .*id.* | .*mac.* | .*fw_ver.* | .*ip.* | .*model.* | .*input_0.* | .*event_cnt.* | .*event.* | .*temperature_f.* | .*overtemperature.*
   logtype    text
   room       Logs


Und ein Bild vom LogFile


Was mach ich da falsch?
Danke
Helmut
System1 fhem 6.1 auf RPi 4B mit 4GB, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 6.1 auf RPi 4B mit 4GB (Bullseye) mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/

amenomade

Ich würde zuerst die Leerzeichen entfernen
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Wzut

warum zuerst "her mit allem" und dann aber sagen du & du dann doch nicht, statt gleich nur das zuzulassen was man wirklich will ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

#3
M.E. liegt das Problem weniger auf der FileLog-Seite, sondern zu einem großen Teil an ungünstigen event-on-change-etc.-Attributen an dem MQTT2_DEVICE (das ist doch das ausgangsdevice, oder?).

Speziell zu Shelly@MQTT2_DEVICE warte ich seit Monaten darauf, dass jemand auf den Zug aufspringt und sich mal tiefgreifend Gedanken macht, ob das, was ich da irgendwo mal kurz zusammengeklöppelt habe denn jetzt ein "guter Standard" (bekanntzumachen via attrTemplate) werden soll. Über https://forum.fhem.de/index.php/topic,116162.msg1104833.html#msg1104833 wäre ggf. dann die passende "Generaldiskussion" zu finden.

Die Auswirkungen, wenn man da nicht sauber vorgeht und das dann noch nicht optimalen regexp kombiniert (egal, ob FileLog, notify oder anderer Event-Handler) kann man dann z.B. hier sehen (in dem konkreten Beitrag ist auch zu finden, wie man z.B. für notify feststellen kann, wie groß das "Problem" ggf. ist): https://forum.fhem.de/index.php/topic,116547.msg1109967.html#msg1109967
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

OdfFhem

@Helmi55

Zitat2020-12-12 14:48:31   linesInTheFile  7573183
Mehr als 7 Millionen Datensätze - definitiv eine "viel" zu hohe Zahl.

Zitat von: Wzut am 12 Dezember 2020, 19:48:41
warum zuerst "her mit allem" und dann aber sagen du & du dann doch nicht, statt gleich nur das zuzulassen was man wirklich will ?
Auf jeden Fall sehr empfehlenswert. Will man nur bestimmte Readings loggen, ist die Einschränkung bei der FileLog-Definition die beste Lösung. Der Einsatz von ignoreRegexp dient in einem solchen Fall nur dem nicht abwendbarem Feinschliff, sofern notwendig.


Zitat
Was mach ich da falsch?
Diese Frage ist nicht wirklich beantwortbar, da unklar ist, was Du genau machen willst.

Um einer brauchbaren Lösung näherzukommen, wäre ein list von MV_Brunnen hilfreich.
Die Readings, die Du wirklich loggen willst, solltest Du aufführen.
Sollte der Vorwärtsweg nicht möglich sein, müsstest Du die unerwünschten Readings nennen. Im Hinterkopf sollte man dabei immer haben, dass mit z.B. Firmware-Updates u.U. wieder neue, unerwünschte Readings dazukommen ...


Generell kann man sagen:

*** Ebene #1 ***
Verwendung von "event-on-change-reading .*" beim Event-liefernden Device. Readings für Temperatur, Verbrauch, usw. werden u.U. noch durch die Angabe eines Schwellwertes verfeinert. Will man nur für bestimmte Readings Events bekommen, kann man hier auch eine geeignete Liste hinterlegen.

*** Ebene #2 ***
Bei der FileLog-Definition wird festgelegt, welche Werte man loggen will. Sollte die Angabe für die Eingrenzung nicht ausreichen, kann man via ignoreRegexp das Logging weiter beeinflussen. "Neuerdings" kann man auch via filelog-event-min-interval das Log-Verhalten einschränken - bei power-Devices von shelly oder innr nicht ganz uninteressant.

Helmi55

Hallo und Danke für eure Lösungsansätze
@ Amenomade
Du hast recht - ich brauche eine Brille - ich habe das im Wiki als Leerzeichen angesehen ;D 8)

@Wzut
Das ist sicher der einfachere Weg
./log/Heizung_Brunnen-%Y.log Heizung_Brunnen:(on|off)

@OdfFhem
Danke für deine Hilfe. Ziel war es für mich nur aufzuzeichnen ob on off beim Magnetventil richtig funktioniert (hier habe ich im Moment das Aufwändige
Ausschlussverfahren ignoreRegexp eingegeben) und bei der BrunnenHeizung habe ich jetzt wie oben nur on|off geschrieben.

Ach ja und event-on-change-reading habe ich jetzt natürlich auch .* gesetzt.

@Beta-User
Du hast vollkommen recht, die Shellies senden eine Datenflut.
Aber deine Ansätze sind MIR als einfacher, kleiner User eine oder mehrere Nummern zu groß
Sicher könnte ich auch schon in den Templates Veränderungen durchführen, aber das ist mir zu unsicher

Nochmals Danke für eure Hilfen und einen schönen 3. Advent

Ich schließe das Thema noch nicht - hoffe das es noch Diskussionen geben wird

System1 fhem 6.1 auf RPi 4B mit 4GB, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 6.1 auf RPi 4B mit 4GB (Bullseye) mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/

Beta-User

Zitat von: Helmi55 am 13 Dezember 2020, 11:17:13
./log/Heizung_Brunnen-%Y.log Heizung_Brunnen:(on|off)
M.E. besser:
./log/Heizung_Brunnen-%Y.log Heizung_Brunnen:o[nf]+
Schau dir einfach an, ob da ein NOTIFYDEV erscheint.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Helmi55

#7
Servus ja tut es (ist aber schon hohe Programmierkunst oder? 8))
das bedeutet alles was mit o anfängt und auf n und f ändert wird berücksichtigt z. B. oben
Danke
Helmut
System1 fhem 6.1 auf RPi 4B mit 4GB, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 6.1 auf RPi 4B mit 4GB (Bullseye) mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/

Beta-User

Nein, es war was anderes gemeint. Vor und nach der Änderung mal ein list nach dem genannten Schlagwort durchsuchen, dann wird es evtl. klarer ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Helmi55

Hab das gerade noch in meinen Post eingefügt
das bedeutet alles was mit o anfängt und auf n und f ändert wird berücksichtigt z. B. oben

System1 fhem 6.1 auf RPi 4B mit 4GB, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 6.1 auf RPi 4B mit 4GB (Bullseye) mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/

Beta-User

Nochmal eine Langfassung:

Wir haben hier zwei Themen: zum einen die Frage einer optimierten regexp beim Eventhandler (hier: FileLog).
Zum anderen die Frage der "guten" Gestaltung des Ausgangsdevices, dass es _nur die Events erzeugt_, die du auch brauchst.

Zum ersten Punkt: Ein Eventhandler, der NOTIFYDEV grundsätzlich unterstützt, aber dieses nicht in den Internals anzeigt, bekommt einfach alle Events (d.h., auch von ganz anderen Geräten, einfach alles) und muss dann entscheiden, ob diese ihn überhaupt interessieren. Ist die regexp "gut", bekommt er nur noch Events von den Geräten, auf die NOTIFYDEV zutrifft, also weniger.
Das ganze ist eine reine Performance-Frage, beide regexp führen zu passenden Einträgen im Log.
Deswegen: Ändere das define mal in beide Varianten und schau dann jeweils mal in ein list, ob du NOTIFYDEV findest...

Du kannst das alternativ mit einer speziellen Funktion testen:
{ notifyRegexpCheck('Heizung_Brunnen:(on|off)') } bzw.
{ notifyRegexpCheck('Heizung_Brunnen:o[nf]+') }




Das andere Thema ist komplexer:
In dem einen Beitrag war eine "Muster"-RAW-Definition. in der sind m.E. folgende Zeilen interessant:
attr Muster_Shelly1pm event-on-change-reading state,temperature:0.2,online,loadState,overtemperature,Verbrauch_Total_kWh,relay_0_.*,relay0,input0
attr Muster_Shelly1pm event-on-update-reading stat[ERT].*
attr Muster_Shelly1pm timestamp-on-change-reading state,online,loadState,overtemperature
[...]
  shellies/shelly1pm-123456789012/temperature_f:.* {}\


Fangen wir mit der letzten an:
Zunächst mal erzeugt jeder Match in der readingList ein Event, wenn ein Reading erzeugt wird. Da wir hier aber in der Regel nur die °C-Werte beachten, interessieren uns die in Fahrenheit umgerechneten Werte gar nicht. Diese letzte Zeile sagt also schlicht: Mache nichts, erzeuge kein Reading.

Eigentlich würde man sich wünschen, dass das in der Shelly-firmware konfigurierbar wäre, so müssen wir diesen Unsinn eben irgendwie bearbeiten.
Die Alternative wäre, die Zeile nicht zu schreiben und stattdessen das autocreate-Attribut am Gerät auf "0" zu setzen. Da ich davon ausgehe, dass jemand früher oder später da Änderungen vornimmt und das vermutlich auch kaum ein Performance-Unterschied macht, würde ich  das mit dem "mache nichts" eigentlich auch gerne zum Standard machen.

Zu dieser Frage kann sich auch jeder "normale" User äußern, das ist keine komplexe Angelegenheit.

Das mit den ersten beiden anderen ist genau das, was OdfFhem als "Ebene 1" beschrieben hat.
Auch da würde mich eigentlich nur interessieren, ob das auch für andere soweit taugliche Einstellungen sind, dass die für >80% der Fälle als "brauchbar" angesehen werden können.
Ist also auch nur "verstehen und Meinung abgeben".

Das dritte aus der "eocr"-Familie "timestamp-on-change-reading" ist ein bisschen spezieller. Da geht es darum, dass mit event-on-... zwar kein Event erzeugt wird, aber der Zeitstempel trotzdem aktualisiert wird. Mit anderen Worten: die Antwort auf die Frage: "Wann wurde xy eingeschaltet?" wird falsch beantwortet, wenn man ReadingsAge() verwendet.
Mit diesem Attribut wird das geändert. Auch da ist eben die schlichte Frage: Ist das ein sinnvoller Vorschlag oder nicht...

Deine Meinung würde mich interessieren ;) .

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Helmi55

Hallo guten Abend
hier noch das List vom MV_Brunnen - war ich noch schuldig -sorry

Internals:
   CID        shellyswitch25_686C74
   DEF        shellyswitch25_686C74
   DEVICETOPIC MV_Brunnen
   FUUID      5fd5df5d-f33f-b033-3db7-a66e9062a71f65f4
   IODev      myBroker
   LASTInputDev myBroker
   MSGCNT     7128
   NAME       MV_Brunnen
   NR         541
   STATE      off
   TYPE       MQTT2_DEVICE
   myBroker_MSGCNT 7128
   myBroker_TIME 2020-12-13 18:30:34
   READINGS:
     2020-12-13 10:31:12   actions_stats_skipped 0
     2020-12-13 10:31:41   associatedWith  Heizung_Brunnen
     2020-12-13 10:31:09   attrTemplateVersion 20200831
     2020-12-13 10:31:12   cfg_changed_cnt 1
     2020-12-13 10:31:12   cloud_connected false
     2020-12-13 10:31:12   cloud_enabled   false
     2020-12-13 18:30:34   event           
     2020-12-13 18:30:34   event_cnt       0
     2020-12-13 10:31:12   fs_free         122237
     2020-12-13 10:31:12   fs_size         233681
     2020-12-13 11:05:53   fw_ver          20201128-102046/v1.9.2@e83f7025
     2020-12-13 10:31:12   has_update      false
     2020-12-13 11:05:53   id              Brunnen__switch25-686C74
     2020-12-13 18:30:34   input1          0
     2020-12-13 10:31:12   inputs_1_event 
     2020-12-13 10:31:12   inputs_1_event_cnt 0
     2020-12-13 10:31:12   inputs_1_input  0
     2020-12-13 10:31:12   inputs_2_event 
     2020-12-13 10:31:12   inputs_2_event_cnt 0
     2020-12-13 10:31:12   inputs_2_input  0
     2020-12-13 11:05:53   ip              10.0.0.155
     2020-12-13 11:05:53   mac             2CF432686C74
     2020-12-13 10:31:12   meters_1_counters_1 0.000
     2020-12-13 10:31:12   meters_1_counters_2 0.000
     2020-12-13 10:31:12   meters_1_counters_3 0.000
     2020-12-13 10:31:12   meters_1_is_valid true
     2020-12-13 10:31:12   meters_1_overpower 0.00
     2020-12-13 10:31:12   meters_1_power  0.00
     2020-12-13 10:31:12   meters_1_timestamp 1607855472
     2020-12-13 10:31:12   meters_1_total  0
     2020-12-13 10:31:12   meters_2_counters_1 0.000
     2020-12-13 10:31:12   meters_2_counters_2 0.000
     2020-12-13 10:31:12   meters_2_counters_3 0.000
     2020-12-13 10:31:12   meters_2_is_valid true
     2020-12-13 10:31:12   meters_2_overpower 0.00
     2020-12-13 10:31:12   meters_2_power  0.00
     2020-12-13 10:31:12   meters_2_timestamp 1607855472
     2020-12-13 10:31:12   meters_2_total  0
     2020-12-13 11:05:53   model           SHSW-25
     2020-12-13 10:31:12   mqtt_connected  true
     2020-12-13 11:05:53   new_fw          false
     2020-12-13 11:05:53   online          true
     2020-12-13 18:30:34   overtemperature 0
     2020-12-13 10:31:12   ram_free        35132
     2020-12-13 10:31:12   ram_total       48704
     2020-12-13 18:30:34   relay1          off
     2020-12-13 18:30:34   relay_1_energy  9
     2020-12-13 18:30:34   relay_1_kWh     0.00
     2020-12-13 18:30:34   relay_1_power   0.00
     2020-12-13 10:31:12   relays_1_has_timer false
     2020-12-13 10:31:12   relays_1_is_valid true
     2020-12-13 10:31:12   relays_1_ison   false
     2020-12-13 10:31:12   relays_1_overpower false
     2020-12-13 10:31:12   relays_1_overtemperature false
     2020-12-13 10:31:12   relays_1_source input
     2020-12-13 10:31:12   relays_1_timer_duration 0
     2020-12-13 10:31:12   relays_1_timer_remaining 0
     2020-12-13 10:31:12   relays_1_timer_started 0
     2020-12-13 10:31:12   relays_2_has_timer false
     2020-12-13 10:31:12   relays_2_is_valid true
     2020-12-13 10:31:12   relays_2_ison   false
     2020-12-13 10:31:12   relays_2_overpower false
     2020-12-13 10:31:12   relays_2_overtemperature false
     2020-12-13 10:31:12   relays_2_source input
     2020-12-13 10:31:12   relays_2_timer_duration 0
     2020-12-13 10:31:12   relays_2_timer_remaining 0
     2020-12-13 10:31:12   relays_2_timer_started 0
     2020-12-13 10:31:12   serial          3
     2020-12-13 18:30:34   state           off
     2020-12-13 18:30:34   temperature     34.98
     2020-12-13 18:30:34   temperature_f   94.96
     2020-12-13 10:31:12   temperature_status Normal
     2020-12-13 10:31:12   time            10:31
     2020-12-13 10:31:12   tmp_is_valid    true
     2020-12-13 10:31:12   tmp_tC          34.80
     2020-12-13 10:31:12   tmp_tF          94.65
     2020-12-13 10:31:12   unixtime        1607855472
     2020-12-13 10:31:12   update_beta_version 20201202-140039/v1.9.3-rc3@50c6ab57
     2020-12-13 10:31:12   update_has_update false
     2020-12-13 10:31:12   update_new_version 20201128-102046/v1.9.2@e83f7025
     2020-12-13 10:31:12   update_old_version 20201128-102046/v1.9.2@e83f7025
     2020-12-13 10:31:12   update_status   idle
     2020-12-13 10:31:12   uptime          36
     2020-12-13 10:31:12   voltage         223.59
     2020-12-13 10:31:12   wifi_sta_connected true
     2020-12-13 10:31:12   wifi_sta_ip     10.0.0.155
     2020-12-13 10:31:12   wifi_sta_rssi   -27
     2020-12-13 10:31:12   wifi_sta_ssid   xxxxxxxxx
Attributes:
   IODev      myBroker
   comment    Channel 2 for MQTT2_shellyswitch25_686C74
   devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen"; my $light = ReadingsVal($name,"state","off"); my $cons = ReadingsVal($name,"relay_1_power","unknown"); my $temp = ReadingsVal($name,"temperature","-100");"<div><a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a> Aktuell: $cons W / Temp.: $temp °C<b></b>"}
   event-on-change-reading .*
   model      shelly25_split
   readingList shellies/Brunnen__switch25-686C74/relay/1:.* state
  shellies/Brunnen__switch25-686C74/relay/1:.* relay1
  shellies/Brunnen__switch25-686C74/input/1:.* input1
  shellies/Brunnen__switch25-686C74/online:.* online
  shellies/announce:.* { $EVENT =~ m,..id...Brunnen__switch25-686C74...mac.*, ? json2nameValue($EVENT) : return }
  shellies/Brunnen__switch25-686C74/announce:.* { json2nameValue($EVENT) }
  shellies/Brunnen__switch25-686C74/relay/1/power:.* relay_1_power
  shellies/Brunnen__switch25-686C74/relay/1/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : return }
  shellies/Brunnen__switch25-686C74/temperature:.* temperature
  shellies/Brunnen__switch25-686C74/overtemperature:.* overtemperature
  shellies/Brunnen__switch25-686C74/temperature_f:.* temperature_f
  shellies/Brunnen__switch25-686C74/relay/1/energy:.* relay_1_energy
  shellies/Brunnen__switch25-686C74/relay/1/energy:.* {'relay_1_kWh' => sprintf("%.2f",$EVENT/60/1000)}
  shellies/Brunnen__switch25-686C74/longpush/1:.* longpush_1
  shellies/Brunnen__switch25-686C74/input_event/1:.* { json2nameValue($EVENT) }
shellyswitch25_686C74:shellies/Brunnen__switch25-686C74/info:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    off:noArg shellies/Brunnen__switch25-686C74/relay/1/command off
  on:noArg shellies/Brunnen__switch25-686C74/relay/1/command on


1 Kanal davon ist im Brunnenhaus für die Heizung im Winter zuständig und
der 2 Kanal davon schaltet jeden Tag um 7 Uhr ein Magnetventil für 30 Sekunden am Windkessel ein (hilft das keine Luft in den langen Leitungen zum Haus ist)

und hier möchte ich nun gerne auf einen Blick im Logfile sehen ob das ordentlich abgehandelt wurde, bzw. ob der Heizlüfter richtig arbeitet.
Ich könnte es natürlich auch noch mit einer Pushover Meldung verknüpfen um ganz sicher zu sein.

So mache ich es zum Beispiel bei meiner Teststation von der ich meine Unifi NanoStations anpinge und bei absent bekomm ich eine Meldung aufs handy
Aber Gott sei Dank das funktioniert jetzt bestens und ich hab keine Ausfälle mehr.

Ich habe jetzt bei der Heizung_Brunnen folgende def im LogFile
./log/Heizung_Brunnen-%Y.log Heizung_Brunnen:o[nf]+

Und bekomme eine schöne Auswertung:


Danke Beta-user für deine Zeit und genaue Erklärung - muss ich mir in Ruhe durcharbeiten
System1 fhem 6.1 auf RPi 4B mit 4GB, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 6.1 auf RPi 4B mit 4GB (Bullseye) mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/

Beta-User

Zitat von: Helmi55 am 13 Dezember 2020, 18:44:10
Danke Beta-user für deine Zeit und genaue Erklärung - muss ich mir in Ruhe durcharbeiten
Gerne :) .

Du bist btw. bei weitem nicht der einzige User mit dieser Art Problem (aber  einer der Wenigen, die das thematisieren, wenn auch am "falschen Ende", von daher: Respekt!).

Danke auch für das list. Ich habe nur den einen "Muster-"Shelly und den schon länger nicht mehr upgedated. Mit jedem update scheint der Hersteller die MQTT-Schnittstelle noch "geschwätziger" gemacht zu haben; unschön. Von daher wird wohl v.a. der "info"-Topic nochmal etwas näherer Betrachtung bedürfen.
Muß wohl mal ein update machen, ist eher schwierig zu erklären, was mir in Bezug auf das Topic so alles im Kopf rumschwirrt. (Falls einer mitliest, der mehr mit dem "workshop" anfangen kann, wäre es toll, wenn derjenige die Hand heben würde und fertige Vorschläge für jsonMap & eocr&Co liefern möchte...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Helmi55

Servus
wie meinst du das "am falschen Ende"?
Tja ich frage halt hier im Forum wenn ich mich nicht auskenne bzw. wenn ich durch wiki oder Cref nicht klug werde
Habe dafür auch schon viel Kritik einstecken müssen, aber ich denke mir dazu ist ja das Forum da.
Nice eve

Helmut
System1 fhem 6.1 auf RPi 4B mit 4GB, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 6.1 auf RPi 4B mit 4GB (Bullseye) mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/

Wzut

Zitat von: Helmi55 am 14 Dezember 2020, 18:57:46
Tja ich frage halt hier im Forum wenn ich mich nicht auskenne
da hast aber jetzt etwas gründlich falsch verstanden .... mit dem falschen Ende war das FileLog gemeint, frei nach dem Motto was am Anfang erst gar nicht da ist muss man später nicht mit Gewalt platt schlagen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher