Folgende Frage zu Sonoff/Tasmota und MQTT2_Device

Begonnen von moonsorrox, 13 Dezember 2018, 16:27:05

Vorheriges Thema - Nächstes Thema

noansi

Hallo Rudolf,

ZitatFuer ON/OFF habe ich vor kurzem ein alias (opensvg/iconalias.txt) gesetzt, jetzt folgte in fhemSVG/iconalias.txt fuer set_ON/set_OFF/set_on/set_off mit light_exclamation.svg
da Du schon mal www\images\fhemSVG\iconalias.txt anpackst, es fehlen auch noch:
set_toggle        light_toggle.svg
set_on_for_timer  light_on-for-timer.svg
set_off_for_timer light_off-for-timer.svg
set_dimup         light_dim_up.svg
set_dimdown       light_dim_down.svg

Dann wird auch dazu die passende SVG Grafik angezeigt, z.B. bei HM-devices.

Gruß, Ansgar.

rudolfkoenig


Beta-User

Zitat von: rudolfkoenig am 16 Dezember 2018, 23:30:18
Weiterhin habe ich "toggle" (klick auf dem Status-Icon) auch fuer ON/OFF (d.h. Grossgeschrieben) implementiert. Achtung: ON/OFF wird nur dann im STATE richtig ausgewertet, falls die Befehle auch ON/OFF lauten, sonst wird mir das zu kompliziert.
Fuer ON/OFF habe ich vor kurzem ein alias (opensvg/iconalias.txt) gesetzt, jetzt folgte in fhemSVG/iconalias.txt fuer set_ON/set_OFF/set_on/set_off mit light_exclamation.svg
Ist das evtl. eine unerwünschte Nebenwirkung: https://forum.fhem.de/index.php/topic,94586.0.html
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

noansi

Hallo Rudolf,

ZitatHabe iconalias.txt modifiziert, wie bestellt.

Danke!

Gruß, Ansgar.

Beta-User

So, eben habe ich die vorhin angekündigten templates eingecheckt, nachdem ich die mehrkanaligen zumindest mal auf ein "fake"-Tasmota angewendet habe und die da ohne Probleme durchgelaufen sind.

Ihr meldet euch, wenn was nicht paßt...

Interessieren würde mich vor allem, ob jetzt die Statusmeldungen gleich  da sind (ohne reboot).
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

osr

Zitat von: Beta-User am 17 Dezember 2018, 22:31:07
So, eben habe ich die vorhin angekündigten templates eingecheckt, nachdem ich die mehrkanaligen zumindest mal auf ein "fake"-Tasmota angewendet habe und die da ohne Probleme durchgelaufen sind.
Interessieren würde mich vor allem, ob jetzt die Statusmeldungen gleich  da sind (ohne reboot).

Meinst du den COMMAND/Status ? Der bewirkt nicht das gewünschte. Es ging hier um die INFO1, INFO2, ... die kommen nur nach einem restart.

Deswegen würde das gewünschte Resultat nur ein

COMMAND/restart 1

auslösen. Dann startet ein Tasmota-Gerät neu und sendet alle Parameter.

Bitte füge das pure_base auch wieder hinzu. Das war sehr praktisch um allen Geräten mal den Grundzustand überzubraten. Die komplette Konfiguration will man ja normalerweise nach dem Einrichten eines Gerätes nicht mehr verändern. Der Command/restart wäre da auch ganz praktisch gleich mit dazu.

Ansonsten ersetze sonoff in der Regel durch Tasmota oder bei den template-Namen nur 1ch, 4ch etc. sonoff hat da im Template einfach nichts zu suchen. Von den voreingestellten Tasmota-Geräten  in der Tasmota Firmware ist nur ein kleiner Teil wirklich von Sonoff. POWER etc. ist aber unabhängig davon. Auch z. B. ein Gosun funktioniert mit dem Template und das ist alles andere als ein sonoff-Gerät.

Ansonsten macht sich das so langsam ganz gut.

Das test ist mir etwas zu viel geklicke. Für mich wäre für die mehrkanaligen einfach ein klicken auf das Statusicon zum umschalten ausreichend. Dann bräuchte ich die webcmd gar nicht. Muss mir das die nächsten Tage mal genauer ansehen...

Beta-User

Schade, dass das mit dem COMMAND/status so nicht geklappt hat. Hattest du mal versucht, den Befehl mit einer Zahl dahinter abzusetzen (würde dann am ehesten auf 1 tippen; das geht direkt am Server-Device)?
Zitat von: Beta-User am 17 Dezember 2018, 14:02:15Ganz neu habe ich den Versuch aufgenommen, die Statusinfos abzufragen. Kann sein, dass da noch eine Zahl dahinter Sinn macht (https://github.com/arendst/Sonoff-Tasmota/wiki/Commands#management), Testen wäre nett.
Wie gesagt: ein Reboot finde ich eigentlich nicht optimal da ggf. in manchen Situationen unerwünscht, und es gibt lt. Doku ausdrücklich diverse Informationslevel, die man abrufen kann (ich bin also noch nicht überzeugt, dass es nur mit dem Reboot geht ;) ).

Was genau wünschst du dir für pure_base?
Das "alte" machte ja nur die kurze Reading-Liste, keine Schaltbefehle (hat aber auch nichts gelöscht). Sowas?
Ansonsten war mein Gedanke, dass das "basic" (mit state=POWER) bzw. die Variante mit state=POWER1 eigentlich eine Art Grundzustand sind (also anders gesagt, immer ein Relay zum Schalten da ist, das auch gleich konfiguriert werden kann). Wenn diese Annahme falsch ist, bau' ich ein eigenes temoplate gerne wieder ein, für jetzt habe ich den "basic" erst mal im Namen wieder verkürzt, das irritiert vielleicht sonst. Grundsätzlich wäre sonst meine Denke, dass man die Anzahl der Varianten einigermaßen überschaubar halten sollte. Aber eine Art "cleanup-template" ginge natürlich auch (auch mit deleteattr!).
Aber am Ende geschieht, was ihr euch wünscht, ich will das nur hinterfragt haben, damit nicht morgen einer kommt und behauptet, das pure_basic (oder sonst was) bräuchte man doch eigentlich nicht...

Sonoff kommt raus, das hatte mich auch schon irritiert, Danke für den Stups.

Bezgl. des 4-Kanaligen "test": Das mit dem Klicken ist nachvollziehbar, zumal ich den Zeilenumbruch auch noch falsch gesetzt hatte. Vielleicht würde eine eventMap Sinn machen (mit / als Trenner wären darin auch Leerzeichen möglich). Wenn du eine Idee hast: her damit...

Bin jetzt erst mal unterwegs, und checke eben noch den jetzigen Zwischenstand ein (da ist auch eine Verbesserung für die Milight-Sache drin, auch noch nicht fertig, aber immerhin etwas funktionaler).

Gruß und Danke für die Rückmeldung und das Testen!
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

osr

Zitat von: Beta-User am 18 Dezember 2018, 18:59:24
Schade, dass das mit dem COMMAND/status so nicht geklappt hat. Hattest du mal versucht, den Befehl mit einer Zahl dahinter abzusetzen (würde dann am ehesten auf 1 tippen; das geht direkt am Server-Device)? Wie gesagt: ein Reboot finde ich eigentlich nicht optimal da ggf. in manchen Situationen unerwünscht, und es gibt lt. Doku ausdrücklich diverse Informationslevel, die man abrufen kann (ich bin also noch nicht überzeugt, dass es nur mit dem Reboot geht ;) ).

Ja habe das gerade eben mal mit 1 etc. versucht. Ist aber so dass state wirklich etwas anderes ist.  Find ein Reboot ist da wohl das kleinste übel, sofern keiner was besseres auftreibt.

Zitat von: Beta-User am 18 Dezember 2018, 18:59:24
Was genau wünschst du dir für pure_base?
Das "alte" machte ja nur die kurze Reading-Liste, keine Schaltbefehle (hat aber auch nichts gelöscht). Sowas?

Ja genau. Nur mit autocreate 0 und deleteReading. Habe viele Geräte ohne POWER nur mit Sensoren. Zudem etliche mit Bewegungsmeldern und Temperatursensor. Der Bewegungssensor meldet auch über Power zurück, darf aber natürlich auf keinen Fall geschalten werden. So ein pure base dass man bei Änderungen oder Neuinbetriebnahmen gefahrlos mal über alles machen kann ist schon schön. Hatte das mit pure_base schon mal so gemacht. Also set sonoff.* AttrTemplate pure_base
Ansonsten war mein Gedanke, dass das "basic" (mit state=POWER) bzw. die Variante mit state=POWER1 eigentlich eine Art Grundzustand sind (also anders gesagt, immer ein Relay zum Schalten da ist, das auch gleich konfiguriert werden kann). Wenn diese Annahme falsch ist, bau' ich ein eigenes temoplate gerne wieder ein, für jetzt habe ich den "basic" erst mal im Namen wieder verkürzt, das irritiert vielleicht sonst. Grundsätzlich wäre sonst meine Denke, dass man die Anzahl der Varianten einigermaßen überschaubar halten sollte. Aber eine Art "cleanup-template" ginge natürlich auch (auch mit deleteattr!).
Aber am Ende geschieht, was ihr euch wünscht, ich will das nur hinterfragt haben, damit nicht morgen einer kommt und behauptet, das pure_basic (oder sonst was) bräuchte man doch eigentlich nicht...

Sonoff kommt raus, das hatte mich auch schon irritiert, Danke für den Stups.

Bezgl. des 4-Kanaligen "test": Das mit dem Klicken ist nachvollziehbar, zumal ich den Zeilenumbruch auch noch falsch gesetzt hatte. Vielleicht würde eine eventMap Sinn machen (mit / als Trenner wären darin auch Leerzeichen möglich). Wenn du eine Idee hast: her damit...

Bin jetzt erst mal unterwegs, und checke eben noch den jetzigen Zwischenstand ein (da ist auch eine Verbesserung für die Milight-Sache drin, auch noch nicht fertig, aber immerhin etwas funktionaler).

Gruß und Danke für die Rückmeldung und das Testen!
[/quote]

Beta-User

Hm, ok, Problem halbwegs verstanden, allerdings habe ich den Eindruck, dass der Wunsch v.a. auch daher kommt, dass das mit den Prefixen hier nicht erwünscht ist? Wenn das so wäre, wäre doch eigentlich folgendes zu überlegen:

- Nur Readings löschen, die einen Präfix haben (.*_.*)
- autocreate + die readingList lassen, aber beim Aufräumen so kürzen, dass die Readings ohne Präfix gefüllt werden (die Luxuslösung wäre "autoreate 2" zu setzen - gedacht als Anweisung,  json2nameValue() bei autocreate ohne Präfix zu verwenden; müßte aber (mind. letztendlich) Rudi implementieren).

Es wird also so oder so was kommen. Für den Fall, dass meine Vermutung zutrifft, dass eigentlich die Präfixe hier das Thema sind: Zuarbeit für eine passende Regex, um das ", '[^_]+[_]'" aus der readingList rauszuwerfen, wäre willkommen ;) .

Was Reboot angeht: Habe Hemmungen, das ohne Hinweis in ein template zu packen. Wäre es eine Idee, das als separates template anzulegen, und wenn ja, soll dann gleich noch die Voreinstellung mit den 10 Sekunden timeout auf z.B. 120 Sekunden geändert werden? (weiß grade nicht, welche setOption dass das war, aber die häufigen Pings führen uU. zu Problemen...).

Gruß, Beta-User
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

Beta-User

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

Beta-User

Da war im Ersetzen-Teil ein Fehler drin, ihr wart zu schnell mit dem download, sorry
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

Beta-User

Gibt's schon Rückmeldungen?

Ansonsten wäre es nett, wenn mir jemand eine raw-Definition eines unbearbeiteten Tasmota-Geräts (aus einer halbwegs aktuellen Fassung der MQTT2-Module) hier einstellen könnte. Dann kann ich das zwar nicht schalten, aber immerhin checken, ob die Ergebnisse plausibel sind...

[OT]
Beim Zuschauen bei dieser Diskussion hier: https://forum.fhem.de/index.php/topic,94640.0.html hatte ich den starken Eindruck, dass es für HTTPMOD auch eine klasse Sache wäre, wenn man hier attrTemplate nutzen könnte. Eine template-File hätte ich schon (mit zwei templates für die Preise einer Tankstelle bzw. die Umkreissuche), nur leider fehlt mir eine Idee für einen Patchvorschlag für HTTPMOD).

Wenn mir da jemand einen Tip hätte oder das übernehmen wollte?
[/OT]
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

Zitatleider fehlt mir eine Idee für einen Patchvorschlag für HTTPMOD
Den HTTPMOD Autor ueberzeugen SetExtensions zu verwenden, damit kommt attrTemplate auch mit.
Ansonsten aus SetExtensions abschreiben, im wesentlichen ruft man AttrTemplate_Set auf, wenn man selbst mit dem Befehl nichts anfangen kann.

Beta-User

So,

nachdem keiner gemeckert hatte, sind die templates eingecheckt.

Zitat von: rudolfkoenig am 19 Dezember 2018, 22:01:55
Den HTTPMOD Autor ueberzeugen SetExtensions zu verwenden, damit kommt attrTemplate auch mit.
Ansonsten aus SetExtensions abschreiben, im wesentlichen ruft man AttrTemplate_Set auf, wenn man selbst mit dem Befehl nichts anfangen kann.
Danke für die Rückmeldung, ich habe stefanstrobel mal direkt angeschrieben. HTTPMOD bietet per default keine sets an, das übersteigt damit jedenfalls auf die Schnelle meine Perl-Fähigkeiten, und setExtensions sind m.E. nicht der optimale Weg (da HTTPMOD vermutlich häufig reine Lese-Geräte sind).

Gruß, Beta-User
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

Hallo,

hab mir die Tage vorgenommen auf MQTT2 umzustellen.
Hab das so verstanden das ich erstmal über den MQTT2_CLIENT meine bisherigen MQTT_DEVICE in MQTT2_DEVICE ändere, dann MQTT lösche und durch MQTT2_Server ersetze und schlußendlich in IODev der neuen MQTT2_DEVICE den neuen MQTT2_Server eintrage.

Ist die vorgehensweise so korrekt ?


Mein erstes MQTT2_Device ist ein Sonoff_S20.

Hier ist mir aufgefallen wenn ich attrTemplate ($Id: mqtt2.template 17999 2018-12-18 18:02:57Z Beta-User $) nutze das egal ob mit A_01_tasmota_basic oder A_01a_tasmota_basic_state_power1 definiert immer POWER1 verwendet wird, außer in stateformat. Das tut der Funktion zwar nichts, schalten tut der Basic/Sonoff_S20 ja mit beidem.
In der Beschreibung (attr Template ?) steht allerdings das mit A_01_tasmota_basic POWER verwendet werden soll.

ZitatApplies to Sonoff 1 Channel devices using POWER-topic for relay state

Internals:
   CID        myMQTT2CLIENT
   DEF        myMQTT2CLIENT
   DEVICETOPIC 1st_Sonoffs200
   IODev      myMQTT2_CLIENT
   LASTInputDev myMQTT2_CLIENT
   MSGCNT     126
   NAME       1st_Sonoffs200
   NR         513
   STATE      off
   TYPE       MQTT2_DEVICE
   myMQTT2_CLIENT_MSGCNT 126
   myMQTT2_CLIENT_TIME 2018-12-20 12:27:34
   OLDREADINGS:
   READINGS:
     2018-12-20 12:27:33   POWER           OFF
     2018-12-20 11:59:02   SetOption1      OFF
     2018-12-20 12:27:33   Time            2018-12-20T12:27:33
     2018-12-20 12:27:33   Uptime          1T13:16:13
     2018-12-20 12:27:33   Vcc             3.170
     2018-12-20 12:27:33   Wifi_AP         1
     2018-12-20 12:27:33   Wifi_BSSId      BC:05:43:CA:4F:AC
     2018-12-20 12:27:33   Wifi_Channel    13
     2018-12-20 12:27:33   Wifi_RSSI       100
     2018-12-20 12:27:33   Wifi_SSId       FBF
Attributes:
   IODev      myMQTT2_CLIENT
   autocreate 0
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   model      A_01_tasmota_basic
   readingList tele/sonoffs20/LWT:.* LWT
  tele/sonoffs20/STATE:.* { json2nameValue($EVENT) }
  tele/sonoffs20/SENSOR:.* { json2nameValue($EVENT) }
  tele/sonoffs20/INFO.:.* { json2nameValue($EVENT) }
  stat/sonoffs20/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    off:noArg    cmnd/sonoffs20/POWER1 0
  on:noArg     cmnd/sonoffs20/POWER1 1
  toggle:noArg cmnd/sonoffs20/POWER1 2
  mqttRetry   cmnd/sonoffs20/MqttRetry
   stateFormat {lc ReadingsVal("$name","POWER","") }


Internals:
   CID        myMQTT2CLIENT
   DEF        myMQTT2CLIENT
   DEVICETOPIC 1st_Sonoffs200
   IODev      myMQTT2_CLIENT
   LASTInputDev myMQTT2_CLIENT
   MSGCNT     126
   NAME       1st_Sonoffs200
   NR         513
   STATE     
   TYPE       MQTT2_DEVICE
   myMQTT2_CLIENT_MSGCNT 126
   myMQTT2_CLIENT_TIME 2018-12-20 12:27:34
   OLDREADINGS:
   READINGS:
Attributes:
   IODev      myMQTT2_CLIENT
   autocreate 0
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   model      A_01a_tasmota_basic_state_power1
   readingList tele/sonoffs20/LWT:.* LWT
  tele/sonoffs20/STATE:.* { json2nameValue($EVENT) }
  tele/sonoffs20/SENSOR:.* { json2nameValue($EVENT) }
  tele/sonoffs20/INFO.:.* { json2nameValue($EVENT) }
  stat/sonoffs20/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    off:noArg    cmnd/sonoffs20/POWER1 0
  on:noArg     cmnd/sonoffs20/POWER1 1
  toggle:noArg cmnd/sonoffs20/POWER1 2
  mqttRetry   cmnd/sonoffs20/MqttRetry
   stateFormat {lc ReadingsVal("$name","POWER1","") }


Ist mir nur so aufgefallen bei meinem ersten MQTT2_DEVICE, vielleicht versteh ich es auch bloss falsch.

Gruß

Thomas