Probier mal das davor setzen:

import "timezone"
option location = timezone.location(name: "Europe/Berlin")

@stefan-1 https://github.com/ioBroker/ioBroker.admin/issues/1237

llDarkSoull created this issue in ioBroker/ioBroker.admin

closed Admin 5.2.x seems to have issues with js.controler 3.2? #1237

@oxident Und die API hast du Reverse engineered, indem du den Traffic der App inklusive TLS Handshake mitgeschnitten hast oder denke ich da zu kompliziert?

@apollon77 said in Test Adapter influxdb 2.0:

Ich sage jetzt mal frech: Versucht es doch mal ... und schreibt es for uns und die anderen auf. Ich denke "adapter stoppen, updaten, Konfig ändern (ip, port, settings) und starten sollte es sein

Sorry für die späte Rückmeldung. Ich hab die Migration etwas hinausgezögert und wollte das in aller Ruhe machen. Das Mistwetter bietet sich nun dafür an.

Lange Rede: Ich hab heute erfolgreich von v1 auf v2 manuell migriert. Bei mir läuft influxdb als Docker Container auf einer Synology. Hier meine Schritte:

1. Docker Container v2 erstellen, aber noch nicht starten - Umgebungsvariablen passend für setup setzen, z.B.:
   DOCKER_INFLUXDB_INIT_MODE: setup
   DOCKER_INFLUXDB_INIT_BUCKET: iobroker
   DOCKER_INFLUXDB_INIT_ORG: iobroker
   DOCKER_INFLUXDB_INIT_USERNAME: iobroker
   DOCKER_INFLUXDB_INIT_PASSWORD: iobroker

2. optional: Aktuelle v1 DB mit BackItUp sichern (optional, da wir sowieso einen neuen Docker Container für v2 anlegen und damit v1 als Backup vorhanden bleibt)

3. influxDB Instanz stoppen

4. Im Terminal von Docker Container v1 Datenbank exportieren:
   service influxdb stop
   influx_inspect export -waldir /var/lib/influxdb/wal -datadir /var/lib/influxdb/data -database "iobroker" -retention "autogen" -out /var/lib/influxdb/export.db -lponly

5. Docker Container v1 stoppen

6. Docker Container v2 starten und setup abwarten

7. export.db in den gemounteten Data-Ordner Docker Container v2 verschieben

8. Im Terminmal von Docker Containver v2 export db importieren:
   influx write --bucket iobroker --file /var/lib/influxdb2/export.db

9. influxDB Instanz auf 2.x ändern, token eingeben und starten

Die export.db war bei mir fast 10 GByte groß, entsprechend hat der Import gute 1,5 Stunden gedauert, der Export ging mit ca. 10 min deutlich schneller.

Meine Motivation für die Migration war übrigens, dass flux nach Kalendermonaten und Jahren Daten aggregieren kann. Allerdings gibt es bereits einen ersten Wermutstropfen: flux kann aktuell keine Zeitzonen bei der Datenaggregierung. Damit sind die aggregierten Werte leicht falsch, was v.a. bei den Tageswerten deutlich spürbar ist, bei den Monatswerten weniger ins Gewicht fällt. Workaround wäre, für die Tageswerte mit influxql weiterzuarbeiten, allerdings bekomme ich grad die v1 Authentifizierung nicht hin, oder mit fixen timeshifts zu arbeiten, was aufgrund der Zeitumstellung blöd ist.

Insgesamt bin ich aber froh, dass es dann doch so reibungslos funktioniert hat. Leider hat Grafana noch kein QueryBuilder für flux, aber gut.

Danke für den tollen Support hier.

Das Problem war nicht die Achsenskalierung, sondern die Abfrage (query), die nur Werte größer 0 abgefragt hat

@rsuter wir haben sie über eine Kollegin in Frankreich bestellt, da sie dort deutlich günstiger ist.

So sieht meines aktuell auf einem 7 Zoll Tablet aus. Uhrzeit ist so groß, damit man sie auch vom Sofa aus erkennt.

@micklafisch said in Test PV Forecast Adapter:

Moin moin,

weiß jemand wie ich die Stunde Verschiebung zwischen Forecast und Production in meinem Grafana Graph kompensieren kann? Kann ich einer Zeitreihe sagen "Werte-1h"?

Bei mir sind es 45 min, warum auch immer.

Ich nutze influxdb V2. Dort kann man im query ein Timeshift angeben:

|> timeShift (duration: 45m)

@jaskome mein Tipp: in Frankreich nach der Bridge suchen, kostet nur die Hälfte.

@oxident
Danke für das Update des Scripts. Ich bekomme allerdings folgende Fehlermeldung:

script.js.Home.BwwPCloud: Fehler bei getTokenAPI(): AxiosError: Request failed with status code 500

@jaskome mein Tipp: in Frankreich nach der Bridge suchen, kostet nur die Hälfte.

@skb Danke! Liest sich gut und werde ich testen. Insgesamt toller Adapter, der in der Vis was her macht.

Erste Antwort zum Zitat war als Zitat formatiert. Hab's korrigiert.

@flojo Ich hatte das gleiche Problem. Hab's jetzt hinbekommen, muss aber @arteck sagen, dass die Einstellungen etwas verwirrend sind.

Du hast unter Fully-Browser-Geräte nur einen Eintrag, wählst als Api-Type für den Parallel-Betrieb MQTT/REST MQTT aus, stellst aber beim Port den REST-API Port ein. Zumindest funktioniert es bei mir so. Ich hatte da auch zuerst den MQTT Port, was ja das ist, was ich als Api-Type auswähle. Vielleicht sollte hier MQTT+REST stehen oder so.

Danke für den Input und die Inspiration. Meine Antworten unter dem jeweiligen Kommentar.

@skb said in Test Adapter Energiefluss-erweitert v0.2.x GitHub/Latest:

Wenn Dich Nachkommastellen bei Watt stören, dann stell es doch fest auf kW ein - mit 2 Nachkommastellen. Dann ist die Genauigkeit auch gegeben.
Wäre ein Workaround. Für mich aus Platzgründen ideal wäre eine fixe Anzahl von 3 Ziffern (0-999 W, 1,00 - 9,99 kW, 10,0 - 99,9 kW, 100 kW...), hätte damit auch eine sinnvolle Genauigkeit. Bei kW und zwei Nachkommastellen fix finde ich Werte wie 0,05 kW für 50 W optisch wenig ansprechend. Mir gefällt das Feature der automatischen Umstellung von W auf kW.

Hier habe ich gerade eine Überlegung, das dies mit den Überschreibungen relativ einfach machbar mehr - jedoch ohne die Farbe im Datenpunkt - dazu überlege ich noch.

Aktuell könnte man dies (noch nicht implementiert) so lösen:

{
    ">0": {
        "borderfillcolor": "#FF0000",
        "bordercolor": "rgb(255,206,74)",
        "fillcolor": "#FF0000"
    },
    ">500": {
        "borderfillcolor": "rgb(255,206,74)",
        "bordercolor": "#000000",
        "fillcolor": "rgb(255,206,74)"
    },
    ">1000": {
        "borderfillcolor": "#A1D343",
        "bordercolor": "rgb(255,206,74)",
        "fillcolor": "#A1D343"
    }
}

Sähe dann so aus:

Natürlich lassen sich dann die Farben für die Füllung und den Rahmen getrennt angeben, wie es oben beschrieben ist.

Gute Idee für die Batterie, ich habe es ja mittlerweile mit farbigen, teilgefüllten Rahmen gelöst. Bzgl. Datenpunkt ist die Intention, dass sich Farben bei mir nicht immer auf den Wert selbst mappen lassen, sondern auf einen anderen Datenpunkt; z.B. beim Fahrzeugladen-Modus (grüne Punkte bei PV-Überschuss, gelb bei PV+min, rot bei max.), sodass ich ohne ins "Backend" zu gucken sofort sehe, welcher Modus aktiv ist.

@skb Mit Display none geht es auch nicht. Bei einem anderen Wert (ImportExport) funktioniert es mit opacity 0 (und display none).

Ich hab mir mal die Unterschiede angeschaut:
Der ImportExport-Wert ist faktisch nie exakt 0. Bei den beiden getrennten Werden für Laden (40314_3_DCW) und Entladen (40334_4_DCW) ist der jeweils inaktive exakt 0. Im zweiten Screenshot hab ich testweise beide Werte nebeneinander unten mittig, Schwellwert auf 10 W und das CSS mit Display none auf Quelle unter Schwelle gesetzt. Der aktuelle Wert Laden mit 4 W wird nicht angezeigt, der Entladen-Wert mit exakt 0 W wird angezeigt.

Blöde Frage: Kann es sein, dass das Kriterium "Quelle unter Schwelle (positiv/negativ)" nur auf größer/kleiner 0 und nicht größer gleich oder kleiner gleich 0 prüft und daher bei exakt 0 nicht greift?

Edit:
Ich denke, das ist der Grund. Hab im Code geschaut. So wie ich ihn verstehe, greift hier diese Logik:
https://github.com/SKB-CGN/ioBroker.energiefluss-erweitert/blob/1a471b1013e1fb45c3877c5afcb32caf5d76e405/main.js#L1124
Bei == 0 wird das InactiveCss nicht gesetzt.

Edit 2: Root cause bestätigt. Ich hab fürs Entladen (aktuell lädt der Akku, also ist 4_DCW exakt 0 W) einen Alias angelegt und diesen um 0.1 W reduziert. Jetzt greift die CSS-Logik bei unter Schwellwert negativ und der Wert wird ausgeblendet.

Edit 3: Was auch funktioniert: CSS Klasse invisible auf Allgemein (die Logik greift wohl bei exakt 0) und bei über Schwellwert positiv auf visible setzen.

Ich bin mir nur nicht sicher, ob das die Erwartungshaltung ist und was die Intention dahinter ist, == 0 separat zu behandeln, statt >= 0 und <0. Wenn ich eine CSS Klasse für unter Schwellwert positiv einstelle und mein Wert ist exakt 0, dann erwarte ich, dass hier diese Logik greift. Auch wenn man darüber, ob 0 nun der positiven oder negativen Logik zuzuordnen ist, diskutieren kann, dürften die meisten es dem positiven Wertebereich zuordnen.
Edit Ende.

Eine Frage noch:
Bei Überschreibung für Animiation bei der Verbindung für Import/Export hab ich folgendes eingetragen:

{
    ">0": {
        "color": "#FF0000 !important"
    },
    "<=0": {
        "color": "#00FF00 !important"
    }
}

Ich möchte bei Einspeisung (Export, Wert negativ), dass die Striche grün sind und bei Bezug (Import, Wert positiv) rot. Funktioniert leider nicht.

Hallo zusammen, hallo @SKB

erstmal: toller Adapter. Ich möchte damit meine von Hand zusammengebastelte Visualisierung ablösen (Screenshot am Ende).

Mein Setup: Fronius Hybrid WR mit Batterie, ausgelesen über modbus. Balkonsolar, ausgelesen über Shelly. go-e Wallbox. BWWP ausgelesen über Shelly. E-Auto.

Fragen bzw. Bugs?:

Werte verstecken:

• Leistung für Batterie laden/entladen sind zwei getrennte Werte. Der jeweils inaktive Zustand ist bei 0 W.

• Ich hab beide als Datenquelle hinzugefügt, bei beiden die Schwelle (Rohwert) auf 10 gesetzt und bei CSS unter Schwelle (positiv) folgendes CSS:

.invisible {
    opacity: 0 !important;
}

• Funktioniert nicht: Es werden immer beide Werte angezeigt, obwohl einer von beiden 0 ist.

• Ich hab das gleiche für einen anderen Wert versucht, ImportExport, also ob gerade eingespeist oder bezogen wird (das ist nur ein Datenpunkt mit Vorzeichen). Hier auch Schwelle auf 10 und invisible bei unter Schwelle eingetragen. Hier funktioniert es. Hab dieses Objekt auch dupliziert und die Datenquelle auf Akkuladen/entladen geändert -> Wird immer angezeigt.

Hast du eine Idee?

Feature Requests:

• Automatische Berechnung W/kW: Tolles feature. Wäre gut, wenn man getrennte Nachkommastellen konfigurieren könnte. Bei Watt machen Nachkommastellen keinen Sinn, mich interessieren Milliwatt nicht (und gibt die Messgenauigkeit auch gar nicht her), bei Kilowatt ist mir der Wert ohne Nachkommastellen aber zu grob.

• Farbe aus Datenpunkt: Wie du an der alten Visualisierung teils siehst, färbe ich meine Pfeile und Prozentbalken in Abhängigkeit von Modi und dem Füllstand ein. Modi nutze ich z.B. beim E-Auto und BWWP: Wenn das Fahrzeug nur mit PV-Überschuss geladen wird, ist der Pfeil grün, wenn PV+min gelb und max Leistung rot. Entsprechend würde ich auch gern die Verbindung im Energieflussadapter einfärben. Da es vermutlich zu aufwändig wäre, alle Szenarien in der Config-UI abzubilden, würde es mir reichen, wenn ich statt fixer Farben einen Datenpunkt angeben kann wie es in VIS mit {daten.punkt} möglich ist. Dann kann ich mir per Script die passende Farbe je nach Modi oder Füllstand in einen Datenpunkt schreiben.

@Labersack Habe zwei Problemkinder vom Typ HM-LC-Sw1PBU-FM, die sich sofort nach dem Einschalten wieder ausschalten.

Gilt dein Angebot noch? Dann würde ich das gern in Anspruch nehmen.

Edit: Da oben mitgelesen, ich hab auch noch einen Rollladenaktor HM-LC-Bl1PBU-FM, der sich per Taster nicht mehr hochfahren lässt, nur noch runter. Gerade mit einem Schraubenzieher den Taster für nach oben fahren ordentlich gedrückt, es passiert nichts (also wohl kein mechanisches Problem?). Idee? Kann ich den dir auch mitschicken?

@rsuter wir haben sie über eine Kollegin in Frankreich bestellt, da sie dort deutlich günstiger ist.

@oxident Irgendwas stimmt mit dem neuen Script nicht:

javascript.0
2023-10-28 17:02:00.549	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.2.states.core:StatusState.common.def

javascript.0
2023-10-28 17:02:00.548	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.1.states.core:ManufacturerNameState.common.def

javascript.0
2023-10-28 17:02:00.547	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.1.states.io:AwayModeDurationState.common.def

javascript.0
2023-10-28 17:02:00.546	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.1.states.io:SmartGridOptionState.common.def

javascript.0
2023-10-28 17:02:00.544	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.1.states.io:ElectricalExtraManagementState.common.def

javascript.0
2023-10-28 17:02:00.543	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.1.states.io:OperatingRangeState.common.def

javascript.0
2023-10-28 17:02:00.542	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.1.states.io:DHWModeState.common.def

javascript.0
2023-10-28 17:02:00.540	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.1.states.io:RateManagementState.common.def

javascript.0
2023-10-28 17:02:00.539	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.1.states.core:DiscreteRSSILevelState.common.def

javascript.0
2023-10-28 17:02:00.537	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.1.states.core:StatusState.common.def

javascript.0
2023-10-28 17:02:00.536	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.1.states.core:CommandLockLevelsState.common.def

javascript.0
2023-10-28 17:02:00.535	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.1.states.core:VersionState.common.def

javascript.0
2023-10-28 17:02:00.532	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.1.states.core:NameState.common.def

javascript.0
2023-10-28 17:02:00.531	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.0.states.core:LocalIPv4AddressState.common.def

javascript.0
2023-10-28 17:02:00.530	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.0.states.core:CountryCodeState.common.def

javascript.0
2023-10-28 17:02:00.528	error	script.js.Home.BwwPCloud: Wrong type of 0_userdata.0.Heizung.BWWP.0.states.core:NameState.common.def

javascript.0
2023-10-28 17:02:00.550	warn	at processTicksAndRejections (node:internal/process/task_queues:82:21)

javascript.0
2023-10-28 17:02:00.550	warn	at endReadableNT (node:internal/streams/readable:1359:12)

javascript.0
2023-10-28 17:02:00.550	warn	at IncomingMessage.emit (node:domain:489:12)

javascript.0
2023-10-28 17:02:00.550	warn	at IncomingMessage.emit (node:events:526:35)

javascript.0
2023-10-28 17:02:00.550	warn	at Object.onceWrapper (node:events:628:28)

javascript.0
2023-10-28 17:02:00.550	warn	at IncomingMessage.<anonymous> (/opt/iobroker/node_modules/request/request.js:1076:12)

javascript.0
2023-10-28 17:02:00.550	warn	at Request.emit (node:domain:489:12)

javascript.0
2023-10-28 17:02:00.550	warn	at Request.emit (node:events:514:28)

javascript.0
2023-10-28 17:02:00.550	warn	at Request.<anonymous> (/opt/iobroker/node_modules/request/request.js:1154:10)

javascript.0
2023-10-28 17:02:00.550	warn	at Request.emit (node:domain:489:12)

javascript.0
2023-10-28 17:02:00.550	warn	at Request.emit (node:events:514:28)

javascript.0
2023-10-28 17:02:00.550	warn	at Request.self.callback (/opt/iobroker/node_modules/request/request.js:185:22)

javascript.0
2023-10-28 17:02:00.550	warn	at Request._callback (/opt/iobroker/node_modules/iobroker.javascript/lib/request.js:27:17)

javascript.0
2023-10-28 17:02:00.550	warn	at script.js.Home.BwwPCloud:302:17

javascript.0
2023-10-28 17:02:00.550	warn	at enumStates (script.js.Home.BwwPCloud:362:21)

javascript.0
2023-10-28 17:02:00.550	warn	at setState (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1740:20)

javascript.0
2023-10-28 17:02:00.549	warn	State "0_userdata.0.Heizung.BWWP.2.states.core:StatusState" not found