Eine weitere fast immer übersehene Wärmequelle ist der Schaltkontakt, also der Spannungsabfall über dem geschlossenen Kontakt, multipliziert mit dem Laststrom. Der Widerstand des Kontakts ist keineswegs nahezu Null; das Datenblatt nennt als max. Wert 100mOhm !!!
Bei zB 10A Laststrom ergibt sich ein Spannungsabfall von 1V. Die Verlustleistung (=Erwärmung) ist also P=1V*10A=10W !!
Und bei 16A: U=16A*0,1Ohm=1,6V, P=1,6V*16A=25W!
Aber selbst mit optimistischen/realistischen Werten für den Übergangswiderstand der Schaltkontakte von zB 30mOhm ergibt sich bei 16A eine Verlustleistung am Kontakt von fast 8W, bei 10A immer noch 3W (zusätzlich zur Spule mit ca 2W).
Kein Wunder, daß das Shelly Gerät heiß wird.

Die 16A Spezifikation (mit der Shelly deutlich wirbt) bezieht sich also nur auf die Stromtragfähigkeit der Kontakte (incl. des Lastabwurfs), und das auch nur bei rein ohmschen Lasten. Bei induktiven Lasten reduziert sich die Spezifikation auf 8A.

Ich habe große Bedenken, einem solch kleinen Gerät (= kleines Relais, kleine Anschlußklemmen, geringer Adernquerschnitt) einen Laststrom von mehr als 2…3A zuzumuten; heißt Lasten von max. wenigen 100W.

Einen wesentlichen Einfluß auf die thermische (Grenz-)Situation hat die Dauer des EIN-Betriebs: wird die thermisch stabile Situation mit max. Temperatur in der EIN-Zeit überhaupt erreicht? Eine Kaffeemaschine ist anders zu beurteilen als ein Heizstab in einem Brauchwasserspeicher, trotz ähnlicher Leistungswerte.

Die thermische Situation hängt natürlich auch von der Einbausituation ab: Umgebungstemperatur, Kühlung (freier Luftzug oder irgendwo eng eingebaut, der wahrscheinlichere Fall).
Aber bei Werten um und über 10W Verlustleistung im Gerät sind diese Randbedingungen nachrangig , bzw retten das Gerät auch nicht vor Beschädigung durch Überhitzung (insbes. bei Dauerbetrieb, also über Stunden).

PS: es gibt eine Sonderversion des Shelly mit 25A Spezifikation: https://shellyparts.de/products/ogemray25a
Auch hier glaube ich die 25A nicht, aber ca 10A, also etwa 2kW würde ich diesem Gerät zumuten.

Ich hatte ein kleines Problem, dass das Energy Dashboard sich beschwert hat über “unexpected device class” der integrations sensoren. Nach ein wenig hin und her habe ich dann gefunden, dass man diese nicht direkt sondern bei den Quellsensoren setzen muss. Hinzufügen von `device_class: power` bei den Power-Sensoren löste das Problem für mich, da hierdurch beim Integrals-Sensor die ‘device-class:energy’ korrekt abgeleitet wird.

Grüße

Hier meine
Änderung

sensor:
– platform: template
sensors:
# Template sensor for current power comsumption
power_current:
friendly_name: “Power Current”
unit_of_measurement: ‘W’
value_template: >-
{{ states(‘energiezahler_vor_vorsicherung_phase_a_active_power’)|float + states(‘energiezahler_vor_vorsicherung_phase_b_active_power’)|float + states(‘energiezahler_vor_vorsicherung_phase_c_active_power’)|float }}
availability_template: “{{
[ states(‘energiezahler_vor_vorsicherung_phase_a_active_power’),
states(‘energiezahler_vor_vorsicherung_phase_b_active_power’),
states(‘energiezahler_vor_vorsicherung_phase_c_active_power’)
] | map(‘is_number’) | min
}}”

# Template sensor for values of power import (active_power > 0)
power_import:
friendly_name: “Power Import”
unit_of_measurement: ‘W’
value_template: >-
{% if (states(‘energiezahler_vor_vorsicherung_phase_a_active_power’)|float + states(‘energiezahler_vor_vorsicherung_phase_b_active_power’)|float + states(‘energiezahler_vor_vorsicherung_phase_c_active_power’)|float) > 0 %}
{{ states(‘energiezahler_vor_vorsicherung_phase_a_active_power’)|float + states(‘energiezahler_vor_vorsicherung_phase_b_active_power’)|float + states(‘energiezahler_vor_vorsicherung_phase_c_active_power’)|float }}
{% else %}
{{ 0 }}
{% endif %}
availability_template: “{{
[ states(‘energiezahler_vor_vorsicherung_phase_a_active_power’),
states(‘energiezahler_vor_vorsicherung_phase_b_active_power’),
states(‘energiezahler_vor_vorsicherung_phase_c_active_power’)
] | map(‘is_number’) | min
}}”

# Template sensor for values of power export (active_power –
{% if (states(‘energiezahler_vor_vorsicherung_phase_a_active_power’)|float + states(‘energiezahler_vor_vorsicherung_phase_b_active_power’)|float + states(‘energiezahler_vor_vorsicherung_phase_c_active_power’)|float) –
{% if (states(‘sensor.power_export’)|float(0)) > 0 and (states(‘sensor.power_solargen’)|float(0) – states(‘sensor.power_export’)|float(0)) 0 and (states(‘sensor.power_solargen’)|float(0) – states(‘sensor.power_export’)|float(0)) > 0 %}
{{ (states(‘sensor.power_solargen’)|float(0)) – states(‘sensor.power_export’)|float(0) }}
{% else %}
{{ states(‘sensor.power_import’)|float(0) + states(‘sensor.power_solargen’)|float(0) }}
{% endif %}

# Template sensor for values of energy Solar generation (solar_power > 0)
power_solargen:
friendly_name: “Power Solar Generation”
unit_of_measurement: ‘W’
value_template: >-
{% if (states(‘solarsudenvordach_leistung’)|float(0) + states(‘solar_ertrag_leistung’)|float(0)) > 0 %}
{{ (states(‘solarsudenvordach_leistung’)|float(0) + states(‘solar_ertrag_leistung’)|float(0)) }}
{% else %}
{{ 0 }}
{% endif %}

# Sensor for Riemann sum of energy import (W -> Wh)
– platform: integration
source: sensor.power_import
name: energy_import_sum
unit_prefix: k
round: 2
method: left
# Sensor for Riemann sum of energy export (W -> Wh)
– platform: integration
source: sensor.power_export
name: energy_export_sum
unit_prefix: k
round: 2
method: left
# Sensor for Riemann sum of energy consumption (W -> Wh)
– platform: integration
source: sensor.power_consumption
name: energy_consumption_sum
unit_prefix: k
round: 2
method: left
utility_meter:
energy_import_daily:
source: sensor.energy_import_sum
name: Energy Import Daily
cycle: daily
energy_import_monthly:
source: sensor.energy_import_sum
name: Energy Import Monthly
cycle: monthly
energy_export_daily:
source: sensor.energy_export_sum
name: Energy Export Daily
cycle: daily
energy_export_monthly:
source: sensor.energy_export_sum
name: Energy Export Monthly
cycle: monthly
energy_consumption_daily:
source: sensor.energy_consumption_sum
name: Energy Consumption Daily
cycle: daily
energy_consumption_monthly:
source: sensor.energy_consumption_sum
name: Energy Consumption Monthly
cycle: monthly

total_active_power

power_import:
friendly_name: “Netzverbrauch – Leistung”
unit_of_measurement: “W”
device_class: power
value_template: >-
{% set total = states(‘sensor.shellypro3em400_e05a1b33b46c_total_active_power’) | float %}
{{ total if total > 0 else 0 }}

für die Erfassung der Leistung ?

Ein Tipp für alle, die mit der Integration der „Export Daily“ nicht warten wollen bis die Solaranlage genug produziert: Man kann beim Shelly Pro3EM die Messrichtung der Stromzangen in der App softwareseitig umdrehen. (Einstellungen – Messrichtung umkehren). So kann man eine PV Einspeisung simulieren und die Integration auch am Abend durchführen.

Viele Grüße
Sascha

danke für den tollen Beitrag, ich werde auch einen Raum damit beginnen und testen.

Hast du den Blog schon fertig, wie du es im Homeassistant eingebunden hast?

Ich werde mir noch ein Temperaturfühler dazu bestellen. Damit bei erreichen von Temperatur X das Thermostat wieder ausgeschaltet wird.

MfG

Erik

Schau mal in meinen anderen Post. Genauso etwas habe ich mit einer Infrarotheizung umgesetzt und in einem Beitrag dokumentiert.

Hast du mal den Konfigurator auf meiner Seite ausprobiert? Der würde dir alles automatisch in einem Skript zusammenfügen.

Hallo Matthias,
ich nutze das im wesentlichen, wenn ich länger unterwegs bin. Dann werden wie Regler ganz runter gestellt und dann kann nur der Shelly das Ventil öffnen.

Allerdings habe ich abweichend von Deiner Technik sowohl einen ShellyEM für die Gartenhütten-PV-Produktion mit einer Phase, als auch einen ShellyProEm3, anstelle Deiner beiden powerplugs fürs Messen der Produktion, da die Wechselrichter vom Dach 3-phasig produzieren.

Mir ist die Syntax für power_solargen: nicht ganz klar; ich weiß nicht, wie ich Deinem Code insgesamt noch zwei weitere Quellen hinzufügen muß (zwei hattest Du ja bereits angelegt), damit alles funzt.

Kleine Hilfe? Vielen Dank!