UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[crycode]

@hg6806 sagte in Rotex HPSU / Daikin Altherma Wärmepumpe über ioBroker.canbus:

Auf jeden Fall habe ich bei den CAN Objekten keinen TA2 Wert.
Ich kann ihn zwar über canbus.0.680.fac105 abfragen, aber wo wird der eingetragen?

TA2 fehlte tatsächlich noch, genauso wie TDHW2.
Habe die beiden jetzt in der "latest" Konfiguration auf GitHub hinzugefügt (180.fac105 und 180.fac106). Bitte diese laden, testen und mir eine kurze Rückmeldung geben. :-) Wenn alles funktioniert, würde ich die "latest" dann mit neuer Versionsnummer kennzeichnen.

[hg6806]

@crycode
Hat geklappt.
Vielen Dank!

[crycode]

@hg6806 Perfekt, damit ist die bisherige latest Konfiguration jetzt als 1.5.0 für alle als Vorauswahl zum Import verfügbar.

[cb187]

Wie das hier läuft😏👍

[cb187]

@crycode hast du ne Ahnung wie ich Can in proxmox lxc durchgereicht bekomme?

[crycode]

@cb187 sagte in Rotex HPSU / Daikin Altherma Wärmepumpe über ioBroker.canbus:

hast du ne Ahnung wie ich Can in proxmox lxc durchgereicht bekomme?

Nicht direkt, aber das can-Interface ist im System eine Netzwerkschnittstelle.Eventuell kannst du dieses exklusiv an den LXC Container weiterreichen? Alternativ, wie weiter oben für Docker schon erwähnt, per UDP-Übertragung zwischen Host und Container mittels Cannelloni.

[cb187]

@crycode joa hab schon gegoogelt mit der Netzwerkschnittstelle nichts gefunden.Hatte mal wieder langeweile und wollte mal testen ob ich das hinbekomme.Naja mit Canneloni wird das auch nicht gehn weil das Hauptsystem von Proxmox keine can schnittstelle in dem sinne findet.

[hg6806]

Bei mir habe ich gesehen, dass der CAN Adapter mit der Rotex HPSU eine recht hohe CPU Auslastung hat.
Im Log habe ich folgendes gefunden. Kann ich das ignorieren oder kann das der Grund sein?

canbus.0
2022-04-12 22:59:45.344	info	undefined is not a valid state value for id "canbus.0.680.fac101"

canbus.0
2022-04-12 22:59:38.595	info	undefined is not a valid state value for id "canbus.0.680.0e-set"

canbus.0
2022-04-12 22:59:36.222	info	undefined is not a valid state value for id "canbus.0.680.fa0141"

canbus.0
2022-04-12 22:59:36.221	info	undefined is not a valid state value for id "canbus.0.680.fa0115"

canbus.0
2022-04-12 22:59:36.219	info	undefined is not a valid state value for id "canbus.0.680.28"

canbus.0
2022-04-12 22:59:35.343	info	undefined is not a valid state value for id "canbus.0.680.fac101"

canbus.0
2022-04-12 22:59:34.258	info	undefined is not a valid state value for id "canbus.0.680.fa012b"

canbus.0
2022-04-12 22:59:33.702	info	undefined is not a valid state value for id "canbus.0.680.fa012a"

canbus.0
2022-04-12 22:59:33.083	info	State value to set for "canbus.0.680.fa0129" has to be type "boolean" but received type "string"

canbus.0
2022-04-12 22:59:32.912	info	undefined is not a valid state value for id "canbus.0.680.fa0129"

canbus.0
2022-04-12 22:59:25.341	info	undefined is not a valid state value for id "canbus.0.680.fac101"

canbus.0
2022-04-12 22:59:12.868	info	undefined is not a valid state value for id "canbus.0.680.fac101"

canbus.0
2022-04-12 22:59:02.809	info	undefined is not a valid state value for id "canbus.0.680.fac101"

canbus.0
2022-04-12 22:58:52.808	info	undefined is not a valid state value for id "canbus.0.680.fac101"

canbus.0
2022-04-12 22:58:50.109	info	undefined is not a valid state value for id "canbus.0.680.fa066e"

[cb187]

@hg6806 hi das habe ich zb nicht.Haste zu schnelle Abfragewerte vielleicht eingegeben oder bei set automatische abfrage?

[crycode]

@hg6806 Welche Version vom Adapter hast du installiert? Das sieht mir nach einem Problem aus, das es mal in einer alten Version gab.
Zumindest erklärt das die hohe CPU Last, da die States alle fälschlicherweise immer neu geschrieben werden.

[hg6806]

@crycode
Die 1.3.0, die über den Admin aktuell angeboten wird. Gibt es was neueres über Github?

@cb187 Einige Werte frage ich alle par Sekunden ab, was eigenbtlich kein hoher Traffic bedeuten müsste.

[crycode]

@hg6806 1.3.0 ist aktuell, wobei es danach schon noch einen Fix für mögliche Probleme mit fehlenden Werte für das automatische Setzen gab. Vermute fast das wird auch das Problem bei dir sein.

Ich mach heute Abend oder morgen mal eine neue Version 1.3.1 fertig. Bis dahin kannst du mal prüfen, ob du bei den States mit aktiviertem automatischen Setzen auch jeweils einen Wert dazu angegeben hast. Bei den "abfragen" States muss der Haken bei "Zu setzender Wert" gesetzt sein/werden.

[hg6806]

OK, ist der Fix auf Github schon verfügbar? Dann kann ich das schon mal testen.

[crycode]

@hg6806 Ja, ist schon auf GitHub im master-Branch, allerdings noch mit der Versionskennung 1.3.0

[hg6806]

@crycode
So, die undefined Meldungen sind weg, Auslastung ist aber noch immer bei 29% vom Gesamtsystem. Vorher waren es ca. 45%
Ich habe nochmal alle 680er Werte überprüft. Der minimalste Abfragewert liegt bei alle 10.000msec.sonst die meisten 60.000msec

[crycode]

@hg6806 Wie viele Werte fragst du denn regelmäßig ab? Kommt die CPU-Last vom Prozess des Adapters selbst?

[hg6806]

@crycode
Hmmm, grob würde ich sagen 30St. +/- alle 10/60 Sec.

[hg6806]

Moin!

Bei mir ist gerade ein kleiner GAU eingetreten.
Und bin ich gerade verreist und dann komme ich auf ioBroker-Pi nicht mehr drauf.
Pingen geht, aber kein VNC, SSH, ioBroker, etc.
Die autarke Solarthermie pumpt jeden Tag mehr und mehr Wärme in den Speicher, was ich aber nicht regulieren kann. Die Werte der TA UVR Anlage kann ich nur abfragen. Und ich hoffe, die Übertemperaturwerte ordentlich gesetzt zu haben.
Ich regle falls überhaupt mal eine zu hohe Temperatur eintritt meist damit, in dem ich z.B. im Keller die Heizungsventile öffne.
Das funktioniert zwar über Homematic, die Rotex an sich macht aber mal wieder keinen Zappen.
Womöglich durch das nicht laufende CAN, hat es die Rotex in Mitleidenschaft gezogen.
Ich hatte auch öfters mal Fehler E81. Es kann auch sein, dass generell das CAN Kabel zu lang oder die Verdrillung nicht ausreicht.
Das ganze CAN-Zeug läuft leider sehr unstabil, bei dem FHEM-Raspi war das deutlich besser.
Auf jeden Fall ist die Situation gerade sehr ungünstig.
Da ich auch nicht weiß wann wir nach Hause kommen muss ich wohl einen Nachbarn beauftragen, RasPi und Rotex (bei roter Anzeige) stromlos zu machen und wieder einzuschalten.
Generell werde ich auch nie wieder eine Rotex einbauen. Diese Gefrickel mit der Solarthermie ist echt eine Katastrophe, mal ganz abgesehen von vielen anderen schlechten Eigenschaften.
Es ist eigentlich ein Unding, dass eine Heizung in einen solchen Zustand fällt, dass sie gar nichts mehr macht. Gleiches hatte ich übrigens mal im Winter. Die Heizung hatte ich 1 Woche auf Standby geschaltet, dann 4 Tage vor Anreise wieder eingeschaltet und wollte alles hochfahren. Das ging aber nicht mehr, da die Speichertemperatur unter 35° oder 30° abgesunken war und dann erst der Heizstab aktiviert werden muss. An diesem war aber eine Sicherung ausgelöst (warum auch immer), nichts ging mehr, aber im Display war alles ok. Bis ich das gefunden hatte, war im ganzen Haus nur noch 10°C!

[Mic208]

Hallo @hg6806,
ja das kenne ich auch. Inzwischen habe ich zwei Watchdogs installiert, nachdem ich die Rotex stromlos mache und dann wieder neustarte (via HomeMatic Leistungsmesser mit -schalter):

1. Kontrolle der Speichertemperatur via HomeMatic Sensor und Abgleich mit dem CAN-Bus Wert. Bei Differenz größer einem Grad.
2. Fehler 9039.
   Jeder Fehler kommt gefühlt ca. ein Mal pro Monat vor. Mal ist monatelang Ruhe, mal dreimal die Woche.
   Generell würde ich mich deiner Aussage anschließen, zumindest bei meiner Rotex von 2013.
   Komischerweise kommt es auch wirklich häufig im Urlaub vor. Ganz schlecht für den WAF. Zum Glück kann ich via VPN auch mit dem Mobilphone darauf einwirken. Ohne Homematic als Backup wäre ich da sonst aufgeschmissen gewesen.

Mic

[hg6806]

@mic208
Die Speichertemperatur kann ich nach über die Solarthermieanlage auslesen. Die liegt gerade bei 66°, gleich springt die Thermie wieder an...
Was schaltest du denn über den Homematic Schalter? Die ganze Rotex? Welche Leitung?

Ja, habe auch ein 2013er Modell.