einen offset kannst du einfach per + addieren (hier 2000)
es wird zuerst der offset addiert und danach skaliert, also +2000 / 1000 im Beispiel
1,77070100010800ff@1000+2000,HWR_Pow_Bezug,kWh,HWR_Pow_Bezug,4
einen offset kannst du einfach per + addieren (hier 2000)
es wird zuerst der offset addiert und danach skaliert, also +2000 / 1000 im Beispiel
1,77070100010800ff@1000+2000,HWR_Pow_Bezug,kWh,HWR_Pow_Bezug,4
du solltest counter am besten im IRQ mode betreiben (-50)
+1,13,c,0,-50,Zähler3
muss mit allen esp8266 funktionieren.
wie karoCB schon gesagt hat solltest du die Daten im ESP speichern. Allerdings macht das eigentlich nur Sinn mit einer SD Karte da das Flash Filesystem viel zu wenig Speicher hat. Scripting hat dafür eine eigene Datenbank integriert. Ist aber für Anfänger etwas kompliziert.
Früher hatte ich alles auf IOBroker aufgelegt mit Raspberry. Inzwischen habe ich alles auf ESP umgestellt inklusive Grafiken und beliebiger Auswertung.
Alle Verbrauchswerte des Hauses werden alle 15 Minuten in die Datenbank geschrieben. Ein zentraler ESP32 sammelt die Daten von 7 Zählern ein anderer
stellt eine Webseite mit den Auswertungen zur Verfügung. Dort kann ich Tagesprofile jedes einzelnen Tages grafisch anzeigen, sowie Wochenprofile und Jahresprofile als Grafik und Tabelle. Die Tabelle wird jeden Monat einmal per email an mich geschickt als Backup.
Auf Tasmota docs habe ich einige Screenshots gelegt: https://tasmota.github.io/docs/Scripting-Language/
ein anderer User speichert die Daten so wie ich auf SD Karte und so wie karoCB das auch vorgeschlagen hat liest dann mit Excel automatisch die Daten aus und zeigt dann mit Excel Macros die Auswertungen an.
kompiliere mit
#define USE_SML_SCRIPT_CMD
dann kannst du die Variablen mit sml[L] L = decoder Zeile 1 ... N
abfragen
allerdings sollte die Abfrage in >T auch funktionieren.
Sieh dir deine JSON Strings in der Konsole an, dort solltest du sehen wie die Variable heisst.
die richtige Abfrage Syntax wäre aber ohnehin so:
p=WebQuery#meters[0]#power
eventuell geht das ja
oder versuch ob du den Wert in Klammer in einen String einlesen kannst
str=WebQuery#meters[0]
und analysiere dann den String weiter
dieser JSON string ist etwas ungewöhnlich und wird vom Standard script parser nicht unterstützt.
Versuchs mal in user_override mit
#define USE_SCRIPT_FULL_JSON_PARSER
bin nicht sicher aber damit könnte es gehen.
ok werde das wohl besser mit einem Simulator erst mal testen. Bin jetzt ein paar Tage mit anderem beschäftigt. Melde mich dann noch mal mit einer neuen Version.
ok Fehler gefunden
erst mal einfach im override
#define MAX_METERS 5
definieren dann läuft es durch.
nein, die so1 Zeile ist eine extra Zeile die irgendwo dazwischen eingetragen wird. sie erzeugt selbst keinen Output
Hi apos
Freut mich das jetzt geht. Da es jetzt schon mehrere Zähler sind die diese merkwürdige Eigenschaft haben habe ich das jetzt so gelöst dass man keine individuelle Compileroption mehr braucht.
du gibts einmal USE_SML_SPECOPT als define an nicht dein DTZ541
dann kannst du im descriptor diese spezielle Zeile einbauen (special option 1)
1,=so1,00010800,65,11,65,11,00100700
als erstes der obis code der das Richtungsbit mitbringt
danach das Hex byte das das Flag enthält, bei dir 65 bei anderen mal 62 oder 63
du musst das einfach 2 mal angeben da es bei dir beide mal die 65 ist
danach die Bit Nummer des Richtungsbits.
und zuletzt der Obiscode der invertiert werden soll, ist auch bei anderen Zählern ein anderer.
da ich keinen solchen Zähler habe wäre es nett wenn du es mal testen könntest.
Gruß
Gerhard
wenn du einen Tasmota counter anzeigen willst dann entweder den JSON Payload aus MQTT auslesen
>T
a=Counter#C1
oder besser irgendwo im script pc[1] liest den Pulsecounter 1 aus.
hab mich wohl beim Byteoffset vertan. denke diese version sollte funktionieren.
nein der code 65 ist ein Status Flag mit 32 bit im obis code 010800
der Zählerwert selbst kommt dann später in der Zeile
der aktuelle Verbrauch wird dann in Abhängigkeit dieses einen Stausbits in Zukunft invertiert, also negativ angezeigt wie es 95 Prozent der Zähler auch von selbst machen.
trotzdem weis ich nicht welches innerhalb der grünen Hex Zahlen das Export bit ist.
deshalb einfach einen Dump vom Obis Code 010800 einmal beim Import und einmal beim Export
dann kann man sehen in welchem der 4 Byte das Bit umspringt.
bit 11 muss in jedem Fall in einem der mittleren Bytes liegen also in 1d 19
bei anderen Zählern springt aber auch noch die Status Code Kennung um also z.B. von 62 auf 63
da ich die 65 abfrage muss ich sicher sein dass die bei Import und Export auf 65 bleibt.
kannst du einen dump mit verbrauch und Einspeisung machen damit man den Unterschied sehen kann.
weis nicht wo das Bit 11 sein soll, also von wo aus die bits zählen sollen.
also obis code 010800 und dann nach der 65 die nächsten 4 bytes
du kannst noch statt AS2020 ED300L versuchen.
das sind die beiden Zähler die diesen merkwürdigen Modus verwenden die bisher berücksichtigt sind.
dabei nutzen sie aber unterschiedliche Bits.
eventuell ist dein Zähler noch mal anders.
welches bit in welchem OBIS Kode ändert sich bei Einspeisung ?
Ich kann das dann nachprüfen und eventuell einbauen
versuch mal mit dem ganz aktuellen Tasmota und dem zusätzlichen define
#define AS2020
Dieser Zähler verwendet auch diese Kodierung
Grüße
der C3 war noch nicht im Treiber berücksichtigt ( der hat nur 2 UARTs statt 3)
Hier der Patch:
die Systemvariablen sunrise, sunset sind in Minuten nach Mitternacht, ebenso wie time
du vergleichst also ganz einfach
>D
tag=0
>S
if time>sunrise
and time<sunset {
; wir haben Tag
tag=1
} else {
; wir haben Nacht
tag=0
}
if chg[tag]>0 {
; Tag Nacht Wechsel
if tag>0 {
->DisplayDimmer 20
} else {
->DisplayDimmer 1
}
}
danke das hat funktioniert! mit einem App Passwort geht es jetzt auch bei gmail wieder
da die Oleds so günstig sind kann man sie auch jedes Jahr austauschen
Die Änderung in support.Ino werde ich beim nächsten PR einbauen