SOnOff Tasmota MQTT readings aufbereiten

Begonnen von thestealth, 27 Februar 2020, 20:42:52

Vorheriges Thema - Nächstes Thema

thestealth

Hi,

ich habe hier eine bridge mit Tasmota geflasht aber es scheint mir als sei in der neuesten Tasmota die Übertragenen Daten angepasst worden.

Krieg die Variablen nicht verarbeitet.

Raw Bridge:
defmod RFBridge_1 MQTT_DEVICE
attr RFBridge_1 IODev myBroker
attr RFBridge_1 alias Sonoff
attr RFBridge_1 autoSubscribeReadings 1
attr RFBridge_1 group Bridge
attr RFBridge_1 publishSet /Smarthome/Buero/DVES_bridge/cmnd/RfKey15
attr RFBridge_1 room Bridge
attr RFBridge_1 stateFormat {sprintf("Sync: %.0f Low: %.0f High: %.0f Data %.0f RfKey %.0f", ReadingsVal($name,"Sync:",0), ReadingsVal($name,"Low:",0), ReadingsVal($name,"High:",0), ReadingsVal($name,"Data:",0), ReadingsVal($name,"RfKey:",0))}
attr RFBridge_1 subscribeReading_.* /Smarthome/Buero/DVES_bridge/tele/RESULT
attr RFBridge_1 webCmd on

setstate RFBridge_1 Sync: 0 Low: 0 High: 0 Data 0 RfKey 0
setstate RFBridge_1 2020-02-27 20:33:34 .* {"Time":"2020-02-27T20:33:35","RfReceived":{"Sync":12560,"Low":460,"High":1220,"Data":"F57FEE","RfKey":1}}
setstate RFBridge_1 2020-02-27 20:33:34 transmission-state incoming publish received


Console tasmota:
20:35:44 MQT: /Smarthome/Buero/DVES_bridge/tele/RESULT = {"Time":"2020-02-27T20:35:44","RfReceived":{"Sync":15320,"Low":490,"High":1190,"Data":"F57FEE","RfKey":1}}

expandJSON Raw:

defmod ej3 expandJSON RFBridge_1.*:.*:.{.*}
attr ej3 alias Sonoff Tools
attr ej3 room MQTT

setstate ej3 active
setstate ej3 2020-02-27 20:34:57 state active


irgendwie verstehe ich den Wald vor lauter Bäumen nicht mehr.
Habe seid 6 Jahren Fhem am laufen mit allen mögtlichen Aktoren usw.
aber dieses ach so tolle MQTT mit dem ich bei selbst geflashten ESPs nie Probleme hatte bis es die espeasy bridge gab macht mich bei tasmota verrückt.

Wieso gibts keine ESPeasy Bridge Anbindung sollte doch nicht viel anpassung benötigen und die Struktur ist vorhanden.

Könnte mir jedoch jemand meinen Fehler aufzeigen?

Gruß Dennis

rudolfkoenig

Vielleicht bevorzugt tasmota inzwischen MQTT2_DEVICE :)

thestealth

#2
Hatte ich erst ist aber das gleiche ist ja nur das anlegen von Devices vereinfacht und diebtemplates die es so gibt funktionierten mit der neusten tasmota auch nicht

Da komischerweise immer nur im eventlog die Uhrzeit als Status Änderung kam so reagierten notifys nicht obwohl die readings für Rfkey etc. Aktualisiert wurden jedoch tauchten diese nie im eventlog auf




Update habs nochmal mit MQTT2 getestet geht aber nur über umwege indem ich auf alle änderungen reagiere da ja das data reading auch nicht im eventlog auftaucht wenn es zuvor das gleiche an daten enthielt.

Ist blöd geregelt, wenn ich mehrfach einen pir auslöse möchte ich das er den Countdown fürs ausschalten des Lichtes resetet um so der Problematik mit ausgehendem licht bei längerem Aufenthalt im Flur zu umgehen.

dirk.k

Hallo,
bei mir sieht das etwas anders aus ...
bei "autoSubscribeReadings  fhem/sensors/SonoffTuya_pow_2/#" sorgt der pfad (fhem/sensors/SonoffTuya_pow_2/#) dafür, dass ein neues reading erstellt wird.
Das funktioniert noch nicht so ganz ... das Ergebnei ist: "subscribeReading_   fhem/sensors/SonoffTuya_pow_2/cmnd/Dimmer"
Aber das benenne ich um nach subscribeReading_Dimmer .... und dieses füllt sich dann mit den Daten.

Wenn du also "subscribeReading_.* /Smarthome/Buero/DVES_bridge/tele/RESULT" nach "subscribeReading_RESULT /Smarthome/Buero/DVES_bridge/tele/RESULT" änderst, bekommst du schon mal den JSON-String in das reading RESULT.

Dieses zerlege ich dann mittels userreadings:
Dimmer:RESULT:.* {decode_json(ReadingsVal($NAME,"RESULT",0))->{Dimmer}},
RGB:RESULT:.* {decode_json(ReadingsVal($NAME,"RESULT",0))->{Color}},
Power:SENSOR:.* {decode_json(ReadingsVal($NAME,"SENSOR",0))->{ENERGY}{Power}},

Könnte bei deinem JSON "{"Time":"2020-02-27T20:33:35","RfReceived": {"Sync":12560,"Low":460,"High":1220,"Data":"F57FEE","RfKey":1}}" also folgendermassen aussehen:
Time:RESULT:.*  {decode_json(ReadingsVal($NAME,"RESULT",0))->{Time}},
Data:RESULT:.*  {decode_json(ReadingsVal($NAME,"RESULT",0))->{RfReceived}{Data}},

Damit hebelt man bestimmt ein paar Automatismen aus, aber das Ergebnis ist brauchbar.

thestealth

danke deine erklärung war sehr verständlich nur bin ich nun ja bei mqtt2 da gibts kein autoSubscribeReadings

Das jedoch hat mich veranlast die attr mir mal an zu schauen es war das fehlende


attr MQTT2_DVES_bridge_1 event-on-update-reading .*


ich hatte zuvor nur

attr MQTT2_DVES_bridge_1 event-on-change-reading .*

sag ja zu viele Bäume


Danke euch für die Denkanstöße

FHEM PI

Ich versuche mich gerade mit dem Reading von meinem Stromzähler.

Dieses Reading bekomme ich:
RESULT
{"Time":"2022-02-07T14:32:18","MT175":{"Total_in":648.2,"Power_curr":147.0}}


Die Zeit (Time) wird sauber gelesen
Was mache ich bei der Leistung und dem Zaehlerstand falsch?

defmod Stromzaehler.mqtt MQTT_DEVICE
attr Stromzaehler.mqtt IODev Mosquitto.mqtt
attr Stromzaehler.mqtt room Keller,MQTT
attr Stromzaehler.mqtt subscribeReading_RESULT tele/tasmota_620440/SENSOR
attr Stromzaehler.mqtt userReadings Leistung:RESULT:.* {decode_json(ReadingsVal($NAME,"RESULT",0))->{Power_curr}},\
Zaehlerstand:RESULT:.* {decode_json(ReadingsVal($NAME,"RESULT",0))->{Total_in}},\
Time:RESULT:.* {decode_json(ReadingsVal($NAME,"RESULT",0))->{Time}},

setstate Stromzaehler.mqtt 2022-02-07 14:06:17 IODev Mosquitto.mqtt
setstate Stromzaehler.mqtt 2022-02-07 14:34:18 RESULT {"Time":"2022-02-07T14:34:18","MT175":{"Total_in":648.2,"Power_curr":328.0}}
setstate Stromzaehler.mqtt 2022-02-07 14:34:18 Time 2022-02-07T14:34:18
setstate Stromzaehler.mqtt 2022-02-07 14:34:18 transmission-state incoming publish received

Beta-User

..witzig, dass Neulinge immer noch mit MQTT_DEVICE hantieren...

Du willst doch ein Element haben, das Teil der Unterstruktur "MT175" ist. Darauf solltest du dann schon zeigen... In etwa so:
attr Stromzaehler.mqtt userReadings Leistung:RESULT:.* {decode_json(ReadingsVal($NAME,"RESULT",0))->{MT175}->{Power_curr}},\
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

ZitatWas mache ich [...] falsch?
Auf das nicht aktiv gepflegte und umstaendliche MQTT_DEVICE setzen, statt auf MQTT2_DEVICE.