mqtt2.template: bugs, Fragen, Anregungen

Begonnen von Beta-User, 15 Dezember 2018, 11:44:43

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Zitat@Rudi, bzw. sonst ein mitlesender Mod: Kannst du das mit dem anpinnen bitte erledigen?
Habs gemacht.

TomLee

In einigen Templates (älteren und neueren) werden HTML-Tags in farewell verwendet die in dem Dialogfeld gar nicht "interpretiert" werden.
Stolpere nur so nebenbei darauf und frage mich ob das mal ging und jetzt nicht mehr ?
@Beta-User: Falls es noch nie ging, warum verwendest die dann immer wieder ?

Beta-User

Zitat von: TomLee am 07 Dezember 2022, 16:55:21
@Beta-User: Falls es noch nie ging, warum verwendest die dann immer wieder ?
Keine Ahnung, ob es je ging ::) .
Werfe ich bei Gelegenheit dann raus, falls was zu ändern ist bzw. wenn es mir wo auffällt.
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

TomLee

#513
Hi,

es ist bestimmt was ganz banales, was mach ich bei der rL denn noch falsch das es im Dialogfeld zu den u.a. Meldungen kommt:
# tasmota+bla
name:tasmota_bla
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:bla
order:A_01b2
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}tele$3" : undef }
par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }
par:IO_DEV;Currently used IO;{ AttrVal('DEVICE','IODev',InternalVal('DEVICE','IODev',undef)->{NAME}) }
attr DEVICE devStateIcon Motion..true:people_sensor Motion..false:motion_detector
attr DEVICE event-on-change-reading occupancy
attr DEVICE icon people_sensor
attr DEVICE jsonMap Switch1:occupancy
attr DEVICE model tasmota_bla
attr DEVICE readingList \
TELETOPIC/INFO.:.* {}
TELETOPIC/LWT:.* LWT\
TELETOPIC/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/STATE:.* {}\
STATTOPIC/POWER:.* occupancy\
STATTOPIC/RESULT:.* {}
attr DEVICE stateFormat Motion: occupancy
attr DEVICE timestamp-on-change-reading occupancy
deletereading -q DEVICE .*
set IO_DEV publish CMNDTOPIC/Backlog SwitchMode1 1; StateText1 false; StateText1 true; TelePeriod 3600;
set IO_DEV publish CMNDTOPIC/Restart 1
setreading DEVICE attrTemplateVersion 20xxxxxx


Unknown command tele/tasmota_55756B/INFO.:.*, try help.
Unknown command .*, try help.
Unknown command tele/tasmota_55756B/LWT:.*, try help.
Unknown command tele/tasmota_55756B/SENSOR:.*, try help.
Unknown command tele/tasmota_55756B/STATE:.*, try help.
Unknown command stat/tasmota_55756B/POWER:.*, try help.
Unknown command stat/tasmota_55756B/RESULT:.*, try help.


edit:

bei TELETOPIC/INFO... ist das \ am Ende bei meinen Tests vorhanden, ist hier nur ein Kopierfehler

define MQTT2_tasmota_55756B MQTT2_DEVICE tasmota_55756B
attr MQTT2_tasmota_55756B readingList stat/tasmota_55756B/RESULT:.* { json2nameValue($EVENT) }\
tele/tasmota_55756B/LWT:.* LWT\
tele/tasmota_55756B/INFO1:.* { json2nameValue($EVENT) }\
tele/tasmota_55756B/INFO2:.* { json2nameValue($EVENT) }\
tele/tasmota_55756B/INFO3:.* { json2nameValue($EVENT) }\
tele/tasmota_55756B/STATE:.* { json2nameValue($EVENT) }\
tele/tasmota_55756B/SENSOR:.* { json2nameValue($EVENT) }\
stat/tasmota_55756B/POWER:.* POWER
attr MQTT2_tasmota_55756B room MQTT2_DEVICE
#   CFGFN     
#   CID        tasmota_55756B
#   DEF        tasmota_55756B
#   FUUID      63aaf0e6-f33f-78f5-d19f-4aef827704920c7e
#   IODev      MQTT2_Server
#   LASTInputDev MQTT2_Server
#   MQTT2_Server_CONN MQTT2_Server_192.168.188.25_53729
#   MQTT2_Server_MSGCNT 4
#   MQTT2_Server_TIME 2022-12-27 14:21:06
#   MSGCNT     4
#   NAME       MQTT2_tasmota_55756B
#   NR         79962
#   STATE      ???
#   TYPE       MQTT2_DEVICE
#   eventCount 12
#   .DT:
#     DEVICETOPIC MQTT2_tasmota_55756B
#   .attraggr:
#   .attrminint:
#   READINGS:
#     2022-12-27 14:19:44   Heap            27
#     2022-12-27 14:19:34   IODev           MQTT2_Server
#     2022-12-27 14:19:40   Info1_FallbackTopic cmnd/DVES_55756B_fb/
#     2022-12-27 14:19:40   Info1_GroupTopic cmnd/tasmotas/
#     2022-12-27 14:19:40   Info1_Module    Generic
#     2022-12-27 14:19:40   Info1_Version   12.3.1(tasmota)
#     2022-12-27 14:19:40   Info2_Hostname  tasmota-55756B-5483
#     2022-12-27 14:19:40   Info2_IPAddress 192.168.188.25
#     2022-12-27 14:19:40   Info2_WebServerMode Admin
#     2022-12-27 14:19:40   Info3_BootCount 98
#     2022-12-27 14:19:40   Info3_RestartReason Software/System restart
#     2022-12-27 14:19:40   LWT             Online
#     2022-12-27 14:19:44   LoadAvg         19
#     2022-12-27 14:19:44   MqttCount       1
#     2022-12-27 14:21:06   POWER           true
#     2022-12-27 14:19:35   Restart         Restarting
#     2022-12-27 14:19:44   Sleep           50
#     2022-12-27 14:19:44   SleepMode       Dynamic
#     2022-12-27 14:19:44   Switch1         true
#     2022-12-27 14:19:44   Time            2022-12-27T14:19:43
#     2022-12-27 14:19:44   Uptime          0T00:00:08
#     2022-12-27 14:19:44   UptimeSec       8
#     2022-12-27 14:19:44   Wifi_AP         1
#     2022-12-27 14:19:44   Wifi_BSSId      02:EC:DA:FD:26:1A
#     2022-12-27 14:19:44   Wifi_Channel    3
#     2022-12-27 14:19:44   Wifi_Downtime   0T00:00:03
#     2022-12-27 14:19:44   Wifi_LinkCount  1
#     2022-12-27 14:19:44   Wifi_Mode       11n
#     2022-12-27 14:19:44   Wifi_RSSI       68
#     2022-12-27 14:19:44   Wifi_SSId       FBF
#     2022-12-27 14:19:44   Wifi_Signal     -66
#     2022-12-27 14:21:04   associatedWith  MQTT2_Owntracks_Bridge
#
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Heap 27
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:34 IODev MQTT2_Server
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info1_FallbackTopic cmnd/DVES_55756B_fb/
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info1_GroupTopic cmnd/tasmotas/
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info1_Module Generic
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info1_Version 12.3.1(tasmota)
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info2_Hostname tasmota-55756B-5483
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info2_IPAddress 192.168.188.25
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info2_WebServerMode Admin
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info3_BootCount 98
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 Info3_RestartReason Software/System restart
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:40 LWT Online
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 LoadAvg 19
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 MqttCount 1
setstate MQTT2_tasmota_55756B 2022-12-27 14:21:06 POWER true
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:35 Restart Restarting
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Sleep 50
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 SleepMode Dynamic
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Switch1 true
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Time 2022-12-27T14:19:43
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Uptime 0T00:00:08
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 UptimeSec 8
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_AP 1
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_BSSId 02:EC:DA:FD:26:1A
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_Channel 3
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_Downtime 0T00:00:03
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_LinkCount 1
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_Mode 11n
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_RSSI 68
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_SSId FBF
setstate MQTT2_tasmota_55756B 2022-12-27 14:19:44 Wifi_Signal -66
setstate MQTT2_tasmota_55756B 2022-12-27 14:21:04 associatedWith MQTT2_Owntracks_Bridge


Beta-User

Hmm, irgendwie irritierend, dass da bisher noch keiner drüber gestolpert ist...
Anscheinend muss die LWT-Zeile am Anfang stehen.
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

Martin Fischer

Hallo Zusammen,

seit vielen Jahren setze ich 1-Wire ein. Dazu hatte ich die initialen Module für FHEM ins Leben gerufen und später, gemeinsam mit Boris, die Module OWServer und OWDevice entwickelt.

Leider kommt es bei meinen Netzwerk immer wieder zu BlockingCalls, so dass andere Module nachhaltig beeinträchtigt werden. Selbst eine Auslagerung auf ein dediziertes FHEM System, läuft nicht immer "rund".

Daher will ich meine komplette 1-Wire Anbindung FHEM-seitig über MQTT abwickeln. Hierzu habe ich ein schönes Projekt gefunden:
https://github.com/FragJage/MqttOwfs

Die Daten werden brav an einen MQTT2 Server Device geliefert und im "General Bridge" Device wird eine entsprechende readingList erzeugt. (Ausschnitt):
MqttOwfs:owfs/20\x2e03F30F000000/PIO\x2eA:.* PIO.A
MqttOwfs:owfs/20\x2e03F30F000000/PIO\x2eB:.* PIO.B
MqttOwfs:owfs/20\x2e03F30F000000/PIO\x2eC:.* PIO.C
MqttOwfs:owfs/20\x2e03F30F000000/PIO\x2eD:.* PIO.D
MqttOwfs:owfs/20\x2e03F30F000000/volt\x2eA:.* volt.A
MqttOwfs:owfs/20\x2e03F30F000000/volt\x2eB:.* volt.B
MqttOwfs:owfs/20\x2e03F30F000000/volt\x2eC:.* volt.C
MqttOwfs:owfs/20\x2e03F30F000000/volt\x2eD:.* volt.D
MqttOwfs:owfs/20\x2e03F30F000000/volt2\x2eA:.* volt2.A
MqttOwfs:owfs/20\x2e03F30F000000/volt2\x2eB:.* volt2.B
MqttOwfs:owfs/20\x2e03F30F000000/volt2\x2eC:.* volt2.C
MqttOwfs:owfs/20\x2e03F30F000000/volt2\x2eD:.* volt2.D
[...]
MqttOwfs:owfs/28\x2e525715020000/temperature:.* temperature
MqttOwfs:owfs/28\x2e525715020000/temphigh:.* temphigh
MqttOwfs:owfs/28\x2e525715020000/templow:.* templow
[...]
MqttOwfs:owfs/12\x2e1F2173000000/PIO\x2eA:.* PIO.A
MqttOwfs:owfs/12\x2e1F2173000000/PIO\x2eB:.* PIO.B
MqttOwfs:owfs/12\x2e1F2173000000/sensed\x2eA:.* sensed.A
MqttOwfs:owfs/12\x2e1F2173000000/sensed\x2eB:.* sensed.B
[...]
MqttOwfs:owfs/01\x2e463A73140000/isPresent:.* isPresent
[...]
MqttOwfs:owfs/81\x2e93302D000000/isPresent:.* isPresent
[...]
MqttOwfs:owfs/1D\x2eD1490F000000/counters\x2eA:.* counters.A
MqttOwfs:owfs/1D\x2eD1490F000000/counters\x2eB:.* counters.B
[...]

Bisher habe ich noch nicht mit den Templates gearbeitet, würde diese aber gerne nutzen, entsprechend dem Typ korrekte Devices anzulegen.

Anhand der 1-Wire Family, die ersten beiden Stellen der ID im Topic bilden diese ab, möchte ich beim Autocreate dem Devicenamen die Klartextbezeichnung voranstellen. Das "1D" steht z.B. für ein "DS2423" und das "20" für ein "DS2450", usw. Daraus soll dann je ein Device mit dem Namen "DS2423_1D.D1490F000000" erzeugt werden (und wer sich an dem "." im Devicenamen stört, optional auch ohne diesem).

Jedes Device soll dann anhand der Family Id auch ein entsprechendes model Attribut erhalten und je nach Typ angepasste stateFormats und ggf. userReadings vorbelegen. Ich würde hierzu ein dediziertes "Bridge Device" einsetzen wollen, dass die entsprechenden Topics verarbeitet und via Autocreate neue Device anlegt.

Hat wer Lust, das Template / die Templates? gemeinsam mit mir zu entwickeln? Vielleicht jemand, der tiefer im Thema ist, als ich es derzeit bin. ;)

Abgesehen vom Timing zur Verarbeitung der Nutzlast durch den MQTT2 Server, hätten wir dann eine zu 100% BlockingCall freie Implementierung von 1-Wire via MQTT.
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Beta-User

Hallo Martin,

kann gerne versuchen, mit "allgemeinem AttrTemplate-Wissen" weiterzuhelfen, allerdings laufen hier nur "einige" DS18B20, die ebenfalls asynchron per MySensors-Arduinos ausgelesen werden - mit OWServer habe ich daher nichts am Hut.

Würde vorschlagen, das in einem separaten Thread zu behandeln?

An sich scheint das ähnlich zu sein wie einige andere "Dienst + viele Einzelgeräte"-Lösungen, die "irgendwas" in MQTT überführen, wobei bei der Vielfalt der möglichen Geräte der Vergleich zu zigbee2mqtt vielleicht am besten paßt. Dazu gäbe es auch ein etwas ausführlichereres Wiki unter https://wiki.fhem.de/wiki/Zigbee2mqtt.

Man würde also ein "bridge-Device" basteln müssen, das über "bridgeRegexp" dann alles, was zu einem 1-Wire-Baustein gehört je in eine eigene MQTT2_DEVICE-Instanz verweist. Soweit mir das in Erinnerung ist, kann man dabei aber nicht einfach einen "ID2model"-Hash bauen, sondern müsste das hart vercoden, wie z.B. in dieser exemplarischen Zeile:
 
attr bridge bridgeRegexp owfs/(28[^/]+)/.* DS18B20_$1
Anschließend könnte man für derartige Devices dann passende readingList-Attribute vergeben und "schöne" stateFormat/devStateIcon-defaults vorbereiten.... Wobei es sich bei der Namensvergabe kaum (ohne weiteres) vermeiden läßt, dass das "MQTT_"-Präfix dazukommt.

"Blöd" ist halt, dass das Punkte in den Topics drin sind, das ist erfahrungsgemäß nicht so richtig lustig und ich komme auch immer wieder ins Schleudern, wie man damit umgehen muss. Aber Versuch macht bekanntlich kluch (wenn man nicht in den Quelltext schauen will).
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

Martin Fischer

Hallo Jörg,

Zitat von: Beta-User am 17 April 2023, 16:00:53kann gerne versuchen, mit "allgemeinem AttrTemplate-Wissen" weiterzuhelfen, allerdings laufen hier nur "einige" DS18B20, die ebenfalls asynchron per MySensors-Arduinos ausgelesen werden - mit OWServer habe ich daher nichts am Hut.
gerne nehme ich die Hilfe an! Mit OWServer hat das hier allerdings auch nichts zu tun. Die "Architektur" dahinter ist:
OWFS Server -> MqttOwfs Daemon -> MQTT2_SERVER -> MQTT2_DEVICE

ZitatWürde vorschlagen, das in einem separaten Thread zu behandeln?
Ich bin da leidenschaftslos.

ZitatMan würde also ein "bridge-Device" basteln müssen, das über "bridgeRegexp" dann alles, was zu einem 1-Wire-Baustein gehört je in eine eigene MQTT2_DEVICE-Instanz verweist.
Das ist soweit verstanden und auch in der Anwendung. Aus dieser Richtung bin ich gestartet:
[^/:]+/(1D\\x2e\S{12})/.*:.* DS2423_$1erzeugt ein Device namens
MQTT_DS2423_1D.40500B000000Man achte auf den Punkt, der hier korrekt verarbeitet wird. Ansonsten ist mir Deine Anmerkung bzgl. der zulässigen Zeichen im Topic bewusst, doch der MqttOwfs Daemon kodiert es (leider) so. FHEM selbst hat keine Probleme damit. So nutze ich Punkte in allen meinen FHEM Notationen schon seit mehr als 15 Jahren. ;)

ZitatAnschließend könnte man für derartige Devices dann passende readingList-Attribute vergeben und "schöne" stateFormat/devStateIcon-defaults vorbereiten.... Wobei es sich bei der Namensvergabe kaum (ohne weiteres) vermeiden läßt, dass das "MQTT_"-Präfix dazukommt.
Ja, das "MQTT_"-Präfix ist nicht schön aber damit lebe ich erst einmal. Genau um den Rest soll es gehen:
vorgefertigte Templates, die sich an der "Familie" orientieren.
Ein DS18B20 soll z.B. automatisch die Temperatur im STATE anzeigen und ein DS2406 z.B. ob ein Kontakt offen oder geschlossen ist.

Natürlich habe ich mir Beispiel angesehen, vielleicht auch noch ein Verständnisproblem.

"Meine Denke" ist ein entsprechendes Template a-la
name:MqttOwfs_Gateway
filter:TYPE=MQTT2_DEVICE
desc:Use this for the Mqtt daemon to communicate with one wire device.<br>For further details visit https://github.com/FragJage/MqttOwfs.
order:M_02
par:DEV_FAMILY;DEV_FAMILY contains the 1-Wire family identifier;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m,[^/:]+/([0-9A-Z]{2})\\x2e\S{12}/.*:.*, ? $1 : undef}
par:DEV_ID;DEV_ID contains the 1-Wire device id;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m,[^/:]+/([0-9A-Z]{2})\\x2e(\S{12})/.*:.*, ? "$1.$2" : undef}
[...]
anzulegen und dann für jeden Typ ein weiteres Template a-la
name:MqttOwfs_Gateway_DS2423
prereq:{my @devices=devspec2array("model=MqttOwfs_Gateway");return 1 if $devices[0];return 0}
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*/1D[^/]*/.*
desc:use this with an DS2423 sensor
order:X_01f
[...]
defmod ??? MQTT2_\DEVICE <DS_xxxx>_DEV_ID
(oder so) vorzuhalten.

Aber vermutlich bin ich noch nicht 100% auf Spur bzgl. der Templates. So würde ich ja bereits DEV_ID und DEV_FAMILY im "MqttOwfs_Gateway" parsen und auswerten. Dieses Template würde ich - nach meinem Verständnis - auch als Vorlage für das MQTT2_"bridge"_DEVICE nehmen.

Ähnlich dem "MQTT2_CLIENT_general_bridge" Template aus mqtt2.template. Dort wäre dann auch die Regexp aufgehoben:
attr DEVICE bridgeRegexp \
[^/:]+/(01\\x2e\S{12})/.*:.* DS2401_$1\
[^/:]+/(05\\x2e\S{12})/.*:.* DS2405_$1\
[^/:]+/(10\\x2e\S{12})/.*:.* DS18S20_$1\
[^/:]+/(12\\x2e\S{12})/.*:.* DS2406_$1\
[...]

Aber ich glaube, dass ich mich gerade noch etwas "verrannt" habe. Ich will das Prefix z.B. DS18B20_ vor den Devicenamen stellen aber auch als Modell im entsprechenden Attribut hinterlegen. Und da der Devicename später ja auch umbenannt werden könnte, ist das nur für das Autocreate von Bedeutung.

Bzgl. der Vorarbeiten brauche ich mal etwas Nachhilfe:
- erst das Template für die Bridge bauen und festlegen, WAS alles dort definiert werden kann
- dann je FAMILY ein weiteres Template mit prereq auf die Bridge

Liege ich da richtig? Werden die "FAMILY" Templates dann beim Autocreate verwendet?

Wald: Bäume -> Blätter* ;-)

* Warum musste ich jetzt an Trees und Leaves von Novel Netware 4.0 denken? *amkopfkratz*  :o
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Beta-User

Zitat von: Martin Fischer am 17 April 2023, 21:38:49gerne nehme ich die Hilfe an! Mit OWServer hat das hier allerdings auch nichts zu tun. Die "Architektur" dahinter ist:
OWFS Server -> MqttOwfs Daemon -> MQTT2_SERVER -> MQTT2_DEVICE
Ok, sorry, da war ich ungenau, gemeint war OWFS Server, die Architektur ist soweit klar.

 
Zitat
ZitatWürde vorschlagen, das in einem separaten Thread zu behandeln?
Ich bin da leidenschaftslos.
 

 :)  Scheint vollends schnell zu gehen, von daher können wir auch hier bleiben. Mir ging/geht es eher darum, "unfreiwillige Mitleser", die hier irgendwann mal was gepostet hatten, nicht zu langweilen...
Zitat
ZitatMan würde also ein "bridge-Device" basteln müssen, das über "bridgeRegexp" dann alles, was zu einem 1-Wire-Baustein gehört je in eine eigene MQTT2_DEVICE-Instanz verweist.
Das ist soweit verstanden und auch in der Anwendung. Aus dieser Richtung bin ich gestartet:
[^/:]+/(1D\\x2e\S{12})/.*:.* DS2423_$1erzeugt ein Device namens
MQTT_DS2423_1D.40500B000000Man achte auf den Punkt, der hier korrekt verarbeitet wird. Ansonsten ist mir Deine Anmerkung bzgl. der zulässigen Zeichen im Topic bewusst, doch der MqttOwfs Daemon kodiert es (leider) so. FHEM selbst hat keine Probleme damit. So nutze ich Punkte in allen meinen FHEM Notationen schon seit mehr als 15 Jahren. ;)
 

 Na ja, wenn es "von außen" so (unbeeinflussbar) kommt, ist es halt so. Den Punkt finde ich persönlich nicht so "anfängergeeignet", da "doppeldeutig", aber jeder wie er mag. Im MQTT-Topic-Kontext ist es halt "schlecht lesbar" (für Uneingeweihte).

Zitat
ZitatAnschließend könnte man für derartige Devices dann passende readingList-Attribute vergeben und "schöne" stateFormat/devStateIcon-defaults vorbereiten.... Wobei es sich bei der Namensvergabe kaum (ohne weiteres) vermeiden läßt, dass das "MQTT_"-Präfix dazukommt.
Ja, das "MQTT_"-Präfix ist nicht schön aber damit lebe ich erst einmal. Genau um den Rest soll es gehen:
vorgefertigte Templates, die sich an der "Familie" orientieren.
 

Ok, also geht es im Wesentlichen um das "dazwischen". Dazu ein paar Anmerkungen:
Du machst eine m.E. nicht nötige Unterscheidung zwischen dem "MqttOwfs_Gateway" und dem "bridge"-Device? Die bridgeRegexp ist m.E. nur ein funktionaler Teil, der zum "Zentraldevice" gehört und eben eine "Vorsortierung macht, das "MqttOwfs_Gateway" braucht als Parameter dagegen eigentlich nur die BASE_ID (also das base-Topic wie im MqttOwfs Daemon konfiguriert).

 
ZitatAber vermutlich bin ich noch nicht 100% auf Spur bzgl. der Templates. So würde ich ja bereits DEV_ID und DEV_FAMILY im "MqttOwfs_Gateway" parsen und auswerten.
 

Nein, s.o.. Davon abgesehen: Man muss sowieso "auf jeder Stufe" (also in jedem attrTemplate) alle erforderlichen Parameter wieder separat ermitteln. Man kann höchstens bereits ermittelte Parameter bei einem internen attrTemplate-Aufruf mit übergeben (das ist hier aber voraussichtlich nicht relevant).

 
ZitatAber ich glaube, dass ich mich gerade noch etwas "verrannt" habe. Ich will das Prefix z.B. DS18B20_ vor den Devicenamen stellen aber auch als Modell im entsprechenden Attribut hinterlegen. Und da der Devicename später ja auch umbenannt werden könnte, ist das nur für das Autocreate von Bedeutung.
Bzgl. der Vorarbeiten brauche ich mal etwas Nachhilfe:
- erst das Template für die Bridge bauen und festlegen, WAS alles dort definiert werden kann
- dann je FAMILY ein weiteres Template mit prereq auf die Bridge
Liege ich da richtig? Werden die "FAMILY" Templates dann beim Autocreate verwendet?
"Verrannt" würde ich es nicht nennen. Du scheinst nur eventuell zu viel zu erwarten und zu viel auf einmal erreichen zu wollen :) .
Schritt 1 ist erst mal, das "Zentraldevice" schlicht funktional zu haben und zu wissen, was man von ihm erwartet. MAn. sollte das sein:
- Statusinfo zum OWFS Server (wenn möglich) und zum MqttOwfs Daemon (online/offline, evtl. Fehlermeldungen)
- bridgeRegexp, die schlicht alles, was zu einer (noch nicht bekannten) Seriennummer gehört ein eigenes Device weitergibt.

Schritt 2 wäre dann, "einfache Devices" wie Temperatursensoren "hübsch" zu konfigurieren,

Schritt 3 würde sich dann mit "nicht ganz einfachen Devices" befassen (z.B. latch.A ist ein Relay, latch.B ein anderes => "split"-attrTemplate, das beide Relays mit on/off schaltbar macht, damit SetExtensions genutzt werden können.

Schritt 4 wäre dann, mit "prereq" und "filter" ggf. eine Benutzerführung zu basteln, mit der man (neben den unvermeidlichen allgemeinen Sachen) nur noch sieht, was einen grade interessieren könnte (prereq: Zentralevice, filter: anhand der ID?).

Klarer bzw. hilfreich?
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

Martin Fischer

Sodele, gerade etwas Zeit gehabt...

Danke für Deine Ausführungen. Ich habe mal etwas gestrickt. Soweit funktioniert es. Alle Devices werden angelegt, nur die automatische Zuordnung des Templates bei der Erstellung eines neuen Devices, hier im Beispiel ein DS18B20, erfolgt nicht. Manuell geht es jedoch.

Hast Du eine Idee für mich, warum das Template "MqttOwfs_DS18B20" nicht automatisch bei der Anlage des Devices ausgeführt wird?

MQTT2_DS1420_81.93302D000000
MQTT2_DS1420_81.A7C02F000000
MQTT2_DS18B20_28.28609C030000
MQTT2_DS18B20_28.2C373C020000
MQTT2_DS18B20_28.4B909C030000
MQTT2_DS18B20_28.4F999C030000
MQTT2_DS18B20_28.525715020000
MQTT2_DS18B20_28.65529C030000
MQTT2_DS18B20_28.796C9C030000
MQTT2_DS18B20_28.F9673C020000
MQTT2_DS18B20_28.FD649C030000
MQTT2_DS2401_01.463A73140000
MQTT2_DS2423_1D.13C80F000000
MQTT2_DS2423_1D.17C90F000000
MQTT2_DS2423_1D.40500B000000
MQTT2_DS2423_1D.4EC80D000000
MQTT2_DS2423_1D.57D20D000000
MQTT2_DS2423_1D.59600B000000
MQTT2_DS2423_1D.A1460F000000
MQTT2_DS2423_1D.EA490F000000
MQTT2_DS2438_26.126545010000
MQTT2_DS2438_26.168417010000
MQTT2_DS2438_26.28A940010000
MQTT2_DS2438_26.455E23010000
MQTT2_DS2438_26.FBA040010000
MQTT2_DS2450_20.03F30F000000
MQTT2_DS2450_20.1FF3461B0000
owfs2mqtt.bridge

name:MqttOwfs_bridge
filter:TYPE=MQTT2_DEVICE
desc:Use this for the Mqtt daemon to communicate with one wire device.<br>For further details visit https://github.com/FragJage/MqttOwfs.
order:MO_00
par:BASE_TOPIC;base topic as set in MqttOwfs.conf of the MqttOwfs Daemon;{ AttrVal("DEVICE","devicetopic","") =~ m,[\b]?([^/:]+)(/.+)?, ? $1 : AttrVal("DEVICE","readingList","") =~ m,[\b]?([^/:]+)/owfs/.+, ? $1 : undef }
par:ICON;ICON as set, defaults to mqtt;{ AttrVal("DEVICE","icon","mqtt") }
attr DEVICE devicetopic BASE_TOPIC
attr DEVICE bridgeRegexp\
BASE_TOPIC/(01\x2e\S{12})/.*:.* "DS2401_$1"\
BASE_TOPIC/(05\x2e\S{12})/.*:.* "DS2405_$1"\
BASE_TOPIC/(10\x2e\S{12})/.*:.* "DS18S20_$1"\
BASE_TOPIC/(12\x2e\S{12})/.*:.* "DS2406_$1"\
BASE_TOPIC/(1D\x2e\S{12})/.*:.* "DS2423_$1"\
BASE_TOPIC/(20\x2e\S{12})/.*:.* "DS2450_$1"\
BASE_TOPIC/(21\x2e\S{12})/.*:.* "DS1921_$1"\
BASE_TOPIC/(22\x2e\S{12})/.*:.* "DS1822_$1"\
BASE_TOPIC/(26\x2e\S{12})/.*:.* "DS2438_$1"\
BASE_TOPIC/(28\x2e\S{12})/.*:.* "DS18B20_$1"\
BASE_TOPIC/(29\x2e\S{12})/.*:.* "DS2408_$1"\
BASE_TOPIC/(3A\x2e\S{12})/.*:.* "DS2413_$1"\
BASE_TOPIC/(81\x2e\S{12})/.*:.* "DS1420_$1"\
BASE_TOPIC/([0-9A-Z]\x2e\S{12})/.*:.* "OWFS_$1"
attr DEVICE autocreate 1
# set DEVICE attrTemplate do_general_mqtt_cleanup
attr DEVICE model MqttOwfs_bridge
setreading DEVICE attrTemplateVersion 20230418

name:MqttOwfs_DS18B20
prereq:{my @devices=devspec2array("model=MqttOwfs_bridge");;return 1 if $devices[0];;return 0}
desc:DS18B20 sensor via MqttOwfs
filter:TYPE=MQTT2_DEVICE:FILTER=CID=DS18B20_28\.[0-9A-Z]{12}
order:MO_DS18B20
par:BASE_TOPIC;base topic as set in MqttOwfs.conf of the MqttOwfs Daemon;{ AttrVal("DEVICE","devicetopic","") =~ m,[\b]?([^/:]+)(/.+)?, ? $1 : AttrVal("DEVICE","readingList","") =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
par:DEV_FAMILY;DEV_FAMILY contains the 1-Wire family identifier;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m,[^/:]+/([0-9A-Z]{2})\\x2e\S{12}/.*:.*, ? $1 : undef}
par:DEV_ID;DEV_ID contains the 1-Wire device id;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m,[^/:]+/([0-9A-Z]{2})\\x2e(\S{12})/.*:.*, ? "$1.$2" : undef}
attr DEVICE stateFormat {sprintf ("T: %.1f°C", ReadingsVal($name,'temperature',0)) }
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE readingList $\DEVICETOPIC/temperature:.* temperature\
$\DEVICETOPIC/templow:.* templow\
$\DEVICETOPIC/temphigh:.* temphigh
deletereading -q DEVICE (?!associatedWith|IODev).*
attr DEVICE model DS18B20
setreading DEVICE attrTemplateVersion 20230418

Durch die Bridge frisch angelegt:
define MQTT2_DS18B20_28.525715020000 MQTT2_DEVICE DS18B20_28.525715020000
attr MQTT2_DS18B20_28.525715020000 readingList owfs/28\x2e525715020000/temperature:.* temperature
attr MQTT2_DS18B20_28.525715020000 room AUTOCREATE
#   CFGFN     
#   CID        DS18B20_28.525715020000
#   DEF        DS18B20_28.525715020000
#   FUUID      643ef11a-f33f-ce77-d623-47b95a40667a995a
#   IODev      mqtt.server
#   LASTInputDev mqtt.server
#   MSGCNT     1
#   NAME       MQTT2_DS18B20_28.525715020000
#   NR         417
#   STATE      ???
#   TYPE       MQTT2_DEVICE
#   eventCount 2
#   mqtt.server_CONN mqtt.server_172.16.230.1_60068
#   mqtt.server_MSGCNT 1
#   mqtt.server_TIME 2023-04-18 21:36:43
#   READINGS:
#     2023-04-18 21:35:54   IODev           mqtt.server
#     2023-04-18 21:35:54   associatedWith  owfs2mqtt.bridge
#     2023-04-18 21:36:43   temperature     22
#   helper:
#     bm:
#       MQTT2_DEVICE_Attr:
#         cnt        1
#         dmx        -1000
#         dtot       0
#         dtotcnt    0
#         mTS        18.04. 21:35:54
#         max        0.000392913818359375
#         tot        0.000392913818359375
#         mAr:
#           set
#           MQTT2_DS18B20_28.525715020000
#           readingList
#           owfs/28\x2e525715020000/temperature:.* temperature
#       MQTT2_DEVICE_Define:
#         cnt        1
#         dmx        -1000
#         dtot       0
#         dtotcnt    0
#         mTS        18.04. 21:35:54
#         max        0.00113391876220703
#         tot        0.00113391876220703
#         mAr:
#           HASH(0x564526511cf8)
#           MQTT2_DS18B20_28.525715020000 MQTT2_DEVICE DS18B20_28.525715020000 mqtt.server
#       MQTT2_DEVICE_Get:
#         cnt        1
#         dmx        -1000
#         dtot       0
#         dtotcnt    0
#         mTS        18.04. 21:40:01
#         max        3.19480895996094e-05
#         tot        3.19480895996094e-05
#         mAr:
#           HASH(0x564526511cf8)
#           MQTT2_DS18B20_28.525715020000
#           ?
#       MQTT2_DEVICE_Set:
#         cnt        6
#         dmx        -1000
#         dtot       0
#         dtotcnt    0
#         mTS        18.04. 21:40:01
#         max        0.000113010406494141
#         tot        0.000241994857788086
#         mAr:
#           HASH(0x564526511cf8)
#           MQTT2_DS18B20_28.525715020000
#           ?
#
setstate MQTT2_DS18B20_28.525715020000 2023-04-18 21:35:54 IODev mqtt.server
setstate MQTT2_DS18B20_28.525715020000 2023-04-18 21:35:54 associatedWith owfs2mqtt.bridge
setstate MQTT2_DS18B20_28.525715020000 2023-04-18 21:36:43 temperature 22

MqttOwfs_DS18B20 Template, manuell zugewiesen:
define MQTT2_DS18B20_28.FD649C030000 MQTT2_DEVICE DS18B20_28.FD649C030000
attr MQTT2_DS18B20_28.FD649C030000 devicetopic owfs/28.FD649C030000
attr MQTT2_DS18B20_28.FD649C030000 model DS18B20
attr MQTT2_DS18B20_28.FD649C030000 readingList $DEVICETOPIC/temperature:.* temperature\
$DEVICETOPIC/templow:.* templow\
$DEVICETOPIC/temphigh:.* temphigh
attr MQTT2_DS18B20_28.FD649C030000 room AUTOCREATE
attr MQTT2_DS18B20_28.FD649C030000 stateFormat {sprintf ("T: %.1f°C", ReadingsVal($name,'temperature',0)) }
#   CFGFN     
#   CID        DS18B20_28.FD649C030000
#   DEF        DS18B20_28.FD649C030000
#   FUUID      643ef013-f33f-ce77-701d-b596f444e07dcb77
#   IODev      mqtt.server
#   LASTInputDev mqtt.server
#   MSGCNT     4
#   NAME       MQTT2_DS18B20_28.FD649C030000
#   NR         332
#   STATE      T: 23.1°C
#   TYPE       MQTT2_DEVICE
#   eventCount 6
#   mqtt.server_CONN mqtt.server_172.16.230.1_60068
#   mqtt.server_MSGCNT 4
#   mqtt.server_TIME 2023-04-18 21:38:09
#   OLDREADINGS:
#   READINGS:
#     2023-04-18 21:31:31   IODev           mqtt.server
#     2023-04-18 21:31:31   associatedWith  owfs2mqtt.bridge
#     2023-04-18 21:32:03   attrTemplateVersion 20230418
#     2023-04-18 21:38:09   temperature     23.125
#   helper:
#     bm:
#       MQTT2_DEVICE_Attr:
#         cnt        5
#         dmx        -1000
#         dtot       0
#         dtotcnt    0
#         mTS        18.04. 21:32:03
#         max        0.000235080718994141
#         tot        0.000686883926391602
#         mAr:
#           set
#           MQTT2_DS18B20_28.FD649C030000
#           readingList
#           $DEVICETOPIC/temperature:.* temperature
#$DEVICETOPIC/templow:.* templow
#$DEVICETOPIC/temphigh:.* temphigh
#       MQTT2_DEVICE_Define:
#         cnt        1
#         dmx        -1000
#         dtot       0
#         dtotcnt    0
#         mTS        18.04. 21:31:31
#         max        0.000837087631225586
#         tot        0.000837087631225586
#         mAr:
#           HASH(0x564526353850)
#           MQTT2_DS18B20_28.FD649C030000 MQTT2_DEVICE DS18B20_28.FD649C030000 mqtt.server
#       MQTT2_DEVICE_Get:
#         cnt        3
#         dmx        -1000
#         dtot       0
#         dtotcnt    0
#         mTS        18.04. 21:31:47
#         max        2.69412994384766e-05
#         tot        5.88893890380859e-05
#         mAr:
#           HASH(0x564526353850)
#           MQTT2_DS18B20_28.FD649C030000
#           ?
#       MQTT2_DEVICE_Set:
#         cnt        24
#         dmx        -1000
#         dtot       0
#         dtotcnt    0
#         mTS        18.04. 21:32:03
#         max        0.00835299491882324
#         tot        0.00937867164611816
#         mAr:
#           HASH(0x564526353850)
#           MQTT2_DS18B20_28.FD649C030000
#           attrTemplate
#           MqttOwfs_DS18B20
#
setstate MQTT2_DS18B20_28.FD649C030000 T: 23.1°C
setstate MQTT2_DS18B20_28.FD649C030000 2023-04-18 21:31:31 IODev mqtt.server
setstate MQTT2_DS18B20_28.FD649C030000 2023-04-18 21:31:31 associatedWith owfs2mqtt.bridge
setstate MQTT2_DS18B20_28.FD649C030000 2023-04-18 21:32:03 attrTemplateVersion 20230418
setstate MQTT2_DS18B20_28.FD649C030000 2023-04-18 21:38:09 temperature 23.125
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Beta-User

Sieht doch schon gut aus!

Anmerkungen:
Zitatnur die automatische Zuordnung des Templates bei der Erstellung eines neuen Devices, hier im Beispiel ein DS18B20, erfolgt nicht.
Diese Erwartungshaltung kann attrTemplate nicht erfüllen, es ist immer so gedacht, dass der User für ein von autocreate erstelltes neues Device das passende attrTemplate manuell anwendet. Das gilt auch dann, wenn per bridgeRegexp das autocreate "angeschubst" wurde.

Kannst du mir diese Zeile aus bridgeRegexp erläutern:
BASE_TOPIC/([0-9A-Z]\x2e\S{12})/.*:.* "OWFS_$1"
Da scheint es um "alles mögliche" zu gehen, was mit dem OWFS-Server zu tun hat. Warum braucht da jedes Einzel-Zeichen ein eigenes Device?
Oder ist das so gedacht, dass alles andere erkannt wird, was oben nicht abgefrühstückt ist? Dann müßten es vorne zwei Zeichen sein, oder? Wenn ja: Obacht! Alle bridgeRegexp-Ausdrücke aller MQTT2_DEVICE-Instanzen werden intern in einem gemeinsamen Hash verwaltet, und "doppelte/mehrfache Treffer-Möglichkeiten" ergeben zufällige (!) Ergebnisse...! Lieber auf sowas verzichten!

Ansonsten noch zu dem DS18B20-template. "Üblich" wäre:
- ein Icon zu setzen
(- intern noch ein Sprachssteuerungs-attrTemplate aufzurufen, das dem Ding noch einen passenden "genericDeviceType" zuweist und einem "Klartextnamen"; gilt für switches oder Lichter, nicht bei Thermometern)
par:ICON;ICON as set, defaults to temperature_humidity;{ AttrVal("DEVICE","icon","temperature_humidity") }
attr DEVICE icon ICON
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

Martin Fischer

Zitat von: Beta-User am 19 April 2023, 11:48:32
Zitatnur die automatische Zuordnung des Templates bei der Erstellung eines neuen Devices, hier im Beispiel ein DS18B20, erfolgt nicht.
Diese Erwartungshaltung kann attrTemplate nicht erfüllen, es ist immer so gedacht, dass der User für ein von autocreate erstelltes neues Device das passende attrTemplate manuell anwendet. Das gilt auch dann, wenn per bridgeRegexp das autocreate "angeschubst" wurde.

Ok, dann hatte ich das Mißverstanden. Ich ging davon aus, warum auch immer, dass nach dem Autocreate automatisch das Template gezogen wird, was ja "genauestens" darauf zugeschnitten ist. Es fehlt ja eigentlich nur ein "set <device> attrTemplate <foobar>".

ZitatKannst du mir diese Zeile aus bridgeRegexp erläutern:
BASE_TOPIC/([0-9A-Z]\x2e\S{12})/.*:.* "OWFS_$1"

Da nicht alle 1wire Sensoren in der Bridge, sondern nur die geläufigen, abgefangen werden, werde nicht geparste Familycodes hiermit erfasst und zumindest noch mit dem Prefix OWFS_ versehen.

ZitatWenn ja: Obacht! Alle bridgeRegexp-Ausdrücke aller MQTT2_DEVICE-Instanzen werden intern in einem gemeinsamen Hash verwaltet, und "doppelte/mehrfache Treffer-Möglichkeiten" ergeben zufällige (!) Ergebnisse...! Lieber auf sowas verzichten!

Aus meiner Sicht ist die Gefahr doch eher zu vernachlässigen. Denn "BASE_TOPIC/([0-9A-Z]\x2e\S{12})/.*:.*"
erfasst ja nur Topics, die z.B. ausgeschrieben "owfs/4E\2xe93302D000000/<irgendwas>:<irgendwas>" (oder im Klartext "owfs/4E.93302D000000") treffen. Dies impliziert ja, dass eine 1wire Family, die mit 4E anfängt ja kein Template hat und daher eben das OWFS_ vorangestellt wird. Die Wahrscheinlichkeit, dass es weitere MQTT Topics in diesem Format vorliegen, sehe ich doch als eher sehr gering an.

ZitatAnsonsten noch zu dem DS18B20-template. "Üblich" wäre:
- ein Icon zu setzen
(- intern noch ein Sprachssteuerungs-attrTemplate aufzurufen, das dem Ding noch einen passenden "genericDeviceType" zuweist und einem "Klartextnamen"; gilt für switches oder Lichter, nicht bei Thermometern)
par:ICON;ICON as set, defaults to temperature_humidity;{ AttrVal("DEVICE","icon","temperature_humidity") }
attr DEVICE icon ICON

Die Frage ist ja hier: Was ist üblich? :D

Ich persönlich verzichte in meinen FHEM Instanzen nahezu komplett auf Icons. Nur sehr wenige Devices haben eins. Daher werde ich das in diesem Template für mich nicht erzwingen.  ;)

Das mit der Sprachsteuerung behalte ich im Hinterkopf für andere Geräteklassen. Danke für den Hinweis!

Nun gilt es noch die "komplizierteren" Devices anzugehen. Z.B. die, die einen Split erfordern. Hast Du hier noch ein gutes "nachvollziehbares" Beispiel für mich?

Da gäbe es z.B. noch Sensoren, die mehrere Kanäle für sensed, latch oder counter haben, um nur drei Beispiele zu nennen.
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Beta-User

Zitat von: Martin Fischer am 19 April 2023, 12:16:08Ok, dann hatte ich das Mißverstanden. Ich ging davon aus, warum auch immer, dass nach dem Autocreate automatisch das Template gezogen wird, was ja "genauestens" darauf zugeschnitten ist. Es fehlt ja eigentlich nur ein "set <device> attrTemplate <foobar>".
Na ja, das mit "genauestens" ist so eine Sache...
Für einen "autocreate-plus"-Mechanismus könnte man ein archetype einsetzen, aber m.E. lohnt das nicht. Die User, die attrTemplate kennen, kennen in der Regel den fehlenden Automatismus, und es geht immer noch (hauptsächlich) darum, Attribute zu setzen. Und die "gehören" halt dem User.

ZitatDa nicht alle 1wire Sensoren in der Bridge, sondern nur die geläufigen, abgefangen werden, werde nicht geparste Familycodes hiermit erfasst und zumindest noch mit dem Prefix OWFS_ versehen.
 

MAn. fehlt dann aber noch ein Zeichen in der Regex ;) .
Und wenn du das mal in einer Testinstallation dann mit der "zweistelligen" bridgeRegexp (mehrmals) versuchen magst, kannst du vielleicht verstehen, warum ich von solchen "Würfeleien" Abstand nehmen würde. Wer dann was hat, was noch nicht bekannt/hart vercoded ist, kann ja die bridgeRegexp einfach um den konkret erforderlichen Ausdruck erweitern, ist ja (fast) selbsterklärend, was schon da steht.


ZitatDie Frage ist ja hier: Was ist üblich? :D
 

Es stand da in Anführungsszeichen, weil man sich bekanntlich nicht über Geschmacksfragen zu streiten braucht. Gemeint war damit: "wir" machen das in den anderen attrTemplates eben so. Das hat teils historische Gründe, teils spiegelt das meinen ganz persönlichen Geschmack wieder, und teils entsprechend klare Forderungen ganzer Kohorten von Usern...

ZitatNun gilt es noch die "komplizierteren" Devices anzugehen. Z.B. die, die einen Split erfordern. Hast Du hier noch ein gutes "nachvollziehbares" Beispiel für mich?
Da gäbe es z.B. noch Sensoren, die mehrere Kanäle für sensed, latch oder counter haben, um nur drei Beispiele zu nennen.
Bei allem, was Sensorik ist, tendiere ich dazu, das im "Hauptdevice" zu lassen (also dem, was die bridgeRegexp für diese ID als CID erkennt und an autocreate weitergibt).

"split" spielt nur da eine Rolle, wo es um mehrere schaltbare Elemente (auf derselben Hardware) geht, vorrangig wegen der Themen SetExtensions und Sprachsteuerung.
Wenn du bisher keine MQTT2_DEVICEs hattest, wird vermutlich alles mehr oder weniger gut "nachvollziehbar" sein. Die vorhandenen haben alle ein "split" im Namen, kannst einfach von oben her in "zigbee2mqtt_2channel_split" oder "zigbee2mqtt_2channel_dimmer_split" schauen.
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

Martin Fischer

Zitat von: Beta-User am 19 April 2023, 12:41:07
ZitatDa nicht alle 1wire Sensoren in der Bridge, sondern nur die geläufigen, abgefangen werden, werde nicht geparste Familycodes hiermit erfasst und zumindest noch mit dem Prefix OWFS_ versehen.

MAn. fehlt dann aber noch ein Zeichen in der Regex ;) .

Gerne darfst Du mich mit der Nase darauf stupsen. ;) Aber tatsächlich könnte man es noch optimieren, da ein "A-Z" nicht nötig ist, sondern nur "A-F".

ZitatUnd wenn du das mal in einer Testinstallation dann mit der "zweistelligen" bridgeRegexp (mehrmals) versuchen magst, kannst du vielleicht verstehen, warum ich von solchen "Würfeleien" Abstand nehmen würde.

Du, ich bin da leidenschaftslos. Ich kann das auch herausnehmen. Für mich war nachvollziehbar, dass es nur wenig bis keine Kollisionen geben mag. Ich hatte das auf meinem Broker mit ~1200 Topics getestet und es führte zu keinen Komplikationen.

Und da ja die Templates eh manuell nachgearbeitet werden müssen (was aber dank devspec Filter ganz gut auch bulk geht), spielt dass dann auch keine große Rolle mehr. Es würde nur den Kreis der erfassten aber nicht zugewiesenen Devices anhand des Prefixes "OWFS_" sichtbarer machen.

ZitatEs stand da in Anführungsszeichen, weil man sich bekanntlich nicht über Geschmacksfragen zu streiten braucht.

Auch hier: alles gut! Ich sah hier keinen Widerspruch oder eine Provokation. Wie Du schon schriebst: "Die Attribute gehören dem User.". Von daher sollte man m.M.n. die technisch sinnvollen Attribute setzen und alles was zum "Schick, Schick" o.ä. zählt, dem User überlassen. So etwas ist dann ja auch hier dank devspec Filtern etc. schnell manuell erledigt.

ZitatBei allem, was Sensorik ist, tendiere ich dazu, das im "Hauptdevice" zu lassen (also dem, was die bridgeRegexp für diese ID als CID erkennt und an autocreate weitergibt).

Dem stimme ich (zum Teil) zu. Es gibt ja auch Anwendungen, wo z.B. in einem 1wire Counter zwei Geräte "gezählt" werden, die jeweils z.B. unterschiedlichen Räumen zugewiesen werden müssen. Auch hier gibt es nicht immer "den einen Weg", sondern ggf. auch fallweise Abweichungen. Aber auch das gehört hier ja nicht ausdiskutiert, da beide Argumente ja durchaus ihre Berechtigung haben.

Zitat"split" spielt nur da eine Rolle, wo es um mehrere schaltbare Elemente (auf derselben Hardware) geht, vorrangig wegen der Themen SetExtensions und Sprachsteuerung.

Volle Zustimmung.

ZitatWenn du bisher keine MQTT2_DEVICEs hattest, wird vermutlich alles mehr oder weniger gut "nachvollziehbar" sein.

Na ja... wie oben geschrieben, gibt es da schon ein paar Topics die ich verarbeitet. ;) Es sind also "einige" MQTT2_DEVICEs vorhanden. Ich habe u.a. z.B. 10 Fhem Instanzen am Start, die nicht via fhem2fhem. sondern über MQTT zusammenwirken. Auch meine 1wire Anbindung, die bisher Fhem-seitig via OWServer und OWDevice angebunden und via MQTT_GENERIC_BRIDGE publishen, sind dort enthalten.

Doch da meine Instanzen mittlerweile so umfangreich sind, bekomme ich immer mehr Probleme mit dem Timing. Daher will ich das jetzt komplett auslagern.

ZitatDie vorhandenen haben alle ein "split" im Namen, kannst einfach von oben her in "zigbee2mqtt_2channel_split" oder "zigbee2mqtt_2channel_dimmer_split" schauen.

Ich schau mir das mal an. Danke für Deinen Rat und die Hinweise. Gerne mehr ;)
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Beta-User

Stups:

Statt
BASE_TOPIC/([0-9A-F]\x2e\S{12})/.*:.* "OWFS_$1"
z.B.
BASE_TOPIC/([0-9A-F][0-9A-F]\x2e\S{12})/.*:.* "OWFS_$1" oder
 
BASE_TOPIC/([[:xdigit:]]{2}\x2e\S{12})/.*:.* "OWFS_$1"
Have fun!

Was die "Geschmacksfragen" vs. "technisch notwendig" angeht: Nach meinem persönlichen Eindruck war es zumindest bisher ganz ok, auch "Gimmicks" mit auszuliefern, die man "eigentlich" ohne weiteres selbst anflanschen kann, wie z.B. einige Perl-devStateIcons oder (teilweise) userReadings. So haben erst einige (mich eingeschlossen) verstanden, wie die Dinge ineinandergreifen...

(Ansonsten: alles gut :) ).
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