ich erweitere gerade mein LightScene modul um eine html ansicht in der die zustände aller beteiligeten devices in jeder szene dargestellt und geändert werden können: Link (http://forum.fhem.de/index.php?topic=11485.msg85437#msg85437)
zur zeit habe ich dazu einiges an logik/funktionalität aus FW_dev2image dupliziert weil ich das icon nicht für den aktuellen sondern für einen bestimmten state brauche. wäre es eine option FW_dev2image mit einem optionalen zweiten parameter state auszustatten und diesen an stelle von $d->{STATE} zu verwenden sobald er gesetzt ist?
das würde auch noch das problem lösen das ich an der stelle an der mein html code erzeugt wird nicht rausfinden kann in welchem raum ich gerade bin. das geht nur für detailFN und summaryFN aber nicht im htmlcode für einen weblink.
wenn die erweiterung von FW_dev2image keine options ist wäre ein FW_currentRoom() das $FW_room zurück liefert möglich? oder eine andere methode bei der man im gleichen raum bleibt. floorplan scheint 'room=' mit leerem raum zu verwenden?
gruss
andre
Ich habe FW_dev2image() wie gewuenscht erweitert.
Wir koennen %FW_room auch "globalisieren", aber man kommt an alle Web-Parameter auch ueber %FW_webArgs
danke für die FW_dev2image erweiterung. könnte man das noch auf die summaryFn ausdehnen? also auch hier state als paramtere um das aussehen für einen bestimmten state zu bekommen ?
%FW_webArgs reicht mir völlig.
> könnte man das noch auf die summaryFn ausdehnen?
Sorry, aber das ist mir zu abgehoben :)
Lieber einfacher, und ich verstehe noch in 2 Monaten, wozu es gut ist.
nicht wirklich abgehoben sondern nötig um das richtige icon zu bekommen wenn FW_dev2image() das icon aus der summaryFn verwendet. sonst ist es ja unabhängig von state in diesem fall immer das aktuelle.
FW_dev2image ruft summaryFn nie auf. FW_devState ruft summaryFn auf, genauso wie FW_dev2image, d.h. das optionale Argument muesste hier eingefuehrt werden, und dann zusaetzlich in summaryFn, und evtl. noch anderswo, wo ich es noch nicht blicke.
Ich bin (z.Zt noch :) der Ansicht, dass man das gleiche Ergebnis deutlich einfacher erreichen kann, wenn man $hash->{STATE} temporaer auf das Gewuenschte setzt. Ist zwar etwas unsauber, allerdings bleiben damit die Schnittstellen einfach.
du hast recht mit der aufrufreihenfolge.
STATE umzusetzen geht natürlich. ich weiß aber nicht ob das auf dauer wirklich transparenter und besser zu merken und zu warten ist...
da ich gerade eine version hab die (wenn auch mit einem workaround geht) und ich genug andere baustellen habe fehlt mr erst mal der antrieb dich zu überreden :)