DevelopmentOpenIssues - Versionsgeschichte

Krikan: Kategorie:Development (Archive) zugeordnet

2016-10-19T12:13:08Z

Kategorie:Development (Archive) zugeordnet

← Nächstältere Version		Version vom 19. Oktober 2016, 14:13 Uhr
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)]]

Generix: /* ;; und %% */

2014-11-06T13:52:07Z

;; und %%

← Nächstältere Version		Version vom 6. November 2014, 15:52 Uhr
Zeile 253:		Zeile 253:
	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 ausführt, müssen perl- und shellskripte wieder ein		AnalyzeCommand den Befehl ausführt, müssen perl- und shellskripte wieder ein ?? bekommen, um nicht von AnalyzeCommand an falscher Stelle zersägt zu werden.

	~~<dl><dt><dl><dt> bekommen, um nicht von AnalyzeCommand an falscher Stelle zersägt zu werden.~~
	~~</dt></dl>~~
	~~</dd></dl>~~
	Die "richtige" Lösung wäre so etwas wie		Die "richtige" Lösung wäre so etwas wie

Generix: /* Erweiterungen/Verbesserungen */

2014-11-06T13:51:15Z

Erweiterungen/Verbesserungen

← Nächstältere Version		Version vom 6. November 2014, 15:51 Uhr
Zeile 42:		Zeile 42:

	== Erweiterungen/Verbesserungen ==		== Erweiterungen/Verbesserungen ==
	~~<dl><dt>~~ Auslagerung der Funktionen für die Bildung von Mittelwerten über Zeitintervalle in ein eigenes Modul		;Auslagerung der Funktionen für die Bildung von Mittelwerten über Zeitintervalle in ein eigenes Modul
	~~</dt></dl>~~
	z.B. Niederschlag pro Tag, Woche, Monat		z.B. Niederschlag pro Tag, Woche, Monat
	Module: CUL_WS,KS300,CUL_EM		Module: CUL_WS,KS300,CUL_EM

	~~<dl><dt>~~ contrib/dblog/93_DBLog ins FHEM-Verzeichnis aufrücken lassen		;contrib/dblog/93_DBLog ins FHEM-Verzeichnis aufrücken lassen
	~~</dt></dl>~~
	Kann benutzt werden, um Events in Datenbanken zu loggen.		Kann benutzt werden, um Events in Datenbanken zu loggen.

Zeile 56:		Zeile 55:
	* Komplettdump		* Komplettdump
	* Auflistung der gespeicherten Daten		* Auflistung der gespeicherten Daten
	~~<dl><dt>~~Logs und Zeitreihen		;Logs und Zeitreihen
	~~</dt></dl>~~
	Derzeit erfüllen Logs u.a. zwei grundverschiedene Aufgaben:		Derzeit erfüllen Logs u.a. zwei grundverschiedene Aufgaben:

Generix: /* Vor Entwicklungsbeginn von fhem 5.x zu klären */

2014-11-06T13:50:28Z

Vor Entwicklungsbeginn von fhem 5.x zu klären

← Nächstältere Version		Version vom 6. November 2014, 15:50 Uhr
Zeile 1:		Zeile 1:
	= Open Issues =		= Open Issues =
	== Vor Entwicklungsbeginn von fhem 5.x zu klären ==		== Vor Entwicklungsbeginn von fhem 5.x zu klären ==
	~~<dl><dt>~~Informationsumfang von xmllist		;Informationsumfang von xmllist
	~~</dt></dl>~~
	xmllist muss alle Werte mitnehmen, da sonst diese nie angezeigt werden.		xmllist muss alle Werte mitnehmen, da sonst diese nie angezeigt werden.

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

	~~<dl><dt>~~Aufbau einer Polling-Infrastruktur für Geräte, die nicht aktiv den Zustand melden		;Aufbau einer Polling-Infrastruktur für Geräte, die nicht aktiv den Zustand melden
	~~</dt></dl>~~
	Beispiele: EMEM, M232.		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).		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		;Multithreading/Parallelisierung
	~~</dt></dl>~~
	Nähe zur Polling-Infrastruktur		Nähe zur Polling-Infrastruktur

	~~<dl><dt>~~Dokumentation		;Dokumentation
	~~</dt></dl>~~
	Standardfunktionen:		Standardfunktionen:
	AttrFn		AttrFn
Zeile 42:		Zeile 38:
	WriteFn		WriteFn

	~~<dl><dt>~~Erstellung eines Template-Moduls		;Erstellung eines Template-Moduls
	~~</dt></dl>~~
	Kommentierte Vorlage nn_Modul.pm fuer fhem 5.x.		Kommentierte Vorlage nn_Modul.pm fuer fhem 5.x.

Kamischi am 12. August 2014 um 21:16 Uhr

2014-08-12T21:16:06Z

← Nächstältere Version		Version vom 12. August 2014, 23:16 Uhr
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 noch einmal
	model		model
	in den Attributes vorkommen.		in den Attributes vorkommen.
Zeile 251:		Zeile 251:

	<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>
	als auch ~~spaeter~~ (um 07:00)		als auch später (um 07:00)

	<nowiki>set Lamp1 off; set Lamp2 off</nowiki>		<nowiki>set Lamp1 off; set Lamp2 off</nowiki>
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 ausführt, ~~muessen~~ perl- und shellskripte wieder ein		AnalyzeCommand den Befehl ausführt, müssen 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 zersägt zu werden.
	</dt></dl>		</dt></dl>
	</dd></dl>		</dd></dl>
	Die "richtige" ~~Loesung~~ wäre ~~sowas~~ wie		Die "richtige" Lösung wäre so etwas 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 272:		Zeile 272:
	Uns gefällt @, %, %EVTPART1, usw. immer weniger, wir		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 würden keinen Stress mit @@/%% verursachen. Wir wissen nicht, wie man einen schmerzlosen
	Übergang durchführt, insb. mit den vielen fhemwiki-Beispielen.		Übergang durchführt, insb. mit den vielen fhemwiki-Beispielen.

	[[Kategorie:Development]]		[[Kategorie:Development]]

Kamischi am 12. August 2014 um 19:26 Uhr

2014-08-12T19:26:49Z

← Nächstältere Version		Version vom 12. August 2014, 21:26 Uhr
Zeile 1:		Zeile 1:
	= Open Issues =		= Open Issues =
	== Vor Entwicklungsbeginn von fhem 5.x zu ~~klaeren~~ ==		== Vor Entwicklungsbeginn von fhem 5.x zu klären ==
	<dl><dt>Informationsumfang von xmllist		<dl><dt>Informationsumfang von xmllist
	</dt></dl>		</dt></dl>
Zeile 7:		Zeile 7:
	xmllist hat auch weitere Daten:		xmllist hat auch weitere Daten:

	* die Liste aller ~~moeglichen~~ set Werte		* die Liste aller möglichen set Werte
	* die Liste aller ~~moeglichen~~ Attribute		* die Liste aller möglichen Attribute

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

Kamischi am 12. August 2014 um 19:26 Uhr

2014-08-12T19:26:11Z

← Nächstältere Version		Version vom 12. August 2014, 21:26 Uhr
Zeile 15:		Zeile 15:
	</dt></dl>		</dt></dl>
	Beispiele: EMEM, M232.		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).		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 ~~aufruecken~~ lassen		<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 ~~erfuellen~~ Logs u.a. zwei grundverschiedene Aufgaben:		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 ~~fuer~~ eine Grafik		* ein Frontend kann daraus eine Zeitreihe ableiten für 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~~.		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~~:		Beispiele:
	local, LOCAL		local, LOCAL
	po, PortObj		po, PortObj
Zeile 77:		Zeile 77:
	Type, TYPE		Type, TYPE

	weitere teils unklare ~~bezeichnungen~~, die evtl. harmonisiert werden könnten:		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 ~~standardfunktionen~~ bei Initialize, die einfach mal		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 ~~betrachtung~~ bedarf der ~~trigger~~ für notify's:		einer weiteren Betrachtung bedarf der Trigger für notify's:
	CHANGED		CHANGED
	sowie der eigentlichen		sowie der eigentlichen
	READINGS		READINGS
	~~welche~~ aber in einem anderen ~~context~~ behandelt werden sollten.		die aber in einem anderen Kontext behandelt werden sollten.

	einige feste ~~parameter~~ können vorab schonmal gefiltert werden:		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 ~~werte~~ vorhanden sind:		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 ~~ausfuehrt~~, muessen perl- und shellskripte wieder ein		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 ~~waere~~ sowas wie		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 ~~gefaellt~~ @, %, %EVTPART1, usw. immer weniger, wir		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
	~~Uebergang durchfuehrt~~, insb. mit den vielen fhemwiki-Beispielen.		Übergang durchführt, insb. mit den vielen fhemwiki-Beispielen.

	[[Kategorie:Development]]		[[Kategorie:Development]]

Markusbloch: /* ;; und %% */

2013-05-13T19:23:16Z

;; und %%

← Nächstältere Version		Version vom 13. Mai 2013, 21:23 Uhr
Zeile 274:		Zeile 274:
	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
	Uebergang durchfuehrt, insb. mit den vielen fhemwiki-Beispielen.		Uebergang durchfuehrt, insb. mit den vielen fhemwiki-Beispielen.

			[[Kategorie:Development]]

Generix: Die Seite wurde neu angelegt: „= Open Issues = == Vor Entwicklungsbeginn von fhem 5.x zu klaeren ==
Informationsumfang von xmllist
xmllist muss alle Werte mitnehmen, da so…“

2013-05-10T20:41:16Z

Die Seite wurde neu angelegt: „= Open Issues = == Vor Entwicklungsbeginn von fhem 5.x zu klaeren == <dl><dt>Informationsumfang von xmllist </dt></dl> xmllist muss alle Werte mitnehmen, da so…“

Neue Seite

= Open Issues =
== Vor Entwicklungsbeginn von fhem 5.x zu klaeren ==
<dl><dt>Informationsumfang von xmllist
</dt></dl>
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.

<dl><dt>Aufbau einer Polling-Infrastruktur für Geräte, die nicht aktiv den Zustand melden
</dt></dl>
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).

<dl><dt>Multithreading/Parallelisierung
</dt></dl>
Nähe zur Polling-Infrastruktur

<dl><dt>Dokumentation
</dt></dl>
Standardfunktionen:
AttrFn
AttrList
Clients
DefFn
GetFn
ListFn
Match
MatchList
NotifyFn
ParseFn
ReadFn
ReadyFn
SetFn
ShutdownFn
StateFn
UndefFn
WriteFn

<dl><dt>Erstellung eines Template-Moduls
</dt></dl>
Kommentierte Vorlage nn_Modul.pm fuer fhem 5.x.

== Erweiterungen/Verbesserungen ==
<dl><dt> Auslagerung der Funktionen für die Bildung von Mittelwerten über Zeitintervalle in ein eigenes Modul
</dt></dl>
z.B. Niederschlag pro Tag, Woche, Monat
Module: CUL_WS,KS300,CUL_EM

<dl><dt> contrib/dblog/93_DBLog ins FHEM-Verzeichnis aufruecken lassen
</dt></dl>
Kann benutzt werden, um Events in Datenbanken zu loggen.

Todos:

* FileLog-artigen Getter implementieren
* Komplettdump
* Auflistung der gespeicherten Daten
<dl><dt>Logs und Zeitreihen
</dt></dl>
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

<nowiki>define lampoff at 07:00 set Lamp1 off;; set Lamp2 off</nowiki>
als auch spaeter (um 07:00)

<nowiki>set Lamp1 off; set Lamp2 off</nowiki>
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

<dl><dt><dl><dt> bekommen, um nicht von AnalyzeCommand an falscher Stelle zersaegt zu werden.
</dt></dl>
</dd></dl>
Die "richtige" Loesung waere sowas wie

<nowiki>define lampoff at 07:00 [ set Lamp1 off; set Lamp2 off ]</nowiki>
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.

DevelopmentOpenIssues - Versionsgeschichte

Krikan: Kategorie:Development (Archive) zugeordnet

Generix: /* ;; und %% */

Generix: /* Erweiterungen/Verbesserungen */

Generix: /* Vor Entwicklungsbeginn von fhem 5.x zu klären */

Kamischi am 12. August 2014 um 21:16 Uhr

Kamischi am 12. August 2014 um 19:26 Uhr

Kamischi am 12. August 2014 um 19:26 Uhr

Markusbloch: /* ;; und %% */

Generix: Die Seite wurde neu angelegt: „= Open Issues = == Vor Entwicklungsbeginn von fhem 5.x zu klaeren == Informationsumfang von xmllist xmllist muss alle Werte mitnehmen, da so…“

Generix: Die Seite wurde neu angelegt: „= Open Issues = == Vor Entwicklungsbeginn von fhem 5.x zu klaeren ==
Informationsumfang von xmllist
xmllist muss alle Werte mitnehmen, da so…“