Status von state OFF vs off trotz EventMap

Begonnen von tklein, 05 Juli 2018, 10:29:33

Vorheriges Thema - Nächstes Thema

tklein

Hallo,

wie aus dem Screen hoffentlich ersichtlich, bekomme ich bei dem Status des states-reading immer nur ON oder OFF. Benötige aber on bzw off. Eventmap habe ich gesetzt. Als Test falls es keine Unterscheidung von Groß bzw Kleinschreibung gibt, habe ich erstmal onon bzw offoff genommen.
Es handelt sich um ein Sonoff CH4 Device mit Tasmota 5.14.0 welches via Mqtt eingebunden ist.

attr Sonoff_4CH_ch1 eventMap ON:onon OFF:offoff

Was muss ich (anders) machen, damit im state nur "on" oder "off" angezeigt wird?

BTW: Das Powerreading funktioniert leider auch nicht.

Das TASMOTA_DEVICE-Modul  von Mattias K. habe ich auch schon ausprobiert, weiss allerdings nicht, wie ich dort die einzelnen Channel schalten kann.

Grüße
Thomas
FHEM auf Pi 3, Echo (Plus, Dot und Connect), CUL868/433, HM Komponenten, Broadlink, Enigma (VU DUO2), Alexa/Homebridge, Sonoffs (POW, RF, Basic), Wemos D1 (IR, DHT, BH1750, OLED, BMP180), IT/Steckdosen, Fritzbox mit SIP, Wifilight, MQTT, Pilight, Xiaomi Flower Sensor, Spotify, Dooya, Shelly, Conbee2

betateilchen

eventMap wirkt sich m.W. nicht auf das reading "state" aus, sondern auf das internal "STATE" (das bei einem event von state abgeleitet wird)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

tklein

mhhmm.

Gibt es da noch eine andere Möglichkeit als überall in den Abfragen ein "lc(state-reading)" oder ".. || $status eq "ON"" zu ändern?
Ein notify etc. welches auf Off hört und dann das Device auf off setzt ist auch nicht so schön wie ich finde.

Gruß
Thomas
FHEM auf Pi 3, Echo (Plus, Dot und Connect), CUL868/433, HM Komponenten, Broadlink, Enigma (VU DUO2), Alexa/Homebridge, Sonoffs (POW, RF, Basic), Wemos D1 (IR, DHT, BH1750, OLED, BMP180), IT/Steckdosen, Fritzbox mit SIP, Wifilight, MQTT, Pilight, Xiaomi Flower Sensor, Spotify, Dooya, Shelly, Conbee2

Pfriemler

#3
Ich bin noch sehr neu in dem Topic (meine ersten Schritte mit einer OBI-Steckdose, Tasmota und MQTT sind erste drei Tage her).
Das folgende funktioniert bei mir einwandfrei
defmod OBIplug1M MQTT_DEVICE
attr OBIplug1M IODev myBroker
attr OBIplug1M devStateIcon aus:general_aus@grey an:general_an@lightgreen timedOn:general_an_fuer_zeit@yellow .*:control_home@darkred
attr OBIplug1M eventMap ON:an OFF:aus
attr OBIplug1M icon message_socket
attr OBIplug1M publishSet ON OFF cmnd/SmartHome/mobile/OBIplug1/POWER
attr OBIplug1M room Neugeräte,Spielwiese
attr OBIplug1M stateFormat {(ReadingsVal($name,"LWT", "") eq "online") ? ReadingsVal($name,"Status", "error") : 'offline'}
attr OBIplug1M subscribeReading_Info tele/SmartHome/mobile/OBIplug1/STATE
attr OBIplug1M subscribeReading_LWT tele/SmartHome/mobile/OBIplug1/LWT
attr OBIplug1M subscribeReading_Status stat/SmartHome/mobile/OBIplug1/POWER
attr OBIplug1M webCmd an:aus


Zu Deinem Code:
1. im publishSet und den subscribes gehören cmnd/, tele/ und /status meines Wissens vor das Topic und nicht mittendrin. Bekommt Du denn übehaupt aktualisierte Readings? Ich vermute, dass der Status von der Befehlsaussendung "klebenbleibt" (on->ON), aber vom Gerät gar keine Rückmeldung über den Vollzug kommt, welche eventMap dann rückübersetzt.
eventMap funktioniert bei Dir offenbar (onon). Zum "ON" im Reading "state" ist es so wie betateilchen sagt.

2. Weil state immer ein sehr spezielles Reading ist, löse ich die Rückmeldung über zwei weitere Readings: _LWT und _Status, und eine userReadingsfunktion. Hier bekomme ich als Rückmeldung dann an, aus oder offline (Zwischenstecker antwortet nicht, etwa weil er herausgezogen wurde). Das dürfte für einen festverbauten Tasmota nicht relevant sein, schadet aber auch nicht. Du brauchst es ja nur teilweise umsetzen.

Jm2c.

edit: Die offline-Meldung des Steckers erfolgt bei mir innerhalb von gefühlt 30 Sekunden, der aktualisierte Status nach dem Einstecken in weniger als 15 Sekunden. Das könnte man sogar prima für eine Stromausfallüberwachung nutzen.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

tklein

Hi Pfriemler,

schalten und die Updates (wenn über Hardwarebutton oder über die Tasmotaoberfläche geschaltet wird) bekomme ich von state. Power leider nicht.
Anbei ein Screen von der Console bzw. Mqtt Infos vom Sonoff. Hatte dort topic und prefix gewechselt.

Grüße
Thomas
FHEM auf Pi 3, Echo (Plus, Dot und Connect), CUL868/433, HM Komponenten, Broadlink, Enigma (VU DUO2), Alexa/Homebridge, Sonoffs (POW, RF, Basic), Wemos D1 (IR, DHT, BH1750, OLED, BMP180), IT/Steckdosen, Fritzbox mit SIP, Wifilight, MQTT, Pilight, Xiaomi Flower Sensor, Spotify, Dooya, Shelly, Conbee2

Pfriemler

Hm... es ist Ansichtssache offenbar: ich finde viele Quellen, bei denen der Prefix inmitten des Topics liegt, aber im Zusammenhang mit dem arendst-Tasmota und emfohlenen Einstellungen eben auch oft den Hinweis, in topic den gesamten Pfad anzugeben und in full topic nur die Anordnung des prefix zu regeln (%prefix%/%topic%). Letztlich hat das aber nur Einfluss darauf wann und wo der Tasmota einen prefix erwartet.
Richtet man also fulltopic als "ebene1/ebene2/%prefix%/%topic%" und als topic nur "geraet" ein, so wird Tasmota selbst Meldungen in dem Stil ebene1/ebene2/stat|tele/geraet/VALUE senden und auf ebene1/ebene2/cmnd/geraet/VALUE reagieren. Ich hätte aber (wie auch bspw. [url)https://github.com/arendst/Sonoff-Tasmota/wiki/MQTT-Overview]in diesem Wiki[/url] beschrieben) vermutet, dass man als topic den gesamten Pfad einträgt (so habe ich das gemacht) und in fulltopic nur die Position von stat|tele|cmnd (als %prefix% festlegt - man kann es also auch ans Ende setzen, wie ich auch verschiedentlich gesehen habe.
Viele Köche ...

Weiterhin sehe ich nirgends, dass ein Topic mit / beginnt. Nicht dass das auch zu Problemen führen kann ...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."