Version vom 13. Mai 2013, 21:23 Uhr

Open Issues

Vor Entwicklungsbeginn von fhem 5.x zu klaeren

Informationsumfang von xmllist

xmllist muss alle Werte mitnehmen, da sonst diese nie angezeigt werden.

xmllist hat auch weitere Daten:

die Liste aller moeglichen set Werte
die Liste aller moeglichen Attribute

Variante: Optionales Argument bei xmllist, das die Detailstufe oder der Informationsumfang eingrenzt.

Aufbau einer Polling-Infrastruktur für Geräte, die nicht aktiv den Zustand melden

Beispiele: EMEM, M232. Denkbar auch zur Identifikation von toten Geräten (USF1000 muß alle 30 Minuten einen Wert liefern; bleibt der n mal aus, wird eine Warnung erzeugt).

Multithreading/Parallelisierung

Nähe zur Polling-Infrastruktur

Dokumentation

Standardfunktionen: AttrFn AttrList Clients DefFn GetFn ListFn Match MatchList NotifyFn ParseFn ReadFn ReadyFn SetFn ShutdownFn StateFn UndefFn WriteFn

Erstellung eines Template-Moduls

Kommentierte Vorlage nn_Modul.pm fuer fhem 5.x.

Erweiterungen/Verbesserungen

Auslagerung der Funktionen für die Bildung von Mittelwerten über Zeitintervalle in ein eigenes Modul

z.B. Niederschlag pro Tag, Woche, Monat Module: CUL_WS,KS300,CUL_EM

contrib/dblog/93_DBLog ins FHEM-Verzeichnis aufruecken lassen

Kann benutzt werden, um Events in Datenbanken zu loggen.

Todos:

FileLog-artigen Getter implementieren
Komplettdump
Auflistung der gespeicherten Daten

Logs und Zeitreihen

Derzeit erfuellen Logs u.a. zwei grundverschiedene Aufgaben:

der Benutzer kann sehen, was zu einem bestimmten Zeitpunkt passiert ist
ein Frontend kann daraus eine Zeitreihe ableiten fuer eine Grafik

Es sollte geklaert werden, wie mit den daraus entstehenden Anforderungen an die Logs (moeglichst gut menschenlesbar vs. moeglichst gut maschinenverarbeitbar) optimal erfuellt werden koennen.

Martins Liste der Readings, Internals, etc.

beispiele: local, LOCAL po, PortObj socket, SOCKET Type, TYPE

weitere teils unklare bezeichnungen, die evtl. harmonisiert werden könnten: DELTAUNIT, NUMUNITS, RAINUNIT, UNIT, UNITS, WINDUNIT CODE, FamilyCode, HOUSE INTERVAL, Timer, TRIGGERTIME NAME, DeviceName NR, DEVNR

dann sind da die standardfunktionen bei Initialize, die einfach mal dokumentiert werden müssten: AttrFn AttrList Clients DefFn GetFn ListFn Match MatchList NotifyFn ParseFn ReadFn ReadyFn SetFn ShutdownFn StateFn UndefFn WriteFn

einer weiteren betrachtung bedarf der trigger für notify's: CHANGED sowie der eigentlichen READINGS welche aber in einem anderen context behandelt werden sollten.

einige feste parameter können vorab schonmal gefiltert werden: DEF IODev NAME NR STATE TYPE

je nach IODev können weitere dazu kommen: CUN868_MSGCNT CUN868_RAWMSG CUN868_RSSI CUN868_TIME LASTIODev MSGCNT RAWMSG RSSI

bei X10 fiel auf, das in den Internals MODEL gesetzt wird aber explizit nochmal model in den Attributes vorkommen.

bei CUL_WS fiel auf, das die STATE summary sowohl in den Internals als auch in den Readings auftaucht, obwohl in den Readings einzelne werte vorhanden sind: Internals: STATE T: 16.7 H: 66.7 Readings: humidity 66.7 state T: 16.7 H: 66.7 temperature 16.7

verbleibende Internals:

ALARM ATTR BasicFeePerMonth BTN CHANGETIME Cmd CONTENT corr1 corr2 corr3 corr4 CostPerUnit currentlogfile DELTAFACTOR DELTAUNIT DeviceName DEVNR DIAMETER FACTOR FamilyCode FD FH FHTID FIXNEW FIXRENUMBER GEOMETRY HEIGHT Host HOUSE ID IDX INATTR INPUT INSET INTERVAL INTV_ALARM INTV_CHECK LENGTH LINK LircObj local LOCAL LOCATION logfile MAX MOBILE MODEL NEXT_OPEN NR_CMD_LAST_H NR_EMSG NR_FMSG NR_KMSG NR_RMSG NR_TMSG NTM NUMUNITS OFFSET OLDDEF OW_FAMILY OWFS_ID OW_ID OW_PATH OW_SCALE PARTIAL pipeopentime po PortObj pos PRESENT PREV QUEUE RAINUNIT RA_Timeout RE REGEXP REP RExt ROUTERID SelectObj SENSOR SERIAL SERIALS socket SOCKET STEP TCPDev Timer TRIGGERTIME ttytype Type UNIT UNITS USBDev VERSION VOLATILE WIDTH WINDUNIT XMIT XMIT_TIME

;; und %%

Das Problem ist, dass sowohl

define lampoff at 07:00 set Lamp1 off;; set Lamp2 off

als auch spaeter (um 07:00)

set Lamp1 off; set Lamp2 off

vom gleichen AnalyzeCommandChain verarbeitet werden.

Diese erkennt an dem ;;, dass die erste Zeile nicht zu trennen ist, die zweite aber schon. In der ersten Zeile wird dann auch ;; nach ; gewandelt, und intern speichert das "at" nur noch "set Lamp1 off; set Lamp2 off". Bevor AnalyzeCommand den Befehl ausfuehrt, muessen perl- und shellskripte wieder ein

bekommen, um nicht von AnalyzeCommand an falscher Stelle zersaegt zu werden.

Die "richtige" Loesung waere sowas wie

define lampoff at 07:00 [ set Lamp1 off; set Lamp2 off ]

erfordert aber einen Parser, der den passenden Klammer-zu findet, und das ist aufwendig.

Uns gefaellt @, %, %EVTPART1, usw. immer weniger, wir finden "magische" Variablen wie $DEVICE, $EVENT, $EVTPART1, usw. logischer - sie wuerden keinen Stress mit @@/%% verursachen. Wir wissen nicht, wie man einen schmerzlosen Uebergang durchfuehrt, insb. mit den vielen fhemwiki-Beispielen.