Seit 2 Tagen will der Groschen nicht fallen und es kann eigentlich nur ein klitzekleiner Fehler sein:
Was in meinem Beispiel real passieren soll: Es klingelt -> die Steckdose wird automatisch eingeschaltet -> und nach 1:30 Min wieder ausgeschaltet. Was ich erfolgreich ausprobiert habe:
Einschalten geht:
define n_Stedose_an notify (Klingel) { GetHttpFile("192.168.178.33:80", "/cm?cmnd=Power%20ON") }
Ausschalten geht:
define n_Stedose_an notify (Klingel) { GetHttpFile("192.168.178.33:80", "/cm?cmnd=Power%20OFF") }
Ein- und gleich wieder ausschalten geht:
define n_Stedose_an notify (Klingel) { GetHttpFile("192.168.178.33:80", "/cm?cmnd=Power%20ON") };; { GetHttpFile("192.168.178.33:80", "/cm?cmnd=Power%20OFF") }
Zeitverzögertes schalten geht:
define n_Stedose_an notify (Klingel) define at_Steckdose_aus at +00:01:00 { GetHttpFile("192.168.178.33:80", "/cm?cmnd=Power%20ON") }
... aber das geht leider noch nicht:
Einschalten und dann zeitverzögert ausschalten GEHT NICHT:
define n_Steckdose_an notify (Klingel) { GetHttpFile("192.168.178.33:80", "/cm?cmnd=Power%20ON") };; define at_Steckdose_aus at +00:01:30 { GetHttpFile("192.168.178.33:80", "/cm?cmnd=Power%20OFF") }
Fehlermeldung in der Logdatei:
n_Steckdose_an return value: syntax error at (eval 2983) line 1, near "00:"
Nach den ganzen funktionierenden Befehlen darüber, müsste der letzte eigentlich auch funktionieren. Tut er aber nicht. Ich verzweifle .... es kann nur was Kleines sein, bitte jetzt keine watchdogs/DOIFs/sleep oder andere. Was muss in dem letzten Befehl geändert werden?
Danke
Jannis
Ungetestet würde ich behaupten, dass FHEM es nicht mag, dass du Perl und Perl-Syntax auf diese Art mischst.
Versuch's mal in diese Richtung:
define n_Steckdose_an notify (Klingel) { GetHttpFile("192.168.178.33:80", "/cm?cmnd=Power%20ON"); fhem ('defmod at_Steckdose_aus at +00:01:30 { GetHttpFile("192.168.178.33:80", "/cm?cmnd=Power%20OFF") }')}
90 sek sind keine lange Zeit. Warum da nicht mit dem Sleep-Befehl?
ZitatFHEM-sleep gefolgt von einem Befehl startet dieses Befehl mit einem internen Timer, ist also sowas wie ein at ohne Namen, und blockiert FHEM nicht.
Wenn schon at, dann (wie Beta-User schreibt) mit defmod. Warum? versuch mal das unter 90 sek zu wiederholen.
Ich hätte hier eher ein DOIF genommen, da gibt es WAIT.
Zitat...es kann nur was Kleines sein
Dann bitte ich um Hilfe: der FHEM Befehlsparser ist z.Zt. noch sehr einfach gestrickt, und nimmt bei ^{.*}$ an, dass es sich um _ein_ Perl-Ausdruck handelt, und perl steigt mit der erwaehnten Fehlermeldung aus.
Als Argument zu notify wird _entweder_ eine Kette von FHEM-Befehlen, ein Perl-Ausdruck, oder ein Shell-Kommando akzeptiert. Eine Mischung kann funktionieren, muss aber nicht.
Zitatbitte jetzt keine watchdogs/DOIFs/sleep oder andere.
Habs gelesen, ich wuerde trotzdem fuer andere Leser es versuchen:
defmod ca_steckdose cmdalias set Steckdose .* AS { GetHttpFile("192.168.178.33", "/cm?cmnd=Power%20$EVTPART1");; undef }
defmod n_Steckdose_on notify Klingel set Steckdose ON;; sleep 90;; set Steckdose OFF
Zitat von: rudolfkoenig am 20 November 2019, 16:10:55
Habs gelesen, ich wuerde trotzdem fuer andere Leser es versuchen:defmod ca_steckdose cmdalias set Steckdose .* AS { GetHttpFile("192.168.178.33", "/cm?cmnd=Power%20$EVTPART1");; undef }
defmod n_Steckdose_on notify Klingel set Steckdose ON;; sleep 90;; set Steckdose OFF
Ich ging davon aus, dass ich was falsch gemacht hatte. Da fhem meine Befehle so wie geschrieben nicht richtig parsen kann (warum auch, wenn es auch anders geht .... wusste ich nur nicht :) ) probiere ich nactürlich den Vorschlag auch aus.
Mein Herz hängt auch nicht an dem Einschalten der Steckdose per Perl:
{ GetHttpFile("192.168.178.33:80", "/cm?cmnd=Power%20ON")Ich versuche halt eine Blitzwolf (Gosund)-Steckdose, die ich mit Tasmota geflasht habe, mit fhem einzuschalten. Gibt es da auch ein direkt verfügbares
set Steckdose onohne Tricks über cmdalias?
nimmst du MQTT2_DEVICE, das "kann" auch "on-for-timer" ;) .
sie "Praxisbeispiele" zu MQTT2_DEVICE im Wiki.
Zitat von: Beta-User am 20 November 2019, 17:45:35
nimmst du MQTT2_DEVICE
ja, das nehme ich. Ist da auch ein
set Steckdose on (also ohne es mit mit aliascmd zurechtzubiegen)vorgesehen, ohne das ich Tasmota in der Steckdose direkt mit einen Url-Aufruf wie oben in meinem Code anspreche?
Genau auf diese Frage bezog sich meine vorherige Antwort.
Nochmal die Langform: Die für MQTT2_DEVICE verfügbaren attrTemplates ermöglichen die Übermittlung der set-on und set-off Befehle (und einiges mehr) via MQTT durch direkte set-Optionen am FHEM-Device. Sie bringen die SetExtensions mit, mit deren Hilfe FHEM auch set ... on-for-timer machen kann. Dazu gibt es noch Optionen, den Timer auf den Microcontroller (aka ESP8266) zu verlagern.
(Den Wiki-Artikel hast du gefunden, oder?)
Danke!!!!!
Was soll ich sagen? Alle Möglichkeiten, die ihr mir hier genannt habt, funktionieren und führen zu dem von mir gewünschten Ergebnis. Danke!!!
Aus allen Möglichkeiten habe ich etwas über FHEM gelernt. Aber mich mit MQTT2 auseinander zu setzen, ließ mich staunen; attrTemplate hatte ich in meinen Versuchen ignoriert, aber genau das konfiguriert mir meine Steckdosen so, dass ich sie ohne Tricks einfach mit "set Steckdose on" und sogar on-for-timer schalten kann.
Welches MQTT2 attrTemplate nimmt man für eine WLAN-Steckdose (Blitzwolf SH5 bzw. Gosund SP112), die mit Tasmota geflasht wurde? Ein Template oder mehrere? Ich hab mal "tasmota_basic" gewählt, weil sich das so basic anhört :)
Schönes Wochenende ... demnächst
:) Danke für das Feedback.
Was die Wahl des "richtigen" attrTempates angeht: Kommt darauf an, was die Dinger können. Die templates orientieren sich weniger an den Handelsnamen und mehr an dem was an Infos kommt, also z.B. ob eine Meßfunktion integriert ist usw.
"set ... attrTemplate ?" kann da helfen, und Vorschläge bzw. patches, um da jeweils die passenden Handelsnamen zu nennen, kann ich gerne einarbeiten.
Macht es Sinn, mehrere Templates su "set"zen?
Zitat von: Beta-User am 21 November 2019, 16:04:14
:) Danke für das Feedback.
Was die Wahl des "richtigen" attrTempates angeht: Kommt darauf an, was die Dinger können. Die templates orientieren sich weniger an den Handelsnamen und mehr an dem was an Infos kommt, also z.B. ob eine Meßfunktion integriert ist usw.
Ja, die messen den Verbrauch und haben zusätzlich zwei USB-Steckdosen. Welche/s Template nehmen?
Zitat von: Beta-User am 21 November 2019, 16:04:14
"set ... attrTemplate ?" kann da helfen, und Vorschläge bzw. patches, um da jeweils die passenden Handelsnamen zu nennen, kann ich gerne einarbeiten.
Das wäre bestimmt für Einsteiger sehr hilfreich. Zu den Blitzwolf gibt es ja eine Riesenliste kompatibler, aber ein paar Markennamen wäre schon gut, kompatible kann man sich dann ja selbst suchen.
In der Regel macht es keinen Sinn (als user) mehrere nacheinander aufzurufen. Allerdings ist es bei den Tasmotas so, dass es ein paar Basistemplates gibt, die intern auch von anderen aufgerufen werden (z.B. das basic für die Kleinschreibung).
Vermutlich hätte es also für eine Dose mit Strommessfunktion genügt, das "tasmota_POW"-template anzuwenden.
Nur, wenn z.B. die beiden USB-Steckdosen schaltbar wären, macht es uU. Sinn, erst ein "split"-template anzuwenden und dann auf den ersten Kanal dann das POW (und den nicht benötigten 4. Kanal zu löschen).
Das mit den Markennamen kann man wie gesagt machen, wenn man mal weiß, was die Dinger können und einige konfigurierte Devices gesehen hat, scheint es aber auch zu genügen, dass man das, was das template tun wird dann angezeigt bekommt, zusammen mit der Beschreibung, wenn man eines aus der dropdown-Liste auswählt. Da hat Rudi auch was hilfreiches gebastelt...
Da ich den ganzen Quark aber nicht in Hardware hier habe und nur vom Hörensagen kenne, bin ich für die Einarbeitung der Namen usw. auf Zuarbeit angewiesen, so: feel free...
Zitat von: Beta-User am 21 November 2019, 16:26:56
Da ich den ganzen Quark aber nicht in Hardware hier habe und nur vom Hörensagen kenne, bin ich für die Einarbeitung der Namen usw. auf Zuarbeit angewiesen, so: feel free...
Ok, ich versuch mal zu helfen:
die Blitzwolf SH5 und Kompatible (z.B. Gosund SP112) haben eine Strommessfunktion und zwei USB-Strom-Steckdosen, die über Relais2 ein und ausgeschaltet werden können. Über Relais1 wird das Licht geschaltet.
Zitat von: jannis am 21 November 2019, 16:32:17
Ok, ich versuch mal zu helfen:
Schön, dann würde ich für das weitere Lernen vorschlagen, du nimmst überlegst dir, ob das USB-Relais als Nebenkanal im Hauptdevice angelegt sein soll oder als eigenes und baust dann für die comunity hier ein entsprechendes neues attrTemplate daraus ;) :
Wenn es ein Nebenkanal sein soll, das "tasmota_2ch_unified" als Basis, allerdings dann mit dem Hautrelay nach "state" (wie im POW), und aufgehübschter Energie-Anzeige.
Als "split" kannst du das "tasmota_2channel_split" nehmen, den ersten Kanal dann mit dem POW nachkonfigurieren und den zweiten optisch etwas anpassen (icon passend zu USB usw).
Dazu eine nette desc:, und schon bist du fertig :) .
Klingt bestimmt erst mal kompliziert, aber du kannst dabei eigentlich kaum was falsch machen, aber ungemein was lernen, was das Aussehen von Geräten in FHEMWEB angeht. Gerne kannst du dazu auch einen neuen Thread in MQTT-Bereich aufmachen, da findest du bestimmt auch (weitere) Helfer (die sowas haben), wenn es nicht vorangehen sollte.
Zitat von: Beta-User am 21 November 2019, 16:45:27
Schön, dann würde ich für das weitere Lernen vorschlagen, du nimmst überlegst dir, ob das USB-Relais als Nebenkanal im Hauptdevice angelegt sein soll oder als eigenes und baust dann für die comunity hier ein entsprechendes neues attrTemplate daraus ;) :
Wenn ich weiter bin in FHEM, mache ich das gerne. Doch im Augenblick versuche ich noch den Überblick zu bekommen .... was nicht immer leicht ist: z.B. an MQTT2 wundert mich, dass es auch für Zigbee geht ... oder ist diese FHEM-Systemübersicht falsch bzw. unvollständig: https://wiki.fhem.de/wiki/System%C3%BCbersicht ? Dort ist Zigbbe nämlich nicht mit mqtt2 verbunden.
Schön, dass du darüber gestoplert bist: Da gibt es ein * mit dem Hinweis: Geht auch anders...
(Ist übrigens häufig der Fall, FHEM ist so flexibel, dass es fast immer mehrere Möglichkeiten gibt, irgendwas beliebiges an Hard- und Software einzubinden, anzusprechen...).
Ich habe wohl wahrgenommen, dass du Anfänger bist, aber die Frage an dich war bewußt gestellt: Du kannst an dem Beispiel einiges lernen, und zwar schneller als dir lieb ist ;) . Und FHEM lebt - wie alle open-souce-Projekte vom Mitmachen. Ansprüche stellen wie "kann mal eben einer ein template/code/Modul machen für ..." ist nicht so zielführend, wie den Versuch zu unternehmen, eigene Probleme zu lösen und nach Hilfe zu fragen (die bekommst du, wenn du dich nicht zu doof anstellst, keine Frage ;) ). Andere (ehemalige) Anfänger haben das auch schon erfolgreich durch...
Zitat von: Beta-User am 21 November 2019, 17:03:32
Andere (ehemalige) Anfänger haben das auch schon erfolgreich durch...
Ich war schon in vielen Dingen Anfänger und habe dann Beiträge für die Allgemeinheit geleistet ... leider sieht das nicht jeder als seine soziale Pflicht an. Nur zur Zeit geht es nicht. Wenn aber ein anderer mal ranwill, habe ich wenigstens mal grob überlegt, wie ich (im ersten Versuch) rangehen würde:
Ausgangspunkt: FHEMM/lib/AttrTemplate/mqtt2.template
name:tasmota_POW_USB
set DEVICE attrTemplate tasmota_basic_state_power1
attr DEVICE setList \
off: ... \
on: ... \
toggle: ... \
offUSB ... \
onUSB ... \
toggleUSB ... \
... und noch ein paar andere Einstellungen
Ich würde dafür kein zweites Device absplitten ... außer es ist zwingend nötig (was ich aber als FHEM-Anfänger noch nicht erkenne).
So, ich renne weiter ... die Zeit brennt.
Da ein zweites Device von FHEM aus leichter zu schalten (u.a. wg. SetExtensions) ist, hier der Versuch, das als "split" zu vertemplaten:
# 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>NOTE: a second device will be created for the USB channel; <br>For use e.g. with Gosund SP112 or Blitzwolf SH5
order:A_01c1
set DEVICE attrTemplate tasmota_2channel_split
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
copy DEVICE 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
attr DEVICE model tasmota_POW_USB_split
attr DEVICE_CH2 model tasmota_POW_USB_split
Wenn jemand bei Gelegenheit Rückmeldung gibt, ob das soweit paßt, tue ich was für die Allgemeinheit und checke es ein...