**Der Weg zum individuellen Smart Home: Abschied von Amazon Echo & Einzug von Node-Red**

Vor einiger Zeit haben wir eine Entscheidung getroffen: Die Amazon-Echo-Geräte müssen nach und nach weichen. Den Anfang machte unser Echo Show 15, der durch ein **43-Zoll-Touchdisplay** ersetzt wurde. Da ein so großes Display auch eine entsprechende Oberfläche braucht, haben wir uns für ein komplett eigenständiges Infosystem auf Basis von **Node-Red** entschieden.

Hier laufen jetzt alle Fäden zusammen: Fahrpläne, das aktuelle Wetter, unsere Kalender und die Energieverbräuche im Haus sind auf einen Blick sichtbar.

**Warum Node-Red und nicht FHEM-Boardmittel?**

Unser Backend ist zwar weiterhin #FHEM, aber die nativen Oberflächen (wie das ansonsten sehr gute FUI) stießen bei meinen individuellen Wünschen an ihre Grenzen. FUI ist klasse, bleibt aber weitgehend im FHEM-Kosmos.

Mit Node-Red habe ich dagegen die volle Freiheit:

Die Einbindung externer Dienste ist wesentlich flexibler.

Die Gestaltung der Ansichten (Wetter, Kalender etc.) ist völlig frei.

Ein besonderes Highlight: Ich habe den bekannten „Wetter-Willy“ nachprogrammiert – allerdings in einer speziellen Version. Bei uns ist es **Ami (aus Sailor Moon)**, die je nach Wettervorhersage automatisch die passende Kleidung anzieht. Ein kleiner Nerd-Faktor, der das System erst richtig sympathisch macht! ✨

**Die mobile Ergänzung: Der „kleine Bruder“ für die Hosentasche**

Da man nicht immer vor dem großen Display steht, wollte ich die gleiche Logik auch für die schnelle Bedienung am Smartphone haben.

Entstanden ist eine mobile Node-Red-App, die auf pure Effizienz getrimmt ist. Kein langes Suchen in irgendwelchen tiefen Menüstrukturen, sondern direkter Zugriff auf das Wichtigste:

Morgens mit einem Klick die benötigten Lampen steuern.

Ein schneller Blick in den Tageskalender.

Alles optimiert für die „Ein-Hand-Bedienung“ zwischendurch.

**Wie geht es weiter?**

Zugegeben, durch diese neue Oberfläche hat sich FHEM bei uns wieder ein wenig Verweildauer „erkauft“. Das System läuft stabil, aber perspektivisch steht auch hier eine Ablösung auf dem Plan, um das Setup noch moderner zu gestalten.

Es bleibt ein Work-in-Progress – genau wie die vollständige Ablösung von Amazon. Aber mit dem 43-Zöller und der neuen Handy-App ist ein großer Meilenstein erreicht und der Kreis schließt sich langsam.

#SmartHome #HomeAutomation #NodeRed #FHEM #SailorMoon #AmiMizuno #DIY #SelfHosted #Visualisierung #Dashboard #OpenSource #AmazonExit

Was macht ihr, damit euer #fhem - Interface nicht ganz so den Charme der 80er-Jahre hat?

Ich meine nicht das #ftui3 o.Ä., sondern das Standard-Webinterface. Ich verwende nicht dass Default-CSS (furchtbar 😬), sondern dark, aber da geht bestimmt mehr?

Außerdem gibt's z.B. in jedem Raum doppelte Einträge, weil manche Geräte in mehreren Gruppen sind. Sieht furchtbar aus...

Wäre so schön, wenn man das Interface stolz zeigen könnte, anstatt zu entschuldigen, daß es halt alt ist.

#ui #ux #css #homeautomation

@techtobi Mit #fhem vermute ich mal, daß das mehr ist als"nur" ne Kamera? Was wird automatisiert? Futterausgabe und Reinigung?

@techtobi @k1m Interessant... Ich habe ein ähnliches Setup (#fhem #Pi4, #zwave) und die Latenz ist manchmal grausam. Normalerweise schon jenseits der 300ms, also spürbar. Manchmal im mehrere-sekunden-Bereich.

What's your end of year project? Mine was to #repair the recirculating air of my decades old baking oven. It was easy: go to https://ersatzteilshop.de , enter the model into their search engine and two days later, the spare part arrived. A little bit of dirty work and Bob's your uncle.

Why repair such an ancient oven? It's an exercise in self efficiacy and #righttorepair. But mainly, I can integrate it into my #fhem #homeautomation easily with a #zwave plug. That's sufficient to switch it on and off on schedule and send me a message via #xmpp / #jabber when it is preheated.

The fancy new ones can, of course, be integrated, too. If I use their ruddy, proprietary #cloud service and pay with my data and lose connection when they decide to discontinue their "service". No, nothing that needs cloud connection or can't be #selfhost|ed will join my home automation.

Ich nenne einen 868MHz-#CUL (#SDR als USB-Stick) mein Eigen. Den habe ich früher als Adapter für #FS20-Geräte unter #FHEM verwendet.

Ich hätte eigentlich gerne einen #LoRa -Scanner. Kennt jemand eine Firmware für den CUL, den man als LoRA-Scanner einsetzen kann?

#Fedihelp

@Ann_Effes

Ich hab keine #Homematic Geräte aber im Forum steht dass die #CCU2 wohl #FS20 unterstützt und die CCU2/HCU wird von #HomeAssistant unterstützt.

Man kann scheinbar auch HA Sensoren auf das #FHEM log pointen, die dann Werte herauslesen.

Alle Angaben ohne Gewehr 🔫

https://community.home-assistant.io/t/homematic-ccu2-fs20-cux/453724

@ron schau dir mal docker compose an. Das läuft auch auf einem Raspberry und würde dich aus der Abhängigkeits-Hölle bringen. Bei mir ist praktisch jeder Dienst gedockert. Von #FHEM über #paperlessngx bis #immich. Ein grosses compose.

So, mal Klartext: Der Echo Show 15 bei uns im Flur ging mir schon ewig dermaßen auf den Keks!

Das Ding mutiert zur reinen Dauerwerbesendung, die man nicht mal abstellen kann. Und der Nutzen? War eh schon immer mau. Als Bilderrahmen ein Witz (viel zu klein!) und die Zwangswerbung war echt der Showstopper.

Es war Zeit, den Anfang vom Ende der Amazon-Ära bei uns einzuläuten!

Rauswurf! Der Echo Show 15 war das erste von 12 (!) Geräten (Echos, FireTV, etc.), das hochkant rausflog. Ganz ehrlich, das Teil war (direkt nach der lahmen FireTV Box ohne GBit-LAN) der absolute Fehlkauf des Jahrhunderts. Also: Weg mit dem Schrott!

Okay, ABER: So ein Info-Screen im Flur... Kalender, Wetter, schnelle Notizen... das war schon praktisch. Das wollten wir irgendwie behalten.

Und wie es der Zufall so will: Nach 'nem Hardware-Shuffle bei uns stand plötzlich ein fetter 43-Zoll 4K-Monitor arbeitslos rum. Gleichzeitig langweilte sich mein Raspi 400 ("Sagiri") zu Tode.

Moment mal... Monitor? Check. Computer? Check. Hmmmm... Da geht doch was!
Blöd nur: Im Flur mit 'ner Maus rumfummeln? Nee, danke. Der Echo Show hatte ja wenigstens Touch. 'ne Touchfolie für den 43-Zöller? Kurz gegoogelt und... HOLY MOLY! Schweineteuer. Da bist du sofort im vierstelligen Bereich. Vergiss es.
Irgendwann bin ich dann über Infrarot-Rahmen gestolpert (GreenTouch, für die Nerds). Das Ding packst du quasi *vor* den Monitor. Innen sind LEDs, die ein unsichtbares Gitter spannen. Finger durch? BÄM – Touch-Eingabe! Ob das klappen kann?

Und WIE das klappt! Das rockt richtig!

Unser Monitor hat kaum Rand, aber egal. Den IR-Rahmen pappt man mit Doppeltape drauf. Ein bisschen Nervenkitzel war's schon – bei dem Tape hast du nur *einen* Versuch, keine Korrektur. Also, zu zweit, paar Mal "trocken" geübt, angehalten, Luft angehalten... und... passt! Monitor hochkant gedreht – zack, 43-Zoll-Touch-Tablet!
Hardware steht. Jetzt die Software. Was soll drauf? Wie soll's aussehen?

Der Plan: Wir drei (meine Familie) kriegen eigene, persönliche Dashboards. Weil ich eh mittelfristig von FHEM weg will (Richtung HomeAssistant) und die Standard-Dashboards alle lahm fand, hab ich alles in NodeRed gebaut. Damit hatte ich ja schon bei FHEM und meinen Victron-Sachen rumgespielt.

Bei der Optik hab ich mich fett bei Star Trek bedient: LCARS! Oben 'ne Leiste für unsere persönlichen Ansichten, links ein Menü für spezielle Seiten, rechts schnelle Status-Infos. Und ganz unten ballert ein RBB24-Newsticker durch.

Was muss rein? Klar: Unser Kalender, Wetter, Lichter ausknipsen, Haus-Status. Absolutes Must-have: Robins Stundenplan (heute/morgen), der natürlich Ferien und Feiertage checkt. Und weil's geht: Abfahrtszeiten vom Bus um die Ecke.
Das Teil soll natürlich nicht 24/7 leuchten. Plan A (der coole Plan): Kamera drüber! Wenn einer davorsteht -> Display an. Und (jetzt kommt's!): Gesichtserkennung! Das Display sollte *wissen*, wer ich bin und *meine* Seite zeigen. Für Gäste gab's 'ne Touri-Seite.

... Tja. Das war dann wohl *etwas* zu ambitioniert.

Problem 1: "Sagiri" (der Raspi) kriegt den Monitor nicht aus. HDMI abschalten? Fehlanzeige. Lösung? Der gute alte Holzhammer: 'ne Funksteckdose, die in FHEM hängt. Sagiri funkt jetzt an FHEM: "Mach Saft an!" oder "Mach Saft aus!". Klappt.

Problem 2: Die Gesichtserkennung. Lief... naja... instabil. Lag vielleicht weniger am Raspi als an meiner Faulheit, tausend Trainings-Fotos von uns zu machen. Egal. Plan B: Die Kamera checkt jetzt nur *ob* einer da ist. Display geht an. Und die eigene Seite? Ist ja nur einen Fingertipp entfernt. Passt auch.

Aber fast wär's GANZ gescheitert! Der Standard-USB-Kamera-Node in NodeRed ist andauernd abgeschmiert. Nach 'ner Stunde war Schicht im Schacht. Panik! Zum Glück hab ich irgendwo einen 8 (!) Jahre alten, völlig verstaubten Node ausgegraben, den ich eigentlich nie nutzen wollte... und siehe da: Das Ding läuft stabil wie ein Panzer! (Und wenn der auch zickt, kommt 'n oller Bewegungsmelder drüber. Das geht *immer*.)

So! Hardware: Check. Software-Hürden: Genommen. Der Rest war pure Fleißarbeit am Code.

Und jetzt? FERTIG! Unser "LCARS-Echo-Killer" hängt und läuft. Hat mich alles in allem (Material besorgen + Programmieren) gut zwei Wochen gekostet.

Und jetzt grübel ich... Hmmmm... Was, wenn ich den 65-Zöller in der Küche auch... *touchy* mache? Die FireTV Box nervt mich eh. Der TV könnte doch GoogleTV... Nur mal so'n Gedanke...

#pi400 #nodered #fhem #echoshow #lcars #fhem #smarthome #dashboard #greentouch

@nesges verrückt, ich kenne dich sonst nur als @dnddeutsch und sehe nun, dass du auch was für #FHEM machst. Ich bin da zwar nicht mehr aktiv, aber habe mal archetype, LuftdatenInfo, monitoring, msgDialog, Nmap und powerMap initial beigesteuert

#homeassistant ist ein wirklich gutes Projekt. Das Automationen nach einem Reboot allerdings ihren Status vergessen, empfinde ich als architektonische Fehlentscheidung. Das muss für jede einzelne Automation ein entsprechender Fall angefangen werden. Das hat mir bei #fhem damals besser gefallen. allerdings hat HA auch echt schicke Vorteile ggü. Fhem.

#smarthome

Tado macht sich unbeliebt

https://blog.sengotta.net/tado-macht-sich-unbeliebt/

Auf jeden Fall bei den ganzen Usern von Home Assistant, Openhab, FHEM und Co. Dann all deren Integrationen von Tado Produkten beruhen auf einer, meines Wissens nach inoffiziellen, API des Herstellers.

Und für diese API wird jetzt ein Ratelimit eingeführt wie man der nachstehenden E-Mail, die auch an mich ging, entnehmen kann:

Hello BjöRn,

We have an important update for users of our REST API, which—while never officially supported for third parties—we’ve historically left open and unrestricted. We’ve always believed in fair use, and we intend to continue supporting that principle.

The API is commonly used by third-party and open-source platforms (e.g., Home Assistant), as well as by users running their own custom scripts. Nevertheless, a small fraction of very frequent API users are currently responsible for a disproportionately high share of our server expenses.

To ensure long-term stability and to avoid restricting access for everyone, we will begin introducing daily usage limits for API calls.

Your daily quota will depend on whether you have an active tado° Auto-Assist subscription:

Without Auto-Assist: 100 requests/day
A small daily quota, which should still support basic use cases that are not available via tado’s local APIs: HomeKit for V3/V3+ devices or Matter for tado° X devices. We have updated the documentation on how to access the REST API to reflect these changes.

With Auto-Assist: 20.000 requests/day
This should cover even more demanding use cases, and the subscription fees enable us to offset the increased costs associated with additional server calls.

We’ve shared these changes very early in our consideration process with Home Assistant, the largest open-source software using the unofficial tado° REST API, asking them to adapt their integration to rely more on tado’s local APIs. We understand this creates challenges for community projects. Therefore, we will slowly ramp down limits over the next few months for a smooth transition.

Our goal is to strike a fair balance, ensuring that responsible use remains possible while keeping infrastructure costs under control.

Thank you for your understanding.

Warm regards,

Your tado° Team

Und für die User keine Auto-Assist Subscription haben (oder ein altes Gerät wie ich wo Auto Assist / Geofence halt ein garantiertes Feature war) sind die 100 Anfragen am Tag sehr wenig, vor allem wenn man mehrere Heizkörperthermostate hat etc.

Dementsprechend steil gehen gleich viele User auf Github im Home Assistant Issue Tracker:

https://github.com/home-assistant/core/issues/151223

Ich habe da meine Meinung auch kund getan und dafür natürlich kein „Daumen hoch“ bekommen. Eher recht viele Downvotes, aber gut es ist halt Github: das X der Codehosting Plattformen. Codeberg.org ist die nettere Alternative (schamlose Werbung für dieses tolle Projekt).

Nichtsdestotrotz: Manche haben tausende Pfund / Euro etc. für die Tado Hardware ausgegeben, gerade wegen der inoffziellen offenen Cloud API (hört sich blöd an ist aber scheinbar so), und scheuen sich jetzt die 30€ im Jahr extra für den Auto Assist auszugeben. Die meisten davon haben diese Hardware auch Freunden und Familie empfohlen wegen der offenen inoffiziellen Cloud API. Wie steht man denn jetzt nur da.

Ehrlich gesagt fehlte hier wahrscheinlich bei den Projekte wie Home Assistant etc. ein großer warnender Hinweis. Woher soll der normaler User auch wissen das die Integration auf das Wohlwollen des Herstellers angewiesen ist.

Tado wirft man jetzt vor nur zusätzlich Kasse machen zu wollen, indem man die ganzen Home Assistant etc. User in ein Subscription Modell treibt. Abwegig ist das nicht nicht. Cloudserver wollen bezahlt werden und nur noch wenige Hardware Hersteller deren Produkt Cloudfeatures benötigt kommen ohne ein Abo Modell aus. Warum sollte es bei Tado anders sein. Denn ganz ehrlich, wenn es nur an einigen wenigen Akteuren liegt die die API missbräuchlich nutzen (wie in der Mail beschrieben), könnte man diese sicher auch auf anderem Wege blocken ohne alle API User abzustrafen.

Aber ganz ehrlich: dieses rumgejammer der Community ist doch nur peinlich. Nur weil man sich vorher nicht vernünftig informiert hat, sich so über den Hersteller zu echauffieren, ist doch kindisch.

Möchte ich ein Produkt was ohne Cloud Zwang auskommt, und dazu kann ich nur raten, dann muss ich mich vorher gründlich informieren. Kaufe ich ein Produkt was auf der inoffiziellen Cloud Api des Herstellers aufbaut kann ich mich nicht beschweren wenn die auf einmal weg ist. Und hier ist Sie ja noch nicht einmal weg.

#cloudzwang #fhem #homeassistant #openhab #smarthome #tado

@bjoern

Orrr. APIs nicht-rückwärtskompatibel ändern, wer kommt auf so Blödsinn? In dem fall #Shelly

Usecase: Terrasse hat Licht mit Bewegungsmelder. Wenn man im Sommer abends draußen sitzt will man aber auch dauer-an oder dauer-aus haben. Also Shelly zwischen BWM und Lampe gepackt.

Mit #FHEM über MQTT dann auf Wunsch input detached gesetzt (nicht output zugehörig) und den output auf an oder aus.

Für Normalbetrieb mit BWM den Ausgang wieder auf Follow-Input, dass es auch bei Ausfall WLAN/FHEM geht.

Heute war der letzte von 4 Stromzählern dran:
Dank IR Lesekopf inklusive WLAN-Anbindung kann ich jetzt endlich alle Werte in #FHEM einlesen und weiter verarbeiten.

#heimautomatisierung #FHEM #MQTT

@hobbyblogging Ich finde bei #fhem mangelt es weniger an der Optik. Von einer #Automatisierung erwarte ich auch nicht das Interface zu sehen, soll ja schließlich alles automatisch passieren.
Und wenn man #Eyecandy will, dann gibt's andere Styles, ftui und Floorplan.

In der Automatisierung ist FHEM auch spitze. Es ist unglaublich, was das alles kann.

Aber was *absolut* grottig ist, ist die #discoverability. Schau dir mal die Doku von doif an. Unglaublich mächtiges Tool, aber für mich als Dipl. Inf. (FH) mit 30 Jahren Erfahrung total unverständlich. Ich mag #RTFM, aber auch nach Lektüre der Doku bekomme ich vieles immer noch nicht hin.

Dann gibt's halt auch echt *viel* Doku die kein Mensch lesen kann. Wenn du nicht *weißt* daß es ein bestimmtes Feature gibt *und* wie es heißt, dann hilft nur das Forum.

Leider glaube ich nicht, daß man hier was ändern kann. FHEMs Schicksal wird es sein, nur von FHEM-spezial-Nerds verwendet zu werden. Leider.

Wo wird eigentlich FHEM in 10 Jahren stehen? 🤔 Wird es das Projekt sein, dass irgendwann nur noch von denjenigen eingesetzt wird, die selbst daran schrauben? Versteh mich nicht falsch, aber bei FHEM wird ein wichtiges Bedürfnis von mir schon allein durch die Screenshots nicht erfüllt: Eine ansprechende Optik. 😞 FHEM ist ein bisschen der Onkel, der seit 40 Jahren den gleichen Pulli trägt beim Familienfest. #FHEM #SmartHome #HomeAutomation #TechnikTrends

@spmrider Bei dem Board hätte das sogar sein können. Das konnte damals gut in #FHEM integriert werden 🙂

Die Installation einer Wallbox haben wir genutzt, einen Shelly Pro 3EM in den Sicherungskasten zu integrieren.

Ich wollte endlich sehen, wieviel Leistung wir wirklich abrufen.

Der Shelly ist ein 3-Phasen-Messgerät. Die Leistung wird induktiv gemessen.

Die Installation war einfach, da spare ich mir ein näheres Beschreiben.

Doch der erste Eindruck war ernüchternd. keines meiner erhofften Ziele wurde unmittelbar erreicht (Bild 1)

Weder konnte ich sagen, wieviel Leistung WIRKLICH gerade von meinen Geräten gezogen wurde, noch wieviel in Netz an eigener Leistung eingespeist wurde.

Zum Glück messe ich den Solar-Ertrag separat und speichere diesen Wert in ein laufend (alle 5 Sekunden) aktualisiertes Reading.

Addiere ich nun die Active Power aller drei Phasen und addiere den Solarertrag, habe ich den gesamten Leistungsabruf.

Der Shelly wird in FHEM per MQTT eingebunden.
Am state-format etwas herumgefriemelt, ergibt sich auch eine akzeptable Anzeige (Bild 2).

Wozu brauche ich diesen Gesamtleistungswert? Ich kann damit das Zuschalten der Batterie viel besser auf den Leistungspunkt steuern. Vor dem Shelly fehlten mir immer ca. 50-150 Watt (+ Heizungskessel, dessen Messschalter mir zwischenzeitlich kaputt gegangen ist. Die Heizung selbst zieht zwischen 1500 Watt (Anzünden) und 150 Watt normaler Betrieb mit allen Pumpen etc.), die ich nicht gemessen hatte und die damit immer aus dem Netz bezogen werden mussten, obwohl Akku-Strom vorhanden war. Ganz sauber ist das noch nicht, da die Victron-Orions keine auf den Punkt gebrachte Leistung bereitstellen. Ein Orion kann bis zu 50 Watt mehr (oder weniger) Leistung liefern, als er grundsätzlich soll. Und auch während des Betriebes bleibt die Leistung nicht konstant. Insbesondere wenn die Orions heiß werden, und sie werden SEHR heiß, sinkt ihr Wirkungsgrad.

Daher investiere ich ja soviele Ideen in die Kühlung. Mittlerweile wird kein Orion mehr über 60°C warm, selbst die 50°C werden nur noch selten überschritten. Positiv ist, dass die Kühlung an der Energie-Ausbeute nichts negativ verändert hat. Denn der bessere Wirkungsgrad wird durch die Kühlung nicht aufgefressen. Die Geräte fahren also auf weniger Verschleiß und liefern sogar geringfügig mehr Energie als Strom, als durch die Kühlung "verloren" geht.

BTW: Der Energieverbrauch, der mit dem Shelly gemessen werden kann, interessiert mich allerdings gar nicht. Ich habe direkt vor unserem Zähler einen Sensor sitzen, der ca. alle 5 min den Zählerstand übermittelt. Da sich der Zähler innerhalb von 5 min nur wenig ändert, reicht mir das.

#shelly #fhem #victron #mqtt #orions #stromverbrauch

So, mittlerweile ist es doch akut geworden, sich über das Logging in FHEM Gedanken zu machen. Nach 1,5 Jahren haben sich 87.000.000 Datensätze haben sich in der DbLog angesammelt. Vernünftig handhaben lassen sich diese Daten kaum.

Es ist also Zeit sich einmal grundlegende Gedanken zum logging zu machen.

1. Grundregel: Logging generell ausstellen für JEDES neue Gerät. In die fhem.cfg gehört dieser Befehl:

```
attr global DbLogExclude .*
```

Damit wird erreicht, dass kein Gerät Daten loggt. für jedes Gerät wird explizit entschieden, ob es geloggt werden soll:

```
attr DEVICE DbLogInclude READING1,READING2,READING3
```

2. Nur Veränderungen werden geloggt:
Ohne die folgende Zeile wird *SEHR* viel protokolliert.

```
attr DEVICE READING1,READING2,READING3
```

Damit werden nur geänderte Daten geloggt.

3. Genau überlegen, wofür man die geloggten Daten *WIRKLICH* braucht.
Mir fallen nur 2 Gründe ein: um Fehlern auf die Schliche zu kommen, für Diagramme (Plots, also statistische Erhebungen). Es werden beim Logging ja zwei Tabellen bedient: Eine Tabelle enthält immer den letzten Wert und eine Tabelle enthält auch historische Werte. Wann immer auf aktuelle Werte zurückgegriffen werden soll, wird die current-DB bemüht und nur für Plots und dergleichen wird auf die Histrory zurückgegriffen. Und genau diese wird sehr schnell sehr gross. Bei mir nach 1,5 Jahren knapp 1 TB.

Und je größer die Datenbank, bei MariaDB wird der Zugriff auf die Daten immer langwieriger. Und irgendwann ist sogar das Löschen kaum noch möglich.

Ich habe Schritt für Schritt angefangen zu löschen

```
set DBLog delete OldDays TAGE
```

löscht alles, was älter als TAGE ist. Ich habe Monatsweise gelöscht. Mein System löscht ungefähr 300.000 Datensätze pro Stunde. Pro Monat sind ungefähr 5 h notwendig. In der zeit kann nicht in die Datenbank geschrieben werden. Es gehen aber keine Daten verloren, sie werden zwischengepuffert. Bei mir waren das durchaus im Bereich 30.000 bis 40.000 Datensätze. Ich weiss nicht, wieviele Datensätze das System zwischenspeichern kann... Da ich zum tageswechsel rechenintensive Routinen laufen habe, hab ich es immer so getimet, dass ich weit vor Mitternacht aufgehört habe. Nach 3 Tagen hatte ich ein halbes Jahr Daten über Board gekippt.

4. Da im Laufe der Zeit immer mehr protokolliert wurde, habe ich mich rangesetzt, und bin die Geräte durchgegangen und hab Unsinniges gelöscht. Dazu habe ich aber eine Liste aller Devices gebraucht. Über FHEM weiss ich nicht, wie man hier eine Liste bekommen kann. Das habe ich daher ausserhalb von FHEM gemacht: mit phpMyAdmin. Der folgende SQL-Befehl gibt alle Devices aus und sagt auch, wie viele Datensätze enthalten sind.

```
SELECT history.DEVICE, Count(history.DEVICE) AS
AnzahlvonDEVICE
FROM history
GROUP BY history.DEVICE;
```

sowas kommt dabei raus:

```
Robin_6fachTaster6 6
RonIP 3608305
RouterIP 176987
Schlafzimmer_Thermostat_Clima 30604
Serverstrom 2252086
ShellyBad 63924
SpielZimmer_Heizung_Messwerte 675
```

DIe Geräte mit nur wenigen Treffern sind egal, da wird eher nichts (mehr) protokolliert. Aber alle anderen schaut man sich an. Bei Thermostaten kann man viel sparen: denn wenn man neben dem Stellmotor noch einen Wandthermostaten verwendet, braucht man beim Stellmotor ausser der Ventilöffnung, wenn man die braucht, werden Temperatur noch Luftfeuchtigkeit protokollieren, das tut man beim Wandthermostaten.

Bei Strommessern habe ich die Stromstärke mitgeschrieb en. Wozu? Hab ich noch nie gebraucht.

Bei Schaltern braucht man nicht mitloggen, wie oft man geschaltet hat. u.s.w. u.s.f.

Ich werde jedenfalls noch weiter löschen, bis ich beim 1.1.25 angekommen bin. Da ich zwischenzeitlich die zu speichernde Datenmenge ordentlich ausgemistet habe. Sollten die anfallenden Daten überschaubar sein. Am Interessantesten sind bei mir die Energie-Messwerte. Da könnte man überlegen, ob man die Daten nicht FHEM ausdünnen läßt. z.B. einmal im Monat schmeisst man alles weg, ausser den letzten Wert. Oder man mittelt die tageswerte und hebt nur den Mittelwert auf. Mal schauen. Aber insgesamt denke ich, alles was länmger als 1 Monat zurückliegt, ist eher uninteressant und kann weg. Aber als Daten-Messi fällt es natürlich schwer, sich von Datenmüll zu trennen!
#fhem #dblog #mariadb #wermisstmisstmist

@bodomenke @rsa mit perl doifs können eigene Automationen programmiert werden. Also nicht im yaml Syntax, sondern mit einer Programmiersprache. In #fhem mit Perl, da die Software darauf basiert.