Ein
Channel hat grundsätzlich zwei Kommunikationsrichtungen.
In mqtt gibt es dafür immer zwei Topics, da die Kommunikation in mqtt grundsätzlich gerichtet ist (d.h. ein Topic ist zum lesen da, ein anderes zum schreiben).
Genauso gibt es Parameter, wie die Daten aufbereitet werden, also die
Incoming und
Outgoing Value Transformation sowie das
format before publish. Leider ist aus dem
format before publish in der UI das
Outgoing Value Format geworden, so dass man auch auf die Idee kommen könnte, das hätte etwas mit der Richtung nach openHAB zu tun (das ist nicht der Fall).
Da Du den Zähler nicht setzen willst, musst Du dieses Feld gar nicht berücksichtigen. Ich habe keinen Shelly, ich mutmaße mal, dass es sowieso keine Möglichkeit gibt, den Zähler gezielt zu setzen.
Anzeige in der UI: In der Itemliste wird das State Description Pattern nicht berücksichtigt, hier wird der Wert immer so angezeigt, wie er im Item vorliegt. In der Detailansicht des Items sollte das State Description Pattern verwendet werden. Im Analyzer sollte die Unit verwendet werden, d.h. letztlich der Wert, so wie er in der Itemliste angezeigt wird (denn dieser Wert wird durch die Unit des Items bestimmt).
Dass die Werte im Detail voneinander abweichen, kann ein Rundungsfehler sein. Im Analyze Bereich kommt es auch noch auf den verwendeten Persistence Service an, der eventuell selbst Rundungsfehler mit einbringt.
Dass die Anzeige nicht beeinflusst wird, kann ich nicht bestätigen, es kann aber z.B. gut sein, dass Du jeweils den Browser dazu zwingen musst, die Seite komplett neu zu laden (z.B. Firefox: <Ctrl>+<F5>), ansonsten könnten fehlerhaft Formatierungen aus dem Browser Cache verwendet werden.
Deine Formatierung
%0.f ist falsch.
Grundsätzlich ist das Format so definiert:
%[Index][Flags][Width][.Precision]Conversion. Die 0 ist kein gültiger Index, aber es gibt ein Flag "0". Das hat allerdings nur Auswirkungen, wenn auch die Width gesetzt ist, und zwar auf einen Integer Wert größer 0. Nach dem . muss zwingend ein Integer Wert stehen, der fehlt aber bei Dir. In der Folge wird die Formatierung eventuell komplett ignoriert. Die Conversion ist zwingend anzugeben, alle anderen Teilstrings sind optional.
Mutmaßlich möchtest Du die Nachkommastellen unterdrücken, das wäre dann
%.0f 
Du könntest z.B. auch mit %+05.2f erreichen, dass vor dem Dezimaltrenner immer
mindestens fünf Stellen ausgegeben werden und der Wert auf zwei Nachkommastellen gerundet wird. Hat die Zahl weniger als fünf Stellen, wird mit führenden Nullen gefüllt. Außerdem wird das Vorzeichen mit ausgegeben, auch wenn die Zahl positiv ist. Die 0 gehört ebenfalls zu den Flags.
Eine Liste aller möglichen Flags und überhaupt des Formatierunsstrings:
https://docs.oracle.com/javase/8/docs/a ... tml#syntaxopenHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
