DevelopmentOpenIssues: Unterschied zwischen den Versionen

Aus FHEMWiki
 
Zeile 266: Zeile 266:
Übergang durchführt, insb. mit den vielen fhemwiki-Beispielen.
Übergang durchführt, insb. mit den vielen fhemwiki-Beispielen.


[[Kategorie:Development]]
[[Kategorie:Development (Archive)]]

Aktuelle Version vom 19. Oktober 2016, 13:13 Uhr

Open Issues

Vor Entwicklungsbeginn von fhem 5.x zu klären

Informationsumfang von xmllist

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

xmllist hat auch weitere Daten:

  • die Liste aller möglichen set Werte
  • die Liste aller möglichen 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 muss 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 aufrücken lassen

Kann benutzt werden, um Events in Datenbanken zu loggen.

Todos:

  • FileLog-artigen Getter implementieren
  • Komplettdump
  • Auflistung der gespeicherten Daten
Logs und Zeitreihen

Derzeit erfüllen Logs u.a. zwei grundverschiedene Aufgaben:

  • der Benutzer kann sehen, was zu einem bestimmten Zeitpunkt passiert ist
  • ein Frontend kann daraus eine Zeitreihe ableiten für eine Grafik

Es sollte geklärt werden, wie mit den daraus entstehenden Anforderungen an die Logs (möglichst gut menschenlesbar vs. möglichst gut maschinenverarbeitbar) optimal erfüllt werden können.

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 die aber in einem anderen Kontext 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 noch einmal 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 später (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 ausführt, müssen perl- und shellskripte wieder ein ?? bekommen, um nicht von AnalyzeCommand an falscher Stelle zersägt zu werden.

Die "richtige" Lösung wäre so etwas 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 gefällt @, %, %EVTPART1, usw. immer weniger, wir finden "magische" Variablen wie $DEVICE, $EVENT, $EVTPART1, usw. logischer - sie würden keinen Stress mit @@/%% verursachen. Wir wissen nicht, wie man einen schmerzlosen Übergang durchführt, insb. mit den vielen fhemwiki-Beispielen.