@marc-berg sagte in Heizungsregelung mit IOBroker:

@hansjochen

Ich weiß nicht mehr, ob du im Vortrag darauf eingegangen bist, was meinst du auf der letzten Folie mit "Backitup (Docker Instanz, Wiederherstellung automatisiert"? Welche Art von Automatisierung hast du dort eingebaut?

Das habe ich in Solingen nur am Rand erwähnt, weil es nicht direkt mit Heizen zu tun hat. Für ein System, das keinesfalls ausfallen sollte, finde ich es aber sehr hilfreich: Die Steuerungshardware gibt es bei mir doppelt. Ein Ausfall eines einzelnen Sensors wäre nicht tragisch, aber wenn die ganze Steuerung kaputt ginge, möchte ich keinen tagelangen Ausfall riskieren.

Anfangs habe ich das Zweitsystem mitlaufen lassen und dort jeweils die Backups vom Hauptsystem nächtlich installiert. Ein echter Standby-Server, der automatisch einspringt ist es nicht (braucht es bei uns auch nicht), sondern man muss einmal von Hand umstellen. Das mache ich, indem ich das Gerät entweder über ein Netzwerkkabel oder einen WiFi Stick ins Netzwerk hänge. Beim Starten von IOBroker wird nicht nur das letzte Backup zurück gespielt, sondern auch erkannt, wie das Gerät angeschlossen ist und auf dem Zweitsystem gar nicht erst voll gestartet, um nicht das Hauptsystem zu stören. Die "Automatisierung" an der Stelle läuft über ein kleines IOBroker Startskript:

#!/bin/bash

pkill -u iobroker
iobroker restore `ls /sharename/backupDir/iobroker_20* | tail -n 1`
iobroker host this
iobroker start
test -e ichBinVerkabelt && iob start all

exit 0

Die Datei "ichBinVerkabelt" erstelle oder lösche ich bei Systemstart.

Inzwischen bin ich der Ansicht, dass das Zweitsystem gar nicht immer aktiv mitlaufen muss. Die IOBroker Backups laufen ohnehin ins NAS, das von beiden Steuerungen erreichbar ist. Also reicht es mir, dass ich das Zweitsystem anschließe, falls es jemals erforderlich ist.

Hi @apollon77 ,

Cool, danke für den Hinweis. Ich dachte, ich hatte das angekreuzt. Aber egal, ich schicke Euch morgen mal was.
Klingt auf jeden Fall klasse. Zwei Vortragsreihen finde ich genau richtig.

Schönen Abend!

@rewenode

Die von Dir verlinkte Linux Anweisung
https://github.com/Hyundai-Kia-Connect/hyundai_kia_connect_api/wiki/Kia-Europe-Login-Flow
funktioniert bei mir unter Linux auch mit Hyundai problemlos. Das Einzige, was ich ändern musste, war den Pfad zum Hyundai Skript zu verwenden, also

wget -O ApiToken.py https://raw.githubusercontent.com/Newan/ioBroker.bluelink/refs/heads/master/py/HyundaiFetchApiToken_2.py

und dementsprechend dieses nachher ausführen:

python3 ApiToken.py

Unter MacOS stelle ich mir das ähnlich vor. Ob und wie man da aber erst mal wget installieren muss oder es dafür andere Hausmittel gibt, weiß ich nicht. Sonst sollte es auch reichen, das Skript mit einem Browser zu öffnen und unter dem Namen "ApiToken.py" abzuspeichern.

Cooler Thread hier. Ich kann noch den Solarfocus eco Manager Touch beitragen. Wird bei mir für eine Wärmepumpe (Vampair) benutzt, sollte aber auch für andere Solarfocus Heizungen funktionieren.
Vorsichtshalber weise ich darauf hin, dass bei mir einige Register nicht spezifikationsgemäß funktioniert haben. Ein paar wenige habe ich sogar an anderen Adressen gefunden. Ich kann nicht sagen, ob das bei Solarfocus generell so ist oder nur bei mir abweicht. Die Konfiguration ist bei mir seit 2 Wintern erfolgreich im Einsatz. Ich empfehle aber, vor der Verwendung die Registerbelegung zu prüfen, insbesondere die Holdingregister.

Eingangsregister.txt
Holdingregister.txt

Ich möchte an der Stelle den Organisatoren zu der präzisen Schätzung gratulieren!

1 Monat nach Verkaufsstart sind von den 71 Tickets noch 7 übrig, die werden bis Monatsende sicher auch weg sein. Da ja sicher der Ausverkauf auch das Ziel war, finde ich das für eine Veranstaltung, die zum ersten Mal statt findet, absolut klasse! Ein gutes Omen für das Treffen.

Guten Morgen zusammen,

der IOBroker-Adapter funktioniert bei mir seit Jahren problemlos. Seit ein paar Wochen hat die KLF200 bei mir herumgezickt, so dass sie nicht mehr erreichbar war und der Adapter sie natürlich auch nicht mehr erreichen konnte. Da ähnliche Symptome hier bei anderen Nutzern auch immer mal wieder vorkommen, poste ich hier, wie ich das lösen konnte.

Aufgefallen war mir, dass der Adapter sich nicht mehr verbinden konnte. (Was das ausgelöst hatte, kann ich nicht sagen, ich automatisiere die Dinger für den Sommer, so dass mir die Suche nicht eilig war.)

Ich habe dann bemerkt, dass auch die von der Fritz Box über DHCP vergebene IP Adresse der KLF nicht mehr erreichbar war. Auch mehrfacher Neustart hat dieses Problem nicht beseitigt.

Als ich mich über den WIFI Hotspot der KLF mit dieser verbunden habe, ist mir aufgefallen, dass von allen denkbaren IP Adressen sich diese als WLAN Adresse bei mir ausgerechnet 192.168.0.1 einrichtet. Das darf sie natürlich machen, wenn sie Hotspot ist. Leider ist in der KLF diese Adresse nicht änderbar. Man kann lediglich die LAN Adresse einrichten bzw. per DHCP vergeben. Ebenso leider ist 192.168.0.1 gleichzeitig die Adresse meiner Fritzbox. Die wäre dort leicht änderbar, aber mit großen Auswirkungen auf mein Netzwerk. Meine Fritz Box weißt der KLF die 192.168.0.29 zu. In den Netzwerk Einstellungen der KLF ist DHCP aktiviert und kann ich die 29 als ihre Netzwerk Adresse sehen. Ebenso, dass für den LAN Anschluss als Router die 192.168.0.1 eingetragen ist. Natürlich kommt sie mit diesen Einstellungen aber nicht nach draußen, weil das ja ihre eigene IP Adresse für das WIFI ist.

In den Netzwerk Einstellungen der KLF ist eingerichtet, dass LAN immer aktiv ist (das Ding steht direkt neben meinem IOBroker und da ist mir ein Kabel lieber) und WIFI nur während der ersten 10 Minuten. Die Einstellung erscheint mir sinnvoll: Die Konfiguration ist nur über WIFI möglich. Würde man das ausschalten, wäre möglicherweise ein Werksreset nötig, um wieder Änderungen durchführen zu können.

Die Lösung war sehr simpel: Nachdem ich die KLF mehrere Minuten (so ca. 5) vom Strom getrennt und neu gestartet habe, konnte ich sie wieder anpingen und die Adresse wurde mir in der Fritz Box wieder als benutzt angezeigt. Trotzdem konnte sich zunächst der IOBroker Adapter aber immer noch nicht verbinden, was an der vergurkten WIFI Adresse liegen dürfte. Nachdem sich das WIFI 10 Minuten abschaltet, funktioniert die Kiste wieder wie früher.

@oxident
Dein Post hat mich auf die Idee gebracht, seit gestern diese Limits auch mal zu protokollieren.
Ich denke nicht, dass es einen Weg gibt, die aktuelle Ladegeschwindigkeit nur aus den CHARGE_LIMIT Werten heraus zu lesen. Bei mir stand in allen CHARGE_LIMITs seit gestern nie ein Wert >12A drin. Der Speicher hat aber heute mit voller Geschwindigkeit (2,5kW) geladen bis 75%.

Ab 75% wurde heute die Geschwindigkeit halbiert (genug Überschuss war vorhanden), die CHARGE_LIMITs blieben aber bei 12A. Ab ca. 85% wurde dann die Ladung langsamer und ab da sind dann auch die CHARGE_LIMITs in den einstelligen Bereich.

Die Reduzierung bei 75% sehe ich selten, meistens lädt er ungebremst bis 85%. Die Temperatur der Module lag bei 31-36°C. Ich dachte, dass da noch was aufgrund der Temperatur gedrosselt würde, aber bei 36°C hätte ich das eigentlich noch nicht erwartet.

Irgend welche Einflussfaktoren scheint es noch zu geben.

Vielen Dank für das coole Treffen!

Die Folien zum Heizungsvortrag, das Ganze nochmal als Video und einen Platz, um das Thema "Heizen mit IOBroker" zu diskutieren, findet Ihr hier:

Heizungsregelung mit IOBroker

Hallo @oxident

danke für Deine Nachricht. Ich glaube, jetzt haben wir aneinander vorbei geredet.

@oxident sagte in Adapter für VELUX KLF-200 Interface:

@hansjochen Nee, glaube ich nicht. Mein KLF-200 ist auch 2-3 Jahre alt und die Steuergeräte sind auch recht verschieden (mal Solar, mal Stromanschluss).

Klingt zwar blöd, aber es sieht mir ein wenig danach aus, als könnte der KLF defekt sein. Spontan fällt mir erstmal nur die "Holzhammermethode" ein, also alles ablernen, KLF auf Werkseinstellungen und dann wieder von vorne los.

Du beziehst Dich hier auf einen alten Post von mir, in dem ich Problem und Lösung beschrieben hatte. Mein KLF funktioniert seit dem Neustart.

Mit meinem Post von gestern hatte ich mich auf die Diskussion zwischen Dir und @MiSchroe zum "refreshProduct" bezogen. Ihr hattet vermutet, dass "refreshProduct" abhängig von der Fernbedienung benötigt wird. Ich habe an unterschiedlichen Fenstern beide Fernbedienungsarten und der Refresh kommt bei mir an allen Fenstern automatisch, wenn ich das Fenster über die Fernbedienung bewege. Am Typ der Fernbedienung scheint es also nicht zu liegen. Ist jetzt vielleicht nicht so wichtig - wenn es irgendwo nicht geht, gibt es ja jetzt die Refresh Funktion.

@oxident
Vertauscht scheinen sie bei mir nicht. Die CHARGEs werden niedriger, wenn der Akku voller wird. Wenn er leer ist, sind sie ebenfalls halbiert (also 6A).

Allerdings verstehe ich die DISCHARGEs noch weniger. Die sind die meiste Zeit bei -24A, bis zum leeren Speicher letzte Nacht. Danach sind sie dann runter auf um die -15A. Und dann bei immer noch leerem Speicher wieder hoch auf um die -20A - mit großen Unterschieden: Die einzelnen Module liegen bei -17A bis -22A.

Die Verläufe der CHARGEs fand ich recht plausibel, abgesehen davon, dass es zusätzlich noch andere Beschränkungen zu geben scheint.

@Schimi

Okay, das fällt dann wohl in die Kategorie "gut gemeint"

Das Verhalten von Hand nachzubilden, solange der Adapter hier noch auf Strings basiert, wäre ziemlich müßig. Echarts macht das ja schon automatisch, wenn @ReblausGT , wie er es hier angedacht hat, den Adapter auf Datumsobjekte umstellt. Das sollte dann aber synchron passieren: Im Adapter und in den Templates.

@schimi sagte in TibberLink Adapter:

scheint wohl nicht geklappt zu haben....

Schwer zu sagen. Falls Du das hier erreichen wolltest, hat es geklappt:

Was ist denn Dein Ziel?

@schimi sagte in TibberLink Adapter:

ist das was?

Kunst am Bau?

@rewenode

Reiner Zufall. Habe die Zeremonie selbst erst gestern Abend durchgeführt

Schade, dass Hyundai/Kia da so einen Käse mit den Captchas eingebaut hat. Für Automatisierer ist das eine völlig unnötige Hürde.

Gutes Gelingen!

@reblausgt

Gute Frage. Für mich war das mein erster Berührpunkt mit ECharts. So, wie es jetzt ist, passt es bei mir mit der Skalierung relativ gut. Je nach Fenstergröße auf unterschiedlichen Größen wählt ECharts hier recht vernünftig, welche Punkte auf der Skala weggelassen werden. Beispielsweise sehe ich in dem kleinen Ausschnitt, den ich dem Chart in meiner Visualisierung gönne, die vollen Stunden und wenn ich das Chart alleine im Browser Fullscreen öffne auch die Viertelstunden.

Ich habe mir aber jetzt gerade eine Echart Demo angeschaut (https://echarts.apache.org/examples/en/editor.html?c=area-time-axis), da lässt sich in dem Chart mit dem Mausrad zoomen. Das geht bei uns nicht. Ob die String-Skala der Grund ist, weiß ich nicht. Das könnte ich mir aber vorstellen.

Was wohl in jedem Fall schöner wäre: Es wäre halt der Weg, den ECharts für Zeitserien vorsieht. Das Datum würde nicht ständig wiederholt, sondern nur einmal angezeigt und ansonsten nur die Uhrzeit. Die X-Achse wäre also etwas übersichtlicher.

Mir persönlich wäre die Änderung nicht wichtig, das Template wäre aber leicht anzupassen. Ich kann da bei Bedarf auch gerne unterstützen. Wer sich beispielsweise veränderte Tooltips eingebaut hat, müsste halt selbst noch mal Hand anlegen. Ich würde aber vermuten, wer das hinbekommen hat, wird auch an dem Umbau nicht scheitern.

Übrigens: Ich vermute, dass es einige Nutzer gibt, die mit ECharts keine Berührpunkte hatten und die in ihrer Automatisierung nur für die Tibberpreise benutzen. Dann ist es schon etwas knifflig, die URL für die generierten Charts herauszufinden und die Templates in den Editor zu kopieren könnte auf manche auch etwas abschreckend wirken. Vermutlich benutzen die Meisten eines der Standard Templates ohne Veränderungen.

Da könnte es aus meiner Sicht helfen, wenn die URL im Adapter direkt angezeigt würde und es eine Auswahl der Art "Standard Darstellung", "alternative Darstellung" oder "benutzerdefinierte Darstellung" gäbe und damit der ganze Flexchart Hintergrund samt Erklärungen, Beispielen und Editor nur sichtbar wird, wenn man zuvor "benutzerdefiniert" ausgewählt hat.

@rewenode

Die von Dir verlinkte Linux Anweisung
https://github.com/Hyundai-Kia-Connect/hyundai_kia_connect_api/wiki/Kia-Europe-Login-Flow
funktioniert bei mir unter Linux auch mit Hyundai problemlos. Das Einzige, was ich ändern musste, war den Pfad zum Hyundai Skript zu verwenden, also

wget -O ApiToken.py https://raw.githubusercontent.com/Newan/ioBroker.bluelink/refs/heads/master/py/HyundaiFetchApiToken_2.py

und dementsprechend dieses nachher ausführen:

python3 ApiToken.py

Unter MacOS stelle ich mir das ähnlich vor. Ob und wie man da aber erst mal wget installieren muss oder es dafür andere Hausmittel gibt, weiß ich nicht. Sonst sollte es auch reichen, das Skript mit einem Browser zu öffnen und unter dem Namen "ApiToken.py" abzuspeichern.

Hi @reblausgt ,

danke für Dein Feedback.

Klar, bau es gerne ein. Ich habe das ja hier gepostet, weil ich dachte, dass es auch für andere praktisch sein kann.

Hallo zusammen,

die Flexcharts / ECharts Integration in den Tibberlink Adapter ist absolut klasse. Ich habe mir das Standard-Template so angepasst, dass im Diagramm die aktuelle Zeit mit einer vertikalen Linie markiert wird.
Sieht dann so aus:

Falls das jemand nutzen möchte:

{
	backgroundColor: "rgb(255, 255, 255)",
	title: {
		text: "Tibber Preis",
		textStyle: {
			color: "#ffffff"
		}
	},
	tooltip: {
		trigger: "axis",
		axisPointer: {
			type: "cross"
		}
    },    

	grid: { // Randabstände
		left: "10%", right: "4%", top: "8%", bottom: "8%"
	},
	xAxis: {
		type: "category",
		boundaryGap: false,
		data: %%xAxisData%%
	},
	yAxis: {
		type: "value",
		axisLabel: {formatter: "{value} €"},
		axisPointer: {
			snap: true
		}
	},
	visualMap: {
		min: 0.2,
		max: 0.4,
		inRange: {
			color: ["green", "yellow", "red"] // Verlauf von grün über gelb nach rot
		},
		show: false
	},
	series: [
		{
			name: "Preis",
			type: "line",
			step: "end",
			symbol: "none",
			data: %%yAxisData%%,

			markArea: {
				itemStyle: {
					color: "rgba(120, 200, 120, 0.2)"
				},
				data: [
					%%CalcChannelsData%%
				]
			},
			markLine: {
            data: [   
            {
               name: 'jetzt', xAxis: ("0"+new Date().getDate()).slice(-2)+"."+("0"+(new Date().getMonth()+1)).slice(-2)+"." + "\n" + ("0"+new Date().getHours()).slice(-2)+":"+("0"+(Math.floor(new Date().getMinutes()/15)*15).toString()).slice(-2)}
               
                  ]   
            }
	    }
    ]

};

Guten Morgen,

ich bin gerade auf diesen Thread gestoßen und habe das für mich sehr ähnlich gelöst wie Icebear mit dem hier geteilten Script. Ich möchte hier eine Idee teilen, die aber anders als dieses Script nicht einfach für jeden Senec Besitzer möglich ist und dann auch für jeden etwas anders. Vielleicht mag das aber der eine oder andere für sich auch umsetzen.

Das Summieren der Speicher Werte funktioniert natürlich nur, solange ioBroker läuft. Das wird meistens der Fall sein. Ich ermittle seit Jahren die summierten Verbrauchswerte meiner Wärmepumpe auf die gleiche Art mit gutem Ergebnis. Durch Updates oder Wartung verlorene Verbrauchswerte spielen dort in meiner Statistik eigentlich keine große Rolle. Allerdings: Wenn der Speicher gerade mal nicht kommunizieren mag (NPU Fehler oder sonstwas), gehen ja auch Werte verloren.

Für die Einspeisung und den Netzbezug habe ich Zähler, die ich über einen Tibber Pulse auslese. Die haben geringere Auflösung (die Nachkommastelle wird nicht übermittelt), sind aber sonst natürlich sehr genau und ausfallsicher. Deswegen verwende ich für diese Werte die Zählerwerte und berechne nur Hausverbrauch und Produktion so, wie im in Icebears Skript.

Die Möglichkeiten sind hier vielfältig, je nach Installation und Alter der PV Anlage messen die Zähler etwas anderes. Der Weg ist folgender:

• Ich habe einen Cronjob, der mir jede Stunde, jeden Tag, jeden Monat und jedes Jahr den Zählerstand in einen Datenpunkt kopiert. Bei Skript Neustart prüfe ich den Zeitstempel dieser Zählerwerte und aktualisiere sie, falls sie älter als erwartet sind (dann natürlich zu spät, aber das ist besser, als einen ganzen Jahreswechsel zu verpassen).
• Ein Trigger auf jeden Zähler berechnet die Differenz aus aktuellem Zählerstand und Zählerstand zu Beginn der aktuellen Stunde, Monats, ... und speichert das als Verbrauchswert in diesem Zeitraum.

Die beste Lösung wäre vermutlich eine Mischung der beiden Vorgehensweisen: Die dynamische Berechnung wie in Icebears Script (wegen der höheren Auflösung) mit Korrektur auf Basis der Zählerstände, soweit erforderlich.

@grisu73 sagte in Heizungsregelung mit IOBroker:

@hansjochen Ich warte jetzt mit der Automatisierung , bis die Hydraulik geklärt ist.

Ja, das ist sinnvoll. Solange Du die Heizung nicht manuell dazu bringst, dass sie das tut, was sie soll, kannst Du sie auch nicht automatisieren. Von den Gesprächen mit den Handwerkern lässt sich sehr viel lernen. Ich hatte mit meinen Heizungsbauern immer gute Gespräche, die ich in Form von Fragelisten gut vorbereitet habe. Wenn ich dann gezielt auf Anomalien gezeigt habe, die ich mir nicht erklären konnte, konnten sie es mir manchmal erklären und manchmal haben sie dadurch Fehler in der Hydraulik gefunden, die sie behoben haben. In beiden Fällen hat es mich weiter gebracht.