[cul_hm] seit letztem update hat auch jeder channel das reading commState

[frank]

hallo martin,

ist es absicht, dass nun alle entities das reading commState erhalten?
ganz schön viele "unnötige" events, oder?
dadurch triggern gerade viele doif/notify, da sie "schlecht" gebaut sind.

zeile 8213:

Code Auswählen Erweitern

  CUL_HM_UpdtReadSingle($defs{$_},"commState",$state,1) foreach(CUL_HM_getAssChnNames($name));


[frank]

nur mal zur info!

mit einem getconfig im hauptdevice bei meinem 3-chn-dimmer bekomme ich aktuell 41 events aus 4 entities, die pending, processing oder done enthalten.

allerdings nur, wenn in allen 4 entities "attr event-on-change-reading .*" gesetzt wurde.
default ohne eocr sind es sogar 264.

mich würden ja mal die zahlen bei einer 19-chn-fb interessieren.

edit:
für einen vergleich fehlt natürlich noch die anzahl der events nur im hauptdevice:
das sind 14 events, von denen eigentlich auch schon 5 unnötig sind, da sie zusätzlich im state auftauchen.

somit gibt es aktuell von 14 (9) "nötigen" events zusätzlich 27 "unnötige" events.

[LuckyDay]

Code Auswählen Erweitern

"unnötige" events.

Ich lasse nur events durch die "mich" interessieren, bzw . die ich zur Anzeige usw brauche. Einfach weiter einschränken und nicht den Faul-Joker ziehen.
"attr event-on-change-reading .*" am Dimmer wäre doch nur -> level, pct von Interesse
also statt ".*" ->z.b "level,pct,state"

[Otto123]

das ist wie die nutzlose Umverpackung, die der Kunde gleich im Laden vom Produkt entfernen und in dort bereitgestellte Tonne werfen muss.

[yersinia]

[OT]

das ist wie die nutzlose Umverpackung, die der Kunde gleich im Laden vom Produkt entfernen und in dort bereitgestellte Tonne werfen muss.

Wir wären nicht in Deutschland, wenn die Produktverpackung nicht ein wesentlicher Bestandteil des Produktes ist. Dies kann der Hersteller natürlich individuell definieren - und schon ist eine eigentliche Umverpackung ein Bestandteil der Verkaufsverpackung.
[/OT]

[martinp876]

der commstate je Entitiy wurde gewünscht um in jeder entity anzeigen zu können, ob alles ok ist und die Kommandos auch abgearbeitet werden. War für das web-frontend gedacht und gewünscht.

Ich gebe euch allerdings Recht mit der performance.
Nun überlege ich
- es abschaltbar zu machen (attribut)
   . wäre natürlich zentral cool - also in HMInfo. 
- die Änderungen zu reduzieren - also nur kritische Events anzuzeigen (error).

noch unentschlossen.

[frank]

hm... , da fällt mir gerade was ein.

bei der entwicklung der status-icons von hm.js habe ich davon gesprochen, dass es sehr hilfreich ist, wenn man commState in jeder entity sehen würde, um eine reaktion von fhem beim senden von cmds zu sehen.

daher habe ich das feature dort eingebaut und möchte es auch nicht mehr missen.
hm.js braucht commState aber nicht in jeder entity.
von mir aus braucht es die zusätzlichen readings in jeder entity nicht.


so gesehen, macht das reading grundsätzlich schon sinn.
allerdings ist die position des readings bei mir in der regel sehr weit unten auf der website, also ausserhalb der aktuellen ansicht. dann ist aber ein umswitchen auf einen zusätzlichen tab vom device eigentlich schon wieder "bequemer" und schneller. und dadurch in der entity aber wieder "überflüssig".
wirklich hilfreich ist es eigentlich nur, wenn es auch immer automatisch sofort zu sehen ist. vor allem für anfänger und gelegentliche user.


zentral abschaltbar wäre sicherlich eine gute option, um redundante events zu verhindern.
und über hminfo abzuschalten, erhöht auch auch gleichzeitig die hminfo user.   

[Otto123]

der commstate je Entitiy wurde gewünscht um in jeder entity anzeigen zu können, ob alles ok ist und die Kommandos auch abgearbeitet werden. War für das web-frontend gedacht und gewünscht.

Hallo Martin,

mag sein das sich das jemand so gewünscht hat, aber bitte eben nur für die jeweilige entity!
Beispiel: ich habe einen HM-MOD-RE-8, ich betätige eine entity (SW81_4), das ist das Ergebnis:

Code Auswählen Erweitern

2021-07-19 11:13:32 CUL_HM SW81 commState: CMDs_pending
2021-07-19 11:13:32 CUL_HM SW81_1_TorAuf commState: CMDs_pending
2021-07-19 11:13:32 CUL_HM SW81_2_TorSpalt commState: CMDs_pending
2021-07-19 11:13:32 CUL_HM SW81_3_TorZu commState: CMDs_pending
2021-07-19 11:13:32 CUL_HM SW81_4 commState: CMDs_pending
2021-07-19 11:13:32 CUL_HM SW81_5 commState: CMDs_pending
2021-07-19 11:13:32 CUL_HM SW81_6 commState: CMDs_pending
2021-07-19 11:13:32 CUL_HM SW81_7 commState: CMDs_pending
2021-07-19 11:13:32 CUL_HM SW81_8 commState: CMDs_pending
2021-07-19 11:13:32 CUL_HM SW81 commState: CMDs_processing...
2021-07-19 11:13:32 CUL_HM SW81_1_TorAuf commState: CMDs_processing...
2021-07-19 11:13:32 CUL_HM SW81_2_TorSpalt commState: CMDs_processing...
2021-07-19 11:13:32 CUL_HM SW81_3_TorZu commState: CMDs_processing...
2021-07-19 11:13:32 CUL_HM SW81_4 commState: CMDs_processing...
2021-07-19 11:13:32 CUL_HM SW81_5 commState: CMDs_processing...
2021-07-19 11:13:32 CUL_HM SW81_6 commState: CMDs_processing...
2021-07-19 11:13:32 CUL_HM SW81_7 commState: CMDs_processing...
2021-07-19 11:13:32 CUL_HM SW81_8 commState: CMDs_processing...
2021-07-19 11:13:32 CUL_HM SW81 commState: CMDs_done
2021-07-19 11:13:33 CUL_HM SW81_1_TorAuf commState: CMDs_done
2021-07-19 11:13:33 CUL_HM SW81_2_TorSpalt commState: CMDs_done
2021-07-19 11:13:33 CUL_HM SW81_3_TorZu commState: CMDs_done
2021-07-19 11:13:33 CUL_HM SW81_4 commState: CMDs_done
2021-07-19 11:13:33 CUL_HM SW81_5 commState: CMDs_done
2021-07-19 11:13:33 CUL_HM SW81_6 commState: CMDs_done
2021-07-19 11:13:33 CUL_HM SW81_7 commState: CMDs_done
2021-07-19 11:13:33 CUL_HM SW81_8 commState: CMDs_done

Das kann sich doch keiner gewünscht haben?! Darf ich mir auch was wünschen? Mach es bitte wieder weg!

Welche Idee steckt dahinter, die Komunikation (die meines Wissen ja im Hauptdevice stattfindet) einfach stumpf in alle Kanäle (die überhaupt nicht separat kommunizieren können) zu spiegeln?

Gruß Otto

[martinp876]

Hallo Otto,

der COM state gilt nun einmal für alle Channels. hm... es auf Kommands für die entiy zu begrenzen ist aufwändig - und muss erst einmal definiert werden. Wird beispielsweise ein getConfig gemacht für das Device ist es auch relevant für jeden channel. Zum einen ist der Einbau aufwändig und zum anderen wird es kaum einer verstehen.

Einfacher und pragmatischer ist, es abschaltbar zu machen. Das macht man dann aber nur in Device:
Attr commStInCh (on|off) mit default "on"
Beschreibung: on: show device reading commState in each channel
ein
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual commStInCh off

Download aktuell in
https://forum.fhem.de/index.php?topic=122107.msg1168633#msg1168633

Ab nächste Woche wie  normal
im (von mir empfohlenen) User.cfg stellt es dann nach Reboot sicher.

[Otto123]

Wird beispielsweise ein getConfig gemacht für das Device ist es auch relevant für jeden channel. Zum einen ist der Einbau aufwändig und zum anderen wird es kaum einer verstehen.

Hallo Martin,

das überzeugt mich nicht. Ich rede nicht vom getConfig (Amtsblatt). Ich rede davon: Einer macht die Tür auf und zu und alle im Dorf bekommen eine Email deswegen. Der Bürgermeister sagt: wenn ihr das nicht wollt baut doch eine Regel in eurem Outlook ein.
Diese Denkweise ist klimaschädlich.

Edit:
Du bietest jetzt als Workaround ein opt out Verfahren. Warum änderst Du das nicht in ein opt in? Der sich das Verhalten gewünscht hat, kann doch gerne dieses Verhalten aktivieren - alle anderen müssen nicht darunter leiden.

Gruß Otto

[martinp876]

Grundsätzlich ist es mir egal. Aber...
Grund ist, dass der Default typisch aktuelle Implementierung abbildet. Aktuell ist es 'on'. Du wirst argumentieren, dass es vor der implementierung "off" war - womit du auffallend recht hättest. Ich haben eine Entscheidung getroffen.
Für dich als alten Fuchs ist ein

Code Auswählen Erweitern

attr TYPE=CUL_HM:FILTER=DEF=...... commStInCh off
im (von mir empfohlenen und als zwingend angesehenen) UserConfig.cfg kein Problem.

Mein UserCfg.cfg ist voll mit default settings - welche ich hiermit selbst bestimme. Einer der wirklich guten Optionen in FHEM!!!

Spätestens beim Reboot ist dann alles wie du es willst.