Statistics (Stromverbrauch) [gelöst]

Begonnen von Rheingold, 23 Februar 2022, 08:58:02

Vorheriges Thema - Nächstes Thema

Beta-User

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Rheingold

Bezieht sich dein Kopfschüttel auf meine eingedeutschten Readings?

Nun, das ist bei mir aus Unwissenheit zu den gewissen Standards entstanden (hatte tatsächlich deinen Post hierzu nicht mitbekommen :( ). Generell stimme ich dir da zu, dass Standards gut und einzuhalten sind. Jedoch möchte ich anmerken, dass ich FHEM bei mir Zuhause nutze und nicht irgendwo kommerziell einsetze wo evtl. andere Parteien/Firmen mit dran arbeiten. Daher kann ich aktuell mit meinen Readings ganz gut leben :)

Würde ich ein Smart Home bei mir von Grund auf neu aufsetzen (müssen), würde ich heute auch vieles anders machen und auch evtl. andere Lösungen als FHEM austesten. Aber warum soll ich das tun? Es läuft doch (fast) alles wunderbar :)
Fhem auf Raspi 3; Jeelink mit 6x TX29DTH; CUL433 mit 9x RCS 1000 N und Somfy-Steuerung; CUL868; MAX-Cube + Thermostate; Philips Hue & Ikea Tradfri; Google Home Assistant; FTUI für Tablet und SmartPhone via Reverse-Proxy

Beta-User

Zitat von: Rheingold am 24 Februar 2022, 07:18:04
Bezieht sich dein Kopfschüttel auf meine eingedeutschten Readings?
Nicht nur, eigentlich ist das eher der kleinste Teil. Es stellen sich ein paar weitere Fragen bei deiner Lösung:
- Wann und wie oft wird dein zusätzliches userReading evaluiert?
- Gibt es dabei verdeckte Abhängigkeiten? Sind die alle korrekt aufgelöst?
- Welche Folgewirkungen hat jede Evaluierung des zusätzlichen userReadings?
- Wofür wird der gerundete Wert benötigt? Gibt es andere Lösungen, um das angestrebte Ziel zu erreichen (insbes.: stateFormat)

Zum Rest:
Zitat
Generell stimme ich dir da zu, dass Standards gut und einzuhalten sind. Jedoch möchte ich anmerken, dass ich FHEM bei mir Zuhause nutze und nicht irgendwo kommerziell einsetze wo evtl. andere Parteien/Firmen mit dran arbeiten. Daher kann ich aktuell mit meinen Readings ganz gut leben :)
Das kann schon so sein, aber zum einen fängst du grade damit an, so dass jetzt eigentlich der richtige Zeitpunkt wäre, um es gleich "passend" (standardisiert) zu machen. Es gibt dazu aber leider (noch?) keine Standards, siehe z.B. auch DevelopmentGuidelinesReadings - weitere Vorschläge für künftige Module.

Das Problem mit den "eigenen" Reading-Namen ist halt, dass du dann jedes Mal deine eigenen Sonderlocken nachpflegen mußt, wenn jemand eine Lösung für "die Allgemeinheit" bereitstellt (z.B. für die Visualisierung von Solarerträgen etc.). Klar: Es ist dein Mehraufwand, kannst du gerne so entscheiden, und ich habe auch gesehen, dass du den Post ja überlesen hattest und über den Punkt daher noch nicht intensiver nachgedacht...

Zitat
Würde ich ein Smart Home bei mir von Grund auf neu aufsetzen (müssen), würde ich heute auch vieles anders machen und auch evtl. andere Lösungen als FHEM austesten. Aber warum soll ich das tun? Es läuft doch (fast) alles wunderbar :)
Vielleicht...

Ich würde vermutlich auch erst "das ganze Internet" durchforsten und mich ggf. auch von (teilweise nachweislich falschen!) Argumenten von irgendwelchen Videobloggern in die Irre leiten lassen und was auch immer ausprobieren, weil es "moderner" aussieht. Am Ende kochen aber alle Lösungen nur mit Wasser, und FHEM ist nach wie vor vermutlich die "stabilste" Lösung (auch, was das update-Verhalten über der Zeit angeht).
Man kann immer auch jemanden in seiner Muttersprache fragen, warum etwas nicht klappt, und solche "Kleinigkeiten" an inneren Abhängigkeiten und "Regeln", wie wir sie hier besprechen, gibt es mit Sicherheit auch in anderen Lösungen - nur kenne ich die nicht...

Daher versuche ich grade auch, nach und nach meine copy/paste-Lösungen zu hinterfragen und manches ggf. einfach aufzuräumen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors