ok danke Dir, schau ich mir an.
MFG 3306
ok danke Dir, schau ich mir an.
MFG 3306
wird rf="0xBEF0B8" weiterhin beibehalten,
triggert dies in >E auch wenn ein anderes event als RfReceived eintritt.
sehe ich auch so, zeigen auch meine Tests.
OK,danke hat mir super weiter geholfen.
Hast du auch eine Idee, wie man in einer Liste aufsteigend Messwerte sortieren kann, dann daraus die ersten und die letzten Werte löschen und dann aus dem Rest einen Mittelwert bilden kann, und das alles mit Skript.
MFG 3306
danke Dir,
nee, pullup ist schon vorhanden,daran liegt es nicht,
aber ich habe da gestern auch noch weiter gelesen und experimentiert und habe herausgefunden , dass die Anweisung chg und upd sich selber nach Abarbeitung wieder löschen, also dachte ich mir, muß vielleicht die String-Variable per Hand gelöscht werden, weil das nicht passiert.
Habe also genau das was du schreibst auch mal probiert, mit rf="0" und siehe da, das war es. Ich habe dies aber vor endif eingefügt.
1. Aber warum ist das Verhalten so in E> ?
2. in E> wird doch nur etwas abgearbeitet, wenn ein entsprechendes Event auftritt, aber doch nicht alles, was da noch so in E> steht, oder doch?
3. Ist das so, als ob ich in die Unterroutine: E> springe, wenn ein Event eintrifft?
4. Lösche ich mit rf="" die Variable wieder, oder nur in E> ?
Kann man kaum was zu lesen.
MFG 3306
danke, hat soweit schon mal funktioniert, wie zu sehen:
20:25:32.261 MQT: tele/tasmota_99/RESULT = {"Time":"2022-03-28T20:25:32","RfReceived":{"Data":"0xBEF0B8","Bits":24,"Protocol":1,"Pulse":244}}
20:25:32.265 Taste: 0xBEF0B8
20:25:32.268 Script: performs "Power1 2"
20:25:32.314 MQT: stat/tasmota_99/RESULT = {"POWER1":"ON"}
20:25:32.329 MQT: stat/tasmota_99/POWER1 = ON
20:25:36.521 MQT: tele/tasmota_99/RESULT = {"Time":"2022-03-28T20:25:36","RfReceived":{"Data":"0xBEF0B8","Bits":24,"Protocol":1,"Pulse":244}}
20:25:36.526 Taste: 0xBEF0B8
20:25:36.527 Script: performs "Power1 2"
20:25:36.569 MQT: stat/tasmota_99/RESULT = {"POWER1":"OFF"}
20:25:36.584 MQT: stat/tasmota_99/POWER1 = OFF
habe das jetzt mal erweitert und damit aber ein Problem:
>D
rf=""
B1=1;Taster_Licht_EIN/AUS,GPIO13
>E
rf=RfReceived#Data
if rf=="0xBEF0B8"
then
print Taste: %rf%
=>Power1 2
endif
B1=Button1#Action
if upd[B1]>0
then
=>Power1 2
endif
Alles anzeigen
wenn ich nur Button1 drücke, toggle ich damit Power1,
21:04:53.724 MQT: stat/tasmota_99/RESULT = {"Button1":{"Action":"SINGLE"}}
21:04:53.728 Script: performs "Power1 2"
21:04:53.768 MQT: stat/tasmota_99/RESULT = {"POWER1":"ON"}
21:04:53.783 MQT: stat/tasmota_99/POWER1 = ON
21:04:58.680 MQT: stat/tasmota_99/RESULT = {"Button1":{"Action":"SINGLE"}}
21:04:58.686 Script: performs "Power1 2"
21:04:58.729 MQT: stat/tasmota_99/RESULT = {"POWER1":"OFF"}
21:04:58.740 MQT: stat/tasmota_99/POWER1 = OFF
aber wenn ich zuvor rf-Taste betätigt habe, geht bei nachträglichem betätigen von Button1 Power1 kurz An,dann Aus und dann wieder toogle,
wie in der Konsole zu sehen:
20:42:58.463 Taste: 0xBEF0B8
20:42:58.465 Script: performs "Power1 2"
20:42:58.515 MQT: stat/tasmota_99/RESULT = {"POWER1":"ON"}
20:42:58.523 MQT: stat/tasmota_99/POWER1 = ON
20:42:58.534 MQT: stat/tasmota_99/RESULT = {"Button1":{"Action":"SINGLE"}}
20:42:58.538 Taste: 0xBEF0B8
20:42:58.540 Script: performs "Power1 2"
20:42:58.587 MQT: stat/tasmota_99/RESULT = {"POWER1":"OFF"}
20:42:58.599 MQT: stat/tasmota_99/POWER1 = OFF
20:42:58.604 Script: performs "Power1 2"
20:42:58.651 MQT: stat/tasmota_99/RESULT = {"POWER1":"ON"}
20:42:58.664 MQT: stat/tasmota_99/POWER1 = ON
Alles anzeigen
um diesen Effekt zu deaktivieren,muß ich den ESP32 neu starten.
Ich weis nicht, warum die RF-Taste nochmals 2x mit abgearbeitet wird.
Ist schon komisch! Vielleicht kann jemand weiterhelfen?
ich muß noch ergänzend dazu sagen, dass ich die Button-Eingänge von den Relais-Ausgängen abgekoppelt habe, mit:
;Button- Eingänge von Relais-Ausgänge abkoppeln, nur MQTT-Nachricht
=>setoption73 1
;Button-Eingänge nur auf 1-Tastendruck voreinstellen,voreingestellt:disable
=>setoption13 1
MFG 3306
Hallo, habe mal ein Frage:
wie kann ich die String-Information eines RF-Senders mit Script richtig abfragen?
folgendes brachte die Konsole beim betätigen der Taste:
22:44:09.489 MQT: tele/tasmota_99/RESULT =
22:44:09.489 MQT: tele/tasmota_99/RESULT = {"Time":"2022-03-27T22:44:09","RfReceived":{"Data":"0xBEF0B8","Bits":24,"Protocol":1,"Pulse":244}}
die Taste soll z.B. Power1 toggeln
MFG 3306
Hallo Gerhard,
ich lese nun schon zwei Tage in deinen Ausführungen zu Tasmota32 und Berry. Finde es hochinteressant, was du da schon alles herrausgefunden und geschaffst hast. Habe selber schon einiges mit ESP8266 gemacht. Bin zu ESP32 gegangen, da ich oft mehr GPIOs benötige,als der ESP8266 bereithält und mit den Port-Erweiterungen PCF8574 und MCP23017 am ESP8266 immer so meine Probleme habe. Habe dabei mit Rules gearbeitet und versuchte mich dann auch in die Skript-Sprache einzuarbeiten, da Rules doch sehr begrenzt sind.
Bei mir läuft IOBroker mit VIS , um mir sämtliche Smart-Home- Ereignisse auf einem Display anzeigen zu lassen und es Steuern zu können.
Unter anderem Gewächshaus-beregnung, Sauna-steuerung, Poolsteuerung und Überwachung Regenwasserzisterne.
Da auch ich mit Ausreißern der Messwerte kämpfe, kam ich zu deinen Artikeln.
Ich komme leider in Berry nicht wirklich rein, mir fehlen einfach mal ein paar Beispiele, an den ich es fest machen und probieren kann.
Wäre schön, wenn du mir da mal auf die Sprünge helfen könntest. Vielleicht könnten wir gemeinsam dies an dem Programm für den Zisternenfüllstand durchgehen.
Mein jetziges System : selber Ultraschallsensor läuft am ESP8266 und bringt per Mqtt ständig Rohwerte des Abstandes, die ich dann per Brockly-Skript im IO-Broker in Abstand cm, Volumen Liter, Füllstand % umrechnen lasse und zur Anzeige bringe. Alles ziemlich weit weg vom Mess-system und störanfällig.
Bei mir sitzt nur der Sensor in der Zisterne, die Auswerte-Platine und der ESP draußen, wo ich leicht ran komme. Der ESP8266 ist ein Sonoff Basic.
Das Berry-Cookbook sagt mir leider nur Bahnhof. Aber es klingt sehr gut erweiterbar, wahrscheinlich komme ich dann mit anderen Projektproblemen besser voran.
Ich habe hier alles schon zu liegen
MFG Andreas
Hallo,
tele funktioniert so:
was auch noch geht:
on MCP230XX_INT#D0 do var1 %value% endon
oder
on MCP230XX_INT#D0 do power1 %value% endon
oder
on event#MCPINT_D0=0 do power1 off endon on event#MCPINT_D0=1 do power1 on endon
gelöst habe ich es nun doch mit mem, da die schaltvorgänge nicht so oft sind:
on MCP230XX_INT#D1 do mem1 %value% endon
on MCP230XX_INT#D2 do mem2 %value% endon
on MCP230XX_INT#D3 do mem3 %value% endon
on MCP230XX_INT#D4 do mem4 %value% endon
on mem1#State=0 do if (%mem2%==1 AND %mem3%==1 AND %mem4%==1) power2 0;power3 1 else power4 0 endif endon
somit sind die letzten Eingangszustände nach Stromausfall sofort wieder verfügbar und können in den if-endif -Vergleichen verarbeitet werden.
Danke noch mal für die Hilfe.
MFG 3306
Hallo, HoerMirAuf,
wie von Dir erwartet, folgendes geht nicht
Zitaton system#boot do backlog var6 %MCPint_D6%; var7 %MCPint_D7% endon
auch das geht nicht:
Zitaton system#boot do backlog event MCPINT_D6; event MCPINT_D7 endon
Zitat
Ich hab keine Ahnung was sich hinter dem event verbirgt
dies ist ein event, dass ausgelöst wird, wenn der als Eingang konfiguierte GPIO eines I2C-Portexpanders MCP23017 einen Signalwechsel L=>H oder H=>L per Interrupt erfährt. Dieser kommt in der Konsole als MCPint_D6=0 oder MCPint_D6=1 an.
im iobroker sieht das so aus:
ich kann dieses event auch nicht einfach mal so auslösen, es muß extern ein Schalter betätigt werden, so das der GPIO Low oder High sieht.
Die Implementierung des MCP23017 ist schon älter,ist aber vor kurzem überarbeitet worden und funktioniert jetzt gut.
Ich kenne mich mit C leider nicht gut aus, so dass ich dort wohl keinen Einfluss nehmen kann, so dass ich vielleicht auch ein anderes event erzeugen könnte.
Das größte Problem ist einfach:
ZitatWas bisschen blöd ist, das Trigger Inhalte nicht unmittelbar innerhalb vom IF/ENDIF ausgewertet werden.
hab auch schon folgendes probiert:
leider auch nichts.:
langsam gehen mir die Ideen aus.
Vielleicht hast du da noch was?
MFG 3306
Hallo,
ja das mit den begrenzten Schreibzyklen ist ja so mein Denkanstoß, um zu überlegen, gerade die Mem-Variablen nicht zu nehmen.
Wobei sich die Zustände meiner GPIO-Eingänge nun auch nicht so oft ändern.
Feste Werte aus den Mem-Variablen holen ist dann auch nicht so günstig, da das dann nicht mit den tatsächlichen Signalzuständen der GPIO-Eingängen übereinstimmt und so dann nicht korrekt wäre.
als Beispiel:
on event#MCPINT_D6=0 do var6 0 endon on event#MCPINT_D6=1 do var6 1 endon
on event#MCPINT_D7=0 do var7 0 endon on event#MCPINT_D7=1 do var7 1 endon
on var6#State do if (%var6%==0 OR %var7%==0) power7 1 else power7 0 endif endon
hier vergleiche ich den tatsächlichen Signalzustand von var6 mit dem nicht aktuellem Wert aus var7 , da ich nur var6 mit dem event#MCPINT_D6 aktuell einlese, aber nicht var7.
deswegen ist das einlesen und vergleichen von Variablen, die nicht aktuell gehalten sind, nicht optimal .
Ich finde jetzt gerade keine weitere Lösung dazu.
Schön wäre es ungefähr so:
on system#boot do backlog var6 %MCPint_D6%; var7 %MCPint_D7% endon
on event#MCPINT_D6=0 do var6 0 endon on event#MCPINT_D6=1 do var6 1 endon
on event#MCPINT_D7=0 do var7 0 endon on event#MCPINT_D7=1 do var7 1 endon
das muß ich mal probieren, ob das geht.
MFG 3306
ZitatWie viele Variablen kan man denn benutzen?
ich habe es selber in der tasmota.h gefunden, vordefiniert sind es 16 Variablen.
Was ich jetzt noch als Problem habe, nach Stromausfall sind diese Variablen nicht gefüllt (oder noch gar nicht definiert) und müssen einmalig erst wieder durch ein event gefüllt (oder definiert) werden.
Kann man sowas nach dem einschalten automatisch machen lassen?
Habe auch gelesen, das es auch feste Variablen "mem" gibt, die ihren Wert nicht mehr verlieren. Sind diese im EEprom abgelegt und nicht so oft beschreibbar? Wäre das die Lösung?
MFG 3306
ZitatMan muss sie erst mal in eine Variable schreiben um dann damit arbeiten zu können.
danke Dir, das war die Lösung.
Wie viele Variablen kan man denn benutzen?
Ich brauche die ganze Sache für ein größeres Projekt, habe dazu schon einen i2c-Portexpander MCP23017 im Einsatz, der bereits 8 Eingänge und 8 Ausgänge bereitstellt. Mal sehen, ob ich mit den 3 Rules hinkomme.
Habe mich gerade mit den Rules so einigermaßen eingearbeitet und deshalb jetzt nicht zum Scripting wechseln, wobei man da wohl viel mehr machen kann.
hier mal meine Test- Lösung.:
rule2
on event#MCPINT_D6=0 do var6 0 endon on event#MCPINT_D6=1 do var6 1 endon
on event#MCPINT_D7=0 do var7 0 endon on event#MCPINT_D7=1 do var7 1 endon
on var6#State do if (%var6%==0 AND %var7%==0) power7 1 else power7 0 endif endon
on var7#State do if (%var6%==0 AND %var7%==0) power7 1 else power7 0 endif endon
rule2
on event#MCPINT_D6=0 do var6 0 endon on event#MCPINT_D6=1 do var6 1 endon
on event#MCPINT_D7=0 do var7 0 endon on event#MCPINT_D7=1 do var7 1 endon
on var6#State do if (%var6%==0 OR %var7%==0) power7 1 else power7 0 endif endon
on var7#State do if (%var6%==0 OR %var7%==0) power7 1 else power7 0 endif endon
Alles anzeigen
MFG 3306
Hallo,
ich bin schon eine Weile am experimentieren, um die AND und OR-Befehle in einer Rule zum laufen zu bringen.
Habe bereits die user-config-override.h angepasst und use_expression und support_if_statement definiert und neu kompilliert.
Kann mir jemand mal ein Beispiel geben,wie das in einer Rule laufen könnte?
Ich möchte folgendes realisieren:
2 GPIO-Eingänge abfragen, entweder AND oder OR verknüpfen und damit z.B. einen Ausgangs-GPIO schalten.
Habe auch schon mit If,Else-Routinen probiert, aber nichts vernüftiges erreicht.
P.S. gibt nicht wirklich viele Beispiele dafür, läuft das schon?
MFG 3306