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

[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/