Folgende Frage zu Sonoff/Tasmota und MQTT2_Device

[IngoF]

Hast recht. Mit

Code: [Auswählen]

attr DEVICE setStateList on offpasst das. Status wird immer korrekt angezeigt. Wenn der Sonoff nicht reagiert bleibt das Icon auf Ausrufezeichen. Passt übrigens auch auf den Sonoff Dual.
So ist mein Sonoff jetzt konfiguriert ist.

Code: [Auswählen]

defmod SonoffBasic MQTT2_DEVICE DVES_A8497A
attr SonoffBasic DbLogExclude .*
attr SonoffBasic IODev MQTT2_FHEM_Server
attr SonoffBasic autocreate 0
attr SonoffBasic model A_01a_tasmota_basic_state_power1
attr SonoffBasic readingList tele/sonofftest/LWT:.* LWT\
  tele/sonofftest/STATE:.* { json2nameValue($EVENT) }\
  tele/sonofftest/SENSOR:.* { json2nameValue($EVENT) }\
  tele/sonofftest/INFO.:.* { json2nameValue($EVENT) }\
  stat/sonofftest/RESULT:.* { json2nameValue($EVENT) }
attr SonoffBasic room MQTT2_DEVICE
attr SonoffBasic setList off:noArg    cmnd/sonofftest/POWER1 0\
  on:noArg     cmnd/sonofftest/POWER1 1\
  toggle:noArg cmnd/sonofftest/POWER1 2
attr SonoffBasic setStateList on off
attr SonoffBasic stateFormat POWER1


[tpm88]

Hallo Beta-User,

ich denke, bei Tasmota in der RegEx zur Bestimmung des DEVNAME für die Ersetzung fehlt noch etwas. Das funktioniert für einfache Topics (wie z.B. sonoff oder sonoff_s20_01) nicht aber bei mehrstufigen Topics wie z.B. sonoff/s20/01.

Im Template steht folgende Beschreibung:

Code: [Auswählen]

# The regexp must handle
# - tele/sonoff/LWT: => cmnd/sonoff/
# - DVES_XXXXXX:/SmartHome/Esszimmer/Stehlampe/tele/LWT: => /SmartHome/Esszimmer/Stehlampe/cmnd/

Korrekt müsste die zweite Bedingung bei der Ersetzung für die regexp doch so heißen:

Code: [Auswählen]

DVES_XXXXXX:tele/SmartHome/Esszimmer/Stehlampe/LWT: => cmnd/SmartHome/Esszimmer/Stehlampe
Ich habe das mal mittels https://regex101.com überprüft:

Die regexp im Template

Code: [Auswählen]

m,tele/([^/]*)/, liefert für DEVNAME beim Teststring

Code: [Auswählen]

DVES_375AB5:tele/sonoff/S20/02/LWT auch nur sonoff und nicht sonoff/S20/02 zurück.

Allerdings habe ich (noch) keine Idee, wie die regexp richtig lauten müsste. Oder habe ich generell etwas falsch verstanden??

Gruß
Tobias

[Beta-User]

Hallo Tobias,
Danke für Deine Frage; jetzt ich bin mir auch nicht so richtig sicher, ob die Beschreibung und die Regex jeweils so passen...
Die Beschreibung stammt noch aus der ersten Fassung; da war noch ein

Code: [Auswählen]

par:COMMAND;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\btele(/.*)?/LWT:, ? "${1}cmnd$2" : undef }drin und sowas in der Art:

Code: [Auswählen]

attr DEVICE setList \
off:noArg    COMMAND/POWER1 0\
on:noArg     COMMAND/POWER1 1\
toggle:noArg COMMAND/POWER1 2\
mqttRetry   COMMAND/MqttRetryWürde das auf Deine Pfade soweit passen? Dann müßte ich das wieder herstellen; scheinbar haben bisher alle anderen ihre Pfade nicht angepaßt gehabt...

[tpm88]

Nein, ohne noch einmal den ganzen Thread gelesen zu haben, wurde doch die Berücksichtigung von Tasmota prefixes verworfen.

So komplex muß es also gar nicht sein.

Ganz trivial sollte das für die Aufgabenstellung in der Beschreibung eigentlich auch genügen:

Code: [Auswählen]

m,tele/(.*)/LWT:,
Dann werden sowohl einstufige Topics (z.B. sonoff) als auch mehrstufige (z.B. SmartHome/Esszimmer/Stehlampe) korrekt als DEVNAME zurückgegeben. 

Diese RegEx prüft natürlich nicht die Syntax der Topics, würde aber bei syntaktisch korrekten Ausgangstopics die richtigen Ersetzungen liefern.

[Beta-User]

Hmm,

das mit den Prefixes ist m.E. eine andere Baustelle;

aber dein Vorschlag klingt eigentlich auch ganz einleuchtend, jedenfalls, wenn der Topic-Pfad so statisch ist, wie er zu sein scheint. Muß mal in Ruhe drübersehen .

[IngoF]

Dann müßte ich das wieder herstellen; scheinbar haben bisher alle anderen ihre Pfade nicht angepaßt gehabt...

Ich habe meine Pfade schon angepasst... halt auf die Standardeinstellung von Tasmota (%prefix%/%topic%/). Das ist der default nach "Konfiguration zurücksetzen".
Hatte das bei der Umstellung auf MQTT2 gemacht damit die Templates funktionieren  . Hatte vorher auch meine Geräte mit /smarthome/wohnzimmer/%topic%/%prefix% eingerichtet was ich eigentlich auch logischer fand.

[Beta-User]

Ich habe meine Pfade schon angepasst... halt auf die Standardeinstellung von Tasmota (%prefix%/%topic%/). Das ist der default nach "Konfiguration zurücksetzen".
Hatte das bei der Umstellung auf MQTT2 gemacht damit die Templates funktionieren  . Hatte vorher auch meine Geräte mit /smarthome/wohnzimmer/%topic%/%prefix% eingerichtet was ich eigentlich auch logischer fand.

Na ja, jeder hat da seine eigenen Vorstellungen, kommt halt scheinbar drauf an, auf was man den Schwerpunkt legt.
Auf diese Variante hätte dann wieder die jetzt vorgeschlagene Regex nicht gepaßt, da muß %prefix% demnach vorne bleiben...
Wie dem auch sei, eine Variante, die nicht mit den Defaults kann, wird es jedenfalls nicht, allenfalls eine erweiterte, die sich nicht an "Verlängerungen" stört .
Und wer es unbedingt haben will, muß halt doch händisch nachbessern .

@Rudi:
Kann es eigentlich sein, dass das Eingabefeld nicht funktioniert, das jeweils erscheint, wenn die Regex nicht hinhaut? Ich hatte das neulich mal, den Effekt dann aber bis grade verdrängt....

Und noch was: Wegen des homekit-Themas von nebenan: Es könnte durchaus Sinn machen, sowas wie einen postProcessingHint für ergänzende Konfigurationsoptionen da reinzubauen. Dann hätte man all sowas "an einem Ort", ohne dass die entsprechenden Module jeweils geladen sein müßten.
Der "Hit" wären An- und Abwähl-Optionen...

[rudolfkoenig]

Kann es eigentlich sein, dass das Eingabefeld nicht funktioniert, das jeweils erscheint, wenn die Regex nicht hinhaut?

Es kann alles sein, ich brauche aber Beispiele.
Es gibt kein Dialog, wenn alle Parameter gesetzt sind. Ob Inhalt des Parameters im Sinne des Erfinders ist,wird aber nicht geprueft.

Wegen des homekit-Themas von nebenan

Wenn ich damit gemeint bin: da brauche ich deutlich mehr Kontext.

[Beta-User]

Es kann alles sein, ich brauche aber Beispiele.
Es gibt kein Dialog, wenn alle Parameter gesetzt sind. Ob Inhalt des Parameters im Sinne des Erfinders ist,wird aber nicht geprueft.

Korrekt, aber wenn irgendwas schief läuft, also ein Parameter - aus welchen Gründen auch immer - nicht automatisch bestimmt werden kann, kommt ein Dialogfeld. In das kann man zwar was eintragen, aber ganz egal, was man da eingibt, es hat keine Auswirkungen.

Beispiel: Man manipuliere die readingList eines tasmota, z.B. so (tulu statt tele):

Code: [Auswählen]

defmod tasmota_test3 MQTT2_DEVICE DVES_9B01BD
attr tasmota_test3 IODev MQTT2_FHEM_Server
attr tasmota_test3 readingList DVES_9B01BD:tulu/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tulu/sonoffkitchen/INFO:.* { json2nameValue($EVENT) }
attr tasmota_test3 room MQTT2_DEVICE
und versuche dann, darauf eines der Tasmota-templates anzuwenden.
Ergebnis: Es passiert nichts, selbst wenn man da "das richtige" (sonoffkitchen) oder irgendwas anderes einträgt.

Erwartung wäre: der eingegebene Text ersetzt den Parameter.

Wenn ich damit gemeint bin: da brauche ich deutlich mehr Kontext.

Ok, es geht um die Thematik, die hier und in den paar Beiträgen davor angerissen wird:
Nutzt jemand z.B. homekit, macht es Sinn, gleich die passende Parametrierung vorzunehmen (siriName, genericDeviceType, und eigentlich muß das Gerät dann noch in den Raum Homekit). Entsprechendes gilt für AutoShuttersControl, vermutlich auch andere Sprachsteuerungen etc...
Mal sind es mehrere Attribute, die gesetzt werden müssen (mit sinnvollem individuellem Inhalt, z.B. für siriName), mal ist es nur ein klar definiertes Attribut (ASC). Allen ist gemeinsam: sie können nur gesetzt werden, wenn das betr. Modul überhaupt geladen ist (könnte man ggf, auch prüfen, aber irgendwann ist auch gut...)

Vielleicht wird es klarer mit folgendem Fantasie-template:

Code: [Auswählen]

# shelly2 using original firmware in roller mode.
name:A_11b_shelly2_roller
filter:TYPE=MQTT2_DEVICE
desc:shelly2 using original firmware. <br>NOTE: shelly2 roller operated, change settings first!
par:DEVNAME;Shelly2 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE comment shelly2 roller operated
attr DEVICE setList \
  open:noArg shellies/DEVNAME/roller/0/command open\
  close:noArg shellies/DEVNAME/roller/0/command close\
  stop:noArg shellies/DEVNAME/roller/0/command stop\
  pct:slider,0,1,100 shellies/DEVNAME/roller/0/command/pos $EVTPART1\
  DoRecalibration:noArg shellies/DEVNAME/roller/0/command rc
attr DEVICE readingList shellies/DEVNAME/roller/0/pos:.* pct\
  shellies/DEVNAME/status/0/rollers:.* power\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/roller/0:.* state\
  shellies/DEVNAME/input/1:.* input1\
  shellies/DEVNAME/input/0:.* input0
attr DEVICE devStateIcon 0:fts_shutter_100 100:fts_shutter_10 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100 set_.*:fts_shutter_updown
attr DEVICE stateFormat pct
deleteReading DEVICE .*
attr DEVICE setStateList open close stop

option01:SIRINAME;When using homekit enter desired siriname and click OK, otherwise CANCEL;
attr DEVICE siriName SIRINAME
attr DEVICE genericDeviceType blind
par:ROOM_ATTRIBUTE;Extend room attribute with Homekit;{ my $rooms = AttrVal("DEVICE","room","none"); $rooms =~ m,none, ? "Homekit" : $rooms =~ m,Homekit, ? $rooms : $rooms.",Homekit" }
attr DEVICE room ROOM_ATTRIBUTE
option01end

option02:;Set AutoShuttersControl attribute?
attr DEVICE ASC 2
option02end

finalhint:Thank you for using mqtt2Template. Now have fun using your device and don't forget to save changes.

attr DEVICE model A_11b_shelly2_rollerDas könnte man entweder Option für Option durchgehen, oder einmal ein Dialogfeld anzeigen, das für jede Optionsgruppe ein "Kreuzchenfeld" vorneweg hat, das das jeweils aktiviert. (Ich habe aber keine Ahnung, wie man das mit erforderlichem Userinput machen würde; hier ggf. nachgelagerte Abfragen...?).

Aber das ist der totale Luxus, über den wir hier sprechen...

[IngoF]

Mir ist da noch was aufgefallen. Durch

Code: [Auswählen]

attr DEVICE setStateList on offseht ja im  Reading state "set_on" oder halt "set_off". Das kommt dann auch so bei der Homebridge an wie man im Log sieht. Die kann damit nichts anfangen und man sieht auf dem IPhone leider nicht den aktuellen Status des Geräts. Auch direktes schalten bekommt man so leider nicht mit. Ist es den möglich das Reading state mit dem vom Gerät gemeldeten Status zu befüllen (POWER1)? StateFormat hilft hier ja nicht weiter .

[Beta-User]

Hmmm, eigentlich sollte das nur so lange so sein, bis auch Vollzug vom Gerät zurückgemeldet wird....
Ist also eigentlich nicht schlecht, wenn das sichtbar ist. Wenn du das Ausschalten wolltest, schreibe mal testweise Unsinn rein (reboot oder so).

[IngoF]

wenn ich bei setStateList irgendwas reinschreibe bekomme ich zwei neue Readings wenn ich mit FHEM schalte.

Code: [Auswählen]

setstate SonoffBasic 2019-01-16 21:51:26 off set
setstate SonoffBasic 2019-01-16 21:51:27 on set
setstate SonoffBasic 2019-01-16 21:50:53 state set_on

[Beta-User]

Hmmm,

bei intensiverem Nachdenken scheint es so zu sein, dass sich Homekit da direkt state greift und nicht irgendwas, was danach passiert. Als Spielmaterial kommt m.E. noch ein userReadings in Frage:

Code: [Auswählen]

attr DEVICE userReadings state:POWER1:.* { lc(ReadingsVal($name,"POWER1","")) }
(lc ist vermutlich nicht mehr erforderlich; insgesamt gefällt mir das gar nicht im template, userReadings sollte man m.E. wirklich vollständig in User-Hand lassen)

[tpm88]

Die Beschreibung stammt noch aus der ersten Fassung; da war noch ein

Code: [Auswählen]

par:COMMAND;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\btele(/.*)?/LWT:, ? "${1}cmnd$2" : undef }drin und sowas in der Art:
...

Hallo Beta-User,

nachdem ich https://github.com/arendst/Sonoff-Tasmota/wiki/MQTT-Features noch einmal gründlich durchgesehen habe, ziehe ich meinen Vorschlag aus #168 zurück. Mehrstufige Topics werden also nicht via %topic% sondern mit Hilfe von FullTopic gebildet. Da man dort komplett frei ist bei der Bildung der Topics, sehe ich überhaupt keine sinnvolle Möglichkeit, das im Attribut Template vernünftig abzubilden. Das sind ja auch nur _Beispiele_ für mehrstufige Topics:

Zitat: Using the tokens the following example topics can be made:

Code: [Auswählen]

    FullTopic %prefix%/%topic%/ being the legacy situation up to version 5.0.5
    FullTopic tasmota/%topic%/%prefix%/
    FullTopic tasmota/bedroom/%topic%/%prefix%/
    FullTopic penthouse/bedroom1/bathroom2/%topic%/%prefix%/

Insbesondere kann %prefix% am Ende stehen, muß aber nicht...

Insofern denke ich, sollte das Template nur den Auslieferungszustand von Tasmota mit einem einfachen einstufigen Topic %topic% abbilden.

Gruß
Tobias

[rudolfkoenig]

Insbesondere kann %prefix% am Ende stehen, muß aber nicht...

In diese Falle bin ich auch am Anfang geraten, und ich habe mal ein Regexp gebaut, was beide Faelle abgedeckt hat (irgendwo hier im Forum dokumentiert). Allerdings bin ich nicht sicher, dass es _alle_ Faelle abdeckt, und bin dafuer, keine Zeit und Energie fuer Sonderloesungen zu vergeuden, und nur die Tasmota Voreinstellung zu unterstuetzen. Hoffentlich kommen die nicht auf die Idee, daran was zu drehen.