Bin nicht oft im Forum und hab gerade gesehen, dass es ein FFM-Usertreffen geben soll/gibt.
Da wäre ich auch dabei. Gerne persönlich, aber auch gerne per Teams.
Ich hab hier ne relativ große ioB-Installation und bin natürlich immer an Austausch interessiert.

@klassisch Im Grunde ist es ganz einfach.... wenn man mal alle Teile zusammen getragen hat.
Ich lese mit dem Smartmeter Adapter die Werte aus dem Zähler des Netzbetreibers aus.
Somit stehen sie schon mal im ioBroker zur Verfügung.
Dann gibt es auf Github ein Projekt das einen sdm630 Zähler im System emuliert.
Das findest man auf Github, wenn man nach victron und sdm630 sucht oder einfach hier über diesen Link
Da muss man allerdings den Code etwas anpassen und mit Go neu kompilieren.
Das coole ist, es ist in Go geschrieben und lässt sich auch auf einem Windowsrechner für den Raspi erstellen.
In diesem Projekt ist eigentlich alles ziemlich gut erklärt.
Wenn das Programm dann neu erstellt wurde und auf dem Venus OS läuft, muss man im ioBroker nur noch eine Struktur unter MQTT erstellen.
Die sieht dann so aus:
Topic (z.B Hauszaehler)
---sdm1-1
------Current
---------L1
---------L2
---------L3
------Power
---------L1
---------L2
---------L3
------Voltage
---------L1
---------L2
---------L3
---Import
---Export
wobei Power und Current selbst auch Datenpunkte sein sollten.
Diese müssen dann über ein Script im Broker noch mit Werten gefüllt werden. Der Rest passiert von alleine.
Achso, eins noch. Im Code der Zähleremulation werden negative Werte auf 0 gesetzt. Somit könnte man dem System keine Einspeisewerte mitteilen. Da hab ich die Abfragen einfach raus genommen und übertrage die Werte so, wie sie vom Zähler kommen.
Das coole an der Geschichte ist, dass man im ioBroker-Script die Werte noch manipulieren könnte. So könnte man bei Bezug z.B. immer 50 oder 100Wh mehr übertragen, das hätte dann zur Folge, dass der MP2 auch immer etwas mehr Leistung erzeugt als benötigt wird (wird dann eben eingespeist), auf der anderen Seite hätte man aber auch einen gewissen Puffer um Netzbezug durch Regelträgheit möglichst zu vermeiden.

Wenn ihr Fragen habt, kann ich gerne helfen.

Nachtrag: ich hab heute das Auslesen meines Hauptzählers neu gemacht. D.h. ich lese jetzt nicht mehr mit einem eigenen Raspi und einem USB Lesekopf aus sondern mit einem D1 Mini und einem Seriell-IR Lesekopf.
Jetzt kommen die Updates der aktuellen Verbrauchsdaten im Sekundentakt und der zeitliche Versatz liegt bei maximal 0,2 Sekunden. Damit kann ich jetzt perfekt leben. Viel schneller könnte es ein EM24 auch nicht

Hy,

ich hab zwar ne relativ große PV auf dem Dach, steuere aber aktuell meine Waschmaschine nicht "smart".

Allerdings hab ich mich mit dem Thema vor einiger Zeit mal beschäftigt.

Vorgehensweise war damals immer diese "schaltbare" Steckdose dann zu schalten, wenn seit z.B. 15 Min. genügend PV-Überschuß erzeugt wird.

Die Waschmaschine wird entsprechend vorbereitet, also mit Wäsche beladen und bei manuell geschalteter Steckdose das Programm gewählt und gestartet. Dann wird, wieder manuell, die Steckdose ausgeschaltet.

Schaltet nun dein Smarthomesystem die Steckdose ein, arbeitet die Maschine da weiter, wo sie aufgehört hat.

So zumindest die Idee. Ob das bei deiner Maschine auch funktionieren würde, musst du testen.

Ich habe mich damals nicht weiter damit beschäftigt, weil mir meine Frau was erzählen würde, wenn sie beim waschen immer erst auf schönes Wetter warten müsste und ich es ziemlich doof fand die Maschine so mittendrin "abzuwürgen" nur um ein paar Cent zu sparen.

@ilovegym unser Sohnemann kommt zwar heute mit unserem "neuen" Enkelkind, aber ich werde mich da sicher auch mal ne Zeit lang raus ziehen können. Dann bis 18 Uhr. Bin gespannt, wie das Treffen online wird

Gestern konnte ich leider nicht kommen. War aber auch nicht angemeldet. Wir hatten hier bei uns einen Faschingsumzug und da kommste mit dem Auto nicht raus.
Nachher sollte es aber klappen.
Beim nächsten Treffen bin ich aber dann auch live dabei.

Gestern konnte ich leider nicht kommen. War aber auch nicht angemeldet. Wir hatten hier bei uns einen Faschingsumzug und da kommste mit dem Auto nicht raus.
Nachher sollte es aber klappen.
Beim nächsten Treffen bin ich aber dann auch live dabei.

@ilovegym unser Sohnemann kommt zwar heute mit unserem "neuen" Enkelkind, aber ich werde mich da sicher auch mal ne Zeit lang raus ziehen können. Dann bis 18 Uhr. Bin gespannt, wie das Treffen online wird

Der Umzug ist vollbracht.
Wenn auch nicht zu 100% automatisiert. Aber ich war mir zuerst gar nicht sicher, ob es überhaupt machbar ist.
Mein Vorgehen, vielleicht können sich ja mal die Profis zu äußern, ob das so halbwegs ok war.

1. Vollbackup vom kompletten System, Also iobroker_data, Redis und der SQL-Datenbank
2. Ich hab mir in ioB ein Script geschrieben, dass mir alle Datenpunkte unter javascript.0.Datenpunkte ausliest und daraus zwei Textdateien erstellt. In der ersten wird für jeden Datenpunkt ein createState generiert, das den Datenpunkt mit allen Eigenschaften unter 0_userdata.0 anlegt.
   Im zweiten File wird für jeden Datenpunkt ein setState / getState erzeugt, das mir dann später alle Values von den alten DPs auf die neuen kopiert.
3. Ich hab die script.json Datei aus dem Backup extrahiert und ein python Tool geschrieben (bzw. von der KI schreiben lassen), dass in dieser Datei erst mal alle "Datenpunktpfade" anpasst. Danach wird geprüft ob es sich jeweils um einen Blockly-Eintrag handelt und wenn ja, wird der letzte Kommentar extrahiert, Base64 dekodiert, URL dekodiert dann darin die Pfade angepasst, URL kodiert, Base64 kodiert und damit dann der alte Kommentar überschrieben. Das natürlich für alle enthaltenen Skripte. Waren bei mir immerhin rund 130 von den 170 enthaltenen Skripten.
   Zu guter Letzt wurde die Datei gespeichert und wieder gepackt und ins Backupverzeichnis kopiert.
4. Ich hab mir den Inhalt der ersten Textdatei in ein javascript-Skript kopiert und ausgeführt. Damit waren schon mal alle Datenpunkte angelegt.
5. Das gepatchte Backup wurde eingespielt.
6. Dann hab ich mir den Inhalt der zweiten Textdatei in ein Skript kopiert und ausgeführt, damit die Datenpunkte alle aktuellen Werte hatten.
7. Test der neuen Skripte
   Dabei ist mir dann aufgefallen, dass ich alle Skripte einmal öffnen und neu speichern muss, damit sie sauber laufen. Das war zwar lästig, aber auch in 10 oder 15 Minuten passiert.
8. Ich hab den javascript Adapter vollständig gelöscht und neu installiert. Im Grunde war das der Auslöser meiner ganzen Aktion, weil der die Skripte nach einem Neustart nicht mehr automatisch gestartet hat. Kam immer ne Fehlermeldung er können eine View nicht finden.
9. ioB neu starten, damit die entsprechend konfigurierten neuen Datenpunkte auch wieder sauber in die Datenbank geloggt werden und das System die neue Umgebung kennt.
10. Abschließender Test ob die programmierten Automationen wieder funktionieren.
11. Was ich völlig vergessen hatte war die Anpassung der VIS und der Charts. Das hat dann noch mal gute drei Stunden gedauert, damit auch dort alle Datenpunkte die neuen Pfade hatten. Das hab ich allerdings von Hand gemacht und das war echte Strafarbeit :-).

Auf jeden Fall scheint jetzt wieder alles zu laufen und ich hab endlich wieder ein halbwegs aufgeräumtes System vor der Brust.
Ich nutze in meinem System keine Alias und hatte daher damit auch keinen Aufwand. Allerdings würde man die dann auch anpassen müssen, sollte man sie nutzen.

@ticaki Danke für die schnelle Antwort.
Base64 dekodieren ist je erst mal kein Problem. Den Step nach XML würde ich mir sparen. Dürfte für meinen Zweck nicht nötig sein, weil ich ja nur die Pfade abändern und dann wieder Base64 kodiert speichern will.
Mir ging es eher um die "merkwürdigen" id's. Aus deinem Beispiel wäre das z.B.
"A]_ ;ZMV[1/R_X1YQ!W[" aus dem Part: <block type="control" id="A] ;ZMV[1/R_X1YQ!W[_" x="88" y="262">.

Da bin ich mir unsicher, ob das auch noch irgendwie kodiert ist oder ob es wirklich einfach eine ID ist, die ioB halt so verwendet.

Ich hab hier eine relativ alte ioB installation und alle Datenpunkte sind noch im javascript Ordner angelegt. userdata gabs damals noch gar nicht.
Ich hatte schon länger vor, das ganze mal zu bereinigen und hab mich die Tage mal dran gesetzt.
Ein Skript, dass mir alle Datenpunkte ausliest und mit den gleichen Eigenschaften (also type, desc, min, max, custom usw) unter userdata anlegt hab ich schon und das funktioniert auch problemlos.
Meine Skripte sind fast alle in Blockly geschrieben und die müssen natürlich auch angepasst werden. Meine Idee war, ich exportiere alle Skripte, ersetze dann einfach in den exportierten Daten "javascript.0.Datenpunkte" mit "0_userdata_0" und importiere dann alle Skripte wieder. Das funktioniert aber nicht, weil die Blocklyinformationen anscheinend kodiert (Base64 ?) im letzten Kommentar stehen.
Dekodiere ich diesen Kommentar, dann kann man zwar halbwegs Code erkennen, aber es werden auch viele "nicht sprechende" IDs benutzt.

Daher hier meine Frage, hat jemand ne Idee, wie ich in einem Batchjob in allen Skripten den Pfad zu meinen Datenpunkten austauschen kann?
Das muss nicht zwingend mit ioB Bordmitteln sein, gerne auch über Export/Import oder wie auch immer.

Bin nicht oft im Forum und hab gerade gesehen, dass es ein FFM-Usertreffen geben soll/gibt.
Da wäre ich auch dabei. Gerne persönlich, aber auch gerne per Teams.
Ich hab hier ne relativ große ioB-Installation und bin natürlich immer an Austausch interessiert.

@apollon77 Der Ansatz an sich ist mir schon klar und der ist im Grunde ja auch gut so.
Meine Idee, Daten in die DB zu schreiben, war im Grunde sowieso nur eine Krücke, weil ich keine andere Möglichkeit gesehen habe als über den FLOT Adapter zu gehen. Aber die Daten direkt über SQL auszuwerten und als JSON String zurück geben zu lassen ist natürlich viel eleganter.
Man kann sich zwar sicher über die Optik streiten, aber für meine Zwecke reicht das alle mal.
Danke dir trotzdem für die Antworten.

@bananajoe danke für den Tip. as mit dem Zeitstempel klingt grundsätzlich interessant.
Aber die Daten als solches liegen ja schon in einer Tabelle als Tageswerte vor. Ich muss also lediglich in einer SQL Abfrage die Daten entsprechend aggregieren und anzeigen lassen.
Mein erster Ansatz, die berechneten Daten wieder in die DB zu schreiben, war eigentlich dämlich und nur dem Umstand geschuldet, dass ich keine Idee hatte diese Daten irgendwie anders anzeigen zu können. Es gibt aber VIS Objekte, die Daten aus einem JSON-String anzeigen können.
Damit wird es relativ einfach das umzusetzen, was ich mir vorgestellt habe. Es ginge zwar vermutlich mit Grafana hübscher, aber die Lösung reicht mir voll und ganz und ist relativ flexibel.
So sieht es jetzt aus und das passt so für mich:

@apollon77 Ne, ich möchte die Daten schon aggregiert in die Datenbank schreiben.
Ich hab die ganzen Tageswerte und zeig sie mir aktuell in einer Tabelle an. Das funktioniert problemlos. Aber, ein altes Sprichwort sagt... Ein Bild sagt mehr als tausend Worte.
Ich würde mir diese Daten eben auch gerne in einer Graphik anzeigen lassen. Nach vorne verschieben, rein zoomen usw.
Die PV Tagesdaten hab ich mal aus einem Onlineportal extrahiert und in die DB (eigene Tabelle) geschrieben. Flot weigert sich aber hartnäckig diese Daten als Quelle anzuerkennen.
Wenn das ginge, wäre alles geritzt. Aber da kommt mir gerade eine Idee... vielleicht geht es ja mit einem JSON Chart Objekt... Ich spiel damit mal ein wenig rum....

@apollon77 Hy, gibt es eine Möglichkeit, historische Werte (die nicht aus ioBroker stammen) im entsprechenden Format in die Datentabellen der ioBroker Datenbank zu schreiben um diese dann mit Flot zu nutzen? Ich würde mir gerne Charts meiner PV-Anlage konsolidiert auf Tage, Monate und Jahre graphisch anzeigen lassen.
Die Daten im entsprechenden Format kann ich problemlos in die Tabellen einfügen, nur Flot nutzt diese Daten einfach nicht.
Ich hab mir dazu z.B. auch schon einen Datenpunkt angelegt und im Admin zum speichern eingestellt. Werte die ich nach der Erstellung in die DB speichere werden angezeigt. Daten davor leider nicht. Gibt es dafür eine Lösung außer Grafana zu verwenden?