dimmer bleibt im state set_xxx hängen

[justme1968]

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

[justme1968]

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:

Code Auswählen Erweitern

attr global verbose 1
attr global mseclog 1
attr cul2 loglevel 1
set LED2 on
set LED2 off
set LED2 10
set LED2 off


Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[martinp876]

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.

15: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:

15: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

[justme1968]

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

[martinp876]

Hallo Andre,

wenn 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.

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.

warum nicht? Der reale Zustand ist als "state" in allen deinen 3 channels zu sehen. Nim doch einfach den ersten channel.

- 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...

Code Auswählen Erweitern

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')}

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.

ok, hat hier nichts mehr verloren, muss ich korrigieren.

wenn 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

[martinp876]

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

[justme1968]

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

[justme1968]

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

[martinp876]

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
 

[justme1968]

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

[martinp876]

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

[justme1968]

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

[martinp876]

Hallo Andre

bei 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.

was 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...)

im 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.

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.

auch korrekt - das ist der Teil, der fuer 4 spricht

hier 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.

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.

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.

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?

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.

vielleicht 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

[justme1968]

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

[martinp876]

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