Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[OliverIO]

@jey-cee
Der Mechanismus von Iobroker jeden datenpunkt einzeln zu übertragen finde ich per websocket eigentlich schon effizient
Sonst müssten ja alle 500 Daten jedesmal auch wenn nur einer sich davon ändert in Summe übertragen werdeb

[OliverIO]

@homoran sagte in Performance-Vergleich VIS HTML Binding vs. JS:

Außerdem greift ein Binding in der vis auf die Ressourcen des meist deutlich schwächeren Frontends zu, während js auf dem Server läuft.

Das ist korrekt
Aber das muss er ausprobieren wieviel sein endgerät schafft.
So schlimm ist es mit dem binding jetzt auch nicht, aber bei 500
Und sekündlicher Aktualisierung könnte man zu Problemen kommen.

Es geht ja hier darum ihm evtl eine Menge Arbeit zu ersparen.
Wenn er es dennoch ausprobieren möchte dann gerne.

[joergeli]

@liv-in-sky
Die Leistungsdaten von "Energieverbrauch Haus" kommen über einen Hichi-Leskopf rein, d.h. über den Sonoff-Adapter.
Da greift dann die TelePeriod, welche ich auf 30 Sekunden eingestellt habe.

Bei den restlichen Leistungsdaten, die mittels Shelly-Adapter (COAP) ermittelt werden, kann ich es nicht sagen, da bei den Shellys ja meines Wissens nicht so etwas wie TelePeriod eingestellt werden kann.
"Gefühlt" werden diese Leistungsdaten aber sehr schnell aktualisiert.

[joergeli]

@picky
Anbei der Code für die linke obere Tabelle "Energieverbrauch Haus":

<style type="text/css">
table.energiehaus {
  font-family: Arial, Helvetica, sans-serif;
  /*background-color: #ebebeb;*/
      background-color: #fafafa;
  
  text-align: center;
  border-collapse: collapse;
  border: 2px solid #8a8a8a;
}
table.energiehaus td, table.energiehaus th {
  padding: 1px 8px;
}

table.energiehaus tbody td {
  font-size: 11px;
  font-weight: normal;
  color: #330F1A;
}
table.energiehaus tr:nth-child(even) {
  /*background: #dddddd;*/
    background: #EEF0F3;
}
table.energiehaus thead {
  background: #eaeaea;
  border-bottom: 1px solid #8a8a8a;
}
table.energiehaus thead th {
  font-size: 11px;
  font-weight: bold;
  color: #bb0000;
  text-align: center;
  border-left: 1px solid #8a8a8a;
}
table.energiehaus thead th:first-child {
  border-left: none;
}
  
.gesamt {
  background-color: #ffe4c4;
  color: kWhite;
  border: 1px solid black;
} 
  
.borderlinks {
  border-left: 1px solid #8a8a8a;
} 


  

</style>


<table class="energiehaus">
<thead>
<tr>
<th colspan="4">Energieverbrauch Haus</th>
</tr>
<tr>
<th colspan="2">Woche</th>
<th colspan="2">2022</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Montag</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.currentYear.delivered.currentWeek.01_Monday} kWh</td>
<td align="left" class="borderlinks">Jan</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.2022.delivered.months.01_January} kWh</td>
</tr>
<tr>
<td align="left">Dienstag</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.currentYear.delivered.currentWeek.02_Tuesday} kWh</td>
<td align="left" class="borderlinks">Feb</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.2022.delivered.months.02_February} kWh</td>
</tr>
<tr>
<td align="left">Mittwoch</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.currentYear.delivered.currentWeek.03_Wednesday} kWh</td>
<td align="left" class="borderlinks">Mrz</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.2022.delivered.months.03_March} kWh</td>
</tr>
<tr>
<td align="left">Donnerstag</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.currentYear.delivered.currentWeek.04_Thursday} kWh</td>
<td align="left" class="borderlinks">Apr</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.2022.delivered.months.04_April} kWh</td>
</tr>
<tr>
<td align="left">Freitag</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.currentYear.delivered.currentWeek.05_Friday} kWh</td>
<td align="left" class="borderlinks">Mai</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.2022.delivered.months.05_May} kWh</td>
</tr>
<tr>
<td align="left">Samstag</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.currentYear.delivered.currentWeek.06_Saturday} kWh</td>
<td align="left" class="borderlinks">Jun</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.2022.delivered.months.06_June} kWh</td>
</tr>
<tr>
<td align="left">Sonntag</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.currentYear.delivered.currentWeek.07_Sunday} kWh</td>
<td align="left" class="borderlinks">Jul</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.2022.delivered.months.07_July} kWh</td></tr>
<tr>
<td align="left"></td><td align="right"></td>
<td align="left" class="borderlinks">Aug</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.2022.delivered.months.08_August} kWh</td>
</tr>


<tr>
<td align="left"></td><td align="right"></td>
<td align="left" class="borderlinks">Sep</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.2022.delivered.months.09_September} kWh</td>
</tr>
<tr>
<td align="left"></td><td align="right"></td>
<td align="left" class="borderlinks">Okt</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.2022.delivered.months.10_October} kWh</td>
</tr>
<tr>
<td align="left"></td><td align="right"></td>
<td align="left" class="borderlinks">Nov</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.2022.delivered.months.11_November} kWh</td>
</tr>
<tr>
<td align="left"></td><td align="right"></td>
<td align="left" class="borderlinks">Dez</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.2022.delivered.months.12_December} kWh</td>
</tr>

<tr class="gesamt">
<td align="left">Woche</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.currentYear.delivered.02_currentWeek} kWh</td>
<td align="left" class="borderlinks">Jahr</td><td align="right">{sourceanalytix.0.sonoff__0__IR-Lesekopf__Strom_total_in.2022.deliveredCumulative} kWh</td>
</tr>
</tbody>
</tr>
</table>

Hinweis:
Ich bin nicht so der HTML/CSS-Crack und habe mir das Ganze mit Try & Error zusammengefrickelt.

Wenn mehrere Tabellen im gleichen View verwendet werden, muß man darauf achten, daß in den CSS-Definitionen für jede Tabelle jeweils andere Namen verwendet werden ( wie z.B. table.energiehaus , table.pv, etc.).

Die Tabellen habe ich zuerst mit einem Texteditor (Notepad++) erstellt, und dann mit Copy&Paste in das basic-HTML Widget kopiert, weil das direkte Erstellen im VIS-Editor wegen des rel. kleinen Eingabefeldes so gut wie "unmöglich" ist.

Erschwerend kommt hinzu, daß in den einzelnen basic-HTML Widegts im VIS-Editor ja die Bindings angezeigt werden und die Daten erst im VIS selbst geschrieben werden.
Deshalb ist es etwas frickelig, die einzelnen Widgets korrekt zueinander auszurichten - aber es geht.
Im VIS-Editor sieht es so aus:

Zur Performance kann ich nur sagen, daß es auf einem älteren Samsung A16 Android-Tablet, als auch auf auf einem Raspi 4 (4 GByte) mit Chromium-Browser im Kiosk-Mode auf einem 24"-Touchscreen problemlos läuft.

Diese Vorgehensweise war für meinen Wissensstand halt am einfachsten, mag sein, daß andere Lösungen performanter sind.

[joergeli]

Ich vermute, der TE wurde mißverstanden:

@wolfgangfb sagte in Performance-Vergleich VIS HTML Binding vs. JS:

Ich berechne nicht 500 Datenpunkte pro Sekunde. Es gibt insgesamt ca. 500 Datenpunkte. Pro Verbraucher einmal Momentanleistung, Gesamtenergieverbrauch, Verbrauch heute, Verbrauch gestern, Verbrauch letzter Monat, Verbrauch letzte Jahr. Macht bei ca. 70 Verbrauchern 420 Datenpunkte (OK, etwas weniger als 500).
Es kommt im Schnitt jede Sekunde irgendein Messwert an (Leistung oder Energie), d.h. ich berechne und schreibe dann die restlichen 5 Datenpunkte für diesen Sensor.

@oliverio sagte in Performance-Vergleich VIS HTML Binding vs. JS:

So schlimm ist es mit dem binding jetzt auch nicht, aber bei 500
Und sekündlicher Aktualisierung könnte man zu Problemen kommen.

So wie ich es verstehe, werden nicht alle 500 Datenpunkte gleichzeitig aktualisiert, sondern - wie auch bei mir - nur die Datenpunkte aktualisiert, die sich gerade geändert haben.
Das wäre lt. seiner Aussage im Schnitt jede Sekunde ein Meßwert.

[OliverIO]

@joergeli
Ja das habe ich verstanden.
Aber der Vorschlag war es ja die Daten alle in ein json zusammen zu packen.
Das json würde dann bei jeder Änderung erzeugt werden und auf dem Client/Browser dann auch auf einmal in eine Tabelle geschrieben werden.

Binding wäre da schon erstmal der richtige Weg.
Aber wie gesagt es gibt das Limit mit 50 pro Widget.
Mein Vorschlag war es die Daten sinnvoll aufzuteilen und in verschiedene views zu packen.

Ich glaub, ich muss mal dazuschreiben, das meine jeweiligen Antworten immer im Gesamtkontext des threads zu sehen sind und ich nicht in jedem einzelnen Post alles von mir zuvor gesagte erneut wiederholt werden muss.

[WolfgangFB]

@jey-cee sagte in Performance-Vergleich VIS HTML Binding vs. JS:

@wolfgangfb um die Frage kurz und knapp zu beantworten:
Bindings sind die schlechteste Wahl wegen dem Overhead der da dran hängt. Davon abgeshen das jeder Wert einzeln Übertragen werden muss.

Fällt eh weg weil es ja die Beschränkung auf 50 gibt.

Die JSON variante ist deutlich besser, hat aber den Nachteil das die Daten noch in HTML gewandelt werden. Hier wird nur eine abfrage gemacht und die Menge an Daten spielt eine kleine Rolle.

Die HTML variante wird performance mässig im Browser am besten sein. Der Browser muss hier nicht mehr viel verarbeiten. Dafür ist die Erstellung im Backend etwas Aufwändiger.

Ob ich jetzt ein json oder eine HTML Tabelle erstelle macht für mich keinen großen Unterschied. Außer dass es für mich eben viel einfacher ist, die html Tabelle entsprechend zu gestalten.

Ich kann hier über die Radiobuttons oben noch einstellen, welche Werte ich überhupt sehen möchte (hier alles über 10 W).
Wie gesagt, der einzige Wert, der immer überschrieben wird, ist der Datenpunkt mit der html Tabelle. Ansonsten reagiere ich nur auf das, was die S0 Counter oder die Shellys/Tuyas/Sonoffs gerade so abliefern und aktualisiere für genau dieses Gerät die Daten.

[BananaJoe]

@wolfgangfb der Vorteil einer JSON Tabelle ist das z.B. das JSON-Widget von Inventwo das sortieren per Klick auf die Spaltenüberschriften zulässt. Zudem kannst du die Reihenfolge der Spalten frei wählen oder einzelne ausgeblendet lassen / ignorieren. Das Widget erlaubt auch das Einfärben jeder 2. Zeile, setzen der Überschriften etc.

Wenn du also etwas an der Darstellung ändern willst musst nicht das JSON anfassen bzw. kannst ein und das selbe JSON verschieden darstellen.

JSON ist einfach! Gib dich nicht auf, lerne JSON!
Der JSON Path Finder: https://jsonpathfinder.com/
und ein JSON Validator https://jsonformatter.curiousconcept.com/ sind dein Freund.
Viele APIs liefern Ihre Daten als JSON - und auch ioBroker arbeitet intern nicht ohne Grund mit JSONs wie eine kleine Suche nach .json oder .jsonl Dateien im ioBroker Programmverzeichnis dir zeigen wird.

[BananaJoe]

@wolfgangfb Nachtrag: ich sehe im Screenshot gerade deine >10 >50 Buttons. Hast du die mit im HTML-Code oder veranlassen die nur eine Neuerstellung?

[WolfgangFB]

@bananajoe sagte in Performance-Vergleich VIS HTML Binding vs. JS:

@wolfgangfb Nachtrag: ich sehe im Screenshot gerade deine >10 >50 Buttons. Hast du die mit im HTML-Code oder veranlassen die nur eine Neuerstellung?

Die veranlasen eine Neuerstellung bzw. sorgen beim Erstellen der Tabelle dafür, dass nur bestimmte Zeilen erzeugt werden. Ich wüsste auch nicht, wie ich das in html (oder auch json) realisieren könnte, dass z.B. nur Zeilen von echten Zählern (S0 Counter, Eintrag "LS") angezeigt werden.

PS. Es ist nicht so, dass ich mit json nichts anfangn könnte oder eine Abneigung dagegen hätte, ich nehme gerne den Weg, mit dem ich am geradlinigsten zum Ziel komme..