![\"Eine](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/energieuebersicht-de.png\")
Wohin die Nutzlast geht und warum sie dort bleibt<\/h2>\n
Entdeckung ist eine Nachricht auf einem Topic, das der Broker beh\u00e4lt: Der zweite Befehl ist der, der meist fehlt. Die Entit\u00e4t in der Oberfl\u00e4che zu l\u00f6schen, entfernt sie bis zum n\u00e4chsten Neustart; dann spielt der Broker die behaltene Konfiguration wieder ein, und das Ger\u00e4t ist zur\u00fcck. Eine MQTT-Entit\u00e4t ist erst weg, wenn das Topic leer ist, das sie erzeugt hat.<\/p>\n Eine Feinheit von F\u00fcnf der sechs zeigen sich als etwas anderes als ein Fehler. Das ist die Gestalt des ganzen Problems: Eine Entdeckungsnutzlast wird Feld f\u00fcr Feld angenommen oder \u00fcbergangen, und ein \u00fcbergangenes Feld hinterl\u00e4sst keine Spur au\u00dfer der F\u00e4higkeit, die es lautlos vorenthalten hat.<\/p>\n Ein MQTT-Sensor ohne Verf\u00fcgbarkeitsbehandlung kennt kein Offline. Der letzte eingetroffene Wert bleibt stehen, und bei einem Z\u00e4hlerstand ist das schlimmer als eine L\u00fccke: Die Zahl wirkt plausibel, der Verlauf ist flach, und die Energie\u00fcbersicht meldet einen Haushalt, der seit Dienstag nichts verbraucht hat.<\/p>\n Langzeitstatistiken entstehen einmal je Stunde aus den Zust\u00e4nden, die in dieser Stunde aufgezeichnet wurden. Eine am Freitag berichtigte Nutzlast erzeugt keine Statistik f\u00fcr Montag bis Donnerstag, weil es nichts gab, woraus sie h\u00e4tte entstehen k\u00f6nnen – die Zust\u00e4nde waren da, nur hatte niemand angeordnet, sie zu summieren.<\/p>\n Das Loch l\u00e4sst sich im Statistikeditor unter den Entwicklerwerkzeugen von Hand schlie\u00dfen, der einzelne Summen \u00e4ndern kann, und bei einem Z\u00e4hler, auf dessen St\u00e4nde es ankommt, lohnt sich das. Es ist zugleich der Grund, die drei Felder am Tag der Einrichtung zu pr\u00fcfen statt am Monatsende: Alles andere in einer Entdeckungsnutzlast l\u00e4sst sich sp\u00e4ter berichtigen, ohne dass etwas verloren geht.<\/p>\nhomeassistant\/<Komponente>\/<Knoten>\/<Objekt>\/config<\/code>, ver\u00f6ffentlicht mit gesetztem Retain-Merker. Behalten hei\u00dft, dass der Broker sie Home Assistant nach jedem Neustart erneut zustellt – deshalb \u00fcbersteht ein MQTT-Ger\u00e4t einen Neustart, ohne dass das Ger\u00e4t etwas senden m\u00fcsste.<\/p>\n# anlegen, behalten\nmosquitto_pub -h broker -r -t \"homeassistant\/sensor\/zaehler01\/energie\/config\" -m \"$(cat sensor.json)\"\n\n# entfernen: leere Nutzlast auf dasselbe Topic, wieder behalten\nmosquitto_pub -h broker -r -t \"homeassistant\/sensor\/zaehler01\/energie\/config\" -m \"\"<\/code><\/pre>\nDie drei Felder, die alles entscheiden<\/h2>\n
device_class<\/code> erkl\u00e4rt, um welche Art Gr\u00f6\u00dfe es sich handelt, und legt damit fest, welche Einheiten dazu erlaubt sind. F\u00fcr energy<\/code> sind das Wh, kWh und MWh. F\u00fcr power<\/code> sind es W und kW, und ein Leistungssensor kommt als Energiequelle nicht in Frage, gleich was sonst in der Nutzlast steht – Watt ist eine Rate, und eine \u00dcbersicht, die Raten aufaddiert, w\u00e4re falsch.<\/p>\nunit_of_measurement<\/code> wird buchst\u00e4blich verglichen. kWh<\/code> geht durch, kwh<\/code> und KWH<\/code> nicht, und das Ergebnis ist keine abgelehnte Nutzlast, sondern eine Entit\u00e4t, deren Einheit nicht zur Klasse passt und die sich deshalb nicht ausw\u00e4hlen l\u00e4sst. Das ist die mit Abstand h\u00e4ufigste Ursache, und sie ist auf jedem Bildschirm unsichtbar au\u00dfer auf dem, auf dem die Entit\u00e4t nicht erscheint.<\/p>\nstate_class<\/code> entscheidet, ob \u00fcberhaupt Langzeitstatistik entsteht. Ohne dieses Feld bleibt der Wert im kurzen Verlauf und sonst nirgends; mit dem falschen ebenso. Nur total<\/code> und total_increasing<\/code> erzeugen die Stundensummen, aus denen eine Energie\u00fcbersicht liest.<\/p>\ntotal_increasing, total, measurement<\/h2>\n
total_increasing<\/code> ist f\u00fcr Z\u00e4hler gedacht, die nur aufw\u00e4rts z\u00e4hlen. Ein R\u00fcckgang wird als Z\u00e4hlerwechsel gelesen – ein getauschtes Ger\u00e4t, eine Firmware, die bei null beginnt – und der neue Wert z\u00e4hlt ab dort, statt als negativer Verbrauch. Es braucht kein last_reset<\/code> und ist f\u00fcr nahezu jeden Energiez\u00e4hler die richtige Wahl.<\/p>\ntotal<\/code> ist f\u00fcr Werte, die auch fallen k\u00f6nnen, etwa eine Bilanz, und erwartet einen last_reset<\/code>-Zeitpunkt, um zu wissen, wann eine Periode begann. measurement<\/code> ist f\u00fcr alles, was ein Zustand ist und keine Summe: Temperatur, Leistung, Feuchte. Es ist die Angabe, zu der alle greifen, weil sie neutral klingt, und es ist der Grund, warum ein tadelloser Z\u00e4hlerstand einen sch\u00f6nen Verlauf ergibt und nie eine einzige Kilowattstunde.<\/p>\ntotal_increasing<\/code> sollte bekannt sein, bevor sie eintritt: Ein Wert, der nach unten springt, wird bei gen\u00fcgend gro\u00dfem Sprung als Z\u00e4hlerwechsel gelesen, und der gesamte neue Stand wird in dieser Stunde als Verbrauch verbucht. Ein Z\u00e4hler, der gelegentlich einen alten, niedrigeren Wert meldet, erzeugt also keinen kleinen Fehler, sondern eine Spitze in H\u00f6he des ganzen Z\u00e4hlerstands.<\/p>\nWelches Symptom aus welcher Zeile kommt<\/h2>\n
\n\n
\n \nSymptom<\/th>\n Ursache in der Nutzlast<\/th>\n<\/tr>\n<\/thead>\n \n Entit\u00e4t da, als Energiequelle nicht w\u00e4hlbar<\/td>\n state_class<\/code> fehlt oder steht auf measurement<\/code><\/td>\n<\/tr>\n\n Entit\u00e4t da, Einheit sichtbar, aber nie summiert<\/td>\n Einheit passt nicht zur device_class<\/code>, etwa kwh<\/code><\/td>\n<\/tr>\n\n Entit\u00e4t l\u00e4sst sich nicht umbenennen oder bearbeiten<\/td>\n unique_id<\/code> fehlt – und damit auch keine Energiequelle<\/td>\n<\/tr>\n\n Eine einzelne riesige Spitze in einer Stunde<\/td>\n total_increasing<\/code> an einem Z\u00e4hler, der niedriger meldete<\/td>\n<\/tr>\n\n Wert steht tagelang still, Verbrauch ist null<\/td>\n kein availability_topic<\/code> und kein expire_after<\/code><\/td>\n<\/tr>\n\n Ein gel\u00f6schtes Ger\u00e4t ist nach dem Neustart zur\u00fcck<\/td>\n das behaltene Konfigurationstopic wurde nie geleert<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Der Sensor, der seinen letzten Wert f\u00fcr immer beh\u00e4lt<\/h2>\n
availability_topic<\/code> mit einem letzten Willen auf der Ger\u00e4teseite ist die saubere L\u00f6sung, expire_after<\/code> die grobe – eine Sekundenzahl, nach der der Zustand als nicht verf\u00fcgbar gilt, wenn nichts Neues eintrifft. F\u00fcr einen Z\u00e4hler, der alle zehn Sekunden sendet, sind dreihundert gro\u00dfz\u00fcgig und fangen ein totes Ger\u00e4t trotzdem binnen f\u00fcnf Minuten ab.<\/p>\nStatistik schaut nicht zur\u00fcck<\/h2>\n