Heating_Control Zustandsicon

Begonnen von Deckoffizier, 10 Dezember 2016, 18:55:29

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: skyline am 29 Oktober 2021, 19:32:58
Verstehe ich aber nicht so recht, warum es an manchen Stellen auch so gelöst wird (z.B. Shelly1) (in deiner 99_myUtils_Homematic.pm).
Da müßte ich zum einen auch suchen, warum ich das irgendwann man so gemacht habe...
Bei den Homematic-Geräten (und auch in ZWave-Utils ist sowas zu finden) gibt es halt die Besonderheit, dass "andere Geräte" in FHEM da nicht zwangsläufig bedeutet, dass es andere Hardware ist => man bekommt ein update auf alle Kanäle zurück, so dass das Aktualisierungs-Problem nicht in der Form besteht, das du hier beschreibst:
ZitatJedoch aktualisiert sich hier das devStateIcon erst nach einer Browser-Seiten-Aktualisierung.
Hat hier vielleicht noch jemand einen Tipp, wie ich das sauber abgebildet bekomme?
devStateIcon braucht einen Trigger auf das Gerät, damit die Ansicht (afaik via longpoll) aktualisiert wird. Ist wie die roten Zeitstempel bei Reading-Aktualiserungen.

Zitat
Ich habe gesehen, dass es im Wiki auch einen Beitrag zu readingGroup gibt und werde mir das auch anschauen.
Ist ein sehr mächtiges Tool, und es gibt ganz ordentliche Beispiele da. Leider nicht mehr ganz aktuell, da werden manchmal dummy eingesetzt, die man heute wohl nicht mehr braucht.

Zitat
Jedoch möchte ich lieber ohne zusätzliche Module auskommen und es geht mir ja auch um den Lernprozess.
Auch da kann man viel lernen, und das ist afaik im laufenden Betrieb ziemlich leichtgewichtig, da reines Frontend-Tool.
Zitat
Ohhh, das kannte ich nicht. Da hast du aber echt was tolles abgeliefert. Werde ich bestimmt noch einsetzten!
Danke für die Rückmeldung und viel Spaß beim Austüfteln, wie du das für dich nutzbar machen kannst.

Zitat
Für meinen Fall gerade leider nicht zu gebrauchen, da ich meine MAX-Thermostate mit Pid20 verwende, wenn dies nicht mehr am Thermostat auf on stehen, soll ich ganze Regelung über Pid20/WDT ausgesetzt werden.
Kann ich nicht beurteilen, aber meine Vermutung wäre, dass die ganze Logik ggf. über weekprofile-Topics viel einfacher umzusetzen wäre. Kenne aber PID20 nicht. Falls da z.B. die Option besteht, eine Zieltemp "off" (oder "deacivated" oder whatever) zu wählen, um zu deaktivieren, könnte die recht einfach aus weekprofile kommen, eventuell noch in Verbindung mit einem Event-Mapping bei WDT (auch das ein relativ neues feature).

Wir sollten solche Sachen aber mAn. nicht mehr unter dem Thread-Titel "Heating_Control" diskutieren, das ist einfach outdated, und wenn jemand versucht, das wiederzubeleben, erlebt er  uU. einen bösen "auf-die-Nase-Faller"... :P

Generelle Anmerkung: Es gibt relativ wenige Threads etc., die sich mit weekprofile/WDT beschäftigen (ab dem Zeitpunkt, an dem den TE jeweils klar war, wie es grundsätzlich funktioniert). Ich vermute, es wäre ggf. auch für andere User hilfreich, wenn wir (ggf. im Wiki) wieder ein aktualisiertes Beispiel auch für PID20 hätten. Da gibt es - soweit mir in Erinnerung - nur einen zu HC+PID20.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors