Modul weekprofile + FHEMWEB widget

[spe]

Hallo,

mein erster Forum-Eintrag, man möge mir bitte evtl. Fehler verzeihen. 

Ich möchte auch über weekprofile Wandthermostate (HM-TC-IT-WM-W-EU) und Heizkörperthermostate (HM-CC-RT-DN) steuern. Die Devices sind vom Type HMCCUDEV.
Die Wandthermostate brauchen einen Präfix "P1_" (z.B. "P1_TEMPERATURE_MONDAY=") im Kommando die Heizkörperthermostate brauchen keinen Präfix ((z.B. "TEMPERATURE_MONDAY=").

Wenn ich den Code von weekprofile richtig verstanden habe (meine Perl-Kenntnisse sind quasi = 0)  wird in der Funktion "sub weekprofile_get_prefix_HM" der Präfix anhand von bestehenden Readings gebildet. Wenn aber die Readings nicht vorhanden sind geht das schief. Muss ich als Anwender hier dafür sorgen das die Readings vorhanden sind, sprich mach ich da was falsch ?
Die Readings lassen sich ja per clear löschen.

Ich habe jetzt mal zum testen in der Funktion den Devicetype (ccutype) abgefragt und abhängig davon den Präfix direkt beschrieben. Beim Wandthermostaten benutze ich nur das Programm "P1".
Dann funktioniert es mal für meine beiden Devicetypen. Es gibt aber vermutlich noch viele andere Devicetypen.

Danke, schon mal für eine Antwort.
Grüße, Peter

[Risiko]

Genau das war meine Frage im letzten Post https://forum.fhem.de/index.php/topic,46117.msg1105242.html#msg1105242, welche nicht beantwortet wurde.
Als Anwender soll man da nichts machen müssen!

Es gibt aber vermutlich noch viele andere Devicetypen.

Genau das ist das Problem bei Homematic bzw. der Umsetzung im HM-Modul. Jedes Gerät scheint hier anders zu funktionieren. Meine Anfragen an den Modulentwickler blieben bis jetzt alle unbeantwortet.
Daher bin ich auf die Hinweise, wie jetzt von dir, angewiesen.
Kannst du bitte deine Version hier zur Verfügung stellen?

Risiko

[spe]

Hallo,

ich habe lediglich in der Function den Devicetyp eingelesen und dann anhand von diesem den Prefix überschrieben.
So ist man von den Readings unabhängig.
Ich habe leider nur diese 2 Typen im Einsatz, so das ich leider nicht mehr Infos beitragen kann.

Code Auswählen Erweitern


sub weekprofile_get_prefix_HM($@)
{
  my ($device,$base_name,$me) = @_;
  my @prefix_lst = ("","R-1.P1_","R-","R-P1_","P1_");
  my $prefix = undef;

  foreach (@prefix_lst) {
    my $reading = "$_"."$base_name";
    my $time = ReadingsVal($device, $reading, "");
    Log3 $me, 5, "$me(weekprofile_get_prefix_HM): check: $reading $time";
    if ($time ne "") {
      $prefix = $_;
      last;
    }
  }
  ################### SPE Anpassung Start ###########################
  my $devHash = $main::defs{$device};
  my $model = $devHash->{ccutype};
  Log3 $me, 5, "$me(weekprofile_get_prefix_HM): SPE-Anpassung model=$model, prefix=$prefix";
  if($model eq "HM-TC-IT-WM-W-EU") {
    $prefix="P1_"
  } elsif ($model eq "HM-CC-RT-DN") {
    $prefix=""   
  }
  Log3 $me, 5, "$me(weekprofile_get_prefix_HM): model=$model, prefix=$prefix";
  ################### SPE Anpassung Ende ###########################
  return $prefix;
}


Grüße, Peter

[onurbi]

Hi Risiko,

auch von mir vielen Dank an das super praktische Modul! Habe nach einigen Jahren mal wieder geupdated und mich gleich nach Durchlesen des Theads auf das Anlegen von Wochenprofilen gestürzt!

Topics hatte ich kurz definiert, aktuell ist "attr wp_Bad useTopics 1" aber aus kommentiert. Möglicherweise stört ja ',"TOPIC":"default","REF":null}' am Ende des JSON-Strings vom Weekprofile-Konfigfile von Raum Bad.

Mir ist klar, dass man beim Editieren des "masters" damit rechnen muss, dass nach ein paar Sekunden die Änderung durch das Neueinlesen der Werte weg sind. Ist auch schwer zu vermeiden, da die Masteranzeige auch die von anderer Stelle gemachten Änderungen aktuell anzeigen soll.

Nach spätestens 20s ist das aber auch bei einem mit "+" erstellten Profil der Fall. D.h. ich sollte nach jeder "Zeitzeile" gleich auf Speichern klicken.

Ich hätte einen Vorschlag: Nach Klicken der Zahnräder könnte dann oberhalb der editierbaren Zeittabellen der Profilname angezeigt werden. So kann man sicher sein, nicht das master erwischt zu haben.

Ist das Überschreiben so gewollt?

[Risiko]

Hallo,

ich habe lediglich in der Function den Devicetyp eingelesen und dann anhand von diesem den Prefix überschrieben.
So ist man von den Readings unabhängig.
Ich habe leider nur diese 2 Typen im Einsatz, so das ich leider nicht mehr Infos beitragen kann.

Danke Peter für die Infos.
Ich bin noch am überlegen, ob ich es in irgend einer Art aufnehme. So spezielle Anhängigkeiten wollte ich nie haben. Sehe aber leider aufgrund der aktuellen Umsetzung im HM-Modul auch so richtig keine Alternativen.

Risiko

[Risiko]

Hi Risiko,

auch von mir vielen Dank an das super praktische Modul!

Danke.

Topics hatte ich kurz definiert, aktuell ist "attr wp_Bad useTopics 1" aber aus kommentiert. Möglicherweise stört ja ',"TOPIC":"default","REF":null}' am Ende des JSON-Strings vom Weekprofile-Konfigfile von Raum Bad.

Verstehe leider nicht, was du fragen\sagen willst

Nach spätestens 20s ist das aber auch bei einem mit "+" erstellten Profil der Fall. D.h. ich sollte nach jeder "Zeitzeile" gleich auf Speichern klicken.

Nein, das ist meiner Meinung nach nicht sinnvoll. Komplett bearbeiten und speichern. Dann erst wieder bearbeiten, wenn die Änderungen vom Device übernommen wurden.
Während der Bearbeitung stattfindende Änderungen, werden im Bearbeitungsmodus nicht detektiert und folglich durch das Speichern ggf. wieder überschrieben.

Ich hätte einen Vorschlag: Nach Klicken der Zahnräder könnte dann oberhalb der editierbaren Zeittabellen der Profilname angezeigt werden. So kann man sicher sein, nicht das master erwischt zu haben.

Kling sinnvoll. Mal schauen, wenn ich etwas Zeit habe, kommt es mit rein.

Ist das Überschreiben so gewollt?

Ja, beim Speichern ist das überschreiben gewollt.

[onurbi]

>Topics hatte ich kurz definiert, aktuell ist "attr wp_Bad useTopics 1" aber aus kommentiert. Möglicherweise stört ja ',"TOPIC":"default","REF":null}' am Ende des JSON-Strings vom Weekprofile-Konfigfile von Raum Bad.
Verstehe leider nicht, was du fragen\sagen willst

Sollte nur meine Konfiguration beschreiben, dachte wäre vielleicht wichtig.

Nein, das ist meiner Meinung nach nicht sinnvoll

Da es sonst niemand als störend erwähnt hat, muss ich vielleicht anders vorgehen.
So sind Änderungen auf Dauer halt leicht "mühsam" weil ich immer wieder von vorne anfangen muss. Kann doch nicht im Sinne des Erfinders sein.

Ja, beim Speichern ist das überschreiben gewollt.

Ich habe mich vielleicht unklar ausgedrückt. Ich meinte das Löschen der Änderungen auf die Uhrzeiten welche vorher dastanden. Ich habe ja noch nicht nicht den "Speichern" Button geklickt.

[Risiko]

So sind Änderungen auf Dauer halt leicht "mühsam" weil ich immer wieder von vorne anfangen muss.

Verstehe ich leider nicht.

Ich meinte das Löschen der Änderungen auf die Uhrzeiten welche vorher dastanden. Ich habe ja noch nicht nicht den "Speichern" Button geklickt.

Verstehe ich leider auch nicht.

[onurbi]

Ich liste mal die Schritte auf, die zum Problem führen:

• Weekprofile master mit "+" kopieren
• Name des kopierten Profiles ist "HO"
• Auswählen von"HO"
• Zahnräder klicken
• Erste Uhrzeit Montag von 8:00 auf 8:05 ändern
• 30 Sekunden warten
• Die Uhrzeit springt wieder zurück auf 8:00

Ich kann natürlich vor Ablauf der 20s auf Speichern klicken. Dann wird auch gespeichert. So sind größere Änderungen mit unnötig viel Aufwand verbunden weil ich nach jeder Anpassung Speichern klicken muss, sie war sonst nicht wirksam. Nach 30 Sekunden war die Arbeit für die Katz.

Gibt es irgendeine Möglichkeit, dieses "Undo" zu verhindern?

Solange man im Edit mode ist, sollte das intervallgesteuerte Reading gestoppt sein.

[kadettilac89]

Ich liste mal die Schritte auf, die zum Problem führen:
....
Ich kann natürlich vor Ablauf der 20s auf Speichern klicken. Dann wird auch gespeichert. So sind größere Änderungen mit unnötig viel Aufwand verbunden weil ich nach jeder Anpassung Speichern klicken muss, sie war sonst nicht wirksam.
Gibt es irgendeine Möglichkeit, dieses "Undo" zu verhindern?
Solange man im Editmode ist, sollte das nicht passieren.

habe versucht das nachzustellen, ich habe den edit Mode jetzt 30 Minuten unberührt offen gehabt. Es ist nichts zurückgesprungen. Was aber die Werte löscht ist ein Refresh im Browser.

Schau mal was du in Device WEB (oder dem entsprechenden Web-Frontend) im Attribut longpoll hast. Teste mal 1 oder websocket ..

[onurbi]

Es ist nichts zurückgesprungen

Danke fürs Nachstellen. Das erklärt, warum es sonst niemandem aufgefallen ist.

Ich habe ein "list WEB" ausgeführt. Ich hoffe, das würde das Attribut logpoll auflisten. Es ist "leider" nicht dabei:

Code Auswählen Erweitern

Internals:
   BYTES_READ 8222737
   BYTES_WRITTEN 6005549
   CONNECTS   435
   CSRFTOKEN  csrf_283651142539926
   DEF        8083 global
   FD         7
   FUUID      5fd1ce0d-f33f-cf93-543c-8d1654c7febef272
   NAME       WEB
   NR         6
   NTFY_ORDER 50-WEB
   PORT       8083
   STATE      Initialized
   TYPE       FHEMWEB
   READINGS:
     2020-12-10 08:28:13   state           Initialized
Attributes:
   editConfig 1
   stylesheetPrefix dark

Im Sourcecode der Webseite (Ctrl-U) im Edit mode habe ich zumindest nicht das Wort "refresh" gefunden.

[kadettilac89]

Nur weil es bis jetzt keiner gemeldet hat heißt es nicht, dass sonst keiner betroffen ist. Kann auch sein, dass alle anderen immer zwischendurch speichern.

Wähle das Attribut mal aus und setze es auf 1 oder longpoll ... sind ja nur 3 Werte möglich. Alle 3 mal testen sollte kein großer Aufwand sein.

Das mit dem Refresh hängt von Browser und auch davon ab, ob direkt oder über reverse Proxy o. ä. zugegriffen wird. Bei mir läuft es über einen reverse Proxy.

[onurbi]

Kann auch sein, dass alle anderen immer zwischendurch speichern.

Klar!

Alle 3 mal testen sollte kein großer Aufwand sein.

Nein, ist kein Problem. Teste ich heute Abend.
Kennst Du den Defaultwert von longpoll ?

Das mit dem Refresh hängt von Browser und auch davon ab, ob direkt oder über reverse Proxy o. ä. zugegriffen wird. Bei mir läuft es über einen reverse Proxy.

Bei mir geht es direkt.

[Beta-User]

default ist afaik "1", das aber v.a. aus Kompabilitätsgründen zu einigen älteren Browsern, die ws noch nicht unterstützen. Zu empfehen wäre mAn. "ws".



An der Stelle ein großes Danke an Risiko für's Einbauen der Unterstützung von MQTT2_DEVICE als neuen Client für weekprofile!

Bin mal gespannt, wie viele das Feature nutzen werden . Ist in der Umsetzung auf der MQTT2_DEVICE-Seite nicht ganz trivial, weil jedes Endgerät ein anderes Zielformat haben will und man das daher passend konvertieren muss, bevor man publisht.
Beispielcode ist ab heute auch im svn zu finden, die Kette beginnt mit dem attrTemplate zigbee2mqtt_thermostat_with_weekrofile und der zugehörigen myUtils-File.

[Risiko]

Ich liste mal die Schritte auf, die zum Problem führen:

Ich kann das auch nicht nachstellen.
Es kann nur mit der Verbindung zwischen FHEM und Browser zu tun haben.
Bei click auf die Zahnräder wird das Wochenprofil zum Browser gesendet. Die Bearbeitung erfolgt mir JavaScript vollständig clientseitig im Browser, welcher das vollständige Profil beim Speichern wieder an FHEM (weekprofile) sendet.
Ich weiß nicht, wer ein Refresh der Seite auslösen sollte.

Risiko