gernot - rau@home - Seite 2 von 3 in Nümbrecht

4. Mai 20237. Juni 2023

Neuer Vor-Ort-Termin

Vergangene Woche rief mich die Firma Solaris and more an und fragte an, ob am

04.05.2023

eine vorbereitende Begehung stattfinden könnte.

Sämtliche Rahmenbedingungen wurden überprüft und dokumentiert.

Dachflächen und Dachaufbau
Leitungswege
Verteilerschrank
Standort Wechselrichter und Speicher
Größe und Position des Gerüstes

Unser Wunsch, dass die an der Fassade verlaufenden Leitungsführungen über das Fachwerk verlaufen und in schwarz ausgeführt werden sollen, wurde bestätigt.

Der Zählerschrank wurde erneut begutachtet und unsere Wunschstandorte von Wechselrichter und Speicher geprüft.

Der weitere Ablauf wurde erläutert:

Fr. 12.05.23 Gerüststellung
Mo 15.05.23 Ein Team Dach und ein Team Elektro

28. April 20237. Juni 2023

Wallboxinstallation

Heute, am 28.04.2023, wurde die Wallbox installiert. Ein sehr freundlicher Mitarbeiter hat die Wallbox auf gehangen und die notwendigen Kabel sehr ordentlich und sauber bis zum Zählerschrank verlegt.

Auch meinen Wunsch zur Montage der Wallbox mit bauseits vorhandenen langen Schrauben durch die Dämmung bis in die massive Wand ist er nachgekommen.

Er hat es alleine geschafft , obwohl im abschliessenden Bericht 2 Mitarbeiter geplant waren. Außerdem enthielt der Bericht die vollständige Installation. Nach Rückfrage und Bestätigung, dass die Anschlussarbeiten im Rahmen der PV-Anlageninstallation nachgeholt werden, habe ich die vor dem Techniker per E-Mail eingegangene Rechnung für die Wallbox Installation angewiesen.

Vielen Dank an den Wallbox – Monteur.

17. April 202319. April 2023

Shelly pro 3EM

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:

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.

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/#

topic	message
`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`	number	ID der EM Komponenteninstanz
`a_current`	number or null	Phase A [L1] Messwert der Stromstärke, [A]
`a_voltage`	number or null	Phase A [L1] Messwert der Spannung, [V]
`a_act_power`	number or null	Phase A [L1] Messwert der Wirkleistung, [W]
`a_aprt_power`	number or null	Phase A [L1] Messwert der Scheinleistung, [VA]
`a_pf`	number or null	Phase A [L1] Messwert des Leistungsfaktors
`a_errors`	array of type string	Phase 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_current`	number or null	Phase B [L2] Messwert der Stromstärke, [A]
`b_voltage`	number or null	Phase B [L2] Messwert der Spannung, [V]
`b_act_power`	number or null	Phase B [L2] Messwert der Wirkleistung, [W]
`b_aprt_power`	number or null	Phase B [L2] Messwert der Scheinleistung, [VA]
`b_pf`	number or null	Phase B [L2] Messwert des Leistungsfaktors
`b_errors`	array of type string	Phase 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_current`	number or null	Phase C [L3] Messwert der Stromstärke, [A]
`c_voltage`	number or null	Phase C [L3] Messwert der Spannung, [V]
`c_act_power`	number or null	Phase C [L3] Messwert der Wirkleistung, [W]
`c_aprt_power`	number or null	Phase C [L3] Messwert der Scheinleistung, [VA]
`c_pf`	number or null	Phase C [L3] Messwert des Leistungsfaktors
`c_errors`	array of type string	Phase 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_current`	number or null	Neutral [N] Messwert der Stromstärke, [A] (wenn vorhanden)
`n_errors`	array of type string	Neutral aufgetretende Fehler. z.B. Wert außerhalb des Bereichs: `out_of_range:current`, (Ausgabe nur, wenn mind. 1 Fehler vorhanden)
`total_current`	number or null	Summe of the Stromstärke aller Phasen [L] (ohne N Werte, wenn vorhanden)
`total_act_power`	number or null	Summe der Wirkleistung aller Phasen [L1+L2+L3]
`total_aprt_power`	number or null	Summe Scheinleistung aller Phasen [L1+L2+L3]
`user_calibrated_phase`	array of type string	Benutzer kalibrierte Phasenmessungen
`errors`	array of type string	EM 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

Eigenschaft	Typ	Beschreibung
`id`	number	ID der EM Komponenteninstanz
`a_total_act_energy`	number	Gesamte Wirkenergie (Verbrauch) der Phase A [L1], Wh
`a_total_act_ret_energy`	number	Gesamte rückgeführte Wirkenergie (Einspeisung) der Phase A [L1], Wh
`b_total_act_energy`	number	Gesamte Wirkenergie (Verbrauch) der Phase B [L2], Wh
`b_total_act_ret_energy`	number	Gesamte rückgeführte Wirkenergie (Einspeisung) der Phase B [L2], Wh
`c_total_act_energy`	number	Gesamte Wirkenergie (Verbrauch) der Phase C [L3], Wh
`c_total_act_ret_energy`	number	Gesamte rückgeführte Wirkenergie (Einspeisung) der Phase C [L3], Wh
`total_act`	number	Gesamte Wirkenergie (Verbrauch) aller Phasen [L1+L2+L3], Wh
`total_act_ret`	number	Gesamte rückgeführte Wirkenergie (Einspeisung) aller Phasen [L1+L2+L3], Wh
`errors`	array of type string	EM 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

31. März 20237. Juni 2023

Terminänderung Wallbox

Photovoltaik - Anlage Terminverschiebung

Heute, am 32.03.2023, kam eine Terminänderung für die Vorbereitung der Wallbox Installation. Diesmal wurde der Termin auf den

28.04.2023

vorverlegt.

Nach der Klärung, dass es sich dabei nicht um den 1. Installationstag (= Fälligkeit der 60% Anzahlung) der Anlage handelt, haben wir erneut Urlaub umgeplant.

27. März 202328. März 2023

Debmatic – Installation als CCU2

Warum debmatic?

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

Eine neue CCU3
ELV-Charly
RaspberryMatic
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,
– IOBROKER,
– HOMEASSISTANT und
– 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.

8. März 202313. März 2023

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 Programmierer, Datenbankentwickler 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 (Variablen, Konstanten), Objekte,^[1] Funktionen, Typen, Klassen, Module, Prozeduren, 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
		ROOM	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.

Einstellungen tasmota:

Einstelllungen shelly (alt):

Einsatzzweck – MQTT – Topics

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.

6. März 202326. April 2023

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

Anzeigen

Shelly 1PM

Anschlussschemas

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

Ansehen

Shelly 2.5

Anschlussschemas

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

Ansehen

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

WLAN – Konfiguration

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

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 prefix	24_Deckenleuchte
MQTT – Topic (base)	shellies/24_Deckenleuchte/#
IP	DHCP \| [Fix IP without local DNS]
Local DNS	24.deckenleuchte.iot
Haus	home
Etage	20_KELLER
Raum	24_VORRATSRAUM

6. März 202318. Mai 2023

Photovoltaik – Anlage – Terminverschiebung

Heute war der Termin für das Aufstellen des Gerüstes. Richtig, war, denn lt. Solaris and more wurde bei der Eingangskontrolle des SMA – Wechselrichters ein Mangel festgestellt. Ein Ersatz ist nicht bis zum geplanten Termin der elektrischen Installation verfügbar.

Das Angebot, die Dachmontage, wie geplant vorzunehmen, und, die Elektroinstallation nachzuholen, habe nicht akzeptiert, da am 1. Tag der Installation 80% der Gesamtsumme gemäß vereinbarter Zahlungsbedingungen fällig würden. Meine Nachfrage, die Fälligkeit der Teilzahlung an den Termin der Elektroinstallation zu binden, wollte solaris and more nicht entsprechen.

Wir haben uns darauf verständigt, dass die vollständige Montage, Dachmontage und Elektroinstallation, am 15.05.2023 erfolgen soll. Da an diesem Termin auch der Speicher verfügbar ist, kann dann auch dieser zeitgleich eingerichtet werden.

26. Februar 20231. März 2023

2. Stabilität – Homematic CCU2

<< 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 – 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	Typ	Icon	Bezeichnung
2	HM-CC-RT-DN		Funk-Heizkörperthermostat
1	HM-LC-Bl1-FM		Funk-Rollladenaktor 1-fach, Unterputzmontage
1	HM-LC-Bl1PBU-FM		Funk-Rollladenaktor 1-fach für Markenschalter, Unterputz
1	HM-LC-Dim1T-DR		Funk-Dimmaktor 1-fach, Phasenabschnitt, Hutschienenmontage
1	HM-LC-Sw4-DR-2		Funk-Schaltaktor 4-fach, Hutschienenmontage
1	HM-RC-2-PBU-FM		Funk-Sender 2-fach für Markenschalter, Unterputzmontage
2	HM-Sec-RHS		Funk-Fenster-/ Drehgriffkontakt
5	HM-Sec-SCo		Funk- Tür-/Fensterkontakt optisch
1	HmIP-BDT		Homematic IP Dimmaktor für Markenschalter, Unterputzmontage
1	HMIP-PS		Homematic IP Zwischenstecker Schalten
4	HmIP-SMI		Homematic IP Bewegungsmelder innen
4	HmIP-SMO		Homematic IP Bewegungsmelder außen
5	HmIP-SPI		Homematic IP Präsenzmelder – innen
2	HmIP-SWSD		Homematic IP Rauchmelder
1	HB-RF-ETH		HB-RF-ETH, RPI-RF-MOD mit externer Antenne und POE Adapter
2	HmIP-HAP		Homematic IP Access Point
1	HM CCU2		Homematic CCU2 als RF Gateway
35	Homematic	Geräte	Homematic/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!

25. Februar 20232. März 2023

1. Smarthome – Einstieg

2. Stabilität – Homematic CCU2 >>

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.

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.

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.

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.

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.

Falls du das leist, Mathias, vielen Dank.

Weitere Bastel-Projekte

Terrassensteuerung mit ESP8266 und MQTT:

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.

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:

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.

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

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.

nmap-Modul vs Fing – Modul

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

…

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:

Vielen Dank an den Wallbox – Monteur.

Anschluss

Verbindung mit dem bereitgestellten (Standard) Access Point

Netzwerkeinstellungen

Verbindungseinstellungen (hier: MQTT)

MQTT Messages

70-shellypro3em-xxxxxxxxxxxx/#

Verwendete Werte und Einheiten im Topic em:0

Verwendete Werte und Einheiten im Topic emdata:0

Auswertung der MQTT – Daten

Aktuelle Netzauslastung

Netzqualität

Verbrauch-/Einspeisedaten

Warum debmatic?

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

Wikipedia Definition

Ziel: Einheitliche weitgehend durchgängige Namensgebung

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

Einsatzzweck – Lokal DNS-Name von Netzwerk-Clients

Einstellungen tasmota:

Einstelllungen shelly (alt):

Einsatzzweck – MQTT – Topics

Einsatzzweck – Device Name

Installation

Anschlussschemas Shelly

Anschlussschemas

Anschlussschemas

Anschlussschemas

WLAN – Konfiguration

Konfigurationsregeln

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

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

MQTT

Entscheidungsfindung

FHEM – Integration mit HMCCU – Modul

Empfohlene Informationsquellen

Homematic – Aktueller Ausbau

Wechsel zu debmatic

Wie alles begann

Erste FHEM – Installation

Ersten 433 MHz CUL-Stick

Matthias Kleine – haus-automatisierung.com

Weitere Bastel-Projekte

Terrassensteuerung mit ESP8266 und MQTT:

Logitech Harmony Elite ultimative Universal-Fernbedienung

Homebridge Einstieg

Numan Two – Küchenradio

TV-Sender Integration

nmap-Modul vs Fing – Modul

…

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