Schnittstellenänderung

[JoeALLb]

Die tägliche Nutzung der neuen Version ist viel Angenehmer als bei der bisherigen.
Dennoch stelle ich die Notwendigkeit von "-get" in Frage!
Ich habe meine Installation fast komplett migriert, am meisten Aufwand war
die Änderung durch die Großkleinschreibung... da funktionierten plötzlich die kleingeschriebenen Readings nicht mehr.

Mit "-put" und "-set" kann ich sehr gut leben,
jedoch wenn ich ein

Code Auswählen Erweitern

get <device> temperature
absetze, erwarte ich mir eigentlich als Rückgabe eine Temperatur!
zudem schänkt mich das "-get" in der Namenswahl deutlich ein.

Ich beobachte mich immer häufiger beim Umschreiben der "-get" readings mittels userReadings, was ich für sinnlosen Doppelaufwand halte!

Wenn Du es nicht allgemeingültig ändern möchtest, wie wäre es mit einem Attribut?
Dann würde auch bei einem set <device> in der Weboberfläche gleich der aktuelle Wert vorab ausgewählt werden, was besonders bei Temperaturen
hilfreich ist!

sG
Joe

[JoeALLb]

Nachtrag #x:

Ich weiß nicht, wie es in anderen Modulen ist, aber wenn ein userReading undef zurückgibt, werden KEINE Events mehr produziert und somit auch nichts mehr geloggt.
Gespeichert werden die geänderten Werte jedoch in ihren Readings!

sG
Joe

[Andi291]

Moin!

Zu Deiner Anregung wegen -get...
-get wird in vielen Fällen sehr wohl benötigt - zumindest je nach Ansatz. Eine Umbenenneung packe ich jetzt nicht an - da drehen wir alle anderen hohl Wenn Du eine minimal invasive Lösung brauchst, lautet die Antwort: manipuliere -get in der Define-Methode beim Schreiben der Gaddetails.
Die Unterscheidung zwischen Groß- und Kleinschreibung hab ich bereits vor einigen WOchen eingebaut. Ist nicht unproblematisch - gab aber doch einige entsprechende Wünsche...
Bezüglich Userreadings hab ich 0,0 Behandlung im Modul - will ich auch beibehalten...

Zu den Themen von gestern:
- putCmd wird immer ausgeführt
- "-put" überschreibt den ggf. vorbelegten Wert von "state"
- $hash krieg ich in putCmd mangels Kontext nicht sauberer hin - musst beim Hardcodieren bleiben
- Der Input mit GETSTRING war super - hier war noch ein unschöner bug drin...

Doku mach ich nach Ostern, dann isses meine ich reif für einen Breitentest...

Grüße, Andi

[JoeALLb]

Hallo Andi,

danke für die neue Version!

#1: Das Problem aus #72 existiert noch.
Anbei die WRAW_Definition eines Devices. Wenn ich

Code Auswählen Erweitern

fhem> get knx.TEST measured-temp
current value for knx.TEST (5/5/0) requested absetze, erhalte ich als Antwort, dass 5/5/0 abgefragt wird, nicht
5/5/6, wie ich erwartet hätte.

Code Auswählen Erweitern

defmod knx.TEST KNX 5/5/0:dpt9.004:brightRight\
5/5/2:dpt9.004:brightCenter\
5/5/3:dpt9.004:brightLeft\
5/5/4:dpt9.004:twilight\
5/5/5:dpt1.001:daynight\
5/5/6:dpt9.001:measured-temp\
5/5/1:dpt1.001:alarm-bright-right\
5/5/20:dpt1.001:alarm-bright-center1\
5/5/7:dpt1.001:alarm-temp-frost\
5/5/17:dpt1.001:alarm-temp-hitze\
5/5/10:dpt1:alarm-wind1\
5/5/20:dpt1:alarm-wind2\
5/5/18:dpt1:alarm-rain1\
5/5/19:dpt1:alarm-rain2\
5/5/15:dpt1.001:alarm-Sensor\
5/5/14:dpt1.001:alarm-Time\
5/5/16:dpt1.001:alarm-Unit\
5/5/8:dpt9.026:measured-rain\
5/5/9:dpt9.028:measured-wind\
5/5/11:dpt10:time\
5/5/12:dpt1.001:getDate\
5/5/13:dpt11:date
attr knx.TEST DbLogExclude last-sender, state
attr knx.TEST IODev KNX
attr knx.TEST room TEST
attr knx.TEST verbose 5
attr knx.TEST webCmd :
attr knx.TEST widgetOverride stateCmd:textField-long\
eventMap:textField-long\
widgetOverride:textField-long

setstate knx.TEST 16.72 °;C
setstate knx.TEST 2018-03-28 08:09:07 alarm-temp-hitze-get off
setstate knx.TEST 2018-03-28 08:09:07 alarm-wind1-get off
setstate knx.TEST 2018-03-28 08:09:29 last-sender 1/1/10
setstate knx.TEST 2018-03-28 08:09:29 measured-temp-get 16.72 °;C
setstate knx.TEST 2018-03-28 08:09:29 state 16.72 °;C


Zu Deiner Anregung wegen -get...
- Wenn Du eine minimal invasive Lösung brauchst, lautet die Antwort: manipuliere -get in der Define-Methode beim Schreiben der Gaddetails.

Werde ich machen! Schlage hier jedoch trotzdem eine Suffix-Attribut vor, das ja standardmäßig mit "-get" vorbelegt sein kann.

Die Unterscheidung zwischen Groß- und Kleinschreibung hab ich bereits vor einigen WOchen eingebaut.

Nicht falsch verstehen, mir gefällt dies! Musste nur einige stateCmd's und anderes aktualisieren!

Bezüglich Userreadings hab ich 0,0 Behandlung im Modul - will ich auch beibehalten...

Mich wundert nur, dass danach nichtmal mehr moduleigene Readings Events produzierten.
Da weicht das Verhalten zumindest von anderen Modulen ab.
Die Rückgabe von undef ist nötig, wenn man im Userreading entscheidet, dass dies in diesem Fall eben NICHT aktualisiert werden soll.
Ich werd mir das aber auch noch genauer ansehen!

- $hash krieg ich in putCmd mangels Kontext nicht sauberer hin - musst beim Hardcodieren bleiben

Das ist bitter... warum funktioniert es im stateCmd schon?

Dann sag ich erstmal nochmals Danke für die neue Version, werde sie weiter testen!

sG
Joe

[Andi291]

Moin!

Ich schau mir das mit den verzwirbelten Adressen nochmal an - hab ich noch nicht verstanden.
Bitte poste auch die Konfiguration des Devices mit der GAD 5/5/0.

Bezüglich Userreadings hab ich 0,0 Behandlung im Modul - will ich auch beibehalten...
Mich wundert nur, dass danach nichtmal mehr moduleigene Readings Events produzierten.
Da weicht das Verhalten zumindest von anderen Modulen ab.
Die Rückgabe von undef ist nötig, wenn man im Userreading entscheidet, dass dies in diesem Fall eben NICHT aktualisiert werden soll.
Ich werd mir das aber auch noch genauer ansehen!

Ja, bitte.

$hash krieg ich in putCmd mangels Kontext nicht sauberer hin - musst beim Hardcodieren bleiben
Das ist bitter... warum funktioniert es im stateCmd schon?

Hatte ich vorgestern versucht zu erklären - stateCmd passiert im eigenen Kontext, putCmd kann auch im fremden Kontext passieren...

Grüße, Andi

[JoeALLb]

Bitte poste auch die Konfiguration des Devices mit der GAD 5/5/0.

Hängt doch oben in Beitrag 78 mit dran, zum selber ausprobieren.

sG
Joe

[Andi291]

Nein. In dem Device von Beitrag 78 ist die GAD 5/5/0 nicht definiert.

Ich nehme an, die ist Teil einer anderen Definition...Und genau die Suche ich. Ich vermute, hier kommen Namen durcheinander...

[JoeALLb]

Nein. In dem Device von Beitrag 78 ist die GAD 5/5/0 nicht definiert.

Doch, schau in die erste Zeile mit dem Gad Namen brightRight.

SG Joe

[Andi291]

Gibs zu, das hast Du heimlich editiert

EDIT:
Bitteschön...

[JoeALLb]

Gibs zu, das hast Du heimlich editiert

EDIT:
Bitteschön...

Sonst wärs doch langweilig
... über Deinen Edit wurde ich nicht per Email informiert, daher hab ich die Version gerade eben erst per Zufall "gefunden"

Werd testen!

[JoeALLb]

Hi,
Ich benötige unbedingt eine Möglichkeit, das Answer einer Gad zu verhindern, während eine andere sehrwohl antwortet.
Sonst bekomme ich bei einem Heizungsthermostat (zB. Für die gad der Temperaturmessung) doppelte antworten...

Generell würde ich bei der Definition nach dem Namen der Gäste einen vierten optionalen Block vorschlagen.

Als kurzfristig Lösung würde ich h jedoch vorschlagen, dass wenn putCmd den value auf undef (oder einen beliebig anderen vordefinierten Wert) setzt, keine Antwort gesendet wird. ( Oder ist dies schon so, da undef ja nicht wirklich gesendet werden kann?)
Durch diese undef- variante kann ich beispielsweise auch gleich verhindern, dass eine Antwort zu oft generiert wird und sie beispielsweise auf 1x pro Minute limitieren, um den Bus zu entlasten.

SG Joe

[JoeALLb]

Hier ein Beispieldevice, das zeigen soll,
warum suffixe manchmal problematisch sind.
Ich benötige hier das userreading nur, um den wert in das richtige reading (also ohne -set) zu kopieren.
Ich würde also ein Atribut vorschlagen, das "set-suffix, default to '-set' " heißen könnte.

Da, wie das Beispiel zeigt, die Widgets nun so schön genutzt werden können, würde ich vorschlagen, das Attribut "slider"
als veraltet zu bezeichnen und diesen FHEM-Standard durchgängig zu propagieren ...

Code Auswählen Erweitern

defmod HeizungMaster3 KNX 7/3/0:dpt1.003:acutator-mode
attr HeizungMaster3 eventMap /acutator-mode disable:acutator-mode auto/\
acutator-mode enable:acutator-mode closed/
attr HeizungMaster3 room KNXtest
attr HeizungMaster3 stateCmd {  "Mode: ".ReadingsVal($name,"acutator-mode","undef").\
""}\
\

attr HeizungMaster3 stateRegex /status-set:enable/closed/ /status-set:disable/auto/ /XXX.*//
attr HeizungMaster3 userReadings acutator-mode:acutator-mode-set.* {   \
  my $reading = ReadingsVal($name,"acutator-mode-set",undef);;\
  if ($reading =~ /enable/)\
    {\
      return "closed";;\
    }\
  else\
    {  \
     return "auto";;\
    }\
}
attr HeizungMaster3 verbose 5
attr HeizungMaster3 webCmd acutator-mode
attr HeizungMaster3 widgetOverride devStateIcon:textField-long\
stateCmd:textField-long\
stateRegex:textField-long\
eventMap:textField-long\
widgetOverride:textField-long\
acutator-mode:uzsuToggle,auto,closed

setstate HeizungMaster3 Mode: auto
setstate HeizungMaster3 2018-04-02 13:11:41 acutator-mode closed
setstate HeizungMaster3 2018-04-02 13:11:41 acutator-mode-set enable
setstate HeizungMaster3 2018-04-02 13:11:41 state Mode: auto



sG
Joe

[Andi291]

Moin!

Das hab ich schon auf dem Schirm.
Dafür kannst Du in der Definition get/set/listenonly angeben. Muss ich aber noch scharf schalten.

Wenn answerReading nicht gesetzt ist, und putCmd undef ist, wird keine Antwort gesendet.

Grüße, Andi

[JoeALLb]

Das hab ich schon auf dem Schirm.
Dafür kannst Du in der Definition get/set/listenonly angeben. Muss ich aber noch scharf schalten.

Top! Das war eigentlich mein größter Showstopper.
Ich bekomme noch manche userreadings nicht mit DbLog geloggt, aber das wollte ich mir noch genauer ansehen.
Ich habe dafür im Moment einen workaround mittels cronjob im Einsatz.

Aus meiner Sicht steht daher einer veröffentlichung nichts mehr im Weg.
Ich hab noch einen Vorschlag für eine Vereinfachung der Funktion splitFn, das teste ich aber vorab noch.

sG
Joe