Hallo zusammen,
hat hier jemand schon den AC-Thor 9s eigebunden und am laufen?
@c.lehne @stefan.feilmeier macht es sinn, den als extra Nature / neues Nature eventuell “SmartHeater” anzulegen?
Da hätte ich dann nämlich schon 2 davon 
Eventuell auch mit einem neuen Widget in der UI bezüglich der Temperatur einstellen?
Grüße
Hallo @Sn0w3y,
danke für die Anregung. Ich kenne den AC-Thor, meines Wissens wurde er aber noch nicht eingebunden.
Bisher haben wir im Bereich Wärme überhaupt noch keine Natures definiert. Die entsprechenden Controller arbeiten hier ja lediglich direkt auf Relais. Also ja: Natures in dem Bereich wären sinnvoll. Im Idealfall sogar nur eine, die so generisch gestaltet ist, dass sie für “Heizstab an 3 Relais” und “Stufenloser Heizstab” funktioniert. Das könnte z. B. mit einem Channel CONTROL_STEP_SIZE in [W] funktionieren.
Wie sollen wir weiter vorgehen? Oder startest du einfach mal mit einer Modbus-Implementierung - vorerst ohne separate Nature?
Gruß,
Stefan
Hallo Stefan,
sobald ich den AC-Thor habe würde ich mal “einfach so” starten, werde aber dann im nächsten Step mal versuchen das alles zusammenzulegen auf eine Nature mit dem Channel, den du vorgeschlagen hast.
Ich bekomme noch bald einen 2. Heizstab, den man auch mit Modbus TCP ansteuern kann. Dann würde ich das (wenn ich den 2. habe) in Angriff nehmen.
Ich denke das hört sich gut an
Grüße
BTW: Wenn du mal kurz in die Keba-Phase Switch Logik in den PR auf GitHub schauen könntest wäre das toll
Wäre es eventuell nicht sogar gut, den Controller “IO-Heatingelement” zu erweitern um diesen einen Channel und dann in dem Controller eine Config setzen e.g. “PWM-Heater” Boolean, sodass dieser automatisch dann die Logik des PWMs nutzt und dann die Phasen des Heizstabes damit bedient ?
Das wäre doch ein guter Ansatz, oder?
Dazu hätte man dann auch noch den Vorteil, dass man die aktuelle UI nutzen kann, um die Befehle in der UI trotzdem weiterhin auf “ON”, "OFF, und “AUTOMATIC” stellen könnte, um das ganze dann manuell zu steuern, oder ?
Zudem würden wir dann einen Controller haben für Smarte Heizstäbe UND für “dumme” Heizstäbe über Relaisboards in einem
Grüße !
Kurze Info zum AC-Thor: Wir haben eine AC-Thor Implementierung als PR an unser eigenes Repo gestellt. Wenn das interne Review durch ist, wird daraus auch ein PR gegen das öfftl. Repo gestellt werden. Leider dauern PR bei uns immer viel Zeit. Für das schnelle Tempo in der Community manchmal zu viel Zeit, daher dieser Hinweis.
Der PR beinhaltet eine einfache Modbus-Anbindung des AC-Thor. Dieser kann über drei DigitalInput Eingänge gesteuert werden und schaltet dann wahlweise ein, zwei oder drei Phasen zu. Diese Art der Implementierung nutzt wenig Features des AC-Thor bietet aber den Vorteil, dass sie sehr stabil und zuverlässig ist und direkt mit dem Controller IO Heating Element gesteuert werden kann.
Das sieht dann so aus:
Leider haben wir aktuell kein AC-Thor mehr in Betrieb. Der Code ist also seit etwa einem halben Jahr nicht mehr getestet. Ich sehe hier aber kein Grund warum es nicht funktionieren sollte.
Hallo Christian,
Aber dann hat man ja eigentlich gegenüber einem “dummen” Heizstab gar keine Vorteile 
Siehe auch meinen Kommentar hier:
Ich arbeite aktuell an einer “SmartHeater” Nature, sodass wir die Smarten Heater mit Modbus und mit PWM ansteuern können (mit Seperatem Controller ähnlich wie Controller IO Heating Element)
Grüße !
Hallo nochmal Stefan,
kannst du mir bitte einmal kurz erklären, wie du dir die neue Nature vorstellen kannst und wie Sie in einem Workflow aussehen soll?
Wie gehe ich da am besten systematisch vor um eine “SmartHeater” Nature zu implementieren ?
Grüße !
So genau weiß ich das selbst noch nicht. Ich hatte mir das ungeführ so vorgestellt wie bei ManagedSymmetricEss:
Eine Methode (und/oder Channel) CONTROL_STEP_SIZE könnte z. B. für einen AC-Thor den Wert 1 [W] zurückgeben. Für einen dreiphasigen 4,5 kW Heizstab den Wert 1500 [W]. Mit diesen Informationen könnte man dann einen Controller und ein UI dynamisch aufbauen.
