DIY-UP-Aktor mit Leistungsmessung

[Ing-Dom]

Hallo zusammen,

ich tüftle schon seit einiger Zeit an einem UP-Schaltaktor mit optionaler Leistungsmessung: ACT-1ACM

Erste Muster-PCB hab ich bereits da und auch den Mess-IC hab ich schon auf dem Breadboard ausprobiert (ohne 230V, natürlich).

Aber erstmal zur Vorstellung:

2021-03-16 21_46_52-Window.png 2021-03-16 21_47_32-Window.png 2021-03-16 21_48_13-Window.png

KNX-Anschaltung durch die NanoBCU, die kleine Schwester der MicroBCU2 mit NCN5120. VCC2 = 14.4V.
SAMD21 als MCU, mit SPI Flash. FW als "DualStack" mit Konnekting und thesing-stack geplant (compile-Option).
Bistabiles High-Inrush Relais (500A !) mit 16A Nennstrom und reinforced insulation.
1000µF C für das Relais mit Ladeschaltung.
Gehäuse aus dem Drucker.

Die Leistungsmessung ist eigentlich das kniffeligste. Nach langer Recherche hab ich mich für den ACS37800 vo Allegro entschieden, weil:
4.8kV Isolation. Das heißt, keine externe Isolation, DC-DC Wandler etc notwendig. Der Strom wird über Halleffekt gemessen, die Spannung ist eine normales Widerstandsnetzwerk.

Und genau mit der Spannungsmessung hab ich aktuell Probleme, da komme ich nicht so recht weiter.
Der IC misst einfach nur Spannung zwischen zwei Pins im Bereich +-350mV.
Für "floating gnd", also von der zu messenden Spannung isolierte Versorgung des ICs gibt das DB folgende Schaltung:

2021-03-15 13_13_12-Window.png

2021-03-15 13_36_25-Window.png

Ich hab zuerst die GND-Verbindung an VINN übersehen (die fehlt dann auch auf meinen Mustern) und irgendwann ist mir dann aufgefallen, dass VINN / VINP dann ja in RIchtung 115V Potentialunterschied zur MCU (KNX) Seite haben. Kann nicht sein... dann hab ich die GND-Verbindung entdeckt und verstanden, dass dadurch (ohne Stromfluss!) das isolierte Potential hochgezogen wird, das bedeutet im Fall der gezeigten Versorgung der MCU aus einem dezidierten isolierten Supply nur dieses. Siehe auch https://knx-user-forum.de/forum/%C3%...-und-isolation.

Aber hier würde ja das komplette KNX-Netzwerk, das ja isoliert ist, hochgezogen. Gefährlich ist das nicht, weil durch die 2 Megaohm nur wenige µA Strom fließen, das ist ungefährlich und nicht spürbar.
Weil aber jedes Netzteil gewisse Ableitströme hat wird der Strom nicht nur den Pfad über die RIsos und Rsense nehmen, sondern auch über KNX-GND. Das verfälscht dann die Messung!

Ich frage mich nun ernsthaft, ob man das iVm KNX überhaupt so bauen kann. Zum Einen aus der Sicht KNX (Potentialanhebung) und aus der Sicht der Qualität der Messung.

[Ing-Dom]

wow, ich muss sagen das Interesse überrascht mich. Im negativen Sinne.

Neueste Erkentnisse: So ohne Weiteres wird es nichts mit der Spannungsmessung, und damit auch mit der Leistungsmessung.

Die Messmethode ist ungeeignet wenn die MCU-Seite ein "SELV-Netz" ist.

Es gäbe nun verschiedene Lösungsansätze.

1) auf die Spannungsmessung verzichten und mit dem ACS37800 nur den Strom zu messen. Wenn man U = 230V antizipert und einen reinen Sinus, passt das schon ganz gut. Die Stromaufnahme diverser Netzteile jedoch ist nicht sinusförmig und daher sehr wahrscheinlich stark fehlerbelastet.

2) Eine zweite Potentialinsel, getrennt von der MCU für den ACS37800 aufbauen. I2c isolieren und über einen isolierten DCDC-Wandler versorgen. Braucht Platz, kostet Geld. Wenigstens ist nur eine Funtkionsisolierung, keine Schutzisolierung nötig, denn die leistet ja bereits der ACS bzw. die MegOhm - Rs.
Es ist zweifelhaft, ob man das noch auf dem PCB unterbringt!

3) Wenn man schon eine zweite Potentialinsel macht, könnte man die auch gleich mit 4kV isolieren und einen ganz anderen IC einsetzen. Es gibt wesentlich günstigere power meter IC (unter 1 USD) die jedoch keine Potentialtrennung haben. Das wäre aber wieder ein hoher Aufwand.


Ich tendiere aktuell zu 1).
Schaltaktor ohne Messung, optional mit reiner Strommessung über den ACS37800.

Warum? Ich zweifle den Nutzen einer genaueren Messung an. Um Energieverbräuche zu messen ist der IC eh ungeeignet, im <20W Bereich hohe Fehler.
Weiterhin zweifle ich an, dass die Messung überhaupt so oft gebraucht wird.

Was ist eure Meinung dazu?

[jeff25]

Also ich lese schon mit und finde dein Vorhaben immer noch super!

[starwarsfan]

Hallo miteinander

wow, ich muss sagen das Interesse überrascht mich. Im negativen Sinne.

Naja, vielleicht geht's ja nicht nur mir so, von derartigen nicht-SELV Basteleien besser die Finger zu lassen...

[mumpf]

Um mal positives Interesse zu bekunden: Ein UP-Schaltaktor mit Strommessung wäre schon der Hammer, weil es so was sonst nicht gibt. Dabei kommt es (zumindest mir) nicht darauf an, dass ich irgendwelche Verbräuche messe, sondern nur dass ich verschiedene Verbrauchslevel unterscheiden kann. Also ist die Spannung nicht wichtig. Und wenn es auch noch auf der SAMD-Plattform läuft und somit dann der knx-Stack von thesing darauf läuft (sprich: Es gibt eine ETS-Anbindung), finde ich das noch reizvoller.

Allerdings würde es für mich nur interessant sein, wenn die Reaktion auf ein eingeschaltetes Gerät <1 Sekunde wäre. Also müsste der Messchip schnell genug reagieren. Hast Du da Erfahrungen?
Und... würdest Du dann auch nur Hardware verkaufen, mit den notwendigen Infos (welche GPIO für was verwendet werden usw.) damit man selber die Firmware implementieren kann? Ich würde für so was ja eher meinen Stack-Fork nehmen und mein Logikmodul mit reinpacken .

Gruß, Waldemar

[mumpf]

Noch was: Wo sind die Klemmen für den 230V-Anschluß? Die KNX-Klemme hab ich gesehen...

Gruß, Waldemar

[Ing-Dom]

Allerdings würde es für mich nur interessant sein, wenn die Reaktion auf ein eingeschaltetes Gerät <1 Sekunde wäre. Also müsste der Messchip schnell genug reagieren. Hast Du da Erfahrungen?

mit dem konkreten Chip (noch) keine, aber ich würde stark davon ausgehen dass da nur wenige ms Verzögerung vom Stromfluss bis zur MCU sind.

Und... würdest Du dann auch nur Hardware verkaufen, mit den notwendigen Infos (welche GPIO für was verwendet werden usw.) damit man selber die Firmware implementieren kann? Ich würde für so was ja eher meinen Stack-Fork nehmen und mein Logikmodul mit reinpacken .

Ich würde wie bei allen meinen Schaltungen auf jeden Fall den Schaltplan veröffentlichen und wahrscheinlich auch die Firmware als Quelle. Insofern spricht überhaupt gar nichts dagegen eine eigene Firmware dafür zu machen. Ich begrüße das ausdrücklich, wobei ich es gut fände wenn man an einem Strang zieht als wenn jeder für sich eine alternative FW baut.

Noch was: Wo sind die Klemmen für den 230V-Anschluß? Die KNX-Klemme hab ich gesehen...

Für 230V Klemmen war kein Platz. Daher werden die Anschlüsse (L-IN, L-OUT und ggf. N) als Litzen nach außen geführt.
Die Befestigung der Litzen am PCB ist etwas, was noch verbessert werden will - aktuell sind da nur Lötpads, aber das ist nicht ideal.

[mumpf]

Hi,

verstehe mich bitte nicht falsch, ich habe höchsten Respekt vor Leuten, die zuverlässige Hardware bauen können. Litzen sind natürlich auch eine Option, hab ich gar nicht bedacht. Würde man in der UP-Dose noch was machen müssen, damit 230V und KNX zuverlässig getrennt sind? Oder anders gesagt: Hast Du auch ein Gehäuse im Sinn? Damit der 230V-Teil nicht frei in der UP-Dose "rumfliegt"?

Zur Software: Natürlich könnte ich auch die ETS-Basierte Software übernehmen und veröffentlichen (mache ich sowieso). Da müssten wir nicht parallel oder gar konkurrierend arbeiten. Ich habe nur keine Erfahrung mit KONNEKTING und könnte da nicht unterstützen. Mit Matthias Masifi hab ich immer so gearbeitet, dass ich die Sensorimplementierung (also I2C-Handling incl. asynchroner - also non-blocking - Abfrage in knx-common (meine Sensoren-Lib) implementiert habe, das seinerseits keinerlei Referenzen auf den knx-Stack hat. Testweise hatte ich dann eine frühe KONNEKTING-Version seines Sensormoduls auch so angepasst, dass sie mit meiner Sensor-Implementierung läuft. Vorteil ist dann, dass weitere Sensor-Implementierungen auch für KONNEKTING zur Verfügung stehen.

Wenn ich das richtig verstanden habe, kommuniziert Dein Chip auch über I2C, liefert Sensordaten (Stromstärke und/oder Spannung, falls Du das doch mit Spannung machst), und dann gibt es noch einen Pin, der irgendwie das Relais schaltet. Non-Blocking Sensor-Applikation hab ich schon , eine Schaltaktor-Applikation fehlt noch in meiner Sammlung... wobei die meisten Sachen, die man am Eingang eines Schaltaktors machen kann schon in meiner Logik gehen (und einiges mehr). Wenn ich also dem Ausgang einer Logik sagen kann, dass er den Relais-Pin schreiben soll, würde schon ziemlich viel gehen (Und, Oder, Exor, Tor, Treppenlicht, Sperre, Blinken, Schwellwertschalter, Zeitschaltuhr, Status, usw.)

Sorry, ich schweife ab. Eigentlich wollte ich nur sagen, dass ich bei der Firmware für den ETS-KNX-Stack helfen könnte.

Gruß, Waldemar

[Ing-Dom]

Hast Du auch ein Gehäuse im Sinn? Damit der 230V-Teil nicht frei in der UP-Dose "rumfliegt"?

na klaro. Aus dem 3D-Drucker.
Sowohl das Relais als auch der ACS37800 haben eine sichere elektrische Trennung, sind also ohne weiteres für de Trennung von 230V / SELV geeignet.
Ansonsten sind die Leiterbahnen mit entsprechender Kriechstrecke (mind. 6mm) bzw durch 1.6mm PCB getrennt.

Meine Idee bzgl. Konnekting / ETS-KNX-Stack wäre, dass man eine Art KNX-Abstraktions-Layer einzieht.
Detailierte Gedanken dazu hab ich mir aber noch nicht gemacht.

ommuniziert Dein Chip auch über I2C, liefert Sensordaten (Stromstärke und/oder Spannung, falls Du das doch mit Spannung machst),

korrekt, die Lib ist vom Grundgerüst her schon fertig, es fehlt nur noch die Business-Logik.

und dann gibt es noch einen Pin

2 Pins. Bistabiles Relais.

[mumpf]

2 Pins. Bistabiles Relais.

Natürlich. Mein Fehler

Meine Idee bzgl. Konnekting / ETS-KNX-Stack wäre, dass man eine Art KNX-Abstraktions-Layer einzieht.

Ja, das hatte ich auch gedacht. Und vielleicht hast Du eine gute Idee, das zu lösen. Ich fand damals, dass die Programmiermodelle zu unterschiedlich sind, wobei ich eher keine Erfahrung mit Konnekting habe. Nur als Beispiel: Bei ETS-Stack lese ich Parameter immer direkt aus dem Flash (die Diskussion hatten wir schon), bei Konnekting stehen sie im EEPROM und müssen erst ins RAM geladen werden. Bei meiner Lösung hätte ich dann nicht genug Speicher gehabt.
Ferner ist die Parametrisierung in der ETS ganz anders organisiert als bei Konnekting. Klar, bei einem Schaltaktor gibt es nicht viele Parameter, vor allen bei nur einem Kanal, das würde man schon hin bekommen.

Ich habe eher den Ansatz befolgt, verschiedene möglichst wiederverwendbare Software-Komponenten zu schreiben, die dann mit kleinen Anpassungen in Geräten kombiniert werden können. Das dann für 2 knx-Stacks mit unterschiedlichen Parametrisierungsmodellen durchzuhalten wollte ich mir nicht antun. Deswegen der andere Ansatz: Die "Business-Logik" passend zum jeweiligen Stack und die optimierten Zugriffsmethoden auf Hardware in einer gemeinsamen Lib. Dabei war eigentlich immer klar, dass die Konnekting-Variante eher weniger Funktionen haben wird, hauptsächlich weil die Parametrisierung für Konnekting zu komplex werden würde.

Aber das ist natürlich ein anderer Ansatz (mehrere Geräte als Kombi von mehreren Softwarekomponenten) als ein Gerät für 2 Stacks. Deswegen bin ich mir nicht sicher, wie wir hier zusammenkommen... Aber lass uns mal reden, wenn die Hardware soweit ist. Wenn Dein Aktor wirklich schnell misst, hätte ich einen Anwendungsfall für meine Kaffeemaschine .

Gruß, Waldemar

[Ing-Dom]

Nur als Beispiel: Bei ETS-Stack lese ich Parameter immer direkt aus dem Flash (die Diskussion hatten wir schon), bei Konnekting stehen sie im EEPROM und müssen erst ins RAM geladen werden. Bei meiner Lösung hätte ich dann nicht genug Speicher gehabt.
Ferner ist die Parametrisierung in der ETS ganz anders organisiert als bei Konnekting. Klar, bei einem Schaltaktor gibt es nicht viele Parameter, vor allen bei nur einem Kanal, das würde man schon hin bekommen.

Problematisch wird es dann, wenn sich die Parameter-Strukturen aufgrund der Möglichkeiten stark unterscheiden.

Ich habe eher den Ansatz befolgt, verschiedene möglichst wiederverwendbare Software-Komponenten zu schreiben, die dann mit kleinen Anpassungen in Geräten kombiniert werden können.

Ja, so in etwas mache ich das auch.
Konkret bei meinem Dimmer, wobei meine DimmChannel Klasse auch direkt konnekting im Bauch hat, also knd.write aufruft. Aber das wäre ja kein Thema, as etwas zu abstrahieren.

[Ing-Dom]

Hab mich nun final dazu entschieden, auf die Spannungsmessung zu verzichten. Die optionale Strommessung sollte für die allermeisten Anwendungen ausreichen. Dafür ist nun auch Platz für zwei Eingänge!

Anwenungsfall, der Ersatz eines herkömmlichen Lichtschalters - lange Leitungswege und Einkopplungen daher nicht zu erwarten.
Insofern könnte man wohl einfach die MCU Pins rausführen und GND und mit Nutzung der internen Pullups und SW-Entprellung arbeiten.

Es wäre aber auch Platz für etwas Hühnerfutter. Wie steht ihr dazu?

[mumpf]

Wie steht ihr dazu?

Da bin ich leidenschaftslos... ich denke, da wo man Strommessung braucht, wird man nicht einen Schalter haben wollen. Ich persönlich suche nach einem schnell reagierenden UP Aktor mit Strommessung für eine Tiefe Dose hinter einer Steckdose. Wobei es nicht auf die Steckdose ankommt, da wäre sowieso immer das gleiche Gerät drin.

Gruß, Waldemar

[Ing-Dom]

ich denke, da wo man Strommessung braucht, wird man nicht einen Schalter haben wollen.

ja, stimmt wohl.
Aber UP-Aktor mit Eingängen ist sicher ganz praktisch. Je universeller das Gerät aufgebaut ist, desto mehr Anwender.

2021-04-07 10_35_22-Eeschema — input.sch [_Input_] — D__Data_Eigene Dokumente_Projekte_EIB_Konnektin.png

Meinungen ? A4 ist der MCU Eingang, J6 wird auf GND gezogen per Taster.

[Ing-Dom]

Mittlerweile hab ich die V00.02 Hardware aufgebaut.
Leider auch hier noch (mind.) 2 Probleme drin:
- die Booster-Ladeschaltung für den Elko hab ich verbockt, ich wolte mit n-Kanal High-Side schalten
=> eigentlich zeigt sich, dass man die Schaltung nicht braucht.

- erste Test mit 230V-Schalten (75W Glühbirne): Bei jedem dritten Schaltvorgang geht die MCU in den Reset.
Ich hab wohl der Reset-Leitung zu wenig Aufmerksamkeit geschenkt, der interne Pullup reicht hier wohl nicht aus.


IMG_20210513_185123769.jpg IMG_20210514_083037765.jpg