hallo martin,
ich habe gerade das problem das alle dimmer beim 'set on' oder 'set off' danach im state set_xxx stehen bleiben. und das nur der virtLevel richtig auf on oder off gesetzt wird. bei 'set 40' oder jedem anderen level geht es aber.
mit einem 'attr stateFormat virtLevel' passt zwar alles in der anzeige aber in einer structure geht natürlich ohne on und off nichts mehr richtig.
ist das so beabstichtigt ?
gruss
andre
Hallo Andre,
hoert sich nicht korrekt an....
liegt evtl an der rampe, die bei 'set 40' gesetzt wird und bei on nicht...
Welches Device hast du?
Kannst du auch ein list device schicken? Und aller seiner channels?
und ein messagelog auch noch...
werde versuchen es zu reproduzieren.
Gruss
Martin
hallo martin,
das eine ist ein HM-LC-Dim1PWM-CV mit allen virtuellen channels definiert, das andere ein HM-LC-Dim1TPBU-FM ohne channels (nur das device definiert).
es passiert auch nur bei den beiden dimmern. ein HM-LC-Sw1PBU-FM funktioniert noch ganz normal.
mehr heute abend.
gruss
andre
hab das Problem - verbesserung kommt heute
klasse.
wollte gerade die logs produzieren.
gruss
andre
geht!
danke
andre
hallo martin,
leider habe ich eben bemerkt das da geht sich nur auf den HM-LC-Dim1TPBU-FM bezieht.
beim HM-LC-Dim1PWM-CV mit den virtuellen kanälen gibt es noch ein paar probleme oder ungereimtheiten:
- das device selber bleibt im state immer noch auf set_xxx hängen. der virtLevel ist aber korrekt.
- die einzelnen kanäle springen im state scheinbar alle gleichzeitig auf den letzten dim level wenn am device die helligkeit gesetzt wird.
kann es sein das hier state und virtLevel vertauscht sind ?
- die einzelnen kanäle haben kein pct reading.
was genau brauchst du in welcher reihenfolge an logs um das verhalten nachzuvollziehen?
vielleicht reden wir auch was die darstellung der kanäle angeht aneinander vorbei. meine idee wie das ganze funktionieren könnte:
- ein set im device geht auf den ersten channel (ich denke das ist zur zeit auch so)
- ein set in einem channel geht nur auf den channel
- jeder channel hat als state den state den der channel hat.
- das device hat als state den kombinierten status
- den virtLevel braucht es dann entweder garnicht oder nur beim device
- die devices sollten auch ein pct reading haben. damit der slider in der detail ansicht vorinitialisiert werden kann
damit würde man überall wo das device verwendet wird den tatsächlichen kombinierten status sehen und da wo die details interessieren könnte man sich in einem raum die channel hin konfigurieren und die übersicht sehen.
gruss
andre
Hallo Andre
ich brauche die "üblichen logs" der messages.
Moeglich, dass der PWM einen anderen Status schickt... werde ich durchsehen
der State ist nicht so, wie du sagst.
State ist der physikalische Zustand des Channel - und bei allen virtuellen channels einer Gruppe gleich.
Der Level des Channel ist im "virtLevel" zu sehen.
Gründe:
- LichtLevel kann nicht in device da es immer nur ein Device gibt, aber manchmal mehrere dimmer (Phy-channels) in einem Device. Das könnte ich dann nicht mehr darstellen.
- der Physikalische Zustand muss immer in State da sonst einiges in FHEM nicht funktioniert.
=> somit kommt der Licht Level nicht in das device (Ausnahme, Channel 1 nicht definiert)
soweit die Fakten - und dann noch meine Meinung:
man sollte den Physikalischen Zustand immer sehen, egal welchen virtuellen channel man bearbeitet. Der Physikalische ist einfach der wichtigste, egal wie er zustande kommt.
Soweit schlüssig?
Gruss
Martin
guten morgen,
das was ich zum state und zum verhalten geschrieben habe war das was ich mir wünschen würde :)
aber wenn es mit dem virtLevel wirklich funktioniert kann ich es ja einfach mit stateFormat mappen. dann passt schon alles.
bitte schau dir noch mal das mit dem pct reading in den channels an.
logs kommen heute abend.
gruss
andre
Hi Andre,
ja, ich weiss noch, was du gewuenscht hast...
das Problem ist ein 2 channel device (z.B.HM-LC-Dim2L). Da hast du
dev
chn1 (physical1)
chn2 (physical2)
chn3 (physical1)
chn4 (physical1)
chn5 (physical2)
chn6 (physical2)
und dann klappt es mit dem deivce nicht mehr, da wir nur eines haben. Einzige Moeglichkeit ist, fuer chan1 und 2 als physical zu nehmen und hier einen virtual zu addieren. Das ist aber dann noch komplizierter fuer den simple-user der das eigentlich sehr selten braucht.
Es sind noch bugs drin bei den 'relativen' kommandos up/down und toggle. Diese beziehen sich noch auf den physikalischen Zustand. Wird demnaechst behoben.
Das mit dem pct werde ich mir ansehen...
Gruss
Martin
du hast natürlich recht mit den geräten mit mehr als einem physikalischen device.
das gleiche gilt ja für meinen HM-LC-SW4-DR auch. für mich sind das metal immer zwei oder vier devices weil sie ja eigentlich aus endanwender sicht nichts miteinander zu tun haben ausser im gleichen kasten zu sitzen.
und mit dem stateFormat kann ich es ja so hinbiegen wie ich es mag.
gruss
andre
das mit up/down habe ich im Griff (hoffe ich) - und auch die Timing-Werte.
Wie man immer unruhe schaffen kann ist, wenn man mit langen Rampen arbeitet (egal in welchen Kommando) und dann relative Einstellungen (up/down) vornimmt. Immer wenn der Aktor einen neuen Status meldet wird dieser als gültig genommen und von dem aus weitergerechnet.
Was ich nicht verstehe ist dein pct Problem. Bei mir haben alle dimmer das "pct" kommando.
Du solltest beachten, dass alle Kanaele keinen subtype haben - bis auf das device.
Wenn du den subtype setzen musst, dann auf "dimmer" - fhem setzt den nur bei devices.
was kommt, wenn du set <name> ? schickst?
Gruss
Martin
hallo martin,
der pct slider ist da aber die channels haben kein pct reading. d.h. der slider steht immer bei 0 und wird nicht auf den aktuellen wert initialisiert.
ups... ich sehe gerade das ist bei keinem hm device der fall und ich hab es gerade mit meinen hue lampen durcheinander geschmissen. asche auf mein haupt.
für die logs muß ich dich auch auf morgen vertrösten. mir ist noch was ganz anderes dazwischen gekommen.
gruss
andre
hallo martin,
immer noch keine logs... aber ich gelobe besserung.
dafür ein neues problem seit heute. wenn ich auf einen der virtuellen channel ein set LED2_2 50 420 mache wird das licht kurz heller aber dann geht der channel sofort wieder aus.
ich habe hier noch einen zweiten HM-LC-Dim1PWM-CV der noch nicht in betrieb ist. wenn du magst kann ich ihn dir einfach ausleihen. dann kannst du selber mit den virtuellen channel spielen.
gruss
andre
Hi Andre,
nein, einen dimmer habe ich.
pct und up/down habe ich zusammengefasst. Und die Berechnung korrigiert. (ein dauer-ein waren eigentlich nur 6.7mio sec, ganz schoen lang, aber nicht dauern...
Ist dein Problem nur bei virtuellen channels? Also bei allen 3en oder nur den letzten beiden? Die Verknuepfung hast du ggf. eingestellt.
dein
LED2_2 50 420
soll in 2.5 sec auf 50% regeln. Dann 420 sec an bleiben und dann aus gehen, soweit sind wir uns einig.
getestet hast du mit der 2951 von gestern Abend? Vorher war ein bug drin.
Gruss
Martin
hallo martin,
die version war die von gestern mittag. ich hatte nicht gesehen das es noch eine am abend gab. die habe ich eben kurz von hand probiert und es scheint zu gehen. genau kann ich es dir erst heute abend sagen wenn es dunkel genug für den bewegsungsmelder ist.
dann bekommst du endlich auch die logs wegen dem eigentlichen thema hier. das mit den set_xx im device ist immer noch so.
danke und gruss
andre
hallo martin,
mit der aktuellen version bleibt das device nicht mehr bei set_xx stehen sondern set_pct xx. ein set on oder ein set off spiegelt sich im device gar nicht mehr wieder.
anbei endlich die versprochenen log ausgaben: attr global verbose 1
attr global mseclog 1
attr cul2 loglevel 1
set LED2 on
set LED2 off
set LED2 10
set LED2 off
2013.03.25 15:47:04.800 1: SW: As0ECAA011F100001B4FEF0201C80000
2013.03.25 15:47:04.952 1: cul2: A0FCA80021B4FEFF100000101C8003BA4 -63
2013.03.25 15:47:07.959 1: SW: As0BCBA001F100001B4FEF010E
2013.03.25 15:47:08.110 1: cul2: A0FCBA4101B4FEFF100000601C8003BC8 -63.5
2013.03.25 15:47:08.204 1: SW: As0ACB8002F100001B4FEF00
2013.03.25 15:47:11.449 1: SW: As0ECCA011F100001B4FEF0201000000
2013.03.25 15:47:11.600 1: cul2: A0FCC80021B4FEFF10000010100003BEC -63.5
2013.03.25 15:47:14.607 1: SW: As0BCDA001F100001B4FEF010E
2013.03.25 15:47:14.759 1: cul2: A0FCDA4101B4FEFF10000060100003B00 -63.5
2013.03.25 15:47:14.854 1: SW: As0ACD8002F100001B4FEF00
2013.03.25 15:47:17.614 1: SW: As10CEA011F100001B4FEF0201140320FFFF
2013.03.25 15:47:17.765 1: cul2: A0FCE80021B4FEFF10000010101103BA4 -63.5
2013.03.25 15:47:20.772 1: SW: As0BCFA001F100001B4FEF010E
2013.03.25 15:47:20.925 1: cul2: A0FCFA4101B4FEFF10000060114003B14 -63
2013.03.25 15:47:21.018 1: SW: As0ACF8002F100001B4FEF00
2013.03.25 15:47:22.771 1: cul2: A0FD0A4101B4FEFF10000060114008014 -63
2013.03.25 15:47:22.869 1: SW: As0AD08002F100001B4FEF00
2013.03.25 15:47:27.321 1: SW: As0ED1A011F100001B4FEF0201000000
2013.03.25 15:47:28.493 1: cul2: A0FD180021B4FEFF10000010100003BB4 -63
2013.03.25 15:47:31.498 1: SW: As0BD2A001F100001B4FEF010E
2013.03.25 15:47:31.651 1: cul2: A0FD2A4101B4FEFF10000060100003B00 -63.5
2013.03.25 15:47:31.744 1: SW: As0AD28002F100001B4FEF00
das hier kommt für die gleichen 4 kommandos im event monitor an:2013-03-25 15:53:04 CUL_HM LED2_1 set_on
2013-03-25 15:53:04 CUL_HM LED2_1 virtLevel: on
2013-03-25 15:53:04 CUL_HM LED2_1 deviceMsg: set_pct 99 (to cul2)
2013-03-25 15:53:04 CUL_HM LED2_1 dim: stop:set_pct 99
2013-03-25 15:53:04 CUL_HM LED2_1 overload: off
2013-03-25 15:53:04 CUL_HM LED2_1 overheat: off
2013-03-25 15:53:04 CUL_HM LED2_1 reduced: off
2013-03-25 15:53:04 CUL_HM LED2_1 set_pct 99
2013-03-25 15:53:05 PRESENCE TV aus
2013-03-25 15:53:07 CUL_HM LED2_1 virtLevel: on
2013-03-25 15:53:07 CUL_HM LED2_1 deviceMsg: on (to cul2)
2013-03-25 15:53:07 CUL_HM LED2_1 dim: stop:on
2013-03-25 15:53:07 CUL_HM LED2_1 overload: off
2013-03-25 15:53:07 CUL_HM LED2_1 overheat: off
2013-03-25 15:53:07 CUL_HM LED2_1 reduced: off
2013-03-25 15:53:07 CUL_HM LED2_1 on
2013-03-25 15:53:07 CUL_HM LED2_2 on
2013-03-25 15:53:07 CUL_HM LED2_3 on
2013-03-25 15:53:08 CUL_WS s300ht_5 T: 21.8 H: 44
2013-03-25 15:53:08 CUL_WS s300ht_5 temperature: 21.8
2013-03-25 15:53:08 CUL_WS s300ht_5 humidity: 44
2013-03-25 15:53:09 CUL_HM LED2_1 set_off
2013-03-25 15:53:09 CUL_HM LED2_1 virtLevel: off
2013-03-25 15:53:09 CUL_HM LED2_1 deviceMsg: set_pct 99 (to cul2)
2013-03-25 15:53:09 CUL_HM LED2_1 dim: stop:set_pct 99
2013-03-25 15:53:09 CUL_HM LED2_1 overload: off
2013-03-25 15:53:09 CUL_HM LED2_1 overheat: off
2013-03-25 15:53:09 CUL_HM LED2_1 reduced: off
2013-03-25 15:53:09 CUL_HM LED2_1 set_pct 99
2013-03-25 15:53:10 Global global DELETED checkFensterEG
2013-03-25 15:53:10 Global global DEFINED checkFensterEG
2013-03-25 15:53:13 CUL_HM LED2_1 virtLevel: off
2013-03-25 15:53:13 CUL_HM LED2_1 deviceMsg: off (to cul2)
2013-03-25 15:53:13 CUL_HM LED2_1 dim: stop:off
2013-03-25 15:53:13 CUL_HM LED2_1 overload: off
2013-03-25 15:53:13 CUL_HM LED2_1 overheat: off
2013-03-25 15:53:13 CUL_HM LED2_1 reduced: off
2013-03-25 15:53:13 CUL_HM LED2_1 off
2013-03-25 15:53:13 CUL_HM LED2_2 off
2013-03-25 15:53:13 CUL_HM LED2_3 off
2013-03-25 15:54:36 CUL_HM LED2 virtLevel: set_10
2013-03-25 15:54:36 CUL_HM LED2 set_pct 10
2013-03-25 15:54:36 CUL_HM LED2_1 virtLevel: 0.5 %
2013-03-25 15:54:36 CUL_HM LED2_1 deviceMsg: set_pct 10 (to cul2)
2013-03-25 15:54:36 CUL_HM LED2_1 dim: up:set_pct 10
2013-03-25 15:54:36 CUL_HM LED2_1 overload: off
2013-03-25 15:54:36 CUL_HM LED2_1 overheat: off
2013-03-25 15:54:36 CUL_HM LED2_1 reduced: off
2013-03-25 15:54:36 CUL_HM LED2_1 set_pct 10
2013-03-25 15:54:39 CUL_HM LED2_1 virtLevel: 10 %
2013-03-25 15:54:39 CUL_HM LED2_1 deviceMsg: 10 % (to cul2)
2013-03-25 15:54:39 CUL_HM LED2_1 dim: stop:10 %
2013-03-25 15:54:39 CUL_HM LED2_1 overload: off
2013-03-25 15:54:39 CUL_HM LED2_1 overheat: off
2013-03-25 15:54:39 CUL_HM LED2_1 reduced: off
2013-03-25 15:54:39 CUL_HM LED2_1 10 %
2013-03-25 15:54:39 CUL_HM LED2_2 10 %
2013-03-25 15:54:39 CUL_HM LED2_3 10 %
2013-03-25 15:54:40 Global global DELETED checkFensterEG
2013-03-25 15:54:40 Global global DEFINED checkFensterEG
2013-03-25 15:54:40 CUL_HM LED2_1 set_off
2013-03-25 15:54:40 CUL_HM LED2_1 virtLevel: off
2013-03-25 15:54:40 CUL_HM LED2_1 deviceMsg: set_pct 10 (to cul2)
2013-03-25 15:54:40 CUL_HM LED2_1 dim: stop:set_pct 10
2013-03-25 15:54:40 CUL_HM LED2_1 overload: off
2013-03-25 15:54:40 CUL_HM LED2_1 overheat: off
2013-03-25 15:54:40 CUL_HM LED2_1 reduced: off
2013-03-25 15:54:40 CUL_HM LED2_1 set_pct 10
2013-03-25 15:54:46 iTunes xx presence: disappeared
2013-03-25 15:54:46 CUL_HM LED2_1 virtLevel: off
2013-03-25 15:54:46 CUL_HM LED2_1 deviceMsg: off (to cul2)
2013-03-25 15:54:46 CUL_HM LED2_1 dim: stop:off
2013-03-25 15:54:46 CUL_HM LED2_1 overload: off
2013-03-25 15:54:46 CUL_HM LED2_1 overheat: off
2013-03-25 15:54:46 CUL_HM LED2_1 reduced: off
2013-03-25 15:54:46 CUL_HM LED2_1 off
2013-03-25 15:54:46 CUL_HM LED2_2 off
2013-03-25 15:54:46 CUL_HM LED2_3 off
was mir auffällt ist das am ende jeweils nur die drei notifys für die drei channel kommen aber keins für das device.
gruss
andre
Hallo Andre,
du hast doch jetzt folgende "entities"
<device>
LED2_1
LED2_2
LED2_3
Da channel "1" sauber definiert ist als LED2_1 hat <device> nicht mehr die Funktion eines Channel. Also wird der Status auch nicht dort abgebildet.
<device> ist nur noch die Protokoll-entity. Es wird der Status des Protokoll angezeigt, wenn den einer anzuzeigen waehre.
Eine solch saubere Trennung haette ich mir von allen gewuenscht (device und channel trennung).
Dass etwas haengen bleibt kann ich nicht erkennen.
Zitat15:54:36 LED2 virtLevel: set_10
15:54:36 LED2 set_pct 10
15:54:36 LED2_1 virtLevel: 0.5 %
15:54:36 LED2_1 dim: up:set_pct 10
15:54:36 LED2_1 set_pct 10
hier das Kommando und die entsprechenden Readings, alles "set_"
kurz danach kommt die bestaetigung vom device:
Zitat15:54:39 LED2_1 virtLevel: 10 %
15:54:39 LED2_1 dim: stop:10 %
15:54:39 LED2_1 10 %
15:54:39 LED2_2 10 %
15:54:39 LED2_3 10 %
alles ohne "set", fuer alle 3 channels.
liegt es am refresh? ist nach refresh alles ok?
Gruss
Martin
hallo martin,
wenn device jetzt keine Funktion mehr hat ist das verhalten natürlich verständlich...
ich kann aber nicht mehr wirklich abbilden was ich gerne möchte:
- eine "entity" die ich überall (room, floorplan, ...) verwenden kann wo es mir nur auf den tatsächlichen status ankommt und mit der ich sehen kann wie hell die lampe gerade wirklich ist.
- pro channel eine entity die ich z.b. in in einen raum details packen kann so das ich bei bedarf sehe welchen status die einzelnen channels haben.
für letzteres wollte ich mir in den channels den state per stateFormat auf den virtLevel mappen. ersteres geht dann aber nicht mehr weil ich den gesamt status komplett verloren habe. ich kann ihn noch nicht mal mehr aus einem channel ins device mappen.
selbst wenn das device die funktion des channels verloren hat ist 'set_pct xx' kein wirklich richtiger status nach dem das kommando fertig abgearbeitet wurde. wenn es nicht mehr der gesamt status sein darf dann wenigstens ein done oder ok oder irgendetwas das zeigt das das kommando abgearbeitet wurde.
gruss
andre
Hallo Andre,
Zitatwenn device jetzt keine Funktion mehr hat ist das verhalten natürlich verständlich...
das device hat IMMER die Funktion "protokol-instanz". Sie wird nur ueberlagert von 'channel_01' falls dieser nicht separat eingerichtet wurde.
Zitateine "entity" die ich überall (room, floorplan, ...) verwenden kann wo es mir nur auf den tatsächlichen status ankommt und mit der ich sehen kann wie hell die lampe gerade wirklich ist.
warum nicht? Der reale Zustand ist als "state" in allen deinen 3 channels zu sehen. Nim doch einfach den ersten channel.
Zitat- pro channel eine entity die ich z.b. in in einen raum details packen kann so das ich bei bedarf sehe welchen status die einzelnen channels haben.
das kannst du in virtLevel sehen. Du willst es aber in "state" haben...
für letzteres wollte ich mir in den channels den state per stateFormat auf den virtLevel mappen. ersteres geht dann aber nicht mehr weil ich den gesamt status komplett verloren habe. ich kann ihn noch nicht mal mehr aus einem channel ins device mappen.Wie schon besprochen muss ich den allgemeinen Fall sehen, der ist der 2-channel dimmer mit 6 virtuellen channels. Da du alles ausschliesslich aus "state" lesen willst wuerde es 8 entites benoetigen, dies zu handeln. Plus das device um symetrisch zu bleiben. Ich muesste also noch 2 dummies bauen. Da bin ich mir aber nicht sicher, dass dies von CUL_HM eingebaut werden soll.
Aber das kannst du auch selbst.
define LichtPhys dummy
define updtLP notify LED2_1 set LichtPhys state {ReadingVal('LED2_1','state','unknown')}
attr LED2_1 stateFormat virtLevel
attr LED2_2 stateFormat virtLevel
attr LED2_3 stateFormat virtLevel
Unterstuetzen kann ich dies indem ich den physikalischen state noch in einem weiteren Reading abbilde, also ein "physLevel". Das beugt eventuellen Probleme vor, wenn du mit stateFromat arbeiten willst. Es stellt sich dann nicht mehr die frage, was fhem zuerst ersetzt.
define updtLP notify LED2_1:physLevel.* set LichtPhys state {ReadingVal('LED2_1',physLevel,'unknown')}
Zitatselbst wenn das device die Funktion des channels verloren hat ist 'set_pct xx' kein wirklich richtiger status nach dem das kommando fertig abgearbeitet wurde.
ok, hat hier nichts mehr verloren, muss ich korrigieren.
Zitatwenn es nicht mehr der gesamt status sein darf dann wenigstens ein done oder ok oder irgendetwas das zeigt das das kommando abgearbeitet wurde.
korrekt. Ich denke der protState sollte hier abgebildet werden.
Passt dies dann so? Verbesserungen oder bessere Konzepte?
Gruss,
Martin
nachtrag zum device-state:
der ist gesetzt worden, weil du ein 'set LED2 10' gemacht hast, also auf das Device - korrekt?
Der device-state wird in dieser konfig eigentlich nicht mit channel-daten beschrieben, ausser du nutzt channel kommandos
hm... das wirft dann neue Fragen auf.
- soll ich die channel kommandos fuer ein device sperren, wenn 'channel 01' existiert?
=> koennte bei manchen Usern unmut erzeugen - hauptsaechlich wohl bei TC usern.
++> ich denke, ich werden es sperren (ist einiges an umbau), ausser fuer die sensiblen TC user. Die haben zu viele Konstrukte am laufen.
- reicht es, wenn 'state' nach dem kommand-senden ueberschrieben wird?
Gedanken? Martin
hallo martin,
ich denke mit dem physLevel kann ich genau das tun was ich moechte. von meiner seite klingt das gut.
dummys sind mir immer irgendwie suspekt weil sie ganz oft den beigeschmack eines workaround haben.
ich weiss es ist immer das problem mit den zwei channel dimmern. es ist aber doch nicht das gleiche weil diese kanäle sich auf zwei für den anwender völlig getrennte dinge beziehen. zwei gluehbirnen eben. und sogar hier könnte man sich den physState aus allen devices zusamenkopieren und ein icon mit beiden states nebeneinander anzeigen.
was waere wenn man für den summenkanal auch eine entity erzeugen könnte? einen virtuellen virtuellen channel sozusagen. wäre das nicht am saubersten? dann wäre es überhaupt nicht nötig sich den state zu kopieren. die zwei kanal dimmer hätten sofort beim anlegen das device und die zwei channels mit subtype dimmer zum schalten und um den state anzuzeigen. die virtuellen kanäle würden dann dazukommen. vielleicht mit subtype virtualDimmer. das waere zwar jeweils noch eine entity mehr ( 4 bzw. 8 pro device) aber dann gingen auch notifys eindeutig auf den summenkanal oder und/oderdie virtuellen kanäle.
danke und gruss
andre
nachtrag zu deinem zweiten post. den hab ich eben erst gesehen.
ja. ich hatte das set auf das device gemacht. eigentlich aus gewohnheit und weil ich zu faul war zum tippen. ich hätte kein problem wenn es konistent ist und im device gesperrt sobald es den channel gibt aber ich denke das ist eventuell schwierig zu vermitteln. evenutuell einfacher wenn es den physikalischen channel aus meinem vorschlag oben gibt.
wann genau der state überschrieben wird ist nicht so sehr wichtig solange es zeitnah ist.
aber lass dir noch mal die idee mit noch einem channel mehr durch den kopf gehen:
- wenn es nur das device gibt bleibt alles beim alten
- sobald ein channel angelegt wird sollte es pro physikalischem channel ein device geben und die drei virtuellen.
gruss
andre
Hi Andre,
1) den physLevel baue ich ein wird dann in allen virtuellen channels zu sehen sein. Es gibt ihn nicht fuer dimmer ohne virtual channels.
2) das mit der SummenKanal entity ist der automatisierte 'dummy' incl dem Notify. Sauber waere es, wenn dann der state eines jeden dimmers der virtLevel ist und der State des virtPhysChannel der Reale. Aber sauber ist nicht immer leicht zu verstehen, fuer einfache User. Was gewaehrleistet sein muss ist der Normalfall. Der ist ein Betrieb ohne die virtuellen channels, die benutzt am Ende des Tages doch nur eine Minderheit. Allen anderen die moegliche Komplexitaet aufzudruecken ist nicht moeglich. Somit komme ich zu folgender Herleitung:
- der erste virtuelle Channel muss das reale Licht anzeigen, also state=physLevel
=> es muss einen virtLevel im ersten Channel geben
=> da virtLevel Bedeutung immer gleich sein muss, genauso wie state, werden alle 3 channels einen virtLevel haben und als state den realen Zustand
=> um das Arbeiten zu erleichtern wird es noch den physLevel geben, der erst einmal dem State entspricht (punkt 1)
Bleibt die Frage nach dem 4. Channel. Generell habe ich nichts dagegen, ich will die 99% der einfach User aber nicht mit noch mehr entities ueberfrachten.
Jetzt neuer Vorschlag:
a) Der Aufbau wie er ist, plus physLevel bleibt bestehen.
b) Attribut 'options' (namen sind frei erfunden und koennen von Autor noch geaendert werden;-) )steuert das Anlegen eines summen-devices. "options=0_default" betreibt den Dimmer wie in a). "options=1_physDummy" erzeugt und betreibt einen 4ten virtuellen Channel.
Details zu b) muss ich mir noch erarbeiten.
"options" kann ich ggf zum steuern weiterer Funktionalitaeten nutzen, auch in anderen Anwendungen - irgendwas kommt bestimmt. Options wird in diesem Fall immer am device festgemacht.
Anmerkung: auch in a) sollte alle 3 virtuellen channels sichtbar sein, selbst wenn der User erst einmal nicht so recht weiss, was er damit nachen soll. Die volle sichtbarkeit der HM sollte immer gegeben sein.
Gruss Martin
hallo martin,
deinen vorschlag lese ich nachher noch in ruhe durch. nur kurz noch etwas das auch berücksichtig werden sollte: das verhalten von device, physikalischen und virtuellen channels in gruppierungen wie structure und LightScene:
- die structure funktioniert dann wenn alle beteiligten devices in state das zurüchliefern das der anwender als status versteht.
- die LightScene funtktioniert dann wenn das was ich im state zurückbekomme auch das ist was ich im set setzen muß um das ding wieder in den gleichen zustand zu versetzen.
gruss
andre
Hi Andre,
LightScene habe ich noch nicht probiert, habe dir eine mail geschickt, wie man das handeln kann.
Generell wuerde ich hier gerne ein Interface zu Verfuegung stellen, in dem du den Status abfragen kannst, "FHEM intern" zur Weiterverarbeitung.
subType brauchst du eigentich nicht, solltest es aber, falls du es benoetigst, ueber
CUL_HM_Get($defs{$d},$d,"param","subType");
holen. Nur dann bekommst du fuer Channels auch eine korrektes Resultat.
Zurueck zum Dimmer:
fuer lightScene gibt es also eine einfach Loesung. Gerne koennen wir das Interface auch formalisieren. Wuerde mich freuen, wenn wir die uebergaben per funktion machen koennten, das erleichtert die Kompatibilitaetsbemuehungen und die Weiterentwicklung.
Bei Structure bin ich nicht sicher, wofuer es genutzt werden soll. Zum Setzen macht es wenig Sinn 3 virtual channels gleichzeitig zu setzen. Zur Ueberwachung ist es schon sinnvoll. Hierbei kommen die Werte nicht automatisch ins web-frontend. Ist das dein Anwendugnsfall?
Ueber den 'dummy' channel habe ich noch einmal nachgedacht (schon wieder...).
Hier -noch- eine lange Erklaerung:
Mein Ziel fuer CUL_HM ist:
1) alle Daten aus den HM devices sichtbar zu machen (alle die ich finde...)
2) alle Daten der HM devices einstellbar zu machen (soweit meoglich...)
3) alle Nachrichten dekodieren und in Zustaende mappen
4) alle Nachrichten zum device zu generieren
+alles werde ich nicht schaffen, klar.
darueberhinaus sollen
a) einfache funktionen auch einfach zu bedienen sein (prio 1!)
b) alle komplexe funktionen moeglich sein. User muss sich hier um Details ggf selbst kuemmern.
die virtuellen channels gehoeren sicher in die katerogie b) und werden, wenn wir kein templete erstellen, nur von wenigen genutzt werden. Andererseits gehoeren sie zu 1) - und hier will ich nichts ausblenden, Der User muss immer alle daten einfach sehen koennen. Ausblenden kann er selbst.
Die aktuellen Loesung stellt alles oben schon einmal sicher, wir reden also noch ueber Optimierung.
Die Loesung des 'dimmer problems' halte ich nicht fuer trivial - wenn an es konsequent und konsistent sein soll.
Das Erzeugen eines dummy-channels durch CUL_HM wiedestrebt mir. Das ist eigentlich eine Ebene ueber CUL_HM. Das Ziel ist es, 2 stati darzustellen. Solche Dinge sind schon geloest, beispielsweise bei temperatur sensoren:
T:<temp> H:<humidity>
angelehnt koennen wir auch hier 2 stati anzeigen. Moeglichkeiten
"phys:$physLevel virt:$virtLevel"
"$physLevel virt:$virtLevel"
"$physLevel ".(($physLevel != $virtLevel$)?"virt:$virtLevel":"")
"$virtLevel ".(($physLevel != $virtLevel$)?"phys:$physLevel":"")
die 4. Loesung scheint mir am Besten. User die nur den ersten betreiben werden nicht verwirrt. Sollte es zu Unterschieden kommen werden sie aufmerksam gemacht.
Die Namen der readings koennte man noch aendern in
level: Zustand der Entity (also den Channel) oben: virtLevel
outLevel: Zustand des physikalischen devices (also Zustand der Lampe)oben: physLevel
level wuerde ich bei -allen- aktoren einbauen, die eine level in Zahlen haben. Es ist dann auch eine Zahl von 0-100. damit kann an dann rechnen, es gibt hier kein on/off
outLevel ist ein Sonderfall der Dimmer
state ist ein human-readable Zustand. da gibt es on/off und alle sonstigen Darstellungen.
Das mappen auf ein 4. Device waere auf dieser Ebene nicht mehr vorhanden, kann sich der User aber einrichten.
Was haeltst du von diesem Denkansatz?
Gruss
Martin
hallo martin,
das mit dem interfache baue ich gerne ein. die subtypes brauche ich tatsächlich jetzt noch nicht. später öchte ich aber zwischen szenen überblenden. dazu muß ich die dimmer dann anders behandeln als switches und andere geräte. channels waren noch garnicht auf meinem schirm als ich das mit der LightScene gebaut habe. ich passe es an.
ja. der structure fall betrifft nur die überwachung. der anwendungsfall ist z.b. eine übersichtslampe für ein stockwerk oder ein raum. die dann eben entweder an oder aus oder gedimmt ist. bei den dimmern gibt es noch das problem das je nach device typ state unterschiedlich ausschaut und es ohne klimmzüge erst mal nur innerhalb einer device familie geht. die interfaces würden hier helfen. aber das ist ein anderes thema.
die ziele die du hast und auch die priorisierung sind völlig klar. das die viruellen channels nicht zu a) gehören auch. es wäre aber schoen sie in eine kategorie zwischen a) und b) zu bekommen weil sie gerade in verbindung mit einem bewegungsmelder und einer tag/nacht steuerung wirklich sehr nützlich sind und andere viel kompliziertere konstrukte unnötog machen.
das mit den zwei stati funktioniert nur im web interface und auf der kommandozeile. für den floorplan ist es eher unpraktisch und sicher nicht mehr a). jedenfalls solange es per default kein icon konfiguriert wird das seinen zustand aus einem anderen attribut als state holt. wenn man allerdings das icon von state entkoppelt ist es eine gute möglichkeit.
was ich bei der 3 entity lösung etwas unschön finde ist das es beim übergang von einem auf 3 entities einen bruch gibt weil sich die bedeutung von level ändert. im 1 channel fall ist ja immer die tatsächlich angezeigte helligkeit gleich dem gesetzten wert im channel. im 3 entity fall muß die echte helligkeit keinem der drei channel entsprechen. bei der 4 entity lösung gibt es diesen bruch nicht. das device wird angelegt und es gibt eine weitere entiy die die tatsächliche hellligkeit darstellt. hier kann ich die hellikeit sezten und abfragen. viruelle channel tauchen noch nicht auf. sobald ich diese benutzen will lege ich 2 oder 3 weitere entities an. diese reräsentieren nur die virtuellen channel und haben nur einen state bzw nur ein level attribut. eben der viruelle beitrag. die urspüngliche 1. entity bleibt davon völlig unberührt und stellt weiter im leven bzw state die tatsächliche helligkeit der lampe dar. ich habe das gefühl das sich das einem anfänger leichter vermitteln läßt als alles in nur 3 entities zu packen. auch wenn es der tatsächlichen hm hardware eher entspricht.
die tatsache das beim anlegen eines devices automatisch weitere fhem devices angelegt werden und der anwender eigentlich nur mit diesen interagiert gibt es ja auch beim HM-OU-LED16 oder HM-LC-Sw4-DR. wie ist das bei dem 2 kanal dimmer? gibt es da ein device für den tatsächlichen kasten und ein device je kanal? der 1-kanal dimmer würde dann einfach genau so funktionieren. ein device für den kasten und eins für den einen kanal.
ansonsten: den tatsächlichen level in ein reading zu stecken das so heisst und state für den human-readable zustand zu lassen finde ich gut. vielleicht gleich mit einem mapping bei dem die icons einen vernünfigt default auch für die dimmer haben.
gruss
andre
Hallo Andre
Zitatbei den dimmern gibt es noch das problem das je nach device typ state unterschiedlich ausschaut und es ohne klimmzüge ...
falls es eine Vereinheitlichung gibt, die machbar ist, gerne.
Zitatwas ich bei der 3 entity lösung ... die bedeutung von level ändert.
Aktuell bei mir im Test:
"level" ist immer der Zustand des Channel. "level" gibt es bei allen schaltern, dimmern und blindAktor.
"physLevel" ist der 'resultierende' Zustand. Den gibt es nur bei Aktoren, die einen solchen melden, also dimmer mit virtuelen Channels (gibt auch welchen ohne...)
Zitatim 3 entity fall muß die echte helligkeit keinem der drei channel entsprechen.
Das ist korrekt. Der 3-Entity-Fall wird aber nicht von mir generiert, der ist Realitaet bei den meisten Dimmern. Ich bilde ihn nur ab.
Zitatbei der 4 entity lösung gibt es diesen bruch nicht. das device wird angelegt und es gibt eine weitere entiy die die tatsächliche hellligkeit darstellt.
auch korrekt - das ist der Teil, der fuer 4 spricht
Zitathier kann ich die hellikeit sezten und abfragen.
das ist jetzt nicht mehr korrekt. Die 4. Entity ist im Gegensatz zu den anderen 3 nicht real, sie ist nur ein Monitor in FHEM. Ich habe -keine- Moeglichkeit hierueber irgend etwas zu steuern. Ausschlieslich die 3 virtuellen Channels geben die helligkeit vor. Ich habe noch nicht einmal eine Moeglichkeit, es zu faken.
Zitatviruelle channel tauchen noch nicht auf. sobald ich diese benutzen will lege ich 2 oder 3 weitere entities an. diese reräsentieren nur die virtuellen channel und haben nur einen state bzw nur ein level attribut. eben der viruelle beitrag. die urspüngliche 1. entity bleibt davon völlig unberührt und stellt weiter im leven bzw state die tatsächliche helligkeit der lampe dar. ich habe das gefühl das sich das einem anfänger leichter vermitteln läßt als alles in nur 3 entities zu packen. auch wenn es der tatsächlichen hm hardware eher entspricht.
aber es funktioniert nicht sauber.
1. Entity immer real, 2-4. Entity die virtuellen Channels
=> Sobald die virtuellen Entities ins spiel kommen kann ich nicht mehr einfach das Reale Licht steuern.
Zitatdie tatsache das beim anlegen eines devices automatisch weitere fhem devices angelegt werden und der anwender eigentlich nur mit diesen interagiert gibt es ja auch beim HM-OU-LED16 oder HM-LC-Sw4-DR. wie ist das bei dem 2 kanal dimmer?
CUL_HM legt immer alle channels an, die im Device bekannt sind. Angelegt werden alle fehlenden Channels sobald das device eine Anlernmessage schickt.
Ausnahme sind single-channel-devices. Hier reduziere ich den Overhead, das Device ist auch channel. Macht den code zwar anstrengender, aber einfacher fuer den User.
Ausnahme der Ausnahme sind single-channel dimmer. Die virtuellen cChannels habe ich erst spaeter verstanden und sichtbar gemacht. Nach der obigen regel sollte ich auch hier den ersten channel von Device trennen. Habe ich soeben geaendert, in der test-version. Kommt also. Der dual-dimmer war wegen der 2 channels schon immer so ausgelegt.
Ich bin jetzt auf folgenden Stand
- den fehlenden channel bei single-dimmer-mit-virtual-channel werde ich den 1. channel auto-anlegen
- jeder channel eines dimmer/switch/blind wird ein "level" reading bekommen, "0 %" bis "100 %", kein on/off
- wenn ein "physLevel" gemeldet wird kommt der in ein "phyLevel" reading, format wie "level". Das reding wird in alle 3 channels kopiert, die zu diesem Licht gehoeren
Soweit ist es fix, das war der Pflichtteil. Jetzt kommt die Kür, der stritige Teil, der "state":
Je kanal wird "level" mit "physLevel" verglichen. Sollte der gleich sein wird ein wert wie bisher angezeigt. [on/off/1-99]. Sollte er sich unterscheiden wird angezeit: "chn:<$level> phy:<$phyLevel>".
Diskussion des states:
Fuer einfache Anwendungen kann der User die beiden virtuellen Channels ignorieren. Das Verhalten von "state" ist wir gewohnt.
Sollte es zu Unterschieden kommen wird dies automatisch angezeigt. Im State werden nun beide Zustaende angezeigt, so wie es auch ein temperatur sensor macht. Wenn der simpleUser einen Fehler gemacht hat wird er direkt darauf aufmerksam gemacht.
Der ambitionierte User kann zur Verarbeitung immer auf die beiden Readings zugreifen. Er kann sie in state mappen oder sonst wie verarbeiten. Dieser User muss sowieso wissen, was er tut. Es kann ihm passieren, dass er sein licht nicht mehr einfach ausschalten kann.
Das mit der 4. Entity hat sein Schattenseiten, die hast du mir noch einmal klargemacht. Das sollte in CUL_HM nicht auftauchen, da es nicht abzubilden ist.
Zitatvielleicht gleich mit einem mapping bei dem die icons einen vernünfigt default auch für die dimmer haben.
ja, nachdem ich webCmd setze sollte ich auch icons vordefinieren.
Was haeltst du soweit davon?
Ich werden die Version demnächst herausgeben, dann kannst du es probieren
Gruss
Martin
hallo martin,
das mit den 4 entities finde ich persönlich ohne tiefer von den tatsächlichen hm randbedingungen beleckt zu sein logisch und leicht vermittelbar. wenn es nicht zur realität passt hift das natürlich nicht. aber ich hoffe es war wenigstens als gedankenspiel hilfreich :)
ansonsten klingt alles schlüssig und ich freue mich aufs ausprobieren.
gruss
andre
Hi Andre,
ich bin in jeden Fall dankbar für die Diskussion. Ich habe auch einige Dinge mitgenommen und einfließen lassen.
Ich habe schon so viel geredet, hoffentlich habe ich die Probleme der 4. Entity auch klargemacht. Ich will schließlich eine Lösung nur für mich:
Die Key-Gründe
- Die Entity waere die einzige ohne "HM-Gegenstueck", ein Novum an dieser Stelle
- Es gaebe KEINE kommandos, die man ausführen könnte, die muessen IMMER auf die channels abzielen. Das wuerde quasi jeden verwirren und lange Erklaerungen nötig machen
Ich werde es heute noch einstellen, es fehlen noch ein paar andere Dinge, aber dann...
Gruss
Martin
hallo martin,
ja. ich denke ich habe deine gründe verstanden und kann sie nachvollziehen.
zu den key gründen:
- das ist einerseits richtig, aus einer reinen anwender sicht könnte man aber durchaus sagen das was ich in der tatsächlichen helligkeit meiner lampe sehe
ist das gegenstück.
- das stimmt auch, es gibt aber schon die ausnahme das ein set auf das device den ersten channel geschaltet hat. das wäre hier genau so möglich (set auf den physikalischen channel wird auf den 1. virtuellen umgeleitet) und es würde niemanden verwirren der nicht tiefer einsteigen will weil einfach genau das passiert was der anwender erwartet.
aber genug der diskussion für diesmal :). du hast je eine lösung skizziert die alles abdeckt.
gruss
andre
Hi Andre
Zitatdas stimmt auch, es gibt aber schon die ausnahme das ein set auf das device den ersten channel geschaltet hat
.
das waere nicht mein Problem. Zum einen werde ich es einschränken, wenn Chan 1 definiert ist verliert das device diese Faehigkeit (mit ausnahmen).
Aber moeglich waere das schon, fuer den Dimmer...
Zitatdas wäre hier genau so möglich (set auf den physikalischen channel wird auf den 1. virtuellen umgeleitet)
ja, aber das Ergebnis waere nicht korrekt.
Einfache Beispiel: alle channels werden 'plus' kombiniert,alle 3 stehen auf 10%. Das Licht ist also 30% an, so wuerde es im 4.Kanal stehen.
Jetzt kommt das Kommando "4. Kanal off".
Ich schalte den 1. Kanal auf "0", das licht ist 20% an
=> Ergebnis nicht wie erwartet.
Ich kann noch nicht einmal 'off' eindeutig setzen, selbst wenn ich alle Channel auf '0' setze. Manche Kombinationen sind invertiert, das wuerde das licht einschalten.
Wenn einer 10% haben will, welchen der virtuellen Channels soll ich schalten, selbst wenn ich die die komplette Kombinatorik nachbaue. Und das nachbauen will ich gar nicht, denn dann muss ich auf dem Register-lesen bestehen, noch eine große Falle.
Ausser anzeigen ginge als nichts gesichert.
Gruss,
Martin
hallo martin,
ich habe heute mit den neuen features gespielt und so weit funktioniert mit level, physLevel und dem state in den channels alles. auch den physLevel aus einem channel in ein dummy oder in meinem fall ins device kopieren funktioniert natürlich.
was mir aber auffällt ist das der virtLevel beim dimmen auf set_xx stehen bleibt und beim set on oder set off überhaupt nicht beeinflusst wird. mit level und physLevel ist virtLevel doch eigentlich gar nicht mehr nötig oder?
und diese meldung ist mir noch aufgefallen:Illegal hexadecimal digit '(' ignored at /usr/local/FHEM/share/fhem/FHEM/10_CUL_HM.pm line 2684.
Illegal hexadecimal digit ')' ignored at /usr/local/FHEM/share/fhem/FHEM/10_CUL_HM.pm line 2696.
gruss
andre
Hi Andre,
virtLevel wird nicht mehr genutzt. Da hatte ich noch Reste vergessen. Wenn du die Readings löscht werden sie auch nicht mehr gesetzt.
Readings werden nie richtig aufgeraeumt, ich pruefe nicht, ob welche outdated sind.
Loeschen kann man alle mit set <name> clear readings.
Ist speziell interessant bei Registern, da ich nicht pruefe, welche nicht geschrieben werden. Muss man ggf ueber das Datum machen.
Ich hatte noch einen Bug beim Status-update drin, und bei einigen relativen Befehlen (up/down/toggel).
Kommt gleich
Gruss
Martin
hallo martin,
das mit dem aufräumen weiss ich :) hab ich auch gemacht aber zumindest in der version die ich hatte sind sie wieder aufgetaucht. sogar bei meinem rolladen.
gruss
andre