A1763 Anker C1000 Gen2

[DreamScout]

Hi.
I tried since days to find out the right Code with Chatgpt and Co-Pilot.
This are the results. But i dont know how to test it.
Is it possible to activate and deactivate DC and AC?

This are the results from ChatGPT.

{
  "soc":      { "block": "a5", "index": 2, "scale": 1.0 },
  "temp":     { "block": "a5", "index": 0, "scale": 1.0 },

  "ac_output_w": { "block": "a6", "index": [0,1], "scale": 0.2 },
  "ac_on":       { "block": "a7", "index": 0, "type": "bool" },

  "ac_input_w": { "block": "a4", "index": [6,7], "scale": 1.0 },

  "dc_on":       { "block": "a7", "index": 0, "type": "bool" },
  "dc_power_w":  { "block": "a7", "index": [1,2], "scale": 0.2 },

  "usb_a_w":     { "block": "ab", "index": [0,1], "scale": 1.0 },
  "usb_c1_w":    { "block": "ac", "index": [0,1], "scale": 1.0 },
  "usb_c2_w":    { "block": "a8", "index": [0,1], "scale": 0.1 },
  "usb_c3_w":    { "block": "aa", "index": [0,1], "scale": 0.1 },

  "display_on":  { "block": "f9", "index": 0, "map": { "08": true, "05": false } },

  "charge_limit":   { "block": "a5", "index": 3, "scale": 1.0 },
  "discharge_limit": { "block": "d9", "index": "dynamic", "scale": 1.0 },

  "fast_mode": { "source": "cmd17", "type": "flag" },
  "eco_mode":  { "source": "cmd17", "type": "flag" }
}

This is a Decoder build with Co-Pilot KI.
The AC and DC Status, Temperature, SOC and AC Watt is working and i see it in Home Assistant.

def decode_a1763(data):
    blocks = parse_blocks(data)
    print("\n--- DEBUG AUSGABE ---")
    print("Rohdaten (Hex):", " ".join(f"{b:02x}" for b in data))
    print("Gefundene Blöcke und deren Bytes:")
    for block_id, block_data in blocks.items():
        print(f"  Block {hex(block_id)}: {[f'{b:02x}' for b in block_data]} (Länge: {len(block_data)})")
    print("---------------------")
    if 0xa5 in blocks:
        print("Block a5 Bytes:", [f"{b} (dez) / {b:02x} (hex)" for b in blocks[0xa5]])
    if 0xa7 in blocks:
        print("Block a7 Bytes:", [f"{b} (dez) / {b:02x} (hex)" for b in blocks[0xa7]])
    if 0xa8 in blocks:
        print("Block a8 Bytes:", [f"{b} (dez) / {b:02x} (hex)" for b in blocks[0xa8]])
    if 0xb2 in blocks:
        print("Block b2 Bytes:", [f"{b} (dez) / {b:02x} (hex)" for b in blocks[0xb2]])
    result = {
        'soc': 0,
        'temperature': 0,
        'ac_out': 0,
        'ac_status': 0,
        'solar_in': 0,
        'usb_a': 0,
        'usb_c1': 0,
        'usb_c2': 0,
        'usb_c3': 0,
        'dc_status': 0,
        'dc_out': 0
    }
    if 0xa5 in blocks and len(blocks[0xa5]) > 2:
        result['soc'] = blocks[0xa5][2]
    if 0xa5 in blocks and len(blocks[0xa5]) > 0:
        result['temperature'] = blocks[0xa5][0]
    if 0xa7 in blocks and len(blocks[0xa7]) > 1:
        result['ac_out'] = blocks[0xa7][1]
    if 0xa7 in blocks and len(blocks[0xa7]) > 0:
        result['ac_status'] = blocks[0xa7][0]
    if 0xa6 in blocks and len(blocks[0xa6]) > 9:
        result['solar_in'] = blocks[0xa6][9]
    if 0xaa in blocks and len(blocks[0xaa]) > 1:
        result['usb_a'] = blocks[0xaa][1]
    if 0xab in blocks and len(blocks[0xab]) > 1:
        result['usb_c1'] = blocks[0xab][1]
    if 0xac in blocks and len(blocks[0xac]) > 1:
        result['usb_c2'] = blocks[0xac][1]
    if 0xae in blocks and len(blocks[0xae]) > 1:
        result['usb_c3'] = blocks[0xae][1]
    # DC-Status: Block b2, erstes Byte
    if 0xb2 in blocks and len(blocks[0xb2]) > 0:
        result['dc_status'] = blocks[0xb2][0]
    # DC-Ausgang (Watt): Block a8, zweites Byte
    if 0xa8 in blocks and len(blocks[0xa8]) > 1:
        result['dc_out'] = blocks[0xa8][1]

[thomluther]

Hi, not sure what you are trying to build here.
You can contribute by starting with the mqtt_monitor tool from the Api library and follow the #222.

[thomluther]

So the question is how AI should reliably match the fields to names for your specific device type?
Is that hallucination or do you have references with decoding examples for the field names?

[thomluther]

What I still need for code development and testing is a full randomized System export including MQTT messages as zip file.

[DreamScout]

The System Export Zip is ready. How can i send you the file?

[thomluther]

just attach it here, its randomized

[DreamScout]

c1000gen2_2025-12-02_0956.zip

[thomluther]

Thanks.
I just noticed that the new commands share the same message type, e.g. 0103 for various settings. They just use different byte fields depeding on the setting. That does not fit to the current description schema, which is built on the assumption that each command uses its own message type...
What a crap....I don't know how to resolve that for the command descriptions, since the message type is a unique field in the descriptions...

[thomluther]

OK, I spent the whole day to make required changes to support the new timestamp formats and also description for multiple commands per message type.
It will blow up the MQTT map even more, but that's the way it is. It seems the Gen 2 messages use lots of strb fields. That has the advantage to have multiple values per field, but it makes the decoding more difficult since there is no help from the decoder.
You have to recognize the byte positions for a value, and for multibyte values you have to consider opposite order for conversion (little endian, or least significant first). So if the value byte follows a 0 byte you don't know whether it belongs to the value.
Typically values never larger than 255 use 'ui' type, 2 byte values is 'sile' type, and 4 byte values are probably sfle for a float value.
I'm not sure if your descriptions above are all correct, I tried to merge that all and compare the extracted values with your exported messages. But your USB port order for the byte fields may be screwed up?

Most of my descriptions are questionable to me, because the messages had lots of 0 values. You will have to compare that while ports and sockets have corresponding power values or changing states, when you compare the decoded messages and extracted values with the App live values. You can follow that on the value view once the fields are described with a name.
At least you now have a template now that you can start enhancing.
A1763_0421

That template is the same for 0421 and 0900 messages, those message types seem to have the same format.
The first commands are also described for the device, you can complete them in same format.

Having nested commands per message makes the command composition from the description more difficult. But better to consider this now, than after those routines have been developed and just then comes a new format. So fortunately I did not start with that framework yet, until I have a better overview about existing commands.
Therefore it will be good if you describe all commands or post decoded examples here with value options.

Important to know is also if you see regular messages, without any realtime trigger? I don't think the 0900 is regular from the intervals I found in the export. Maybe there is one even less frequently.

The problem is, that without regular status message you are always forced to either trigger realtime data, or find a command for one time status request, that can be automated as desired (via HA for example)

If you can trigger a single status message request with the new status request option of the mqtt_monitor, you can validate that.
It uses old format 0040, maybe the device responds with a single status.
Likewise, which realtime trigger commands do you see while RT is inactive in the monitor?
Format 0057 messages or maybe also 0040 from the App?

Last but not least: When you name the values, re-use the namings as defined for C1000 model. Unique names are only to be used for unique functions between the 2 models (or basically across all devices). For that reason and existing Api value I also change ac_charge_limit to ac_input_limit for the state descriptions in the 'ac_charge_limit' command.

[DreamScout]

My actual Mqttmap with some changes. I have deleted the question marks in the MQTT map from the things that are working.
mqttmap.py

[DreamScout]

with an other debug decoder (KI Created) Chatgpt say the AC_INPUT_ and AC_OUTPUT is visible because the decoder is reading everything. Inluded the 0900 block. Chatgpt can identifiy the AC_INPUT here -> 0900: 23 02 61 64 ...
Dont know. May Chatgpt get crazy like me ;)

[thomluther]

I uploaded the new version, the 'length' field should no longer be required, unless the strb fields contain strings with fixed length, then it must specified. If first byte contains length, it not needed either.

If you need to find a value, convert it from Dec to Hex, then reverse the bytes and search for that pattern. If the value contains a factor, it is more difficult since the bytes may be signed float conversion in reversed order (4 byte values).

[thomluther]

My next problem is that I don’t know how to execute these commands to control the power station. Where exactly do I need to enter them, and do you have an example for me?

They cannot. All commands have to be described first from the commands sent by the app.
Once I have better overview about a greater command set across the devices, I have to develop a generic command composed from the description structure, that can also validate the parameters of the commands according description.
Once this is done, the command function can be implemented into the normal monitor tool, that can then also display directly the resulting states in the data.

You can use the monitor already to display most of the extracted values, that are utilized by the library (validated,defined names only, so only a subset of the MQTT cache data is used by the device).

[thomluther]

with an other debug decoder (KI Created) Chatgpt say the AC_INPUT_ and AC_OUTPUT is visible because the decoder is reading everything. Inluded the 0900 block. Chatgpt can identifiy the AC_INPUT here -> 0900: 23 02 61 64 ...
Dont know. May Chatgpt get crazy like me ;)

If you send me the hex message and the missing values that I should look for, I can maybe find their patterns with some manual effort.
I'm afraid you may have to look for 4 byte combinations and use signed float conversion from little endian byteorder.
If the converted value comes close to the search value (consider also factors for the decimals), then you found your 4 byte pattern...

[thomluther]

you can also test a combination of various start bytes for the value, just described each option with a different name and look for the extracted value that may match

    "a6": {
        "bytes": {
            "05": {
                "name": "output_power_total_1?",  # OUTPUT POWER TOTAL
                "type": DeviceHexDataTypes.sile.value,
            },
            "06": {
                "name": "output_power_total_2?",  # OUTPUT POWER TOTAL
                "type": DeviceHexDataTypes.sile.value,
            },
            "07": {
                "name": "output_power_total_3?",  # OUTPUT POWER TOTAL
                "type": DeviceHexDataTypes.sile.value,
            }
        },
    },

which gives on one of the messages:

  "output_power_total_1?": -21760,
  "output_power_total_2?": 10923,
  "output_power_total_3?": 25642,

So I guess 2 or 3 are candiates with factor 0.01 depending what the value actually was...

[thomluther]

Raw Data Proof:

1. **Fast Charge ON:**
   Timestamp: 17:11:23
   Raw Hex: `... a4:1b:04: ... 00:00:00:00:00:`**`01`**`:00:64:01:03`
   -> Byte at Offset 20 is `01`.

2. **Fast Charge OFF:**
   Timestamp: 17:11:29
   Raw Hex: `... a4:1b:04: ... 00:00:00:00:00:`**`00`**`:00:64:01:03`
   -> Byte at Offset 20 is `00`.

That is what I need, but again AI did cut off the proof part. Offset from where? I need the offset from the value part of the field, start counting at 00.
Anyway, forget the Fast charge state byte, that is described already at '20', see previous comment

[DreamScout]

1. AC OUTPUT SWITCH (State Byte)

You asked for the byte reflecting the ac_output_power_switch setting.
From log CMD AC an aus.txt:

• Status Message: 04 21 (State Info)
• Field Tag: a7 (Binary Struct)
• Byte Offset: 0 (The very first byte of payload)
• Values: 00 = OFF, 01 = ON.

Raw Proof:
OFF: a7:07:04:00:00:00:00:00:00
ON: a7:07:04:01:00:00:00:00:00

2. DC OUTPUT SWITCH (State Byte)

You asked for the byte reflecting the dc_output_power_switch.
From log CMD DC Energiesparen.txt:

• Field Tag: b2
• Byte Offset: 0
• Values: 00 = OFF, 01 = ON.

Raw Proof:
OFF: b2:04:04:00:00:00:00
ON: b2:04:04:01:30:00:00 (Byte 1 changes too, likely load)

3. DISPLAY SWITCH (Command & State)

• Command (Toggle): Message 01 03, Tag a2. (Value 0/1).
• State Byte: Found in Field a4 (Msg 0421), Byte Offset 22.
  • 00 = Display Off
  • 01 = Display On
    (See log CMD Bildschirm ein aus.txt)

4. DISPLAY TIMEOUT (State Bytes)

• State: Found in Field a4, Byte Offsets 16-17 (Little Endian UInt).
  • Validated values: 10, 30, 60, 300, 1800 (Seconds).

5. FAST CHARGE (Command & State)

• Command: Message 01 01, Tag a7 (Value 0/1).
• State: Found in Field a4, Byte Offset 20.
  • 00 = Normal
  • 01 = Fast Charge

6. DC INPUT vs OUTPUT

You asked about DC Input. The command 01 02 Tag a4 definitely toggles the DC Output (Car Socket).
The DC Input (Solar) does not have a switch in the App (it's always active when sun shines).
Field a8 in the status message (0421) seems to reflect DC Input status/power (dc_input_power_switch at Offset 0), but I haven't found a command to toggle it.

SUMMARY OF FIELD a4 (Status 0421)

This single field contains almost all configuration states:

• Offset 4-5: AC Input Limit (Watts)
• Offset 7: DC Energy Saving Mode (0/1)
• Offset 11: AC Smart Mode (0/1)
• Offset 16-17: Display Timeout (Seconds)
• Offset 20: AC Fast Charge Status (0/1)
• Offset 22: Display Switch Status (0/1) (Correction: Might be Memory Switch? Need to double check if 22 is Memory or Display. In my logs it toggled with Display).

[thomluther]

• Offset 22: Display Switch Status (0/1) (Correction: Might be Memory Switch? Need to double check if 22 is Memory or Display. In my logs it toggled with Display).

That is the big question, because you confirmed previously byte 22 is port memory switch state, now it suddenly is Display switch state.
So what is valid?

[thomluther]

• Offset 16-17: Display Timeout (Seconds

Definitely wrong. I found that in your logs to be 15 and 16, see comment

            "15": {
                "name": "display_timeout_seconds",  # 0 (Never), 10, 30, 60, 300, 1800
                "type": DeviceHexDataTypes.sile.value,

Quite bothering the AI answers, only making confusion and different summaries and keeping me busy all day to validate.

[DreamScout]

maybe i should give you the onedrive link with all my dumps? and if you need some i put it in there?

[thomluther]

OK, mein letzter Versuch die fehlenden Infos zu bekommen, ich hoffe du kannst mir diese Infos geben ohne deine KI bemühen zu müssen, die eh nur Verwirrung und unötige Arbeit macht. Das nervt mich gerade extrem um ehrlich zu sein....

1. Ich brauche MQTT log files von dir wo du jeweils nur eine Sache umschaltest. Die scheinst du ja schon zu haben wenn du die KI damit fütterst. Es muss klar sein, was jeweils von dir umgestellt wurde. Dann suche ich mir die Bytes selbst aus den Logs. Folgende Kommandos fehlen noch:

• DC Ausgangsschalter: Frage hierzu: Gibt es nur einen Schalter für alles an DC, oder getrennte für die USB ports und 12V. Falls getrennt, brauche ich die Logs von beiden getrennt
• Gibt es einen DC Input Schalter? für 12V oder PV Eingang bzw Laden? Dann brauche ich auch das Log davon
• Display Schalter
• Display Mode (Helligkeit)
• Geräte Zeitabschaltung (Timeout)

2. Ich brauche die erlauben Werte in der App für:

• min SOC von - bis?, 1 oder 5 % Schritte einstellbar?
• max SOC von - bis?, 1 oder 5 % Schritte einstellbar?

[DreamScout]

DC Ausgangsschalter: Nein nur 1 Schalter!
Achtung! Beim aktivieren von DC oder AC wird der Bildschirm automatisch eingeschaltet!

CMD DC ein aus .txt

Gibt es einen DC Input Schalter? Nein! Solareingang hat keinen Schalter!

Display Schalter An / Aus
CMD Bildschirm ein aus.txt

Display Mode (Helligkeit) niedrig / mittel / hoch
CMD Displayhelligkeit niedrig mittel hoch mittel niedrig.txt

Geräte Zeitabschaltung (Timeout) Funktionen: nie, 24h, 12h, 6h, 4h, 2h, 1h, 30 min
CMD Geräte-Timeout .txt

min Soc 1%, 5%, 10%, 15%, 20%
max SOC 100% 95%, 90%, 85%, 80%
cmd LadeundEntladegrenzen 1%5.10.15.20.95.90.85.80%.txt

Bei allen Logs nur 1nes geschaltet! Bei gewissen Funktionen werden aber Display und AC und DC kurz geschaltet laut Logs aber nicht wirklich aktiviert. Ich kann das auch gar nicht sehen ob da irgendwas aktiviert wurde da die Einstellungen und AC,DC und Bildschirm auf verschiedenen Seiten der App sind. Hören an Schaltvorgängen kann ich aber nichts.

Sorry das ich dich sauer mache aber wie gesagt ich versuche mein Bestes
Theoretisch wäre es genug für die meisten und für mich die Werte der Box zu haben und AC und DC schalten zu können.

Danke das du mir hilfst.

Jederzeit gerne mehr wenn du brauchst.

[thomluther]

Danke für die Logs, ich schau mir die an, dann kann ich auch mehr aus der Sequenz erkennen, was die App vielleicht zusätzlich schickt.
Könnte ja auch sein, dass eine Einstellung mehr als eine Kommandomessage triggert. Dann wäre die Frage, ob das wirklich mehrere sein müssen, (wie zum Beispiel dieses merkwürdige Limit Kommando, was statt einem Zeitstempel hat nur merkwürdige Bytes in FE hat.
Kann auch gut sein, dass es sich hier um einen Bug von Anker handelt, welcher eigentlich den Zeitstempel in ms nehmen soll für das FD Feld, diesen aber als Sekundenzeitstempel konvertiert und das FE benutzt. Bei einer Zahl die Faktor 1000 größer ist, kann dann so ein Mist rauskommen in Hex. Das würde aber auch bedeuten, dass der Zeitstempel im Kommando nicht wirklich von Bedeutung ist...
Also falls man solche Zusatzkommandos nicht braucht, ist es besser sie wegzulassen, zumal wir es eh nicht genau verstehen.

Das alles wird sich aber erst beim Testen zeigen, wie die Kommandos auch aus einem Monitor Tool abgesetzt werden können. Das dauert noch ein paar Wochen

Mir fällt gerade auf, das Log vom Port Memory Switch brauche ich auch noch, das gab es ja die KI Verwirrung um das Statusbyte.

[thomluther]

PS: Ich habe interessahalber das FE Feld in einem 0100 Kommando mal umgerechnet:

fe   04  23    8c:2e:69
└->   4 unk         b'\x8c.i'

23:8c:2e:69 sind 692e 8c23 in hex, das ergibt in Decimal einen Zeitstempel in ms:

Also benutzt das Kommando einen Zeistempel im neuen Format, schreibt es aber fälchlicherweise in 'FE' ohne Typ Byte, statt in FD als 'str' wie die anderen Kommandos das machen => Anker Bug, ist aber scheinbar egal.

[DreamScout]

Port Memory Switch? Was meinst du genau? Ich denke du meinst den Ausgangsport-Speicherschalter oder ;)
CMD Port Memory Switch aka Ausgangsport-Speicherschalter .txt

[thomluther]

Das ist beschrieben ja.
Aber es gibt noch kein Framework, welches die Kommandomessages erzeugt. Das wird noch ein paar wochen dauern, bis Kommandos getestet werden können.
Du kannst dir aber im normalen Monitor die Werte anschauen, sobald du MQTT messages aktiviert. Da sollten die meisten Settings zumindest dargestellt werden und auch Änderungen über die App.
Das hier ist ein Beispiel von einem System Export, den du hier mal reingehangen hast (anonymisiert)

================================================================================
Device [A1763] : SOLIX C1000 Gen 2       Alias          : SOLIX C1000 Gen 2
Serialnumber   : 6WPYSCSCKOX3F770I       Admin          : YES
Wireless Type  :                         Bluetooth MAC  : AAD797C1C3AC
Wifi SSID      : wifi-network-1          Wifi MAC       : CBABCDDEF560
Wifi State     : Online                  Signal         :   80 % (-57 dBm)
SW Version     : v1.1.2.6 (Latest)       Auto-Upgrade   : Unknown (OTA v1.1.2.6)
MQTT Device    : Disconnected            Subscription   : Inactive
Last Update    : 2025-12-02 08:52:06     Time Remaining : --:--
Display Ctrl   :  ON / Low (1)           Display Timeout:   30 Sec.
AC Out Ctrl    : OFF / Smart (0)         DC Out Ctrl    : OFF / Smart (0)
Battery SoC Tot:  100 %                  SoC Min/Max    :    1 % / 100 %
Battery SoC/SoH:  100 % / 100.00 %       Battery Temp.  :   23 °C
Backup charge  : ---                     Fast charge    : OFF
Port Memory    : OFF                     Energy Saving  : ---
Battery Energy : 1024 Wh                 Capacity       : 1024 Wh
Max. Load      : ---- W                  Device Timeout :    0 Min.
DC In Pwr Tot  :    0 W                  Charging Status: ---- (-)
DC Out Pwr Tot :    0 W                  DC Out Timeout : 0:00:00
AC Input Power :    0 W                  AC Socket Power: ---- W
AC Charge Power: ---- W                  AC Charge Limit:  100 W
AC Output Power:    0 W                  AC Out Tot/Off : ---- W / 0:00:00
USB-C 1 Power  :    0 W (inactive)       USB-C 2 Power  :    0 W (inactive)
USB-C 3 Power  :    0 W (inactive)       USB-C 4 Power  : ---- W
USB-A 1 Power  :    0 W (inactive)       USB-A 2 Power  : ---- W
================================================================================

Falls da noch irgendwas fehlt, oder eine Setting Änderung nicht angezeigt wird, gib mir Bescheid.

[thomluther]

Bevor ich die Kommandos angehe, muss ich aber erst noch die letzten Änderungen und Fixes für die HA integration machen und testen.
Also wird es dauern

[DreamScout]

Werd ich mal ausprobieren. Danke dir!

[DreamScout]

Hi.

Absolut für mich als Laien beindruckend das du das zum laufen gebracht hast.
Funktioniert top! Danke!
Aber..
Wenn ich den AC Smart Modus "AC-Ausgang-Smart-Modus" schalte dann ist wenn er aus ist im Monitor:
AC Out Ctrl : ON / Smart (0)
wenn ich ihn einschalte:
AC Out Ctrl : ON / Normal (1)
Ist das nicht vertauscht? Normal ist doch aus und Smart dann an?

Beim DC Out Ctrl das gleiche verhalten.
DC Out Ctrl : OFF / Normal (1) ist an und
DC Out Ctrl : OFF / Smart (0) is aus

Anschlüsse ohne Werte da es diese auch nicht vorhanden sind:
USB-C 4 Power, USB-A 2 Power

Was die übrigen Werte in weiß sein sollen hab ich auch nicht nachvollziehen können bzw. Werte bekommen.

[thomluther]

Was weiss ist, ist von der Api, das siehst du so evtl garnicht
Smart und Normal ist nur eine Übersetzung des Wertes. Da gibt es leider ein Konflikt zur Gen 1, die sagt 1 ist Normal und 2 ist Smart beim setzen, und der Zustand ist 1 Normal und 0 Smart....
Also genau umgekehrt wie bei Gen 2
Weiß nicht nicht wie ich das lösen soll.
Die Striche sind da, wenn es keine Werte gibt vom Gerät, also normal wenn du das nicht hast, oder wenn die Werte nicht beschrieben sind, bzw. extrahiert werden können aus den Daten.

[thomluther]

Hi @DreamScout
Hat die Gen 2 auch ein LED Licht, welches gesteuert werden kann wie die Gen1?
Wenn ja brauche ich davon auch MQTT dumps, damit ich das Kommando und das Setting beschreiben kann.

Das gleiche gilt für die Temperaturumstellung auf Fahrenheit. Sollte jedes Gerät haben was Temperaturen anzeigt denke ich.

[DreamScout]

Hi.
Ein gutes neues Jahr.
Ich bin leider seit Weihnachten beruflich unterwegs und habe keinen Zugriff auf die Box usw.
Bin ab 19.01. wieder zuhause.
Nein die Gen2 hat kein LED Licht. Aber interessant wäre es ob in den Dumps auch die Restlaufzeit der Entladung bzw. Ladung ersichtlich ist.
Melde mich wenn ich wieder zuhause bin.
Gruß

[thomluther]

Dito, bin auch im Urlaub.
Mit Sicherheit gibt es die Info in den Bytes, dafür brauchst du aber die genaue Dauer aus der App.
Der Mqtt Wert ist unterschiedlich, mal in h mit Faktor 0.1, oder in Minuten oder Minuten Intervallen, zB 6 bei 10 Minuten Intervall und 1h Dauer. Da müsstest du mehrere Vergleiche haben um die geänderten Felder zu Filtern und dann die Umrechnung des eigentlichen Wertes verstehen...