Fritz!Powerline546E | Fritz!DECT200

[housekeeper]

Irgendwie scheint hier forumstechnisch gerade etwas aus dem Ruder zu laufen. Wichtige Beiträge zu diesen Themen findet man an unterschiedlichen Stellen im Forum, mit steigender Tendenz ( einfach mal die Stichwörter in der Suche eingeben. wobei offenbar die Suchfunktion auf Ziffern (etwa 546) nicht reagiert.

Daß DECT unter slowRF einsortiert wird ist ja gerade noch nachzuvollziehbar, weil DECT ja nun mal ein Funkprotokoll ist. Allerdings hat FHEM mit dem Funkteil nichts zu schaffen, das macht die Fritz!Box über den AHA-Server. Oder habe ich etwas verpennt, und es gibt inzwischen ein CUL_DECT oder ein DECT_LAN ?

Das Fritz!Powerline546E hat mit Funk nun gleich gar nichts am Hut, und gehört daher nicht dorthin.

Die Gemeinsamkeit beider AVM-Produkte besteht im Wesentlichen in der Ansteuerung über den AHA-Server der Fritz!Box, also wäre entweder das ganze Thema unter Fritz!Box oder unter FBAHA einzuordnen.

Dazu kommt erschwerend, daß das Fritz!Powerline546E über eigene "Intelligenz" verfügt und einen eigenen AHA-Server mitbringt, der allerdings, mangels DECT, nichts mit den Fritz!DECT200 Dosen anfangen kann.

Aus meiner Sicht sollte, wer eine Fritz!Box 7390 (unterstützt sonst noch eine AHA ?) hat, in FHEM diese als FBAHA device einrichten. Wer _nur_ das Fritz!Powerlin546E besitzt, muß dieses Gerät als FBAHA device definieren.

Wer ein Fritz!Fon hat, kann alle diese Geräte über das Telefon-Menü abfragen oder steuern, das bringt allerdings FHEM völlig aus dem Tritt. Laut Rudi hat AVM dieses Problem erkannt und ein Firmware-Update zugesagt (für wann ?)

Ich habe derzeit eine Fritz!Box 7390, ein Fritz!Powerline 546E und zwei Fritz!DECT200 im Einsatz, als FBAHA device ist ( inzwischen) die Fritz!Box eingerichtet.

Das Fritz!Powerline 546E wird von autocreate als FBDECT_20000 erkannt und eingerichtet, die beiden Fritz!DECT200 als FBDECT_17 und FBDECT_18. FBDECT_16 wurde von autocreate an ein nicht existentes Gerät vergeben. (Gibt es Überreichweiten bei Powerline ? Könnte es das Gerät eines Nachbarn sein ?)

FHEM gibt sich große Mühe jedes Detail der registrierten Geräte realtime aufzusaugen, obwohl das bereits die beiden AHA Server machen und auf Wunsch per Email verschicken.

Weniger wäre aus meiner Sicht mehr an dieser Stelle, mir würde die Anzeige der Schaltzustände und die Möglichkeit diese zu beeinflussen an hier völlig ausreichen.

Vorschlag:

- Eine eigene Kategorie für FBAHA

- Abspecken der 00_FBAHA.pm auf ein sinnvolles* Maß und Erfassung der Detaildaten nur auf ausdrückliche Anforderung.

*) sinnvolles Maß = Anzeige und Beeinflussung der Schaltzustände mit Reduzierung des Netzwerkverkehrs auf das dazu nötige Minimum.




 

[rudolfkoenig]

>  FHEM gibt sich große Mühe jedes Detail der registrierten Geräte realtime aufzusaugen

FHEM verarbeitet nur die vom AHA Server gemeldeten Daten, das Intervall fuer Messwerte kann man inzwischen dem AHA Server mitteilen, was er genau melden soll, (noch?) nicht (auch, um das Modul einfach zu halten). Ich verstehe nicht, welcher Aspekt Dich stoert, die FHEM Events kann man auch mit FHEM-mitteln (event-*) weiter filtern.


> ...mir würde die Anzeige der Schaltzustände und die Möglichkeit diese zu beeinflussen an hier völlig ausreichen.

Mag sein, andere finden aber den Aspekt der Strom-Messung wichtig.


> - Eine eigene Kategorie für FBAHA

Muesste einer der Forum-Admins einrichten ich bin keins. Bei der Menge der Postings bin ich aber nicht so sicher, dass es sich lohnt. Ich sehe ein, dass SlowRF nicht ideal benannt ist, das ist halt Z.Zt ein Sammelbecken fuer "alles andere per Funk". Die Fritz-Box Gruppe ist eigentlich in der Kategorie "FHEM - Hardware - Themen zu diversen Plattformen auf denen FHEM betrieben wird. " zu finden, und eignet sich deswegen nicht so gut fuer FBDECT.


> Abspecken der 00_FBAHA.pm

Da gibt es nichts abzuspecken, hoechstens mit weiteren Parameter erweitern.

Was ich vermisse ist ein FBAHA/FBDECT Eintrag fuer Anfaenger in fhemwiki, das sollte aber von einem erfahrenen Anwender kommen. Als Entwickler Plfege ich commandref.html, was zwar alles beschreibt, aber evtl. zu kurz fuer den normalen Anwender.

[housekeeper]

Ich verstehe nicht, welcher Aspekt Dich stoert, die FHEM Events kann man auch mit FHEM-mitteln (event-*) weiter filtern.

Stören tut mich eigentlich nichts direkt, was ich nur feststelle, ist, daß die Datenflut der AHA-Server FHEM dermaßen zufährt, daß andere Aspekte notleidend werden. Wenn sich das filtern läßt, sollte es vielleicht als default auf minimal geändert werden, AVM sollte dann das Sendeverhalten der Teile etwas entschärfen, da die unsinnig hohe Anzahl von Paketen dem Netz sicher nicht zuträglich ist (CSMACD). Nach meinen Beobachtungen senden die Teile jede Sekunde 6mal ein (das gleiche?) Telegramm, wenn man die Geräte über das Telefon schaltet scheint es lawinenartig anzusteigen.

Mag sein, andere finden aber den Aspekt der Strom-Messung wichtig.

Na ja, soweit ich sehe werden die Schaltzustände nicht geloggt, dafür aber Leistungsdaten alle 3 Minuten

Code Auswählen Erweitern

2013-06-13_09:18:12 FBDECT_17 power: 0.00 W
Man könnte, zum Beispiel, die Schaltzustände loggen und die Leistungsdaten nur bei eingeschaltetem Gerät oder angeschlossenem Verbraucher messen. Außerdem hielte ich es für schlau, nicht parallel zur Fritz!Box nachzurechnen was sich tut, sondern die von der Box zusammengestellten Protokolle und Diagramme zu importieren, um die Last für FHEM klein zu halten.

Im Übrigen ist der _Nur-Anwender_, der so ein Teil erwirbt wohl eher daran interessiert, daß es einfach tut (Plug and Play) anstatt erst mal herauszufinden ob und wie man mit FHEM Netzwerkpakete filtern kann.

Vielleicht könnte man zwei oder drei Grundszenarien zur Auswahl stellen ?

Klar könnte man vermutlich mit FHEM Plots Lissajous-Figuren erzeugen und seine Gäste damit beeindrucken, aber was hat das noch mit Haus-Automation zu tun ?

Muesste einer der Forum-Admins einrichten ich bin keins.

Dem steht ja nichts im Wege, ich denke die lesen auch Beiträge ;-)

Was ich vermisse ist ein FBAHA/FBDECT Eintrag fuer Anfaenger in fhemwiki, das sollte aber von einem erfahrenen Anwender kommen.

Könnte ich schon machen, allerdings ist meine Erfahrung an der Ecke noch ziemlich rudimentär

[rudolfkoenig]

> was ich nur feststelle, ist, daß die Datenflut der AHA-Server FHEM dermaßen zufährt...

Das Problem ist durch einen (gemeldeten!) Bug im AHA verursacht: Das Intervall fuer die Meldungen ist wohl im AHA eine globale Variable, und wird z.Bsp. beim Aufruf von Smarthome auf einem FRITZ!Fon MT-D auf eine Sekunde gestellt. Daraufhin habe ich die Moeglichkeit in FBAHA eingebaut, das Intervall zu setzen (msgInterval). Ist trotzdem ein bisschen Kampf gegen Windmuehlen, solange AVM den Bug nicht behebt.


> ...  die von der Box zusammengestellten Protokolle und Diagramme zu importieren

Das steht Dir frei in einem neuen Modul (parallel zu FBDECT) zu implementieren, aber:
- mAn aus Architektur-Sicht der falsche Ansatz (und ich sollte es wissen :)
- es ist zusaetzlicher Programmieraufwand (und nicht wenig, siehe naechster Punkt)
- die Daten liegen damit nicht in dem Form vor, wie die FHEM-Visiualisierungs-Module (SVG/etc) es benoetigen, d.h. man muss die Darstellung neu implementieren, oder die Daten dazu irgendwie konvertieren.


> ... anstatt erst mal herauszufinden ob und wie man mit FHEM Netzwerkpakete filtern kann.

Das geht erstens nicht, und zweitens ist es ueberfluessig, weil 1-2kb/sec ein 100MBit Netz nicht wirklich belasten. Probleme kriegt FHEM auf schwacher Hardware (FB), wenn sekuendlich 6 Events pro Steckdose durch die 100 Notifies/FileLogs/Watchdogs geprueft und ignoriert werden muessen. Aber das kann man mit den event-* parameter oder mit dem  abfiltern.


>  Könnte ich schon machen, allerdings ist meine Erfahrung an der Ecke noch ziemlich rudimentär

Das ist kein Problem, da 1. man waechst mit der Aufgabe, und 2. als unerfahrener Benutzer macht man die Fehler, die andere Anfaenger auch machen, und Entwickler instinktiv vermeiden. Und sowas gehoert in das fhemwiki.