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.
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.
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.
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.
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.
Muster der Web-GUI ohne Anschluss der Klemmen
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.
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.
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.
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.
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.
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.
Einstellungen tasmota:
Einstelllungen shelly (alt):
Einsatzzweck – MQTT – Topics
Shelly
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.
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.
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
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.):
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.
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
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!
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.
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:
Zum Ändern Ihrer Datenschutzeinstellung, z.B. Erteilung oder Widerruf von Einwilligungen, klicken Sie hier:
Einstellungen