Hi, ich schaue mir das auch an und habe winzige Anpassungen (bzw. Vorschläge, dies in Post 1 in das Script einzubauen)

• alle Datenpunkte als const, also auch den Verbrauchszähler, z.B.

/** Datenpunkt für den aktuell gemessene Akku Ladungzustand in % */
const AKTUELLER_AKKULADEZUSTAND = 'alias.0.MSA-000000000000.q_soc'; // q = aus quick

/** Datenpunkt für den aktuell gemessene Verbrauch plus=Überschuss/Einspeisung minus=Verbrauch/Kauf*/
const VERBRAUCHSZAEHLER = '0_userdata.0.Blockly.ShellyEmu.Power-Total-Raw';

• neben "laden" und "entladen" gibt es noch "standby" als Status des Akku, wenn er voll ist. Dies könnte auch bei der Loganzeige verwendet werden, da ein Akku > SOC_Ladeschwelle nicht mehr geladen wird.

const akkuSOC = getState(AKTUELLER_AKKULADEZUSTAND).val;
const istAkkuVoll = akkuSOC > SOC_LADESTOPP; // grösser als Ladestopp bedeutet Akku voll

• die internen Werte könnten auch optional als iobroker-Werte gespeichert werden, dann kann man sie auch in Grafen verwenden, eventuell in einstellbarem Zeitraster, um nicht zuviele Punkte in die DB zu schreiben

• eine Variable zum einfachen Pausieren der Regelung, etwa um Akkuswapping bei mehreren Akkus zu verhindern

Ansonsten vielen Dank für deine Mühe, läuft schon ganz gut, mal auf Erfahrungen warten
cu
Harvey

Hallo zusammen,
meine Fragen zu influxdb bzw. BestPractice:
Ich habe einige schnell sich änderende Daten, etwa von meiner Solaranlage und Speicher, teils alle 10 Sekunden. Da interessieren mich zeitnah die Daten der etwa 7 Tage, danach wird es eher uninteressant, also längere Zeitabstände wären super (auch für Speicherverbrauch in influxdb).
Leider gibt es wohl keine (einfache, allgemeine) Lösung, die Speicherdauer unterschiedlich zu begrenzen, also schnell sich ändernde Daten z.B. 4 Wochen zu halten, danach die Daten auf z.B. 1/30 zu reduzieren. Also von 10 Sekunden auf 5 Minuten ... Eigentlich eine mögliche influxdb interne Aufgabe (timed data reduction). Oder zwei Buckets mit unterschiedlichen retentions zur Auswahl ...
Aktuell habe ich eine vereinfachte Zwischenlösung, die aber neue Probleme hat:
ich habe die "Blockzeit" auf 300000ms (5 Minuten) eingestellt, so werden die sich schnell ändernden Werte zwar in echarts sofort angezeigt, aber nur nach 5 Minuten "Blockierung" in die Datenbank eingetragen. Damit taucht aber ein neues Problem auf:
Wenn etwa in der Solarleistung INNERHALB der Blockzeit der Wert z.B. auf 0.0W fällt und dann unverändert bleibt wird ja der letzte Wert VOR Beginn der Blockzeit in die Datenbank geschrieben, der allerneueste Wert, auch wenn geändert, wird ja aufgrund der Blockzeit in der Datenbank ignoriert. Das führt dazu, dass etwa bei Solarleistung der letzte Wert VOR der Blockzeit, z.B. 15W die ganze Nacht erhalten bleibt, obwohl wenige Sekunden hinter dem Wert von 15W der Wert 0.0W gemessen wurde, aber dieser Wert aufgrund der Blockzeit nicht in die Datenbank eingetragen wurde. Danach erfolgt aber keine weitere Eintragung in die Datenbank, da der Wert ja nicht mehr geändert wird (und nur geänderte Werte eingetragen werden sollen). Auch bei kurzen Bool-Werteänderungen führt das dazu, dass der allerneueste Wert nicht in die Datenbank eingetragen wird, da er blockiert wird.
Jemand eine Idee dazu?
Vielen lieben Dank!
cu
Harvey

Hi, ich schaue mir das auch an und habe winzige Anpassungen (bzw. Vorschläge, dies in Post 1 in das Script einzubauen)

• alle Datenpunkte als const, also auch den Verbrauchszähler, z.B.

/** Datenpunkt für den aktuell gemessene Akku Ladungzustand in % */
const AKTUELLER_AKKULADEZUSTAND = 'alias.0.MSA-000000000000.q_soc'; // q = aus quick

/** Datenpunkt für den aktuell gemessene Verbrauch plus=Überschuss/Einspeisung minus=Verbrauch/Kauf*/
const VERBRAUCHSZAEHLER = '0_userdata.0.Blockly.ShellyEmu.Power-Total-Raw';

• neben "laden" und "entladen" gibt es noch "standby" als Status des Akku, wenn er voll ist. Dies könnte auch bei der Loganzeige verwendet werden, da ein Akku > SOC_Ladeschwelle nicht mehr geladen wird.

const akkuSOC = getState(AKTUELLER_AKKULADEZUSTAND).val;
const istAkkuVoll = akkuSOC > SOC_LADESTOPP; // grösser als Ladestopp bedeutet Akku voll

• die internen Werte könnten auch optional als iobroker-Werte gespeichert werden, dann kann man sie auch in Grafen verwenden, eventuell in einstellbarem Zeitraster, um nicht zuviele Punkte in die DB zu schreiben

• eine Variable zum einfachen Pausieren der Regelung, etwa um Akkuswapping bei mehreren Akkus zu verhindern

Ansonsten vielen Dank für deine Mühe, läuft schon ganz gut, mal auf Erfahrungen warten
cu
Harvey

@harvey637
erfolgreich gelöst mit update von NPM auf Version 9.2.0 - also jetzt alles ok!
Thx
Harvey

natürlich auch mit "iobroker stop", also komplett wie in Thread beschrieben.

Hmmmm,

bei mir mit Problemen:

Checking for uncompressed JSONL databases... This might take a while!

npx: Installierte 12 in 6.213s
No path given, using /opt/iobroker/iobroker-data
Compressing /opt/iobroker/iobroker-data/states.jsonl
Compressing /opt/iobroker/iobroker-data/objects.jsonl
Compressed 2 JSONL files. Done

==========================================================================
    Checking autostart (4/4)
==========================================================================

Enabling autostart...
Autostart enabled!

==========================================================================

    Your installation was fixed successfully
    Run iobroker start to start ioBroker again!

==========================================================================

pi@raspberrypi:/opt/iobroker $ iobroker upgrade self
Update js-controller from @4.0.23 to @4.0.24
Stopped Objects DB
Stopped States DB
NPM version: 6.14.17
Installing iobroker.js-controller@4.0.24... (System call)
host.raspberrypi Cannot install iobroker.js-controller@4.0.24: 236

Hmmm ?!?
Irgend eine Idee?
habe:
rebootet
nach nach laufenden iobroker Prozessen gesehen (keine)
iobroker update, fix und dann upgrade self gemacht, mehrfach erfolglos

pi@raspberrypi:/opt/iobroker $ nodejs -v
v14.21.1
pi@raspberrypi:/opt/iobroker $ npm -v
6.14.17

Hi,
bisher habe ich NACH einem Update des hm-rpc-Adapters durchgeführt:

• die 50er *_thumb.png Bildchen der nicht bereits bekannten Geräte nach /opt/iobroker/iobroker-data/files/hm-rpc.admin/icons kopiert
• diese *png mit allgemeinen Leserechten versehen: chmod 644 /opt/iobro..../icons/*png
• in der Datei /opt/iobroker/node_modules/iobroker.hm-rpc/lib/images.js die Devices hinzugefügt, z.B.

...
    'HB-UNI-Sen-TEMP-DS18B20':  'hb-uni-sen-temp-ds18b20_thumb.png',
    'HB-UNI-RGB-LED-CTRL':      'hb-uni-rgb-led-ctrl_thumb.png',
    'HB-UNI-Sensor1':           'hb-uni-sensor1_thumb.png',
    'HB-UNI-Sensor5':           'hb-uni-sensor5_thumb.png',
    'HB-UNI-Sensor4':           'hb-uni-sensor4_thumb.png',
    'HB-UNI-Sensor6':           'hb-uni-sensor6_thumb.png',
    'HB-UNI-Sen-LEV-US':        'hb-uni-sen-lev-us_thumb.png',
    'HB-UNI-Sen-WEA':           'hb-uni-sen-wea_thumb.png',
...

• Geräte neu synchronisieren und neu starten des hm-rpc Adapters.

Nun habe ich für viele der so eingefügten *.png ein korrektes Mini-Icon auf dem objects -> rpc.0 Tab,
aber nicht für alle, obwohl sie korrekt eingetragen sind.

Meine Fragen:
Wie ist der korrekte Weg, eigene Geräte und eigene Icons dem hm-rpc.admin hinzuzufügen?
Wie kann man die hm-rpc.meta bearbeiten, wenn sie garnicht angezeigt wird? Dort sind manchmal die Änderungen in den XML-firmwware/rftype-Dateien nicht aktualisiert, aber der Adapter wird auch nicht aufklappbar angezeigt?

Danke!
Sonst habe ich nur die Frage, ob es noch irgendwelches Leben im FLOT-Adapter gibt, da dort diverse teils kleine, aber ärgerliche Fehler schon sehr lange stören und keine Updates kommen.

cu
Harvey

Hi,

das sehe ich auch so!

Unschön trotzdem, z.B. wenn Änderungen (z.B. "Feiertag heute") um Mitternacht halt zwei Stunden "neben" dem Tageswechsel-x-Tick

angezeigt werden und der Tag hat nicht mittags "halbiert" wird. Bei kürzeren Zeitabständen wird das Problem weniger offensichtlich.

Daher hatte ich das bisher durch einen einfachen Editiervorgang innerhalb von chart.js einen vorhandenen

Kommentar (so etwa "#timezone = browser") durch das entfernen des Kommentarzeichens # aktiviert …

und alles war gut. Ein einfacher Editorschritt, unschön, weil manuell nach jedem update, aber einfach möglich.

Jetzt ist das Editieren etwa aufwändiger. Villeicht passt es dann in "Konfigurationsdaten" des Flotadapters?

By the way, es war Zeile 521 von chart.js.

Nur so eine Idee ...

cu

Harvey

Hi,

mit dem aktuellen Flot-Adapter (1.9.1) sind alle *.js in minimaler Form zusammengezogen, gut für die downloads.

Allerdings sehe ich, wenn die Zeitskala so ist, dass Mitternacht (Tageswechsel) und EINE weitere x-Hilfslinie (senkrecht) gezogen wird

diese zweite Linie um "14:00" Uhr. Erwarten würde ich sie Mittags um "12:00" Uhr.

Bei andern Zeitformaten sehe ich sogar "02:00:00 20.06.18" und "14:00:00 20.06.18" und "02:00:00 21.06.18" …

Früher hatte ich immer nach Update des flot-Adapters in charts.js auskommentiert "timezone = browser", das erscheint jetzt etwas mühsam.

Wäre schön, wenn sich die (ja selbst skalierende) Zeitachse auf die "menschlichen" Tagesunterteilungen wie

Mitternacht (24:00/00:00), Mittags (12:00), bei vier Zeiten = "00:00 - "06:00" - "12:00" - "18:00" - "00:00"…. skalieren würde, dann wird der

Tageswechsel deutlich besser sichtbar.

Wie gesagt, bei mir war vorher das mit Änderung in charts.js perfekt.

Danke und ciao

Harvey

Hi @ apollon77,

es ist so, wie Du sagst, das Setzen der Variable auf "true" startet das Programm auf der ccu. Dnach kann/muss man die Variable

manuell wieder auf "false" setzen", da nur der Übergang false->true das Program auslöst.

Leider aber nicht das, was ich suche.

Ich möchte ja die Ausführung eines Programms protokollieren, um etwa den Ausführungszeitpunkt (etwa eines Tastendrucks)

zu sammeln und mit anderen Variablen grafisch darzustellen. Super wäre auch, Programmstart UND Programmende (bzw Laufzeit)

zu protokollieren.

Für ein einzelnes Programm ist es möglich, eine besondere Variable zu setzen und eine Sekunde später zurückzusetzen.

Das hilft mir in einem konkreten Fall wohl schon. Ist aber "im Prinzip" unschön, wegen vielen Variablen und Programmspaghetti.

Vielleicht ist Thema "Loggen eines Programmablaufs" auch für andere interessant. Es erscheint mir so, als würde eigentlich alles

fast schon fertig sein (Anbindung rega an sql/history, für Variable gehts es schon immer zu loggen).

Über die XML-Api wird zumindest der timestamp des letzten Programmlauf zurückgegeben.

<program id="9984" active="true" timestamp="1517857567" name="RolloManuellReset" description="...." visible="true" operate="true"></program>

Vielen Dank

cu

Harvey

Hallo,

die Suche hat nichts ergeben, daher meine Frage:

Wie logge ich die Ausführung eines Programms (9984 ist das gewünschte Programm)?

Ich sehe unter hm-rega.0.9984.ProgramExecute die Rolle "action.execute" mit einen Wert "false", erscheint mir logisch und ok,

das Programm läuft ja jetzt gerade nicht.

Im SQL-Adapter habe ich aktiviert, es entsteht der erste Eintrag mit "false", soweit ok.

Wenn ich das Programm manuell starte oder das Programm etwa durch das Zeitmodul abläuft sehe ich in der HM-WebUI die geänderte

"Letzte Ausführung". Allerdings gibt es keinen Eintrag im SQL-Adapter.

Ich habe schon mit "nur Änderungen" und der "Entprellzeit" experimentiert, leider ohne Erfolg.

Natürlich könnte ich für jedes Programm eine Systemvariable erstellen, die ich zusätzlich zum Programmstart setze und nach 10 Sekunden zurücksetze,

aber das erscheint mir bei > 30 Programmen irgendwie overkill zu sein und hilft nicht ber Lesbarkeit oder dem Variablenverbrauch.

Hat Jemand noch eine andere Idee?

Vielen Dank

Harvey