ebusd.mqtt2.template: Fragen, Anregungen

Begonnen von TomLee, 28 Februar 2019, 17:04:14

Vorheriges Thema - Nächstes Thema

Reinhart

#135
ja natürlich kannst du das gefahrlos testen!

Irgendwie verstehe ich aber nicht warum du die Geräte alle nach $1_bai schieben willst. Die "bai" ist ja schon ein Gerät. Die Calormatic 430 wird ja durch die 2. Regexp auch schön brav als $1_430 angelegt, das klappt doch prima. Ich finde es sogar übersichtlicher wenn jedes Gerät am eBus als eigenes Device angelegt wird sonst werden die Readings pro Device sehr unübersichtlich, also besser so lassen wie es jetzt ist.

Die Template sind ja so aufgebaut, das sie meist nur innerhalb eines Devices funktionieren weil dort eben gewisse Readings vorhanden sind die nur für dieses Device zutreffen. ZB: "hcurve" gibt es nur bei Zusatzgeräten wie Calormatic oder ähnlichem, also 700, 430,470, 470f, 350 und so weiter, aber nie in einer "bai" weil das eben nur das Grundgerät ist und in dieser Ausstattung noch keine Heizkurve kennt.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Beta-User

Zitat von: Reinhart am 02 April 2019, 15:02:06
ja natürlich kannst du das gefahrlos testen!
Um es auszutesten, würde ich aber alle vorhandenen ebus-MQTT2-Devices (mehrfach) löschen müssen und zwischendurch speichern... Das wollte ich dann nicht so nebenbei ohne Ankündigung machen, nachdem ich den Zugang seit längerem nicht mehr "zerstörend" genutzt hatte.

ZitatIrgendwie verstehe ich aber nicht warum du die Geräte alle nach $1_bai [...]
Sorry, Mißverständnis, das will ich gar nicht, im Gegenteil: auch bai und broadcast bekommen dann eigene Geräte, so dass braodcast nicht weiter in "bai" landet, obwohl jemand ein ehp nutzt und mit "bai" nichts anfangen kann ;) .
Die Logik soll sein (unabhängig von der Aufteilung in die einzelnen Zeilen): Alles, was separat aufgelistet ist, bekommt $1_$2 (wenn $2 dann z.B. broadcast oder bai oder ehp ist), nur was zwar $1 hat, aber nicht in der Liste auftaucht ($2 undef), kommt zu "ebusd" (=idR. $1 "solo").
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

Patrick131184

#137
@Reinhart
Das Template läuft soweit

Ein kleiner Fehler hat sich dennoch eingeschlichen.

Bei mir werden 2 Werte nicht richtig gesetzt.
bei Wednesday fehlte ein 3
Dein Code:fhem "set ebusMQTT publish ebusd/BASE_DEV/hcTimer.Wednesday/set " . ReadingsVal("TimeMi","HHMM1w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM2w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMMw",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM4w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM5w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM6w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM7w",0);;\


richtiger Code:
fhem "set ebusMQTT publish ebusd/BASE_DEV/hcTimer.Wednesday/set " . ReadingsVal("TimeMi","HHMM1w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM2w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM3w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM4w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM5w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM6w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM7w",0);;\


und du hast 2x "Thuesday" anstatt "tuesday" und "thursday"

Reinhart

Danke fürs testen und für die Korrektur.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Beta-User

So, erst mal wieder ein aktualisierter Vorschlag zur bridgeRegexp am "splitter":

attr MQTT2_ebusd bridgeRegexp (ebus.)[^/]*/(bai|broadcast|[\d]+|cc|e7f|ehp|f[\d][\d]|general|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|scan|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"\
(ebus.)[^/]*/(global)/.*:.* "$1"

Leider wollte das mit der Unterscheidung ob $2 jetzt vorhanden ist oder nicht nicht so recht, aber so müßte es jetzt eigentlich im Großen und Ganzen passen.

Anmerkungen:
- Das ist nur im laufenden Betrieb getestet, also ohne den ebusd neu zu starten; ob das sauber sortiert wird, was da ggf. noch am messages kommt, kann ich daher nicht abschließend sagen.
- Hart auf das Gerät mit der "ebusd"-CID umgeleitet habe ich jetzt die global-Messages, die scheinen sich wirklich auf den ebusd-Dämon zu beziehen. Im Moment würde ich dazu neigen, auf dieses Gerät auch "general" und "scan" umzuleiten (das also von der ersten in die 2. Zeile zu verschieben), diese sind nach John30 Auskunft ja auch "rein intern".
- Wenn ich es richtig verstanden habe, ist broadcast auch eher so ein allgemeines topic und kein wirkliches Gerät, aber dafür auch auf allen ebus-Systemen vorhanden (vermutlich mit gleichem Inhalt?). Würde es da nicht Sinn machen, auch diese Readings noch im ebus-MQTT2-Gerät zu sammeln?
Ergäbe dann ins Unreine:
attr MQTT2_ebusd bridgeRegexp (ebus.)[^/]*/(bai|[\d]+|cc|e7f|ehp|f[\d][\d]|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"\
(ebus.)[^/]*/(global|broadcast|general|scan|)/.*:.* "$1"


Wäre schön, wenn ihr Rückmeldung dazu geben könntet, dann würde ich das baldmöglichst einpflegen.

(Und ein JSONMAP-template für "bai" (ehp wäre gleich?) wäre auch noch nett...)
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

Reinhart

Ich habe jetzt den Dämon neu gestartet und auch das Log mit den Fehlermeldungen angesehen, aber da dürfte noch was nicht so stimmen.

2019.04.03 19:09:05 5: PUBLISH: 0(25)(0)(19)ebusd/global/uptime5446
2019.04.03 19:09:05 4: ebusMQTT_10.0.0.8_42278 ebusd_3.2_3783 PUBLISH ebusd/global/uptime:5446
2019.04.03 19:09:05 5: ebusMQTT: dispatch autocreate=complex\000ebusd_3.2_3783\000ebusd/global/uptime\0005446
2019.04.03 19:09:06 5: PUBLISH: 0(145)(1)(0)(18)ebusd/bai/DateTime{ "dcfstate": {"value": "nosignal"}, "btime": {"value": "03:19:06"}, "bdate": {"value": "-.-.-"}, "temp2": {"value": 14.312}}
2019.04.03 19:09:06 4: ebusMQTT_10.0.0.8_42278 ebusd_3.2_3783 PUBLISH ebusd/bai/DateTime:{ "dcfstate": {"value": "nosignal"}, "btime": {"value": "03:19:06"}, "bdate": {"value": "-.-.-"}, "temp2": {"value": 14.312}}
2019.04.03 19:09:06 5: ebusMQTT: dispatch autocreate=complex\000ebusd_3.2_3783\000ebusd/bai/DateTime\000{ "dcfstate": {"value": "nosignal"}, "btime": {"value": "03:19:06"}, "bdate": {"value": "-.-.-"}, "temp2": {"value": 14.312}}
2019.04.03 19:09:06 1: PERL WARNING: Backslash found where operator expected at (eval 6694) line 1, near ""$1_$2"\"
2019.04.03 19:09:06 1: PERL WARNING: Scalar found where operator expected at (eval 6694) line 1, near "* "$1"
2019.04.03 19:09:06 1: PERL WARNING: String found where operator expected at (eval 6694) line 1, at end of line
2019.04.03 19:09:06 1: MQTT2_DEVICE: Error evaluating "$1_$2"\ (ebus.)[^/]*/(global|broadcast|general|scan|)/.*:.* "$1": Can't find string terminator '"' anywhere before EOF at (eval 6694) line 1.


Ich habe nun alle angelegten Devices gelöscht. die Regexp installiert und autocreate wieder auf 1 gestellt (MQTT2_ebusd). Die Fehlermeldung ist nun weg (habe die regExp vom Post verwendet), aber autrocreate legt nun in "MQTT2_ebusd_3.2_378" an. Einige Devices werden überhaupt nicht mehr angelegt (430).

Ich teste jetzt noch weiter um dahinter zu kommen was da schief läuft.

LG

FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Reinhart

Ok, Fehler gefunden, da war ich schuld weil ich einfach die regExp aus deinem Post kopiert habe und hier ein "\" vorhanden ist. Beim Fhem internen Editor entfällt der natürlich!

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Beta-User

Sorry, hätte ich auch deutlicher schreiben können...

Btw.: was mir bei manchen templates  aufgefallen ist, die ich testweise zum teil aufgerufen habe: Da steckt manchmal gar keine ReadingList dahinter. Dadurch erhält man zwar eine Anzeige, die den beim Aufruf der Seite aktuellen Stand wiedergibt, aber aktualisiert wird dann nichts. Das geschieht bei Perl-devStateIcon-Code nur, wenn sich ein Reading ändert (eventuell sogar nur dann, wenn das betr. Reading im Code abgefragt wird).

Dass der Code an sich funktioniert ist klar (das hatte ich ja soweit auf demselben System getestet), offen waren
- das Verhalten, wenn der ebusd neu gestartet wird bzw. sonst irgendwie dazu veranlaßt, neue Info zu senden (die scan-Messages würden mich speziell interessieren, die waren teilweise "besonders", die finde ich grade auf dem Testsystem aber nicht in irggendeinen Device, oder?), und
- die Zuordnung der genannten topic-Pfade in einzelne Geräte oder das ebusd-Gerät selbst.

Wäre nett, wenn dazu jemand was sagen könnte (gut wäre, wenn es auch mit MQTT2_CLIENT jemand testen könnte; sollte zwar keine Probleme geben, aber leider erleben wir ja alle gelegentlich Dinge, die sich erst nach intensiverem Nachdenken erklären lassen :) ).
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

Reinhart

also das mit der readingList ist ja so, das im "MQTT2_ebusd_bai" die readingList ja automatisch angelegt wird und der anzuzeigende neue Device ja mit ReadingsVal auf dieses Reading zugreift. Ändert sich das betreffende Reading im "bai", dann ist das ja auch eine Änderung im Zieldevice.

"{my $vD = ReadingsVal("MQTT2_ebusd_bai", "WaterPressure_press_value", "30"); my $colDruck = substr(Color::pahColor(0,1,2,$vD,0),0,6); my $iconDruck = 'weather_barometric_pressure@'.$colDruck; ; "<div style=\"text-align:right\" > Wasserdruck: " . FW_makeImage("$iconDruck",'file_unknown@grey') . int($vD*100)/100 . " Bar</div>"}"

Ich habe das jetzt verglichen mit ECMD Daten und das passt soweit. Bei der Pumpe und dem Ventilator fällt das besser auf, weil die sich öfters ändern und das wird online sofort aktualisiert.

Den MQTT2_CLIENT teste ich im Hauptsystem und gebe dann morgen bescheid. Den eBus hatte ich am Testsystem schon gestern gestartet, habe es aber jetzt auch nochmals durchgeführt. Es kommen ja dann diese "MQTT2_ebusd_3.2_5143" Meldungen mit der Versionsnummer vom Scan. Die werden angelegt und der Inhalt passt auch.

Internals:
   CFGFN     
   CID        ebusd_3.2_5143
   DEF        ebusd_3.2_5143
   DEVICETOPIC MQTT2_ebusd_3.2_5143
   FUUID      5ca6237f-f33f-f7ac-890e-00329ef74dfa1f60
   IODev      ebusMQTT
   NAME       MQTT2_ebusd_3.2_5143
   NR         531
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-04-04 17:32:15   scan.08_HW_value 7401
     2019-04-04 17:32:15   scan.08_ID_value BAI00
     2019-04-04 17:32:15   scan.08_MF_value Vaillant
     2019-04-04 17:32:15   scan.08_SW_value 0518
     2019-04-04 17:32:18   scan.15_HW_value 2002
     2019-04-04 17:32:18   scan.15_ID_value 43000
     2019-04-04 17:32:18   scan.15_MF_value Vaillant
     2019-04-04 17:32:18   scan.15_SW_value 0215
Attributes:
   IODev      ebusMQTT
   readingList ebusd_3.2_5143:ebusd/scan\.08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }
ebusd_3.2_5143:ebusd/scan\.15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }
   room       MQTT2_DEVICE


LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Beta-User

#144
**Grummel*** sowas hatte ich befürchtet.

Die bisherige bridgeRegexp mag die scan-Geschichten nicht, alles kommt in das via CID identifizierte Device. Das hier sollte für Abhilfe sorgen, und für jeden .nn-Scan ein eigenes Device anlegen:
attr MQTT2_ebusd bridgeRegexp (ebus.)[^/]*/(bai|broadcast|[\d]+|cc|e7f|ehp|f[\d][\d]|general|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|scan[^/]*|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"\
(ebus.)[^/]*/(global)/.*:.* "$1"


EDIT:
Wie wäre es, auch die scan-Infos in das ebusd-Gerät umzuleiten?
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

Reinhart

da hat sich jetzt aber nichts geändert.

Internals:
   CFGFN     
   CID        ebusd_3.2_6203
   DEF        ebusd_3.2_6203
   DEVICETOPIC MQTT2_ebusd_3.2_6203
   FUUID      5ca6f2f7-f33f-f7ac-6fdf-f5093fcfe46cddd1
   IODev      ebusMQTT
   NAME       MQTT2_ebusd_3.2_6203
   NR         657
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-04-05 08:17:27   outsidetemp_temp2_value 4.875
     2019-04-05 08:17:27   scan.08_HW_value 7401
     2019-04-05 08:17:27   scan.08_ID_value BAI00
     2019-04-05 08:17:27   scan.08_MF_value Vaillant
     2019-04-05 08:17:27   scan.08_SW_value 0518
Attributes:
   IODev      ebusMQTT
   readingList ebusd_3.2_6203:ebusd/scan\.08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }
ebusd_3.2_6203:ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }
   room       MQTT2_DEVICE


Mich stört das nicht wenn die Scan Infos in ein eigenes Device wandern, so bleibt die Übersicht besser als wenn alles in einem Device liegt. Bei den Templates mache ich es ja auch so, dass ich eigene Devices generiere nur der Übersicht halber.

Ebenfalls habe ich mir jetzt den im Hauptsystem den MQTT2_CLIENT angesehen und auch dort funktioniert alles. Dazu ist meine Umgebung mit den 2 Geräten aber etwas einseitig, dass müsste ein User mit vielen Geräten einmal austesten. Eigentlich sehe ich ja bei meiner Konstellation keinen Unterschied zur vorherigen bridgeRegexp. Interessant wären ja auch Umgebungen mit Solareinspeisung, da gäbe es dann auch genug Rohdaten für weitere Templates kann ich mir vorstellen.

Was passiert eigentlich Fhem intern mit so komplexen Regexp? Ist das nicht ein Einfluß auf die Gesamtperformance, denn das Filter muss ja erst abgearbeitet werden. Ich habe mit dem ganzen MQTT2 Zeugs jetzt jede Menge DbLogExclude eingebaut, weil sonst die Db die Gui so langsam macht. Kritisch sind hier vor allem die readingsgroup weil die ja auch meist Temperaturen enthalten (die ohnehin schon abgelegt sind) die alle paar Sekunden eintreffen. Der automatischen Pflege der Datenbank ( reduceLog und deleteOldDays ) ist hier ein besonderes Augenmerk zu widmen.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Beta-User

Zitat von: Reinhart am 05 April 2019, 08:56:41
da hat sich jetzt aber nichts geändert.
Leider doch: Es landen jetzt auch die Broadcast-Infos im "Sammeldevice" rein auf CID-Basis (ebusd_3.2_6203) (EDIT: Fehler gefunden, da das nachfolgende aber schon geschrieben war und ggf. zum Verständnis wichtig ist); die CID ist zu allem Überfluß beim ebusd scheinbar auch noch volatil. Zur Klarstellung: Du scheinst davon auszugehen, dass das nur ein unwichtiger Nebenaspekt ist, aber m.E. ist das eine Symptomatik, hinter der ein echtes Problem steht, das nur nicht erkennbar ist, weil die Zahl der Geräte zu gering ist. Du brauchst nur mal nachzusehen, wieviele und welche FileLog-Devices mit definiert wurden, dann ahnst du vielleicht, was ich meine.
Und dass der broadcast-Filter jetzt nicht mehr greift, ist auch "gar nicht gut"...

@John30: könnte man dem ebusd das abgewöhnen und in der config irgendwo optional eine CID festlegen? (Das hilft allerdings nicht, wenn MQTT2_CLIENT eingesetzt wird, ist also keine Lösung, sondern nur eine Verbesserung...).

ZitatMich stört das nicht wenn die Scan Infos in ein eigenes Device wandern, so bleibt die Übersicht besser als wenn alles in einem Device liegt. Bei den Templates mache ich es ja auch so, dass ich eigene Devices generiere nur der Übersicht halber.
Meine Meinung: Es sollte zwar alles in ein eigenes Device, was wirklich separates "Gerät" (auch im Hardware-Sinn) ist. Ob aber die "Atomisierung" aller Informationen Sinn macht, erscheint mir nicht so ganz zwingend, vor allem dann nicht, wenn diese Art Daten tatsächlich auf (fast) allen Systemen vorhanden sind und im Prinzip statisch (sind die scan-Infos doch im wesentlichen, oder?). Dann hat man alle Infos "an einem Ort" und kann dann ggf. selbst in STATE packen, was man da haben möchte (macht m.E. bei dieser Art Info nicht den großen Sinn).

Unabhängig von allem, müssen wir erst mal funktionierende Teil-Abfragen haben und können dann immer noch entscheiden, wie es effektiv weitergehen soll. Ich würde jetzt mal mit folgendem an den Start gehen:
attr MQTT2_ebusd bridgeRegexp (ebus.)[^/]*/(bai|[\d]+|cc|e7f|ehp|f[\d][\d]|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"\
(ebus.)[^/]*/(global|broadcast|general|scan([^/]*))/.*:.* "$1"


Grade zu den Geräten ohne ReadingList: werden die aktualisiert, wenn du das betreffende Browserfenster einfach offen hältst? (Ich habe sowas ähnliches mit meinen HM-RTs/WTs realisiert, und da werden "externe Daten" (von anderen Kanälen als dem dargestellten) nur dann aktualisiert, wenn sich ein "echtes" Reading des Devices ändert.) Ansonsten muß man die Seite neu laden...

Zur Belastung mit der bridgeRegexp: Die wird nach meinem Verständnis ja erst aufgerufen, wenn zwei Bedingungen zutreffen:
1. muß autocreate aktiv sein und (v.a.)
2. darf es nicht schon ein readingList-Elemet geben, das "die Info fängt".
Gerade wegen 2. sehe ich den Impact als gering an, aber Rudi wird mir da bestimmt widersprechen, wenn ich das falsch verstanden haben sollte.
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

rudolfkoenig

#147
Die Belastung sehe ich auch nicht.
Wenn aber so ein Regexp noetig ist, dann macht man was falsch, oder die Architektur (meine Baustelle) ist daneben, da man das nicht sinnvoll warten kann.
Gibt es nicht was Anderes, an dem man solche Topics einfach erkennen kann?
Wenn nicht: kann man nicht mit den ebus Leuten reden, dass sie das einbauen?
Evtl. hilft auch eine Vereinfachung, was zwar theoretisch nicht alle zukuenftigen Faelle abfaengt, aber verstaendlich bleibt.

Uebrigens:
- [\d] ist equivalent mit \d
- (ebus.*)[^/]*/ kann man auch als (ebus.*?)/ schreiben
- v[\d][\d] deckt v81 ab.

rudolfkoenig

ZitatIch habe mit dem ganzen MQTT2 Zeugs jetzt jede Menge DbLogExclude eingebaut, weil sonst die Db die Gui so langsam macht. Kritisch sind hier vor allem die readingsgroup weil die ja auch meist Temperaturen enthalten (die ohnehin schon abgelegt sind) die alle paar Sekunden eintreffen.
Man kann unerwuenschte Readings mit jsonMap unterdruecken, oder per event-min-interval filtern.
Allerdings waere sowas am besten auch im ebus2mqtt gefiltert: je frueher, desto besser.

Beta-User

Zitat von: rudolfkoenig am 05 April 2019, 10:27:12
Man kann unerwuenschte Readings mit jsonMap unterdruecken
Kommt mir wie eine neue Info vor. Ohne jetzt die Doku nochmal gegengeprüft zu haben: Wo findet man dazu eine Erklärung/ein Beispiel? Das wäre eventuell in der Tat ein Argument für "complex" bei manchen eigentlich einfachen Geräten.

Zitat von: rudolfkoenig am 05 April 2019, 10:15:37
Evtl. hilft auch eine Vereinfachung, was zwar theoretisch nicht alle zukuenftigen Faelle abfaengt, aber verstaendlich bleibt.
Na ja, da das via template kommt, kann es m.E. auch kompliziert sein und braucht nicht unbedingt durch den User verstanden zu werden. Allerdings ist die Topic-Struktur insgesamt schon eine Sache, die eventuell zu überdenken wäre (@Rudi: John30 liest hier ja mit, du "redest" also bereits mit ihm...). Aber wenn das Konzept eben so ist, dass der ebusd eben eine Art bridge für die am Bus angeschlossenen Geräte ist, und die so unterschiedlich sein können, ist es eben, wie es ist... Man sollte nur zusammenfassen, was inhaltlich zusammen gehört. (In diese Richtung gingen ja meine wiederholten Fragen, ob es nicht sinnvoll wäre, manche Dinge zusammenzufassen).

ZitatUebrigens:
- [\d] ist equivalent mit \d
- (ebus.*)[^/]*/ kann man auch als (ebus.*?)/ schreiben
- v[\d][\d] deckt v81 ab.
Danke für die Hinweise, ich bin auch erst am lernen und kopiere (zu?) oft einfach Sachen, die ich woanders gesehen habe.
"(ebus.)[^/]*/" sollte so bleiben, da (ggf. auch erst über einen Umweg) gelegentlich auch sehr schräge "vorneweg"-Angaben, beginnend mit "ebusd" gebildet wurden. "ebusd" wird am Dämon konfiguriert und ist Quasi-Standard. Da es möglich ist, dass jemand mehrere ebus-Dämonen betreibt, wäre dann eben der nächste mit "ebuse" oder "ebusf" zu konfigurieren, da kommt der eine Punkt her...

Bereinigte Fassung:
attr MQTT2_ebusd bridgeRegexp (ebus.)[^/]*/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
(ebus.)[^/]*/(global|broadcast|general|scan([^/]*))/.*:.* "$1"


Ist am Testsystem eingerichtet, scheint (bis auf das von mir nicht testbare scan!) zu funktionieren.
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