DevelopmentOpenIssues: Unterschied zwischen den Versionen
KKeine Bearbeitungszusammenfassung |
|||
| Zeile 15: | Zeile 15: | ||
</dt></dl> | </dt></dl> | ||
Beispiele: EMEM, M232. | Beispiele: EMEM, M232. | ||
Denkbar auch zur Identifikation von toten Geräten (USF1000 | 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). | ||
<dl><dt>Multithreading/Parallelisierung | <dl><dt>Multithreading/Parallelisierung | ||
| Zeile 52: | Zeile 52: | ||
Module: CUL_WS,KS300,CUL_EM | Module: CUL_WS,KS300,CUL_EM | ||
<dl><dt> contrib/dblog/93_DBLog ins FHEM-Verzeichnis | <dl><dt> contrib/dblog/93_DBLog ins FHEM-Verzeichnis aufrücken lassen | ||
</dt></dl> | </dt></dl> | ||
Kann benutzt werden, um Events in Datenbanken zu loggen. | Kann benutzt werden, um Events in Datenbanken zu loggen. | ||
| Zeile 63: | Zeile 63: | ||
<dl><dt>Logs und Zeitreihen | <dl><dt>Logs und Zeitreihen | ||
</dt></dl> | </dt></dl> | ||
Derzeit | Derzeit erfüllen Logs u.a. zwei grundverschiedene Aufgaben: | ||
* der Benutzer kann sehen, was zu einem bestimmten Zeitpunkt passiert ist | * der Benutzer kann sehen, was zu einem bestimmten Zeitpunkt passiert ist | ||
* ein Frontend kann daraus eine Zeitreihe ableiten | * ein Frontend kann daraus eine Zeitreihe ableiten für eine Grafik | ||
Es sollte | 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. = | = Martins Liste der Readings, Internals, etc. = | ||
Beispiele: | |||
local, LOCAL | local, LOCAL | ||
po, PortObj | po, PortObj | ||
| Zeile 77: | Zeile 77: | ||
Type, TYPE | Type, TYPE | ||
weitere teils unklare | weitere teils unklare Bezeichnungen, die evtl. harmonisiert werden könnten: | ||
DELTAUNIT, NUMUNITS, RAINUNIT, UNIT, UNITS, WINDUNIT | DELTAUNIT, NUMUNITS, RAINUNIT, UNIT, UNITS, WINDUNIT | ||
CODE, FamilyCode, HOUSE | CODE, FamilyCode, HOUSE | ||
| Zeile 84: | Zeile 84: | ||
NR, DEVNR | NR, DEVNR | ||
dann sind da die | dann sind da die Standardfunktionen bei Initialize, die einfach mal | ||
dokumentiert werden müssten: | dokumentiert werden müssten: | ||
AttrFn | AttrFn | ||
| Zeile 104: | Zeile 104: | ||
WriteFn | WriteFn | ||
einer weiteren | einer weiteren Betrachtung bedarf der Trigger für notify's: | ||
CHANGED | CHANGED | ||
sowie der eigentlichen | sowie der eigentlichen | ||
READINGS | READINGS | ||
die aber in einem anderen Kontext behandelt werden sollten. | |||
einige feste | einige feste Parameter können vorab schonmal gefiltert werden: | ||
DEF | DEF | ||
IODev | IODev | ||
| Zeile 130: | Zeile 130: | ||
bei X10 fiel auf, das in den Internals | bei X10 fiel auf, das in den Internals | ||
MODEL | MODEL | ||
gesetzt wird aber explizit nochmal | gesetzt wird, aber explizit nochmal | ||
model | model | ||
in den Attributes vorkommen. | in den Attributes vorkommen. | ||
bei CUL_WS fiel auf, das die STATE summary sowohl in den Internals als auch in | bei CUL_WS fiel auf, das die STATE summary sowohl in den Internals als auch in | ||
den Readings auftaucht, obwohl in den Readings einzelne | den Readings auftaucht, obwohl in den Readings einzelne Werte vorhanden sind: | ||
Internals: | Internals: | ||
STATE T: 16.7 H: 66.7 | STATE T: 16.7 H: 66.7 | ||
| Zeile 259: | Zeile 259: | ||
aber schon. In der ersten Zeile wird dann auch ;; nach ; gewandelt, und intern | 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 | speichert das "at" nur noch "set Lamp1 off; set Lamp2 off". Bevor | ||
AnalyzeCommand den Befehl | AnalyzeCommand den Befehl ausführt, muessen perl- und shellskripte wieder ein | ||
<dl><dt><dl><dt> bekommen, um nicht von AnalyzeCommand an falscher Stelle zersaegt zu werden. | <dl><dt><dl><dt> bekommen, um nicht von AnalyzeCommand an falscher Stelle zersaegt zu werden. | ||
</dt></dl> | </dt></dl> | ||
</dd></dl> | </dd></dl> | ||
Die "richtige" Loesung | Die "richtige" Loesung wäre sowas wie | ||
<nowiki>define lampoff at 07:00 [ set Lamp1 off; set Lamp2 off ]</nowiki> | <nowiki>define lampoff at 07:00 [ set Lamp1 off; set Lamp2 off ]</nowiki> | ||
| Zeile 270: | Zeile 270: | ||
aufwendig. | aufwendig. | ||
Uns | Uns gefällt @, %, %EVTPART1, usw. immer weniger, wir | ||
finden "magische" Variablen wie $DEVICE, $EVENT, $EVTPART1, usw. | finden "magische" Variablen wie $DEVICE, $EVENT, $EVTPART1, usw. | ||
logischer - sie wuerden keinen Stress mit @@/%% verursachen. Wir wissen nicht, wie man einen schmerzlosen | logischer - sie wuerden keinen Stress mit @@/%% verursachen. Wir wissen nicht, wie man einen schmerzlosen | ||
Übergang durchführt, insb. mit den vielen fhemwiki-Beispielen. | |||
[[Kategorie:Development]] | [[Kategorie:Development]] | ||
Version vom 12. August 2014, 21:26 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 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 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 ausführt, muessen perl- und shellskripte wieder ein
- bekommen, um nicht von AnalyzeCommand an falscher Stelle zersaegt zu werden.
Die "richtige" Loesung wäre 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 gefällt @, %, %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 Übergang durchführt, insb. mit den vielen fhemwiki-Beispielen.