mqtt2.template: bugs, Fragen, Anregungen

Begonnen von Beta-User, 15 Dezember 2018, 11:44:43

Vorheriges Thema - Nächstes Thema

flummy1978

Hallo Beta-User & Hallo alle anderen,

ich hab mal ne Anregung zu den Templates generell....

Ich weiß nicht wie es andere halten, aber ich versuche das Gespamme in meinen Logs (bzw Event Monitor- weil ich mit diesem sehr viel arbeite) im Griff zu halten und auch beim Erstellen neuer Devices auf möglichst notwendige Events zu reduzieren. Selbst wenn man ALLE Änderungen als Event haben möchte, so wäre es doch sinnvoll ein
attr event-on-change-reading .*
für alle Geräte pauschal mit aufzunehmen oder ?

Diejenigen die darauf achten, welche Readings sie in einem ein Event brauchen, passen es eh noch an und alle anderen werden zumindst nicht mit Updates zugespammt oder "verpassen" Änderungen, weil es aus irgendeinem Grund vorher kein Event ausgelöst hat.....

Just my 2cent - Idee .... wenn Blödsinn, wäre ich für den Grund dankbar (kann ja nur was davon lernen), dann kann man es schnell wieder vergessen ;)

Grüße
Andreas

rudolfkoenig

Zitatso wäre es doch sinnvoll ein "attr event-on-change-reading .*" für alle Geräte pauschal mit aufzunehmen oder ?
Meiner Ansicht nach nicht, sonst waere das die Voreinstellung.
Nachteile:
- man weiss nicht, ob ein Geraet noch lebt
- man muss in den Plots Fantasiewerte einbauen
- in der Kombination mit anderen event-* Attributen bekommt man nicht das, was man denkt

Ich wuerde die Daten in der Quelle auf einen "normalen" Mass beschraenken (Meldung alle 1-5 Minuten), und meine Finger von jeglichen event-* Attributen lassen.

Beta-User

Hallo zusammen,

im svn ist wieder eine aktualisierte Version, eingeflossen sind:

- neues template für McLightning (https://forum.fhem.de/index.php/topic,109946.0.html, thx an Andi89);

- Änderungen bei OpenMQTTGateway:
-- "Erster" bei periodicCmd für ein attrTemplate...
-- (Hoffentlich funktionierende) Erweiterung für "non-JSON" sendende Builds

Mein Server hat in dem Zusammenhang eine ignoreRegexp erhalten:
attr MQTT2_FHEM_Server ignoreRegexp homeassistant/.*/config:.*Damit werden "discovery"-Meldungen, die für HomeAssistant gedacht sind, direkt verworfen (hoffentlich jedenfalls). Eigentlich wäre das ein separates template wert (bzw. evtl. mehrere), vielleicht mag jemand den Gedanken aufgreifen, und z.B. ein template bauen, mit dem man aus einem Tasmota-Device heraus den installations-spezifischen "cmnd-Pfad" ermitteln kann, schauen, ob der schon in ignoreRegexp des IO's steht und diese ggf. dort ERWEITERN (und auf das IO wechseln)?

- dimup/down bei shellydimmer geändert (ich hoffe, das was sich um https://forum.fhem.de/index.php/topic,94060.msg1040699.html#msg1040699 herum findet zutreffend interpretiert zu haben? Die "7" verstehe ich allerdings nicht, wäre ohne testen auf 5 oder 9 gekommen.)

Zu dem event-on-... Thema:
Rudi hat recht, flummy1987 kann ich mit dem Anliegen aber auch sehr gut verstehen... Rudi und ich hatten im Prinzip dieselbe Diskussion vor wenigen Wochen schon mal. Für reine "on/off(/dimm)"-Devices (mit dem flummy1987 sich zuletzt intensiv beschäftigt hatte, s.o.),  ist es gefühlt einfach nur "falsch", dass der  shellyständig "bin noch an" (usw.) zu melden scheint (irgendwo gab's dazu eine Diskussion, bei der afaik auch Otto123 beteiligt war; es könnte einen Einstellung in der shelly-firmware geben, mit der man das ausschalten kann). Für tasmota müßten wir das jetzt durch die ganzen jsonMap-Geschichten indirekt im Griff haben, bei shelly hat sich dagegen noch keiner damit beschäftigt...

Rudi's Punkt ist der: Sobald es nicht um on/off/Dimmwert oä geht, die statisch sind, solange niemand sie ändert, sondern z.B. um Temperaturwerte, will man typischerweise eben auch den unveränderten Meßwert haben. (Für die Frage, ob das Device noch lebt, paßt die Argumentation mMn. bei MQTT _meistens_ nicht, jedenfalls, wenn es ein "ordentlich programmiertes" Gerät ist, das "Last Will" (z.B. LWT@Tasmota) so nutzt, wie es gedacht ist. Machen aber auch nicht immer alle...)

Für den McLighting habe ich das btw. auch mit .* übernommen wie vorgeschlagen, da ich davon ausgehe, dass das Teil eher in die "statische Ecke" paßt. Allerdings enthält dessen readingList nichts, das auf den ersten Blick wie ein LWT-Pfad aussieht.

Nu ja, einen Schritt nach dem anderen...
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

joelinux

Zitat von: Beta-User am 11 April 2020, 06:54:44

- dimup/down bei shellydimmer geändert (ich hoffe, das was sich um https://forum.fhem.de/index.php/topic,94060.msg1040699.html#msg1040699 herum findet zutreffend interpretiert zu haben? Die "7" verstehe ich allerdings nicht, wäre ohne testen auf 5 oder 9 gekommen.)

In meinen Versuchen die shellydimmer dimup und dimdown Logik nach Tasmota zu überführen ist mir aufgefallen das die Multiplikation mit 10 in den Zeilen 1986 und 1987 fehlt.

  dimup:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+4)/10)*10+10; return qq {shellies/DEVNAME/light/0/set {"turn": "on", "brightness": $num}}; }\
  dimdown:noArg my $num=int((ReadingsNum($NAME,'pct',0)+7)/10)*10-10; return qq {shellies/DEVNAME/light/0/set {"turn": "on", "brightness": $num}}; }\


[workinprogress]
Für ein Tasmota Gerät mit jsonmap Dimmer:pct Reading habe ich bisher


dimup:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+4)/10)*10+10; return qq {cmnd/Tasmota-LSC-Filament-2/Dimmer $num}; }
dimdown:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+7)/10)*10-10; return qq {cmnd/Tasmota-LSC-Filament-2/Dimmer $num}; }


in einem Tasmota Template kann daraus


  dimup:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+4)/10)*10+10; return qq {CMNDTOPIC/Dimmer $num}; }\
  dimdown:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+7)/10)*10-10; return qq {CMNDTOPIC/Dimmer $num}; }\


werden.

[/workinprogress]

Mit freundlichem Gruß

joelinux
FHem on RPi2 Buster, Duofern Rollladen, ZWave Rolllade + Steckdosen, ZigBee (Philips, Tradfri), Tasmota (diverse Steckdosen, GU10 und E14 LSC Leds von Action, Sonoff RF Bridge), InterTechno Dimmer Steckdose ITLR-200

Pacman111178

Hallo Fhem User und Programmierer .
Ich bin ein totaler Anfänger, stelle gerade von Mqtt ( Moskito) auf Mqtt2Fhem_Server  um . Funktioniert sogar Prima . Aber wenn Ich das Template vom Sonoff Pow für einen Sonoff Pow lade , stürzt die Fhem ab !
Habe sie eigentlich auf nem Zero laufen habe aber zum testen gerade einen Pi3B+ dran .. aber das gleiche Problem .
Ich denke nicht das meine Frage um Hilfe hier richtig ist aber Ich komme hier im Forum nicht ganz klar!

LG Boris

Gesendet von meinem SM-G960F mit Tapatalk


87insane

Steht etwas im LOG?
Wie genau meinst du das "es stürzt ab".?
Welche Meldung(en) erhält du?
Ist fhem nach ca 20 Sekunden wieder an und siehst du das Gerät dann noch?



Gesendet von meinem LM-G810 mit Tapatalk


Pacman111178

Hallo Danke für die schnelle Antwort!
"Connection Lost try in 5 Seconds " kommt von der Fhem nachdem Ich Set gedrückt habe !
Habe gerade das Template vom basic_state_power1 reingelade ohne Probleme.. habe gesehen das das wohl das Grund template vom Pow ist !
Aber alle Features vom Pow habe Ich wohl nicht ! Was kann Ich denn noch probieren wo kann Ich dir den log zeigen ?

Gesendet von meinem SM-G960F mit Tapatalk


87insane

Im Menü links steht Logfile. Da steht ggf genau zur Absturz Zeit etwas drin warum das so ist.

Hinzu würde ich grundsätzlich mal ein update machen. Vom lesen her ist das für mich ein Wunder das du fhem am laufen hast. Bitte nimm mir den Kommentar nicht böse.

Gesendet von meinem LM-G810 mit Tapatalk


Pacman111178

Nein Kein Problem [emoji1]
Ich habe das vorher mit einem Kumpel gemacht , mittlerweile kämpfe Ich mich alleine weiter .. hab ne Awtrix alleine eingebunden und dadurch kam auch die Umstellung auf Mqtt2 ! Funktioniert ja auch super bei den Sonoff Basic , Sonoff SV  und einen  H801RGBW Controller  aber den kann Alexa leider nur Ein/ Aus und Dimmen schalten! Keine Farben .

Ich werde jetzt mal den Pow  komplett löschen und ihn wieder finden lassen von der Fhem dann werde Ich das Template versuchen zu laden und danach gucke Ich in den log !
Vielen Dank für deine Gedult !

Gesendet von meinem SM-G960F mit Tapatalk


Pacman111178

PS : Fhem und Pow hatte Ich vorher upgedatet !

Gesendet von meinem SM-G960F mit Tapatalk


87insane

Löschen und neu anlegen hört sich gut an. Sind ja nur 10 Sekunden.



Gesendet von meinem LM-G810 mit Tapatalk


Pacman111178

So , Ich hoffe das hilft ...(https://uploads.tapatalk-cdn.com/20200412/443012406db974fd432a379d70db2582.jpg)

Gesendet von meinem SM-G960F mit Tapatalk


87insane

Leider bringt das nix.

Hast du dir den Artikel durchgelesen wie das mit mqtt2 funktioniert?
Hinzu empfehle ich dir mal so ein fhem guide durch zu lesen. Ich bin mir aktuell nicht mal sicher ob du fhem überhaupt über einen Browser öffnest.

Wir brauchen hier grundsätzlich immer ein list vom betroffenen Gerät. Hinzu alle Infos die wichtig sein könnten. Dazu zählen hier zb log Einträge oder der genaue Fehler usw. Leider scheinen wir das aber nicht hin zu bekommen. Also du muss unbedingt ein wenig lesen. Ich glaube das dir da so einige Dinge auffallen wo du dich freuen wirst das gelesen zu haben.

Danach bitte ein list vom neuen Gerät am besten vor Auswahl des templates und ein list danach...
Und bitte in die logdatei gucken. Wenn es geht bitte ein Bild was nicht aus der putty Konsole kommt.

Gesendet von meinem LM-G810 mit Tapatalk


Beta-User

Zitat von: joelinux am 12 April 2020, 08:14:24
[workinprogress]
in einem Tasmota Template kann daraus

  dimup:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+4)/10)*10+10; return qq {CMNDTOPIC/Dimmer $num}; }\
  dimdown:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+7)/10)*10-10; return qq {CMNDTOPIC/Dimmer $num}; }\

werden.
[/workinprogress]

Thx. für den Hinweis, hab's korrigiert bzw. aufgenommen...

(Noch ein Argument, das modularer aufzubauen, aber im Moment komme ich da nicht voran... => feel free, Vorschläge zu machen ;) ).



Zitat von: Pacman111178 am 12 April 2020, 12:01:29
So , Ich hoffe das hilft ...(https://uploads.tapatalk-cdn.com/20200412/443012406db974fd432a379d70db2582.jpg)

Gesendet von meinem SM-G960F mit Tapatalk
Wie schon geschrieben: Screenshots sind Sch... (falls das eine Linux-Konsole ist, aus der du was rauskopieren willst: Strg+Umschalt+c geht, wenn man mit der Maus markiert hat).

Der screenshot sieht so aus, als würde die attrTemplate-Anweisung aus einem "alten" Fenster ausgeführt werden => browser vorher refreshen, wenn FHEM oben ist.
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

joelinux

Zitat von: Pacman111178 am 12 April 2020, 10:41:30
Ich denke nicht das meine Frage um Hilfe hier richtig ist aber Ich komme hier im Forum nicht ganz klar!

LG Boris

Hallo Boris,

dein Gefühl, das deine Anfrage hier nicht 'richtig' ist trifft zu. Ebenso kann die Menge an Informationen im Forum einen schier erschlagen (zumindest geht es mir so).

Deine Anfrage kann gerne als neuer Gesprächsfaden im Bereich Anfängerfragen von dir eröffnet werden.
Dort kannst du auch Hilfestellung bei einer Erstellung einer detaillierten Problembeschreibung erhalten.

Im übrigen wundert es mich nicht das du FHEM zum Laufen gebracht hast.
FHEM zeigt damit eine seiner Stärken. Nach moderatem Studium von CommandRef, Wiki und Co. ist es möglich mit berechtigter Freude ein funktionsfähiges Hausautomations Projekt zu führen. Es freut mich, das du deinem persönlichen Hausautomations Projekt weitere Aufgaben hinzufügst und diese mit FHEM lösen möchtest.

Mit freundlichem Gruß

joelinux
FHem on RPi2 Buster, Duofern Rollladen, ZWave Rolllade + Steckdosen, ZigBee (Philips, Tradfri), Tasmota (diverse Steckdosen, GU10 und E14 LSC Leds von Action, Sonoff RF Bridge), InterTechno Dimmer Steckdose ITLR-200