fhempy: rct_power (RCT-Power)

Begonnen von dominik, 10 Februar 2022, 20:20:12

Vorheriges Thema - Nächstes Thema

dominik

Hallo,

auf Anfrage von chris_kmn habe ich das rct_power Modul in fhempy implementiert. Wer es nutzen möchte, installiert einfach fhempy (https://github.com/dominikkarall/fhempy#installation) und macht dann
define my_rct_device fhempy rct_power IP

Danach werden einige Werte ausgelesen. Mit dem Attribut "interval" lässt sich das poll Intervall einstellen, default ist 10s.

Falls weitere Werte gewünscht werden, kann ich auch ein Attribut erstellen wo jeder seine Werte zum Auslesen selbst definieren kann. Lasst mich wissen ob das sinnvoll ist. Ich selbst habe kein RCT Power Device und daher kann ich die Use Cases nicht so gut bewerten.

VG
Dominik
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

marvin78

#1
Das sieht gut aus. In meinem Modul das auf der CLI des RCT Clients basiert, lasse ich dem User komplett die Wahl, welche Attribute in welchem Format und in welches Reading aus der Registry gelesen wird/werden. Zur Config wird ein Json erstellt. Wenn das hier auch identisch möglich wäre, würde ich das Modul weg schmeißen ;) Performance ist bei meinem Modul eher mäßig.

https://forum.fhem.de/index.php/topic,120219.0.html

chris_kmn

Um es hier auch nochmal offiziell zu machen: ich würde die Parametrierung von marvin78 auch begrüßen.

Und ein Write/set wäre grandios 😊

dominik

Parametrisierung kann ich gerne mal ausprobieren, paar fragen dazu...

- "unit": "%", was macht das oder soll es machen? Ich würde keine Einheiten in die Reading Values mit reingeben, weil sonst kann man damit nicht mehr rechnen. Wenn dann könnte man das am Reading hinten dran hängen. Z.B. battery_kWh. Wäre das sinnvoll?

- "factor": 100, was macht der Faktor? Ausgelesenen Werte dividieren?

- "intervalFactor": 1, ich denke das ist nicht notwendig, weil die Werte sowieso alle in einem Befehl gelesen werden können. Ob da nun 10 statische Werte alle 10s mit ausgelesen werden, sollte keine Rolle spielen. Natürlich weiß ich nicht wie das Gerät selbst bei vielen Abfragen reagiert?

Ich würde die Parametrisierung in den Attributen machen, damit man kein separaten File ablegen muss.

Write...schau ich mir noch an ;)
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

marvin78

#4
unit kann man weglassen.

Faktor ist wichtig. Und es ist, was es heißt, ein Faktor für den gelesenen Wert . Viele Werte kommen in unüblichen Größenordnungen an. Der User entscheidet, wie er es möchte. Und das pro Wert. Manchmal passt es manchmal nicht.

Interval Faktor ist hier ggf. nicht nötig. Mein Modul holt jeden Wert einzeln. Es geht nicht anders über die CLI. Hiermit kann man etwas verteilen (nicht jeder Wert bei jedem Durchlauf) und das tut der Performance gut.

Man braucht, aus meiner Sicht das Format, den Readingnamen (oft zu kryptisch) und den Faktor PRO WERT. In meinem Modul steht das gesamte Json über alle Werte in einem Attribut. Warum auch nicht? Die Registry ist groß und man sollte alle Werte lesen können. Da ist ein Json die beste Struktur (aus meiner Sicht).

{
    "values":[
    {
      "name": "battery.soc",
      "reading": "battery_soc",
      "unit": "",
      "factor": 100,
      "intervalFactor": 1,
      "format": "%.1f"
    },
    {
      "name": "battery.soh",
      "reading": "battery_soh",
      "unit": "",
      "factor": 100,
      "intervalFactor": 109,
      "format": "%.0f"
    },
    {
      "name": "battery.soc_target",
      "reading": "battery_soc_target",
      "unit": "",
      "factor": 100,
      "intervalFactor": 3,
      "format": "%.1f"
    },
    {

dominik

Alles klar....ja, das JSON direkt in einem Attribut ist eine gute Idee!

Ich würde 2 Attribute machen:
- Ein Attribut für "Anfänger", dort tragt man nur die Namen der gewünschten weiteren auszulesenden Werte ein
- Ein Attribut mit dem JSON, mit name, reading, factor und format (macht wahrscheinlich auch Sinn?)

Wie sollen die beiden Attribute heißen? poll_readings, poll_readings_json? Im rctclient heißen die einzelnen Werte immer ObjectInfos, aber ob poll_objectinfos verständlich ist?
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

chris_kmn

Ich denke auch, dass der intervallFactor weg gelassen werden kann.

Der factor ist eine Vorverarbeitung. Der SoC wird zum Beispiel als Wert zwischen  0 und 1 übertragen, ist aber eigentlich ein Prozentwert zwischen 0 und 100. Man könnte das auch mit einem userReadings machen, ist aber aufwändiger.

Hier sind mal ein paar Beispiele aus meinem Inverter mit dem fhempy Modul:

battery.efficiency  0.8496540784835815
battery.soc 0.5997843742370605
battery.soc_target 0.6100000143051147
battery.soc_target_low 0.6100000143051147
battery.soh 1.0
battery.temperature 18.575000762939453
battery_soc 59.1
db.temp1 19.162555694580078
energy.e_ac_day 5082.580078125
energy.e_grid_feed_day -1457.903076171875
energy.e_grid_load_day 10203.939453125
energy.e_load_day 13829.1513671875


Man sieht, dass die Rohwerte recht unformatiert rüber kommen. Bei allen Werten würden zwei Nachkommastellen reichen.

chris_kmn

#7
Man könnte die attribute device_readings nennen oder inverter_readings und dann device_readings_adv  oder so

Oder more_readings


Aus den ,,Standard Readings" im Modul könnte man noch die Werte

temperature.sink_temp_power_reduction
inverter_sn

löschen. Das sind Festwerte und machen wenig Sinn für FHEM. Hatte ich glaube ich nur mal zum Vergleichen genutzt.

dominik

Update ist online :)

Neue Attribute:
- device_readings
- device_readings_json

Im Hilfetext der Attribute steht jeweils die Info wie die Attribute formatiert werden müssen. inverter_sn habe ich drin gelassen, dachte mir, dass ist ein Reading was garantiert überall funktioniert und daher für neue User schon mal ein Zeichen, dass das Modul funktioniert.

Write schau ich mir am Wochenende an. Leider hat der rctclient selber kein Write implementiert, da muss ich was dazu bauen.
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

marvin78

irgendwas ist da noch im Argen (siehe Anlage). Bin noch nicht dazu gekommen, auf die Konsole zu schauen.


marvin78

Anliegend die Meldungen aus der JS-Konsole.  Es wird keine Hilfe zum Attribut angezeigt.

dominik

Hmmm...das ist der Helptext. Kannst du bitte im Source der Seite nach "github" suchen und dann das href Object hier rein kopieren. Da ist sicher ein " nicht escaped.
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

dominik

Fehler gefunden, ich habe 2 Files die ich geändert habe nicht committet :)

Update ist in paar Minuten ready.
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

marvin78

#13
<a href=\"https://github.com/svalouch/python-rctclient/blob/67b0f7bc5a8fb6d8b8e15d68d4a24b1d9fb93e48/src/rctclient/registry.py#L202\">Object Infos</a>

Wenn du ohnhin dabei bist: Hast du dich gegen Format entschieden? Das wäre, aus meiner Sicht, bei den ankommenden Werten recht wichtig. Ich benötige keine 10 Nachkommastellen (nicht bei jedem Wert). :)

Und noch eine Frage: Die Defaults werden über das Attribut überschrieben oder bleiben sie vorhanden?


EDIT: Ich habe gesehen, dass du ein Standard-Format mit 2 Nachkommastellen machst. Das will man ggf. aber auch schonmal anders haben.

marvin78

#14
Was mir zusätzlich noch auffällt:

Wenn ein Wert nicht gelesen werden kann, stehen die Fehler in den Readings. Das ist ggf. für Frontends nicht optimal. Da es ohnehin nur temporär ist, könnte man das ggf. nicht ins Reading schreiben, sondern in ein Sammel-Error-Reading und den alten Wert stehen lassen. Man kann es natürlich auch für das Frontend filtern bzw. ist es bei dem ein oder anderen Fehler auch nicht schlecht, wenn man den Fehler sieht. Das kommt sicher auf den Fehler an. Hier wird es dann kompliziert.

EDIT: Was mir noch fehlt, ist ein disable. Aber das ist nicht so wichtig.