[gelöst per scripting] Tasmota rule, OBIS Zähler und deutliche Power-Änderungen

[Beta-User]

Hallo zusammen,

bestimmt habe ich zu kurz oder falsch gesucht, ganz sicher aber  bin im falschen Forum,
jedenfalls kann ich mir nicht vorstellen, dass das bisher noch niemand gelöst hat und seine Lösung teilen möchte...

Also: Gegeben ist ein smarter Stromzähler (Landis Gyr+ E320), der von einem Tasmota-ESP via IR-Lesekopf ausgelesen wird. Der Tasmota kennt also ca. alle Sekunde den aktuellen Verbrauch bzw. die aktuelle Einspeisung.

Versendet wird dann immer alles, wenn teleperiode um ist. (z.B. die Wifi-Daten). Daher finde ich es nicht die optimale Lösung, die deutlich zu verkürzen, zumal dann auch kein Filter dran ist, um vorab zu checken, ob das wirklich interessant ist. Denn wenn die aktuelle Einspeisung von 3456W auf 3277W sinkt, ist das nicht optimal, aber vermutlich kein Anlass, irgendeinen Automatismus anlaufen zu lassen. Wie dem auch sei, was ich gerne hätte, wäre dass sich der ESP merkt, welchen Wert er zuletzt gesendet hat und dann bei jedem Mess-Durchlauf checkt, ob die Abweichung dazu (z.B., Absolutwerte, also für Einspeisung und Bezug gleich)
bei unter 250W gesamt mehr als 50W,
bei unter 1000W gesamt mehr als 100W,
bei unter 2000W gesamt mehr als 250W,
und darüber mehr als 500W beträgt.

Wenn ja: Sende (nur) den (einen) neuen Wert...

Bestimmt ein Klacks für jemand, der sich mit Tasmota-rules oder Tasmota-scripting auskennt . (Ich wollte mich da aber nicht auch noch einarbeiten ).

Danke für zielführende Hinweise oder fertigen Code , ich würde ihn dann ggf. auch teilen bzw. eventuell ein attrTemplate für Tasmota-OBIS basteln, über das man das dann ggf. auch wiederfinden kann...

Grüße, Beta-User

[DasQ]

mit tasmota rules auskennt, ist sehrwahrscheinlich viel zu hochtrabend von mir. aber ich habe schon einige rules erstellt.

als erstes fällt mir da natürlich das hier ein. ich habe sinnigerweise einen ähnlich geartet fall und zwar wird mir sporadisch ein viel zu hoher wert aufgelesen und versaut mir dadurch den nullpunkt im fhem plot.
das wollte ich schon längst gelöst haben und schlägt in die selbe kerbe (so denk ich)

ich nehm dein post jetzt mal zum anlass, diesen missstand bei mir in angriff zu nehmen. weg muss er eh und zeit zum lernen hab ich grade auch.

ich meld mich sobald ich erste erfolge zu verbuchen habe.

[Beta-User]

Cool, Danke schon mal vorab!

(Eilt nicht, schaffe grade erst die Voraussetzungen, um sinnige Reaktionen aus dieser Art Wert abzuleiten...).

[Beta-User]

Hmm, irgendwie bin ich grade noch bei "scripting language" gelandet und habe zwei snipplets gefunden, die interessant aussehen:
https://tasmota.github.io/docs/Scripting-Language/#send-power-reading-with-formatted-time-stamp-via-websend und https://tasmota.github.io/docs/Scripting-Language/#fast-polling

Code Auswählen Erweitern

>T
et=ENERGY#Total
p=ENERGY#Power
; every 5 minutes
if upsecs%300==0
then
y=sb(tstamp 0 4)
m=sb(tstamp 5 2)
d=sb(tstamp 8 2)
=>%ws%/service/r2/addstatus.jsp?key=%key%&sid=%id%&d=%1.0(y)%%2.0(m)%%2.0(d)%&t=%1(sb(tstamp 11 5))%&v2=%s(2.0p)%
endif

(publish-Anweisung; auch für einen T>-Abschnitt)

Code Auswählen Erweitern

; publish abs hum every teleperiod time
if mqtts>0
and upsecs%tper==0
then
; calc abs humidity
tmp=pow(2.718281828 (17.67*temp)/(temp+243.5))
tmp=(6.112*tmp*hum*18.01534)/((273.15+temp)*8.31447215)
; publish median filtered value
=>Publish tele/%topic%/SENSOR {"Script":{"abshum":%med(0 tmp)%}}
endif

[Beta-User]

Mal mein aktueller Zwischenstand:

Man kann wohl entweder scripting haben oder rules, und für die SML-Auswertung braucht man so oder so scripting. Für den E320 gibt es einen "Smart Meter Descriptor". Von daher hier das erweiterte script für den E320:

Code Auswählen Erweitern

>D
pow=0
>B
=>sensor53 r
;disable publishing at MQTT teleperiod, on boot
smlj=0
>S
;re-enable publishing at MQTT teleperiod, after 10 seconds of uptime
if upsecs>10
then
smlj|=1
endif

; publish power every teleperiod/20 time (default result: 15 sec)
if mqtts>0
and upsecs%(tper/20)==0
then
pow=#Power_in

;pow=sml[3]
; just publish power value
=>Publish tele/%topic%/SENSOR {"Script":{"power":%0pow%}}
endif
>M 1
+1,3,s,20,9600,E320
1,77070100020800ff@1000,Total Delivered,kWh,Total_out,3
1,77070100010800ff@1000,Total Consumed,kWh,Total_in,3
1,77070100100700ff@1,Current power,W,Power_in,0
1,77070100600100ff@#,Server-ID,,Meter_Number,0
#
Das sendet schon mal regelmäßig zur jeweils erwarteten Zeit, aber leider mit "pow=nur Nullen oder (mit dem Versuch, auf das sml-Array zuzugreifen) kaputte JSON (und eine Fehlermeldung in der Tasmota-Konsole)...

Ergo stellt sich die Frage, wie man auf den Wert zugreifen kann? Der muss ja irgendwo gespeichert sein?!?
E320#Power_in wollte jedenfalls auch nicht...

Für das sml[3]-Ding gibt es vielleicht eine Erklärung:

To get the value of one of the descriptor lines, use sml[X]. X = Line number. Starts with 1. (compiling with USE_SML_SCRIPT_CMD required)

Muss vermutlich die Tasmota-Firmware dann doch mal selber compilien. Oder mal die "scripting"-firmware aus dem hier verlinkten repo testen: https://github.com/arendst/Tasmota/discussions/17733#discussioncomment-4709425

[DasQ]

Wie du hast die nicht selbst kompiliert? Die SML Version muss man zwingend selber bauen. Das ist nicht im Release

Btw. Ich hab gestern die meiste Zeit damit verbummelt wieder mein plattfomio zu reparieren. Eigentlich sollte alles passen, wenn willst Bau ich's dir

[Beta-User]

Na ja, den Lesekopf gab es mit oder ohne ESP, und mit kostete nicht wesentlich mehr wie ohne. Da ich mir nicht unnötig Komplexität einhandeln wollte, habe ich "mit" gekauft, und da war halt das passende Tasmota gleich drauf...

Wichtiger wie ein fertiges bin wäre mir ein user-Konfig-file für ein "Minimal"-Tasmota mit scripting und der nämlichen Erweiterung. Dann kann ich das bei Bedarf auch künftig ggf. auf den aktuellen Stand holen... (Andererseits: ein aktuelles fertiges bin hätte schon auch was!).

OT:
VSCode mit pio ist zumindest im Moment nicht das Problem, nachdem ich mich gedanklich erfolgreich von Atom verabschiedet habe und das für die MI-Integration in AhoyDTU jetzt auf dem aktuellen Stand habe .

[DasQ]

minimal kannst relativ einfach in der platformio_override.ini aktivieren
semikolon vor tasmota-minimal entfernen.


***edit*** ich bau dir eins extra, im letzten bin waren noch wlanconfigs drin.****
solltest du ein wemos ähnlichen esp haben (1Mb) häng ich mal ein funktionierendes bin an
auf welchen gpios ist der lesekopf?

(hast du die pin für dein zähler, wenn er denn ein hat?)

script sollte das sein. (GPIO ggf anpassen)

Code Auswählen Erweitern

>D
>B
=>sensor53 r
>M 1
+1,3,s,20,9600,E320
1,77070100020800ff@1000,Total Delivered,KWh,Total_out,3
1,77070100010800ff@1000,Total Consumed,KWh,Total_in,3
1,77070100100700ff@1,Current power,W,Power_in,3
1,77070100600100ff@#,Server-ID,,Meter_Number,0   
#

[Beta-User]

THX. Ist ein "nackiger" 01-ESP8266 (mit den 8 PINs), der da verbastelt ist. Von denen habe ich noch ein paar staubige in meiner Bastelkiste ganz unten...

Leider meldet das Ding für OTA, dass der Speicher nicht ausreicht.... Ist vielleicht sowieso besser, wenn ich das bin erst mal auf einen anderen packe und das dann damit teste. Irgendwo sollte ich auch so ein "flash-board" für die 01-er ESP's rumliegen haben. (Hatte ich schon angemerkt, dass ich die Dinger eigentlich nicht leiden kann...?!? Hätte nicht geglaubt, dass ich die jemals wieder rauskrame.)

"Mein" erweitertes script hattest du gesehen? Das ist die von dir gepostete Fassung (aus der Tasmota-Doku) mit ein paar Erweiterungen .

EDIT: dein .bin wird wieder gelöscht, warte dann auf das "gereinigte"

[DasQ]

welche tasmota version ist drunter? je nach version musst du erst mal hoch patchen

dazu die lite-release versionen in der reihenfolge verwenden
https://tasmota.github.io/docs/Upgrading/
Upgrade Flow~

v1.0.11  🔀  v3.9.22  🔀  v4.2.0  🔀  v5.14.0  🔀  v6.7.1  🔀  v7.2.0  🔀  v8.5.1  🔀  v9.1  🔀  Current release

p.s. eben versucht die minimal mit sml zu bastel siehe screenshot ... muss ich erstmal fixen
p.s.2. also minimal und lite lässt sich nicht mit sml kompilieren.
p.s.3. mit dem minimal war käse. da hat sich inzwischen soviel geändert das ich unqualifiziert mist gesagt hab. sorry

[Beta-User]

THX.

Da ist grade eine 12.3.1 am werkeln, und nachdem mir das mit der Kellerkiste wieder eingefallen ist, werde ich wohl erst mal versuchen, die sensors-bin auf einen jungfäulichen ESP zu knallen und meine readingList vorab entsprechend anzupassen...

Das muss aber noch ein bißchen warten .

Wenn kein OTA geht, und man immer diesen Zwischenschritt über die Minimal braucht (ist bei tasmota2zigbee genauso, wenn ich mich recht entsinne), dann ist das mit dem updaten schon immer ein wenig lästig.

[DasQ]

du sagtest esp01 ... da musst mit den gpios aufpassen, der hat ja eigentlich nur 2. wenn der nicht ausfrisiert ist (ports vom ic direkt abgegriffen)

btw.
so sieht der sml reader bei mir in fhem aus. wobei mir die werte von gestern und heut über statistik modul gemacht werden, die werte sollten morgen wieder stimmen

Code Auswählen Erweitern

defmod MQTT2_DVES_79008C MQTT2_DEVICE DVES_79008C
attr MQTT2_DVES_79008C alias Stromzaehler
attr MQTT2_DVES_79008C devStateIcon Online:10px-kreis-gruen Offline:10px-kreis-rot
attr MQTT2_DVES_79008C group Stromzähler
attr MQTT2_DVES_79008C readingList DVES_79008C:stat/tasmota_79008C/RESULT:.* { json2nameValue($EVENT) }\
DVES_79008C:tele/tasmota_79008C/LWT:.* LWT\
DVES_79008C:cmnd/tasmota_79008C/POWER:.* POWER\
DVES_79008C:tele/tasmota_79008C/INFO1:.* { json2nameValue($EVENT) }\
DVES_79008C:tele/tasmota_79008C/INFO2:.* { json2nameValue($EVENT) }\
DVES_79008C:tele/tasmota_79008C/INFO3:.* { json2nameValue($EVENT) }\
DVES_79008C:tele/tasmota_79008C/STATE:.* { json2nameValue($EVENT) }\
DVES_79008C:tele/tasmota_79008C/SENSOR:.* { json2nameValue($EVENT) }\
DVES_79008C:stat/tasmota_79008C/POWER:.* POWER\
DVES_79008C:tasmota/discovery/807D3A79008C/config:.* { json2nameValue($EVENT) }\
DVES_79008C:tasmota/discovery/807D3A79008C/sensors:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_79008C room Keller
attr MQTT2_DVES_79008C sortby 1
attr MQTT2_DVES_79008C stateFormat <a href="http://Info2_IPAddress" target="_blank">\
LWT\
</a>\
uptime: Uptime\
<br>\
Heut: statSML_Total_inDay Wh\
Gestern: statSML_Total_inDayLast Wh\
<br>\
aktuell: SML_Power_cur W\
Gesamt: SML_Total_in Wh


bin hab ich oben angehängt

[Sany]

Hallo Beta-User,
wenn der von Dir benutzte ESP den Zähler auslesen kann dann ist das scripting aktiv und Du bräuchtest eigentlich erst mal nix weiter, ausser dem richtigen script. Da Du von einem ESP-01 sprichst bin ich bei Details dazu erst mal raus, da ich meine "Forschungen" auf einem ESP32 Board mit Ethernet gemacht hab. Stichwort: Speicher, ist bei den ESP-01 halt eher klein, scripting und vor allem genutzte Variablen in scripting brauchen aber gerade eines: Speicher. Ich will mal unterstellen, dass mit Anstieg deiner Anforderungen wohl auch die Probleme ansteigen werden. Ich würde jetzt auf dem vorhandenen ESP versuchen, das script zum laufen zu bekommen, wenn beim Start vom Script dann schon "Fehlermeldungen" mit Bezug auf Speicher auftauchen würde ich performantere Hardware nehmen. Da kannst Du dann die .bin mit den gewünschten (oder ungewünschten) Komponenten brennen. Ich habe bei mir z.B. das ganze HomeAssit und Autokonfig und so rausgelassen.

Zum Script: Dein Script aus #4 liefert schon etwas, sprich auf der tasmota-Webseite kommen die Daten, und per MQTT wohl auch schon?
Mit der Vermutung von sml[3] bist du auf dem richtigen Weg: In sml sind alle ausgelesenen Zählerwerte, in [3] ist der Power-Wert, einfach der dritte definierte Wert:

>M 1
+1,3,s,20,9600,E320
1,77070100020800ff@1000,Total Delivered,kWh,Total_out,3    --> sml[1]
1,77070100010800ff@1000,Total Consumed,kWh,Total_in,3    --> sml[2]
1,77070100100700ff@1,Current power,W,Power_in,0              --> sml[3]
1,77070100600100ff@#,Server-ID,,Meter_Number,0
#

der Rest müßte eigentlich so gehen.
Noch ein paar Worte zum scripting (obwohl es mindestens so gut wie die fhem-commandref unter Tasmota/scripting beschrieben ist):
- Variablennamen so kurz wir möglich (Speicher!), müssen zu Beginn in >D deklariert werden
- Bedingungen: es gibt 2 Schreibweisen: if-then-endif etc oder if(Bedingung){Ausführung} else {andere Ausführung} darf man NICHT mischen!
ich finde die Klammern übersichtlicher, besonders wenn man irgendwann verschachtelte Zweige hat. Geschmacksfrage.
- zum testen kannst Du einfach print die Variable VAR hat den Inhalt: %3VAR% schreiben, wird dann in der Konsole ausgegeben. Die Variable wird zwischen %-zeichen gesetzt, die Zahl hinter dem ersten % ergibt die Kommastellen. Genau wie beim Publish.
...

Gruß



Sany

[DasQ]

kurze zwischen info
so tasmota hat mich mal wieder eineinhalbstunden meiner wertvollen lebenszeit gekostet.

Code Auswählen Erweitern

not enough space

ich war stocksteif der meinung (laut anleitung) ich müsste von einer kleineren (minimal oder lite) version starten zu upgraden/flashen. ging aber nich . jetzt hab ich einfach mal die 4m version genommen, danach die sml und siehe da 

schaut dein tasmota webif so aus?

[Beta-User]

So, kurzer frustrierter Zwischenstand:

Der Tasmota mit der sml-Version von DasQ läuft, ich mußte das Ding dazu aber ausbauen und auf meinem supertollen ESP-01-flash-helper-Board direkt via USB flashen, OTA war nicht genug Speicher da. (Die weiteren Geschichten des heutigen Versuches erspare ich euch...)

Ergebnis: wie vorher - das script läuft, alle Werte sind im Web-IF da und werden zur teleperiode versendet. Der Zusatz läuft auch, alle 15 Sekunden wird gepublisht - nur leider nach wie vor die "0".

Die Firmware ist mit "USE_SML_SCRIPT_CMD" konfiguriert gewesen, richtig?

[DasQ]

moin Beta-User nicht explizit, da ich auf der sml seite nur "NO_USE_SML_SCRIPT_CMD" finde, geh ich davon aus es ist standardmäßig aktiv.
sag bescheid wenn das elementar ist. jetzt kurz gesucht und noch nicht gefunden.

also die user_config_override.h schaut bei mir so aus. den undef part hab ich aus meiner älteren TasmotaSML version übernommen, dachte ja zunächst das Bin-file ist zu groß.

Code Auswählen Erweitern


#ifndef _USER_CONFIG_OVERRIDE_H_
#define _USER_CONFIG_OVERRIDE_H_

// hier ist für standard wlan usw config auskommentiert

#ifndef USE_SCRIPT
#define USE_SCRIPT
#endif
#ifndef USE_SML_M
#define USE_SML_M
#endif
#ifdef USE_RULES
#undef USE_RULES
#endif
#define USE_UFILESYS


#undef USE_DOMOTICZ
#undef USE_HOME_ASSISTANT
#undef USE_EMULATION_HUE
#undef USE_EMULATION_WEMO
#undef ROTARY_V1
#undef USE_SONOFF_RF
#undef USE_SONOFF_SC
#undef USE_TUYA_MCU
#undef USE_ARMTRONIX_DIMMERS
#undef USE_PS_16_DZ
#undef USE_SONOFF_IFAN
#undef USE_BUZZER
#undef USE_ARILUX_RF
#undef USE_SHUTTER
#undef USE_DEEPSLEEP
#undef USE_EXS_DIMMER
#undef USE_DEVICE_GROUPS
#undef USE_PWM_DIMMER
#undef USE_SONOFF_D1
#undef USE_SHELLY_DIMMER
#undef USE_WS2812
#undef USE_MY92X1
#undef USE_SM16716
#undef USE_SM2135
#undef USE_SONOFF_L1
#undef USE_ELECTRIQ_MOODL
#undef USE_LIGHT_PALETTE
#undef USE_DGR_LIGHT_SEQUENCE
#undef USE_DS18x20
#undef USE_ADE7953
#undef USE_SERIAL_BRIDGE
#undef USE_ENERGY_MARGIN_DETECTION
#undef USE_PZEM004T
#undef USE_PZEM_AC
#undef USE_PZEM_DC
#undef USE_MCP39F501
#undef USE_DHT
#undef USE_BL0940
#undef USE_IR_REMOTE
#undef USE_IR_RECEIVE
#undef USE_ZIGBEE_ZNP
#endif

***edit***
da es fehlerfrei durch läuft sollten xdrv_10_scripter.ino und xsns_53_sml.ino abgearbeitet worden sein und dort ist es aktiv. (so mit morgentlich müden augen kurz abgecheckt) aber ich kontrollier des nach dem ersten kaffe nochmals

[DasQ]

moin die zweite

schau mal was ich da für dich habe (zähler config bitte anpassen)
in sml[3] ist bei mir auch nur ne 0 drin. arrays fangen aber bei 0 an, also 0,1,2,

Code Auswählen Erweitern

>D
pow=0
p0=0

>B
=>sensor53 r
>S
pow=0
p0=0
print %pow% %p0% %sml[0]% %sml[1]% %sml[2]%
;disable publishing at MQTT teleperiod, on boot
smlj=0
pow=sml[1]
print log1 %pow% %p0%

;re-enable publishing at MQTT teleperiod, after 10 seconds of uptime
if upsecs>10
then
smlj|=1
endif

; publish power every teleperiod/20 time (default result: 15 sec)
if mqtts>0
and upsecs%(tper/20)==0
then
p0=sml[2]
print log2 %pow% %p0%

;pow=sml[3]
; just publish power value
=>Publish tele/%topic%/SENSOR {"Script":{"power":%sml[1]%}}
endif
>M 1
+1,12,s,0,9600,SML
1,77070100010800ff@1000,Total Consumed,KWh,Total_in,3
1,77070100100700ff@1,Current Consumption,W,Power_cur,0
1,77070100020800ff@1000,Total Delivered,KWh,Total_out,3
1,7707010060320101@#,Service ID,,Meter_id,0
#

[Beta-User]

Vielen Dank für's Recherchieren und Austesten!

Jetzt kommt (mit der auf 0 Stellen angewiesenen sml[3]-Variable in der publish-Anweisung) schon mal der ungeglättete Power-Wert!!!!

Strange ist das trotzdem, dass das gestern den Tag über nicht wollte. Da scheint also tatsächlich dieses feature aus irgendwelchen Gründen nicht aktiv gewesen sein, oder man darf in der publish-Anweisung nur das sml-Array verwenden?

Na ja, wie dem auch sei: Muss das ganze dann mal noch mit der gleitenden Mittelwert-Betrachtung erweitern, dafür sollte der Speicher in dem 01-er 8266 ausreichen (der ist schön mit im Lesekopf verbaut!), und dann versuche ich irgendwann noch, die firmware auch mal selbst zu bauen (falls nicht was funktionierendes in dem repo zu finden ist).

Anmerkungen noch:
- Die Doku bei Tasmota-Scripting ist wirklich sehr gut! (Es ging mir eigentlich wirklich eher darum, mich für so ein "Standardproblem" (?!?) nicht auch noch da einlesen zu müssen )
- An ein Problem mit der Zählung im Array hatte ich auch zuerst gedacht und mein script daher direkt auf [2] umgestellt. Nachdem da aber immer derselbe Wert kam, ist mir aufgefallen, dass der zu groß ist bzw. das falsche Vorzeichen hat... Warum das bei uns unterschiedlich zu sein scheint, ist mir jedenfalls völlig unerklärlich.

Na ja, für's erste bin ich jedenfalls ausgesprochen Happy, Danke vielmals (!!!) für eure Unterstützung bis hierher und werde jetzt erst mal "normale Samstags-Jobs" erledigen...

[DasQ]

das coole an der sache ist, ich kanns für mich selbst verwenden.

bin aber ernsthaft am überlegen mein sml kopf mit nem esp32 zu bestücken. btw. is da kein meter daneben einer der meine heizungstemperaturen erfasst. der hätte noch genug ressourcen offen die sml geschichte zu übernehmen. (da lassen sich auch ganz hübsche webif`s basteln hab ich gesehn)

ach ja das mit dem vorzeichen hatte ich zu anfang auch mal, aber nach dem ich den modul type auf generic (18) gestellt hatte wars danach weg. (der müsste fallback seitig bei dir auf "sonoff basic (1)" stehen)

[Beta-User]

das coole an der sache ist, ich kanns für mich selbst verwenden.

So oder so: Danke!

Hatte schon den "Verdacht", dass das ganze ein Thema ist, das nicht nur einen interessiert, und bei dem es mehr Fallstricke gibt, als man auf den ersten Blick annehmen würde...

bin aber ernsthaft am überlegen mein sml kopf mit nem esp32 zu bestücken. btw. is da kein meter daneben einer der meine heizungstemperaturen erfasst. der hätte noch genug ressourcen offen die sml geschichte zu übernehmen. (da lassen sich auch ganz hübsche webif`s basteln hab ich gesehn)

Na ja, bei mir ist _an dieser Stelle_ tatsächlich nur der Stromzähler, da macht "mehr Power" oder ein Display gar keinen Sinn.

ABER: Demnächst werde ich (hoffentlich) noch etwas Solarthermie in Betrieb nehmen (der Puffer ist endlich da). Und für diesen Zweck habe ich einen EPS32 mit LAN-Schnittstelle vorgesehen - die Thermie-Steuerung hat jedenfalls eine (u.a.) per Tasmota-Scripting auslesbare Schnittstelle...
(Im Endausbau soll aber der ESP die gesamte Heizungsanlage einschließlich der Junkers-Therme steuern, mal sehen, ob ich das hinbekomme... Das wird dann aber vermutlich kein Tasmota mehr. Wobei....)

ach ja das mit dem vorzeichen hatte ich zu anfang auch mal, aber nach dem ich den modul type auf generic (18) gestellt hatte wars danach weg. (der müsste fallback seitig bei dir auf "sonoff basic (1)" stehen)

Das mit dem Vorzeichen paßt schon, da hängt auf meiner Seite eine Solananlage dran, die grade mehr erzeugt als verbraucht wird . Daher auch die ganze Umstellung bzw. der Bedarf für zeitnahe Werte... Wenn Strom im Überfluss da ist und Heizbedarf besteht, kann der auch direkt da rein gehen .

[DasQ]

hehe danke das ich hier weiter OT mitschreiben darf.

also weil es mir keine ruhe lies und ich ja einen wemos mini im einsatz habe, meine sml-tasmota version von 2022 (v11) einen punkt "verwalte dateisystem" hatte und ich in der infomationen anzeige nur 1024kb zur verfügung hatte (weil ja für esp01 gebaut), habe ich nun noch eine version für den Wemos gemacht. (schachtelsätzekannichsupa )

[Sany]

@Beta-User
aus dem ersten Post von Dir lese ich, Du möchtest einerseits die Datenflut eindämmen und andererseits Fehlauslesungen nicht gesendet bekommen. Falsche Werte liest mein Tasmota auch aus, keine Ahnung ob das am Script oder in der Natur des Sache liegt. Was ich für mich realisiert habe ist folgendes:
- der tasmota kennt die Uhrzeit
- ich lese sekündlich die Zählerdaten aus (Zählerstände, nicht den Powerwert) Dann wird gecheckt, ob der Wert ok ist, falls nicht (im Moment noch) lasse ich den in ein Error-Reading publishen, man möchte die möglichen Fehler ja kennenlernen.
- ich erhöhe jede Sekunde einen Zähler.
- beim Minutenwechsel publische ich einerseits die Zählerstände, andererseits wird die Differenz der Zählerstände mit dem Sekundenzähler verrechnet und als Power-wert für diese Minute gepublished.
- in fhem mache ich noch zeitgleich eine Abfrage vom Wechselrichter und habe am Ende innerhalb der ersten paar Sekunden nach einem Minutenwechsel die Power-Werte für Bezug, Einspeisung und Erzeugung und kann dann einen validen Wert für den Verbrauch des Hauses errechnen.
Final brauchts die Zählerstände um die Verbrauchswerte für Tag/Monat/Jahr etc zu rechnen und zu plotten, die Powerwerte sind eigentlich nur zur Anzeige, so erstellt allerdings auch irgendwie valide verglichen mit wild sich ändernden Power-Werten direkt vom Zähler.
Ob das in den ESP-01 passt, keine Ahnung. Käme auf einen Versuch an.

Bei Interesse schreib mich an, ich müsste mein Script erst von den anderen Sachen, die es noch macht, bereinigen.

Gruß


Sany

[DasQ]

hatte ich wie gesagt auch ... sinnigerweise in den letzten log files nicht mehr. (immer wenn man ein sporadischen fehler braucht, gibt es ihn nicht mehr Fu**)

btw. hier ein stückchen aus der tasmota manual

Meter Definition~

    +<M>,<rxGPIO>,<type>,<flag>,<parameter>,<jsonPrefix>{,<txGPIO>,<txPeriod>,<cmdTelegram>}

<flag> ... - 16 - enable median filter for that meter. Can help with sporadic dropouts, reading errors (not available for counters). this option is enabled by default #define USE_SML_MEDIAN_FILTER, if you are low on memory and dont use this feature you may outcomment this define in the driver

vielleicht hilft ja das?

[Beta-User]

So, nochmal vielen Dank für eure Rückmeldungen!

Vorläufige Fassung des scripts:

Code Auswählen Erweitern

>D
M:pavg=0

>B
=>sensor53 r
;disable publishing at MQTT teleperiod, on boot
smlj=0
>S
;re-enable publishing at MQTT teleperiod, after 10 seconds of uptime
if upsecs>10
then
smlj|=1
endif

; add to moving average filter
pavg=sml[3]

; publish power every teleperiod/20 time (default result: 15 sec)
if mqtts>0
and upsecs%(tper/20)==0
then
; just publish power value
=>Publish tele/%topic%/SENSOR {"Script":{"power":%0sml[3]%,"p_avg":%0pavg[-2]%}}
endif
>M 1
+1,3,s,20,9600,E320
1,77070100020800ff@1000,Total Delivered,kWh,Total_out,3
1,77070100010800ff@1000,Total Consumed,kWh,Total_in,3
1,77070100100700ff@1,Current power,W,Power_in,0
1,77070100600100ff@#,Server-ID,,Meter_Number,0
#

Anmerkungen: Ob es überhaupt Lesefehler usw. gibt, weiß ich (noch) nicht. Das, was bisher an Werten zu sehen war, sah ziemlich plausibel aus, und auch das, was (seit kurzem) per moving average vom ESP geliefert wurde.
Generell gefällt mir der Ansatz, diese Standardaufgaben vom ESP lösen zu lassen und an FHEM dann eben nur die verdichteten Infos zu pushen.

Sehr cool finde ich auch, dass man direkt sieht, was so ein script (grade) macht. Von daher bin ich echt grade am Überlegen, ob das nicht doch ein relativ einfach zu debuggender Ansatz für meine Heizungssteuerung ist.

Weiß jemand auf die Schnelle, ob das Auslesen von DS18B20 nonblocking ausgelegt ist und wie oft die ausgelesen werden (das scheint allgemein vom publish entkoppelt zu sein)?
Wenn es dann noch fertige bin-files mit scripting und ESP32 incl. LAN (!) gäbe, würde ich wohl mal den Versuch unternehmen...
Außer, dass das ziemlich speicherhungrig zu sein scheint, sehe ich im Moment keine Nachteile.

[DasQ]

Wenn mir erklärst was nonblocking ist, ich hab 10 DS18B20 an nem ESP32 mit espeasy hängen.

So eben kurz nachgelesen aber noch nicht verstanden was das Problem ist. Geht's um schnelles auslesen? Das klappt mir ein paar aussetzten bis zu 1 Sekunde. Aber Temperatur ist für gewöhnlich langsamer.

[Beta-User]

Wenn mir erklärst was nonblocking ist, ich hab 10 DS18B20 an nem ESP32 mit espeasy hängen.

Also - kurzer Exkurs zu DS18x20:
Um von denen eine Temperatur zu bekommen, muss der Ablauf "Bitte messen" - "warten" - "auslesen" sein, wobei die Dauer von "warten" von der gewünschten Auflösung abhängt. Jetzt kann man wirklich "warten" (=>blocking), oder eben zwischenzeitlich was anderes tun und später den Auslese-Code ausführen (=>nonblocking).

Wenn ich das ab https://github.com/arendst/Tasmota/blob/master/tasmota/tasmota_xsns_sensor/xsns_05_ds18x20.ino#L497 korrekt interpretiere, ist das (wenig überraschend) nonblocking ausgelegt, wobei ziemlich häufig gemessen wird (?), nämlich jeden 2. (?) Durchlauf (also alle 2 Sekunden). Ist eigentlich deutlich mehr, als ich brauche, aber andererseits auch nicht optimal, weil wohl jeder Sensor beim Auslesen 12ms benötigt. Das sind bei geschätzt 10-15 Sensoren (muss mal nachzählen...) dann immerhin schon knapp 15-20% der in jedem 2. Durchlauf verfügbaren Zeit...

Zum Vergleich: meine aktuelle MySensors-Heizungsnode (ATMega32) liest einen Sensor alle 10 Sekunden aus, die restlichen (6?) alle 30 Sekunden oder noch seltener. Die hat aber praktisch auch wenig anderes zu tun...

[DasQ]

weil ich gerade über ein hübsches template gestolpert bin, dacht ich mir ich zeigs dir

https://ottelo.jimdofree.com/stromz%C3%A4hler-auslesen-tasmota/