Wirkleistungamessung für separate Phase

[wuchtbrumme]

Moin,

ich suche ein Wirkleistungsmesser für separate Phasen. Dh. ich möchte den Energieverbrauch von ein paar Systemen überwachen, die an einzelnen RCDs hängen.

Der MDT AZI geht nicht da der nur ein gemeinsames N hat. Sonst hab ich nur das Enertex KNX SmartMeter 85A gefunden - hat jemand damit Erfahrung?

Das Enertex ist aber ziemlich groß, in einem Schaltschrank muss ich nur eine Phase überwachen.

Hat jemand Erfahrung mit den Shellys, haben die echte Wirkleistungsmessung?

[ralf9000]

Wie wäre es mit einem Zennio KES Plus, der lässt sich relativ variabel konfigurieren? Breite 2 Einheiten und der Preis ist auch ok .... brauchst noch die "Stromklipse".

Bilder hier ...

[Hubertus81]

Die Shellys messen doch Wirkleistung. Die Frage ist nur wie genau die messen. Ich würde aber behaupten son MDT AZI misst nicht umbedingt besser als nen Shelly...

Der MDT AZI geht nicht da der nur ein gemeinsames N hat

Das ist kein Hindernis. Du kannst den N auch einfach vor dem RCD abgreifen.

[tsb2001]

Bei mehrere unterschiedlichen Stromkreisen würde ich den hier für Modbus nehmen; ist sogar MID aus dem Jahr 2025 https://stromzähler.eu/Stromzaehler/Wechselstromzaehler/fuer-Hutschiene-geeicht/SDM120-Modbus-MID-1-Phasen-Zweirichtungs-WSZ-fuer-Hutschiene

Wenn es dann Richtung KNX gehen sollte, dann den Modbus->KNX-Gateway entweder mit 32 Kanälen https://my-knx-shop.net/Arcus-eds-KN...n-Datenpunkten oder den hier mit 200 Kanälen https://www.voltus.de/mdt-scn-mbgrtu-01-knx-modbus-gateway-modbus-rtu.html?ex_s=google&ex_m=paid&ex_c=19906711895&ex _t=&ex_co=&ex_a=&ex_gid=EAIaIQobChMIkre3isv4jAMVtQ YGAB0fTC2rEAQYASABEgLz1fD_BwE&gad_source=1&gad_cam paignid=19899534684&gbraid=0AAAAA-lkDk9kmav0IpvRSVZ3KzHM2_7q3&gclid=EAIaIQobChMIkre3 isv4jAMVtQYGAB0fTC2rEAQYASABEgLz1fD_BwE je nachdem wie viele Zähler und welche Menge an Datenpunkte einem wichtig sind.

[wuchtbrumme]

Danke für die ganzen Antworten. Messung muss nicht super genau sein.

Das ist kein Hindernis. Du kannst den N auch einfach vor dem RCD abgreifen.

Sicher? Ich find bei MDT hierzu keine Aussage. Keine Ahnung wie die Dinger funktionieren, kann also nicht sagen ob das geht. Hier im Forum hab ich irgendwo gegenteiliges gelesen.

Beim Zennio scheint's aber zu gehen mit gemeinsamen N (steht explizit im Datenblatt), der Enterex hat 3 getrennte Eingänge. Bizarr.

Modbus würd' ich mir gerne sparen.

[tsb2001]

Sicher? Ich find bei MDT hierzu keine Aussage. Keine Ahnung wie die Dinger funktionieren, kann also nicht sagen ob das geht.

Geht. Das ist lediglich das Bezugspotential zur Messung und verursacht Fehlerströme im Mikroamperebereich und tangiert keinen RCD.
Man kann darüber streiten, ob das nun richtig oder falsch ist; da diese Bauweise jedoch keine sicherheitsrelevante Gefährdung darstellt und das Risiko einer Fehlauslösung auch nicht erhöht wird, würde ich das so bauen.

Modbus würd' ich mir gerne sparen.

Ich würde mir mittlerweile sparen, solche Messwerte auf KNX zu bringen. Ich hab hier drei Wärmemengenzähler, die über M-Bus gesammelt werden und dann mittels Gateway auf KNX übertragen werden.
Die fluten den Bus mit vielen Telegrammen, obwohl ich die dar nicht auf dem Bus weiterverarbeite, sondern damit nur den Homeassistant mit Daten versorge.
Alle anderen Zähler bei mir liefern mittlerweile die Daten via Modbus-TCP aus und gehen direkt ins LAN. Solche Daten sind da einfach besser aufgehoben.

Daher würde ich zur Anschaffung der Komponenten nicht nur die Quelle der Daten berücksichtigen, sondern auch das Ziel der Weiterverarbeitung. Wenn die wie z.B bei mir gar nicht im KNX benötigt werden, würde ich das auch nicht als Übertragungsmedium verwenden.

[wuchtbrumme]

Ha, guter Punkt bzgl. des Ziels. Soll bei mir natürlich auch direkt in den HA, und hat eigentlich auf dem KNX-Bus nix zu suchen. War reiner Automatismus 🙄

Der SDM120-Modbus sieht tatsächlich gut aus: sehr klein, günstig, mit Zählerdisplay. Aber gibt's sowas auch für TCP? Naja am besten verkabel ich das im Schrank mit Modbus RTU und hau mir irgendwo einen billigen Konverter hin der's dann per TCP in den HA bringt.

Super Tipp, danke!

[tsb2001]

Naja am besten verkabel ich das im Schrank mit Modbus RTU und hau mir irgendwo einen billigen Konverter hin der's dann per TCP in den HA bringt.

Exakt so würde ich es zukünftig auch machen!

[wuchtbrumme]

Exakt so würde ich es zukünftig auch machen!

Ok dann mach ich das so. Hmm, also ich hätte da ein paar KNX-Geräte zu verkaufen... 🤣

[Hubertus81]

Naja am besten verkabel ich das im Schrank mit Modbus RTU und hau mir irgendwo einen billigen Konverter hin der's dann per TCP in den HA bringt.

Super Tipp, danke!

Bedenke dass Modbus eine Punkt zu Punkt Verbindung ist. Du kannst es also dann unter Umständen nur in HA einbinden. Willst du es an anderen Stellen dann noch nutzen musst du die Daten entweder über HA direkt weiterschicken, dich mit nem Modbus Proxy auseinander setzen, oder schauen ob du doch mehrere Verbindungen gleichzeitig aufbauen kannst.

Ich würde nen anderen Weg gehen nämlich den über MQTT. Zumindest wenn du die Werte an mehrere Stellen verteilen willst...

Sprich: Modbus RTU => MQTT => HomeAssistant/Influxdb/etc. wenn du das Teil wirklich nur in HA brauchst kannste das mit Modbus aber so machen...

[wuchtbrumme]

Bedenke dass Modbus eine Punkt zu Punkt Verbindung ist. Du kannst es also dann unter Umständen nur in HA einbinden. Willst du es an anderen Stellen dann noch nutzen musst du die Daten entweder über HA direkt weiterschicken, dich mit nem Modbus Proxy auseinander setzen, oder schauen ob du doch mehrere Verbindungen gleichzeitig aufbauen kannst.

Ich würde nen anderen Weg gehen nämlich den über MQTT. Zumindest wenn du die Werte an mehrere Stellen verteilen willst...

Guter Hinweis, danke. Bei mir aber zum Glück kein Problem, da's wirklich nur in de HA muss. Ich hab eher das Problem dass ich mehrere Quellen habe die in verschiedenen Gebäuden bzw. -teilen liegen. Da wird's wahrscheinlich trotzdem das günstigste sein die per separate Modbus-Installationen und TCP anzuschliessen (da ich überall Netzwerk liegen habe)

[tsb2001]

Ich würde nen anderen Weg gehen nämlich den über MQTT.

Bei mir aber zum Glück kein Problem, da's wirklich nur in de HA muss.

Wenn es im HA erst mal angekommen ist, ist die Verteilung eh über alle gängigen Protokolle möglich. Ein direktes „Publishing“ des Stromzählers auf MQTT wird ohnehin nicht funktionieren und bedarf eines Gateways. Das kann der HA umsonst mittels Bordmitteln; und wenn es Richtung KNX gehen soll, wird es auch funktionieren…

[Hubertus81]

Das kann HA alles "irgendwie", nur HA bekommt auch regelmäßig Updates und muss von mal zu mal dann doch neugestartet werden. Ein MQTT Broker im vergleich dazu ist wesentlich schlanker und kann einfach so durchlaufen...
Die Frage ist also ob man HA wirklich zur Zentrale für alles machen will. Ich persönlich will das nicht und trenne es daher sauber...

[tsb2001]

nur HA bekommt auch regelmäßig Updates und muss von mal zu mal dann doch neugestartet werden. Ein MQTT Broker im vergleich dazu ist wesentlich schlanker

Da ein MQTT-Broker kein passives Hardwareteil ist, läuft der auch irgendwo auf irgendeiner Plattform und hängt im Netz. Folglich wird der ebenfalls Updates benötigen; wenn auch seltener.
Wenn das Datenziel (hier der Homeassistant) in diesem Fall ohnehin die Drehscheibe aller Daten des Threaderstellers ist, würde ein externer MQTT-Broker seine Daten ins Nirvana senden, wenn HA updated.

Daher bin ich persönlich eher für das Motto „keep it simple“, denn selbst wenn der Broker nur auf einem RasPi oder sonstiger Hardware läuft, muss man den kaufen, mit Energie versorgen und zusätzlich auch pflegen.
Zudem erschließt sich mir kein Fall, wo ich die Daten meiner Zähler benötigen würde, wenn der HA ohnehin nicht verfügbar ist. Messwerte werden nur dort verarbeitet; und wenn nicht, würden die halt beim nächsten Start neu eingesammelt und verteilt. Ist dann halt eine Latenz von 3-4 Minuten drin.
Ich sammle zum Beispiel via Modbus TCP den Akkufüllstand vom Wechselrichter ein und sende den Richtung KNX, um den auf der Glasbedienzentrale zu visualisieren. Der Rest landet in der Influx-DB, ebenfalls im HA und ist somit beim Update ebenfalls down, während KNX durchläuft.

Da ich aber den Homeassistant niemals händisch update, sondern via Automatisierung das immer Sonntags um 3:00 Uhr in der Nacht mache, liegt dieser Datenausfall jede Woche einmal mitten in der Nacht für diese paar Minuten vor. Damit kann ich leben.

Ob das wuchtbrumme ebenfalls kann, muss dieser nun für sich selbst entscheiden…

[Hubertus81]

Folglich wird der ebenfalls Updates benötigen; wenn auch seltener.

Da ich aber den Homeassistant niemals händisch update, sondern via Automatisierung das immer Sonntags um 3:00 Uhr in der Nacht mache, liegt dieser Datenausfall jede Woche einmal mitten in der Nacht für diese paar Minuten vor. Damit kann ich leben.

Halten wir fest HA benötigt öfter Updates, HA ist EINIGES komplexer als ein simpler MQTT Broker...
Die Warscheinlichkeit dass so ein automatisiertes Update mal schief laufen kann und HA dann nicht mehr hochfährt ist auch gegeben, auch da dürfte ein MQTT Broker der einfach nur durchläuft zuverlässiger sein was das angeht.

Und ja im Idealfall ist ein MQTT Broker ein eigenes Stück Hardware. Da seltener Update kommen kann ich diese auch manuell anstoßen, aber wieso überhaupt updaten wenn es läuft? Mache ich nur manuell wenns Probleme gibt oder im Zug einer "Wartung" wenn ich ohnehin neustarten muss kann ich auch eben update einspielen. Wenn alles läuft gibt es dort eh kein Grund für Updates. HA hingegen hat soviele Abhängigkeiten da sich ständig irgendwo was ändert ist man auf die Updates angewiesen. Das Projekt wäre tot wenn keiner mehr seit Monaten Updates bringen würde.

keep it simple ist für mich eher was anderes als was du drunter verstehst... Für mich bedeutet das dass die Dienste möglichst getrennt und Unabhängig voneinander laufen. InfluxDB läuft bei mir aus dem Grund auch nicht in HomeAssistant, genauso wie mein Broker da läuft..

Mein Broker läuft auf Proxmox, was in meinen Augen schonmal besser ist als es in HA laufen zu haben, aber ideal wäre wie angemerkt einfach eigene Hardware dafür