Fehler bei Setzen des Attribut Templates bei MQTT2_Device

Begonnen von bromosky, 27 Mai 2020, 12:50:45

Vorheriges Thema - Nächstes Thema

bromosky

Moin,

nach langem Zetern habe ich gestern Abend Tasmota auf eine Gosund SP112 geflasht. Irgendwann hat auch das Autocreate funktioniert (Ich habe mich wohl sehr dämlich angestellt) und die MQTT2_Devices für beide Geräte wurden angelegt. Zu meinem Erstaunen gibt es sogar ein Template dafür.

Folgendes geschieht:
Ich wähle das Template aus, drücke auf set <NAME> attrTemplate tasmota_POW_USB_split. Danach passiert gar nichts, sprich der FHEM sagt, es wäre nicht zu erreichen. Es wird nichts geändert. Nach ein paar Sekunden ist FHEM wieder zu erreichen, der Event Monitor zeigt gar keine Befehle an.

Wie kann ich dennoch das Template einfügen, denn ich würde das ja nun schon gerne Schalten. Sprich welche einzelnen Befehle müsste ich an FHEM füttern?
Wie kann ich grundsätzlich dieses Problem umgehen, das FHEM nicht auf die Auswahl des MQTT2_Device Templateattributs reagiert?

Grüße, Max :)

Beta-User

Bist du auf dem letzten Stand?

(Es gab afaik ein gelöstes Problem bei dem intern verwendeten tasmota_2channel_split. Ggf. erst mal ein update+restart machen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

bromosky

Ja, alles auf dem neusten Stand, da gestern ein Backup aufgespielt wurde. Habe direkt ein update all gemacht. Nochmal gerade, nur um auf Nummer sicher zu gehen.

Das Problem bezieht sich anscheinend nicht nur auf dieses Template bei mir. Tasmota Basic geht prima, Tasmota POW oder ein weiteres (tasmota rgbw split) gehen auch nicht.

Beta-User

Hmm, bin grade etwas ratlos.

Das dritte ist das hier, oder? tasmota_plug_with_rgbw_split

Geht denn das "normale" split: tasmota_2channel_split?

Und steht ggf. irgendwas im Log?
(Sonst muß ich bei Gelegenheit selbst testen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

bromosky

Genau, das Dritte ist "tasmota_plug_with_rgbw_split". Ich habe einfach willkürlich irgendwelche ausgetestet um zu schauen, ob es auch bei anderen Templates ist.

Das tasmota_2channel_split nimmt FHEM übrigens an ohne zu meckern. Alles richtig im EventMonitor. FHEM Log zeigt nix an.

Sobald ich wieder das andere Template nehme (tasmota_POW_USB_split), wieder FHEM unresponsive, nichts im EventMonitor, nichts im Log.

Kann ich irgendwie noch weitere Daten zusammentragen?


Beta-User

#5
Hmm, ist irgenwie komisch...

Also: In dem einen war noch ein kleiner Hänger drin, über den man aber nur stolpern kann, wenn man eine der drei unterstützten Sprachsteuerungsoptionen im Einsatz hat. Das hier sollte diesen Teil beheben:

# sonoff 1 channel + USB device flashed with Tasmota.
name:tasmota_POW_USB_split
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:Plug with additional USB outlet flashed with Tasmota. <br>For use e.g. with Gosund SP112 or Blitzwolf SH5<br>NOTE: a second device will be created for the USB channel.<br>NOTE: still untested template, feedback is welcome!
order:A_01c1
set DEVICE attrTemplate tasmota_2channel_split CALLSPEECHRECOGN=0
set DEVICE attrTemplate tasmota_POW
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
par:ICON;ICON as set, defaults to usb;{ AttrVal("DEVICE_CH2","icon","usb") }
attr DEVICE_CH2 icon ICON
attr DEVICE_CH2 comment Channel 2 (USB outlets) for DEVICE
setreading DEVICE_CH2 associatedWith DEVICE
attr DEVICE_CH2 devStateIcon on:usb:off off:usb@red:on
attr DEVICE_CH2 setStateList on off toggle
set DEVICE_CH2 attrTemplate speechcontrol_type_switch
attr DEVICE,DEVICE_CH2 model tasmota_POW_USB_split
setreading DEVICE,DEVICE_CH2 attrTemplateVersion 20200527

Ansonsten habe ich grade in einer Testinstallation ohne Spracherkennung alle drei ohne jeglichen Mucks durchgetestet und auch keine wirkliche Erklärung für die Hänger. Sehr vielleicht ist im Hintergrund wegen des fehlgeschlagenen Versuchs irgendwas im Argen (=> FHEM neu starten)?

Hast du denn  Spracherkennung im Einsatz? Und ggf. welche?

EDIT: Bitte auch noch OS+Perl-Version.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

bromosky

Danke beta-user für deine Hilfe!

Ich hab keine Sprachsteuerung aktiviert. Daran wird es also nicht liegen. Ich kann mich ganz entfernt daran erinnern, dass ich selbiges Problem auch schonmal hatte, ich glaube da waren es Templates für Zigbee2MQTT. Das konnte ich dann aber irgendwie umgehen. Da das jedoch nun auch schon mindestens ein halbes Jahr her ist, habe ich keine Vorgehensweise im Kopf.

Zudem ist es ja wirklich eigenartig, dass bestimmte Templates gehen, andere nicht. Und auch "split" geht ja.
Bei mir ist wirklich viel im Argen, ich sollte wohl wirklich das System einmal neu aufsetzen. (Grundlegend, aber wann hat man schon dafür Zeit)

Neugestartet wurde es häufiger, dies löste das Problem auch nicht. Ich habe nun den Pi mal neugestartet, auch dies brachte keine Änderung.

Beta-User

Sorry, das war wohl zu leicht zu übersehen:
Zitat von: Beta-User am 27 Mai 2020, 14:50:56
EDIT: Bitte auch noch OS+Perl-Version.
(getestet hier unter MSWin32, Perl 5.28.1, fheminfo gibt Auskunft).

An sich glaube ich nicht, dass das irgendwie an einer Fehlkonfiguration liegt, dazu ist der Mechanismus an der Stelle m.E. zu simpel.

Das einzige, was mir noch einfällt, ist der Perl-Code in devStateIcon. Da dämmert mir, dass es ggf. mal Probleme gab mit Perl-Verisonen <5.24 (?). Falls du sowas noch hast, kannst du die betreffenden Zeilen mal auskommentieren, {AttrTemplate_Initialize()} ausführen und es dann nochmal probieren?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

bromosky

Ich lese nur gerne 2-3 mal über meinen Post, bevor ich Stuss schreibe, deswegen habe ich es übersehen.

Raspbian Stretch 9, Perl 5.24.1 läuft bei mir.

ZitatDas einzige, was mir noch einfällt, ist der Perl-Code in devStateIcon. Da dämmert mir, dass es ggf. mal Probleme gab mit Perl-Verisonen <5.24 (?). Falls du sowas noch hast, kannst du die betreffenden Zeilen mal auskommentieren, {AttrTemplate_Initialize()} ausführen und es dann nochmal probieren?
Ich könnte es trotzdem austesten, wenn das vielversprechend sein könnte. Dann bräuchte ich aber das etwas konkreter, wie ich das testen könnte.

Beta-User

Auskommentieren will sagen: einfach ein # an den Zeilenbeginn setzen, dann wird die ignoriert und es gibt kein devStateIcon.
Der Pfad zur Datei ist typischerweise: /opt/fhem/FHEM/lib/AttrTemplate/mqtt2.template.
Kannst einen beliebigen Editor nehmen, die Rechte müssen halt hinterher wieder passen (ich verwende gerne mcedit aus dem Paket mc).

Danach muß die file neu eingelesen werden, dazu in die FHEM-Befehlszeile das bezeichnete Kommando. That's all...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

bromosky

Gesagt, getan. Danke für die Erklärung! Auskommentiert (habs mit nano gemacht), Rechte liegen immernoch bei FHEM.
Attribute neu geladen, auch im Logfile nachgeschaut ob es funktioniert hat.

Selbes Problem, sprich keine Änderung.

Beta-User

...dann bin ich für den Moment ratlos...

Ggf. kannst du versuchen, das "zu Fuß" zu machen. Dann eben jeden Befehl/jedes Attribut über die (erweiterte) Kommandozeile (das "+") eingeben und die Parameter entsprechend selbst ersetzen. (Das scheint ja im template zu klappen, sonst bekämst du ein Dialogfeld).
Wo ein "set DEVICE attrTemplate xy" auftaucht: Dasselbe für dieses andere attrTemplate.

Vielleicht finden wir so die kritische(n) Zeile(n)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

bromosky

Auch das habe ich jetzt umgesetzt, bin gerade bei tasmota_POW. Genau der verursacht bei tasmota_POW_USB_split die Probleme.

Folgendes also gemacht,
set DEVICE attrTemplate tasmota_2channel_split Funktioniert.
set DEVICE attrTemplate tasmota_POW Ging nicht, da zweites Device angelegt, weiter mit 1. Device und Befehler für tasmota_POW
set DEVICE attrTemplate tasmota_basic_state_power1 Funktioniert.
... setlist funktioniert, alles funktioniert weiterhin bis auf:
attr MQTT2_DVES_02AAB5 devStateIcon {my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot"; my $light = ReadingsVal($name,"state","off");"<a href=\"http://".ReadingsVal($name,"IPAddress","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a> uptime: ".ReadingsVal($name,"Uptime","unknown").sprintf(" aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))}
FHEM schmiert wieder ab, ist kurzzeitig nicht zu erreichen!

Rest funktionierte tadellos.

Beta-User

Also wie vermutet der Perl-Teil in devStateicon...

"schmiert ab" bedeutet auch Neustart? (Dann sollte aber auch was im Log stehen, hmm, also eher nur Denkpause...) Sonst könnte stacktrace weitere Infos liefern, wenn FHEM wirklich abschmiert und nicht versucht, irgendwelche Daten aus dem Nivana zu holen. Aber wenn es "nur" hakt, ist es schwierig.

Wir könnten noch versuchen, das noch etwas zu "entschlacken":
attr MQTT2_DVES_02AAB5 devStateIcon {my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot"; my $light = ReadingsVal($name,"state","off");'<a href="http://'.ReadingsVal($name,"IPAddress","none").' "target="_blank">'.FW_makeImage($onl).'</a> <a href="/fhem?cmd.dummy=set $name toggle&XHR=1">'.FW_makeImage($light)."</a> uptime: ".ReadingsVal($name,"Uptime","unknown").sprintf(" aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))}
Weitergehender wäre, die Parameter für sprintf vorher noch aufzulösen oder zu versuchen, das ganze als multiline-stateFormat zu basteln.
(Dazu habe ich aber grade nicht die große Motivation; wenn du magst und das gleichwertig hinbekommst, übernehme ich das aber gerne).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rudolfkoenig

Wenn es stimmt, dass FHEM abstuerzt, dann kann man das Problem am ehesten lokalisieren, wenn man FHEM im Terminal per "perl fhem.pl -d fhem.cfg" startet, und nach dem Crash hier die letzten 10 Zeilen uns mitteilt.