Hallo alle!
Es tut mir leid, das ist ziemlich sicher total trivial, aber ich schaffe es nicht den state eines Dummy Devices (Temperatur Dummy) über MQTT2 zu publishen. Die ganzen Beispiele in der wiki beziehen sich auch komplexe Devices oder auf MQTT(1) Devices (mqttPublish). Aber ich kann einfach nicht verstehen wie ich ein Reading eines ganz einfachen Dummys publishen kann?
Freue mich über Hilfestellung, stehe grad total an.
LG,
Matthias
1. Bitte beachte die angepinnten Beiträge. Hier sehe ich insbesondere keine list.
2. Für MQTT-Themen gibt es im MQTT-Bereich einen weiteren gepinnten Thread, der das für die dafür spezifischen Themen ergänzt (ist hier aber sogar einigermaßen beantwortet).
3. Man KANN so eine Problemstellung auch mit dummy+MQTT_GENERIC_BRIDGE lösen, ich vermute allerdings, dass es dir leichter fallen würde, schlicht und ergreifend ein MQTT2_DEVICE zu bauen.
4. "Temperatur-Dummy" klingt für mich wie "Infos unnötig umpacken", was im Klartext sowas heißt wie: "von hinten durch die Brust ins Auge"... "Eigentlich" reicht es vermutlich, die Attribute für MQTT_GENERIC_BRIDGE v.a. am "Datenlieferanten" passend zu setzen und "der Fisch ist geputzt" ;) . Ganz ohne weiteren dummy (samt Eventhandler, der den befüllt) oder MQTT2_DEVICE.
es gibt einen eigenen Thread für solche Anwendungen mit etlichen Beispielen ... geprüft?
https://forum.fhem.de/index.php?topic=91642.0
Ansonsten, du willst aus einem dummy mit MQTT_GENERIC_BRIDGE publishen? Hast du das Attribut "mqttForward
all" gesetzt? Ansonsten published ein dummy-Device nicht.
Für mehr Input erstmal list deiner Devices
Danke euch beiden!
Ja List hab ich entgegen besserem Wissen nicht reingepackt weil ihr wohl kaum einen Informationsgewinn von meinen scheußlichen Dummys habt und ich ja nicht an der Semantik sondern an der Konzeption scheitere.
Die Dummys sind von hinten durch die Brust ins Auge, das liegt auch daran dass das alles ein seit Jahren gewachsener Flickenteppich aus KNX, LaCrosse und EmonHub ist und jetzt von MQTT auf MQTT2 umgestellt werden musste. Die Dummys sind hier mein Datenlieferant der Wahl weil zwischendrin teilweise Berechnungen laufen von denen ich von den Dummys letztlich die Werte auf dem Silbertablett präsentiert bekomme. Aber es geht sicher auch anders.
Der Link von Dir kadettilac bezieht sich primär auf MQTT und nicht auf MQTT2 - will sagen mqttpublish zB wibt es ja in meiner Situation nicht, zumindest habe ich es nicht gefunden. Das muss irgendwie mit setList gepublished werden wenn ich das richtig verstanden habe, aber ich hab nicht gecheckt wie die Syntax da ist.
Das wäre das Listing für den Datenlieferanten:
Internals:
DEF 03
FUUID 5d4fdfae-f33f-db1a-6cc0-eba3c90d469c0e9f
IODev myJeeLink
LASTInputDev myJeeLink
LaCrosse_lastRcv 2021-01-02 09:58:37
MSGCNT 7912
NAME Esszimmer
NR 232
STATE 21.7 °C / 36%
TYPE LaCrosse
addr 03
battery_new 0
corr1 0
corr2 0
myJeeLink_MSGCNT 7912
myJeeLink_RAWMSG OK 9 3 1 4 193 36
myJeeLink_TIME 2021-01-02 09:58:37
previousH 36
previousT 21.7
sensorType 0=T(H)
Helper:
DBLOG:
D:
DBLogging:
TIME 1609577917.0189
VALUE 6
absFeuchte:
DBLogging:
TIME 1609577917.0189
VALUE 7
battery:
DBLogging:
TIME 1609577917.0189
VALUE ok
dewpoint:
DBLogging:
TIME 1609577917.0189
VALUE 6
humidity:
DBLogging:
TIME 1609577917.0189
VALUE 36
state:
DBLogging:
TIME 1609577917.0189
VALUE T: 21.7 H: 36
temperature:
DBLogging:
TIME 1609577917.0189
VALUE 21.7
READINGS:
2021-01-02 09:58:37 D 6
2021-01-02 09:58:37 absFeuchte 7
2021-01-02 09:58:37 battery ok
2021-01-02 09:58:37 dewpoint 6
2021-01-02 09:58:37 humidity 36
2021-01-02 09:58:37 state T: 21.7 H: 36
2021-01-02 09:58:37 temperature 21.7
Attributes:
IODev myJeeLink
alias Esszimmer
group Klima
room Homekit,Klima,Küche-Esszimmer,Wohnzimmer
stateFormat {sprintf("%.1f °C / %d%%",ReadingsVal("$name","temperature",0),ReadingsVal("$name","humidity",0))}
Ich hätte gedacht ich kann vielleicht mit einem notify in ein MQTT2_Device schreiben
defmod LaCrosseToMQTT_Innentemp notify Esszimmer:temperature:.* setreading Innentemp_MQTT temperature $EVTPART1
Und dann aus dem MQTT2 Device publishen. Dafür wäre wohl ReadingList gedacht
Internals:
CFGFN
DEVICETOPIC Innentemp_MQTT
FUUID 5fef88d2-f33f-db1a-65c3-5cb51e0e3c45765a
IODev Mosquitto2
NAME Innentemp_MQTT
NR 2268
STATE ???
TYPE MQTT2_DEVICE
Helper:
DBLOG:
attrTemplateVersion:
DBLogging:
TIME 1609534100.10682
VALUE 20201208
temperature:
DBLogging:
TIME 1609577289.4289
VALUE 21.7
OLDREADINGS:
READINGS:
2021-01-01 21:48:20 attrTemplateVersion 20201208
2021-01-02 09:48:09 temperature 21.7
Attributes:
IODev Mosquitto2
autocreate 1
bridgeRegexp (tele|stat|shellies|valetudo|Advantech)/([^/]+)/.*:.* "$2"
zigbee2mqtt/bridge/.*:.* "zigbee2mqtt"
sonos/connected.* "sonos"
tvheadend/[^/:]+.* "tvheadend"
milight/LWT:.* "milight"
(ESPClient_[^/]+)/.*:.* "$1"
(ebusd[^/]*)/global/.*:.* "$1"
[^/]+/(ems-esp[^/]+)/start:.* "$1"
(mygateway[\d]+)-(in|out)/.* "$1"
(wallpanel|wled)/([^/]+)/.*:.* "$1_$2"
go-eCharger/([^/]+)/.*:.* "go_eCharger_$1"
owntracks/[^/]+/([^/:]+).* "owntracks_$1"
home/(O[^/]*M[^/]*G[^/]*)/LWT:.* "$1"
homeassistant/.*/config:.* ""
comment Do not use very open bridgeRegexp expressions! This might lead to irritating results... Especially make sure to not have two regexpes that may both match!
icon mqtt_bridge_2
model MQTT2_CLIENT_general_bridge
readingList Innentemp_MQTT/temperature:.* { json2nameValue($EVENT) }
Das ist offensichtlich falsch, aber ich weiß auch nicht wies richtig geht
Au...
Also bitte lass die MQTT2_CLIENT_general_bridge "in Ruhe". So ein Device sollte es einmal geben und man sollte keine anderen Aufgaben dahin verschieben.
Das ist dann nur für bridgeRegexp und ignoreRegexp zuständig (auch letzteres ist m.E. zwingend, wenn man mit externem Broker arbeitet).
Aber erst mal zu deinem Problem:
- Man kann auch MQTT_GENERIC_BRIDGE mit MQTT2_CLIENT (oder .*-SERVER) betreiben, das wäre also nicht das Thema, und da z.B. der Lacrosse auch unverändert rausgeht, wäre das hier m.E. das Mittel der Wahl.
Für die "berechneten Werte" mag es ok sein, die in einen dummy zu schreiben, ich würde das eher über (ordentlich getriggerten!) userReadings-Code direkt an der Quelle regeln. Trotzdem auch dazu die "Lösung".
- Was gepublisht werden soll, gehört bei einem MQTT2_DEVICE in die setList. Gleich das ganze mit widget (kann man aber ändern):
attr <m2_device> setList temperature:slider,5.0,0.5,30.0,1 Innentemp_MQTT/temperature $EVTPART1
Dann aber nicht mit "setreading" im notify arbeiten, sondern mit "set".
Ups sorry ok, das hab ich also gelöscht.
Also schaut es jetzt dann so aus:
Internals:
CFGFN
DEF
DEVICETOPIC Innentemp_MQTT
FUUID 5fef88d2-f33f-db1a-65c3-5cb51e0e3c45765a
IODev Mosquitto2
NAME Innentemp_MQTT
NR 2268
STATE temperature
TYPE MQTT2_DEVICE
Helper:
DBLOG:
attrTemplateVersion:
DBLogging:
TIME 1609534100.10682
VALUE 20201208
state:
DBLogging:
TIME 1609581228.31293
VALUE temperature
temperature:
DBLogging:
TIME 1609580597.35444
VALUE 21.8
OLDREADINGS:
READINGS:
2021-01-02 10:53:48 state temperature
2021-01-02 10:43:17 temperature 21.8
Attributes:
IODev Mosquitto2
autocreate 0
icon mqtt_bridge_2
setList temperature:slider,5.0,0.5,30.0,1 Innentemp_MQTT/temperature $EVTPART1
Korrekt? Funktioniert! :-) Danke!
Aber warum set und nicht setreading?