muss anscheinend <-90 über <0 einfügen
Ja ich hatte beide Reihenfolgen von <0 und <-90 probiert. Aktuell:
{
"<-90": {
"borderfillcolor": "cyan"
},
"<0": {
"borderfillcolor": "magenta"
},
">0": {
"borderfillcolor": "blue"
},
">90": {
"borderfillcolor": "red"
},
">180": {
"borderfillcolor": "yellow"
},
">270": {
"borderfillcolor": "green"
}
}
und alles negative ist magenta.
Das hier funktioniert (abgesehen vom o.g. reverse-color-Problem):
{
"<-90": {
"borderfillcolor": "cyan"
},
">0": {
"borderfillcolor": "blue"
},
">90": {
"borderfillcolor": "red"
},
">180": {
"borderfillcolor": "yellow"
},
">270": {
"borderfillcolor": "green"
}
}
Setze ich
"<0": {
"borderfillcolor": "magenta"
},
davor, wird das anschliessende -90 cyan ignoriert.
Auch wenn ich probehalber die beiden negativen Bedingungen vertausche, bleibt es magenta.
@skb said in Test Adapter Energiefluss-erweitert v0.7.x GitHub/Latest:
@hardwarefehler Prima.
Wenn du möchtest, kannst Du einfach mal über Github drüber installieren.
Hiermit geübt. Install/github. Upload file. Reload website. Oh, neue Farbe 
Habe folgendes hinzugefügt:
- FIX: Override for bordercolor and borderfillcolor were not correctely applied on rect or circle
- Added: New line-end for filling outline according to value added. Can now be round, square and butt
- Added: Few language corrections
Wenns für Dich passt, kann ich es so lassen
Passt und hochpräzise geschnitten.
Allerdings funktioniert beim negativen raw-Wert zwar noch der Richtungswechsel, aber nicht mehr die andere Farbe "color for the other direction". Auch wenn ich den Overwrite komplett leer lasse.
Genaugenommen bräuchte man für den Richtungswechsel auch noch einen Overwrite-Schlüssel, also 'borderreversefillcolor'? edit: nein, borderfillcolor geht auch für negative Werte im Reverse.
Hatte ich dich in dem anderen Post richtig verstanden, das du die
valuevia Überschreibungen passend berechnen wolltest? Dies kann ich natürlich noch nachreichen.
Ja, ich will den Wertebereich 0...360° nach -180...+180° transponieren um besser mit den Einfärbungen im und gegen den Uhrzeigersinn arbeiten zu können.
Das Problem war, dass sich die Umschaltung des Uhrzeigersinns nach dem Raw-Wert richtet und nicht nach dem berechneten.
Workaround wäre, die Datenpunkte vorab umzurechnen.
Das www/js/functions.min.js zeigt im Github alles in einer Zeile, ist das gewollt? Das macht eine Diff-Anzeige und das Code-Verstehen schwierig.
@skb said in Test Adapter Energiefluss-erweitert v0.7.x GitHub/Latest:
Ich kann dort nur butt noch hinzufügen.
butt ist perfekt, funktioniert. (offenbar rendert Firefox dann bei einem ungültigen Wert auch keine linecaps, daher hatte es mit meinem spontanen none auch geklappt)
Ist für Füllstände dann auch präziser.
@skb
Ja am sinnvollsten wäre dann wohl, das none hier mit vorzusehen:
@hardwarefehler said in Test Adapter Energiefluss-erweitert v0.7.x GitHub/Latest:
Dort habe ich probehalber mal stroke-linecap: none gesetzt und siehe da, mein Problem mit den 0˚ ist gelöst. Bekomme ich das auch im Overwrite konfiguriert oder könnte man das none beim "end of line" im Menü hinzufügen?
Gibt es denn im Overwrite einen prinzipiellen Mechnismus, einen CSS-Wert gezielt einer bestimmten 'class' zuzuordnen?
Wenn ich versuche, die linecaps auf none zu setzen,
"default": {
"bordercolor": "cyan",
"borderfillcolor": "#ffffff",
"stroke-linecap": "none"
}
}
kommt das im HTML nicht an und bleibt square, wohl weil es der class="border_fill" nicht zugeordnet ist?
<circle cx="86" cy="86" r="50" class="border_fill" id="border_0" style="stroke: rgb(163, 154, 30); stroke-width: 6px; transform: rotate(270deg); stroke-dashoffset: 314px; stroke-dasharray: 314.159px; stroke-linecap: square;"></circle>
Mit 0.7.4 sollte ich meine Ringfärbungen wohl besser hier diskutieren.
{
"default": {
"bordercolor": "magenta",
"borderfillcolor": "#ffffff"
}
}
Meine Erwartungshaltung, dass der Ring jetzt magenta/weiss wird, erfüllt sich nur beim Untergrund, Füllung bleibt ocker. Auch im HTML:
<circle cx="86" cy="86" r="50" class="border_fill" id="border_0" style="stroke: rgb(163, 154, 30); stroke-width: 6px; transform: rotate(270deg); stroke-dashoffset: 314px; stroke-dasharray: 314.159px; stroke-linecap: none;"></circle>
Dort habe ich probehalber mal stroke-linecap: none gesetzt und siehe da, mein Problem mit den 0˚ ist gelöst. Bekomme ich das auch im Overwrite konfiguriert oder könnte man das none beim "end of line" im Menü hinzufügen?
@skb said in Support Adapter Energiefluss-erweitert v0.6.2:
Bei der Version ab 0.7.x (aktuell im latest) ist das Problem mit der negativen Füllung des Rahmens behoben.
Ja, das ist super. Ein original negativer Datenpunkt erzeugt jetzt die Gegenrichtung mit der Alternativfarbe. Wenn ich aber den negativen Wert im Override erzeuge, ändert sich nichts.
Wenn das so beabsichtigt ist, müsste ich die Datenpunkte vorher umrechnen, ansonsten auf den Bugfix warten.
Im textuellen Datasource-Element funktioniert die Umrechnung.
{
">=180": {
"value": "val => val - 360;"
}
}
v.0.7.4.: 
Vermutlich sollten wir ein neues Topic aufmachen zu den Kapazitätsbelägen von NYM-Kabeln im Eigenheim 
Momentan wäre mir schon geholfen zu klären, ob ich hinsichtlich des Richtungswechsels der Befüllung des Kreisringes bei negativen Werten etwas falsch konfiguriert habe oder ob ein Bug vorliegt.
Ich habe das Problem im vorigen Post mal etwas hervorgehoben.
@homoran said in Support Adapter Energiefluss-erweitert v0.6.2:
die größten kapazitativen Lasten von parallel laufenden Leitungen
Keine Schaltnetzteile im Haus? LED-Lampen?
