FHEMWEB Anpassungen

[rudolfkoenig]

Betrifft die FHEMWEB Anpassung:

Die FHEMWEB Statusanzeige hat hartkodierte Vorbelegungen, wenn bestimmte Befehle verfuegbar sind:

- bei desired-temp: falls state measured-temp:.* ist, dann wird daraus "Wert °C", webCmd (das sind die anklickbaren Befehle, rechts vom Status) wird mit desired-temp vorbelegt. desired-temp wird in CUL_HM, EnOcean, FBDECT, ZWave, FHT und (ueber attrTemplate) in MQTT2 erzeugt.

- bei desiredTemperature: state wird auf dem ReadingsVal temperature gesetzt (mit °C), und webCmd mit desiredTemperature vorbelegt. desiredTemperature kommt aus EQ3BT und MAX.

- bei on und off (bzw. ON und OFF) => webCmd wird mit on:off vorbelegt.

Anzeige/Bedienung muesste das Modul vorbelegen, der Benutzer sollte das per Attribut ueberstimmen koennen. Mit STATE hat das Modul bereits eine Moeglichkeit, die Anzeige vorzubelegen (der Benutzer kann das mit dem Attribut stateFormat ueberschreiben), mit einem neuen Internal $hash->{webCmd} koennte man das webCmd Attribut "vorbelegen". Wenn ich schon dabei bin: ich wuerde diese Vorbelegung auch fuer andere Attribute (cmdIcon, devStateIcon, devStateStyle, icon und webCmdLabel) uebernehmen, als $hash->{cmdIcon}, usw.
Die on/off Behandlung wuerde ich nicht anfassen, nur desired-temp und desiredTemperature.

Die Module FBDECT, ZWave und FHT wuerde ich uebernehmen (d.h. $hash->{webCmd} und $hash->{STATE} setzen), die anderen Modul-Maintainer muessten benachrichtigt werden.

Meinungen?

P.S.: Im Sinne der Vereinheitlichung wuerde ich begruessen, wenn EQ3BT und MAX auch/zusaetzlch measured-temp/desired-temp anbieten wuerde.

[Wzut]

P.S.: Im Sinne der Vereinheitlichung wuerde ich begruessen, wenn EQ3BT und MAX auch/zusaetzlch measured-temp/desired-temp anbieten wuerde.

kann ich nach meinem Urlaub machen , nP - wäre dann wieder ein Schritt näher an HM was Bezeichnungen betrifft.
Was deine vorgeschlagenen Änderungen für FHEMWEB betrifft :
Habe ich das richtig verstanden : du legst beim FHEMWEB erst einmal vor und ich kann/muß dann später nachziehen ?

[rudolfkoenig]

- 01_FHEMWEB.pm: die Vorbelegung fuer webCmd, webCmdLabel, cmdIcon, devStateIcon, devStateStyle, und icon ist ab sofort $hash->{webCmd}, usw.

- FHT.pm: $hash->{webCmd} wird mit desired-temp vorbelegt, und state wurde von "measured-temp: $val" auf "$val C" geaendert. Das ° ist weggefallen, da ich keine Loesung fuer Plain-Text (aka telnet) und HTTP gefunden habe.

- FBDECT.pm: beim Typ actuator wird $hash->{webCmd} = "desired-temp" gesetzt. State war auch bisher desired-temp, das lasse ich einfach so.

- ZWave.pm: bei Geraeten mit THERMOSTAT_SETPOINT wird $hash->{webCmd} = "desired-temp" gesetzt, weiterhin wird dafuer widget-Type auf slider,7,1,28,1 gesetzt

- fhemweb.js: slider Bug bei Zahlen-Extrahieren aus ReadingName:Wert gefixt.

Die desired-temp-Magie habe ich aus FHEMWEB.pm noch nicht entfernt, dazu brauche ich noch die Rueckmeldung von den anderen Maintainer. Wuerde mich freuen, falls man die Benachrichtigung jemand uebernehmen wuerde.

[Wzut]

ich war mal so frei den Teil im MAX Forum abzutrennen und hier her zu verschieben

[Wzut]

mit einem neuen Internal $hash->{webCmd} koennte man das webCmd Attribut "vorbelegen"

--snipp --

die anderen Modul-Maintainer muessten benachrichtigt werden.

--snipp--

Im Sinne der Vereinheitlichung wuerde ich begruessen, wenn EQ3BT und MAX auch/zusaetzlch measured-temp/desired-temp anbieten wuerde.

a. ich nehme das Attribut webCmd wenn vorhanden und kopiere es nach  $hash->{webCmd} bzw setzte sonst desiredTemperature

Code: [Auswählen]

$shash->{webCmd} = AttrVal($sname, 'webCmd', 'desiredTemperature');
oder habe ich das jetzt falsch verstanden und du setzt webCmd in 01_FHEMWEB und ich muß das Attribut nachziehen ?

b. Ich habe Dominik (EQ3BT) und Martin (CUL_HM) angeschrieben, fehlt da noch jemand ?

c.  measured-temp/desired-temp ist drin, kann ich sofort einchecken. zusammen mit webCmd

Rudi, wie werden dann die weiteren Änderungen an FHEMWB aussehen , willst du lediglich

Code: [Auswählen]

$txt .= "°C";
entfernen oder den ganzen elsif Block drumherum ?

[dominik]

Hi,

danke für die PN, ich passe es auch am Wochenende in EQ3BT an.

Eine Frage noch zu Vorbelegungen, wie gehen wir damit bei Updates um? Vorbelegungen die vom User nicht verändert werden, sollten auch vom Miantainer weiterhin beim Update geändert werden, sobald der User einmal was ändert, sollte es dann unverändert bleiben. Sehr ihr das auch so? Schön wäre, wenn das durch die neuen $hash->{...} Werte gleich einheitlich so im Hintergrund gemacht wird.

[martinp876]

Danke für die PN.

Ich habe es nicht überrissen. (CUL_HM)
1) On/Off sind keine Kommandos sondern werden über desired-temp als min/max temp eingestellt. So ist es aus EQ3 übernommen....  Ein °C wäre hier seltsam.
2) In der Anzeige eine Einheit anzufügen ist ok - allerdings muss dies bei der Kommandoeingabe entfernt werden, da hier keine Einheiten vorhanden /berücksichtigt sind.
3) was hat desired-temp mit state measured-temp zu tun?
   a) soll °C nur im "State" erscheinen, wenn das Kommando desired-temp vorhanden ist, "state=measured-temp:.*" und damit ach measured-temp?
   b) measured-temp und desired-temp bleiben einheitslos?
  => ganz im Ernst: Das ist viel Aufwand für wenig.
  => für meine persönliche Anzeige ist das eh VIEL zu wenig. In meinem State die 3 Teile, welchen den Zustand des HK beschreiben:
      - desired-temp
      - measured-temp
      - valve position
     das sind die key-zustände eines Thermostat-reglers - ich will sie alle im Frontend/state
4) in CUL_HM setze ich aktuell  für einige Module das Attribut state und webCmd auf einen Default. Setzt der User ein eigenes hat er eben keinen Default mehr. Das ist m.E. sinnvoll (und die Idee von einem Default). Der User kann es überschreiben/ändern oder nutzen. Es ist vor allem SICHTBAR! und bedarf keiner neuen, undurchsichtigen Methode.

Im WebCmd für eine Thermostatsteuerung braucht CUL_HM (setzt als default)
- desired-temp
- controlMode (auto|manual|boost|night|day)
- tempTmplSet (setzen des vordefinierten Wochenpogramms)


Also mein Kommentar:
I) Einheiten sind prima - aber bitte eine generelle Lösung für alle Readings. pha hatte vor Jahren vorgeschlagen, Readings in Wert und Einheit zu zerlegen. Ein komplexes Thema, da hier u.a. geprüft werden muss, wie bspw mit attr stateFormat umgegangen wird
II) Warum ich ein hash->{webCmd} brauche ist mir nicht klar - das Attribut sollte reichen (funktioniert prima, keine Reklamationen)

[betateilchen]

II) Warum ich ein hash->{webCmd} brauche ist mir nicht klar - das Attribut sollte reichen (funktioniert prima, keine Reklamationen)

*unterschreib*