Fast relay switching based on power increase

[tobetobe66]

Hi Gemu,

thanks a lot for the beautiful scripting feature.

I am using a Gosund SP1, GPIO4: 134, GPIO5: 132, GPIO12: 131, GPIO14: 21. I am monitoring power and switch off the relay as soon as power is over 1 Watt using the following code:

T _pow=ENERGY#Power

F . . . if ((_pow>1) and (_s==S)) { ->power1 0 e_eP=1 }

This works perfectly fine, however it takes sometimes way above 1 second for the relay to switch off. This is a bit too slow for me. The load is 800W, power rise should be instant. Is there a way to do this faster? Maybe it's not possible at all, because sampling rate of power measurement is too slow.

I would be grateful for some ideas. Thank you very much.

[gemu2015]

Ja so ist es, bei ; mitten in einer Zeile weis man nicht genau was passiert!

[tobetobe66]

Verständnisfrage Wenn ich t:xyz als timer verwende geht das nur auf Sekundenbasis oder? Wenn ich was in ms will, dann muss ich mir über upsec,uptime was in der F-Section bauen, das wäre dann in 0,1s Schritten oder? Danke Gruss Tobi

[gemu2015]

Ja die t:xx timer sind in Sekunden.

in der >F Sektion kannst du halt in 100ms Schritten selbst zählen. Darauf kannst du dich aber nicht wirklich verlassen, weil die >F section gepollt wird es können auch mehr als 100ms zwischen 2 polls vergehen.

Am 31.05.2020 um 11:01 schrieb tobetobe66 notifications@github.com:

Verständnisfrage Wenn ich t:xyz als timer verwende geht das nur auf Sekundenbasis oder? Wenn ich was in ms will, dann muss ich mir über upsec,uptime was in der F-Section bauen, das wäre dann in 0,1s Schritten oder? Danke Gruss Tobi

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gemu2015/Sonoff-Tasmota/issues/21#issuecomment-636442770, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACY3QY6T2BXI7CK5R35SJVLRUIMHLANCNFSM4NGUNWAA.

[tobetobe66]

Hallo Gerhard,

wollte mal kurz Rückmeldung geben. Also es funktioniert alles. Heute mal mit 3 Gosunds getestet. Gosund 1: niedrige Prio mit 800W Wasserkocher Gosund 2: mittlere Prio mit 2000W Heizofen Gosund 3: hohe Prio mit 2000W Fön Maximale Leistung 2800W eingestellt. Wasserkocher und Fön eingeschaltet, die loggen sich ein und laufen. Danach den Fön dazu. In etwa 1 Sekunde hat der Fön sich eingeschaltet und die beiden anderen rausgeschmissen. Danach hat sich der Wasserkocher wieder zugeschaltet, da noch Lesitung frei war. Das hat absolut alltagstauglich funktioniert, dank der tollen Scriptingmöglichkeit.

Folgende Störfälle kann ich erkennen und zeitnah 10 sec. bearbeiten: -MQTT Verbindung reist ab, dann wird alles wieder neu gestartet -Ein oder mehrere Gosunds fallen aus, dann wird alles wieder neu gestartet

Falls bei bestehender MQTT-Verbindung Nachrichten verloren gehen, führt dies zu einem instabilen System. Aber ich denke die Wahrscheinlichkeit geht bei gutem WLAN wegen darunterliegendem TCP gegen Null. Evtl. baue ich noch ein, dass verlorene Nachrichten nach 10 Sekunden wieder zu einem stabilen Zustand führen.

Danke nochmals für deine Hilfe. Beste Grüsse Tobi

[tobetobe66]

Hallo Gerhard,

habe bereits ein neues Scripting-Projekt auf dem Schirm: DCF 77-Funkuhr mit Script.

Dazu muss ich 1 mal pro Sekunde eine Pulsdauer messen ansteigende Flanke, fallende Flanke. Ist das im Script möglich? Ich muss noch mal genauer prüfen was Tasmota hier bietet. Bin mir nicht sicher, ob die Zeit zwischen steigender und fallender Flanke messbar ist. Du stellst ja im Script mit pc[x] was zur Verfügung.

Für Erleuchtung bin ich stets dankbar.

Grüsse Tobi

[gemu2015]

Hi Tobi, Freut mich wirklich dass es so gut funktioniert! Ist ne tolle Anwendung! Vielleicht hast du ja Lust das mal bei den Beispielen einzustellen.

Der Tasmota Counter kann Pulslängen messen das weis ich. Das Ergebnis kannst du dann mit pc[x] abholen.

Eigentlich wundert es mich dass es für DCF77 noch keinen eigenen Tasmota Treiber gibt.

Grüsse

Gerhard

[tobetobe66]

Hi Gerhard,

stelle das gerne bei den Beispielen ein. Muss aber noch ein bisschen "beautyfyen". Ausserdem möchte ich es gerne bei mir min. 2 Wochen live testen. Die Skripte sind auch ziemlich lang. Kann das jeder einstellen? Habe mir auch überlegt, ob ich das mal in ein Solarforum einstelle. Was meinst Du?

Bezüglich DCF77, ich probiere mal, ob ich das im Skript hinbekomme. Dann kann da gerne jemand einen Treiber für GPIO xyz erstellen.

Mein Anspruch ist es im Skript zu schaffen. :-)

Gruss Tobi

[gemu2015]

im Prinzip kann das jeder einstellen! Ist ein pull request bei Tasmota Docs. Da ich Schreibrechte habe könnte ich es auch für dich einstellen.

Ja macht Spass das "Scripten". Leider hat der ESP8266 nicht so viele Möglichkeiten wie der ESP32. Zur Zeit arbeite ich fast nur noch damit. Da ist halt ein Realtime Multitasking Betriebssystem darunter (FreeRTOS). Da kannst du z.B. Scripter Tasks als Multitasking starten. Die laufen weiter auch wenn Tasmota hängt.

[tobetobe66]

Das mit dem ESP32 ist natürlich toll. Das werde ich mir als nächstes ansehen. Die 8266 sind halt in vielen Steckdosen, Schaltern etc.. verbaut. Fertige Hardware eben. Die 32er kommen hoffentlich bald in kommerzielle Plattformen (Stecker dran:-))

Darauf freue ich mich jetzt schon. Bezüglich der Anwendung mit den Gosunds teste ich und mache die Doku fertig. dann melde ich mich bei Dir.

[tobetobe66]

Hi Gerhard,

brauche deine Hilfe. Für DCF77 muss ich an einem GPIO die Dauer eines Pulses (Dauer zwischen steigender Flanke und fallender Flanke) messen. So wie das aussieht sprechen die Counter nur auf fallende Flanken an. Habe ich was übersehen oder muss man da mit Switches arbeiten?

Hast Du eine Idee?

[gemu2015]

soweit ich das verstanden habe kann man doch die Periodendauer messen ? CounterType = 1 => Pulse Timer liefert die Pulszeit des Low Pulses Da die Pulse bei DCF immer im Sekundenabstand kommen kannst du ja 1 sec - counter Wert nehmen. du musst ja nur zwischen 100 und 200 ms unterscheiden, wären dann halt 800 oder 900 ms

[tobetobe66]

hmm, ich sehe mir das an.

[tobetobe66]

Ich komme da nicht zu Rande. Bei countertype = 1, pulse counter, kann ich die Zeit zwischen zwei fallenden Flanken messen. Ich kann dann zwar Wechsel zwischen 0 und 1, 1 und 0 eindeutig unterscheiden, aber bei 0,0 und 1,1 kann ich dann nichts mehr erkennen. Deswegen wäre es sehr hilfreich, die Zeit zwischen steigender und fallender Flanke messen zu können.

[gemu2015]

ok, dann werd ich dir wohl so was einbauen müssen. werd mal nachdenken, ist aber nicht schwer.

[tobetobe66]

Ich sage bereits jetzt danke. :-)

[gemu2015]

so, versuch mal dein Glück (GitHub)

measure pulse time: res = mpt(-P) = > define Pin P as timer input

res = mpt(0) hole pulstime in ms

erst mal zwischen steigender und fallender Flanke

später vielleicht umschaltbar

bisher auch nur 1 Pin, also nicht mehrere Pins zu messen

[tobetobe66]

Ok, mache ich gleich.

Nur fürs Protokoll:

• irgendeinen pin als counter definieren und auf pulsetime stellen.

dann res = mpt(-P) in D-Section???? oder einfach in F oder S Section? res=mpt(0) zum auslesen?

[gemu2015]

z.B. >D res=0

>B ; definiere GPIO 4 als Pulse Timer res=mpt(-4)

>S res=mpt(0)

print %res%

[gemu2015]

so noch ne kleine Änderung >D res=0

>B ; definiere GPIO 4 als Pulse Timer res=mpt(4)

>S res=mpt(-1)

print %res%

wenn man 128 auf die Pin Nummer draufzählt misst er zwischen fallend und steigend sonst umgekehrt res=mpt(128+4)

[tobetobe66]

va bene, gerade am testen. dann geh ich mal compilieren :-)

[tobetobe66]

Läuft so wie es aussieht. Danke. 20:24:52 963.00 20:24:53 1008.00 20:24:54 1008.00 20:24:55 1016.00 20:24:56 1016.00 20:24:57 1016.00

Das ist der Output bei in S-Section flippendem GPIO5. Passt also. Getestet mit res=mpt(128+4) Echt klasse.

[tobetobe66]

Die Möglichkeit, im Script zwischen den Messarten mit res=mpt(128+4) oder res=mpt(4) umzuschalten, ist grossartig.

[gemu2015]

Morgen Tobi,

so habe mal drüber geschlafen und weiter verbessert.

mpt(x) definiert den Pin

mpt(-1) liest die high low Zeit mpt(-2) liest die low high Zeit die Pulszeit wird nach dem Auslesen auf Null gesetzt. Damit kannst du erkennen ob überhaupt eine Periode statt gefunden hat. (du must ja den DCF Sync alle Minute finden)

und weil diese Funktion sicher selten gebraucht wird und kostbaren IRAM verbraucht habe ich sie optional gemacht mit anderen seltenen Funktionen du must #define USE_ANGLE_FUNC angeben.

Grüße

Gerhard

[tobetobe66]

Moin Gerhard,

Perfekt. Die Erkennung des Sync hätte auch so funktioniert, aber so ist es viel besser. Die m:, bzw. M: Variablen sind bei der Umsetzung sehr hilfreich. Einfach vollschreiben und dann nach Detektion des Sync einfach auslesen und berechnen. Sollte eigentlich funktionieren.

Vielen Dank. Gruss Tobi

[gemu2015]

Hab jetzt noch was ganz verwegenes eingebaut. Wenn du 128 zur Pinnummer addierst wird bei der steigenden Flanke die Sektion >I in scripter aufgerufen. Damit wärst du komplett synchron mit dem Signal. Da das aber im Interrupt geschieht darf da nichts schief gehen und es darf nur ganz wenig Code im >I Teil stehen, also nur Wert abholen und in array schreiben oder so. Das würde auch schief gehen wenn das Signal prellt, habe zwar ein debounce von 20 ms drin aber besser sollte das Signal sauber sein, also kein Switch oder so.

[tobetobe66]

Das ist ja ein Träumchen. Kann erst in 5 Stunden weiter machen. Ich habe es noch nicht probiert, deswegen frage ich jetzt einfach. Kann man den aktuellen Index eines arrays, also array[0] auch setzten?

Danke Gruss Tobi

[gemu2015]

ja den kann man auch setzen!

[gemu2015]

ja das mit der >I section war leider ein Irrtum. Da der Interrupt auch während eines Flash update passieren kann darf man von dort keine Flash Programme aufrufen. Hab das wieder ausgebaut. Wär schön gewesen. Da deine >S oder >F Sektionen nicht synchron mit dem DCF sind könnte es gelegentlich zu Fehldetektionen kommen. Kann man aber sicher abfangen.

[tobetobe66]

Schade, das wäre der Knaller gewesen. In der F-Section bin ich max 100ms daneben, damit habe ich kein Problem. Bin gespannt ob es funktioniert. Muss man eben ausprobieren.

[tobetobe66]

Morgen Gerhard,

so habe jetzt einen alten Funkwecker zerlegt und versucht das DCF-Signal zu verwenden. Hat leider nicht lange funktioniert:-). Danach noch einen zerlegt, den kann ich jetzt zum Testen verwenden. Liefert auch schöne 100ms und 200ms Pulse am Oszi.

Mit deiner letzten Version liefert folgendes Skript:

D res=0

B ; definiere GPIO 4 als Pulse Timer res=mpt(4) spinm(4 0) F res=mpt(-2) print %res%

Den folgenden Output:

06:40:57 897.00 06:40:57 0.00 06:40:57 1099.00 06:40:57 0.00 06:40:57 0.00 06:40:57 0.00 06:40:57 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:59 0.00 06:40:59 0.00 06:40:59 0.00 06:40:59 1798.00 06:40:59 1900.00 06:40:59 0.00 06:40:59 0.00 06:40:59 0.00 06:40:59 0.00 06:40:59 0.00 06:41:00 0.00 06:41:00 0.00 06:41:00 0.00 06:41:00 898.00 06:41:00 0.00 06:41:00 1100.00 06:41:00 0.00 06:41:00 0.00 06:41:00 0.00 06:41:00 0.00 06:41:01 0.00 06:41:01 0.00 06:41:01 0.00 06:41:01 796.00 06:41:01 894.00 06:41:01 0.00 06:41:01 0.00 06:41:01 0.00 06:41:01 0.00 06:41:01 0.00 06:41:02 0.00 06:41:02 0.00 06:41:02 0.00 06:41:02 902.00 06:41:02 0.00 06:41:02 1105.00

Man erkennt sehr schön den langen Sync-Puls. Auffällig ist:

• Es werden immer 2 Werte geliefert
• ein Aufruf von res=mpt(-1) anstatt -2 liefert immer 0

Eigentlich müsste ich doch bei Aufruf von -1, nur jeweils einen Wert (100 oder 200) bekommen und bei Aufruf von -2 jeweils auch nur einen Wert (800, 900, 1800, 1900) oder?

Danke Grüsse Tobi

[gemu2015]

Moin Tobi,

Sehr merkwürdig,

die Werte sollten doch 100,200 oder 800,900 liefern. DCF ist doch alle Sekunde ein Impuls ? Finde auf Anhieb keinen Fehler in meinem Kode. Glitches ? Werde jetzt mal einen Testaufbau machen und Signale vom Funktionsgenerator einspeisen. Melde mich dann wieder

Grüße

Gerhard

PS spinm() brauchst du nicht, macht schon mpt()

Am 05.06.2020 um 07:48 schrieb tobetobe66 notifications@github.com:

Morgen Gerhard,

so habe jetzt einen alten Funkwecker zerlegt und versucht das DCF-Signal zu verwenden. Hat leider nicht lange funktioniert:-). Danach noch einen zerlegt, den kann ich jetzt zum Testen verwenden. Liefert auch schöne 100ms und 200ms Pulse am Oszi.

Mit deiner letzten Version liefert folgendes Skript:

D res=0

B ; definiere GPIO 4 als Pulse Timer res=mpt(4) spinm(4 0) F res=mpt(-2) print %res%

Den folgenden Output:

06:40:57 897.00 06:40:57 0.00 06:40:57 1099.00 06:40:57 0.00 06:40:57 0.00 06:40:57 0.00 06:40:57 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:58 0.00 06:40:59 0.00 06:40:59 0.00 06:40:59 0.00 06:40:59 1798.00 06:40:59 1900.00 06:40:59 0.00 06:40:59 0.00 06:40:59 0.00 06:40:59 0.00 06:40:59 0.00 06:41:00 0.00 06:41:00 0.00 06:41:00 0.00 06:41:00 898.00 06:41:00 0.00 06:41:00 1100.00 06:41:00 0.00 06:41:00 0.00 06:41:00 0.00 06:41:00 0.00 06:41:01 0.00 06:41:01 0.00 06:41:01 0.00 06:41:01 796.00 06:41:01 894.00 06:41:01 0.00 06:41:01 0.00 06:41:01 0.00 06:41:01 0.00 06:41:01 0.00 06:41:02 0.00 06:41:02 0.00 06:41:02 0.00 06:41:02 902.00 06:41:02 0.00 06:41:02 1105.00

Man erkennt sehr schön den langen Sync-Puls. Auffällig ist:

Es werden immer 2 Werte geliefert ein Aufruf von res=mpt(-1) anstatt -2 liefert immer 0 Eigentlich müsste ich doch bei Aufruf von -1, nur jeweils einen Wert (100 oder 200) bekommen und bei Aufruf von -2 jeweils auch nur einen Wert (800, 900, 1800, 1900) oder?

Danke Grüsse Tobi

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gemu2015/Sonoff-Tasmota/issues/21#issuecomment-639273249, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACY3QY6GLAXSYRGLS3UTERLRVCBLZANCNFSM4NGUNWAA.

[gemu2015]

Hab das mal jetzt aufgebaut und erst mal mit einem Taster ausprobiert. Einen DCF habe ich gerade nicht zur Hand. Den Funktionsgenerator müsste ich erst anpassen (hat 5 Volt Ausgang)

Die Ergebnisse sind plausibel. Habe jetzt noch eine Unterdrückung von kurzen Spikes eingebaut (erst mal 10 ms) Teste mal meine aktuelle Version

[gemu2015]

so, habe jetzt mit Funktionsgenerator getestet und alles funktioniert wie es soll.

[tobetobe66]

Ich teste

[tobetobe66]

Hallo Gerhard,

bei mir läuft jetzt auch alles wie es soll. Hatte zunächst den Pegel der Funkuhr direkt abgegriffen. Der war entweder zu niedrig oder es hat nicht gereicht den Eingang des Wemos zu treiben oder beides. Hat aber zu interessanten Ergebnissen geführt. An dieser Stelle ein grosses MEA CULPA. Hätte ich besser prüfen müssen. Das positive an der Sache ist, es ist jetzt 2 mal getestet worden: Einmal Funktionsgenerator und dann mit DCF77 Empfänger aus Funkuhr. Vermutlich würde es sogar ohne debounce 10ms funktionieren. Ich teste jetzt das DCF77 Script und melde mich dann. Gruss und DANKESCHÖN Tobi

[tobetobe66]

Ich vergass, Abhilfe schufen 2 Widerstände und ein NPN Transistor.

[gemu2015]

Hi Tobi, Baue gerade einen Editor mit Syntaxcolorierung für die Scripte. Falls du Interesse hast das mit zu testen schicke ich dir eine Version. Das Script wird local editiert und soll dann per Tastendruck an den ESP geschickt und direkt gestartet werden.Davor werden alle Kommentare und Indents entfernt damit das script möglichst kompakt wird. Die Kolorierung geht schon, das kompakt file wird abgespeichert (unter compressed_script.txt) aber noch nicht gepostet. daran arbeite ich noch.

Habe Mac und PC version

Gruß Gerhard

[tobetobe66]

Hallo Gerhard,

natürlich helfe ich beim Testen. Ist doch klar. Brauche Mac.

Bezüglich DCF77: Ist aufwändiger als gedacht. Eigentlich einfach, Problem ist aber tatsächlich die Synchronisation. Da ich in der F-Section arbeiten muss, kann es vorkommen, dass aufgrund unterschiedlicher Laufzeiten der Section sich das Sampling-Fenster verschiebt. Kann gerade nicht mehr weitertesten, da mein Testrechner belegt ist. Sind aber bisher alles nur Vermutungen.

Die I-Section wäre extrem hilfreich gewesen. Ein Interrupt der im Script zugänglich ist, wäre der Knaller gewesen.

Gruss Tobi

[gemu2015]

Moin Tobi

https://www.dropbox.com/s/pj44bmxzkipebzd/uVariotest.zip?dl=0 hier die version die auch das file sendet. auf GitHub der zugehörige scripter

Die scripts müssen .txt suffix haben und in der ersten Zeile muss >D stehen, dann erkennt er die Datei als Tasmota script.

Du kannst jetzt beliebig kommentieren und einrücken.

in irgend einer Zeile muss IP=xxx.xxx.xxx.xxx die IP deines Tasmota stehen

Jetzt CMD R oder im Menu run eingeben und das script wird gesendet und sofort gestartet.

Viel Spass damit

Gerhard

[tobetobe66]

War gerade am ausprobieren. Dann lade ich jetzt die neue Version. Funktioniert bei Dir das highlighting bereits komplett und fehlerfrei?

Gruss Tobi

[kugelkopf123]

Moin Gerhard.

Ich versuche dir schon seit Tagen auf deine Nachricht zu Antworten. Allerdings zickt das Forum wieder. Gibt es in GH eigentlich eine PN Funktion? Habe nun über die Tasmota Docs die Beschreibung zum externen Script Editor gefunden. Tolle Arbeit von euch beiden! Allerdings funktioniert er nicht bei mir, wenn nach dem >D eine Zahl folgt.

>D 37 Syntax Error in Line 1. Ist die Fehlermeldung.

Oh und wie verhält es sich mit dem Kompressionsfaktor, wenn man beim Kompilieren #define ESP32_SCRIPT_SIZE 8192 angibt? Konnte diese definition überhaupt nicht in den tasmota Docs finden. Vielleicht existiert sie ja garnicht mehr.

Viele Grüße Chris

[tobetobe66]

Nur fürs Protokoll: Ich habe nicht viel gemacht :-) Grüsse Tobi