Stromzähler ablesen

Im Rahmen der Installation der PV – Anlage habe ich einen neuen Stromzähler von der GWN erhalten …

eBZ Modell: WD3 2R10 DTA – ODZ1

Stromzaehler

Hierbei handelt es sich um einen saldierenden 3-Phasen, 2-Richtungszähler.
Dieser liefert im Auslieferungszustand nur 1.8.0 Bezugs- und 2.8.0 Exportwerte (kWh Zählerstand). Mit der Eingabe der PIN (Abfrage bei der GWN) über die Infrarot Schnittstelle werden zusätzlichen Werte freigeschaltet und die Abfrage des PIN kann abgeschaltet werden.

PIN Anfrage an den Energieversorger bzw. Eigentümer des Zählers

Meine E-Mail mit der Bitte um Mitteilung des PIN’s wurde von den Gemeindewerken Nümbrecht GmbH unmittelbar beantwortet.

Dafür, vielen Dank an die freundlichen Mitarbeiter der GWN.

PIN Eingabe über das Infrarot – Interface

Die Eingabe des PIN ist mit einer geeigneten Taschenlampe möglich. Viel einfacher war für mich die Nutzung der iOS APP: EDL21 Control.

Dafür habe ich als erstes den PIN in der APP eingegeben und danach die (Taschenlampen) LED des Handy’s direkt auf die Infrarot Schnittstelle gehalten und “Entsperren” ausgewählt.

IR - entsperren

Anschließend habe ich mit Hilfe der Funktion “Zähler steuern” den Menüpunkt “PIN Eingabe” mit “weiter, weiter, …” ausgewählt und mit “Aktion” umgestellt.

Damit der erweiterte Datensatz übertragen wird muss Eintrag “Inf” im Menü des Zählers auf on gestellt werden.

ir zaehlereinstellen

Ob die Infrarotschnittstelle Daten ausgibt, kann man ebenfalls mit der Handy Kamera sehr gut überprüfen (leuchten der IR-Interfaces im Kamera Modus).

Hinweis:

Die “Inf” – Eingabe muss bei jedem Stromausfall erneut erfolgen, anderenfalls fehlen die erweiterten Daten (Saldierte Leistung aller Phasen, Leistung der einzelnen Phasen)!

bitShake SmartMeterReader in Betrieb nehmen

Als “Leser” verwende ich den bitShake SmartMeterReader – WiFi Set | IR Lesekopf | TASMOTA vorinstalliert | WLAN | MQTT.

bitshake IR Reader

Achtung:

Vorinstalliertes Tasmota nur akutalisieren, wenn man weiß, was man tut, anderenfalls ist die Sonderfunktion: “script Editor” im Menu “Consoles” weg.

Lesekopf mit dem Wemos D1 verbinden

Falls nicht vorbereitet muss der Lesekopf mit dem mitgelieferten Wemos D1 mini gemäß Anleitung verbunden werden. Bitte unbedingt auf die korrekten Verbindungen (+, -, RX, TX) achten.

Anschließend kann der Wemos D1 mini über den USB Anschluss mit Strom versorgt werden.

Tasmota Konfiguration als Client im heimischen WLAN

Im Auslieferungszustand befindet sich der Wemos D1 Mini im “Access Point” Modus. Um ihn mit dem eigenen WLAN zu verbinden wechselt man im Handy auf das neu verfügbare tasmota WLAN. Nach der Verbindung erscheint unmittelbar das Konfigurationsmenü zur Auswahl der eignen WLAN Verbindung. Nach Auswahl der korrekten SSID und Erfassung des entsprechenden Passwortes, wechselt das vorinstallierte tasmota automatisch in das heimische WLAN.

Nachdem sichergestellt ist, dass das Handy wieder mit dem heimischen WLAN verbunden ist, benötigt man die vom eigenen DHCP-Server (z.B. Fritz!Box, Teleport, …) vergebene IP Adresse für den Lesekopf (z.B. über die APP oder die Web-GUI der Firtz!Box (Teleport, …).

Verbindung zum MQTT Broker eingeben

Da fast alle meine Geräte über MQTT verfügbar sind, erfasse ich auch hier die Verbindungsdaten zu meinen MQTT Broker.

Hinweis

Alle Daten werden in einem Topic jeweils einzeln als “name:value” des SM json-Objektes übertragen.

Smart-Meter-Interface für den Zähler WD3 2R10 DTA – ODZ1 konfigurieren

Ein sehr spannendes Thema, das, – sofern der korrekte Zähler nicht als Beispiel auf der SmartMeter-Interface Seite von tasmota gelistet korrekt ist -, kompliziert werden kann.

Folgendes Skript funktioniert für den Zähler WD3 2R10 DTA – ODZ1:

>D
>B
TelePeriod 30
=>sensor53 r
>M 1
+1,5,o,0,9600,SM,4
1,1-0:1.8.0*255(@0.001,Energie Bezug,Wh,1_8_0,3
1,1-0:2.8.0*255(@0.001,Energie Export,Wh,2_8_0,3
1,1-0:16.7.0*255(@1,Leistung,W,16_7_0,18
1,1-0:36.7.0*255(@1,Leistung L1,W,36_7_0,18
1,1-0:56.7.0*255(@1,Leistung L2,W,56_7_0,18
1,1-0:76.7.0*255(@1,Leistung L3,W,76_7_0,18
1,1-0:96.1.0*255(@#),Identifikation,,96_1_0,0

Hinweis:

Besonderheiten des bitshake SmartMeterReader am WD3 2R10 DTA – ODZ1:

Der korrekte GPIO ist 5 und die Kommunikationseinstellungen lauten 7 Datenbits, gerade Parität, ein Stoppbit, 9600 Baud (9600 7E1).

image 2

Shelly pro 3EM

Shelly

Ich habe meinen bestellten Shelly Pro 3EM erhalten und einige Tests durchgeführt. Die folgenden Beschreibungen ersetzen keinesfalls die mitgelieferten/veröffentlichten Original Handbücher/Bedienungsanleitungen

Anschluss

Da ich bisher keine Anschlussschemata gefunden habe, hier mein laienhaft erstelltes Schema:

Anschluss Schema

So funktioniert es bei mir mit der Ausgabe des gesamten Stromverbrauchs des Anschlusses. Wichtig sind zum einen, dass sich die Abnahmeklemmen (IA, IB oder IC) immer an der entsprechend angeschlossenen Phase (L1 = A, L2 = B, L3 = C) die Leistung abnehmen, und, die Klemmen in der aufgedruckten Fliessrichtung (K > L) gedreht sind.

Selbstverständlich sind andere Messungen (Wechselrichter, Wallbox, …) unter Beachtung der entsprechenden Zuordnungen möglich.

Verbindung mit dem bereitgestellten (Standard) Access Point

Nach der elektrischen Inbetriebnahme (mind. N = Null und C = L3) stellt der Shelly Pro 3EM einen WLAN Access Point mit der SSID ShellyPro3EM-XXXXXXXXXXXX ohne Passwort zur Verfügung (XXXXXXXXXXXX = Device ID). Ich habe auf dem Handy die WLAN Verbindung aktiviert und im Browser http://192.168.33.1 zur Konfiguration über dei Web-GUI eingegeben.

Shelly Pro 3EM - Settings

Netzwerkeinstellungen

Wenn möglich sollte Ethernet verwendet werden. Da als Standard hier ein DHCP Verbindungsaufbau konfiguriert ist, sollte (ohne eigenen DNS – Server oder adäquater Konfiguration des DHCP Servers) eine fest IP eingetragen werden, damit die Web-GUI des Shelly Pro 3EM ohne lästiges suchen der aktuell vergebenen IP Adresse aufgerufen werden kann. Das gilt auch, wenn der WiFi verwendet werden soll.

Zusätzlich empfehle ich den Access Point als “trouble port” oder als Schaltschrank internen Access Point mit einem Passwort geschützt aktiv zu lassen, und, wenn nicht als Gateway benötigt, Bluetooth abzuschalten.

Verbindungseinstellungen (hier: MQTT)

Hier gibt es sehr viele realisierbare Möglichkeiten. Meine bevorzugte ist MQTT. Zum Einstieg und Kennenlernen habe ich alle Optionen der MQTT Einstellungen aktiviert. Auch MQTT debug unter Settings – Debug sind aktiviert.

Nach eine Neustart läuft der Shelly Pro 3EM einwandfrei und liefert Daten an den MQTT Broker.

MQTT Messages

70-shellypro3em-xxxxxxxxxxxx/#

topicmessage
online [fix, bei Änderung]true
rpc [variabel]z.B.:
{
"id": 0,
"method": "EMData.GetData",
"params": {
  "id": 0,
  "ts": 1680771600,
"minutes": 60
}
}
debug/log [variabel]z.B.:
shellypro3em-xxxxxxxxxxxx 58015 1681805794.002 2|
shelly_notification:161 Status change of em:0:
{
"id":0,
"a_act_power":-0.0,
"a_aprt_power":0.0,
"a_current":0.029,
"a_pf":1.00,
"a_voltage":0.1,
"b_act_power":-0.0,
"b_aprt_power":0.0,
"b_current":0.028,
"b_pf":1.00,
"b_voltage":0.1,
"c_act_power":-0.1,
"c_aprt_power"

… wird hier abgeschnitten?!
events/rpc [variabel]z.B.:
{
"src": "shellypro3em-xxxxxxxxxxxx",
"dst": "70-shellypro3em-xxxxxxxxxxxx/events",
"method": "NotifyStatus",
"params": {
"ts": 1681806001.9,
"em:0": {
"id": 0,
"a_act_power": 0,
"a_aprt_power": 0,
"a_current": 0.03,
"a_pf": 1,
"a_voltage": 0.1,
"b_act_power": 0,
"b_aprt_power": 0,
"b_current": 0.027,
"b_pf": 1,
"b_voltage": 0.1,
"c_act_power": -0.1,
"c_aprt_power": 6.9,
"c_current": 0.029,
"c_pf": 1,
"c_voltage": 238.2,
"n_current": null,
"total_act_power": -0.118,
"total_aprt_power": 6.948,
"total_current": 0.086
}
}
}
status/em:0 [fix, bei Änderung]{
"id": 0,
"a_current": 0.03,
"a_voltage": 0.1,
"a_act_power": 0,
"a_aprt_power": 0,
"a_pf": 1,
"b_current": 0.028,
"b_voltage": 0.1,
"b_act_power": 0,
"b_aprt_power": 0,
"b_pf": 1,
"c_current": 0.028,
"c_voltage": 238.4,
"c_act_power": 0,
"c_aprt_power": 6.8,
"c_pf": 1,
"n_current": null,
"total_current": 0.086,
"total_act_power": -0.017,
"total_aprt_power": 6.78,
"user_calibrated_phase": [],
"errors": [
"no_load"
]
}
status/emdata:0 [fix, Minute]{
"id": 0,
"a_total_act_energy": 0.08,
"a_total_act_ret_energy": 0,
"b_total_act_energy": 0.07,
"b_total_act_ret_energy": 0,
"c_total_act_energy": 0.09,
"c_total_act_ret_energy": 0,
"total_act": 0.24,
"total_act_ret": 0
}
status/mqtt [fix, bei Änderung]{"connected":true}
status/sys [fix, bei Änderung]{
"mac": "XXXXXXXXXXXX",
"restart_required": true,
"time": "11:28",
"unixtime": 1681723737,
"uptime": 439831,
"ram_size": 246308,
"ram_free": 97032,
"fs_size": 524288,
"fs_free": 172032,
"cfg_rev": 23,
"kvs_rev": 0,
"webhook_rev": 0,
"available_updates": {}
}

Verwendete Werte und Einheiten im Topic em:0

id numberID der EM Komponenteninstanz
a_currentnumber or nullPhase A [L1] Messwert der Stromstärke, [A]
a_voltagenumber or nullPhase A [L1] Messwert der Spannung, [V]
a_act_powernumber or nullPhase A [L1] Messwert der Wirkleistung, [W]
a_aprt_powernumber or nullPhase A [L1] Messwert der Scheinleistung, [VA]
a_pfnumber or nullPhase A [L1] Messwert des Leistungsfaktors
a_errorsarray of type stringPhase A [L1] aufgetretende Fehler. z.B.
Wert außerhalb des Bereichs:
out_of_range:active_power
out_of_range:apparent_power,
out_of_range:voltage
out_of_range:current,
(Ausgabe nur, wenn mind. 1 Fehler vorhanden)
b_currentnumber or nullPhase B [L2] Messwert der Stromstärke, [A]
b_voltagenumber or nullPhase B [L2] Messwert der Spannung, [V]
b_act_powernumber or nullPhase B [L2] Messwert der Wirkleistung, [W]
b_aprt_powernumber or nullPhase B [L2] Messwert der Scheinleistung, [VA]
b_pfnumber or nullPhase B [L2] Messwert des Leistungsfaktors
b_errorsarray of type stringPhase B [L2] aufgetretende Fehler. z.B.
Wert außerhalb des Bereichs:
out_of_range:active_power
out_of_range:apparent_power,
out_of_range:voltage
out_of_range:current,
(Ausgabe nur, wenn mind. 1 Fehler vorhanden)
c_currentnumber or nullPhase C [L3] Messwert der Stromstärke, [A]
c_voltagenumber or nullPhase C [L3] Messwert der Spannung, [V]
c_act_powernumber or nullPhase C [L3] Messwert der Wirkleistung, [W]
c_aprt_powernumber or nullPhase C [L3] Messwert der Scheinleistung, [VA]
c_pfnumber or nullPhase C [L3] Messwert des Leistungsfaktors
c_errorsarray of type stringPhase C [L3] aufgetretende Fehler. z.B.
Wert außerhalb des Bereichs:
out_of_range:active_power
out_of_range:apparent_power,
out_of_range:voltage
out_of_range:current,
(Ausgabe nur, wenn mind. 1 Fehler vorhanden)
n_currentnumber or nullNeutral [N] Messwert der Stromstärke, [A] (wenn vorhanden)
n_errorsarray of type stringNeutral aufgetretende Fehler. z.B.
Wert außerhalb des Bereichs:
out_of_range:current,
(Ausgabe nur, wenn mind. 1 Fehler vorhanden)
total_currentnumber or nullSumme of the Stromstärke aller Phasen [L] (ohne N Werte, wenn vorhanden)
total_act_powernumber or nullSumme der Wirkleistung aller Phasen [L1+L2+L3]
total_aprt_powernumber or nullSumme Scheinleistung aller Phasen [L1+L2+L3]
user_calibrated_phasearray of type stringBenutzer kalibrierte Phasenmessungen
errorsarray of type stringEM Komponentenfehler. z.B.: power_meter_failure
phase_sequence or 
no_load.
(Ausgabe nur, wenn mind. 1 Fehler vorhanden)
siehe Original: https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/EM#status

Verwendete Werte und Einheiten im Topic emdata:0

EigenschaftTypBeschreibung
idnumberID der EM Komponenteninstanz
a_total_act_energynumberGesamte Wirkenergie (Verbrauch) der Phase A [L1], Wh
a_total_act_ret_energynumberGesamte rückgeführte Wirkenergie (Einspeisung) der Phase A [L1], Wh
b_total_act_energynumberGesamte Wirkenergie (Verbrauch) der Phase B [L2], Wh
b_total_act_ret_energynumberGesamte rückgeführte Wirkenergie (Einspeisung) der Phase B [L2], Wh
c_total_act_energynumberGesamte Wirkenergie (Verbrauch) der Phase C [L3], Wh
c_total_act_ret_energynumberGesamte rückgeführte Wirkenergie (Einspeisung) der Phase C [L3], Wh
total_actnumberGesamte Wirkenergie (Verbrauch) aller Phasen [L1+L2+L3], Wh
total_act_retnumberGesamte rückgeführte Wirkenergie (Einspeisung) aller Phasen [L1+L2+L3], Wh
errorsarray of type stringEM Komponentenfehler. z.B.:
database_error,
(Ausgabe nur, wenn mind. 1 Fehler vorhanden) 
siehe Original: https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/EMData#status

Auswertung der MQTT – Daten

Mittlerweile nutze ich für die Auswertung und Darstellung der Daten die InfluxDB und Grafana. Im Folgenden werde ich meine generellen Gedanken zur geeigneten Auswertbarkeit der gelieferten Daten erläutern.

Grundsätzliche unterscheide ich 3 Bereiche:

Aktuelle Netzauslastung

Hier interessieren mich Werte wie Grundlast und Spitzenlasten und erweitert die Verursacher. Dazu greife ich auf die Daten aus dem Topic "70-shellypro3em-xxxxxxxxxxxx/em:0" zurück.

Insbesondere verwende ich die Verläufe von der Wirkleistung (power in Watt) und der Stromstärke (current in Amper). Aktuelle Werte (letzte Stunde), der Tages- und Wochenverlauf stehen dabei im Vordergrund.

shelly pro 3em - grafana
Muster in Grafana ohne Anschluss der Klemmen

Netzqualität

Auch hier verwende ich im Wesentlichen Daten aus der dem Topic "70-shellypro3em-xxxxxxxxxxxx/em:0". Dabei sind neben den Fehlern (error) die Werte aus der Scheinleistung (aprt_power in VA), der Spannung (voltage in V) und des Leistungsfaktors (pf ohne Einheit) im Fokus.

shelly pro 3em - diagram view
Muster der Web-GUI ohne Anschluss der Klemmen
shelly pro 3em - Classic View
Muster der Web-GUI ohne Anschluss der Klemmen

Verbrauch-/Einspeisedaten

Dafür verwende ich die in Wattstunden (Wh) angegebenen Werte aus dem Topic "70-shellypro3em-xxxxxxxxxxxx/emdata:0". Hier wird bereits der Verbrauch (act_energy in Wh) und die Einspeisung (act_ret_energy in Wh) unterschieden.

shelly pro 3em - energy graphs
Muster der Web-GUI ohne Anschluss der Klemmen

Debmatic – Installation als CCU2

debmatic homematic unter debian

Warum debmatic?

Nachdem die CCU2 nach ca. 5 Jahren nicht mehr alle Funktionen hatte stand ich vor der Wahl:

  1. Eine neue CCU3
  2. ELV-Charly
  3. RaspberryMatic
  4. Debmatic

Meine Wahl fiel auf debmatic, da ich im Wesentlichen neben HM RF und HM IP nur die RPC Schnittstelle und ggf. CUXD benötige und ich neben dem vorhandenen Proxmox Server nur eine HB-RF-ETH mit einer Funk-Modulplatine für Raspberry Pi 3, RPI-RF-MOD kaufen mußte. Inklusive Gehäuse und POE Adapter habe ich keine 100 € ausgegeben und damit die maximale Freiheit für den Ausstellungsort erhalten.

Zu keiner Zeit habe ich diese Entscheidung bereut. Absolut zuverlässig, toller Support und 100% kompatibel.

Alexander Reinert, größten Respekt für Deine Arbeit.

Alles funktioniert einwandfrei.

  • GUI,
  • RPC-Schnittstelle,
  • Alle HM und HMIP Gräte,
  • Wiederherstellung aus Backup,
  • Einbindung von HM-IP Access-Points,
  • Weiterverwendung der alten CCU2 als Gateway

Das GUI der CCU ist, sagen wir einmal, speziell. Der Vorteil, alles funktioniert. Einige Steuerungen aus der Vergangenheit sind noch aktiv. In meiner Vision sind zukünftig alle Steuerungen an einer Stelle. Leider habe ich mich noch nicht entschieden.

Ausprobiert habe ich bis jetzt:

  • FHEM - Logo – FHEM,
  • IO-Broker - Logo – IOBROKER,
  •  Homeassistant Logo – HOMEASSISTANT und
  • Node-RED Logo – Node-Red

Mein Favorit, FHEM, fällt aufgrund des Women Acceptance Factor, kurz WAF, leider aus der engeren Wahl. Da bieten alle anderen deutlich mehr (für mich machbare) Möglichkeiten. Dennoch habe ich die Hoffnung, dass irgendwann ein moderneres Frontend auch von den Puristen zumindest als Option akzeptiert wird.

Der IOBROKER bietet neben einer agilen deutschen Communitiy die flexibelste Frontend Gestaltungsmöglichkeiten. Leider gefällt mir die Middleware mit den Ressourcen vernichtenden Modulen nicht. Da sind 4 GB RAM schnell verbraucht.

Bei HomeAssistant, mein aktueller Testkanditat, kann ich mich noch nicht so ganz mit der Steuerung anfreunden. Einfaches über Automation, anderes über Templates oder node-red.

4. Raumnummernsystem und Namenskonvention

Eine Gerätetyp übergreifende Namenskonvention kann auf Basis eines beispielhaften Raumnummernsystem beruhen. Das im Folgenden dargestellte Raumnummernsystem dient als Muster. Es gibt sicher viele andere gute Systemdefinitionen. Mein Augenmerk liegt auf der übergreifenden Einheitlichkeit und der Sortierbarkeit. Je größer der “Gerätezoo” wird, desto schwieriger wird es ein durchgängig umsetzbares Bezeichnungssystem zu finden.

Wikipedia Definition

Namenskonventionen sind Festlegungen/Vorschriften/Empfehlungen für ProgrammiererDatenbankentwickler etc. zur Benennung von Bezeichnern (Namen) für Objekte im Quelltext von Software. Durch ihre Anwendung sollen die Namen dieser Objekte – im Rahmen der Syntaxbestimmungen der Programmiersprache und auch programm-übergreifend – nach einheitlichen Regeln gebildet werden, wodurch das Software-Qualitätsmerkmal Änderbarkeit (Wartbarkeit) durch einfacheres Verstehen des Programmtextes unterstützt wird.
Derartige Regelungen gelten – meist unternehmens- oder projektspezifisch – grundsätzlich für alle in der Programmierung verwendeten Konstrukte – wie Datenfelder (VariablenKonstanten), Objekte,[1] FunktionenTypenKlassenModuleProzeduren, Befehlstextabschnitte etc. und sollen zu „lesbarem Code“ beitragen.[2]

Seite „Namenskonvention (Datenverarbeitung)“. In: Wikipedia – Die freie Enzyklopädie. Bearbeitungsstand: 29. September 2022, 07:25 UTC. URL: https://de.wikipedia.org/w/index.php?title=Namenskonvention_(Datenverarbeitung)&oldid=226598825 (Abgerufen: 8. März 2023, 11:44 UTC)

Ziel: Einheitliche weitgehend durchgängige Namensgebung

Da man an verschiedenen Stellen immer mal wieder den DNS-Namen, die Gerätebezeichnung, das MQTT-Topic oder einen anderen eindeutigen Bezeichner benötigt, hilft die Namenskonvention.

Muster Raumnummernsystem als Basis für die Namenskonvention im smarten Haus:

HOME FLOORS
FLOOR ROOMS
ROOM DEVICES
NAME DESCRIPTION TYPE
raunet 00_ERDGESCHOSS 01_WOHNZIMMER 01_Licht Beschreibung light
01_FS1 Beschreibung contact
02_ESSZIMMER 02_Licht Beschreibung light
02_FS Beschreibung contact
03_KUECHE 03_Licht Beschreibung light
03_FS Beschreibung contact
04_GAESTEWC 04_Licht Beschreibung light
04_FS Beschreibung contact
05_GAESTEBAD 05_Licht Beschreibung light
05_FS Beschreibung contact
06_GAESTEZIMMER 06_Licht Beschreibung light
06_FS Beschreibung contact
09_FLUR 09_Licht Beschreibung light
09_FS Beschreibung contact
10_OBERGESCHOSS 11_WOHNZIMMER 11_Licht Beschreibung light
11_FS1 Beschreibung contact
12_ANKLEIDE 12_Licht Beschreibung light
12_FS Beschreibung contact
13_WAESCHE 13_Licht Beschreibung light
13_FS Beschreibung contact
14_EMPORE 14_Licht Beschreibung light
14_FS Beschreibung contact
19_FLUR 19_Licht Beschreibung light
19_TS Beschreibung contact
20_KELLERGESCHOSS 21_BUERO 21_Licht Beschreibung light
21_FS1 Beschreibung contact
22_HOBBY 22_Licht Beschreibung light
22_FS Beschreibung contact
23_HEIZUNG 23_Licht Beschreibung light
23_HEIZUNG Beschreibung switch
23_FBH_Pumpe Beschreibung switch
24_VORRATSROOM 24_Licht Beschreibung light
24_FS Beschreibung contact
24_Gerfiertruhe Beschreibung switch
25_HAUSANSCHLUSSROOM 25_Licht Beschreibung light
25_STROMMESSUNG Shelly 3 EM powermeter
26_DUSCHE 24_Licht Beschreibung light
26_Abluft Beschreibung switch
29_FLUR 29_Licht Beschreibung light
29_TS Beschreibung contact
30_AUSSENANLAGEN 31_EINGANG 31_Licht Beschreibung light
31_Standleuchte_groß Beschreibung light
31_Standleuchte_klein Beschreibung light
31_BWM Beschreibung motion
31_Eingangskamera Beschreibung camera
32_TERRASSE 22_Licht Beschreibung light
32_BWM Beschreibung motion
32_Quellstein Beschreibung switch
33_CARPORT 23_Licht Beschreibung light
33_BWM Beschreibung motion
34_UNTERSTAND 24_Licht Beschreibung light
34_BWM Beschreibung motion
35_SCHUPPEN 25_Licht Beschreibung light

Einsatzzweck – Lokal DNS-Name von Netzwerk-Clients

Unifi Network unterstützt, zumindest auf der Web GUI, den lokalen DNS Namen. Damit benötigt der Browser http://[lokaler DNS Name][:][Port] als URL.

image

Einstellungen tasmota:

image 2

Einstelllungen shelly (alt):

image 3

Einsatzzweck – MQTT – Topics

image 4
Shelly
image 5
tasmota

Zumindest Teile des verwendeten Topics kann bei allen Systemen vorgegeben werden.

Einsatzzweck – Device Name

In diversen Smarthome-Systemen (FHEM, ioBroker, HomeAssistant, …) können interne Namen für die unterschiedlichen Geräte vergeben werden. Auch hier empfiehlt es sich das einheitliche Benennungssystem zu verwenden.

3. Spielereien mit Shelly – Einstieg in MQTT

Mitte 2019 konnte ich dem Hype um die Shelly Produkte nicht mehr ausweichen, und habe mir, mit dem Ziel meine Bastelarbeiten durch Produkte mit CE – Zeichen ohne Cloud-Zwang zu ersetzten, direkt in Bulgarien bei alterco im Shop 4 x Shelly 1PM, 4 x Shelly 2.5 und 4 x Shelly 1 bestellt.

Die Lieferung erfolgte erfreulich schnell, was ein wenig die damals sehr hohen Versandkosten bei DHL – Lieferung rechtfertigten.

Installation

Anschlussschemas Shelly

Shelly 1

Anschlussschemas

Anschlussschemas aus dem Offiziellen Shelly Support Forum. CO-ADMIN @SparkyMaster stellt Anschlussschemas mit Urheberschutz bereit

Schaltplan Shelly
Shelly 1PM

Anschlussschemas

Anschlussschemas aus dem Offiziellen Shelly Support Forum. CO-ADMIN @SparkyMaster stellt Anschlussschemas mit Urheberschutz bereit

Anschlussschemas Shelly 1PM
Shelly 2.5

Anschlussschemas

Anschlussschemas aus dem Offiziellen Shelly Support Forum. CO-ADMIN @SparkyMaster stellt Anschlussschemas mit Urheberschutz bereit

Anschlussschemas Shelly 2.5
previous arrow
next arrow

Selbstverständlich erfolgte die völlig problemlose Installation (Verkabelung) durch einen freundlichen und interessierten Elektriker, vielen Dank dafür.

WLAN – Konfiguration

wifi funk

Alle Shellies funken im 2,4 Mhz WLAN. Unser Haus mit 3 Etagen und verschiedenen Räumen mit Fußbodenheizung ist für die optimale Verteilung von Funkwellen in diesem oder höheren Frequenzbereichen nicht wirklich geeignet. Aus diesem Grund hatte ich bereits vor der Shelly – Installation die Etagen über Devolo DLAN – Wifi verbunden.

Es wurde mir jedoch klar, dass eine Fritz-Box auf Dauer keine geeignete Lösung für mittlerweile deutlich über 30 WLAN – Clients und diverse weitere LAN – Clients sein wird. Immerhin habe ich es zum Laufen gebracht.

Konfigurationsregeln

Konfiguration über Web-GUI des Shellies (ohne Cloud):

Der Standard Mode bei Auslieferung oder nach dem Zurücksetzen auf die Werkseinstellungen ist: Access Point

Verbinden des Shellies mit dem Standard Wi-Fi-Netzwerk (im Auslieferungszustand) (SSID) z.B. wie Shelly1 – 84CCA87D7CDC ohne Passwort. Die universelle IP-Adresse für alle Shelly-Geräte lautet: 192.168.33.1, um auf die Webschnittstelle zu gelangen.

Es erscheint eine abgespeckte Konfigurationsmaske für die Erfassung der eigenen WLAN – Zugangsdaten (SSID und Passwort WPA).

Nach dem Neustart verbindet sich der Shelly mit eigenen WLAN

Über die lokale IP Adresse wird die Konfiguration fortgesetzt

Beispiel “Returned json from:” http://admin:[password]@[IP | DNS-Name]/settings

{
   "device":{
      "type":"SHSW-1",
      "mac":"0123456789AB",
      "hostname":"shelly1-6789AB",
      "num_outputs":1
   },
   "wifi_ap":{
      "enabled":false,
      "ssid":"shelly1-6789AB",
      "key":""
   },
   "wifi_sta":{
      "enabled":true,
      "ssid":"RAUNETWLANIOT",
      "ipv4_method":"dhcp",
      "ip":null,
      "gw":null,
      "mask":null,
      "dns":null
   },
   "wifi_sta1":{
      "enabled":false,
      "ssid":null,
      "ipv4_method":"dhcp",
      "ip":null,
      "gw":null,
      "mask":null,
      "dns":null
   },
   "ap_roaming":{
      "enabled":true,
      "threshold":-70
   },
   "mqtt":{
      "enable":true,
      "server":"service.iot:1883",
      "user":"admin",
      "id":"24_Deckenleuchte",
      "reconnect_timeout_max":60.000000,
      "reconnect_timeout_min":2.000000,
      "clean_session":true,
      "keep_alive":60,
      "max_qos":1,
      "retain":false,
      "update_period":30
   },
   "coiot":{
      "enabled":true,
      "update_period":15,
      "peer":""
   },
   "sntp":{
      "server":"time.google.com",
      "enabled":true
   },
   "login":{
      "enabled":true,
      "unprotected":false,
      "username":"admin"
   },
   "pin_code":"",
   "name":"24_Deckenleuchte",
   "fw":"20230329-161525/v1.13.0-rc2-g1b3e5af",
   "factory_reset_from_switch":true,
   "discoverable":true,
   "build_info":{
      "build_id":"20230329-161525/v1.13.0-rc2-g1b3e5af",
      "build_timestamp":"2023-03-29T16:15:25Z",
      "build_version":"1.0"
   },
   "cloud":{
      "enabled":false,
      "connected":false
   },
   "timezone":"Europe/Berlin",
   "lat":50.123456,
   "lng":7.123456,
   "tzautodetect":true,
   "tz_utc_offset":7200,
   "tz_dst":true,
   "tz_dst_auto":true,
   "time":"09:19",
   "unixtime":1682493563,
   "debug_enable":false,
   "allow_cross_origin":true,
   "ext_switch_enable":false,
   "ext_switch_reverse":false,
   "ext_switch":{
      "0":{
         "relay_num":-1
      }
   },
   "actions":{
      "active":false,
      "names":[
         "btn_on_url",
         "btn_off_url",
         "longpush_url",
         "shortpush_url",
         "out_on_url",
         "out_off_url",
         "lp_on_url",
         "lp_off_url",
         "report_url",
         "report_url",
         "report_url",
         "ext_temp_over_url",
         "ext_temp_under_url",
         "ext_temp_over_url",
         "ext_temp_under_url",
         "ext_temp_over_url",
         "ext_temp_under_url",
         "ext_hum_over_url",
         "ext_hum_under_url"
      ]
   },
   "hwinfo":{
      "hw_revision":"prod-2018-08",
      "batch_id":2
   },
   "mode":"relay",
   "longpush_time":800,
   "relays":[
      {
         "name":"24_Deckenleuchte",
         "appliance_type":"Switch",
         "ison":false,
         "has_timer":false,
         "default_state":"off",
         "btn_type":"edge",
         "btn_reverse":1,
         "auto_on":0.00,
         "auto_off":0.00,
         "power":0.00,
         "schedule":false,
         "schedule_rules":[
            
         ]
      }
   ],
   "ext_sensors":{
      
   },
   "ext_temperature":{
      
   },
   "ext_humidity":{
      
   },
   "eco_mode_enabled":true
}

MQTT

MQTT

Als (ehemaliger) FHEM – User hat man ein latentes Unwohlsein bei der Nutzung einer Cloud. Da Shellies auf MQTT “ohne Cloud” umgestellt werden konnten und in FHEM MQTT Server und Client Module bereits existierten, habe ich mich in dieses Thema eingearbeitet.

Trotz aller folgenden tollen Entwicklungen sehe ich auch heute noch die Vorteile dieser Kommunikation von IOT – Ereignissen über einen oder mehrere Broker und beliebig vielen Abonnenten von topics. Leider bietet dieses System einfach zu viele Gestaltungsmöglichkeiten und keinen einheitlichen Standard.

So publizieren Shellies relativ starr generell alles unter dem Topic “shellies/[devicename]/#”. Eine Abbildung des Raumnummernsystems in MQTT ist, – wenn zwingend gewünscht -, nur durch zusätzliche Topic – Spiegelungen möglich. Ich habe es mittlerweile aufgegeben und nur noch den Gerätenamen auf Basis des Raumnummernsystems vergeben.

Beispiel Shelly 1 (SHSW-1) Deckenleuchte im Vorratsraum im Keller (settings: s.o.):

Feld(er)Inhalt
Name (DEVICE NAME, CHANNEL NAME)24_Deckenleuchte
Use custom MQTT prefix24_Deckenleuchte
MQTT – Topic (base)shellies/24_Deckenleuchte/#
IPDHCP | [Fix IP without local DNS]
Local DNS24.deckenleuchte.iot
Haushome
Etage20_KELLER
Raum24_VORRATSRAUM

2. Stabilität – Homematic CCU2

homematic CCU 2 Software

<< 1. Smarthome – Einstieg

3. netAtmo – Raumklima >>

Entscheidungsfindung

Nach intensiver Beratung im FHEM Forum und den ersten Tests mit einem gebrauchten HM-LAN Adapter habe ich ein Angebot genutzt und mir eine Homematic CCU2 mit einigen Unterputz Schalten für unser Merten Standard – Polarweis angeschafft.

FHEM – Integration mit HMCCU – Modul

Allen Warnungen zum Trotz habe ich die CCU2 mit dem HMCCU-Modul von Zap in FHEM eingebunden. Hauptsächlich fehlte mir in den anderen Varianten die Unterstützung von HM-IP.

Nachdem ich mich in die Homematic GUI eingearbeitet hatte fiel es mir immer schwerer mich auf eine “Steuerung” festzulegen.

Empfohlene Informationsquellen

Neben dem offiziellen Homematic Forum ist Stefan Kleen mit seinen Videos und Blogs eine hervorragende Informationsquelle.

Wenn‘s ins Eingemachte geht ist Alexander Reinert (ist auch im Homematic Forum unter deimos aktiv) eine gute Wahl.

homematic forum

Homematic – Aktueller Ausbau

Aufgrund der hohen Stabilität und der Unabhängigkeit von einem zusätzlich 24/7 laufenden Server fand ein schneller Ausbau statt, der fast alle ESP8266 – Basteleien ersetzen konnte. Selbst die “433 Mhz gesteuerte Panikbeleuchtung” (RollingCode-Problem) konnte ersetzt werden.

Stück TypIconBezeichnung
2HM-CC-RT-DNHM CC RT DNFunk-Heizkörperthermostat
1HM-LC-Bl1-FMHM-LC-Bl1-FMFunk-Rollladenaktor 1-fach, Unterputzmontage
1HM-LC-Bl1PBU-FMHM-LC-Bl1PBU-FMFunk-Rollladenaktor 1-fach für Markenschalter, Unterputz
1HM-LC-Dim1T-DRHM LC Dim1T DRFunk-Dimmaktor 1-fach, Phasenabschnitt, Hutschienenmontage
1HM-LC-Sw4-DR-2HM LC Sw4 DR 2Funk-Schaltaktor 4-fach, Hutschienenmontage
1HM-RC-2-PBU-FMHM RC 2 PBU FMFunk-Sender 2-fach für Markenschalter, Unterputzmontage
2HM-Sec-RHSHM Sec RHSFunk-Fenster-/ Drehgriffkontakt
5HM-Sec-SCoHM Sec SCoFunk- Tür-/Fensterkontakt optisch
1HmIP-BDTHmIP BDTHomematic IP Dimmaktor für Markenschalter, Unterputzmontage
1HMIP-PSHMIP PSHomematic IP Zwischenstecker Schalten
4HmIP-SMIHmIP-SMIHomematic IP Bewegungsmelder innen
4HmIP-SMOHmIP-SMOHomematic IP Bewegungsmelder außen
5HmIP-SPIHmIP-SPIHomematic IP Präsenzmelder – innen
2HmIP-SWSDHmIP SWSDHomematic IP Rauchmelder
1HB-RF-ETHHB-RF-ETHHB-RF-ETH, RPI-RF-MOD mit externer Antenne und POE Adapter
2HmIP-HAPHmIP HAPHomematic IP Access Point 
1HM CCU2HMCCU2Homematic CCU2 als RF Gateway
35HomematicGeräteHomematic/Homematic IP

Wechsel zu debmatic

Die CCU2 und der LAN-Adapter habe ca. 4 Jahre nonstop völlig problemlos gearbeitet. Der notwendige Pflegeaufwand war sehr gering.

Zur verbesserung der Reichweite für entlegene HMIP-Geräte wurde das System um 2 x HMIP-HAP, die als LAN-Router fungieren erweitert. Da ich in 2021 meinen Proxmox -Server in Betrieb genommen hatte, stand ich vor der Wahl, ob es eine CCU3, ein RaspberryMatic oder ein debmatic als virtuelle Maschine werden soll.

Entschieden habe ich mich für debmatic in einer VM auf Proxmox mit einem HB-RF-ETH mit einem RPI-RF-MOD Funkmodule für HM und HMIP.

Seit her werkelt meine alte CCU2 als HomeMatic RF-LAN Gateway und den alten LAN-Adapter habe ich verschenkt.

Auch diese debmatic Konfiguration läuft mittlerweile schon fast 2 Jahre ohne irgendwelche Beanstandungen.

Hinweis/Empfehlung:

debmatic in einer Virtuellen Maschine von Proxmox installieren!

1. Smarthome – Einstieg

SmartHome fhem - Forum

Wie alles begann

Wie bei vielen anderen Gleichgesinnten auch waren es die ersten 433 Mhz intertechno Funkschaltsteckdosen, die den Anreiz schafften, sie mit dem PC zu steuern. Also etwas im Netz gestöbert und Systeme wie openHab und FHEM gefunden.

Intertechno Funksteckdose

Meine Wahl viel 2016 auf FHEM, weil mich die Community begeistert hat. Nicht ausschließlich die deutsche Sprache, die ich auf jeden Fall besser beherrsche als Englisch (openHAB), sondern auch der Perl Interpreter, der, im Vergleich zu Java, mir an anderer Stelle bereits über den Weg gelaufen ist.

Erste FHEM – Installation

Für meinen Mac Mini hatte ich bereits Paralles zur Windows Virtualisierung im Einsatz. Also, was lag näher, als eine weitere virtuelle Maschine auf Linux Basis (Ubuntu Server 16.04 LTS) anzulegen, und, FHEM zu installieren. Ein wenig kniffelig war das Durchreichen vom USB Anschluss, aber lösbar.

image 3

Ersten 433 MHz CUL-Stick

… nach Anleitung aus dem FHEM – Wiki zusammen gelötet. Die Firmware “geflasht”, in Parallels durchgereicht und diesen in FHEM eingebunden, perfekt, auf Anhieb schaltbar.

Nach einigen Erfahrungen und Tests im Umgang mit FHEM hatte ich das Prinzip von FHEM zumindest grob verstanden und wollte ich schnell immer mehr.

In meiner anfänglich sehr naiven Vorstellung sollte es doch irgendwie möglich sein die vorhandene Funk-Panik-Beleuchtung der Firma IVT Hirschau mit RFXTRX in FHEM zu steuern. Mir wurde jedoch schnell klar, dass es sich um eine “Rolling-Code” Fernbedienung handelt.

image 6

Einerseits war ich froh, dass unsere Panik-Beleuchtung nicht so einfach von Fremden zu steuern war, andererseits war aufgeben keine Option. Die konkrete Antwort “… Rolling Code, keine Chance …” von Markus M. im FHEM Forum beendete dann endgültig meine Bemühungen softwareseitig.

Die Lösung war letztendlich, eine der beiden angelernten Funkfernbedienungen zu opfern und mit einem Arduino den Tastendruck zu übernehmen. Dank der Unterstützung von Arnd (RaspiLED) in diesem Beitrag schaffte ich es die Steuerung über das Firmata – Modul zu übernehmen.

image 7

Matthias Kleine – haus-automatisierung.com

Als Meilenstein in meiner Entwicklung darf ich Matthias Kleine nicht vergessen. Seine Videos und Tutorials habe ich mit Begeisterung verfolgt und nachgebaut.

So entstanden diverse FHEM – Integrationen und meine FHEM Oberfläche erhielt einen neuen, meiner Ansicht nach WAF – tauglichen, Look.

image 9

Falls du das leist, Mathias, vielen Dank.

Weitere Bastel-Projekte

Terrassensteuerung mit ESP8266 und MQTT:

image 8

Logitech Harmony Elite ultimative Universal-Fernbedienung

Ein Traum wurde wahr, als meine Universal Fernbedienung von Logitech zu einem echten “Schnapperpreis” angkommen ist.

Die den folgenden Tagen, naja eher Wochen, habe ich neben unseren Hifi-Komponeten, TV, PS3, …, auch alle möglichen SmartHome Steuerungen auf diese Fernbedienung gelegt. Ein echt cooles Projekt mit gutem Ausgang dank der tollen Unterstützung der FHEM Community und im Speziellen, von justme1968.

image 11

Die Fernbedienung ist immer nach über 6 Jahren immer noch im Einsatz. Sie steuert zwar nicht mehr soviele SmartHome – Komponenten, jedoch einige Szenen werden auch heute noch damit aktiviert.

Homebridge Einstieg

Ebenfalls konnte ich auf die Expertise von justme1968 vertrauen, bei der ebenfalls erfolgreichen Homekit Anbindung.

Mittlerweile nutze ich den Homebridge Dienst, zwar nicht mehr mit FHEM-Anbindung, immer noch mit einigen Sub-Bridges für meine Apple Geräte:

image 10

Numan Two – Küchenradio

Auch unser Küchenradio konnte nicht außen vor bleiben und wurde in FHEM integriert. Hier habe ich mumpitzstuff als versierten Experten viel zu verdanken.

image 13

Hier habe ich mich, unter Anderem, intensiver mit readingsgroups, defStateIcon und stateformat von FHEM beschäftigt:

image 12

TV-Sender Integration

Entsprechend meiner Universal Fernbedienung sollte auch mein iPad die Möglichkeit bieten zu den favorisierten Kanälen über ein Senderlogo umzuschalten. Das war zügig umsetzbar.

Naja, wenn man schon mal dabei ist, wäre es doch nett so eine Art “elektronischen Programmführer” auf dem iPad anzuzeigen. Mit Bild und Text zu der gerade laufenden Sendung wäre noch besser, und, den Vogel abschießen würde es, wenn auch die folgenden Sendungen und das aktuell, zur PrimeTime und der PrimeTime folgenden Sendungen dargestellt würden mit der Möglichkeit zur Programmierung einer Aufzeichnung.

Essentiell war hier das httpmod – Modul. Mit der Unterstützung von CoolTux hatte ich (kurzfristig) mein erstes Modul erstellt. Das lief dank der Unterstützung von CoolTux auch sehr gut. Leider habe ich es im Forum und auf github mit einem viel zu kurzen Aktualisierungsinterval veröffentlicht. In kurzer Zeit hatte die von mir gewählte Programmzeitschrift so viele Zugriffe und traffic, dass man sich an offizieller Stelle beschwert hat.

Ich habe mich entschuldigt und den Code und das Modul aus dem FHEM Forum und von github entfernt, und, alle Nutzer gebeten das Interval auf > 60 Minuten zustellen, oder besser, die auf meinem Code basierenden Devices wieder zu löschen.

image 14

nmap-Modul vs Fing – Modul

Zwischenzeitlich hatte ich in einem indiegogo KickStarter – Projekt eine “FingBox” geordert.

image 15

Da die ersten Firmware Versionen keine Schnittstelle oder API zur Verfügung stellte, habe ich zunächst versucht mit dem FHEM nmap- Modul von igami den Netwerkscan auszuführen und aufzubereiten:

image 16